Decommissioning Exchange On-Premises Servers and Consolidating Email SMTP Relays 

When migrating to the latest version of Exchange On-Premises Server or Exchange Online, two major events must take place. One is the decommissioning of the old Exchange on-premises servers from the environment. The other is the consolidation of email SMTP relays used for email applications, multi-function printers, etc.  

This article describes the planning requirements and key factors to consider when decommissioning Exchange servers and consolidating SMTP relay servers or appliances.  

Disable External Protocol Access to Exchange On-Premises Servers After Mailbox Moves  

In an Exchange on-premises Server migration from Exchange 2013 or 2016 to Exchange 2019, a coexistence period will occur where two sets of Exchange servers exist in the production environment. 

Administrators must manage both sets of servers and perform daily administration tasks such as installing the latest Cumulative and Security Updates on servers. With reports of day-zero vulnerabilities and Exchange servers being seen as potential security liabilities, it’s important to disable external protocols such as OWA for webmail, EAS for ActiveSync,  EWS for availability service, and RPS for remote PowerShell access as soon as possible after migrating mailboxes from these servers.  

Move Mailboxes from Database Availability Groups  

If some of the source Exchange servers are part of a Database Availability Group (DAG), Exchange servers host multiple copies of a database, as illustrated in figure 1.

As you move mailboxes off of the DAG, the mailboxes should be moved from the servers where the active database copy in all yellow in the figure above no longer hosts any mailboxes.  

Once all mailboxes have been migrated off a server within a DAG, the Exchange on-premises servers are ready to go through the decommissioning process. 

Place Exchange On-Premises Servers Into Maintenance Mode  

Before removing a server, you must place the server into maintenance mode. 

To place a standalone Exchange server that is not part of a DAG into maintenance mode, run the following command from the Exchange Management Shell (EMS): 

Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance 

To validate that the server has been placed into maintenance mode, run the following command in EMS to confirm that only the Monitoring and RecoveryActionsEnabled components are in an Active state and all others show in an Inactive state:  

Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize 

To place an Exchange server that is a member of a DAG into maintenance mode, follow the steps listed in Microsoft’s documentation.

Remove Database Copies and Remove Server from DAG 

Once a DAG member server is in maintenance mode, all database copies must be removed from the server.  

Run the following command from EMS to remove all database copies from the server: 

Get-MailboxDatabaseCopyStatus -Server <ServerName> | Remove-MailboxDatabaseCopy -Confirm:$false 

You will see warning prompts stating the copy of the database on the server has been removed (from the Exchange configuration) and advice to remove the physical database files from the server.  

To remove the server from the DAG, run the following command from EMS: 

Remove-DatabaseAvailabilityGroupServer -Identity "<DAGNAME>" -MailboxServer "<SERVERNAME>" -Confirm:$false 

Uninstall Exchange from the Server 

Once an Exchange server supports no remaining databases and is in a standalone state (if removed from a DAG), you can uninstall Exchange from the server.  

Steps that help speed up the uninstallation process prior to uninstalling Exchange include the following: 

• Reboot the Server Before Uninstallation: A reboot of the server prior to the Exchange uninstall helps to avoid any errors that may occur, such as processes containing open Exchange files or a previous pending reboot condition of a server. 

• Turn Off Antivirus: Disabling any installed antivirus jobs running on the Exchange server helps to prevent on-demand file scanning of the Exchange files during the uninstallation process.  

You must first uninstall any Exchange Security Updates (SU) or Interim Updates (IU) before uninstalling Exchange from the server. SU’s and IU’s update file versions that need to be patched with a higher version number than the installed version of the Exchange Cumulative Update (CU), as illustrated in Figures 2 and 3. If you attempt to uninstall the Exchange CU first without removing the SU or IU, the Exchange setup will fail, stating the version of Exchange installed on the server does not match the version of Exchange in the setup files, as noted in Microsoft’s documentation.  

You can uninstall the Exchange SU using the EXE file initially used to install the SU with the elevated level of permissions needed. You can also uninstall the Exchange SU in an unattended mode by running a script that uses the MSIEXEC process to find the product GUID code of the Exchange version and the patch GUID of the SU. In the example below, the first GUID in the argument list is the version of Exchange, and the second GUID is the identifier of the SU patch: 

Start-process -filepath "c:\windows\system32\msiexec.exe" -argumentlist "/i {4934D1EA-BE46-48B1-8847-F1AF20E892C1} MSIPATCHREMOVE={1666047B-AF92-4A37-A3B9-003967CD763E}" -PassThru -wait 

You can identify the SU patch information needed from the following WMI or COM command examples: 

get-wmiobject Win32_Product | Sort-Object -Property Name |Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize 

$Installer = New-Object -ComObject WindowsInstaller.Installer; $InstallerProducts = $Installer.ProductsEx("", "", 7); $InstalledProducts = ForEach($Product in $InstallerProducts){[PSCustomObject]@{ProductCode = $Product.ProductCode(); LocalPackage = $Product.InstallProperty("LocalPackage"); VersionString = $Product.InstallProperty("VersionString"); ProductPath = $Product.InstallProperty("ProductName")}} $InstalledProducts

You can then uninstall Exchange in unattended mode by following the examples listed here to build the uninstall command. Once the uninstall is complete, remove any Exchange files from the server after reboot.  

SMTP Relay Server and Appliance Consolidation 

As you are removing Exchange servers from the environment, you also must factor in the consolidation or removal of SMTP servers and appliances responsible for sending any volume of email.  

Start by identifying the number and types of appliances, the SMTP servers you have, and the workloads and traffic patterns for each appliance and server. This information will help you determine what can be consolidated and how to do so in a way that will minimize disruption and maximize performance.  

To help identify SMTP appliances that are in use for external SMTP relay traffic, you can use a third-party website to lookup the external DNS MX record for your email domain. You can then lookup the external DNS A records that point to your MX record, which would identify the external IP addresses of possible SMTP appliances. You could then search internally within your environment to lookup the internal pointer record that matches the DNS external A record.  

To identify IP addresses that use Exchange SMTP relay servers, you first have to determine if verbose logging is turned on for your SMTP relay receive connector.  

Run the following cmdlet in EMS: 

Get-ReceiveConnector -Server “SERVERNAME” | ft Identity, Enabled, TransportRole,Protocol*,Bindings 

If the ProtocolLoggingLevel shows the value Verbose, this means logging is enabled.  

To enable verbose logging on the SMTP relay receive connector, run the following cmdlet in EMS: 

Get-ReceiveConnector -Identity “SERVERNAME\ConnectorName” | Set-ReceiveConnector -ProtocolLogging Verbose 

Once logs are generated, you can find the log path by running the following cmdlet in EMS: 

Get-FrontendTransportService -Identity “SERVERNAME” | fl Name,Identity,Receive* 

You can also search the Exchange message transport logs to help identify SMTP traffic, by referring to the examples listed here.  

Once you have a clear understanding of your current environment, you can start planning the consolidation. This may involve replacing older or less efficient appliances with newer, more powerful ones, or consolidating multiple appliances into a single, larger appliance. If you use dedicated Exchange on-premises servers as SMTP relays, you should turn off external OWA, EAS, and PowerShell protocol access on those servers to limit potential vulnerabilities. You should also consider factors such as the impact on your network and the potential need for additional hardware or software to support the consolidation. 

As part of the consolidation process, you’ll need to migrate your existing SMTP relay settings and configurations to the new appliances or Exchange send connectors. This may require some testing and fine-tuning to ensure that everything is working properly and that emails are being delivered reliably. 

Decommissioning is Vital 

Decommissioning Exchange servers and consolidating SMTP relay servers and appliances are a vital part of any migration or hardware refresh project. By including these considerations and steps in your planning and execution processes, you can increase the chances of a successful project.