Mail migration to Office 365 | Optimizing the Mail Migration throughput | Part 3/4

In this article, we review the recommendation and “best practices” that can help us to improve and optimize the results of the “moving our mail infrastructure to the cloud” project.

Mail migration to Office 365 | Optimizing the Mail Migration throughput | The article series

The article series includes the following articles:

1. Mail migration to Office 365 | Mail Migration methods
2. Mail migration to Office 365 | Factors that impact mail Migration performance
3. Mail migration to Office 365 | Optimizing the Mail Migration throughput (this article)
4. Mail Migration to Office 365 | Measure and estimate Mail Migration throughputs

Mail migration to Office 365 timeline

Generally speaking, there are two factors that we can measure:

1. The mail migration throughput – the time it takes to transfer a specific amount of data to the cloud (Exchange Online)
2. The amount of time required for completion of the mail migration*

*For example, in case the management instructs us to migrate all the organization’s mail infrastructure to the cloud in a period of no more than 10 days, can we accomplish this task?

In this article, we review some of the factors and the options available to us for improving and optimizing the results of the mail migration throughput or the time that we will need to accomplish the mail migration project.

Factors that impact mail migration throughput

In the following section, we will review some of the factors that impact the throughputs (transfer rate) of the mail migration and the options that are available for use to fine-tune or optimize these factors to improve the results of the mail migration throughputs.

Network infrastructure

1. Communication line bandwidth

The “speed” (The bandwidth) of the organizational communication line.

To be able to measure the performance of our communication line, we can use a web tool that is provided by the ISP or use public tools such as speedtest.

Using the results, we can get a better understanding of the available resources that we can use such as the Upload rate (when we are moving an organization mailbox to the cloud, we use the “upload channel), the download rate and so on.

Based on our results, we can decide if there is a need to increase the bandwidth of the existing communication line.

In case we want to get more detailed information about the load and performance of the communication line during the day, week, etc.

Most ISPs can provide this information (for free most of the time), by accessing a web interface that will display daily, weekly and monthly results of the communication line performance.

Personally, I like to use a product named PRTG that enables us to get a very clear and graphic view of the network performance.

2. Working hours and weekends

Office 365 native mail migration tools enable us to schedule the mail migration process. In case we want to avoid a scenario, in which the mail migration will “load” the organization communication line (and downgrade the network performance -the communication lines available bandwidth) or in case that we want to use all the available communication line bandwidth, we can consider scheduling the mail migration process to “non-working hours” or implementing the mail migration on the weekends.

3. Network devices performance and tuning

Firewall or Proxy load and performance

To be able to verify that the existing network device such as Firewall or Proxy, are not the cause for the “Bottleneck” or slowing the performance of the mail migration, the best practice is to implement a Pilot of mailbox migration and monitor the load performance of the Firewall/Proxy to verify that the server utilization is not high or causing the Firewall/Proxy to “reach their end limit.

Another important factor that can impact the performance of the mail migration is configuration settings that restrict the maximum value of the “allowed sessions.”

Firewall/Proxy | possible restriction of the maximum allowed sessions

Check the Firewall/Proxy server to verify that the migration process session is not blocked or restricted by the Firewall/Proxy policy.

4. Geographic location of the organization’s network

One of the factors that affect the mail migration throughput to Exchange Online is the “physical distance” between the organization network and the Office 365 data centers.

Technically, is not easy to measure or assess the quality of the communication path from point A (organization network) to the destination (Office 365 data center) but, the good news is that Microsoft provides a helpful Web-based tool named: Office 365 Network Analysis Tool, that can help us to get a detailed information about the performance of the communication channel between a particular organization network and the Office 365 data center that hosts the organization mailbox.

The Office 365 Network Analysis Tool is a Java-based tool and implemented as a web application.

To be able to get the required results we will need to choose the suitable URL for the Office 365 data center that hosts the organization mailbox, specify our Public domain name that registered with Office 365 and the tools will start to collect information and on the next step, display detailed results.

To use the Office 365 Network Analysis Tool, we first need to download and install the java client.

In case you try to use the tool and get the following error “application blocked by a security setting”, go to the control panel, look for the icon named: Java, and in the security tab, change the default settings to: medium

In the first screen, we will need to provide the domain name that is hosted in Office 365.

When the scanning process is completed, we can browse by selecting the different tabs to get detailed information about a specific section of the findings.

When choosing the speed tab, we can see a graph that includes information about the download and the upload speed.

When choosing the capacity tab, we can get more details about the download and upload performance.

5. Using a QoS (Quality of Service) product

Most of the time, the important question is not “what is the bandwidth of the communication line”? But instead, “what is the utilization of the communication line or what is the “free percentage’” of the communication line?

The process of mail migration considers demanding because, most of the time, we “transfer” a significant amount of data from the organization’s network to the cloud.

In case your organization uses a QoS product, the best practice is to allocate a predefined percentage of the network bandwidth for the task of the mail migration or prioritize communication that relates to the mail migration.

6. Plan for the required communication line bandwidth

When relating to the concept of “Plan for the required communication line bandwidth”, one major phase is the bandwidth that is required for the mail migration (the mailbox data that will be transferred from the Exchange on-Premises server to the cloud). Additionally, we will need to plan ahead for the required communication line bandwidth that is allocated to the communication between the organization users who access their Exchange Online mailboxes.

Exchange On-Premises infrastructure

1. Data source (Exchange Server) – Performance

The migration process is going to put a heavy load on the Exchange on-Premises servers who host the user’s mailboxes or in case that we use hybrid configuration of the Exchange on-Premises hybrid server.

Before we start the migration process, the best practice is to ensure that the existing Exchange on-Premises servers have the require resources (RAM, CPU, Storage, etc.) that will enable this server to perform in an optimal way.

Q: How can I know if the migration process is overwhelming the Exchange on-Premises server?

A: Start low as 10 and then increase this number while monitoring the data source performance to avoid end-user access issues.

In my opinion, the option of “upgrading existing Exchange on-Premises server hardware” is most relevant in case that the Exchange on-Premises server is based on a virtual machine because, in this scenario, the hardware upgrade process is a “one-click procedure.”

Hybrid migration | Server performance

In case you use a Hybrid server that will use as a “Router” for the mail migration process, the best practice is to use powerful server-class physical machines instead of virtual machines for the Exchange 2013 and 2010 hybrid servers.

2. Tuning the MRSProxy resource allocation

The MRSProxy is the Exchange server component that is responsible for implementing a mailbox move (in our scenario mailbox move from Exchange On-Premises server to Exchange Online).

The tasks that are executed by the MRSProxy are described as connections. The default value for the maximum number of connections is 100, but we have the ability to “tune” these values based on our needs.

Scenario 1: Exchange Server overwhelmed by the migration load. In case we find that the migration process impairs the performance of the Exchange on-Premises server, we can reduce the maximum number of connections that the MRSProxy will be able to use.

Scenario 2: In case the existing Exchange On-Premises server has sufficient hardware resources, and we want to expand more resources to the MRSProxy, we can increase the default number of connections that will be available for the MRSProxy and by doing so, an optimizer that mailbox migration transfer rate.

The PowerShell command that we can use is:

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>

3. Exchange On-Premises server throttling policy

In case you have an implementation of an Exchange on-Premises server throttling policy that could “slow down” or “downgrade” the performance of the mail migration process, consider stopping or disabling these settings while the mail migration is running.

4. Using Hybrid migration if possible

Using the option of Hybrid migration decreases the amount of data related to mail migration.

In the previous article Mail migration to Office 365 | Factors that impact Mail Migration throughput, we describe the difference that exists between Hybrid migration vs. stage migration and Cutover migration regarding the amount of data that is involved in the mail migration process.

Just a short recap: When using the option of Hybrid migration, we don’t have to configure a new Outlook mail profile, but instead, we can use the same Outlook mail profile and the existing OST file. By doing so, we avoid the need to “download back” the mailbox content to the user’s desktop.

I’m unfamiliar with each of the third-party mail migration tools that exist and if there are third-party mail migration tools that “know” how to use the local Outlook OST instead of downloading all the mailbox data at a new OST file.

Using the option of Hybrid migration minimum is based on the minimum requirements of Exchange 2010 SP3 on-Premises server. In a scenario in which the organization mail infrastructure based on older Exchange on-Premises server such as 2003, 2007, I would suggest you consider the option of installing a “temporary Exchange 2010 on-Premises server” for the mail migration project.

The Interesting fact is that you don’t even need to pay for a license. Microsoft enables an organization that wants to install Exchange 2010/2013/2016/2019 On-Premises server only as a hybrid server (without using the mailbox rule option) to get a free license for this server.

5. Exchange multiple site infrastructure

Mid and large organizations will usually have more than one Exchange site.

In case your organization uses more than one Exchange site (Multiple Exchange sites) and in the event that each of these Exchange sites has a “public presence” that enables to external hosts to connect the Exchange on-Premises server who “represent” the Exchange site, we can significantly improve the mail migration throughputs.

For example, in our scenario, we need to migrate 300 hundred mailboxes from the organization Exchange On-Premises servers to the cloud.

We have a very narrow time window for completing this task, and we would like to shorten or expedite the mail migration process.

In the following diagram, we can see that by using the concept of implementing a mail migration from multiple Exchange sites at the same time (parallel), we can multiply or triangle the amount of mailboxes that we can migrate at the same time.

6. Multiple Exchange site’s infrastructure and AutoDiscover

In a scenario of Multiple Exchange sites infrastructures, we can rely on the AutoDiscover service for implementing a mail migration from a multiple Exchange sites at the same time, based on the location of the user mailbox (the Exchange site and the Exchange server which hosts the user mailbox).

The pre-requirements is that each of the Exchange sites will have a public presence that includes “Public name” (URL) that can access from a public network.

To be able to understand this process better let’s use the following example:

An organization named: o365info has two Exchange sites. One site is located in New York, and the additional site is based in Los Angles.

• The Exchange mail server in the New York site uses the following public name:
  Mail.Ny-o365info.com
• The Exchange mail server in the Los Angles site uses the following public name:
  Mail.La-o365info.com

We are using the Hybrid migration option, and are creating a new migration batch based on a CSV file that includes a list of users who we want to migrate to the cloud (Exchange Online). The CSV users list includes a “mixture” of users from both organization sites.

In our example: User1 and User2 mailboxes are located in the New York site, and User3 and User4 mailboxes are located in the Los Angeles site.

In our scenario, the AutoDiscover record of o365info.com, is pointing to the additional Exchange server which is not located on the company site.

When we start the migration batch, Exchange Online uses the AutoDiscover service to get the required information about the mail infrastructure, etc.

In the following diagram, we can see that Exchange Online asks about the Exchange server (The CAS server) that can provide information and access to the mailbox data of User1@o365info.com.

The origination Exchange server provides an “answer” by redirecting the Exchange Online to additional server: Mail.Ny-o365info.com

In the second step, Exchange Online will try to connect to the Mail.Ny-o365info.com and “ask for a permission” to copy the mailbox data of User1.

Exchange Online creates a new migration endpoint using the connection settings that successfully discovered or that you provided manually. We recommend that you create migration endpoints whose connection settings were automatically discovered rather than creating endpoints whose settings you entered manually. This is because the Autodiscover service will be used to connect to each user mailbox during the migration.

If manual settings are used, Exchange Online won’t use the Autodiscover service, but will connect to a specific source server using the connection settings you manually entered. If you use manual settings and have multiple on-premises Exchange servers, you may need to create different migration endpoints that correspond to each server.

Office 365/Exchange Online factors

1. Office 365/Exchange Online Throttling policy

The Throttling policy that relates to mail migration is described as migration-service throttling. This policy was designed to limit the maximum migration concurrency.

The good news is that we can easily increase the default value and, by doing so, increase the number of mailboxes that can be migrated.

In my option, the default value of “maximum 20 mailboxes at the same time” was not created to protect the Exchange Online server performance because theoretically, there is no limitation to the resources that allocated to the Exchange Online server.

The attention was to protect the Exchange on-Premises server from a scenario of “overwhelming”. In case we put too much load on the Exchange on-Premises server, the load of the migration process could impact other Exchange on-Premises server services.

So, if you consider increasing the value of the migration-service throttling, please verify that your Exchange on-Premises server has the required resources for supporting the amount of mailboxes that migrated to Exchange Online.

After you create a migration batch, you can use the following Windows PowerShell command to increase this to a maximum of 100.

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

2. The maximum number of concurrent moves for a Migration Endpoints

There is a limit of 100 concurrent migrations for each type of migration endpoint. For example, your organization could have five Outlook Anywhere migration endpoints and each endpoint could be configured for 20 maximum concurrent migrations. Or you could have two IMAP migration endpoints, with each end point configured to support 50 maximum concurrent migrations.

In the following screenshot, you can see that when we try to use a value bigger than 100.

The result is the following error:

This endpoint would make the maximum concurrent migrations ‘101’, which would exceed the allowed limit of ‘100’ for endpoints of type ‘ExchangeRemoteMove’.

Just a friendly piece of advice: The fact that Office 365 enables us to “extend” the value of a concurrent mailbox move doesn’t mean that you should automatically use this option.

A high value of parallel mailbox moves can overload your network bandwidth and Exchange On-Premises servers.

The number of mailboxes to migrate field simultaneously specifies the number of connections to your on-premises mail server used during migration. The more connections you have to your on-premises mail server, the more mailboxes you can migrate at one time. While this reduces the amount of time it takes to migrate mailboxes, these additional connections can consume your Internet bandwidth, negatively affecting network performance and users’ ability to access Internet resources.

In the next article, we will look into Mail Migration to Office 365 | Measure and estimate Mail Migration throughputs.