Very often I receive a question about migrating from one Exchange server to another at the same version of Exchange – or what I refer to as a “like for like” migration.
The common reasons for this type of migration are:
- Physical to virtual (P2V) migration (replacing a physical server with a virtual machine)
- Physical to physical (P2P) migration (replacement of physical hardware with new hardware, usually due to warranty expiring)
The ultimate goal is to migrate all of the data and services from server A to server B. In this article I’ll provide an overview of this process and some resources you can use to make it easier.
But first, some frequently asked questions:
Q: Can I P2V or clone my Exchange server?
A: Technically yes, but I don’t recommend it. If you don’t perform the task correctly you could harm your Exchange server or lose data. Even if you do perform it correctly, a migration to a new server provides you the opportunity to do a clean build.
Q: Can I keep the same Exchange server name/IP address?
A: No. Two servers can’t exist with the same server name or IP address at the same time. And you can’t rename an Exchange server, so rule that option out as well. The name of an Exchange server is largely irrelevant, as end users connect to the namespaces you configure for different services, not to the server’s real name. Yes you can change the Exchange server’s IP address later, but it’s just a simple to update DNS records and firewall rules to point to a new IP address.
Q: Can I just copy the whole database across instead of migrating mailboxes?
A: Technically yes, using database portability. But I don’t recommend it. Database portability is a recovery solution, not a migration solution. It will require a lengthy outage, and it carries the risk that some problem with the new server will impact all of your users at once. Better to do a small pilot migration first to test the new server’s stability, then migrate the rest of the mailboxes in manageable batches.
Scenario Overview
A simple like for like scenario involves a single Exchange server that is responsible for internal and external RPC/HTTPS clients, as well as internal and external SMTP services.
To plan the migration project we can break it down to several steps:
- Install the new Exchange server
- Configure the new Exchange server
- Client access (Outlook, OWA, mobile devices, etc)
- Transport (mail flow)
- Mailbox databases
- Migrate data and services to the new Exchange server
- Client access
- Transport services
- Mailboxes
- Decommission the old server
Installing the New Exchange Server
I’m going to assume that you’ve already designed your new server specifications and acquired the hardware, or provisioned the virtual resources, to build it. Whether you’re installing Exchange Server 2010, 2013 or 2016 doesn’t matter particularly much at this point. If you’re installing the same build (e.g, Exchange Server 2013 Cumulative Update 10) as your existing server then there should be no surprises of additional requirements such as schema updates.
For all versions of Exchange, when you’re introducing a new one into the environment, you need to be aware of the Autodiscover SCP that the new server will be registering in Active Directory, and be prepared to change that immediately to match the Autodiscover URL for the existing server. A more detailed explanation and example is in the following article, which applies equally to 2010, 2013, and 2016:
Make sure your operating system configuration is built to your normal standards and includes any extra considerations such as third party products, updates, backups, monitoring, antivirus, and so on.
Configure the New Exchange Server
In a like for like migration the goal is to configure the new server to match the existing server’s configuration for client access, transport, and mailbox services so that it can seamlessly perform the same role as the previous server.
Client Access
For Exchange Server 2013 and 2016 you should configure the client access namespaces to match the current server. You can read more about how and why to configure client access namespaces in the following articles:
- Avoiding Server Names in SSL Certificates for Exchange Server
- Exchange Server 2016 Client Access Namespace Configuration
Configuring the namespaces on a server can be performed quickly and easily using my ConfigureExchangeURLs.ps1 script.
For Exchange Server 2010 there is an additional consideration for the CAS Array (or RPCClientAccessServer). If there is already a CAS Array defined for the AD Site, then there should be no problems with this. If there is not a CAS Array defined for the site, then you may run into problems when you decommission the old server. To understand this issue more and learn what to do about it review the following articles:
- Outlook Clients Unable to Connect to Exchange After Client Access Role Moved
- Getting Started with Exchange Server 2010 Client Access Server Arrays
The new server will also need a matching SSL certificate. You can re-use the certificate from the existing server if it is still valid.
- Export/import SSL certificates for Exchange Server 2016
- Export/import SSL certificates for Exchange Server 2013
- Export an Exchange 2010 SSL certificate, and import it to another Exchange 2010 server
Transport
Transport refers to mail flow internally and externally for the organization. My personal preference is to pre-configure and test transport at this stage of the project, but not to cut over to the new server just yet. There are two things to consider at this stage.
Transport size limits should be configured on the new server to match the existing server. This means verifying that the receive connectors on the new server have the same message size limits.
In addition to size limits, if you have a relay connector on the old server then you should configure a matching relay connector on the new server:
You can test transport by using Telnet to send email via the new server. The tests I like to perform include:
- Telnet from old server to new server (you don’t need to send an email, but verifying that SMTP connectivity is successful is a good idea)
- Telnet from new server to old server (same as above)
- Telnet from a device on your network that should have SMTP relay access to the new server, and send a test email
- Telnet from the new server to a mail server on the internet and send a test email (or at least verify that outbound SMTP connectivity through your firewall is permitted)
Mailbox Databases
For the new server, create and configure your mailbox databases. Make sure you’ve got the database and log files located on the intended volumes, and that the mailbox quota settings match the existing server’s databases.
Make absolutely sure that the new databases are being backed up. And by that I mean don’t just add them to your backup job and hope for the best, actually verify the backup timestamps on the databases, and perform a test restore (you’ll need to place a test mailbox with some email items on the database first).
Migrate Data and Services to the New Exchange Server
I like to break down the migration into each individual service. Yes, you could do them all at once, or a mix of services at the same time, but I prefer to keep it simple and limit the amount of change in each step to make it easier to plan, and much easier to troubleshoot if something goes wrong.
Client Access
The client access cut over is primarily a DNS change. The client access namespaces (including the CAS Array namespace for Exchange 2010) are updated in DNS to point to the new server instead of the old server. As this is a high impact change there are a few things you can do to minimise the risks:
- Configure a low TTL value (1 minute is good for cut over periods) for the client access namespace records in DNS. This allows you to quickly roll back the change to the old server without clients’ DNS caches causing them to continue to try and connect to the new server for a long time.
- Use a hosts file to test the DNS change on one or a few clients first.
Internal DNS changes will take care of your internal clients, but external client connectivity also needs to be cut over. If the public IP address that your public DNS records resolve to is not changing then the cut over will be performed on your firewall or edge device that is NATing connections to Exchange.
Transport
The transport cut over is a combination of DNS changes, Exchange configuration changes, and firewall or smart host configuration changes. For internal devices and applications that are using Exchange as an SMTP service, update the DNS alias that they use to point to the new Exchange server. If you did not use a DNS alias and your devices and applications point to Exchange by the real server name or IP address, then you’ll need to manually update them all (I recommend you implement an alias to avoid that again in future).
For inbound internet email, the cut over may be performed in different ways:
- If the public IP address your MX records resolve to is not changing, then the cut over will be performed at the firewall or edge device that NATs SMTP traffic to Exchange, or it will be performed on the smart host that handles incoming email before routing it to Exchange.
- If your MX records are changing, review this article for some tips.
For outbound email the change is performed by updating the source transport server on your send connector to replace the old server with the new server. If you like you can leave both servers on the connector for a while, but that is up to you. If I’m going to decommissioning the old server I prefer to remove it now so that I have a predictable mail flow for any troubleshooting I need to do.
At this stage, while you’ve still got mailboxes on the old server, Exchange will automatically route email between the two servers as required. There’s no need to create additional connectors for that to occur.
Mailboxes
Finally, move the mailboxes to the new server. Move a small pilot group first just to iron out any last minute issues that might come up, and then proceed with the remainder of the migrations using manageable batch sizes.
Mailbox migrations in Exchange 2010, 2013 or 2016 occur online in a non-disruptive manner for the end users, except for the final cut over step. So you can manage the minor outage required for each batch so that it occurs out of business hours. Autodiscover should handle any Outlook profile updates that may need to occur as part of the move. Otherwise, as long as the client access configuration is all good then the migrations should be problem free.
The main issues with mailbox moves will be speed, and possible failed move requests. Speed is largely impacted by server performance. Exchange will throttle the migrations if the server workload is too high. So rather than expect a consistent rate of moves over a period of time, you should expect them to pause and resume automatically. This also means you should not try to accurately predict the cut over time for a given batch. I prefer to simply wait for the batch to be ready to complete, then plan the cut over time after that.
If you experience corruption issues during the moves you can refer to Andrew Higginbotham’s article on the ENow blog for some guidance.
For Exchange 2013 or 2016 the migration should include any public folder mailboxes as well.
Decommission the Old Server
After your migration is complete you can remove the old server. Do not simply shut down the Exchange server and throw it away. The Exchange Server application needs to be cleanly removed or it will leave orphaned objects behind in your Active Directory that will cause you problems later on.
To verify that the server is ready for decommissioning:
- Check that all of your client access and transport namespaces in DNS resolve to the new server.
- Check the IIS logs on the server to see whether it is still receiving client traffic (you may see traffic from the new server’s IP address still).
- Check the SMTP protocol logs on the server to see whether it is still receiving any SMTP traffic. You can also disable any custom receive connectors on the server to see whether that impacts anything on your network.
- Check that the old server has been removed from any send connectors.
- Check that the mailbox databases on the server no longer contain any mailboxes. If they do then you will not be able to remove the database.
- If you’re using Exchange Server 2010 and have public folders you’ll also need to migrate the public folders to the new server before you can remove the public folder database.
If anything has been missed Exchange setup will not let you uninstall the application.
Your own normal server decommissioning process also applies, as far as any backups, monitoring, or other standard disposal procedures go.
What Else?
The example scenario above is a simple like for like migration between two Exchange servers. I’ve covered the most basic items but in your environment there may be more to consider, such as:
- Unified messaging services
- Integration with other Microsoft products such as Lync/Skype for Business
- Integration with Office 365 for Hybrid deployments
- Integration with third party products such as Enterprise Vault or an MDM server
- Capacity management concerns while both servers are operating
So don’t consider the article above to be a complete guide for all scenarios, but hopefully it provides you with enough information to be able to successfully perform your migration.
This article Performing a Like for Like Exchange Server Migration is © 2015 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
