Migrating mailboxes to Office 365 can be a long process, and migration speed may not meet your expectations. Even under the best conditions, mailbox migrations won't whizz through as fast as they theoretically could.
Based on Microsoft's tests, a single mailbox migrating to Office 365
If your migration speeds aren't approaching these speeds -- or if mailbox moves aren't completing -- you might have a problem. Let's look at how and why this happens, and what you can do to avoid these issues.
Determine the type of problem
To help you determine if network speeds are an issue, Microsoft provides tools based in different regions:
You'll need to run these tools from a machine that has Java installed, which is unlikely to be on Exchange Server but will still need to access the Internet via the same route that Office 365 accesses your Exchange Server.
If you don't see any problems when you perform network speed tests with Microsoft tools, the next step is to examine the move status and then move request logs within Exchange Online.
If you've submitted mailbox move requests as Migration Batches via the Exchange Administration Center, navigate to Recipients > Migration, select the Migration Batch and then choose View Details under the Mailbox Status heading (Figure 1).
Details for the migration batch should open if you choose View Details. These details could include a list of mailboxes or the status of the move. For each move, you can view the move report by selecting the user from the list and choosing Download the report for this user (Figure 2).
If mailboxes frequently pause with the status StalledDueToTransientError, that means you have a problem with moves in progress. If you're examining logs, look for errors that show that Exchange Online had intermittent issues connecting to a hybrid Exchange Server. They may be similar to these errors:
|Relinquishing job because the mailbox is locked. The job will attempt to continue again after <date time>|
|Transient error CommunicationErrorTransientException has occurred. The system will retry (1/60)|
|The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted.|
If you see errors like this, which are often repeated through log files, it's likely an issue on your Exchange infrastructure.
Common issues with firewalls and load balancers
If you use a firewall product on the edge of your network that sits between Exchange and Exchange Online, investigate the firewall to ensure there is no rate-limiting in effect, which causes issues.
If you're using Forefront TMG or ISA Server, this is likely an issue with the default configuration. You'll need to open the Forefront TMG console and navigate to Intrusion Prevention System. Within the Behavioral Intrusion Detection tab, select Configure Flood Mitigation Settings (Figure 3).
You'll find these same setting in ISA Server 2006 by navigating through Configuration > General, under Additional Security Policy. Navigate to the IP Exceptions tab and create a new computer set, which contains the full list of Exchange Online data center IP subnets (Figure 4). This list can also be found on this this Microsoft help site.
After adding this computer set to the list of IP exceptions, TMG (or ISA) should no longer be responsible for issues with multiple mailbox moves progressing. Even if you are not experiencing these issues, you should add these exceptions.
If you're using Forefront Unified Access Gateway 2010, you might need to avoid UAG for mailbox moves all together. While it features the same type of flood protection TMG uses, there's no supported method to exclude Exchange Online IP address ranges. In such circumstances, publish a secondary Exchange Server HTTPS namespace for mailbox moves (such as hybrid.contoso.com) and publish it seperately to avoid UAG.
Finally, if you use Exchange 2010 for your hybrid mailbox moves and use load balancing, affinity settings on your load balancer could cause issues. If the load balancer isn't configured for your Exchange Web Services HTTPS Virtual IP address, set it to a minimum of Source IP-based affinity. If it's not, the mailbox move will slow down because Exchange Online only occasionally connects to the right server. It may even fail all together after a long time-out.
What's going on inside Exchange?
Don't forget what's happening at both ends of the migration. If you were hoping to migrate 100 mailboxes concurrently but can't, remember that both Exchange Online and on-premises Exchange have limitations on the maximum number of concurrent migrations. There are also throttling policies to prevent you from causing performance issues for end users.
If you need to, increase the maximum number of allowed concurrent migrations for each mailbox database on-premises. However, this shouldn't be your first option. In Exchange Online, data lives in Mailbox Databases too, which are subject to the same type of limits. You have no control over these limits, and if you're migrating to the same target databases at the same time as other Office 365 customers, there's little you can do to increase your concurrent throughput.
If you're moving from Exchange 2007 or later, consider using migration batches to perform the initial mailbox synchronization in the background. During and after the initial sync, users can continue to normally use mailboxes while they migrate to Office 365. You can complete the migration batch when you're ready to switch, which will perform a final incremental sync and switch.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and Office 365 since its origins in Exchange Labs and Live@EDU.
This was first published in January 2014