A common misconception about granting mailbox access rights in Exchange Online is that you can only add access to the individual and not a group. You may have opened the Exchange Administrator Center (EAC), found the mailbox you wanted and looked at the delegated access tab. Only to be provided with a list of eligible user identity’s, but none of your on-premises security groups that have been created. Fear not, the on-premises groups just need a little remediation to the correct flavour to be seen in the picker and then applied.
The key settings of a group to assign mailbox access in Exchange Online are:
- Universal Security
- Mail Enabled
Things in your environment may have gotten this way over time as legacy on-premises Exchange Server versions weren’t as picky with your selection and would allow the permission to be granted to any kind of group you threw at it. Moving to Exchange Online has more sophisticated taste that needs to be catered for due to its Evergreen state with all the latest Exchange trends.
If you migrate on-premises mailboxes with these slightly incorrect permissions to Exchange Online they will be lost forever. So if you remedy the existing on-premises mailboxes before initiating a remote move request to Exchange Online, no further action will be required at completion.
The Process
Update the group to universal:
[code language=”PowerShell”]Get-Group $Name | Set-Group -Universal[/code]
Mail enable the group:
[code language=”PowerShell”]Enable-DistributionGroup -identity $Name[/code]
Finally, not compulsory but if you want the group to be hidden from your Exchange Address Book:
[code language=”PowerShell”]Get-DistributionGroup -identity $Name | Set-DistributionGroup -HiddenFromAddressListsEnabled:$True[/code]
Force a synchronisation of your group modifications with Azure Active Directory and you should find that the group will be available in the Office 365 Exhange Administrator Center. On the Azure AD Connect Server:
[code language=”PowerShell”]CD C:\Program Files\Microsoft Azure AD Sync\Bin\
.\DirectorySyncClientCmd.exe delta[/code]
So my final note that I would like to re-iterate is that if you tidy this stuff up before migrating to Office 365 you will have a lot less problems when the mailbox becomes active in Office 365. A mailbox that has been migrated with a faulty group type will have permissions assigned on the object, but will not resolve to an object and therefore only show SID information. Firstly the permissions fail, but secondly, it makes it very difficult to find out what the group was previously to add post migration. (see first permissions below)
Hot Tip
Fix the issue with your groups before you start the synchronisation of the mailbox to Exchange Online and the permissions will be stamped correctly during the initial phases of the move request and once finalised, will work as expected.
Hello Arren,
We have implemented the same solution in our environment and we have come up with an issue, where automapping of shared mailbox does not work when permission is assigned through a security group and the mailboxes are migrated to O365.
Kindly suggest how do we address this issue. We have been in touch with Microosft but there is no help!.
Thanks and regards
Rashmita Priyadarsini
You need to use a script that reads the a security group, then applies those users to the mailbox directly.
I have one setup so that every 30 minutes is does a check between the groups and exchange and removes/adds the users as required.
To echo Rashmita… Setting delegation to a group negates the system’s ability to automatically assign a mailbox to members of the group!
While you can manually assign a different mailbox through the account advanced properties, it’s an annoyance that is generating techsupport issues.
We are using Office365 and this seems has been an issue for several years…
Its be design.
Use this this script to have the feature you are looking for, I have this working on 365.
https://gallery.technet.microsoft.com/office/PowerShell-script-for-fe189ccc