[ad_1]
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 mailboxes 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 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 and/or with services disabled) 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.
Source link
