Keep Exchange after migration or uninstall it (i.e. remove the last Exchange server from AD when Exchange Online migration is complete)? This is a question all customers ask, but for many years it was an absolute no-no. The reason for this is (or was) Microsoft’s Supportability Matrix. Without getting into technical details, the reason is (or was) quite simply this:
- Azure AD Connect synchronizes users from AD to Azure AD
- This synchronization process includes email-relevant fields (so these must be maintained in on-premises AD)
The maintenance of the email-relevant fields in the AD may only be carried out via an Exchange Server.
This is how Microsoft ensures that all mailboxes have clean metadata. If, for example, a conversion from user mailbox to shared mailbox (functional mailbox) takes place, a handful of fields must be adjusted on this AD account. Doing this via the Active Directory Users and Computers console would be theoretically possible, but it may only be done via an Exchange Server, since Microsoft sets internal IDs and parameters. This logic would have to be completely rebuilt in manual processes and is therefore very error-prone. For this reason, Microsoft has so far strictly prescribed the use of an Exchange Server for these use cases. If an error occurs and no Exchange Server is available, Microsoft may refuse support.
The practice – creative chaos
In reality, different more or less creative scenarios have developed:
- Exchange Management Server (patched or unpatched) for mailbox maintenance
- Continued operation of Exchange Hybrid although this would not be necessary (because all mailboxes have been migrated to the cloud)
- 1 or more Exchange servers shut down by default and started maximum 1x per week, or in support case to satisfy Microsoft
Dismantling of all Exchange servers (against Microsoft’s rules) for fear of Hafnium and maintenance via Active Directory Users and Computers
The Hafnium incidents in particular have stirred up fear among many customers – it is often forgotten that hafnium is not an Exchange problem in the true sense of the word, but rather the relentless exposure of step-motherly change and update processes. Exchange was only a very prominent example here. Other systems like WordPress, Typo3 and other well-known ones are also vulnerable if not patched. Exchange Online is always patched up-to-date – that’s why it was not affected.
The solution – shut down Exchange in a supported way
Nevertheless, it is always a good idea to reduce systems in order to provide attackers with less surface area. Microsoft now offers for the first time (after many years of waiting) finally a solution to remove the local Exchange servers completely from the environment. Microsoft announced this solution in an article in the Techcommunity.
Microsoft is changing the support cycle of the updates for Exchange – to H1 and H2 (i.e. only 2x per year cumulative updates instead of the previous 4x CUs). Since Exchange 2016 will soon no longer be in mainstream support, this means that the current CU will be the last. Because according to the new update philosophy, the H2 update will in all likelihood be released when mainstream support has run out. Microsoft already writes this quite final in its announcement:
The next CU will be released in H2 of 2022, and it will be for Exchange Server 2019 only; mainstream support has ended for Exchange Server 2013 and Exchange Server 2016. We will release SUs as needed while those versions are in extended support.Quelle: Released: 2022 H1 Cumulative Updates for Exchange Server – Microsoft Tech Community
At first glance, this sounds like very bad news, because Exchange 2019 has never been available as a free server license in the hybrid network until now. But Microsoft has a solution for this as well:
Exchange Server 2019 will be available for free: “We have updated our licensing to add a product key for Exchange 2019 hybrid servers at no additional charge!“Quelle: Released: 2022 H1 Cumulative Updates for Exchange Server – Microsoft Tech Community
Management without Exchange Server? How does it work?
Microsoft offers a simplified version of Exchange Management Tools with the Exchange Server 2019 CU12 update. Simplified means: any GUI has been removed and the management unit has been reduced to PowerShell. Using these management tools in this way allows the ‘legal’ shut down of the last Exchange Server for the first time. Furthermore, this CU brings some commands that simplify the management of the hybrid agent. Likewise, there is now a complete decommissioning guide for Exchange Hybrid. So it can no longer happen in environments that have swung to cloud-only that settings are forgotten.
It is important to remember that the last Exchange Server must not be uninstalled! It may only remain permanently switched off. It is recommended that the server is briefly booted, patched and then switched off again at regular intervals of a few weeks. This also ensures that the AD computer object remains intact. Should the Exchange Server be put back into operation one day, you have already created a solid foundation in this way.
Microsoft has also made this clear in this article. Uninstalling the last Exchange Server is not a good idea, because it removes important information from the AD, which is important for the synchronization of users:
DO NOT uninstall the last server. You can choose to shut down the server, and use the script to clean up, but DO NOT uninstall. Uninstalling the server removes critical information from Active Directory that breaks the ability of the management tool package to manage Exchange attributes.Quelle: Manage recipients in Exchange Server 2019 Hybrid environments | Microsoft Learn
Advantages and disadvantages
The biggest advantage is clearly that the entire maintenance effort for an Exchange server is eliminated after shutting down. Superfluous hybrid configurations can be dismantled. However, it still requires a replacement for SMTP routing. Multifunction printers and third-party applications need to be able to send email. So this could mean shutting down an Exchange server requires new infrastructure components for SMTP.
The reduction from ECP to PowerShell means a significant step backwards for non-script-savvy admins. So for these cases own interfaces have to be developed.
In principle, the ability to shut down Exchange is a great thing, as many or all previous attack surfaces from inside or outside are closed. However, automation or script knowledge needs to be boosted among administrators. Our PowerShell courses are a suitable start here. We also assist you in planning the update to Exchange 2019 and decommissioning of your Exchange Server(s):