December 24, 2013 by UCSip
Recently I had a customer go through a routine upgrade from Exchange 2010 SP2 RTM to Exchange 2010 SP3 that I performed, and after the patching was done everything was fine until we realized management on the Exchange UM servers wasn’t working. We were not even able to remote manage them to configure new users for UM features, so we had a very real problem here which is why I was called in.
The most evident errors seen were in the management interfaces themselves.
Power Shell console Exchange Management Console
In the power shell console the major error was: WinRM client cannot process this request. It cannot determine the content type of the HTTP response from the destination computer.
I now began troubleshooting deeper, starting with an easy pass through the event logs to find an ASP.net error which then led me to the discovery in the second screenshot. I found the Power Shell “Server Error” in two ways, from IIS manager I selected the powershell virtual directory and used the select browse:80 test feature, also I opened Iexplorer.exe and browsed to http://localhost/powershell.
Now like many of you I went to Technet, google and my own archives of case notes looking for answers and found many articles that gave me hope but there it was very scattered.
This one below I thought for sure was the source of all my problems.
Resolving WinRM errors and Exchange 2010 Management tools start-up failures
Unfortunately while this blog article has many great suggestions and a neat tool that actually did find an issue and fixed a problem, it did not fix my specific issues with WinRM connectivity. I still continued to have Remote Management problems with my Exchange 2010 SP3 even though it continued to function properly as a UM server.
How to Repair or Reinstall .NET Framework 3.5/2.0
Next I needed to address the ASP.net errors I was receiving, maybe this was a multiple issue problem and each needed to be addresses in order. So I used the above method to repair what appeared to be a corrupt .NET 2 installation, which makes sense because during our patch we installed a lot of .NET security patches.
This did resolve the ASP.net errors and the SERVER Errors when browsing powershell, but I still could not manage the Exchange server.
So we press on! Never Retreat, Never Surrender!
Fix 3 (The one that works)
I am not totally sure how I found this, call it luck, Wizardry, Magic, extreme fatigue whatever but I’d read enough articles that night to give me enough evidence to believe a posting that made a rather outlandish claim about our beloved Exchange.
On the Exchange server having the issue, open the web.config file for the powershell virtual directory, you will find it at the below path. My paths are on the D:\ drive because I always install the Exchange application to it’s own drive, yours may be C:\.
Exchange 2010 D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell Exchange 2013 D:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell
Once you open the web.config perform a search for any references of the variables %ExchangeInstallPath% or %ExchangeInstallDir% and replace them with the absolute path to these files. Please remember to make a backup copy of your original web.config before making this change.
Yes I know, could or should we just fix the environment variable and/or paths? Well yes I checked those and they were all in place, I even removed them and re-added without change.
Now perform an IISreset and test, this resolved the issues for me and all is working flawlessly now. I hope this Blog post helps you and saves you a bit of time.