Forum Discussion
Cody Henschel
Sep 11, 2017Copper Contributor
AutoMapping Shared Mailbox based on security group
Hi, We were under the impression that once on exch 2016 we would be able to use mail enabled security groups for shared mailboxes -- and (this is the important part) still be able to have the aut...
- Sep 11, 2017Automapping works via the user who is granted permissions being stamped on the msExchDelegateLinkList attribute of the target object. This attribute only lists mail objects and not groups. No change with 2016 (or O365, which runs a version of 2016 at the moment)
kilo77
Feb 03, 2019Copper Contributor
Hi Graham,
Yes it is a rather daunting task, as I find the MS documentation on this subject to be flawed in relation to my real-life tests are showing me.
I believe I have seen the article you refer to (and others stating the same)
If we break it down, your link takes me to a segment called:
Use Exchange Online PowerShell to create a shared mailbox
Which in turn states:
"Users who are members of the security group will be granted the permissions to the mailbox."
And this is entirely true. However, my tests have shown that the Shared Mailbox will never automap.
Furthermore, following the link just above the Use Exchange Online PowerShell to create a shared mailbox section to:
Open and use a shared mailbox in Outlook 2016 and Outlook 2013
You will find a section called
What if it didn't work?
Stating that you then simply add the shared mailbox using the
File > Account Settings > More Settings > Advanced > Add approach as we did it "in the old days".
This will most definitely NOT work in a hybrid setup.
To my experience the shared mailboxes will indeed show up in the Outlook tree, but users wont even be able to see the contents of it.
Using the method of adding the Shared Mailbox manually as an additional account, will work - as in the mailbox showing up in the Outlook tree and users being able to browse it.
BUT the automatic population of FROM: even though you reply to an item in that Shared Mailbox, will still not work.
Furthermore users will be prompted for (o365) username and password when adding it AND again every time they change their user account password. (Hybrid Setup mind you)
This even though single sign on has been implemented - as far as my tests goes.
I believe the actual premise for automatic population of the FROM: field has an dependancy on the actual Outlook profile account context - actually the data file. This sounds a little weird but it explains what I see.
We never did find a out-of-the-box solution to this problem and so we ended up providing Send From buttons inside the Outlook client using good old VBA.
We couldnt solely rely upon users remembering to populate the FROM: field whenever they responded to emails in the Shared Mailboxes (Customer relation functions)
In addition the Registry "hacks" I mentioned earlier makes sure a copy is NOT saved in the users own send items and ONLY created automatically in the respective Shared Maibox's Send Items.
(As such we did NOT set the -SendAsItemsCopiedTo or -SendOnBehalfOfItemsCopiedTo on the Shared Mailboxes as this would produce duplicate items in Sent Items)
I hope this all makes sense to you :)
I really look forward to hearing what your real-life tests show.
Kind regards,
Simon
Sep 07, 2020
kilo77
The AutoMapping feature was never intended for use in conjunction with security groups. The primary reason is that not only a permission entry is added to the shared mailbox, regardless of the mailbox type. The user granted full access to the mailbox has a backlink attribute updated. As a result, there are two "pointers", one for each connected direction.
It would be a smarter approach using a PowerShell script to add or remove users from a full access assignment to a mailbox. This would provide the flexibility to add users for full access having AutoMapping enabled or not.
Some organizations prefer to *not* map mailboxes automatically, but require user to add mailboxes manually, as needed.
-Thomas
- DevinPughJul 19, 2023Copper Contributor
The main issue I'm running into is the ability of users with full access rights given to them by a security group to a shared mailbox being unable to open an encrypted email sent to the shared mailbox. Issue described here Can't read encrypted or restricted message sent to shared mailbox in Outlook - Outlook | Microsoft Learn. The only "fix" is assigning each user to have full access individually so that the mailbox is auto-mapped to Outlook for this functionality to work. Obviously this is not a fix in a large environment with hundreds of mailboxes and thousands of users.
- Kilo77_DKOct 21, 2020Copper ContributorHi Thomas,
I understand and has since found this out as well. But my criticism of the MS documentation remains - at least for wording of phrases like:
"Users who are members of the security group will be granted the permissions to the mailbox."
;D
Kind regard,
Simon (Kilo77)