The symptom
Mail flow stops. In the Services console, the Microsoft Exchange Active Directory Topology service (MSExchangeADTopology) is stuck starting, restarting, or failing outright — and because nearly every other Exchange service depends on it, they're all down too. The application log fills with MSExchange ADAccess events reporting that topology discovery failed; the classic signature is error 0x80040a02 (DSC_E_NO_SUITABLE_CDC) — Exchange telling you, in its way, that it looked for a domain controller it was willing to talk to and found none.
The confusing part is the timing. Nothing about Exchange changed. What changed was the directory underneath it: somebody promoted a shiny new Windows Server 2025 domain controller — a routine AD refresh, on paper — and possibly demoted the older DCs it replaced.
What's actually happening
Exchange doesn't just "use" Active Directory; it continuously discovers and binds to specific domain controllers and global catalog servers through its topology service, and it is opinionated about which directory servers it supports. That support is defined per cumulative update, not per product version — a distinction that routinely surprises even experienced administrators.
When the only reachable global catalogs are running a DC operating system newer than the installed CU supports, topology discovery has nowhere valid to land. The result looks like a catastrophic Exchange failure, but Exchange is behaving exactly as designed — the environment walked out from under it.
The matrix that matters
As of this writing, support for Windows Server 2025 Active Directory servers looks like this:
| Exchange version | WS2025 DCs supported? | Notes |
|---|---|---|
| Exchange Server SE | Yes | Current product; the supported destination |
| Exchange 2019 CU15 | Yes | 2025 H1 CU; also required for hybrid configurations |
| Exchange 2019 CU14 | Yes | Validated retroactively by Microsoft alongside CU15 |
| Exchange 2019 CU13 and earlier | No | The trap: topology discovery failures against 2025-only GCs |
| Exchange 2016 (any CU) | No | Supports nothing newer than Windows Server 2022 DCs |
Three adjacent facts complete the picture. First, Exchange 2019 and 2016 both reached end of support on October 14, 2025 — if you're reading this from either, the destination is Exchange Server SE, not another CU. Second, read-only domain controllers and read-only global catalogs have never been supported by Exchange at any version. Third, in-place upgrading the operating system underneath an installed Exchange server (say, 2022 → 2025) is not supported either — new OS means new server.
Getting out of the hole
If you're in the outage right now, the priority is mail flow, not architecture. In order:
- Give Exchange something supported to bind to. If the pre-2025 domain controllers still exist, ensure at least one is online, reachable, and advertising as a global catalog. If they were demoted, promote a supported-OS DC (Windows Server 2022 is the safe choice) and make it a GC. This is the fastest route back to running services.
- Restart the topology service and watch it bind. Once a suitable GC exists, restart
MSExchangeADTopologyand confirm in the ADAccess events that discovery now succeeds, then bring up dependent services. - Only then plan the real fix. Get Exchange to a CU/version that supports your directory's future — which today means Exchange Server SE — before the next DC refresh, not after.
Resist the temptation to "fix" a live outage by hastily demoting the new 2025 DCs, especially if FSMO roles already moved to them. Adding a supported GC is additive and low-risk; unwinding role holders under pressure is neither.
The traps around the trap
Even on a supported CU, the 2025-era directory has sharp edges worth knowing before you touch schema:
- Schema Master on WS2025: Microsoft's guidance is that a Windows Server 2025 DC holding the Schema Master FSMO role must have the November 2025 (or later) cumulative update installed before running any Exchange
PrepareADoperations, to avoid Active Directory replication issues. Check patch level before you prep, not after. - Functional levels are a separate axis. Windows Server 2025 introduces the first new forest/domain functional level since 2016. Raising it is a different decision with its own compatibility blast radius — don't bundle it into a DC refresh by reflex.
- Multi-NIC Exchange servers hide their own DNS traps — a story with its own failure signature, and its own field note (coming soon).
The lesson
A domain controller promotion is an Exchange change, whether or not anyone tells the Exchange administrator. Any system that binds to the directory inherits every OS decision you make about the directory. Before promoting a new-OS DC into an environment that runs Exchange — or anything else with a supportability matrix — the checklist is short: confirm the installed CU against the matrix, confirm where FSMO roles will live, and keep at least one supported-OS global catalog online until everything bound to the directory has been verified against the new one.
Boring, five-minute checks. We've watched the alternative cost days.