SBS 2011: Unable to manage Exchange 2010 via console, shell or web interface. "WinRM cannot determine contet type of HTTP response."

Current setup:

• SBS 2011 (Windows 2008 R2)
• Exchange 2010 SP3, v14.03.0399.000
• Everything up to TLS 1.1 is disabled, based on PCI3.1 of IIS Crypto 2.0 (yes, I updated RDP to ensure continued connectivity).

Don’t honestly know where this problem crept in, but shortly after a certificate renewal/installation we discovered that while we can reach our email accounts via any normal method, we are unable to administer the Exchange server itself.

Details first, steps attempted after.

When using the Management Console, we get the following error:

[Server] Connecting to remote server 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 more information, see the about_Remote_Troubleshooting help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true -CurrentVersion 'Version 14.3 (Build 123.4)''

When opening up the Management Shell, we get the following:

VERBOSE: Connecting to [Server]
[Server] Connecting to remote server failed with the following error message : The WinRM client ca
nnot 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.
  + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
eption
  + FullyQualifiedErrorId : PSSessionOpenFailed

Plus, any attempt to use a loopback address or localhost where it asks for the FQDN where I want to connect, I get the same error message.

When opening up the web interface, we were presented with a number of errors.

In order to even get anywhere, I had to “log in” to OWA itself using the administrator account, then to “see all options” in the options drop-down, and then to “Manage this organization”. Once inside I got only the following pop-up message when I tried to access any management feature:

Sorry! We're having trouble processing your request right now. Please try again in a few minutes.

When I tried to go directly to EWS using this URL: https://[localhost]/EWS/Exchange.asmx, I got the following IIS error message:

Server Error in '/EWS' Application.
Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.TypeLoadException: Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[TypeLoadException: Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type) +0
   System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName) +95
   System.Type.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) +64
   System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) +59
   System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase) +49

[ConfigurationErrorsException: Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase) +550
   System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, Boolean checkAptcaBit) +30
   System.Web.Configuration.Common.ModulesEntry.SecureGetType(String typeName, String propertyName, ConfigurationElement configElement) +57
   System.Web.Configuration.Common.ModulesEntry..ctor(String name, String typeName, String propertyName, ConfigurationElement configElement) +57
   System.Web.HttpApplication.BuildIntegratedModuleCollection(List`1 moduleList) +173
   System.Web.HttpApplication.GetModuleCollection(IntPtr appContext) +1069
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +130
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +165
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +353
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +341

[HttpException (0x80004005): Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +523
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +107
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +688


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.7.3130.0 

The first step used to diagnose the issue was using EMTShooter for Exchange 2010. When run with admin privileges, it provided the following output:

Welcome to the Exchange Management Troubleshooter!

We recommend that you run the troubleshooter after making changes to
IIS to ensure that connectivity to Exchange Powershell is unaffected.

Checking IIS Service...

Checking the Exchange Install Path variable...

Checking the Powershell Virtual Directory...

Checking the Powershell vdir SSL setting...

Checking the Powershell vdir path setting...

Checking HTTP Port 80...

Checking HTTP Port 80 Host Name...

Testing for errors...

VERBOSE: Connecting to ECLIPSESERVER.eclipse.local


[Server] Connecting to remote server failed with the following error message : The WinRM client can
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExcep
    + FullyQualifiedErrorId : PSSessionOpenFailed
The Exchange Management Troubleshooter successfully completed connecting to:

[Server]

Failed to connect to any Exchange Server in the current site.

Problem found:

Looking for error...

These are the possible causes for this error:

1. If the WSMan module entry is missing from the global modules section of the
C:\Windows\System32\Inetsrv\config\ApplicationHost.config file, as follows:

<globalModules>
           <add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" />

This will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.

To correct this, make sure that the WSMan module has been registered (but not enabled) at the Server level, and has been
 enabled on the PowerShell virtual directory.  Confirm that the WSMan entry exists in the Global Section of the Applicat
ionHost.config file as shown above.


2. Remote PowerShell uses Kerberos to authenticate the user connecting.  IIS implements this Kerberos authentication met
hod via a native module. In IIS Manager, if you go to the PowerShell Virtual Directory and then look at the Modules, you
 should see Kerbauth listed as a Native Module, with the dll location pointing to \Program Files\Microsoft\Exchange Serv
er\v14\Bin\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth modul
e has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you c
an experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, bu
t is only enabled on the PowerShell virtual directory.  The entry type of "Local" indicates that the Kerbauth module was
 enabled directly on this level, and not inherited from a parent.

3.  The Path of the Powershell virtual directory has been modified.  The PowerShell virtual directory must point to the

"\Exchange Server\v14\ClientAccess\PowerShell"

directory or you will encounter problems.

After each error is resolved, close this window and re-run the tool to check for additional problems.

[EMTS] C:\Windows\system32>

Okay, so far so good! Except… not all of these issues existed, and no changes corrected the issue.

1. The <globalModules> had the correct entry.
2. Kerberos auth was done via a native module, that was pointing to the correct dll. Plus, when I went into IIS, expanded Default Web Site, clicked on the PowerShell sub-section and opened Authentication, the Providers for Windows Authentication included Negotiate:Kerberos. I think I may have enabled that Windows Authentication entry at one point, as I am pretty sure it was disabled in the beginning (and Extended Protection was and still is OFF). Either enabled or disabled changes nothing.
3. The PowerShell-Proxy sub-section of the Default Web Site had the Basic Setting slightly wrong to begin with: instead of pointing toward C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell, it pointed toward ...\PowerShell-Proxy instead. There was no change when it was corrected, aside from the Management Console timeout taking about twice as long.

When examining the web access for the /EWS/Exchange.asmx path in particular, I took a hard look at the IIS error message, and found this example. Unfortunately, with SBS2011 the Windows Features just shunted me to Server Manager, and neither the Roles themselves nor the Add Roles Services could provide me any access to .NET Framework 4.5 Advanced Services features, in order to enable everything as that post suggested. The only thing accessible was DotNet 3.x, and everything there was installed and active. I was unable to use the PowerShell suggestions in the subsequent post because the system claimed that ’Install-WindowsFeature’ is not recognized.

I have also gone through other posts on ServerFault:

• Cannot log into Exchange Management Console, Kerberos auth failed, cannot determine content type of HTTP response from destination computer
• Remote PS session fails on non-domain server - yes, winrm quickconfig says it’s already set up
• https://stackoverflow.com/a/17828262 - aspnet_regiis.exe ran successfully, but no change to /EWS/ website.

And have been unable to find a solution.

Right now, I am fresh out of ideas. Any help in regaining access would be greatly appreciated.

Did you try all of the steps described in the following articles?

Error message when you try to start Exchange Management Shell (EMS) or Exchange Management Console (EMC): "The WinRM client... cannot determine the content type of the HTTP response from the destination computer" https://support.microsoft.com/en-sg/help/2028305/error-message-when-you-try-to-start-exchange-management-shell-ems-or-e

Solution for powershell remoting error “It cannot determine the content type of the HTTP response from the destination computer…” https://oyvindnilsen.com/solution-for-powershell-remoting-error-it-cannot-determine-the-content-type-of-the-http-response-from-the-destination-computer/