Exchange 2010 Management Tools Not Working

We recently took over support for an SBS 2011 server that is having issues (to put it politely). Our first indication that we have a problem was the Exchange Management Console and Exchange Management Shell not running properly. When EMC or EMS started, we'd get the following 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. For more information, see the about_Remote_Troubleshooting Help topic.

The exchange online help indicated that this can be cause by a user not having remote powershell permissions. The EMC and EMS in Exchange 2010 use remote powershell which requires WinRM to be properly functional. The exchange help suggests running set-user userid -PowerShellEnabled $true. However, you can't without the EMS properly loaded. Following several documents, I attempted to verify that WinRM was properly configured and ran both Enable-PSRemoting and WinRM quickconfig with no fix.

Then I tried accessing just the main server web site at http://127.0.0.1 and found the following error.

HTTP Error 500 - Internal Server Error Calling LoadLibraryEx on ISAPI filter "C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth\owaauth.dll"
Error code: 0x8007007e

This needs to be fixed because the EMC and EMS find WinRM by accessing the /PowerShell application in the Default Web Site.

After doing some more research I found that this is often a result of IIS not being properly configured. For Exchange 2010 CAS servers you should not enable 32-bit code. It should be 64-bit only. If you enable 32-bit code then you need to edit the applicationhost.config file and add the option preCondition="bitness64" in several lines for 64-bit DLLs that need to be loaded. This may be rewritten when you apply Exchange 2010 updates and is not recommended or required for Exchange. I made sure that 64-bit only was enabled by running cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 FALSE.

What finally got IIS functional again is copying extrace.dll from the Exchange bin folder to C:\Windows\System32. For some reason, this allowed IIS to find it and consequently load owaauth.dll properly.
At this point, the Application log showed a WinRM error for an Exchange as follows:

Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll"

After doing a quick bit of searching, it turns out that this is a result of the variable %ExchangeInstallPath% not being defined on the server. Defining a System variable ExchangeInstallPath with a value of C:\Program Files\Microsoft\Exchange Server\V14\ fixed it up.

Some links I found useful when troubleshooting this issue:

• http://blogs.technet.com/b/exchange/archive/2010/02/04/3409289.aspx
• http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/5b82f131-b469-4661-9d6c-1c1c7939b73a/
• http://blog.misthos.com/2009_09_01_archive.html
• http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/8b18c94b-5c2a-48ad-8ac0-06de12463f6b/