Exchange Server 2016 migration from version 2010

This article is part of a series based on my notes during the migration of an Exchange organization from version 2010 to 2016. This is not a complete procedure, but a description of the main points and areas. The examples relate to a specific design, but can usually be generalized. Similarly, although this is a description of a migration, the information is also suitable for a new installation or administration.

The official Exchange Server documentation is quite good and contains a lot of information. Some things are just harder to find, and others are constantly repeated (we also run into errors or inaccuracies). It's a pity that the migration process is not described there. One mention is What's new when upgrading from Exchange 2010 to Exchange 2016 RTM?

The exact details of the migration depend on the topology and configuration. The description here reflects a situation where we have three Exchange Server Enterprise 2010 SP3 RU17 servers, running on Windows Server 2008 R2 in an AD DS functional level of Windows Server 2012 R2. They are located in two sites and use a DAG. The new servers are Exchange Server Enterprise 2016 CU11 on Windows Server 2016. The Exchange 2016 Edge Transport server is not used.

On the Internet, we can find various migration guides, some of them:

• Migrating to Exchange Server 2016
• Exchange 2010 to Exchange 2016 Migration - Part 1
• Migrating to Exchange 2016 - Part 1
• Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 1)

Migration Planning

At the beginning, it is advisable to have a documented current state. A network diagram and additional information in tables are helpful for an overview. We need to have an overview of the servers, addresses, DNS names, communication services running on the Exchange server, firewalls, and connectivity.

Then we need to prepare a plan for the target state and any transitional period during the migration. Again, we need to record the same data as for the current state.

It is important to record which protocols and through which domain names (addresses) clients and other mail servers will connect. How will the communication occur internally and from the internet. This area is described in the article Exchange Server 2016 Namespaces - service addresses.

It is possible that we previously used separate domain names (and possibly IP addresses) for different services, which we can now significantly consolidate (essentially) to a single common address for most services. It is also possible that internal clients previously connected directly to the addresses of the mail servers. Today (and perhaps even earlier), it is recommended to use a virtual name, a DNS record that contains the address of one or more mail servers. When we want to redirect clients to a new server, we only need to change the DNS, and we don't have to change the client configuration on the Exchange server (on the other hand, if we have a new address for the new servers that we set on them, clients will start using these servers only when the mailbox is moved).

For the internet, we may need the following DNS records:

• A - mail.firma.cz - mail service address
• CNAME - autodiscover.firma.cz - Autodiscover service
• MX - firma.cz - SMTP leading to mail.firma.cz
• TXT - firma.cz - optionally an SPF record or more

Depending on our current and planned future service addresses, we will need to perform SMTP traffic redirection and client connections to the new servers at some point. In most cases, the compatibility works in such a way that when we connect to a server with a new version of Exchange, and the mailbox is on an older version, the communication is redirected/proxied/forwarded to this server. So it works without problems. But if we connect to a server with an older version, and the mailbox is on a newer one, the communication will not reach the mailbox.

We can handle the change of communication routing in various ways. One option is to swap the IP addresses, so that the new servers get the addresses of the older servers, then we don't have to change anything. We probably control the communication from the internet on the firewall, so we can modify the rule. For internal SMTP traffic and client connections, we can modify the DNS record. If an IP address is used, we need to manually modify it. Internal client connections (and possibly external ones as well) are handled by Autodiscover, so it's about its configuration, and routing to the new server before migrating the mailboxes.

Individual Migration Steps

Below are links to articles that describe individual parts of the migration. They list the main migration steps.

• Exchange Server 2016 installation and basic configuration
  • installation of the first and additional Exchange Server 2016
  • certificate configuration
  • creation of a new mailbox database (Mailbox DB), migration of system mailboxes
  • removal of default mailbox DBs
• Exchange Server 2016 Database Availability Group
  • creation of a new DAG
  • adding servers to the DAG
  • creation of database copies
• Exchange Server 2016 Client Access
  • configuration of Client Access Services - MAPI over HTTP, OWA, Outlook Anywhere, Exchange ActiveSync, EWS, OAB, ECP, POP3/IMAP, AutoDiscover
• Exchange Server 2016 Mail Flow - Mail Routing and Connectors
  • configuration of mail flow (SMTP) - Receive and Send Connectors
• Communication Redirection (Client Access Namespace Cutover and Mail Flow Cutover)
  • redirect the Autodiscover service to the new server (SCP, URL, SRV)
  • redirect external communications to the new server
  • redirect internal communications to the new server
• Exchange Server 2016 Public Folders coexistence
  • configure access to public folders from the new servers
• Exchange Server 2016 moving mailboxes and OAB
  • set mailbox and message size limits
  • move mailboxes
  • configure Offline Address Books
• Exchange Server 2016 Public Folders and their migration
  • migration of public folders
• Exchange Server 2016 removing version 2010 servers
  • decommissioning of old servers