Allow to see private emails in shared mailboxes in outlook (in OWA you can see them)
Short:
On shared mailboxes in office 365 emails that are flagged by the sender as private are hidden. In OWA they are visible.
Long:
Users having full access to the shared mailbox do not see emails sent with a private flag - and they do not get informed about it. The emails are just silently hidden by outlook without any further notice. Quite stupid, for a shared mailbox (e.g. incoming orders!)
We discovered that by coincidence: Our users were concerned because the number of unread emails was increasing - although there were no unread emails visible for them.
If they open the same mailbox in OWA, they can actually SEE the private email!
Improvement:
Get consistent behavior between OWA and Outlook.
Let an administrator configure right to see the private messages on shared mailboxes.

83 comments
-
Automation Means Salvation commented
Hello!
We found a workaround for this issue by first creating a dynamic distribution group which contains all SharedMailboxes.
Using recipient filter, it can also be used to only contain certain SharedMailboxes.Create DDG:
New-DynamicDistributionGroup -name "<name>" -alias "<alias>" -Displayname "<DisplayName>" -RecipientFilter "(RecipientTypeDetails -eq 'SharedMailbox')" -PrimarySmtpAddress "<primarysmtpaddress>"Hide DDG from Addresslist:
Set-DynamicDistributionGroup "<name>" -hiddenfromaddresslist $trueDisable that eMails can be sent to the Group:
Set-DynamicDistributionGroup "<name>" -AcceptMessagesOnlyFromSendersOrMembers "<name>"Check DDG Members PowerShell:
$ddg = Get-DynamicDistributionGroup "<name>"
Get-Recipient -RecipientPreviewFilter $ddg.RecipientFilter | fl displayname,primarysmtpaddressThen we created a transportrule to change the Header
FROM
Sensitivity: private
or
Sensitivity: company-confidentialTO
Sensitivity: normalNew-Transportrule -name "Change Header PRIVATE or CONFIDENTIONAL to NORMAL" -SentToMemberOf <DynamicDistibuionGroup> -HeaderMatchesMessageHeader "Sensitivity" -HeaderMatchesPatterns "company-confidential","private" -SetHeaderName Sensitivity -SetHeaderValue Normal
You can also create a similar TransportRule which just REMOVES the Header-Lines
Sensitivity: private
or
Sensitivity: company-confidentialBut paradoxically outlook still treats the messages as confidentional or private (=invisible in SharedMailbox), even if the header has been removed.
That's one of the biggest mysteria in the long existence of MS Outlook.
Therefore only changing the Header to "Sensitivity: normal" works. -
Anonymous commented
PLEASE. Driving me mad!
-
Anonymous commented
same here
-
Donny Nicotero commented
I was able to fix the issue with some help from the comments here, and some ideas from our email vendor and spiceworks (they were able to resolve the issue for a shared mailbox who had an AD account prior)
My account was ONLY a shared mailbox, EVER.
I used these steps provided by Rayco in the comments here.
1. Remove all delegated permissions
2. Wait for it to drop from Outlook folder list (set from Automapping) and/or remove direct access setup through File/Account Settings 3. Re-add permissions - Add-MailboxPermission -Identity sharedmbx@domain.com -User delegate@domain.com -AccessRights FullAccess -AutoMapping:$FALSE
4. Manually re-add to Outlook – File/Add Account - authenticating with delegate users creds
5. Can you see the private emails now? It appears there's a difference in access with Automapping vs. manual config as this is also the same fix I need to setup a rule in a shared mailbox that requires the action: have a server reply using a specific message.Unfortunately when I tried this on the admin account that I usually use, I might not have waited long enough for it to work. I used a test account with nothing else attached to it, added the SharedMailbox@domain.com email via the File/Add Account, signed in with the Dtest user email and password, and after 30 minutes the SharedMailbox@domain.com box was visible and expanding. If you get the message that the set of folders can not be expanded, go make some coffee and come back in half an hour.
Now, once the box was visible, I simply went into the delegate access as stated below. When I tried this before on a user email, it was trying to give the delegate access on the main account.
When it is setup in such a manner that it was not auto mapped, rather added via the File – options menu, the delegate access did allow me to update the permissions for each user in such a way that the private tagged emails DO SHOW properly now!Adding the delegate access was just like this:
Select File in outlook.
Verify the SharedMailbox@domain.com is selected in the info tab drop down menu.
Left Click Account Settings
Left Click Delegate AccessAdd the permission to whichever user you would like.
Assign the Edit permission to all categories.
Tick the box that allows the user to view the "private" items.There was a bit of an issue in being able to add the delegate access, but luckily the Microsoft KB article the error referenced helped me to edit the registry to bypass the need for this missing permission and the functionality it was trying to add.
https://support.microsoft.com/en-us/help/2593557#x_x_letmefixitmyself
That is noted in the above article.
Thanks for the assistance in resolving this matter, and I figured it would be good to share how I was able to do this without actually manually interfacing with each user. (Hallelujah)
-
Dave Webster commented
Just on with support about this now.
Just another another day and another annoying bug that should be fixed without us needing to add votes to user voice..
disappointing.. -
Johnny commented
Very frustrating. Permissions are set correctly, but within Outlook client, still show Private for calendar. If OWA shows full calendar view, that should reflect in Outlook client.
-
rayco commented
This was adversely affecting us as well and believe I found a workaround. Try this….
1. Remove all delegated permissions
2. Wait for it to drop from Outlook folder list (set from Automapping) and/or remove direct access setup through File/Account Settings
3. Re-add permissions - Add-MailboxPermission -Identity sharedmbx@domain.com -User delegate@domain.com -AccessRights FullAccess -AutoMapping:$FALSE
4. Manually re-add to Outlook – File/Add Account - authenticating with delegate users creds
5. Can you see the private emails now? It appears there's a difference in access with Automapping vs. manual config as this is also the same fix I need to setup a rule in a shared mailbox that requires the action: have a server reply using a specific message.I forgot to add - this is an unacceptable workaround as most of us have too many shared mailboxes to work through. Seems obvious Microsoft that this needs to be resolved with a better solution.
-
Anonymous commented
This is absolutely critical especially in hospital and medical school settings where messages with confidential information are often marked private but need to be viewed by the people who have access to the mailbox in a timely manner, the view in the client should be consistent with the web interface.
-
Justin Williams commented
This is actually very critical in a hospital environment. We get medical records needed for treatment from external services that are marked private. When received (or not based on if they can see the email or not in the shared mailbox) the treatment is carried out as needed. Being that these same items can be seen in OWA this doesn't seem like a "working as designed" issue, or you have a bug in OWA.
I understand the reasoning for this option to hide private messages in a user mailbox (admins shouldn't always see messages that are private). I absolutely agree with this. However, if the option was available for shared mailboxes to be turned on or off from the m365 AC per mailbox, this would be an excellent means to control the option for a shared mailbox.
We can setup the users as delegates on the mailboxes' calendars, but by Microsoft's own recommendation that multiple delegates on a calendar is not a good idea, and if the calendar is being used as well, this creates a whole new level of risk and brokenness to deal with.
-
Anonymous commented
Same on Exchange 2016 on-prem.
-
Amir Nazem commented
Please fix this, this is crucial.
-
Adam Lavery commented
For goodness sake Microsoft, just fix this. It makes zero sense that a delegate added through Outlook can access private emails but a delegate added through Full Mailbox Access cannot. How obviously very stupid.
-
jersson commented
requiero de su colaboracion para que solucionado el error, el cual no permite que los mensajes privados estén visibles en el buzón compartido
-
Anonymous commented
This needs fixing asap
-
Kevin P commented
Having this exact same issue.....and it is causing business impact!
-
Sean Callanan commented
We are seeing this now in our tenant, I’m hoping you find a fix regardless of how many ‘votes’ as this issue can go unnoticed. We have been using O365 exchange for over two years and have probably suffered with the issue without knowing. Please fix!!!
-
Anonymous commented
Encountered this for the first time today. Very frustrating that an Exchange Admin cannot alter the setting to allow delegates to view private messages in a Shared Mailbox.
-
Anonymous commented
We are also facing same issue. Private email not visible in outlook. Please give a fix.
-
Mark Sullivan commented
Agred this needs to be fixed. At least give an Exchange Administrator an option to allow Private Messages to be visible in the shared mailbox
-
Scott commented
I seriously have a hard time believing this has been a known issue for over 3 years!