OWA and ECP HTTP 500 errors on Exchange Server: usual causes and how to tell them apart

An HTTP 500 from Outlook on the web or the Exchange admin center tells you that something failed, not what. The same status code comes from half-installed updates, missing configuration files, expired certificates and crashing application pools. In this post I'll show how to find which side of the proxy failed, match what you see to the usual causes, and apply the fix that belongs to it.

Symptoms#

OWA shows its error page, and ECP shows an ASP.NET error, typically:

Something went wrong
Your request couldn't be completed. HTTP Status code: 500

Server Error in '/ecp' Application.
Could not load file or assembly 'Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

Related variants you may see instead:

• After an interrupted installation: something went wrong with Sorry, we can't get that information right now. Please try again later. If the problem continues, contact your helpdesk.
• Sign-in never completes or the browser reports a redirect limit, and the Application log has Event ID 1003 from the front-end HTTP proxy with System.NullReferenceException at Microsoft.Exchange.HttpProxy.FbaModule.ParseCadataCookies.
• ASP.NET Event ID 1309 warnings ("An unhandled exception has occurred") for /owa or /ecp.

Why it happens#

Every OWA or ECP request crosses two IIS sites. The Default Web Site (front end) authenticates the user, and its HttpProxy module forwards the request to the Exchange Back End site on port 444 of the server where the mailbox is active, which runs the real application. Either side can return a 500. The usual reasons:

• A security update installed without elevation. Double-clicking the .msp on a server with UAC enabled can leave files and configuration inconsistent, so OWA and ECP can't load Exchange assemblies.
• A missing SharedWebConfig.config in ClientAccess (back end) or FrontEnd\HttpProxy (front end), typically after setup was interrupted.
• Certificates. An expired Auth (OAuth) certificate breaks forms-based sign-in on the front end; a missing certificate on the back-end 444 binding stops proxying.
• Application pools and config files. A crashing pool, or a web.config IIS can't parse (status 500.19).

How to fix it#

1. Find out which side failed#

Reproduce the error and note the time. OWA's error page details show X-FEServer and X-BEServer, the servers that handled the request. On those servers, search the IIS logs: W3SVC1 is the Default Web Site, W3SVC2 the Exchange Back End.

$log = "u_ex$((Get-Date).ToUniversalTime().ToString('yyMMdd')).log"
foreach ($site in 'W3SVC1','W3SVC2') {
  Select-String -Path "C:\inetpub\logs\LogFiles\$site\$log" -Pattern '/(owa|ecp)/.* 500 \d+ \d+ \d+$' |
    Select-Object -Last 5 | ForEach-Object { "$site  $($_.Line)" }
}

• 500 only in W3SVC1: the front end failed or couldn't reach the back end (Auth certificate, the HttpProxy SharedWebConfig.config, the 444 binding).
• 500 in W3SVC2: the application on the back end failed (non-elevated update, the ClientAccess SharedWebConfig.config, app pool).
• Sub-status 19: a configuration file problem.

The HttpProxy logs in %ExchangeInstallPath%Logging\HttpProxy\Owa and \Ecp add HttpStatus, BackEndStatus, TargetServer, ErrorCode and GenericErrors. A front-end 500 with an empty BackEndStatus means the back end never answered, so check the 444 binding on the target server. Events 1309 and 1003 carry the exception text, which is often the quickest route to the cause.

2. Match what you see to the cause#

3. Repair a non-elevated security update#

Open Command Prompt with Run as administrator, run the full path of the .msp, and restart when it finishes. If OWA or ECP still fail, rebuild the virtual directory files and configuration from an elevated Exchange Management Shell, reset IIS and restart the server (Microsoft's article also covers repairing ECP's bin search paths):

cd (Join-Path $env:ExchangeInstallPath 'Bin')
.\UpdateCas.ps1
.\UpdateConfigFiles.ps1
iisreset

More on avoiding this in installing Exchange security updates.

4. Regenerate a missing SharedWebConfig.config#

Check both locations with Test-Path (Join-Path $env:ExchangeInstallPath 'ClientAccess\SharedWebConfig.config') and the same for FrontEnd\HttpProxy\SharedWebConfig.config. For whichever is missing, run the matching line from an elevated command prompt, then iisreset:

cd /d "%ExchangeInstallPath%\bin"
DependentAssemblyGenerator.exe -exchangePath "%ExchangeInstallPath%\bin" -exchangePath "%ExchangeInstallPath%\ClientAccess" -configFile "%ExchangeInstallPath%\ClientAccess\SharedWebConfig.config"
DependentAssemblyGenerator.exe -exchangePath "%ExchangeInstallPath%\bin" -exchangePath "%ExchangeInstallPath%\FrontEnd\HttpProxy" -configFile "%ExchangeInstallPath%\FrontEnd\HttpProxy\SharedWebConfig.config"

5. Check the Auth certificate and the back-end binding#

$thumb = (Get-AuthConfig).CurrentCertificateThumbprint
Get-ExchangeCertificate -Thumbprint $thumb | Format-List Subject, NotAfter, Status
netsh http show sslcert ipport=0.0.0.0:444

If the Auth certificate has expired or isn't found, renew it as described in renewing the SAN and Auth certificates; the CSS-Exchange script MonitorExchangeAuthCertificate.ps1 can also do it. If the 444 binding has no valid certificate, follow fixing the Exchange Back End 444 binding.

6. Application pools and config files#

Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Where-Object Name -like 'MSExchange*' | Format-Table Name, State
Start-WebAppPool -Name MSExchangeOWAAppPool     # a pool that is Stopped
Restart-WebAppPool -Name MSExchangeECPAppPool   # recycle a running pool

A stopped pool usually produces HTTP 503 rather than 500. If a pool keeps stopping, IIS rapid-fail protection has disabled it after repeated crashes; the WAS events in the System log and the 1309 events explain why. For 500.19, compare the failing application's web.config with the same file on a healthy server at the same build instead of editing by hand, and confirm the IIS URL Rewrite module is installed. Remember that each CU overwrites web.config customisations.

Verify the fix#

• OWA and ECP load for mailboxes on every server; test each one directly, for example https://ex01.contoso.com/owa.
• New IIS log lines for /owa and /ecp show 200 or 302, not 500.
• No new 1309 or 1003 events in the Application log.
• Get-HealthReport -Identity EX01 | Where-Object { $_.HealthSet -like 'OWA*' -or $_.HealthSet -like 'ECP*' } | Format-Table HealthSet, AlertValue shows Healthy once the probes have run.

Key takeaways#

• Read the error text first; it usually names the cause.
• Work out whether the front end or back end failed before changing anything.
• Install security updates from an elevated prompt and run the Health Checker afterwards.
• Keep the Auth certificate and the 444 binding healthy; problems with either only show up when users try to sign in.

References#

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