Exchange hybrid today: what the on-premises server still does and how to do without it
Every mailbox moved to Exchange Online long ago, yet one or two Exchange servers are still running on premises. Nobody is quite sure whether they are still needed. These exposed servers, highly privileged in Active Directory and sometimes poorly patched, are among the risks we report most often.
Why the server stayed
When users are synchronised from Active Directory, their mail attributes (addresses, aliases, proxies) are managed in AD rather than in Exchange Online. For years, Microsoft only supported changing them through the tools of an on-premises Exchange server. Hence the widespread advice: "keep one Exchange server for recipient management".
Other uses then crept in: SMTP relay for printers, applications and scanners, coexistence during migration, public folders, and even inbound mail flows that still pass through the premises. Each must be identified before any decision is made.
A high-risk server
An on-premises Exchange server combines several risk factors:
- exposure: it is often published to the internet, and Exchange has been hit by critical, widely exploited vulnerabilities in recent years;
- privileges in AD: installing Exchange grants extensive rights over the directory; depending on the permissions model and the updates applied, compromising the server can lead to control of the domain;
- link to the cloud: the hybrid configuration establishes a trust relationship with Exchange Online, which must be configured correctly;
- lifecycle: older versions no longer receive security updates; check the installed version and its support status.
Hybrid configuration. Microsoft has changed the architecture of the hybrid relationship, notably by requiring a move to a dedicated application in Entra ID instead of the shared service principal. If your configuration is several years old, check that it follows current guidance.
Managing recipients without an Exchange server
Microsoft now supports a scenario in which, once all mailboxes have been migrated, recipients are managed using the Exchange management tools and their PowerShell module, installed on an admin workstation or server, with no Exchange server running. The conditions are precise: tool version, schema extension, required permissions, and a documented procedure for shutting down the last server that differs from a simple uninstall. Follow the current official documentation, as a standard uninstall can remove configuration you still need.
The device hosting these tools writes to AD: it must be treated as an admin workstation, and recipient management roles delegated sparingly.
The path to removing the server
- Inventory the flows: analyse transport and connection logs to find everything still using the server.
- Replace SMTP relay: authenticated submission to Exchange Online, a dedicated connector for devices, or a separate relay service.
- Check DNS: MX and Autodiscover records pointing to Exchange Online, SPF up to date.
- Deal with residual cases: public folders, mailboxes still on premises, applications using Exchange web services.
- Switch management to the management tools, then shut the server down following the official procedure.
- Clean up: internet publishing, firewall rules, certificates, service accounts, and a review of the permissions granted in AD.
If the server has to stay
Some organisations keep a server for legitimate reasons. It must then be a supported version, patched promptly, not published to the internet unless it needs to be, protected by an EDR, hardened, and treated as a Tier 0 system until its AD permissions have been reduced.
What an audit checks
- The version of the Exchange servers and their patch level.
- Their internet exposure and the services published.
- The permissions granted to Exchange in AD and the permissions model in place.
- Whether the hybrid configuration matches current guidance.
- The flows the server actually handles and the feasibility of removing it.
- Protection of the device hosting the recipient management tools.