This article is based on a migration project I’m currently working on for a large financial company in the Netherlands. In total, we had to migrate around 10000 mailboxes. Because we wanted to keep effects for the users a minimum, I’ve written a migration script that fixes all functionality that gets broken by default when performing a migration.
Microsoft has fixed some of the broken functionality in some upgrades to Exchange Online released around April 2019, but still a lot of functionality is negatively effected when migrating to Exchange Online, using the hybrid migration scenario. All other scenario’s will have an even larger impact on the user population and will normally not be used in a migration of an Exchange organization of more than maybe 50 mailboxes anyways.
The information that I will add to this article can be found on other websites as well, but not all in one spot, including solutions to almost all of the issues you will face.
Situation
This article is based on a migration from Microsoft Exchange 2010, to Exchange Online. The source setup is based on two separate Exchange 2010 organizations, one based in the Netherlands and a second one for the US and Asia locations.
Both Exchange organizations operate in different AD domains, as you cannot have two organizations with a single forest.
The domains do have trusts in place and make use of Quest Collaboration Services, to synchronize the Global Address list and Free busy information.
QCS creates disabled user accounts in the domain of the opposite Exchange organization.
These disabled user accounts are setup with a limited set of attributes. The objects in the Dutch setup, representing the US and Asia accounts, are also in use for the Skype for Business setup, that is only running in the Netherlands, for all employees.
Security is very important and neither Exchange nor Skype are exposed to the internet, except for the Microsoft Azure and Office365 systems required for the Hybrid setup.
ADFS is in use and access is limited to internal clients, or clients that use VPN connections. Azure AD Connect is in use to synchronize a limited set of Organizational Units from the AD domains in both the Netherlands and the international domain. QCS objects are some of the objects excluded from this synchronization, as they would conflict with the objects synchronized from the international domain.
So this is not a ‘simple’ lab setup but an actual, rather complex production environment.
What breaks
Recipient Display type
When you migrate a mailbox toward Exchange Online, by default the recipient display type setting the user object on-premises will get set, does not allow on-premise mailbox users, to grand the migrated user any permissions any more.
This results in a broken functionality. Part of the permissions that were set in the past will continue to work, some settings will need additional repairing covered in the other section that follow, but on-premises users can no longer assign permissions to a migrated mailbox in folder permissions for instance. The user object can no longer be found in the address list.
This can be repaired by changing the recipient display type to an acl-able object variant.
Depending on the type of mailbox object that is being migrated, a new recipient type display setting should be set.
The actual attribute setting is a fairly long numerical value, representing the type of mailbox coupled with the AD user object. The table below lists the setting the user object will receive by default and the setting it needs to be changed to, to recover the normal functionality:
| Default migrated setting | Corrected setting | Mailbox type |
| -2147483642 | -1073741818 | Mailbox user |
| -2147482106 | -1073740282 | Remote Mail user |
| -2147481338 | -1073739514 | Contact |
Practically you will almost always see the Mailbox user object of course, as the other objects will normally have no mailbox connected.
If however you need to be able to assign permissions to contacts or remote mail user objects that have an on-premises AD object, the contact and remote mail users object might turn out to be relevant after all. In Powershell I’ve used the below command to first get the AD object by using the UserPrincipalName (included in the variable $upn) and then setting the corrected value:
get-aduser -filter "userprincipalname -eq '$upn'"|set-aduser -Replace @{MSExchRecipientDisplayType="-1073740282"}To be able to limit the number of corrections to only the applicable situations, I’ve created a filter first checking on the current setting for the user at hand. This will also allow for the script to be rerun, in case it’s execution would get interrupted for some reason, and then only attempt to correct user objects not set correctly.
Specially in migrating large batches of mailboxes, a script monitoring the migration process might take several hours to complete.
The environment I’ve run the script in, uses strict timeout settings for RDP sessions, potentially interrupting the script before it completes.
Send As permissions
When working in a hybrid setup for a longer period of time, or just in the migration phase, Send As permissions is one of the main functionalities that break.
The problem in Send As permissions is that they are maintained on Active Directory level in Exchange on premises and not actually in Exchange attributes. The Send As permission is not synchronized to Exchange Online and thus breaks in the migration or hybrid process.
However, send as permissions can be set on both ends. You have to look at Exchange Online as a separate Exchange organization. Send as permissions for cross premises objects need to be defined on both ends. Or actually, the location of the actual sender needs to be aware of the send as permissions this sender has on other objects.
The most easy way to look at this, is double administration of send as permissions. When you assign someone send as permissions of another mail object, you define it on both on-premises Exchange and Exchange Online.
One additional thin to keep in mind, when defining Send As permissions within Exchange Online, for on-premises Exchange objects, every single SMTP address present on the on-premises object, needs to use a domain name that is registrered as an accepted domain in Exchange Online, not just the default reply address!
Problem solved
How to fixed it during migration?
You could of course do this manually for each user, but I’ve created two scripts. One script that will perform the mailbox migration and several check up front, monitor the migration, corrects the several functionalities that break and several checks after the migration. It finally generates a report for each migrated mailbox. A second script reads the send as permissions setup on-premises and replicates these settings to Exchange Online and visa versa.
In the below PowerShell Example, $MailboxIdentifier determines the mail object who’s address will be used in the Send As operations. This will be a remote mail object from the perspective of the Exchange Organization. $UserIdentifier determines the user who’s granted permissions to execute the Send As permissions. This will be a user object local to the Exchange Organization the command is executed againts.
add-recipientpermission -identity $MailboxIdentifier -accessRight SendAs -trustee $UserIdentifier -confirm:$falseWhen migrating a user mailbox to Exchange Online, you need to watch both other objects having send as permissions on the migrated mailbox and the permissions the migrated mailbox owner has on other mailbox objects. Corrections need to be made in two directions to keep the functionality working in both ways.
Send on behalf
Send on behalf permissions actually are synchronized. The migration script I’ve used in the migration process verified these permissions before and after the mailbox migrations and I can acknowledge these permissions stay intact during migration, so no need for corrections, as long as the object granted with the permission is available online!
We have seen send on behalf permissions granted to AD groups that are not synchronized. These will break as the group object is not available in Exchange Online.
Another situation that will break these permissions is when the permission is granted via a group that is not mail enabled. Again that group object will actually not be available in Exchange Online, despite it being synchronized to Azure AD.
I’ve added a section to my migration script, that will test the group synchronization status and check if it is mail enabled. If it isn’t available in Exchange online for either of these reasons, I’ve expanded the group and assigned the permissions directly to the users.
This same process can also influence other permissions like send as and full access. Folder permissions are less likely to have been assigned to a group that’s not mail enabled, but it could still be a group outside of the Azure AD Connect sync scope.
SentItemsConfiguration
The mailbox settings for how to process sent items, is not synchronized to Exchange Online. If you have for instance a shared mailbox that you have setup to copy the sent items to the shared mailbox’ sent items folder using the Exchange setting MessageCopyForSentAsEnabled or MessageCopyForSendOnBehalfEnabled, these settings will get lost in the migration.
The functionality is available in Exchange Online just the same, so this can easily be fixed to reapply the desired settings once the mailbox is migrated.
Keep in mind this functionality can only work when both mailboxes (the mailbox that is actually sending a message and the mailbox who’s address is being used) are located in the same Exchange Organization. During the time-span only one of the mailboxes is migrated to Exchange Online (the obvious default objective in a hybrid migration scenario), this functionality will be broken!
The reason the functionality will not work when mailboxes are spread over the federated setup is simple, federation between Exchange Organizations is limited to mailtransport, address list synchronization and availability information. MessageCopy settings are not transport based and cannot be executed.
Resetting the MessageCopy setting on Exchange Online will only fix the functionality, as soon as both mailboxes involved in the MessageCopy process have been migrated.
Of course I’ve included this correction in the migration script I’ve used.
Full Mailbox Access
The full mailbox access permissions will normally survive the migration process, but this does depend on how the permissions are assigned. If the permissions are setup using a group which is either not synchronized, or is not mail enabled, the functionality will break.
When fixing the permissions, you will also need to be aware of automapping. When assigning Full Access permissions in Exchange 2007 and up, by default you will also enable automapping. On older versions of Exchange, automapping did not exist. Automapping is actually processed by a different attribute in AD (MSExchDelegateListLink) compared to the Full Access permission. When making corrections to full mailbox access, you need to take the automapping setting into consideration.
In this perspective, it’s very unhandy that Exchange Online does not offer a way to determine if automapping is setup for a certain mailbox. You can disable automapping only when granting full access, but after that, you can only observe if automapping is actually enabled or disabled, by using Outlook.
FolderPermissions
Folderpermissions are a bit special when migrating to Exchange Online. Generally, they will continue to work, but I’ve also seen many mailboxes that are missing some of the permissions that were granted before the migration.
In my experience, this is more related to some user objects that loose permissions on other mailboxes than mailboxes losing the permissions.
However I was unable to determine why some users will loose the permissions to other mailboxes.
Inside my migration script I included a section to export all folder permissions set on source mailboxes and checking the permissions are still in place after the migration has finished.
Again, permissions assigned to groups or other objects outside the scope of AzureAD connect, will not function. The SIDs however are still in place, so adding a an object in scope of AADC, should re-enable the permission.
Besides permissions completely missing from a mailbox, I’ve also seen permissions being changed during the migration, specially on calenders. Most of the times, the permissions ended up to be more strict.
Another thing to keep in mind is the actual usage of folder permissions in a hybrid setup.
Again the calendar permissions are the ones that need some comment.
Permissions assigned to the Default special user, remain intact. But read permissions granted to individuals, are limited to the default setting. For instance you might have granted Default the availability only level of read permissions and a colleague you granted the level of limited details. In that case, that particular colleague can only see you availability and not the limited details he is granted, as long as the colleagues mailbox is still located on-premises. As soon as his/her mailbox is migrated as well, the permissions functionality is restored.
The same applies to full details read permissions.
If you have granted someone with some for of write permissions, those will stay functionally intact during the migration, as long as the permissions were not effected by the permission disappearance covered before off course.
Forwarding
Forwarding settings on mailboxes also need attention during the migration.
You can enable forwarding in several ways on a mailbox. I’ll be focusing on the actual forward settings you have available on the mailbox object itself. Forwarding setup in rules or out of office settings, will continue to work.
There is a little difference in the way forward settings are made in Exchange Online.
In my migration script, I’ve included a section to check on the current forwarding setting and make the same setting active in Exchange Online.
The way forwarding works in AD, is defined using the attribute DeliverToMailboxAndForward .
The address used in forwarding, is defined in attribute ForwardingAddress
Microsoft made this one not easy to compare, as the forwarding address in Active Directory is recorded in the CanonicalName format.
You cannot use that format in setting the forwarding setting in Exchange Online, and you can neither use that format to directly resolve the corresponding AD object that the forwarding session.
So before being able to make any corrections, you first need to translate the old attribute contents to the distinguishedname format, as that can be derived from the Canonical name format. Than use that format to resolve the actual AD object, get the address of that object and then finally you are able to set the forwarding address.
I’ve used a Powershell function I found online to do the translation from canonical name to distinguishedname.
Retention policies
In Exchange On-premises and Online variants you can define retention policies.
Policy associations will not be kept during a migration. So even if you created the same policy settings with the same names, the policy associating of a migrated mailbox will break.
If you need to keep the policy association in place, you’ll need to set the required association again for those mailboxes.
MessageSizeLimits
Settings for MessageSizeLimits do survive the mailbox migration. Despite that, it still might require some attention.
In our migration case, the mailboxes originated from three former Exchange organizations back in the Exchange 2003 days. They did not use the same limitations on messagesize limits. During a period of several years, great variations existed in messagesize limited between servers, even inside the same organizations. In Exchange Online, a maximum message size can be defined of around 150 MB.
If you currently have messagesize limits in place that are more strict than in the past, you might have oversized items in your source mailboxes.
Depending on the actual maximum size of the messages in your mailbox and the current message size limits, you might need to increase the message size limits to allow for the migration of the source mailboxes with all content intact, or you might even run into the situation the you are forced to instruct users to remove certain large messages from their mailboxes, as they are larger than the maximum definable limit of just over 150 MB. That was the situation we ran into.
You can help your users a bit by creating some mailbox folder statistics export to identify the folder that contains the oversized item(s).
Mobile Device registration settings
The migration this article is based on, used MobileIron as a mobile device management solution.
To be able to associate the migrated mailbox with a different MobileIron Sentry server, we had to clear a specific user attribute for mobile device association: msExchMobileMailboxFlags
This is rather a simple solution to execute, simply clear the current value of this user attribute.
To be able to connect the user object to the MobileIron Sentry for Exchange Online users, we’ve used an AD group. This group is connected to the correct policy settings for Mobile Iron.
Included in the migration process, we’ve also switch the users from using the native mail app (this customer almost exclusively used iOS devices) to using the Outlook for iOS client.
As we needed a way to guarantee online managed devices are able to access a mailbox, we’ve also included a VPN requirement in the MobileIron policy, so every connection attempt originates from the company set of external IP addresses.
We’ve added an address filter on the ADFS setting, to only allow known public IP addresses to authenticate towards Exchange Online.
Journaling replacement
Using journaling in Exchange Online is limited compared to Exchange On-premises solutions. You can only use a limited number of journaling rules.
Our On-Premises setup of journaling consisted of a 1 to 1 relationship for usermailboxes and journal mailboxes. This setup makes it very easy to determine which journal mailbox to examine in case of an ediscovery case.
As this setup can not be used maintained, we’ve switched to using Litigation hold.
There is a difference in the way this works from a technical standpoint. For instance all data will continue to exist in the actual user mailbox, for the period specified in the hold period setting.
One advantage is it could also be used as a restore method.
A disadvantage is, the hold capacity is added to the mailbox size. Exchange Online mailboxes can be rather large, up to 100 GB at time of writing, but this does include the capacity used by Litigation hold, but the capacity reported to the user in Outlook does not include this.
You need to keep an eye on extreme mailbox sizes and enable archiving for the in a timely fashion.
Depending on the licensing you use in Exchange Online, the mailbox limit might be lower and archiving might not be an option. Change to a higher license level if capacity is might become an issue.
Another thing to keep in mind, hold settings are only applied to items when they are created in the mailbox. So a hold setting will only be associated with message that are send or received after the hold settings becomes active. Historic items will not be included.
This also means that when you need to change the hold policy, the previous policy setting will still be active for the items that were created/received under that policy. Removing someone from a litigation hold setting, will therefor keep all previously created items under that old hold setting. This is normally exactly what you want, but you need to keep this process in mind.
Reports
The final step I made in the migrations script, was to generate a report for each migrated mailbox. This consists of the mailbox settings in place before and after the migration, including all corrections that might have been made to the mailbox.
To be completed with more PowerShell code
Leo's blog 