Auto-Mapping Mailboxes After Office 365 Migration
Getting the mailboxes to which you have full access automatically mapped in the Outlook profile dates back to Exchange 2010. While it is a time saver in an on-premise deployment of Exchange 2010, how will things be when these mailboxes are migrated to Office 365 in a hybrid deployment?
More...
This is an issue which most of the customers doesn't take into account, thinking that Azure AD Connect is synchronizing all the attributes to the cloud and hence the auto-mapping should just continue to function irrespective of whether the mailboxes are in the cloud or not. Wrong!
The msExchDelegateListLink is the attribute that facilitates the auto-mapping of the mailboxes to which you have full access in your profile. But when these mailboxes are migrated to Office 365, do you think this will continue to work out of the box? Nope!
The mailbox move will bring across the permissions stamped on the mailbox to Office 365. But, if you want to get the auto-mapping back, the full access permission needs to be removed from Exchange Online and added back in. It is the stamping of the permission in Exchange Online which triggers the auto-mapping to start working again.
- One more thing to do add to the post-migration of a mailbox!
Remove the full access permissions and add it back in. Below is what happens if you migrate the mailboxes into Office 365 without taking into account the auto-mapping issue.
- All mailboxes are visible in the user's Outlook profile prior to migration.
- Once the mailboxes are moved to Office 365, user will get a prompt to authenticate against Azure AD. Punch in the credentials and select the checkbox to remember them.
- As soon as that happens, the auto-mapped mailboxes will disappear from the profile.
- The user can always add the mailbox back manually by going into the account properties and add the additional mailbox.
- If an admin wants to automate this, the permissions will have to be removed and re-stamped in Exchange Online.
- We have seen that just re-stamping the permissions in EXO triggers the auto-mapping.
- It is better to remove and re-stamp to be on the safe side, especially if you are automating it using a PowerShell script as a post-migration task.
Have you come across this issue before? Is there any other solution to this?
