In a hybrid deployment, when Office 365 mailboxes are moved to another forest, sometimes mailboxes are not automatically mapped with their respective Outlook profiles.
When we talk about the non-hybrid deployment, automapping works when a user is assigned with full access permissions to the mailbox before the migration. In this case, for assigning full access permission, Add-MailboxPermission cmdlet is used by adding different values to user and his mailbox (to link the objects). The links used are – msExchDelegateListLink (for mailbox to which permission is assigned) and msExchDelegateListBL (for user to which permission is granted).
The reasons for failure of automapping of Office 365 mailboxes with their Outlook profile could be that the user is running the older version of Outlook application or Active Directory attribute values not available to enable the auto-mapping.
There can be two scenarios in hybrid deployment of mailboxes –the permissions are assigned before moving the mailboxes to cloud or the permissions are added after the users or mailboxes are migrated. In both the conditions there is a requirement for enabling the automapping feature.
In the first scenario (permissions are assigned before migration), the automapping attributes, msExchDelegateListLink/BL are to be synchronized by Azure Active Directory Sync (AAD Sync) to the cloud prior to migrating the mailboxes. And while migration is being performed, Mailbox Replication Service in Exchange Server transfer the permissions.
If we talk about the second scenario (permissions are added after moving the mailboxes), the permissions which are added through Add-MailboxPermissions cmdlet. But since the user resides in the on-premises environment, the automapping attributes, msExchDelegateListLink/BL is not added then.
Users can manually add the automapping attributes to mail user object to synchronize it to the cloud. And the synchronization can be performed through AAD Sync. Go to your Active Directory PowerShell module and set the attributes manually using Add parameter of the Set-ADUser cmdlet. Also, users should ensure that user mailbox for migration is running the May 2015 Public Update (PU) for Outlook 2010 or later updates.
You can also troubleshoot the automapping in Office 365 mailboxes. When a mailbox is to be auto-mapped to a profile, there is a need to return information to Outlook within Autodiscover XML. Inspect for this user condition by following the below steps:
In the review, check for the values in the AlternativeMailbox tag (and for Archive mailboxes ii listed as an alternative mailbox of the Archive type).
There can be any of the 2 conditions here, whether the mailbox is listed or not listed in the AlternativeMailbox tag.
Thus the automapping issue after Office 365 migration can be managed easily by end users. However, if you want to avoid issues and perform hassle-free cross-forest migrations, then select the outstanding Exchange migration tool Kernel Migrator for Exchange which provides instant migration without any automapping issues. The tool is capable to perform all type of Exchange and cloud migrations including migration between Office 365 tenants. It also migrates user mailbox permissions from the source to destination.
There can be Automapping issue after the Office 365 mailbox migration in a hybrid deployment. Some methods for troubleshooting are discussed here. And, a reliable third-party software for easy and effective cross-forest migration is recommended to avoid such issues.