Sixteen months ago, HAFNIUM was reading mailboxes through four chained Exchange bugs before Microsoft had a patch ready. We spent March and April of 2021 on incident response for clients who got hit and remediation planning for the much longer list who were exposed but hadn't been — yet. That work should have ended with a decommissioned on-premises Exchange server. For a working majority of the hybrid estates we still touch, it hasn't.
What we find in July 2022, more than a year after ProxyLogon, isn't the on-prem Exchange server surviving as a primary mail platform — that argument is settled. It's the on-prem Exchange server surviving as forgotten infrastructure: still reachable from the internet, still running whatever Cumulative Update it happened to be on when the migration project got marked complete, and still justified with the same sentence every time we ask about it. We only keep it for recipient management.
That sentence is carrying weight it can't support. This note is about what that last Exchange server is actually doing in a hybrid estate, why "temporary" hybrid keeps not ending, and the sequence we run to get a client off that box — without breaking mail flow, free/busy, or the helpdesk's Monday morning.
The alibi: why the last Exchange server never gets decommissioned
Nobody budgets a project called "decommission the Exchange server." It dies by a thousand small deferrals instead. The migration project that moved mailboxes to Exchange Online had a hard deadline and an executive sponsor; the cleanup afterward has neither. The person who understood the transport rules and the connector configuration has usually moved to a different role or a different employer. And the server itself keeps doing something, however small, which means turning it off is a change with a blast radius nobody wants to own on a Friday.
The something is usually one of three things: a handful of line-of-business applications relaying scanned documents and reports through SMTP, a set of AD-sourced distribution groups and mail-enabled security groups edited a few times a year, or the belief — not always tested — that Exchange hybrid free/busy and mail flow still depend on it. We've inherited all three in the same estate more than once. What we rarely inherit is documentation of which one is actually load-bearing, which is exactly why nobody will sign off on removing it.
A regional bank we assessed this spring had an Exchange 2013 server, still domain-joined, still with Outlook Web App and the Exchange admin center published to the internet through an ancient reverse-proxy rule, whose only surviving job — as far as anyone still on staff could tell — was accepting anonymous SMTP relay from branch copiers doing scan-to-email. Nobody had looked at it since a 2018 mailbox migration. It had never been on the patch list because it wasn't "in scope" for anything. That is the profile we see repeatedly: not a server anyone is actively defending, a server everyone has quietly agreed not to ask about.
Recipient management doesn't require what people think it requires
The most durable version of the alibi is legitimate on its face: if your identity source is on-premises Active Directory synchronized through Azure AD Connect, Microsoft's supported position is that you keep at least one Exchange server on-premises to manage mail attributes on synced objects — distribution groups, mail-enabled security groups, remote mailboxes, address book policies. Editing those attributes directly in Active Directory Users and Computers or through ADSI Edit is unsupported and breaks the next directory sync. So the requirement is real.
What isn't required is everything else that server is usually still doing. Recipient management needs Exchange Management Shell reachable to whoever runs Set-RemoteMailbox, Set-DistributionGroup, and Set-Mailbox against synced objects. It does not need Outlook Web App published externally. It does not need the Exchange admin center reachable from the internet. It does not need to accept inbound mail at all if you've moved transport to Exchange Online with the on-prem server out of the mail path. Most of the servers we find still have all of that switched on because nobody revisited the virtual directory configuration after the mailbox moves finished — the defaults from setup never got narrowed.
| Function people assume needs the on-prem server | Actually true in mid-2022 | Where it belongs instead |
|---|---|---|
| Editing distribution groups / mail attributes | Yes, if AD is the identity source | Exchange Management Shell, internal only |
| Outlook Web App / ECP for end users | No | Exchange Online has owned this for years |
| Inbound internet mail flow | Usually no | Exchange Online Protection / connectors |
| Free/busy and hybrid mail routing | Only via HCW-configured endpoints | Hybrid Agent, not a firewall hole |
| SMTP relay for scanners and apps | No, but rarely migrated | Exchange Online direct send or a dedicated connector |
Once a client sees that table applied to their own environment, the recipient-management argument changes shape. Keep the server — but keep it dark. No external OWA, no external ECP, internal-only Exchange Management Shell access, and a firewall rule that starts with deny.
Patch cadence reality: the CU treadmill nobody budgeted for
Here's the part that turns a forgotten server into an active liability: Exchange security updates only install against the two most recent Cumulative Updates for a given version. A server three or four CUs behind — which describes most of what we find — cannot take the security update until it's brought current, and a CU upgrade is not a patch; it's a full version upgrade with its own testing cycle, schema changes, and maintenance window. That's exactly the gap ProxyLogon and, a few months later, ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) rode in on. Plenty of the organizations mass-exploited in that ProxyShell wave weren't negligent; they were behind on Cumulative Updates, and the fix genuinely would not apply to their build.
2022 hasn't been quiet. Patch Tuesday has kept shipping Exchange fixes on a steady cadence, including another remote-code-execution advisory in February (CVE-2022-23277), and every one of them carries the same prerequisite: get current on CU first, then take the SU. We opened this year firefighting a different Exchange failure — the January 1 transport-queue freeze caused by a date-format overflow in the FIP-FS malware-scanning engine, which stopped mail flow across on-premises Exchange 2016 and 2019 servers worldwide the moment the calendar rolled over. Different bug class, same lesson: the team that spent New Year's Day rerouting transport queues is the same team we're now asking to schedule a decommission. Understandably, it isn't top of mind.
We run the Exchange Server Health Checker script against every hybrid server we touch before any other conversation happens. It flags CU currency, TLS configuration, .NET Framework version, and a handful of other things that quietly disqualify a server from taking the next fix.
# Baseline before anything else - build, CU currency, and what's published externally
Get-ExchangeServer -Identity EXCH01 | Select-Object Name, Edition, AdminDisplayVersion
Get-OwaVirtualDirectory -Server EXCH01 | Select-Object Identity, InternalUrl, ExternalUrl
Get-EcpVirtualDirectory -Server EXCH01 | Select-Object Identity, InternalUrl, ExternalUrl
.\HealthChecker.ps1 -Server EXCH01
If the external URL fields come back populated and the build is more than one CU behind current, we already know the shape of the next conversation.
The Emergency Mitigation service, Autodiscover, and what still needs unplugging
Microsoft's own response to the patch-cadence problem was the Exchange Emergency Mitigation service, shipped as a default-on Windows service in the current Cumulative Updates for 2016 and 2019. It phones home to a Microsoft-hosted mitigation feed and applies interim defenses — IIS URL Rewrite rules, module disabling — for newly disclosed vulnerabilities automatically, without waiting for an admin to test and install a Cumulative Update. It's a genuinely useful backstop, and we leave it enabled everywhere. It is not a substitute for patching. It buys days, sometimes weeks, at the cost of some functionality, and it depends on the IIS URL Rewrite module already being installed and the server reaching Microsoft's feed — plenty of locked-down networks block exactly that outbound path. Check it; don't assume it.
The same "still exposed to more than you think" theme showed up last September in independent research on Autodiscover's domain fallback behavior: when the primary Autodiscover DNS lookup fails, Outlook clients progressively try shortened parent-domain variants, which meant credentials could leak in plaintext to whoever happened to own a domain like autodiscover.com. Anyone relying on default Autodiscover discovery rather than an explicit SRV or CNAME record inherited that exposure regardless of their own server's exposure. It's a client-side behavior, not an Exchange server bug, but it belongs in the same bucket as everything else here: old decisions nobody has revisited.
The decommission sequence that actually ships
We do not sell "decommission the Exchange server" as a project on its own; it never gets funded that way. We attach it to whatever is already moving — a security assessment, a Conditional Access hardening program, a tenant consolidation — and run the same five steps regardless of what triggered it.
First, inventory what actually touches the server: send and receive connectors, virtual directory external URLs, certificate bindings, any LOB app referencing its hostname by IP or FQDN. Second, move mail relay use cases off it deliberately — Exchange Online direct send for simple application relay, a dedicated authenticated connector for anything that needs DSN handling or larger volume. Third, replace the Hybrid Configuration Wizard's inbound firewall dependency with the Hybrid Agent, which runs outbound-only and removes the reverse-proxy rule that made ProxyLogon reachable in the first place — worth doing on its own. Fourth, null the external URLs on OWA, ECP, and EWS, and confirm at the firewall — not just in Exchange configuration — that nothing external reaches port 443 on that box. Fifth, get current on Cumulative Update and keep it there, because "we're about to decommission it" has been true in some of these estates for three years running, and the server does not get a patching exemption for good intentions.
# Stop publishing management surfaces externally once relay and recipient-management
# dependencies have been moved off - do this before you touch the firewall rule
Set-OwaVirtualDirectory -Identity "EXCH01\owa (Default Web Site)" -ExternalUrl $null
Set-EcpVirtualDirectory -Identity "EXCH01\ecp (Default Web Site)" -ExternalUrl $null
Get-SendConnector | Select-Object Name, SourceTransportServers, AddressSpaces
Get-ReceiveConnector | Select-Object Name, Bindings, RemoteIPRanges
A state agency we worked with this year found forty mail-enabled security groups whose owning application team no longer existed, all edited maybe twice a year from that same Exchange admin center. None of that justified leaving the console reachable from the internet. It justified writing down who's allowed to run Set-DistributionGroup and from where.
If you're facing this
If your hybrid estate still has an Exchange server nobody wants to touch, start with the Health Checker output and an honest inventory of what's actually load-bearing versus what's habit. Most of what we find doesn't need a migration project — it needs three afternoons and a firewall change control someone's willing to sign. Tell us what's still running and what it's plugged into; we'll help you figure out which parts are real.