Microsoft has announced that Cross-tenant user data migration is now generally available. What means User data and how the Identity will move between the organizations with the mailbox move?
Read the announcement here.
Let’s see what this solutions is about.
Table of Contents
Exchange
Some notes
Cross-tenant Exchange mailbox migrations are supported for tenants in hybrid or cloud only, or any combination of the two.
Users migrating must be present in the target tenant Exchange Online system as Mail-Users, marked with specific attributes to enable the cross-tenant moves.
Target side preparation
It will use App registration with application permissions for the migration.
And permissions have to be Consented by an Admin.
Read from my previous posts more on the consenting choices.
Microsoft is saying in the documentation to consent with an URL like this.
|
1 |
https://login.microsoftonline.com/sourcetenant.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com |
Then need some PowerShell to generate Organizational trust and Migration Endpoints.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# Enable customization if tenant is dehydrated $dehydrated=Get-OrganizationConfig | select isdehydrated if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization} $AppId = "[guid copied from the migrations app]" $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String "[this is your secret password you saved in the previous steps]" -AsPlainText -Force) New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant "sourcetenant.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppId # Create new or edit your existing organization relationship object to your source tenant. $sourceTenantId="[tenant id of your trusted partner, where the source mailboxes are]" $orgrels=Get-OrganizationRelationship $existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId} If ($null -ne $existingOrgRel) { Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound } If ($null -eq $existingOrgRel) { New-OrganizationRelationship "[name of the new organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId } |
Source side preparation
|
1 |
https://login.microsoftonline.com/sourcetenant.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com |
Then you will create and Organizational trust in the source side also.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# The tenant ID that you enter as the $sourceTenantId and $targetTenantId is the GUID and not the tenant domain name. $targetTenantId="[tenant id of your trusted partner, where the mailboxes are being moved to]" $appId="[application id of the mailbox migration app you consented to]" $scope="[name of the mail enabled security group that contains the list of users who are allowed to migrate]" $orgrels=Get-OrganizationRelationship $existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId} If ($null -ne $existingOrgRel) { Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope } If ($null -eq $existingOrgRel) { New-OrganizationRelationship "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope } |
Migration
First have to note that Microsoft is developing a feature called Cross-tenant Identity mapping.
Some of notes for it:
- By automatically configuring variables like
ExchangeGuid,ArchiveGuid, and all required X500 proxy addresses, Cross-Tenant Identity Mapping reduces the possibility of errors while configuring what may possibly be thousands of target objects for a migration. - Decreases the number of manual processes where an error could cause migrations to fail.
Identifies automatically the objects that must be migrated from the source organization to the target organization. - Creates a 1:1 mapping between a Mailbox User object in the source organization and a Mail Enabled User object that already exists in the target organization.
- Automates populating necessary properties from Mailbox User in the source organization to the target organization Mail Enabled User provides a list of objects that are ready for cross-tenant mailbox migration based on the
PrimarySmtpAddressvalue of the source organization users.
But for now it will have these constrains:
- ExchangeGUID must match or the migration won’t start.
- ArchiveGUID must also match.
- LegacyExchangeDN has to presented in X500:LegacyExchangeDN format inside user ProxyAddresses attribute.
- UserPrincipalName will be presented in the target tenant format.
- PrimarySmtpAddress will also be presented in the target tenant format.
- TargetAddress attribute will assigned the value of PrimarySmtpAddress if not populated.
- You cannot add ProxyAddress from the source tenant. As the Custom Domain will reside in the source and it can be added in one Azure AD tenant at the time.
You have to keep Recovered Items size under 30gb or to enable msExchELCMailboxFlags and automatically increase mailbox size to 100gb (see below the limits for mailboxes)
| Feature | Microsoft 365 Business Basic and Standard | Microsoft 365 Business Premium | Microsoft 365 Enterprise E3/E5 | Office 365 Enterprise E1 | Office 365 Enterprise E3/E5 | Office 365 Enterprise F3 |
| Storage quota for Recoverable Items folder in primary mailbox (not on hold) | 30 GB | 30 GB | 30 GB | 30 GB | 30 GB | 30 GB |
| Storage quota for Recoverable Items folder in primary mailbox (on hold) | 100 GB | 100 GB | 100 GB | 100 GB | 100 GB | 100 GB |
| Storage quota for Recoverable Items folder in archive mailbox (on hold) | 100 GB | 1.5 TB | 1.5 TB | 100 GB | 1.5 TB | 100 GB |
You can assign a license to the object in advance but keep in this in mind.
If the target MailUser was previously licensed for or had an ExchangeGuid that does not match the Source ExchangeGuid, you need to perform a cleanup of the cloud MEU. For these cloud MEUs, you can run
|
1 |
Set-User <identity> -PermanentlyClearPreviousMailboxInfo |
Here is some tips for the CSV that is needed for creating the batch. The most equivalent is Cross-forest enterprise move but you will discard to Target database as it will be automatically assigned when migration finishes.
You will create the migration batch with the following command.
|
1 |
New-MigrationBatch -Name Batchname -SourceEndpoint sourcenendpointname -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain targettenant.onmicrosoft.com |
And more information here.
OneDrive
Notes on OneDrive
- You have to remove CMK (Customer Managed Keys) from your OneDrive before migrating.
- For Enterprise Agreement customers, Cross Tenant User Data Migration is an add-on. Licenses for users are per migration (onetime fee)
- You have to pre-create users and assign a license to them.
Here is an excellent Learn documentation on how to do it, you can do it with the same CSV that you did the mailbox migration previously, just modify those headers.
- Anyone who clicks on a shared link to the old location after a OneDrive account has been converted will be forwarded to the new one, providing they still have access to the destination. Until the originating tenant is deprovisioned, the redirects are in place. Redirects can also be removed individually by the admin.
- If they were listed in the identity mapping file, users having access rights to OneDrive content will continue to be able to do so. More on the Identity mapping file https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-onedrive-migration-step5?view=o365-worldwide
More information here.
Tenant-to-tenant migration
Microsoft has release an PDF for seeing the possibilities this feature gives.
Closure
Excellent stuff, just excellent. This is a game changer for acquisitions and mergers. When you also remember that Tenant rename came generally available, you can really do wonders with this solution.
Of course there are still use cases for third-party migrations tools but this a real step forward.
Read my post when this was still in Public preview
And the public documentation on the feature.
RSS - Posts