oeltayeb.com · Exchange Server Troubleshooting Toolkit

Checklist

Exchange Server security update checklist

Based on the article: Installing Exchange Server security updates: preparation, failures and post-install checks · 5 min read

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 to confirm

  • 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.

Likely causes

  • 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.

Checklist

  1. 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. 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
  3. 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. 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
  5. 5

    Fix the specific error

    using the table below.

  6. 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

powershell
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.

+1 more tips in the full article.

Microsoft Learn references