Part 2: Speed up Migrations to Exchange Online
This is a multi-part article in which we will cover Migration Endpoints. First, we will cover what...
This is a multi-part article in which we will cover Migration Endpoints. First, we will cover what Migration Endpoints are, what you use them for and how you can manually configure a migration endpoint. In the second part of this article, we will dive deeper into how you can leverage multiple migration endpoints to potentially speed up your migration to Exchange Online. Lastly, we'll discuss some of the most common mistakes regarding Migration Endpoints and how to avoid or solve them.
One of the key benefits of a hybrid configuration is the near seamless operations between the on-premise Exchange environment and Exchange Online. One of the cornerstone capabilities that unlock this experience is the ability to move mailboxes from on-premise to Exchange online without much hassle like having to recreate a new Outlook profile. Especially since the situation around cross-premise premises permissions are getting better, being able to move mailboxes to and from Exchange Online is key.
As the name implies, Migration Endpoints are ingress points into your on-premises network through which data is moved to Office 365. Exchange Mailbox moves exists in two flavors: push and pull. However, a mailbox move to Office 365 is always a "pull"-type. This means that Exchange Online will make an inbound connection to your on-premises Exchange servers over the (pre-)defined migration endpoint(s). The endpoint Exchange Online uses, it the one you define/select when creating a new move request or migration batch.
By default, the Hybrid Configuration Wizard (HCW) will attempt to create a migration endpoint the first time it runs. This is great for (smaller?) organizations that just want to start migrating mailboxes right after they ran the HCW. In the real world things are a little different. Often, the HCW is ran weeks before the first mailbox is moved. And while I don't necessarily recommend leaving that much time in between, sometimes that's what you must work with.
Typically, a migration endpoint for Mailbox Replication Services (MRS)-based moves consists of the following information:
* Note: when the HCW runs, it will attempt to create a migration endpoint based on the Exchange Web Services (EWS) external URL and using the credentials of the logged in user (who is running the HCW). Often this account will have too many privileges in the on-premises organization. From a security perspective, it is better to create a service account which only has the required permissions. In this case: the account must be a member of the default "Recipient Management" role group. An important side note here is that granting the account only the "Recipient Management" role (through a Role Assignment) will not be sufficient. Confusing, I know. There is a role group named "Recipient Management" and similarly named role "Recipient Management". So, don't get confused!
As pointed out in the note above, the default migration endpoint (the one that gets created by the HCW), will be based on your EWS external URL. If you have published your Exchange Web Services externally, then this is likely how it's published to the Internet:
Graphic: default (logical) publishing topology
Because there are a lot of components at play, the migration performance also referred to as migration velocity can be influenced by a lot of things; some of which you might control, others not. For instance, between your on-premises organization and Exchange Online, there is the Internet. And while you can increase your bandwidth to/from the Internet, you don't always control how traffic is routed to/from Office 365 to your on-premises organization. This is also one of the reasons why Microsoft is putting so much effort in improving the network infrastructure and peering locations on their end. By doing so, they can greatly influence the perceived performance in Office 365. But we're digressing, now.
If you are using a single migration endpoint to move mailboxes to Office 365, the velocity will never exceed the maximum capacity of each link in the chain. In the above topology, that would be:
To minimize the impact of any of the above, consider doing all (or some) of the following:
In addition to these "external" factors, there are a few other things you can tweak to improve performance. On the migration endpoint itself, there are two values that can be changed:
The values for each migration endpoint can be modified using Exchange Online PowerShell and the Set-MigrationEndpoint cmdlet. Although you can create as many migration endpoints as you would like, you can only configure a maximum of 300 concurrent migrations over all the existing endpoints. This value can be retrieved using the Get-MigrationConfig cmdlet:
PS C:\> Get-MigrationConfig | fl
RunspaceId : b9953935-cd81-4ec7-a263-cc55879210f5
Identity : tenantname.onmicrosoft.com
MaxNumberOfBatches : 100
MaxConcurrentMigrations : 300
Features : MultiBatch, PAW
CanSubmitNewBatch : True
SupportsCutover : False
IsValid : True
ObjectState : Unchanged
Although 300 should be sufficient for most organizations, you can request support to raise this value to as much as 1000. Please note, however, that it is far more likely you will run into performance bottlenecks elsewhere before hitting the 1000 concurrent migration limit.
Slow migration performance is rarely caused by a lack of resources on Microsoft's end (though it happens). Most of the time, I see a lack of performance at the source side, like ill-performing Exchange Servers, badly configured networking devices etc. However, if your base infrastructure can handle the load and you're not getting the performance you wanted (or have guestimated), tweaking the endpoint and MRS settings might be a good starting point. In part two of this article, we'll investigate how you can scale out using multiple migration endpoints.
Michael Van Horenbeeck is a Microsoft Certified Solutions Master (MCSM) and Exchange Server MVP from Belgium, with a strong focus on Microsoft Exchange, Office 365, Active Directory, and a bit of Lync. Michael has been active in the industry for about 12 years and developed a love for Exchange back in 2000. He is a frequent blogger and a member of the Belgian Unified Communications User Group Pro-Exchange. Besides writing about technology, Michael is a regular contributor to The UC Architects podcast and speaker at various conferences around the world.