Exchange Server July 2026 SU: What Breaks and How to Fix It Fast

The July 2026 Security Update for Exchange Server has a documented failure mode: after the update installs and the server reboots, every Microsoft Exchange service is disabled. The update reports success. The server comes up silent.

A Microsoft engineer acknowledged the issue on Reddit. Community reports show it affecting Exchange Server 2019 (SE) across different deployment methods, and administrators have observed the same pattern appearing in multiple consecutive monthly SUs, not only July 2026.

Here is the complete recovery sequence.

Pre-Update Checklist: Do This Before the Next SU

Prevention is faster than recovery. Before installing any Exchange Security Update:

1. Take a VM checkpoint or a full backup
2. Open an elevated PowerShell prompt and run:


   cd "$env:ExchangeInstallPath\Bin"
   .\ServiceControl.ps1 Save
   ``
   This saves the current state of all Exchange services to XML files in C:\ExchangeSetupLogs. If services go sideways after an update, these files let you restore the exact pre-update configuration automatically.
3. If you run a Database Availability Group (DAG), update DAG members one at a time. Never update all nodes simultaneously.
4. Consider deploying Exchange SUs manually from an elevated command prompt rather than through WSUS. Community reports suggest WSUS-deployed SUs may correlate with higher failure rates.
Symptom 1: All MSExchange Services Are Disabled After Reboot
This is the primary failure reported across the July 2026 SU threads.
The Fast Fix
If all Exchange services are disabled after reboot, the quickest recovery is a single PowerShell command run from an elevated session:


Get-Service MSExchange | Set-Service -StartupType Automatic

Then restart the server. This re-enables every MSExchange service and sets them to start automatically. After the reboot, verify with:

Get-Service MSExchange

Note: this command affects all MSExchange services. If you do not use IMAP or POP, those services will also be enabled, which may not be desirable from a security standpoint.
The Thorough Fix: ServiceState.xml
The proper recovery path uses the saved service state from before the update. Exchange stores a ServiceState.xml file in C:\ExchangeSetupLogs that records the pre-update service configuration.

If the file exists, run:

cd "$env:ExchangeInstallPath\Bin"
.\ServiceControl.ps1 AfterPatch

This reads the saved XML and restores services to their pre-update state automatically.
If the file is missing (because you did not run ServiceControl.ps1 Save before the update), you can pull the XML files from an identically configured DAG member if you have one, or configure each service manually.

The Microsoft Docs page for this issue: https://learn.microsoft.com/en-us/troubleshoot/exchange/client-connectivity/exchange-security-update-issues#services-dont-start-after-su-installation
Related Services to Check
Beyond MSExchange services, also verify these are not stuck in a disabled state:

*w3svc - World Wide Web Publishing Service (required for OWA and ECP)

was - Windows Process Activation Service (dependency for w3svc)


Run:

Get-Service w3svc, was, MSExchange

If any are disabled, re-enable them before expecting full Exchange functionality.
Symptom 2: Hybrid DAG Replication Issues
After the July 2026 SU, Database Availability Group replication between DAG members can fail or suspend.
After updating a DAG node:
1. Confirm the node is back online and all services are running
2. Check DAG replication health:
   `
   Get-MailboxDatabaseCopyStatus
   `
3. If replication is suspended or shows a failed status, reseed the affected database copy:
   `
   Update-MailboxDatabaseCopy -Identity  -SourceServer  -DeleteExistingFiles
   `
   This can be time-consuming on large databases. Do not skip it.

Update passive DAG members first. Let them fully recover and confirm replication is healthy before updating the active node.
Symptom 3: Out-of-Office Messages to External Recipients Stop Working
Multiple administrators reported that after the July 2026 SU, out-of-office (OOF) messages to external recipients stopped routing. Internal OOF worked fine. External OOF did not arrive.
This is a transport service dependency. When MSExchange services start disabled, the transport service (MSExchangeTransport) does not start, which breaks outbound mail flow, including automated out-of-office replies.
After restoring services, test external OOF manually:
1. Sign in to OWA
2. Create an OOF rule targeting External recipients
3. Send a test message from an external account and verify the OOF reply arrives
If external OOF still does not work after services are restored, confirm the transport service is running and check send connector configuration in the Exchange admin center.
Symptom 4: Hybrid Connection to Exchange Online
If your Exchange environment uses hybrid configuration with Exchange Online, service disruptions can break the bidirectional sync that keeps hybrid mode working.
After recovering services:
1. Confirm the MSExchangeADTopology service is running (required for hybrid topology discovery)
2. Check hybrid inbound and outbound connectors in the Exchange Online admin center
3. Test mail flow between on-premises mailboxes and Exchange Online recipients in both directions
4. If the hybrid connection does not restore, run:
   `
   Get-HybridConfiguration
   `
   and re-run the Hybrid Configuration Wizard if needed

Post-Recovery Validation
Run Microsoft Exchange Server Health Checker after any SU-related incident:

.\HealthChecker.ps1


This validates CPU, memory, database availability, authentication, and service health. Run it from an elevated Exchange Management Shell on the affected server.
Also manually test:

OWA and ECP access
Mail flow to internal and external recipients
Mobile device sync (ActiveSync)
External out-of-office replies
Hybrid mail flow if applicable
DAG replication status

When Mail Flow Disruptions Affect DMARC
Here is the DMARC connection that is easy to miss during incident recovery. When Exchange services are down or mail flow is disrupted, legitimate outbound mail can arrive at receiving servers without the expected authentication headers. Receiving servers then report these as DMARC alignment failures in their aggregate reports.
If you use DMARCFlow to monitor aggregate reports, check your data after recovering from an SU incident. A spike in DMARC failures that coincides with the SU installation window is typically expected and does not indicate a misconfiguration. The real value of monitoring during this window is confirming that DMARC alignment is restored as soon as mail flow is operational again, rather than discovering weeks later that something still is not working correctly.
FAQ
*Can I deploy the July 2026 SU through WSUS safely?

Community reports suggest deploying Exchange SUs through WSUS may correlate with higher failure rates. Microsoft has not formally restricted WSUS deployment, but many administrators recommend running the SU installer directly from an elevated command prompt instead. Either way, always run ServiceControl.ps1 Save before the update and have a rollback plan ready.

What is the ServiceState.xml file and why does it matter?

Before every Exchange SU, the installer saves the current service state to ServiceState.xml in C:\ExchangeSetupLogs. After a failed or problematic SU installation, this file lets you restore services to their pre-update configuration automatically using .\ServiceControl.ps1 AfterPatch. Without it, you must manually re-enable every disabled service. Always run Save` before an update.

Should I update DAG nodes one at a time or simultaneously?

One at a time. Update passive DAG members first, confirm they recover and replication is healthy, then update the active member. Updating all nodes simultaneously risks losing quorum and causing replication conflicts that are harder to resolve.

How do I confirm my hybrid connection to Exchange Online is working after the SU?

Test mail flow in both directions. Send from an on-premises mailbox to an external address and vice versa. Check the Exchange Online admin center for hybrid connector status. If issues persist, re-run the Hybrid Configuration Wizard.

Why are out-of-office messages to external recipients failing after the SU?

The transport service (MSExchangeTransport) must be running for outbound mail to leave the Exchange server. When all MSExchange services are disabled after the SU, the transport service does not start, and external OOF routing breaks. Restoring services fixes this in most cases.

Does this SU affect DMARC authentication for my outbound mail?*

During the window when services are down or mail flow is disrupted, legitimate outbound mail may not carry proper authentication headers, which can cause temporary DMARC alignment failures in receiving server reports. This is expected during an incident and typically resolves once services and mail flow are fully restored. Check your aggregate reports after recovery to confirm alignment is back to normal.