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.
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\
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)
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.