Exchange Management Shell: fixing WinRM 'Connecting to remote server failed' errors

The Exchange Management Shell is a remote PowerShell session, even when you open it on the Exchange server itself. When that session can't be created, you get a WinRM message that describes the transport rather than the cause, and the shell gives up with Failed to connect to an Exchange server in the current site. Here's how EMS connects, what each message means and how to fix it on Exchange Server SE and Exchange 2019.

Symptoms#

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 text after "failed with the following error message" is what matters. Other variants:

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

Some Microsoft articles show the last line as Failed to connect to any Exchange Server in the current site.; it's the same failure.

Why it happens#

The EMS shortcut runs RemoteExchange.ps1, which opens a session to http://<server FQDN>/PowerShell using Kerberos. That's the PowerShell virtual directory in IIS on port 80, not the WinRM listener on 5985, so WinRM listener changes won't fix it. Inside IIS, the native kerbauth module handles Kerberos, the WSMan module speaks WS-Management, Exchange's PowerShell application runs the session, and RBAC decides what you can do. Each message points to one link:

How to fix it#

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:

(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

If RemotePowerShellEnabled is False, fix it from a working session: Set-User <username> -RemotePowerShellEnabled $true.

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:

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

Inside <globalModules> the entry should read <add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" />. Microsoft notes the entry can also go missing when the WinRM IIS Extension feature is installed. Admins also report kerbauth missing from the Exchange Back End site's PowerShell directory after failed patching, so check both sites.

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. A hardening script that ticks it on every virtual directory is a typical way it gets switched on.

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. Restore it under Default Web Site › Bindings to match a healthy server, then run iisreset. If the PowerShell virtual directory itself was deleted, recreate it with New-PowerShellVirtualDirectory from a working session, copying what Get-PowerShellVirtualDirectory -Server EX02 | Format-List * shows for a healthy server.

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. 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). setspn -Q HTTP/ex01.contoso.com shouldn't return a service account; only namespace names like mail.contoso.com belong on the ASA. Also check for clock skew.

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

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

Verify the fix#

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

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.

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.

References#

• WinRM can't determine the content type of the HTTP response when you start Exchange Management Shell (Microsoft Learn)
• HTTP error 403 when you start Exchange Management Shell (Microsoft Learn)