Cross Tenant Personal Exchange Data Migration

-

 

Personal Data migration Exchange and OneDrive

In the previous chapters, it is stated: Teams make use of several M365 service. Especially for the personal side of Teams, Exchange and OneDrive are heavily involved.

Towards Teams migration, it is required, that ALL data is present in the target environment for Exchange Calendar and OneDrive (shared files).

 

Data Pre-Load

Data pre-load is much slow than you expected. This is the most important lesson learned.

While Exchange is faster than OneDrive, be aware of the time required for the data copying process.

Another important statement is: none of the existing solutions are SYNC solutions, data is only copied. Therefore, a co-existence and working parallel in both, source and target tenant can lead to data inconsistence. If data is changed in the target environment and in source, any delta sync will overwrite the target data, if source has a new change date. Same, if the target data is newer, changed source data will not be copied.

 

Throttling

All service in M365 are throttled !

Throttling limits are different across the tenants, smaller tenants have low limits than larger tenants.

For Exchange, throttling can be lifted upon certain stage. This must be requested via the support center in M365. But it is NOT removed.


Conclusion

Plan enough time for data migration. Test the speed between the production tenants. Be aware, that the migration slows down over time. If you are close to completion, the migration speed will be slower than the former average.

Speeding up the migration can only be archived by the following 2+1 solutions:

1.       Clean-up your environment. Delete and data not in use, or not required.

2.       Limit the amount of data required, e.g. do not copy version history, only data to certain date

3.       Use archiving/ backup solutions and store data anywhere else, e.g. Azure or on-premises.
Limiting the amount of data required to be copied.

 

There may be new tools in the future and it might get better and faster.

 

Co-existence DNS Domain issue

In the T2T migration, both tenant will have a co-existence phase. In each tenant DNS Names are registered and used for external service communication. This is from UPN login, Email (SMTP) and Teams SIP calls. A DNS name cannot be registered into two tenants at the same time. The Authority record will not allow this with M365.

There are solution, providing better user experience, but some service do not allow you working with both DNS names. Realtime solution, like Teams and data protection solution have no work-a-rounds.

For T2T migration you have two choices, either you apply the target DNS to all migrated users and service, while retire the source DNS domain. Second option is, migrating the source DNS domain into the target tenant during source tenant decommissioning.

1.       SMTP/ Email
Make use of an external cloud based SMTP redirect solution. This will allow an redirect of mail flow from source to target, keeping externally the same DNS domain in your emails send and received.

2.       Teams SIP/ Chat and Calls, Meetings
There is NOT possibility redirect or masking SIP flow with two DNS domains. Therefore, during user migration, a user migrated to the target tenant cannot have the source DNS SIP domain. You must use the existing DNS domain, or a temporary DNS domain.

3.       Data Protection (MIP/AIP)
MIP depends on an encryption key created in the source tenant, which is build based on the source DNS name. Therefore authentication/ de-/encryption is based on this.
Migrated content, not decrypted will only be accessible as long the source key exists. Therefore I suggest either migrating the key while you move the source DNS domain to the target tenant.
If the target DNS domain shall be used instead, you must de-crypt the data before copying and re-encrypt the data with the new MIP key in the target.

 

Another challenge are the shared services, like Teams Team/Channel or SPO and M365 groups service, as well as other service like Yammer, … There is no simple solution, providing access to a migrated user from target to source. Two possible solution you can think of:

1.       Keeping the user account in source active, while disabling the personal services if the user is migrated. The user must work in both tenants. This is complex situation for most of the users.

2.       Make us of Guest Access and provide for each user who is migrated a corresponding guest user access in the source tenant. This is at least a solution he could life with. But for the migration team, this is extremely complex and work intense.

The only way making a T2T less painful for users, is a proper Change & Adoptions approach. Key users, Champions and more would make a T2T migration more successful.

 

Cross-tenant Identity Mapping (preview) approach:

Cross-tenant mailbox migration - Microsoft 365 Enterprise

Cross-Tenant Identity Mapping is a feature that can be used during migrations from one Microsoft 365 organization to another (commonly referred to as a cross-tenant or tenant-2-tenant migration). It provides a secure method of establishing one-to-one object relationships across organization boundaries and automatically prepares the target objects for a successful migration.

With Cross-Tenant Identity Mapping, data remains within the Microsoft security boundary and is securely copied directly from the source organization to the target organization using specially configured Organization Relationships serving as a unidirectional trust.

This blog article is still designed for 3rd party tool usage and might be updated at a later stage.

 

Cross-tenant Mailbox migration approach:

Cross-tenant mailbox migration - Microsoft 365 Enterprise

Users migrating must be present in the target tenant Exchange Online system as MailUsers, marked with specific attributes to enable the cross-tenant moves. The system will fail moves for users that aren't properly set up in the target tenant.

When the moves are complete, the source user mailbox is converted to a MailUser and the targetAddress (shown as ExternalEmailAddress in Exchange) is stamped with the routing address to the destination tenant. This process leaves the legacy MailUser in the source tenant and allows for coexistence and mail routing. When business processes allow, the source tenant may remove the source MailUser or convert them to a mail contact.

Cross-tenant Exchange mailbox migrations are supported for tenants in hybrid or cloud only, or any combination of the two.

Cross Tenant User Data Migration is available as an add-on to the following Microsoft 365 subscription plans for Enterprise Agreement customers. User licenses are per migration (onetime fee). Please contact your Microsoft account team for details.

Microsoft 365 Business Basic/Business Standard/Business Premium/F1/F3/E3/A3/E5/A5; Office 365 F3/E1/A1/E3/A3/E5/A5; Exchange Online; SharePoint Online; OneDrive for Business.

 

This blog article is still designed for 3rd party tool usage and might be updated at a later stage.

Ensure the cross-tenant license has been assigned to a user before cross-tenant migration.



Comments

Post a Comment

Popular posts from this blog

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

-
Image
Lync Edge Server FQDN and IP PORTS (Version 1.2, Update 26.11.2014) As we all know, we can configure Lync Edge Server in several way. 1) Single Edge Server with a SINGLE IP ADDRESS 2) Single Edge Server with MULTIPLE IP ADDRESSES (3x IPs) 3) Multiple Edge Server in a Pool, with MULTIPLE IP ADDRESSES (Zx 3 IPs) Regardless what we are going to configure, there are common / well-known TCP Port necessary making Lync work, which are: Access: Port: 443 and 5061 Conferencing: Port: 443 and (444) AV: Port: 443 (I have not listed other ports, e.g. STUN or the dynamic port range. This is not required for the topic discussed here) External FQDN with single IP address: What can we see here? If we are going to choose a single IP address, we would have TCP Port overlapping. Therefore the only way avoiding this is assigning other ports. Additionally we will also see and are reminded that Lync highly depends on DNS. If we have single IP, we must have use single, unique FQDN fo
Read more

MFA with Guest Access and different tenants settings

-
Image
There is an update regarding MFA Multi Factor Authentication. If you are guest with a different Tenant, the MFA Settings are now reflecting the settings of all tenants in a different way. Each MFA setting is reflected and you can setup your MFA device as per tenant and the admin settings allow. Login to your Profile in Office 365/ Azure AD: https://account.activedirectory.windowsazure.com/r/#/profile or https://myapps.microsoft.com Go to your PROFILE: Sign in to https://myapps.microsoft.com Select your account name in the top right, then select profile. Select Additional security verification. If might be happen, your admin hast configured MFA, so you wouldn't see this menu. Simply switch the tenant to the guest tenant where you need to configure MFA. Once you go back to your profile and you will find the MFA device and other settings a usual:
Read more

Skype for Business, Lync and Exchange Web Services (EWS) and different DNS Domains- Exchange crawling e.g. for presence

-
Image
Hi all, (This is an updated version 2.2: 09 .07.201 5 ) This blog entry is valid for Lync 2010, Lync 2013 and Skype for Business Server. Generally, I'll write a new blog article, since the conversion history over multiple device and other service have change with Skype for Business 2015 Server. Once this written, I post the link here. there is always confusion in how Lync is crawling Exchange Web Services (EWS). Generally it is necessary to understand how DNS must be implemented: Just remember, identify if you have DNS Split configuration, different internal and external DNS names and what are your SMTP and SIP Domains. Very often you find in Lync/ Exchange deployments an issue, where the Lync configuration show up with empty: EWS Internal URL EWS External URL and EWS Information = EWS not deployed Therefor Exchange Web Service are not connected deployed and several Lync Integration Features are not working, e.g. Presence Information based on your Outlook Calendar.
Read more