Exchange Managment Shell/Console - The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer

This is known issue for Microsoft and they have published an article about this...  However i found its bit difficult to follow this article if you dont have much knowledge in IIS

http://support.microsoft.com/kb/2028305

To start troubleshooting this issue....

As per Microsoft cause of this issue is

This problem occurs because one or more of the following conditions are true:

The Kerbauth module is configured incorrectly in Internet Information Services (IIS) in one of the following ways:

The Kerbauth module is displayed as a Managed module instead of as a Native module.

The Kerbauth module has been loaded on the Default website level (instead of, or in addition to, the PowerShell virtual directory).

The user does not have Remote PowerShell Enabled status.

The WSMan module entry is missing from the Global modules section of the ApplicationHost.config file that is in the following location:

C:\Windows\System32\Inetsrv\config\ApplicationHost.config

This causes the WSMan module to be displayed as a Managed module in the PowerShell virtual directory.

Note: The WSMan Module entry may also be missing from the ApplicationHost.config file if the WinRM IIS Extension feature is installed on the server.

Resolution…

• Make sure that the user who is trying to connect has a Remote PowerShell Enabled status. To determine whether a user is enabled for Remote PowerShell, you have to start Exchange Management Shell by using an account that is enabled, and then run the following command:

(Get-User <username>).RemotePowershellEnabled

This query returns a response of True or False. If the output is displayed as False, the user is not enabled for Remote PowerShell. To enable the user, run the following command:

Set-User <username> -RemotePowerShellEnabled $True

• Make sure that the Kerbauth module is not enabled on the default website but is, instead, enabled only for the PowerShell virtual directory. Remote PowerShell uses Kerberos authentication for the user connection. Internet Information Services (IIS) implements this Kerberos authentication method by using a Native module.
  
  In IIS Manager, Kerbauth should be listed as a Native module in the PowerShell virtual directory. The DLL location for this module should point to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll. 
  
  Note The Local entry type for the Kerbauth module indicates that the module was enabled directly on this level and was not inherited from a parent level.

Please read this link to know how to add a native module.

http://technet.microsoft.com/en-us/library/cc771133(WS.10).aspx

• Make sure that the WSMan module is registered but not enabled at the Server level. Also make sure that the WSMan module is enabled for the PowerShell virtual directory. Then, verify that the following WSMan module entry is included in 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" />

Note You must follow these steps even if the WinRM IIS Extension feature has been removed. This is because the uninstall procedure does not automatically fix the ApplicationHost.config file.

If you hate editing config file,

You can add this WSMan as module as same as you did with Kerbrose. Then you don’t need to edit the configuration file

Some of my old posts....

 Here are some of my old posts....

http://tech-support-team.blogspot.com/search/label/Exchange%20Server