Blog Post

Exchange Team Blog
9 MIN READ

Decommissioning Exchange Server 2013

The_Exchange_Team's avatar
Aug 31, 2022

As we mentioned in our recent blog post, April 13, 2023 (which marks the end of support for Exchange Server 2013) is approaching quickly. To help Exchange 2013 customers move to a newer version of Exchange Server, here’s an overview of Exchange 2013 decommissioning process.

This article focuses on the removal of Exchange 2013 from an environment that already has a Exchange Server 2016 and/or Exchange Server 2019 installed. We won’t go into the steps required to upgrade to Exchange 2016 or 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.

Prepare for Shutdown

Once you’ve completed your migration from Exchange 2013 to a newer version of Exchange Server, you can prepare the Exchange 2013 servers to be decommissioned. The following steps are organized by server role to prepare for a soft shutdown and the removal of server roles.

Inventory and Upgrade Third-Party Applications

Make a list of all applications using Exchange 2013 servers and configure each of them to use the newer Exchange Server infrastructure. Contact the providers of those applications to ensure they are supported on your latest version of Exchange Server.

Client Access Server (CAS) role

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 Outlook Anywhere, Autodiscover, and other 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, 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.0*” -and $_.IsClientAccessServer -eq $true} | Get-ClientAccessService | Format-Table Name, FQDN, AutoDiscoverServiceInternalUri -AutoSize

 

If present, ensure the AutoDiscoverServiceInternalURI routes to the new Exchange Server environment.

 

Set-ClientAccessService -Identity <Ex2013 ServerName> -AutoDiscoverServiceInternalUri “https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml"

 

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

Transport Pipeline

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 2013 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 2013 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 2013 servers have any custom or third-party connectors, ensure they can be recreated on the newer Exchange servers.

 

Get-ReceiveConnector -Server <ServerToDecommission>

 

Tip: Check the SMTP logs to see if any outside systems 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 in hybrid, possibly relay against Office 365.

Edge Transport Role

If you have one or more Edge Transport servers, you must install a newer version of the Edge Transport role and 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.

Mailbox Role

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

Exchange 2013 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.

Once all moves have been completed, delete all migration batches and move requests, as any lingering move requests or mailboxes block uninstalling Exchange 2013.

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 <Ex2013 ServerName> -Arbitration
Get-Mailbox -Server <Ex2013 ServerName> -ResultSize Unlimited
Get-Mailbox -Server <Ex2013 ServerName> -Archive -ResultSize Unlimited
Get-SiteMailbox

 

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 <Ex2013 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 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 the Exchange 2013 servers

Run the following command:

 

Get-Mailbox –ResultSize unlimited | Where-Object {$_.AdminDisplayVersion -like "Version 15.0*"}

 

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

Remove Mailbox Database Copies

Every mailbox database copy on Exchange 2013 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 .edb database file or transaction logs from the server.

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

 

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

 

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

 

Get-MailboxDatabaseCopyStatus <database name> | Where-Object {$_.Status -notlike "*mounted"} | Remove-MailboxDatabaseCopy

 

Remove Mailbox Databases

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

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 2013 DAG.

Unified Messaging Role

Unified Messaging (UM) in Exchange Server 2016 is basically unchanged from Exchange Server 2013. But UM has been removed from Exchange 2019 and Exchange 2019 does not include voicemail or auto attendant features. If you deployed the UM role in Exchange 2013 and you want to upgrade to Exchange 2019, you can migrate your voicemail to the Microsoft Cloud Voicemail service in Microsoft 365. If you want to migrate your voicemail to Cloud Voicemail, see Plan for Skype for Business Server and Exchange Server migration.

Put Exchange 2013 servers into maintenance mode

Once everything is moved from Exchange 2013 to a newer version of Exchange Server, put the Exchange 2013 servers into maintenance mode for one week to observe any unforeseen issues. If issues are experienced, they can be resolved before you remove Exchange 2013. If no issues occur, you can uninstall your Exchange 2013 servers.

The goal is to verify that nothing is trying to connect to these Exchange 2013 servers. If you find something that is, update it to use the new Exchange servers, or return the Exchange 2013 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 2013

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 2013, use the following command to remove all Exchange 2013 health mailboxes:

 

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

 

Uninstall Exchange 2013

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). The uninstall Exchange 2013 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. These may vary depending on the steps taken during your upgrade and depending on your organization’s operational requirements.

Examples include:

  • Removing the Exchange 2013 computer accounts from Active Directory (including the DAG’s Cluster Name Object and Kerberos ASA object).
  • Removing the Exchange 2013 servers as targets to other services (e.g., backup software, antivirus/security agents, network monitoring).
  • Removing Exchange 2013 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 2013 environment.
  • Removing and disposing of the Exchange 2013 environment’s physical equipment.
  • Deleting any Exchange 2013 virtual machines.

In summary, when decommissioning Exchange 2013, the most important considerations are: planning for removal (by updating anything that relies on Exchange to use newer Exchange servers) and 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.

Josh Hagen, Jason Burnside, Louis Gonzalez, David Vasta, Paul Newell, Chad Solarz

Updated Oct 20, 2022
Version 4.0
  • Great guide on how to uninstall Exchange Server 2013. I'm wondering if you have a similar one in migrating to Exchange Server 2016/2019 or even Exchange Online?

  • hrmartinez's avatar
    hrmartinez
    Copper Contributor

    Great guide; it was very useful. I have just completed the uninstallation of Microsoft Exchange Server 2013

     

  • BoBeB's avatar
    BoBeB
    Brass Contributor

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

     

    Get-ClientAccessService is not recognised, shouldnt it be Get-ClientAccessServer ?

    Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like “Version 15.0*” -and $_.IsClientAccessServer -eq $true} | Get-ClientAccessServer | Format-Table Name, FQDN, AutoDiscoverServiceInternalUri -AutoSize

     

  • NotionFDE's avatar
    NotionFDE
    Copper Contributor

    This article, as well as the one for Exchange Server 2010, have been awesome guides to keep track of the entire process. Thank you for both, it has helped make life easier as we continue to assist customers with their upgrades and migration projects day in and day out. I was wondering if there is any sort of formal documented process like this one for Exchange Server 2016 for when a customer is upgrading from 2016 to 2019.

     

    I know it is an unusual ask while they both share the same EOL date, but I'm finding customers are still pushing forward with making the jump up to 2019 from 2016 anyway. Customers just don't know what the right move is when 2016 and 2019 currently end on the same date, Given that they both share the same EOL my theory is that they will extend Exchange Server 2019 EOL, but leave 2016 right where it is.

     

    I hope Microsoft announces something soon if they plan to make any changes to either Exchange Server 2016 or 2019 EOL date. October 2025 will be here before we know it. Expecting customers to make another jump beyond 2019 after they likely upgraded to that is a bit unreasonable with less than 1.5 years worth of advanced notice.. Customers are making the jump to 2019, and if they have to do another one in a year and a half seems unfair. I think it is also a little unfair to leave everyone in the dark about what comes after Exchange Server 2019 when most organizations need time to plan if nothing changes and they both reach EOL at the same time in October 2025.

  • alexandreracine's avatar
    alexandreracine
    Copper Contributor

    Review Service Connection Point objects in Active Directory

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

     

    When I copy and paste that, it does not work because of the "Word processor" quotes "“”", so use this instead:

     

     

    Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like "Version 15.0*" -and $_.IsClientAccessServer -eq $true} | Get-ClientAccessService | Format-Table Name, FQDN, AutoDiscoverServiceInternalUri -AutoSize