So after close to 24 hours of screaming at Exchange for being a dirty tit, I’ve got the solution to the problem on a customers’ server.

The Problem
When opening Exchange Management Console (EMC) you get an error that reads:

“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.”

Most documents/forums/posts I could find pointed to these three fixes to that problem cited on technet

1. Remote PowerShell uses Kerberos to authenticate the user connecting. IIS implements this Kerberos authentication method 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 C:Program FilesMicrosoftExchange Serverv14Binkerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but 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.
   
2. If the WSMan module entry is missing from the global modules section of the C:WindowsSystem32InetsrvconfigApplicationHost.config file, as follows:

             
   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.

3. If the user that is attempting to connect is not Remote PowerShell enabled. To check if a user is enabled for Remote PowerShell, you need to open the Exchange Management Shell with an account that has been enabled, and run the following query.
   

   (Get-User ).RemotePowershellEnabled

   This will return a True or False. If the output shows False, the user is not enabled for Remote PowerShell. To enable the user, run the following command.

   Set-User -RemotePowerShellEnabled $True

Though those are the common issues my IIS setup looked fine and none of those were out of order, but I found this guy who suggested the following:

After opening the web.config file and looking in the file carefully I noticed that the file has two environment variables used %ExchangeInstallDir% and %ExchangeInstallDirPath%. These variables are supposed to be registered in advanced system properties page of the operating system. In my case the physical path for %ExchangeInstallDirPath% was missing. This path should be the actual installation directory of your exchange server (Normally C:Program FilesMicrosoftExchange ServerV14)

This also, didn’t fix the issue for me, so I was trying to repair install Exchange (which you can’t do), so I was going to uninstall and reinstall and when I attempted to uninstall (which you can’t do either because the mailboxes are tied to the Active Directory) I got an error complaining about IIS being in the wrong mode.

If you have checked all of the above, the problem could simply be that IIS is running in 32-bit mode instead of 64-bit.

To change it, run the following: cscript c:inetpubadminscriptsadsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False

As soon as I did that the EMC and EMS worked correctly to connect to the local Exchange server.