Installing Exchange Server security updates: preparation, failures and post-install checks

Exchange Server security updates (SUs) are much smaller than cumulative updates, but a bad install can still leave Outlook on the web (OWA) and the Exchange admin center returning errors, services disabled or mail flow stopped. In this post I'll cover how to prepare so the install succeeds first time, Microsoft's documented fixes for the failures you're most likely to hit, and the checks that prove the update really landed.

Symptoms#

• OWA or ECP returns HTTP 500 after sign-in, with Could not load file or assembly 'Microsoft.Exchange.Common…', or ECP shows no images.
• The installer stops with "The upgrade patch cannot be installed by the Windows Installer service…".
• Setup fails part-way and Exchange services are left Disabled; mail flow stops.
• On a server without internet access, the install sits for a long time at "Creating Native images for .NET assemblies".
• Error code 1603 with "The installer has insufficient privileges to access this directory".
• Setup keeps asking for a restart even after several reboots.

Why it happens#

• SUs are tied to a CU. Each SU is a Windows Installer patch (.msp) built for one specific CU. Install an SU meant for another CU and Windows Installer refuses it.
• Elevation matters. Double-clicking the .msp on a server with User Account Control enabled can leave Exchange files and configuration inconsistent, which is the classic cause of OWA and ECP HTTP 500 errors.
• Services are disabled during install. The installer stops and disables Exchange services, then restores them at the end. If it fails in between, they stay disabled. C:\ExchangeSetupLogs\ServiceControl.log records which ones were changed.
• Offline servers wait on certificate checks. .NET native image generation tries to reach Microsoft's certificate revocation list for each assembly, and every request must time out first.

How to fix it#

1. Confirm the build and the correct SU. Run Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo.FileVersion } and compare the result with Microsoft's Exchange build numbers page. Download the SU for exactly that CU (or for SE RTM).
2. Bring the services back if they were left disabled. In an elevated PowerShell window (adjust the path if Exchange is installed elsewhere):
   PowerShell

   cd "C:\Program Files\Microsoft\Exchange Server\V15\Bin"
   Add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup -ErrorAction SilentlyContinue
   .\ServiceControl.ps1 AfterPatch
   Get-Service -DisplayName "Microsoft Exchange*" |
     Where-Object { $_.DisplayName -notlike "*POP3*" -and $_.DisplayName -notlike "*IMAP4*" } |
     Start-Service

   POP3 and IMAP4 aren't set to start automatically by default, so leave them alone unless you use them.
3. Reinstall the SU from an elevated prompt. Open Command Prompt with Run as administrator, type the full path of the .msp file, press Enter, and restart when it finishes. Do this even if the update already appears as installed.
4. Repair OWA and ECP if they still fail. In IIS Manager open Sites › Exchange Back End › ecp › Application Settings and make sure BinSearchFolder contains real paths, not %ExchangeInstallDir% variables. Then in an elevated Exchange Management Shell:
   PowerShell

   cd "C:\Program Files\Microsoft\Exchange Server\V15\Bin"
   .\UpdateCas.ps1
   .\UpdateConfigFiles.ps1
   iisreset

   Restart the server and test again.
5. Fix the specific error using the table below.
6. If a restart is always pending, run the Health Checker and Microsoft's SetupAssist.ps1 script from the CSS-Exchange project to find what still flags it. For CU setup failures, SetupLogReviewer.ps1 -SetupLog C:\ExchangeSetupLogs\ExchangeSetup.log reads the log and suggests a fix.

Verify the fix#

Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo.FileVersion }
Get-Service -DisplayName "Microsoft Exchange*" | Where-Object StartType -eq "Disabled"
Test-ServiceHealth
Get-ServerComponentState $env:COMPUTERNAME | Where-Object State -ne "Active"

Good looks like:

• The ExSetup version matches the build Microsoft lists for the SU you installed.
• No Exchange services are Disabled (unless you disabled one on purpose), and RequiredServicesRunning is True.
• Only ForwardSyncDaemon and ProvisioningRps are inactive, so the server isn't stuck in maintenance mode.
• OWA and the Exchange admin center sign in normally, mail flows, and the Health Checker lists no vulnerabilities for the server.

Prevent it next time#

• Restart the server before installing, so no restart is pending and services stop cleanly.
• Set proper antivirus exclusions, or turn file scanning off during the install.
• Always install from an elevated prompt, and download the SU that matches your CU.
• Check the Auth certificate's expiry date ahead of patch night: Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | Format-List Subject, NotAfter.
• Patch DAG members one at a time in maintenance mode, as shown in my in-place upgrade walkthrough, and keep management-tools workstations on the same build.
• Run the Health Checker before and after every patch cycle.

References#

• Fix failed Exchange Server updates – Microsoft Learn
• OWA or ECP stops working after you install a security update – Microsoft Learn