Category: Tenant to Tenant Migration

Do mailbox permissions (like FullAccess, SendAs and folder permissions) migrate during a tenant to tenant mailbox migration?

AI generated image that vaguely shows permissions being reapplied to a migrated mailbox

Yes!

…

…

Okay, there’s a bit more to it than that.

According to Microsoft’s documentation, you can expect permissions applied to a mailbox to migrate when you use the Microsoft’s MRS-based tenant to tenant migration service. As mentioned in the title, this includes FullAccess permissions, SendAs and folder permissions. Notably, Send on Behalf permissions are not migrated.

During the preparation steps you need to do for a T2T migration, you set the ExchangeGuid on the target MailUser to the same value as the source mailbox ExchangeGuid. You also take the source mailbox LegacyExchangeDN and stamp this on the target MailUser as an X500 address. This is not only used to correctly map the source and target objects, but it is also used to allow permissions to be reapplied when a mailbox is migrated.

During the mailbox migration, the migration service records who had delegate rights to the mailbox in the source tenant, maps those identities to their target tenant counterparts, and then reapplies those permissions onto the mailbox during the finalising stage of the migration. A key thing to note here is that permissions can only be reapplied if the delegate has also already been migrated (or a MailUser already exists with the ExchangeGuid and LegacyExchangeDN-as-X500 set) so that the migration service knows who to reapply permissions to. The process that reapplies the permissions only runs once at the end of the migration, so if someone who was a delegate on the source mailbox does not yet exists in the target, they will not get their delegate access reapplied even if they migrate later.

So, if you migrate a mailbox that has access permissions applied to it (most commonly shared mailboxes but this does apply to any kind of mailbox) you should already have the users of that mailbox migrated or at least have the MailUsers created with the correct properties set in preparation for a migration in the future. That way their delegate access to the mailbox will be set, and when the users migrate later their access to the mailbox is preserved.

Errors you might encounter when starting a Cross-tenant OneDrive migration

AI generated image of a frustrated user trying to copy files in their computer

A fairly new service from Microsoft, the Cross-tenant OneDrive migration allows you to migrate a users OneDrive from one tenant to another. If you wish to use this service, you need a Cross-Tenant User Content Migration license that is available for purchase to Enterprise Agreement customers.

If you have followed Microsoft’s guide to setting it up, you know the first step in the process is to create a mapping that maps the source tenant user to the target tenant user. After that, you can start the migration by running:

Start-SPOCrossTenantUserContentMove -SourceUserPrincipalName example@sourcetenant.com -TargetUserPrincipalName example@targettenant.com -TargetCrossTenantHostUrl “https://targettenant-my.sharepoint.com/“

Hopefully when you run this command it works without any issues! However, there are a few errors that you might encounter. Here is a list of errors that I have encountered and how to resolve them:

Error -161
This means that the LockState of the users OneDrive site is set to ReadOnly. This is most likely something that an administrator set on the Users OneDrive for one reason or another. You can resolve this by setting the users OneDrive site back to Unlock and starting the OneDrive migration again.

Error -102
This means that the LockState of the users OneDrive site is set to NoAccess. This happens if the user had a OneDrive site provisioned at some point, but since then has lost the right to access it. The most probable cause for this is the user once had a license that enabled them to have a OneDrive but was then moved to a license that does include OneDrive. You can resolve this by reallocating a license to the user that includes a OneDrive (SharePoint Plan 1 or Plan 2) and starting the OneDrive migration again.

The Cross-Tenant content move feature is not enabled for this tenant
Assuming you have correctly set up the trust between the two tenants, this error occurs when you have not applied a Cross Tenant User Data Migration license to the user. This can be applied to either the source or the target user, so apply one and wait a short amount of time, then start the OneDrive migration again.

OneDrive site for source user UPN example@sourcetenant.com does not exist
This means the user does not have a OneDrive provisioned.

Identity map entry for source UPN example@sourcetenant.com does not exist on the target tenant
This means that no mapping exists for this user on the target tenant. Create a mapping for this user and then start the migration again.

The identity map entry for source UPN example@sourcetenant.com does not correspond with the requested target UPN example@targettenant.com
This means that the mapping you created is incorrect. Perhaps the Source user UPN or the target user UPN was wrong. You should try recreating the mapping, or check the existing mapping, and start the OneDrive migration again when you have fixed the mapping.

The remote server returned an error: (429)
This means that your SharePoint tenant is currently being throttled due to your usage limits being exceeded. You can read more about that here, but in the end, this means you just have to try starting the migration again a bit later.

Additionally, there is one other error I have met that does not immediately throw an error but does cause the MoveState to move to Failed (usually after several hours). This is an unusual case where a user is using more space in their OneDrive than their license allows. For example, someone with a Microsoft 365 F1 license assigned which only allows 2 GB of storage in OneDrive, but with more than 2 GB of used storage (which you can check in Microsoft admin center). I expect this happens if a user originally had a license that allows more storage (such as a Microsoft 365 E3 which allows 1 TB of OneDrive storage) but was then downgraded. This situation causes the migration service some confusion as it tries and retries several times before failing.

The solution is to simply apply a license that allows more OneDrive storage and then start the migration again.