Exchange Cumulative Update: Current CUs & Install Order

Our Exchange Server patching support team installs cumulative updates as a standard change type. This page documents the current CU state per Exchange version, the difference between a CU and an SU, the install order with prerequisites, and the one fact that shapes every CU plan: a CU cannot be uninstalled back to the previous version.

CU vs SU: what each one is

An Exchange Cumulative Update (CU) is a full build of the product. Per the official upgrade documentation, each CU is a complete installation of Exchange that includes the updates and changes from all previous CUs — you never chain CUs, and you never install RTM first. Installing a CU is running Exchange Setup in upgrade mode; it replaces the binaries, can extend the Active Directory schema, and overwrites customized configuration files such as web.config and EdgeTransport.exe.config.

A Security Update (SU) is a patch installed on top of a specific CU baseline. It fixes the security vulnerabilities disclosed for that month plus those from prior SUs on the same baseline, and it does not change the CU level. SUs are small, install through Windows Update or a standalone package, and can be uninstalled. Microsoft also ships Hotfix Updates (HUs) through the same channel — same mechanics as an SU, non-security fixes.

Current CUs by version (verified August 2026)

The authoritative source is the Exchange Server build numbers and release dates page. The state as of this writing:

Two consequences of that table. First, Exchange 2016 and 2019 reached end of support on October 14, 2025; only organizations enrolled in the Extended Security Update program receive SUs after December 2025, and no new CUs will ever ship for either version. Second, Exchange SE RTM is code-equivalent to 2019 CU15 plus its updates — the in-place upgrade from 2019 CU14/CU15 to SE RTM is performed exactly like a CU install.

Release cadence: Microsoft ships CUs twice a year, labeled H1 and H2 (2019 CU15 was "2025H1"). Not every CU carries an AD schema change; the per-CU schema requirements are tracked on the AD schema changes reference.

Install order and prerequisites

The sequence below is the documented order for a CU on a production server. On a multi-server org, update Active Directory once, then servers one at a time — internet-facing (Client Access) servers first is the standard convention, and all DAG members should reach the same CU promptly because mixed-CU DAGs are only supported transiently.

1. Backup and evidence. Confirm a recent successful backup of mailbox databases and a system state backup of a domain controller (schema changes are forest-wide and permanent). Export any customized web.config / EdgeTransport.exe.config settings — the CU overwrites them.
2. Health check. Run the Microsoft-recommended HealthChecker script (aka.ms/ExchangeHealthChecker) to confirm the current build, pending reboots, and the installed .NET Framework version. The supported .NET version depends on the target CU — check the Exchange supportability matrix before Setup, because an unlisted .NET version is unsupported and a common cause of failed upgrades.
3. Prepare Active Directory (when the CU requires it; running it when not required is harmless). From an elevated prompt with Schema Admins + Enterprise Admins membership, on a machine in the same AD site as the schema master:

   Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareSchema
   Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD
   Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAllDomains

   Full permission requirements are in Prepare Active Directory and domains. Wait for AD replication before installing on servers.
4. Maintenance mode (DAG members). Before Setup runs on a DAG member, drain it and move active databases off, per the DAG maintenance procedure. The core step:

   Set-ServerComponentState MBX01 -Component ServerWideOffline -State Inactive -Requester Maintenance

   The documented procedure also drains transport, redirects queued messages, and suspends the node in the cluster; run the full sequence, not just this cmdlet.
5. Install the CU. Mount the CU ISO and run Setup in upgrade mode, elevated:

   Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade

   Microsoft's estimate is about 180 minutes per server. Do not interrupt Setup once it starts removing the old installation.
6. Post-checks. Restart the server (required). Re-apply the saved configuration customizations. Confirm the build with Get-Command Exsetup.exe or HealthChecker, verify services with Test-ServiceHealth, check OWA/ECP logins, then take the DAG member out of maintenance mode (-State Active) and rebalance databases.
7. Install the latest SU for the new CU. SUs are baseline-specific: after moving to a new CU, the SUs you had installed on the old CU do not carry over, so the current SU for the new baseline must be installed even if the CU shipped after that SU's release date.

No rollback: a CU cannot be uninstalled

If a CU install fails midway or the server misbehaves afterward, the recovery paths are, in order: re-run Setup to let it complete the upgrade (Setup is restartable from most failure points), run the SetupAssist script (aka.ms/ExSetupAssist) to diagnose the blocking condition, and — for an unrecoverable server — rebuild via Setup /m:RecoverServer on a clean OS install with the same server FQDN, then restore databases. There is no supported path that returns a server to the prior CU in place.

Common CU failure points

• Setup stuck or failed mid-upgrade. Usual causes: a pending Windows reboot, an unsupported .NET version, third-party services holding Exchange files, or insufficient AD permissions for a schema-bearing CU. Setup logs to C:\ExchangeSetupLogs; SetupAssist reads them and names the blocker. Re-running Setup after clearing the cause usually completes the upgrade.
• Services left Disabled after a failed install. Setup disables Exchange services during upgrade and re-enables them on success. A failed run leaves them Disabled; the fix is to complete the upgrade (re-run Setup), not to re-enable services by hand against half-upgraded binaries.
• OWA/ECP broken after the CU. Typically overwritten web.config customizations, a missing post-install reboot, or stale .NET compilation — recycling app pools and running UpdateCas.ps1 from the scripts directory are the documented first steps. If OWA broke after an SU rather than a CU, the usual cause is the SU having been run non-elevated.
• Server stuck in maintenance mode. Component states persist across reboots. If mail flow or client access is dead after an otherwise clean install, check Get-ServerComponentState before anything else.

Version-specific guides

This page is the version-neutral reference. For the legacy versions still running in the field, the step-by-step guides with per-version prerequisites and download links:

• Exchange Server 2016 CU and SU guide — CU23 baseline, ESU-era servicing.
• Exchange Server 2013 CU and SU guide — CU23 baseline, out of support; migration is the only patching strategy left.

When to hand it over

CU installs are long, irreversible changes with a schema step that touches the whole forest. The failure cases above are all recoverable when handled in the right order and expensive when they are not. Our team runs CU and SU cycles for customer Exchange orgs as scheduled maintenance — health check, schema prep, DAG-aware sequencing, post-checks, and the SU pass afterward — with an engineer on the console for the full window.