Exchange 2010 Management Tools Error

  • Article

This past week I was working with a customer who would receive the following error starting the Exchange 2010 Management Console or Exchange Management Shell:

Getting the error "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." when opening the Exchange Management Console or the Exchange Management Shell.

We went through everything under this topic in the post “Troubleshooting Exchange 2010 Management Tools startup issues” and were still running into a dead end. After a load of searching and digging through prior cases here and internal support notes, I finally found a prior case where they found a web.config and redirect.htm present in the file location of the Default Web Site (the wwwroot folder). So, my customer and I looked there and lo and behold, we had a web.config file there. We renamed the web.config and immediately the Exchange Management tools were able to connect to the server and function properly.

We investigated the web.config that was present a little further, and we found it had the following line in it:
<identity impersonate="true" />

Researching this a little bit, I found the following description:
Impersonation enabled. In this instance, ASP.NET impersonates the token passed to it by IIS, which is either an authenticated user or the anonymous Internet user account.

Looking back at the tools startup troubleshooting post, one of the things mentioned is this:
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 <username>).RemotePowershellEnabled

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

It appears that in this case, the impersonation being enabled through the web.config was causing us to use the IIS IUSR account for our actions, which is used for anonymous access, and is not able to be enabled for Remote Powershell. Removing the web.config put us back to passing our user credentials for Remote Powershell access and fixed the problem.