AutoMapping Shared Mailbox based on security group

[Cody Henschel]

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 automapping feature work (ie. all members of the security group would see the share mailbox in their outlook profile)

Testing has shown this not to be the case, and now I am seeing this: https://technet.microsoft.com/en-us/library/jj919240(v=exchg.160).aspx  which is also suggesting that shared mailboxes cannot automap on a security group.

Can anyone say for sure one way or the other - is this on the radar to start working eventually?  I know people have been talking about this since exch 2010.

[#2 · Accepted solution]

Automapping 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)

[#3]

Quite possibly the biggest problem an IT team that deals with Exchange has to contend with in a very large organisation. Assigning individual users to shared mailboxes is a bit of nightmare for tracking who has access to what, its odd that Microsoft would create a feature designed to streamline but then chose to neuter it by tying it to a highly work intensive task.

Imagine an Exchange system with 8,000 users and a couple of hundred shared mailboxes. If enough people asked nicely they may finally make Automapping work with Security Groups, that would be a dream come true.

[#4]

Hi to all,

I have done this in past week in a customer and have worked:

- Create a Security (Mail Enabled) Group

- Add Members to that group

- Create a Mailbox and gave full access to the Security Group

Auto mapping have worked without any problems and you have a group based permissions that is used to distribute email and have access to a shared mailbox and the same security group have access to a SharePoint site.

[#5]

Hi Nuno!
Can you share which version of exchange this is?
I'm having the same problem with exchange 2010. My security groups are not mail enabled.

[#6]

Hi Kari,

It was on Exchange 2016 and on Office 365.

I suggest you to upgrade to Exchange 2016 or migrate to Office 365.

[#7]

You are right, however, Automapping works for all users in a group only when granting access the group for the first time to the shared mailbox, the issue is when adding a new user to the group, automapping won't work for any new user.  :(

[#8]

Would removing FullAccess permissions and re-adding via Powershell cause newly added members to get Auto-mapping? Or does it only work on the initial adding of permission to the shared mailbox?

[#9]

Re-Adding users (not groups) to the list of users having FullAccess permission will add AutoMapping to those users. Using PowerShell gives you the ability to enabled/disable AutoMapping per user added to the list of users having full access. AutoMapping is enabled/disabled for each user added to the list of users having full access. It is not controlled for the mailbox providing access to.

-Thomas

[#10]

So, to be clear, re-adding a sec group to the Full Access list, in GUI or Powershell, will not grant users of that group Automapping? Is this different on more recent versions of Exchange (2016 and/or O365)?

If no, is there any way to automap users that have access to a mailbox via their group membership?

Thank you for your time.

[#11]

You are right. AutoMapping is applied to user accounts added directly to the list of users having FullAccess for a mailbox. AutoMapping is not applied based on an added security group.

Adding a user using GUI -> always AutoMapping:$true

Adding a user using PowerShell -> AutoMapping:$true|$false, as selected

Adding a group using GUI/PowerShell -> AutoMapping not configured aka $false

That behavior has not changed in recent versions. 

[#12]

Hmmm, ok.

So let me just get this 100% clear because now Nuno and Thomas are saying two different things and one important question has gone unanswered imo.

Nuno states:
When adding a mail-enable security group with users in it, these users WILL get AutoMapping:$true at this point.

Someone points out:
Yes, but ONLY right then and there. Adding more users to the group will not set AutoMapping:$true for these newly added users.

Thomas then states:
No. User Groups does not work with shared mailboxes and automapping. Period.

So here is my summarization and conclusive question to all this.
I havent testet this myself, but it sound to me it should be possible to:

• Create a mail-enabled security group for automapping (or mail-enable an existing)
• Add this group to a shared mailbox by GUI or powershell and thus have the AutoMapping:$true set for all members by doing so.
• Future additions to this user group will then require removal and re-adding of said user group to ensure new members also get AutoMapping:$true

If this is the case, it could actually be a viable solution for me. Then simple automation could ensure the last action somehow. 

I hope to find time to test this in the very near future.

[#13]

Hi again,

I tested Nuno's claims as detailed above and can NOT confirm group assignment to be working in relation to auto mapping of shared mailboxes and/or additional user mailboxes in ANY form or application.
On the contrary it seems group assignment could be viewed as completely defered by Microsoft in O365 configurations.

Adding mailboxes as independant accounts in an Outlook profile may show the mailbox in your view, but permissions are not as expected in spite of FullAccess and/or SendAs permissions are set.
In addition, a users will be prompted for each extra mailbox he/she tries to add. Pass-through authentication seems to be void in this setup (using outlook 2016/2019)

Automapping presents other challenges in end user functionality as:

• Automatic population of "From:" field is no longer set according to which mailbox you are currently "standing in"
• Replies to mails in any other mailbox than the one marked as Default, will now only reside in "default" mailbox Sent Items.
• Same goes for Deleted Items. Huge problem if shared mailbox deals with (for instance) sensitive data.

There are registry options you can set for your Outlook klients to revert to old "normal" behavior for this. (Note: one of them requires you to enable Cached Mode)

https://support.microsoft.com/en-us/help/202517/items-that-are-deleted-from-a-shared-mailbox-go-to-t...

https://support.microsoft.com/da-dk/help/2843677/messages-sent-from-a-shared-mailbox-aren-t-saved-to...

As for automatically populating From: field I have found no solution whatsoever from MS or community forums.
Puzzles me a bit as I thought many people use shared mailboxes this way.
We have implemented our own VBA based solution to satisfy customer end user expectations.

[#14]

Hi Kilo77,

We are about to migrate our 2500 staff and 300 shared mailboxes from on-prem Exchange to O365 and I have the same concerns as you regarding the pitfalls of automapping - as cool / handy a feature as it seems.

We have only ever controlled shared mailbox access via security group.  In other words:

1. Create the shared mailbox.
2. Create the security group.
3. Add users to security group.
4. Grant security group full and send-as permissions to the shared mailbox.

Our users understand the process of adding the mailbox within Outlook and this method has worked perfectly for us for the last 10+ years.

Moving to O365 we obviously need to make sure that we have a handle on the process and would, in an ideal world like to continue with the above method.

Automapping is a cool feature and is certainly much less hassle for the end user as they don't have to manually add the mailbox but whilst some of the above issues can be mitigated with reg settings and the set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $True , like you say, the From field is not automatically populated.

Anyway, I just wanted to echo your sentiments on this subject...

Edit.  I just found this !!  Have you seen this?  I need to test this ASAP!!

Regards,

Graham

[#15]

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

[#16]

The mailbox setting MessageCopyForSent(As)Enabled is juste one side of the coin...
The options don’t exist for deleted items.
There should be a uservoice about this.

[#17]

There IS a 'uservoice' about this. Please go vote:

https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/11439519-allow-automappin...

[#18]

This UserVoice suggestion would be more appropriate. As it's just for AutoMapping with security groups.

https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/36525364-enable-auto-mapp...

[#19]

@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

[#20]

Hi 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)