Demystify Exchange-mailbox migration
My very fist Microsoft Exchange version was V4.0 and my first Exchange Migration was from V4.0 to Microsoft Exchange 2000. It was very painful and complicated migration. There was no migration documentation or something like this and no MVP blogposts on the internet. You could just relay on your experience and knowledge of other colleagues. We needed to change credentials from every mailbox, export all emails to PST, import all PST files to the new Exchange-Server and configure Outlook manually on every computer for every employee. Since then, I am continuously migrating mailboxes to the next version of Microsoft Exchange. Since 1996 mailbox migration has been improved, but still very complex. In this article I will try to deep dive into several migration scenarios and explain Microsoft Exchange On-Prem migration to Microsoft Online.
Which mail migration exists and which are covered in this article?
Exchange to Exchange scenarios
How to get migration batch information?
Failed moverequests bulk removal
Bulk configuration of batchname for a bunch of moverequests
Bulk CompleteAfterDate configuration
How to get failure events from moverequests
The operation couldn’t be performed because matches multiple entries
Migration principals
Before I will start with deep dive in to Exchange-Mail migration, I would like to explain some terms and give you a “Start-Up” information, so that you can understand this article in full color range.
What is mail migration?
Mail-Migration is not only migration of email objects from Source to Destination, but also a change of communication and collaboration infrastructure for your company and have a big impact on productivity and business continuity. Any kind of migration may have an impact on:
- Mailbox access
- Mailbox permissions
- Mailflow and mailrelay
- Calender availability
- Distributiongroup- and Securitygroupmembership
- Resource and Sharedmailbox / Functionionalmailbox access
- Addressbook access and membership
- Permission delegation and collaboration
- Email security, like antispam / antiphishing, antivirus and email encryption (conditional access)
So, if you are planning an email migration, think about above mentioned points and how to deal with it.
Which mail migration exists and which are covered in this article?
In this article I will explain only Exchange to Exchange migration. So, I will not explain any 3rd party to Exchange-Migration, because there are tons of tools on the market like QUEST which you can use for it.
Exchange to Exchange scenarios.
Following migration scenarios are covered in this article.
In scenario A we have one Exchange-Organization and one data center. All Exchange Servers are in the same data center. You need to move mailboxes from Exchange-Server B to Exchange-Server A.
In scenario B we have one Exchange-Organization in two data centers. You need to move mailboxes from Exchange-Servers located in data center 1 to Exchange-Servers located in data center 2.
In scenario C we have one Exchange-Organization in two data centers. We are using load-balancers for better quality of service.
It doesn’t matter how many load-balancers do you have in each data center, architecture is almost the same.
You need to move mailboxes from Exchange-Servers located in data center 1 to Exchange-Servers located in data center 2.
In scenario D we have two Exchange-Organizations and two data centers. We have two different forests and need to move mailboxes from one forest to another. This type of migration is called “Forest to Forest” migration and requires additional preparation of target and source forests. Check documentation of this feature here. We will focus only on mailbox moves and not on “Forrest to Forrest” deployment.
In scenario E we have one data center and one Exchange-Organization. We have an Exchange-Hybrid configuration (doesn’t matter if Centralized mailflow, Hybrid-mailflow, or HMA). We are using separate “Exchange-Hybrid” servers only for Client-Access / Hybrid-Configuration-Wizard and have separate “Maibox Servers” which are hosting mailbox-databases in a DAG or without.
All user objects are synchronized via Azure-AD-Sync to AzureAD.
Important: We have only 1 data center, all “Exchange to Exchange” connections are running in the same LAN. You need to move mailboxes from Exchange Mailbox-Servers to Exchange Online.
This is the most complicated scenario which is used in enterprise environment with more than one data center “multiple sites”. We have two data centers and one Exchange-Organization. DC1 is our “Headquarter” and DC2 is our “Branch office”. Between both DCs is a “WAN” connection like MPLs, or VPN tunnel. DC2 has no internet connection, the whole traffic is routed through DC1 via “WAN” link. We have an Exchange-Hybrid configuration (doesn’t matter if Centralized mailflow, Hybrid-mailflow, or HMA). In DC1 we have “Exchange-Hybrid” servers located only for Client-Access / Hybrid-Configuration-Wizard and in DC2 our “Maibox Servers” which are hosting mailbox-databases in a DAG or without.
All user objects are synchronized via Azure-AD-Sync to AzureAD. AzureAD sync is located in DC1. You need to move mailboxes from Exchange Mailbox-Servers over “WAN” connection to Exchange Online.
If you have a scenario which is totally different, as mentioned above, just let me know, I would really appreciate to get more ideas and increase the quality of this article.
MRS proxy
It is a part of Exchange-WebServices and is responsible for Mail-Box migrations. This service is based on EWS (Exchange Webservices) and is handled in the same way as all other EWS features like “HMA”. You can find MRS proxy documentation here.
Important: Exchange-Server is proxying MRS traffic internal via port 444 and only initial Moverequestis using 443. Client/Access Server and Mailbox / Source Server need to have the same External URL configured in EWS.
Network configuration
MRS traffic can be used internal and external.
- External traffic means: if destination server is in a different forest or belongs to Exchange-Online (scenario D,E and F). In this case following ports are required to be opened on your external FW in DC1.
Pot
I
Port | IP | Explanation |
443 | Destination-Server-IP | Inbound HTTPS |
443 | Client / Access Server | Outbound HTTPS |