Home » Exchange Server » Exchange Server 2016 Migration – Removing Legacy Servers

Exchange Server 2016 Migration – Removing Legacy Servers

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.

mail-flow-cutover-3

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:

  1. Removing database copies from the server (unless it is the last DAG member hosting the single copy of the databases)
  2. Removing the server from DAG membership
  3. Removing the databases from the standalone server
  4. 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.

exchange-2016-migration-end

After the legacy Exchange servers have been removed, your migration to Exchange 2016 is complete.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

10 comments

  1. Matt says:

    Hey Paul,

    If a 2016 Exchange Server was installed as a trial alongside a 2010 exchange environment, is it safe to uninstall the 2016 server? We didn’t migrate anything or configure anything to point towards 2016. We basically just installed it to see if it would work first. We shut down the 2016 server and the entire 2010 environment is working fine. Curious if you think anything will break in 2010 environment if we uninstall 2016.

  2. Leo says:

    Hi Paul,

    I’m currently running Exchange 2013 and 2016 in my environment. Migrated fully to 2016 and now I’m at the stage to decommission my 2013 servers.

    I’ve powered off my 2013 servers (2 CAS and 2 MBX nodes) and left it for a couple of days. No impact, no issues. I’m not using any Receive Connectors for 2013. I do have a Send Connector (which applies to all servers in the environment) and I’ve already removed the 2013 servers from the source.

    Ok, so I figured I can now power the 2013 servers back online and then go through removing it cleanly. I reviewed the IIS logs on the 2013 servers, there’s nothing flowing through the CAS nodes, so that’s good. But then I look at the message tracking logs (filtered to -1 days) and there are still some emails hitting the MBX nodes (only showing emails since I powered the servers online). I’m sure the ReceiveConnectors are not configured for 2013, I’ve even gone through and checked all the default 2013 receive connectors for any weird settings. One of the emails in the log isn’t internal. I don’t have any MX pointing to the 2013 hub transport and no DNS alias or anything. Any ideas what else I can check?

      • Leo says:

        Thanks for your reply Paul. I’ve already powered off the server, which effectively does the same thing as stopping the transport services. There were no impacts. Despite that, I think there is a problem:

        – Powered off server for 4 days, no impact
        – Power on server (so I can do a proper clean up)
        – Checked Message Tracking logs for the past 4 days just to be sure, nothing shows up, that’s good
        – Checked Message Tracking logs again, only about 2 hours later. Messages show up.

        The issue is that there seems to be messages hitting the old servers. I’m not using any smarthost, all connectors are configured correctly. I’m just wondering if I missed something at this point.

  3. Jeremy says:

    Amazing series of articles. I’ve bookmarked each page in the 2016 migration series and several of the linked pages as well, all in a dedicated folder acting as a nice migration toolkit. This and the Exchange Deployment Assistant together make for a really well-looked-after feeling during migration projects.

Leave a Reply

Your email address will not be published. Required fields are marked *