Exchange 2016 is approaching the end of extended support and will be out of support on October 14th, 2025. If you are using Exchange Server 2019, you will be able to in-place upgrade to the next version, Exchange Server Subscription Edition (SE), so Exchange Server 2016 will need to be decommissioned at some point.

This article will focus on the removal of Exchange 2016 from an environment which already has Exchange 2019 installed. We will not focus on any of the steps already documented for upgrading to Exchange 2019. To get those details, see the Exchange Deployment Assistant and create a custom step-by-step deployment checklist for your environment. Also check out the Exchange Server documentation for details on upgrading to a newer version of Exchange Server.

If you plan to stay on-premises, we recommend moving to Exchange 2019 as soon as possible. Only Exchange 2019 will support in-place upgrades to Exchange SE, marking the first time in many years that you can perform an in-place upgrade on any Exchange release.  You should start decommissioning Exchange 2016 servers in favor of Exchange 2019 now, to be ready for easy in-place upgrades to Exchange SE when it becomes available.

Prepare for Shutdown

Once you’ve completed your migration from Exchange 2016 to a newer version of Exchange Server, you can prepare the Exchange 2016 servers to be decommissioned.

Inventory and upgrade third-party applications

Make a list of all applications using Exchange 2016 servers and configure each of them to use the newer Exchange Server infrastructure. If you are using a shared namespace for these applications, minimal configuration would be required. Contact the providers of those applications to ensure they are supported on your latest version of Exchange Server.

Client Access Services

Review Exchange virtual directory namespaces

Review all client connectivity namespaces and ensure they are routing to the latest Exchange server(s) in the environment. These include all names published for your Exchange virtual directories. If the newer Exchange environment is using the same namespaces, you can reuse the existing SSL certificate. If the new Exchange environment is using a new namespace that does not exist as a Subject Alternative Name (SAN) on your current SSL certificate, a new certificate will need to be obtained with the appropriate names.

Tip: Verify that all clients including ActiveSync, Outlook (MAPI/HTTP or RPC/HTTP), EWS, OWA, OAB, POP3/IMAP, and Autodiscover are no longer connecting to legacy Exchange servers. Review each Client Access server’s IIS Logs with Log Parser Studio (LPS). LPS is a GUI for Log Parser 2.2 that greatly reduces the complexity of parsing logs, and it can parse large sets of logs concurrently (we have tested with total log sizes of >60GB). See this blog post for details.

Review Service Connection Point objects in Active Directory

Run the following command to obtain the value of the Autodiscover service connection point (SCP). The Autodiscover SCP is used by internal clients to look up connection information from Active Directory:

Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like “Version 15.1*”} | Get-ClientAccessService | Format-Table Name, FQDN, AutoDiscoverServiceInternalUri -AutoSize

If present, ensure the AutoDiscoverServiceInternalURI routes to the new Exchange Servers or load-balanced VIP.

Get the URI from a 2019 server:

$2019AutoDURI = (Get-ExchangeServer <Ex2019 ServerName> | Get-ClientAccessService).AutoDiscoverServiceInternalURI.AbsoluteURI

Then set it on the 2019 virtual directory:

Set-ClientAccessService -Identity <Ex2016 ServerName> -AutoDiscoverServiceInternalUri $2019AutoDURI

You can also remove this value by setting AutoDiscoverServiceInternalUri to $null.

Mailflow

Next, review all mail flow connectors to ensure that the server is ready to be decommissioned.

Review the send connectors

Review the send connectors and ensure that the Exchange 2016 servers have been removed and the newer Exchange servers have been added. Most organizations only permit outbound network traffic on port 25 to a small number of IP addresses, so you may also need to review and update the outbound network configuration.

Get-SendConnector | Format-Table Name, SourceTransportServers -AutoSize
Get-ForeignConnector | Format-Table Name, SourceTransportServers -Autosize

Review the receive connectors

Review the receive connectors on the Exchange 2016 servers and ensure they are recreated on the new Exchange servers (e.g., SMTP relay, anonymous relay, partner, etc.) Review all namespaces used for inbound mail routing and ensure they deliver to the new Exchange servers. If your Exchange 2016 servers have any custom or third-party connectors, ensure they can be recreated on the newer Exchange servers, you can do this by using the Export-CLIXML command.

Get-ReceiveConnector -Server <ServerToDecommission> | Export-CLIXML C:tempOldReceive.xml

Tip: Check the SMTP logs to see if any services are still sending SMTP traffic to the servers via hard coded names or IP addresses. To enable logging, review Configure Protocol Logging. Ensure you capture message logs from a period long enough to account for any apps or processes which relay for weekly or monthly events, such as payroll processing or month-end reporting, as these may not be captured in a small sample size of SMTP Protocol logs.

The decommissioning process is a great opportunity to audit your mail flow configuration, ensuring all the required connectors are properly configured and secured. It’s the perfect time to get rid of any of those Anonymous Relay connectors that may not be in use in your environment. Or, if Exchange is deployed in hybrid, possibly relay against Office 365.

Edge Servers

If you have one or more Edge Transport servers, you must install a newer version of the Edge Transport role (i.e., Exchange 2019). If subscribed to an active directory site, recreate the Edge Subscription as documented here.

If you plan to decommission your Edge servers without replacing them, ensure your firewall rules are updated to route incoming traffic to the Mailbox servers. The Mailbox servers also need to be able to communicate outbound over TCP port 25.

Mailboxes

Move all Exchange 2016 mailboxes to a newer version of Exchange Server

Exchange 2016 cannot be decommissioned until all mailboxes are migrated to the new Exchange servers. Migrations are initiated from the newest version of Exchange. For example, when migrating to Exchange 2019, you create all migration batches and move requests from Exchange 2019; move all your Arbitration Mailboxes to the newest Exchange server first.

Once all moves have been completed, delete all migration batches and move requests. Any lingering move requests or mailboxes will block uninstalling Exchange 2016.

Run the following commands in the Exchange Management Shell (EMS) to identify any mailboxes that need to move to a newer Exchange Server:

Set-ADServerSettings -ViewEntireForest $True
Get-Mailbox -Server <Ex2016 ServerName> -Arbitration
Get-Mailbox -Server <Ex2016 ServerName> -ResultSize Unlimited
Get-Mailbox -Server <Ex2016 ServerName> -Archive -ResultSize Unlimited
Get-SiteMailbox
Get-Mailbox –AuditLog

You may also need to run Get-SiteMailbox –DeletedSiteMailbox if any site mailboxes had been previously removed (as this can still be a blocker for removing databases).

If any mailboxes are found, migrate them to a newer version of Exchange before moving on. Additional information can be found in Manage on-premises mailbox moves in Exchange Server.

After ensuring all arbitration and user mailboxes have been moved, ensure all public folder mailboxes have been migrated:

Get-Mailbox -Server <Ex2016 ServerName> -PublicFolder -ResultSize Unlimited

Additional information on public folder migrations can be found in Migrate public folders from Exchange 2013 to Exchange 2016 or Exchange 2019.

After all mailboxes have been moved to newer Exchange servers, and after reviewing the moves and migration batches, you can remove the moves and batches. Run the command first with the -WhatIf parameter, and after confirming all listed moves and batches can be removed, run it again without the –WhatIf parameter.

All completed move requests can be removed using the following command – see Remove-MoveRequest

Get-MoveRequest -ResultSize Unlimited | Remove-MoveRequest -Confirm:$false -WhatIf

All migration batches can be removed using the following command – see Remove-MigrationBatch

Get-MigrationBatch | Remove-MigrationBatch -Confirm:$false -WhatIf

Decommissioning the Database Availability Group

Verify no mailboxes exist on Exchange 2016 servers

Run the following command:

Get-Mailbox –ResultSize unlimited | Where-Object {$_.AdminDisplayVersion -like “Version 15.1*”}

If any mailboxes are found, migrate them to newer Exchange servers or remove them.

Remove mailbox database copies

Every mailbox database copy on Exchange 2016 must be removed. You can do this in the Exchange admin center (EAC) or using the EMS. Details for using either tool are in Remove a mailbox database copy.

Note that removing a database copy does not remove the actual database files or transaction logs from the server.

To find passive copies on a per-server basis, run:

Get-MailboxDatabaseCopyStatus –Server <Ex2016 ServerName> | Where-Object {$_.Status -notlike “*mounted”} | Remove-MailboxDatabaseCopy

To find passive copies on a per-database basis, run:

Get-MailboxDatabaseCopyStatus <DatabaseName> | Where-Object {$_.Status -notlike “*mounted”} | Remove-MailboxDatabaseCopy

Remove mailbox databases

Assuming best practices were followed for the Exchange 2016 environment, we will have a DAG for HA/DR capabilities. With all mailboxes having been removed from the 2016 environment, we are ready to tear down the DAG to move forward with decommissioning Exchange 2016. After all mailboxes are migrated off Exchange 2016 and all passive database copies are removed, you can remove any leftover databases from the Exchange 2016 environment. 

Run the following command with the –WhatIf parameter to confirm that all listed databases can be removed, and then run the command without the –WhatIf parameter to remove them.

Get-MailboxDatabase –Server <ServerToDecommission> | Remove-MailboxDatabase –Confirm:$false -WhatIf

If any mailboxes are present in a database, you cannot remove the database. The attempt will fail with the following error:

This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, public folder mailboxes or arbitration mailboxes, audit mailboxes.

If you verified that no mailboxes reside in the database, but you are still unable to remove the database, review this article. The database you’re trying to remove might contain an archive mailbox for a primary mailbox in a different database. Bear in mind: if your mailboxes are on an InPlaceHold or LitigationHold, these will be blocked from removal, and you’ll want to ensure it’s safe to remove each hold to allow the continuation of the removal.

Note: If you run into an issue trying to remove mailbox databases that host no active mailboxes one of the ways you can identify which objects are pointing to this database would be these commands:

Set-ADServerSettings -ViewEntireForest $True
$DN =(Get-MailboxDatabase “DBNAME”).DistinguishedName
Get-AdObject -Filter ‘(homemdb -eq $DN -or msExchArchiveDatabaseLink -eq $DN) -and (Name -notlike “HealthMailbox*” -and Name -notlike “SystemMailbox*”)’

Remove all members from your Database Availability Group(s)

Each DAG member must be removed from the DAG before the DAG can be removed. You can do this using the EAC or the EMS. Details for using either tool are in Manage database availability group membership.

Remove DAGs

Once all database copies have been removed, and all members have been removed from the DAG, the DAG can be deleted using the EAC or the EMS. Details for using either tool are in Remove a database availability group.

Tip: If you have a DAG with a file share witness, don’t forget to decommission the file share witness used for the Exchange 2016 DAG.

A note about the Unified Messaging Role

This post does not cover Unified Messaging, because that feature has been removed from Exchange 2019. For detailed steps on migrating Unified Messaging to another solution, see Plan for Skype for Business Server and Exchange Server migration – Skype for Business Hybrid. Note, though, if your Exchange 2016 users have UM-enabled mailboxes, do not move them to Exchange 2019 before you move them to Skype for Business Server 2019, or they will have a voice messaging outage.

Put Exchange 2016 servers into maintenance mode

Once everything is moved from Exchange 2016 to a newer version of Exchange Server, put the Exchange 2016 servers into maintenance mode for one week to observe any unforeseen issues. If issues are experienced, they can be resolved before you remove Exchange 2016. If no issues occur, you can uninstall your Exchange 2016 servers. Please note that we do not recommend shutting down the Exchange 2016 servers as this can cause issues if resources aren’t fully migrated unless you plan to do so within a change control window.

The goal is to verify that nothing is trying to connect to these Exchange 2016 servers. If you find something that is, update it to use the new Exchange servers, or return the Exchange 2016 servers back to service until updates can occur.

Even after reviewing messaging and connectivity logs, it’s not uncommon for an organization to keep their legacy Exchange servers online (in Maintenance Mode) for a period long enough to find issues with unknown processes, unexpected recovery efforts, etc.

To put an Exchange server into maintenance mode, see the Performing maintenance on DAG members section of Manage database availability groups in Exchange Server.

For additional information on Exchange Server component states, see this blog post.

Uninstall Exchange 2016

Review best practices

Start by reviewing the Best Practices section of Upgrade Exchange to the latest Cumulative Update, as they also apply when uninstalling Exchange (e.g., reboot the server before and after running Setup, disable antivirus, etc.).

Remove health mailboxes

Prior to uninstalling Exchange 2016, use the following command to remove all Exchange 2016 health mailboxes:

Get-Mailbox -Monitoring | Where-Object {$_.AdminDisplayVersion -like “Version 15.1*”} | Remove-Mailbox -Confirm:$false

Uninstall Exchange 2016

Before you begin the uninstall process, close EMS and any other programs that might delay the uninstall process (e.g., programs using .NET assemblies, antivirus, and backup agents). Then, uninstall Exchange 2016 using either of these recommended methods (we do not recommend using Control Panel):

Use the unattended setup mode: Setup.exe /mode:Uninstall
Run Setup.exe from the setup file location

Perform post-uninstallation tasks

After uninstalling Exchange, there are some general housekeeping tasks that remain. These may vary depending on the steps taken during your upgrade process and depending upon your organization’s operational requirements.

Examples include:

Removing the Exchange 2016 computer accounts from Active Directory (including the DAG’s Cluster Name Object and Kerberos ASA object).
Removing the Exchange 2016 servers as targets to other services (e.g., backup software, antivirus/security agents, network monitoring).
Removing Exchange 2016 name records from DNS.
Ensuring the folder on the DAG’s file share witness (FSW) servers were successfully removed.
Removing the Exchange Trusted Subsystem from the FSW servers’ local Administrators group unless these servers are witnesses for other DAGs.
Removing old firewall rules that open ports to Exchange 2016 environment.
Removing and disposing of the Exchange 2016 environment’s physical equipment.
Deleting any Exchange 2016 virtual machines.

In summary, when decommissioning Exchange 2016, the most important considerations are:

Planning for removal (by updating anything that relies on Exchange to use newer Exchange servers)
Monitoring to ensure nothing tries to connect to the servers being removed

If you have any questions or would like to discuss a specific scenario, feel free to ask in the Exchange Tech Community forum.

Jason Lockridge, Dylan Stetts, Robin Tinnie and Josh Hagen

​Microsoft Tech Community – Latest Blogs –Read More