After installing an Exchange Server Security Update (SU), rerun Microsoft Exchange Server Health Checker, confirm every server is on a supported update level, and review any manual actions it reports. Then validate Extended Protection against your Exchange version and actual topology—especially TLS, IIS settings, load balancers, hybrid publishing, public folders, and third-party products. An installer reporting success is not a substitute for those checks.
This review follows Microsoft guidance current as of October 4, 2026. The correct actions depend on your Exchange build and environment; use Microsoft’s current instructions for the specific version and topology rather than applying configuration changes blindly.
As an Amazon Associate I earn from qualifying purchases.
Start by confirming what was updated
Build a per-server record of the Exchange edition and version, cumulative update (CU), SU build, server role and topology, installation result, and restart status. This catches a common blind spot: one server may have completed the update while another remains behind or needs a separate manual action.
Microsoft’s Exchange Server update FAQ recommends keeping Exchange supported and current, maintaining an inventory, applying released SUs, and using Health Checker to identify missing updates and manual actions. Available SUs depend on the CU and support status, so verify the current support and update guidance for each deployed version instead of relying on an old build list.
#1 Best Overall
Microsoft’s update guidance says to restart Exchange before and after installing updates, even if the installer does not request a restart afterward. Follow the procedure for the particular update and environment, and record whether the required restarts have occurred.
Rerun Exchange Server Health Checker
Run Microsoft Exchange Server Health Checker after each SU. Microsoft explicitly recommends running it again to find further actions that may be needed. Review the results for servers behind on CUs or SUs and for manual configuration actions; do not treat a successful setup message as the end of the review.
Health Checker and the Microsoft 365 admin center update-status preview serve different purposes. The preview provides aggregate counts and out-of-support status, but does not identify which individual servers are behind. Use server-level inventory and Health Checker results to locate and address specific systems.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsRank #2
| Tool | What it helps you see | Important limitation |
|---|---|---|
| Exchange Server Health Checker | Server-level update status and manual actions to review. | Review each server’s output and address the actions relevant to that environment. |
| Microsoft 365 admin center update-status preview | Aggregate update counts and out-of-support status. | It does not identify the individual servers that are behind, so it cannot replace server-level review. |
Microsoft says the Hybrid Configuration Wizard does not need to be rerun just because updates were installed. That does not remove the need to check hybrid-specific Extended Protection requirements if you use the Hybrid Agent.
Validate Extended Protection before changing it
Windows Extended Protection helps mitigate authentication relay and man-in-the-middle attacks by using channel-binding information, including Channel Binding Tokens associated primarily with TLS. It is not a universal switch: prerequisites and configuration depend on Exchange version, build, IIS virtual directories, authentication, and topology. Microsoft’s Exchange Server support guidance says support for Exchange 2013, 2016, and 2019 began with the August 2022 SU releases, subject to its prerequisites. Exchange 2013 reached end of support on April 11, 2023. Exchange Server 2019 CU14 and later setup enables Extended Protection by default.
Before enabling or changing Extended Protection, compare the environment with Microsoft’s current prerequisites. Check the following items together; a mismatch in one layer can cause connectivity or authentication problems.
- Exchange version and build: Confirm that the server meets the current version-specific requirements. Do not infer eligibility from the product name alone.
- IIS virtual directories and SSL flags: Microsoft’s configuration varies by virtual directory and calls for the
SSLandSSL128flags in the documented Extended Protection configuration. Validate every in-scope virtual directory rather than assuming an update preserved or reset the desired settings. - TLS consistency: Microsoft says TLS configuration should be consistent across Exchange servers. In its documented Extended Protection scenario, it specifies the registry values
SchUseStrongCrypto=1andSystemDefaultTlsVersions=1. Confirm that those settings apply to the server versions and Windows configuration in use before changing registry values. - NTLM: NTLMv1 is incompatible with Extended Protection and Microsoft describes it as weak. In the documented scenario, Microsoft recommends
LmCompatibilityLevel5 and says the value must be at least 3. Check relevant client, server, and Group Policy settings if users experience authentication prompts or failures. - Load balancer: Extended Protection is not supported with SSL offloading. SSL bridging can be supported when Exchange and the load balancer use the same SSL certificate. Verify what the load balancer actually does and which certificates it presents.
- Third-party products: Test compatibility before enabling Extended Protection. A proxy or antivirus product that intercepts connections can be blocked as a man-in-the-middle connection; confirm the intended configuration with the vendor if compatibility is uncertain.
- Public folders and coexistence: Microsoft warns about Exchange 2013 public folders and older Exchange 2016 or 2019 public-folder hierarchy hosts. Check which server hosts the hierarchy and meet Microsoft’s migration or upgrade prerequisites before enabling or changing Extended Protection.
- Hybrid Agent publishing: Incorrect configuration can disrupt hybrid features on servers published through the Hybrid Agent. Microsoft says not to enable Extended Protection on the Front-End EWS virtual directory for those servers.
Microsoft recommends the ExchangeExtendedProtectionManagement.ps1 script rather than manual IIS Manager changes because the configuration spans multiple locations and the script checks prerequisites. Use the latest script and follow its current instructions for your scenario, including any required exclusions. Do not apply a command or configuration change until you have verified the topology and prerequisites.
Choose the configuration route that matches the deployment
| Route | When it applies | What to verify |
|---|---|---|
| Exchange Server 2019 CU14-or-later setup | Setup enables Extended Protection by default on these builds. | Confirm the resulting configuration against current prerequisites, topology, and any applicable exceptions. |
| ExchangeExtendedProtectionManagement.ps1 | Microsoft’s recommended management approach for supported older configurations and multi-server changes. | Use the latest script and its current instructions; verify TLS, load-balancer behavior, third-party compatibility, and any Hybrid Agent or virtual-directory exclusions first. |
| Manual IIS Manager changes | Not Microsoft’s preferred method for this multi-location configuration. | Do not substitute ad hoc changes for the documented script and prerequisite checks. |
Check services, then troubleshoot the observed symptom
After the update and required restarts, check whether Exchange services and user-facing functions behave as expected. If something fails, use the Microsoft repair guidance that matches the actual error rather than applying a generic fix.
OWA or ECP returns HTTP 500 with a missing assembly error
Microsoft documents a specific post-update OWA/ECP HTTP 500 case in which authentication fails because the Microsoft.Exchange.Common assembly is missing. For that documented error, Microsoft’s resolution is to reinstall the SU from an elevated command prompt. This is a targeted remedy for that case, not a general response to every HTTP 500.
Exchange setup or update reports an error
For Exchange installation errors, Microsoft directs administrators to SetupAssist. If an update failed or Exchange no longer operates correctly afterward, follow Microsoft’s failed CU/SU installation repair guidance for the specific failure. Preserve the exact error and affected server details while diagnosing; do not assume that an unrelated repair procedure applies.
Review mitigations and keep the operating system current
Exchange Emergency Mitigation (EM) can apply temporary protections for known threats, including IIS URL Rewrite, Exchange service, or application-pool mitigations. The service checks Microsoft’s Office Config Service hourly and requires outbound connectivity to retrieve and validate mitigations. Check its service and configuration status where applicable.
EM mitigations are interim protections, not a replacement for the SU that addresses a vulnerability. Continue to install applicable Exchange SUs and Windows updates; Microsoft notes that Windows vulnerabilities can contribute to an attack chain.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
