Sep 11 2017 10:18 AM
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.
Sep 11 2017 12:48 PM
SolutionNov 05 2017 11:26 AM - edited Nov 05 2017 11:33 AM
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.
Nov 05 2017 02:14 PM
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.
May 18 2018 01:43 AM
May 18 2018 03:55 AM
Hi Kari,
It was on Exchange 2016 and on Office 365.
I suggest you to upgrade to Exchange 2016 or migrate to Office 365.
Jun 19 2018 07:00 PM
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. 😞
Jul 30 2018 07:06 AM
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?
Jul 30 2018 08:28 AM
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
Jul 30 2018 09:24 AM
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.
Jul 31 2018 01:41 AM
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.
Nov 28 2018 06:56 AM - edited Nov 28 2018 06:56 AM
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:
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.
Dec 21 2018 07:20 AM - edited Dec 21 2018 07:22 AM
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:
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)
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.
Jan 31 2019 12:58 PM
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:
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
Feb 03 2019 02:50 PM - edited Feb 03 2019 02:55 PM
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
Jul 05 2019 04:17 AM
Oct 02 2019 11:29 AM
There IS a 'uservoice' about this. Please go vote:
Sep 04 2020 05:49 AM - edited Sep 04 2020 05:54 AM
This UserVoice suggestion would be more appropriate. As it's just for AutoMapping with security groups.
Sep 07 2020 03:30 AM
@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
Oct 21 2020 03:57 AM
Sep 11 2017 12:48 PM
Solution