In this blog post we will discuss hybrid migration endpoints in both Classic and Modern hybrid topologies, explain what migration endpoints are and how you can find them. In Part 2 of this post (now available) we cover troubleshooting of any related issues.
A migration endpoint in Exchange Online represents the source connection information for all our supported migration types: Remote Moves, Cutover, Staged, IMAP, and G Suite. A Hybrid Migration endpoint is a term used interchangeably with Remote Move endpoint when referring to the source on-premises environment for Hybrid migrations to Exchange Online.
As you probably know, there are 2 flavors of hybrid configurations:
To choose one vs. the other, when running the Hybrid Configuration Wizard (HCW), you would choose one of the appropriate options when running the HCW:
We won’t go into details about MRS here, but here are some references for you to read if you are interested to read more:
- Moving mailboxes, Exchange 2010 way
- Enable the MRS Proxy endpoint for remote moves
- Move mailboxes between on-premises and Exchange Online organizations in hybrid deployments
One of the greatest benefits of MRS-based moves is that we don’t need to recreate Outlook profiles and re-download the OST after migration, because we keep the same ExchangeGuid and mailbox signature of the mailbox when it is moved. With hybrid remote moves, we migrate all the data that is contained in the mailbox and we cannot skip any data (like dumpster or junk folder).
When moving mailboxes through migration batches, another service called Migration Service is also involved. It is an orchestration engine on top of MRS. Migration Service does not have an independent service running on the server, it is a part of Microsoft Exchange Service Host. This is present in Exchange Online and on-premises Exchange 2013/2016/2019 servers. Migration Service runs cmdlets like New-MoveRequest (hybrid migrations), New-SyncRequest (IMAP migrations), New-MergeRequest (Outlook Anywhere migrations) and is managed using “migration” commands like New-MigrationBatch, New-MigrationUser, New-MigrationEndpoint etc.
More specifically, when you start a migration through batches, the Migration Service will:
- Create the batch of users as per your inputs: the name of the migration batch, which users are to be migrated in a batch based on CSV file or selecting them from People Picker in the GUI, settings like bad and large items limit, settings for manual or automatic startup / completion of the batch.
In the background, the cmdlet New-MigrationBatch <name of the migration batch> will create the batch containing the user identities to be migrated in that batch, ex: john@contoso.com, jane@contoso.com. This will create new migration user objects for each user identity from the migration batch that you can retrieve later with Get-MigrationUser and Get-MigrationUserStatistics cmdlets.
As a note, hybrid migrations are the only ones where migration batches can be completed (Complete-MigrationBatch). Also, with Cutover migrations, you can have only one batch (this will take all your on-premises Exchange recipients present in the GAL). For the rest of our native migrations, there is a 100 batches limit.
- Create the migration endpoint if it does not exist already, for example: New-MigrationEndpoint -Name “Hybrid Exchange” -ExchangeRemoteMove
On migration endpoints, you will choose settings like using Autodiscover or not, on-premises admin credentials, max concurrent migrations. - Invoke cmdlets specific for the migration type chosen (Hybrid, Cutover, Staged, IMAP/GSuite), example New-MoveRequest john@contoso.com -Remote for a Hybrid Migration (Exchange Remote Move).
Below is a simplified image of what migration service in Exchange Online does when you start a migration:
Knowing this background processes will help you troubleshoot your migrations more efficiently, see exactly where are you stuck at with your migration: if for example you see that a migration user is created in a hybrid migration but a corresponding move request is not created, then you could just try to inject the move request by yourself and see if it gives the same error message (bypassing the Migration Service as a troubleshooting step).
Additionally, if you are not able to do migrations anymore via an existing migration endpoint (supposing the credentials of a particular admin for that endpoint expired) , you could directly inject the move request in Exchange Online PowerShell and inputting valid admin credentials to start the migration until you update that endpoint / create a new one.
Example of a cmdlet that will directly inject the onboarding move request in Exchange Online PowerShell, bypassing the migration endpoint settings or the Migration Service itself:
New-MoveRequest -Identity john@contoso.com -Remote -RemoteHostName <External EWS URL or Hybrid Agent> -TargetDeliveryDomain <YourTenantInitialDomain>.mail.onmicrosoft.com -RemoteCredential (Get-Credential domain\admin)
When initiating a move request like this, you won’t have a migration user object created for it, as the Migration Service / migration batches were not used.
So, depending on how the migration was initiated – through migration batches or not - you will see these objects created by default by the Migration Service and you can run get-* commands to see what has been created in your environment during a migration: Get-Migration* commands results are available when migrations were initiated through migration batches / Migration Service and Get-MoveRequest command results would be available if for example you started a hybrid move directly from PowerShell with New-MoveRequest but also if you started migration via batches and the Migration Service successfully created the move request (see below image).
Hybrid migrations (as well as the other native migrations) are always initiated from O365 Exchange Online side in both onboarding (migrate to Exchange Online) and offboarding (migrate from Exchange Online). However, offboarding request back to on-premises Exchange are only natively possible with Hybrid Migrations. These can be performed using migration batches or through separate move requests in PowerShell. The most common way is by using migration batches, typically from GUI.
Now that you have an idea on the migration components involved, let us show you how we check the migration endpoints in Exchange Admin Center (EAC) and PowerShell.
Locate migration endpoints in EAC:
Get-MigrationEndpoint
Get-MigrationEndpoint | FL
Get-MigrationEndpoint -DiagnosticInfo verbose | FL
I wanted to thank Brad Hughes, Nino Bilic and Greg Taylor for their review of this post.