Why can’t you remove the last Exchange Server?

So, you’ve completed your migration to Exchange Online. Email flows smoothly into and out of the cloud, and all your mailboxes are now online. What’s next for your Exchange Servers, now that you’ve made the transition?

After completion you will have several tasks to perform to remove Exchange Servers from your environment, but there is one important caveat you need to know about; if you run Azure AD Connect then you can’t remove every Exchange Server from your environment. You will need to keep at least one around for management purposes. In this article, I’ll walk through what you can do to minimize what you keep and need to maintain, and what you can consider planning for in the future. You can also join me at TEC this week, on September 2nd.

Read more: Microsoft Patches Four More Exchange Server Vulnerabilities as the FBI Moves to Clean Infected Servers

If you run Azure AD Connect, you need Exchange for recipient management

At the time of writing (August 2021), Microsoft still haven’t removed the need to keep at least one Exchange Server around after migrating to Exchange Online – if you plan to still run Hybrid Identity.

This is because when you run Hybrid Identity, your on-premises Active Directory Forest and Domains remain the source of truth for objects that are synchronized to Azure Active Directory (Azure AD). Azure AD is the directory that Microsoft 365, including Exchange Online uses, and almost all attributes that are synced from your local AD are read-only in Azure AD and must be set and edited locally.

That means that when you create a new user account, you must create the user account in your local Active Directory. After creating the new user account, Azure AD Connect will run a synchronization job and see a new user account, and then create a new synced account in Azure AD. The new Azure AD account will be linked back to that account and if it’s missing vital attributes, you won’t be able to use the online tools, like the Exchange Admin Center, to fill in missing values or update values.

Your local Active Directory management tools aren’t designed to manage Exchange attributes, and whilst you can technically set Exchange-specific attributes using Active Directory Users and Computers (via the attribute editor), ADSIEdit.msc or by using PowerShell scripting, Microsoft do not support manually editing the attributes. Microsoft clearly state that you must use an Exchange Server, if you want the option of phoning up Microsoft for support:

There are good reasons why Microsoft have made this statement. Firstly, Microsoft have committed to providing a solution for removing the last Exchange Server from your environment, but as it’s a reasonably complex problem that needs to account for the needs of small, medium and large organizations, then providing a one-size fits all solution will be difficult. Solutions like cutting off the sync of Exchange attributes have been suggested in the community, but would result in stale and out of date data in AD; complex solutions for write-back or co-ordinated changes aren’t practical in many enterprise environments that are regulated, nor are suitable for smaller customers. And simply providing a set of PowerShell scripts to replace Exchange Management tools could work for some organizations, but would be too complex for smaller organizations to manage.

If you do choose to go it alone and remove the last Exchange Server there is another risk; that when Microsoft do provide a solution, whatever you’ve done yourself will break. This is because Microsoft have suggested the solution might require an update before removal can take place:

Finally, it’s reasonably rare to find either a third-party tool or scripts that a consultant or IT administrator have provided that sufficiently cover the same functionality as the Exchange Admin Center or Exchange Management Shell. Remember that the configuration stored and used within the local Active Directory includes several areas directly related to ongoing recipient management in Exchange Online:

• Remote Mailbox management for users, shared mailboxes and archives (i.e. management of the AD attributes linked to your mailboxes in Exchange Online)
• Mail User management
• Mail Contact management
• Mail-Enabled Security Group management
• Distribution Group management
• Accepted Domain and Remote Domain management
• Email Address Policy management and updates
• Autodiscover Service Connection Point management

Even when I’ve seen reasonably comprehensive scripts aimed at managing this, these don’t always provide the same validation functionality that the Exchange tooling does; for example – ensuring address uniqueness and RFC compliance when altering proxy addresses and the primary email address, or following the same logic when applying changes to Email Address Policies. Because scripts or tools are acting directly against Active Directory (which has little knowledge of Exchange) you can create scripts that make changes that would not be valid if performed through the Exchange tooling.

As Microsoft state – it is possible to examine everything Exchange does with regards to recipient management, but it is at your own risk. However as time goes on, and the risk of running Exchange on-premises appears to increase – there may be a time when the Microsoft 365 community of IT pros (and Microsoft MVPs like myself) weigh up the risks collectively and provide a solution. Right now though it’s not yet the time.

If you relay SMTP email on behalf of legacy application servers

The best thing you can do is upgrade line-of-business applications to their respective vendors’ SaaS equivalents or at the very least, upgrade to versions that have native support for Microsoft 365 and Exchange Online. There should be no vendor worthy of respect that appears to be confused by a request to configure their software so that it can send email directly using Exchange Online.

Such applications should not need to use an on-premises mail server to relay outbound mail to or through Exchange Online in 2021; Exchange Online has been around for ten years. And those vendors should not be shocked or confused that simply using authenticated SMTP with Exchange Online won’t be enough either; Microsoft announced in September 2019 (almost three years ago) that legacy authentications will no longer be supported in due time, and announced support for OAuth 2.0 with SMTP around 18 months ago. A vendor that has asked it’s development team to spend an hour looking into what they should do will have fast arrived at the conclusion that they should use Microsoft Graph to submit email messages, and build their integration in a way that doesn’t require a username and password to be stored and works seamlessly in environments that leverage Conditional Access policies and Multi-Factor Authentication. If your vendor claims they haven’t been asked if their application can work properly with Microsoft 365, then you should be suspicious, unless you are their only customer.

Unfortunately, getting on a call and grandstanding with the vendor won’t solve the fact they’ve done little except collect recurring revenue from you to support their solution. And if, like many organizations, you run tens of applications like this or have in-house bespoke applications relied upon that were created by developers who’ve long since left the business, you might find yourself in a difficult position.

That position is often one where you need to be able to accept unauthenticated, insecure SMTP messages and relay them either outbound through Exchange Online to your customers or to employee mailboxes. In that case, then the simplest option often is to continue to run several Exchange Servers, utilizing a copy of your existing relay receive connectors. As you’ve read above, you need the servers for ongoing management – so it often makes sense.

Recommendations for the “last Exchange Server”

Assuming you aren’t moving to cloud-only identities and removing Active Directory today (which some organizations are) then you are keeping Exchange running on premises. What this needs to be depends somewhat on your organization, but should be guided by several principles:

• The server(s) required to run Exchange Hybrid functionality for management and SMTP relay purposes is unlikely to be the same specification you needed to host Mailboxes on, and can be a lower specification.
• The server(s) are typically is suited to run as a Virtual Machine on-premises or in a cloud provider, so long as core requirements for access to Active Directory are met with no firewall rules in-between.
• You only need to run Exchange Server 2016 on these servers. There is no benefit today in running Exchange Server 2019, except for the ability to run on Server Core and support in-place operating system upgrades, and the free Hybrid license is only available for Exchange 2016 and below.
• The specifications for the last Exchange Server can be lower than normal Exchange Servers. The minimum requirements for Exchange Server are not typically sufficient, but 2 to 4 virtual CPUs and 12GB RAM, with a minimum of 100GB of disk space often work well as a starting specification. If you expect significant SMTP relay traffic, then you should size the servers appropriately to ensure mail queue database size and logs are meet your requirements, and ensure you have sufficient disk space to keep extended logs for security investigation purposes.
• You should not need to expose HTTPS services to the internet, now you’ve migrated all mailboxes (and public folders) to Exchange Online. You will first move your Autodiscover records to point directly at Exchange Online, and set your Service Connection Point to $null; no clients should be accessing these servers.
• If you are relaying SMTP mail outbound only and not receiving mail back to on-premises or running centralized transport, then you should not need firewall rules to allow SMTP mail to be received inbound to these servers.
• You may choose to restrict HTTPS and other connectivity on your internal network to the Exchange Servers, now that no internal clients require access to Exchange On-Premises. If you need more than one Exchange Server to provide HA for SMTP relay, Load Balancing functionality will only be relevant for SMTP relay and not for HTTPS, as HTTPS access will only be used for IT administrator access from secured clients.
• Don’t run the Exchange Mailbox role on a server running other related services, such as on an Active Directory Domain Controller or Azure AD Connect server.
• You must keep the Exchange Servers up-to-date. This needs to be the latest update, or immediately previous update (i.e. you remain supported for the small duration of time, such as a week, that it takes to agree the change to perform the updates); furthermore you absolutely must apply security updates as soon as you can after they are released. Do this whether or not the servers are published to the internet; it is common for a low-privilege account to be compromised and this account used to explore your network to find opportunities to gain escalated privileges.
• Ensure logging capabilities on the servers are set so that you keep enough security and access logs so that you can investigate a security incident, should Exchange be subject to a zero-day threat again. If you have the capability, ensure logs are consumed by your SOC or SOC service and analyzed in real-time for threats.
• Ensure you are installing EPP and EDR software. Exchange admins have questioned in the past the validity of running Anti-Virus software on Exchange Servers because AV software can attempt to scan database files and cause issues. This only happens if you don’t specify the correct exclusions. EDR (Endpoint Detection and Response) software, like Defender for Endpoint has specific capabilities and recommendations for Exchange too, so if you have purchased these products, use them.

A future without Exchange Servers on-premises

However, as Microsoft do say they will have a solution coming for removing the last Exchange Server – and that, given Exchange has become a cybersecurity target – you might actually want to restrict access to Exchange Servers or potentially even switch them off when they aren’t being used for management. So if you need SMTP relay for legacy applications, multi-function copiers and don’t want to poke a bunch of outbound SMTP holes in your firewall for direct delivery to Exchange Online – what can you do?

Whilst we’d hope that Microsoft will provide some guidance when they do finally release a way to remove the last Exchange Server, there are several options you can consider; after all – we are only considering standards-compliant SMTP relay with a known configuration on the Exchange Online side that can accept TLS-secured messages from known IP addresses and certificates.

The first option is to consider using Exchange Servers running the Edge Transport role. This role can be installed without connecting to any local Active Directory domain on standalone servers within a perimeter network area like a DMZ. The Edge Transport role doesn’t install any HTTPS services, and has lower minimum hardware requirements. Edge Servers are supported in a Hybrid Deployment, but the model for a sans-Exchange future would mean this model was not applicable, as no Exchange 2016 Mailbox servers would exist to provide an EdgeSync relationship, and you would instead create Send and Receive connectors directly on each Edge Server. Microsoft’s licensing FAQ indicates that a hybrid mail flow scenario would cover Edge Transport servers, as particular roles are not specified, but it’s important to check with your Microsoft account manager that this applies to you. Otherwise, the Edge Transport role provides the same ability to maintain relay Receive Connectors and a Send Connector onward to Exchange Online using the same skills you have today, and fulfils the need to remove Exchange from the corporate network and Active Directory.

Other options include firstly, using Windows Server’s IIS SMTP functionality. This is a configuration that some organizations have used with success, but remember – this is very similar to the SMTP functionality long-term Exchange admins will remember from Exchange Server 2000 and 2003. If you are considering IIS SMTP for mail relay, then it’s likely that you are desperate for an option to use, and perhaps a non-Microsoft solution might be more appropriate that has ongoing development and support. Open Source mail servers, like Exim, Postfix and Sendmail are well documented and capable of sustaining extremely high mail flow loads. They often form the underpinnings of cloud-based mail filtering solutions – but they require skills to setup and do require checks and maintenance – a Unix, Linux or BSD-based server running a Mail Transport Agent still needs to be patched, and can still be compromised.

If you’ve read this far and are thinking “No thanks – I don’t want to manage SMTP mail relay on-premises” – then consider whether beginning those efforts to press your legacy application vendors into making their software relay mail properly with Exchange Online is energy better spent and will result in a solution you don’t have to maintain.

Join me at TEC this week

For more on removing the last Exchange Server, join me this week for TEC. I’m presenting “Removing the last Exchange On-Premises Server“ where I talk through the above – and much more. I’d love to see you there.