When all of the services and data have been migrated to Exchange Server 2016, you can begin to decommission the legacy Exchange servers from your environment. Exchange servers must be correctly removed from an organization by uninstalling the application. If you simply shut down servers without cleanly uninstalling them, you’ll leave config data in Active Directory for the servers that will cause numerous issues in future. So you should always take the time to correctly decommission your Exchange servers.
For Not Real University, the organization is running in coexistence with Exchange Server 2010, 2013, and 2016. The goal is to remove all of the legacy servers, leaving only the Exchange 2016 Mailbox and Edge Transport servers in the environment.
Removing Edge Transport Servers
The Exchange 2013 Edge Transport server for Not Real University has already been shut down, but it’s worth taking a brief look at what steps you should perform to remove an Edge Transport server. The most important thing is to ensure no more mail flow is traversing the server. After removing the Edge Subscription, ensuring no MX records are still pointing at the server, and waiting a few hours or days, you can use protocol logs and message tracking logs to verify that no more SMTP connections are hitting the server and no more messages are being processed.
When you’re sure no more email is being processed by the server, you can shut it down for a few days as a final test. You can then power it back on when ready, and uninstall the Exchange Server application from the server.
Removing Other Server Roles
The recommended practice for Exchange 2010 or later is to install multi-role servers, however it’s possible that you have installed your server roles on separate servers, so let’s look at them individually.
Exchange 2010 Client Access
Client access services are no longer needed when there are no longer any mailboxes or public folders hosted on the legacy version of Exchange. The easiest way to verify that client connections are not hitting a server any more is to review the IIS logs. It’s normal to see some traffic in IIS logs from PowerShell connections, or server-to-server traffic (such as health probes), but as long as no regular users are showing up in the IIS logs on the server you can pretty safely consider it safe to remove.
Exchange 2010 Hub Transport
Exchange 2010 Hub Transport servers can be decommissioned when there is no more email routing through the server. If there are no send connectors that are configured to use the server as a source transport server, no MX records pointing at the server, and no DNS aliases for SMTP pointing at the server, then it is likely the server is no longer required for production mail flow.
However, it’s possible some internal mail flow is still passing through the server simple due to Exchange using all available routes that exist, and some traffic will still appear in message tracking logs. So as a precaution, you can pause the transport services on the server and see if that impacts your production mail flow.
Exchange 2013 Client Access
Exchange 2013 Client Access servers need to be reviewed in the same way as Exchange 2010 Client Access, by checking IIS logs for user connections. Exchange 2013 Client Access also performs Frontend Transport functionality, so you should also review the protocol logs on the server for any SMTP connections that might still be occurring.
Exchange 2013 Mailbox Servers (Transport)
Exchange 2013 Mailbox servers perform the same transport role as Exchange 2010 Hub Transport servers, so you should review them in the same way by using message tracking log searches to determine if any mail flow is still passing through the server. As with Exchange 2010, you can pause the transport services on an Exchange 2013 Mailbox server to gauge the impact (if any) on your production mail flow.
Exchange 2010/2013 Mailbox Servers (Databases)
Exchange 2010 and 2013 Mailbox servers can’t be uninstalled until they no longer host any mailboxes or public folders. They can still host empty databases, but setup will not allow the uninstall to proceed if any mailboxes or public folders still exist in those databases. Exchange 2010 setup will also block the uninstall if the server is still responsible for Offline Address Book generation. Since the Exchange 2010 OAB is not used for Exchange 2013 or later organizations, you can simply remove any Exchange 2010 OABs that still exist.
You can also dismount the databases to determine if their removal is going to cause any problems.
For DAG members the approach is a little different. The process involves:
- Removing database copies from the server (unless it is the last DAG member hosting the single copy of the databases)
- Removing the server from DAG membership
- Removing the databases from the standalone server
- Removing the DAG object from the organization when it has no more members
Uninstalling Exchange
The uninstall of Exchange from the server can be initiated from the Control Panel, in Programs and Features or Add/Remove Programs, depending on your version of Windows Server. Exchange setup will warn you of any decommission steps that you’ve missed, and block you from proceeding with the uninstall if anything still needs to be addressed. When Exchange has been removed, you can complete the decommission of the Windows servers themselves by following your standard process.
After the legacy Exchange servers have been removed, your migration to Exchange 2016 is complete.
