For a few years now, Microsoft has provided pretty much the same types of migration for organizations to use to migrate email data to Exchange Online in Office 365 from on-premises messaging systems, be that Exchange or not. Additionally, end users themselves can also import their own email, contacts, and other mailbox information to an Office 365 mailbox created for them, but that’s typically only used in very small migrations. Part of the migration process, excluding some third-party migrations, is the configuration and use of one or more Exchange Online migration endpoints. These are simply a connector from Office 365 to the on-premises email system, and that’s what this article focuses on. But before exploring these endpoints in more detail, let’s have a quick recap of the available migration methods provided by Microsoft.
Office 365 supports several methods to migrate email, calendar, and contact data from an existing messaging environment to Office 365. Since a migration endpoint is used in all these migration methods, it is important to understand them. Due to the huge number of articles already on the Internet regarding migration methods, and because this is not the main focus of this article, the following is just a high-level overview.
Internet Message Access Protocol (IMAP) migration
For environments running Exchange 2000 or earlier (I really hope there are none out there by now!), or for non-Microsoft email systems such as Gmail or Yahoo Mail, we can use IMAP to migrate data into Office 365 mailboxes.
This type of migration is called a cutover Exchange migration because all on-premises mailboxes are migrated to Exchange Online in a single migration batch. Using a cutover migration, administrators migrate all on-premises mailboxes to Exchange Online over a few days, depending on the volume of data. A cutover migration is used when we plan to move the entire email organization to Office 365 and manage user accounts from there. We can migrate a maximum of 2,000 mailboxes from our on-premises Exchange organization, but the recommended number is 150 as performance suffers with numbers higher than this. These numbers don’t mean that organizations with less than 2,000 mailboxes must choose a cutover migration. If an organization wants to migrate their users in smaller batches instead of one big batch, then a cutover migration would not be suitable.
A staged migration is used when we plan to eventually migrate all mailboxes to Office 365. Using a staged migration, we migrate batches of on-premises mailboxes to Office 365 over the course of a few days, weeks, or months. For this migration, we must synchronize accounts between the on-premises Active Directory (AD) and Office 365 by using Azure AD Connect.
A hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Exchange organization to the cloud. It provides the seamless look and feel of a single Exchange organization between an on-premises Exchange and Office 365. In addition, a hybrid deployment can serve as an intermediate step to moving completely to Office 365. As with a staged migration, we must synchronize accounts between the on-premises AD and Office 365.
A full hybrid is a common configuration for large organizations that will take some time to migrate completely or organizations that will not be able to move all their mailboxes to Exchange Online in the short to medium term. This is the most complex option to configure, but it gives organizations enhanced features like cross-premises free/busy and enhanced mail-flow options. Recently, Microsoft introduced two new flavors of hybrid:
There are many tools available from third parties, each using different protocols and approaches, to conduct email migrations from email platforms like IBM Lotus Notes, Novell GroupWise, or even Exchange, to Office 365.
Office 365 Import Service
Although not relevant for this article as it does not use a migration endpoint, organizations with many large PST files can also use the Office 365 Import Service to migrate email data to Office 365 by either uploading PST files through the network, or by mailing the PST files in a drive to Microsoft.
The table below summarizes the migration methods available for each source system:
|Exchange 2000 or earlier||X|
|Other email systems||X|
What do all of these migration methods have in common? A migration endpoint. To move the data itself, Office 365 needs to connect and communicate with the source email system on-premises. To do this, Office 365 uses a migration endpoint: a management object in Exchange Online that contains the connection settings and administrator credentials for the source server that hosts the mailboxes that we want to migrate to Exchange Online.
For certain migration types such as a cutover or staged migration, the migration endpoint also defines the number of mailboxes to synchronize and migrate.
Before starting the migration, we must enable the MRSproxy on our CAS servers, as this endpoint is responsible for accepting the requests for remote moves and to proxy them to the servers that are running Mailbox Replication Service. This service is responsible for cross-forest mailbox moves and remote move migrations between on-premises Exchange organization and Exchange Online:
The ability of a Client Access server to accept these MRS requests is disabled by default. To allow the Client Access server to accept incoming move requests, we must enable the MRS Proxy endpoint. The following command enables the MRS Proxy endpoint on a Client Access server named EXCH-01:
Set-WebServicesVirtualDirectory “EXCH-01\EWS (Default Web Site)” -MRSProxyEnabled $True
The following command enables the MRS Proxy endpoint on all Client Access servers in the organization:
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $True
To verify that we’ve successfully enabled the MRS Proxy endpoint, run the following command and verify that the MRSProxyEnabled parameter is set to True:
Get-WebServicesVirtualDirectory | Select Identity, MRSProxyEnabled
Before proceeding, it is recommended to use the Test-MRSHealth cmdlet to test the health of an instance of the Exchange Mailbox Replication service. This needs to be run on the on-premises Exchange server that we want to test.
It is also recommended to test the connection settings to the server that hosts the mailboxes that we want to migrate. The connection settings will be tested when we create a migration endpoint, but verifying these before creating an endpoint will give us an opportunity to troubleshoot any issues beforehand. The best way to verify that the MRS Proxy endpoint is enabled and working is to use the Test-MigrationServerAvailability cmdlet from Office 365 side to test the ability to communicate with the remote server that hosts the mailboxes that we want to move.
For IMAP migrations, the following command verifies the connection to the IMAP mail server imap.techgenix.com:
Test-MigrationServerAvailability -Imap -RemoteServer imap.techgenix.com -Port 143
The next example uses the ExchangeOutlookAnywhere parameter to verify the connection to an on-premises Exchange server in preparation for a cutover or staged migration. The EmailAddress is the email address of one of the mailboxes that we want to move; the Autodiscover parameter specifies that the cmdlet should use the Autodiscover service to obtain the connection settings for the target server; and Credentials specifies the logon credentials for an account that can access that particular mailbox on the target server:
$Credentials = Get-Credential Test-MigrationServerAvailability -ExchangeOutlookAnywhere -Autodiscover -EmailAddress firstname.lastname@example.org -Credentials $Credentials
The following example tests the connection to a server in the techgenix.com forest. The ExchangeRemoteMove parameter specifies that we plan to perform a cross-forest move or migrate mailboxes between an on-premises Exchange organization and Exchange Online in a hybrid deployment.
$Credentials = Get-Credential Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress email@example.com -Credentials $Credentials
One final test is to browse to the MRSproxy external URL, which can help confirm that the MRS proxy URL is reachable from outside the network. Since MRSproxy endpoint runs under Exchange Web Services, it is expected that all the MRS requests will be encapsulated in EWS calls, so the URL should have this format: https://mail.techgenix.com/ews/mrsproxy.svc, where mail.techgenix.com is the external URL for the EWS service.
If MRSproxy service is accessible from outside the network, we should receive a credential prompt. If we don’t, this indicates that the EWS service is not accessible externally.
There are several factors that can prevent the incoming MRS calls from reaching the destination server, the most common being firewalls. As such, ensure that your firewall allows incoming connections on URLs containing /ews/mrsproxy.svc on port 443. If you are using IP filtering, make sure you have the updated Exchange Online IP list in the firewall configuration. Finally, note that if your firewall requires pre-authentication or you are using a solution that performs SSL offloading in front of CAS servers, these configurations are not supported in remote moves scenarios; this is because the on-premises MRS expects to receive the incoming traffic over port 443 with SSL encryption and it refuses the connection if these conditions are not met.
If you are certain that the firewall is not the problem, you can check further if the incoming MRS calls have reached out to their correct destination by checking the IIS logs on the CAS servers. When running Exchange 2013/2016, and if you see the MRS requests on the IIS logs from CAS servers but are not sure about where the issue might be, you can extract more information from the HTTP proxy logs for EWS located at C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ews, as well as from the HTTP error logs located at C:\Windows\System32\LogFiles\HTTPERR.
When we manage to successfully run the hybrid wizard, one would expect to have the same success when creating the migration endpoint. This is a wrong expectation because, in some cases, firewall configuration (URL filtering or IP restriction), might cause the endpoint creation to fail.
If for any reason we need to manually create a migration endpoint, this can easily be done both through the Exchange Admin Center GUI:
And obviously through PowerShell, which this article focuses on, using the New-MigrationEndpoint cmdlet. The following example creates an endpoint for remote moves by using the Autodiscover parameter to detect the required settings:
$Credentials = Get-Credential New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint -Autodiscover –EmailAddress firstname.lastname@example.org -Credentials $Credentials
IMPORTANT: This on-premises user account that you use to connect to your on-premises Exchange organization during the migration (called the migration administrator) must have the necessary permissions to access and, in some cases, modify the on-premises mailboxes that you want to migrate. To successfully create a migration endpoint (or create a migration batch if no migration endpoints exist in your Exchange Online organization), the migration administrator must have the necessary administrative privileges in your on-premises Exchange organization. For example, for a remote move migration in Exchange hybrid deployments, the migration administrator account must be one of the following: 1) a member of the Domain Admins group in the on-premises AD, 2) a member of the Exchange Recipients Administrators group in the on-premises AD, or 3) a member of the Organization Management or Recipient Management group in Exchange 2010/2013/2016.
Please note that if the account specified expires, or if you change its password without updating the endpoint, any migrations will fail as the endpoint is unable to use those credentials.
Alternatively, we can manually specify the FQDN of the server(s) we want to use (this is extremely useful in a globally dispersed environment to ensure that mailboxes are migrated through a local server closer to them):
$Credentials = Get-Credential New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint_Europe - RemoteServer europe.mail.techgenix.com –EmailAddress email@example.com -Credentials $Credentials
In this case, when moving mailboxes using New-MigrationBatch we can use the SourceEndpoint parameter to specify the endpoint we just created.
Note: At the moment of writing this article, the Express Hybrid Migration only supports one migration endpoint. If there is more than one endpoint, Office 365 will choose the one created by the hybrid wizard.
To verify that we have successfully created the migration endpoint, we run:
Get-MigrationEndpoint OnpremEndpoint_Europe | FL
The Get-MigrationEndpoint cmdlet has a parameter named Type that we can use to filter the results returned by the cmdlet by the type of migration endpoint. This is useful when we have multiple endpoints created. The most common valid values for this parameter, and the ones most relevant for this article, are:
Once a migration endpoint has been created, it is easy to update its settings using the Set-MigrationEndpoint cmdlet:
Set-MigrationEndpoint OnpremEndpoint_Europe -MaxConcurrentMigrations 30 -RemoteServer europe.mail.techgenix.com
In this example, we used the MaxConcurrentMigrations parameter to specify the maximum number of mailboxes that will be migrated for this endpoint at a specified time. This parameter is applicable for all migration types.
Exchange Online migration endpoints are a vital component for any Office 365 migration. They allow Office 365 to communicate with an on-premises Exchange environment in order to extract and migrate the data. Before creating a migration point, or let the wizard create one for you, it is important to enable the MRSproxy, ensure it works without any errors, and confirm that from Office 365 you can with the MRSproxy external URL.
Once all of this has been set up, you are ready to migrate your data!
Here’s a script designed to start and stop virtual machines based on tags associated at the resource group level. It…
Traditional VPNs are showing their age in the modern cloud-powered workplace. That’s why software-defined perimeter solutions are in your future.
Should you disallow NUMA spanning in your Hyper-V architecture? There are two sides to this story, and you’ll get both…
Coding may not be the No. 1 job duty for cloud admins, but it is often a part of the…
Believe it or not, Hyper-V virtual machines can be configured to use a dedicated physical hard disk, which is referred…