Exchange Management Shell (WinRM) checklist

Symptoms to confirm

The shell tries each Exchange server in the local Active Directory site, then asks for one:

VERBOSE: Connecting to EX01.contoso.com.
New-PSSession : [ex01.contoso.com] Connecting to remote server ex01.contoso.com failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.
Failed to connect to an Exchange server in the current site.
Enter the server FQDN where you want to connect.:

• The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure.
• The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
• The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available.
• Processing data from remote server EX01 failed with the following error message: Unable to load the type "Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin" specified in the "InitializationParameters" section.

Likely causes

The EMS shortcut runs RemoteExchange.ps1, which opens a session to http://<server FQDN>/PowerShell using Kerberos.

Checklist

1. 1

   Get a working shell and collect facts

   At the prompt, enter another Exchange server's FQDN. If that works, the fault is local to the first server; if every server fails, suspect your account or something organisation-wide. On the broken server, check:

   powershell

   (Get-User <username>).RemotePowerShellEnabled
   Get-Service W3SVC, WAS, WinRM | Format-Table Name, Status
   Import-Module WebAdministration
   Get-ChildItem IIS:\AppPools | Where-Object Name -like 'MSExchangePowerShell*' | Format-Table Name, State
   Get-WebBinding -Name 'Default Web Site' | Format-Table protocol, bindingInformation

2. 2

   "Cannot determine the content type": kerbauth and WSMan

   Microsoft documents this case in KB 2028305 (Exchange SE, 2019 and 2016):

   • In IIS Manager, open Default Web Site › PowerShell › Modules. kerbauth must be a Native module pointing to C:\Program Files\Microsoft\Exchange Server\V15\Bin\kerbauth.dll. If it shows as Managed, or is also loaded at the Default Web Site level, correct that.
   • WSMan must be registered at server level but not enabled there, and enabled on the PowerShell virtual directory. If it appears as a Managed module, its global entry is missing from applicationHost.config.

   Back up the IIS configuration before editing, and compare with a healthy server on the same build:

   powershell

   & "$env:windir\system32\inetsrv\appcmd.exe" add backup "BeforeEMSFix"
   Select-String -Path "$env:windir\system32\inetsrv\config\applicationHost.config" -Pattern 'name="WSMan"'

3. 3

   "HTTP status code of 403": Require SSL

   EMS connects over HTTP on port 80, and Kerberos protects the session, so Default Web Site › PowerShell › SSL Settings › Require SSL must be cleared. Microsoft's fix (KB 2276957) is to clear it, click Apply, run iisreset and reopen EMS.

4. 4

   "Requested HTTP URL was not available": the port 80 binding

   Default Web Site needs an HTTP binding on port 80 that EMS can reach by the server's own name; Microsoft's documented fix is a binding with no host name on All Unassigned. Deleting it, or limiting it to a host name or IP address that the server's FQDN doesn't match, breaks EMS while HTTPS clients keep working.

5. 5

   Error 500 or "Unable to load the type": repair Exchange

   IIS answered, but Exchange's code behind it failed. Check the Application log for the exception, then:

   • If a cumulative or security update was interrupted or run without elevation, run it again from an elevated prompt (see installing Exchange security updates).
   • If OWA and ECP are failing too, check that the Exchange Back End site's HTTPS binding on port 444 still has a valid certificate, normally the self-signed "Microsoft Exchange" certificate.
   • Confirm antivirus excludes Exchange folders and processes; admins have traced the ExchangeAuthorizationPlugin error to antivirus.
6. 6

   Kerberos and proxy problems

   A message containing The following error with errorcode 0x80090322 occurred while using Kerberos authentication usually points to a service principal name problem, for example the server's HTTP SPN registered on another account such as a load-balancing alternate service account (ASA).

   If netsh winhttp show proxy lists a proxy, admins report EMS requests going to it; bypass the local machine and your Exchange servers:

   cmd

   netsh winhttp set proxy proxy-server="proxy.contoso.com:8080" bypass-list="<local>;*.contoso.com"

Verify

• Good looks like VERBOSE: Connected to EX01.contoso.com. when the shell opens, a session with configuration Microsoft.Exchange in state Opened, and cmdlets returning data.
• Then run the Health Checker on every server you changed.

Get-PSSession | Format-Table ComputerName, ConfigurationName, State

Prevent it next time

• Test EMS after any IIS hardening, binding change or module clean-up on Exchange sites.
• Install updates from an elevated prompt and confirm EMS, OWA and ECP before ending maintenance.
• Keep a second server or management workstation so one broken server can't lock you out.