Performing a Like for Like Exchange Server Migration

DECEMBER 10, 2015 BY PAUL CUNNINGHAM 42 COMMENTS

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.

March 17, 2021 1

To plan the migration project, we can break it down to several steps:

1. Install the new Exchange server

2. Configure the new Exchange server
• Client access (Outlook, OWA, mobile devices, etc)
• Transport (mail flow)
• Mailbox databases
3. Migrate data and services to the new Exchange server
• Client access
• Transport services
• Mailboxes
4. 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.

March 17, 2021 2

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:
• Certificate Warnings in Outlook After Installing New Exchange Server

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:

March 17, 2021 3

 • 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:

• Exchange Server 2016 SMTP relay

• Exchange Server 2013 SMTP relay
• Exchange Server 2010 SMTP relay

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)

March 17, 2021 4

 • 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).

Add the Get-DailyBackupAlerts.ps1 script to your daily monitoring to ensure you don’t
have missed or failed backups going unnoticed in your Exchange environment.

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.

March 17, 2021 5

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

March 17, 2021 6

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.

March 17, 2021 7

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.

March 17, 2021 8

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.

March 17, 2021 9

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.

-eof-

March 17, 2021 10