Поделиться через

Exchange Management Shell Error 500 - Internal Server Error

  • Статья

I have come across this issue enough times that even if it is documented on TechNet it deserves mention here.

When you launch Exchange Management Shell or try to connect to an Exchange 2010 Server remotely using PowerShell, you get error “500 – Internal Server Error. There is a problem with the resource you are looking for, and it cannot be displayed.”

Error details also show the following:

 For more information, see the about_Remote_Troubleshooting Help topic.

    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException

    + FullyQualifiedErrorId : PSSessionOpenFailed

The other possible errors you may see are the following:

 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.

Or

 Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.

Or

 The WinRM client received an HTTP status code of 403 from the remote WS-Management service.

All of these issues relate to a problem with PowerShell virtual directory on given server not configured properly. If you were to run Exchange Best Practices Analyzer, it alerts about this issues as well.

The resolution is well documented on TechNet article “PowerShell Virtual Directory issues cause problems with Exchange Management tools”. I will let you read the solution there, however, I wanted to mention the oddity in my case.

Looking at the error I was getting and mapping it to solution in article didn’t resolve the issue. I had to configure kerberos authentication as mentioned in the article. Once KerbAuth was registered as native module, EMS and remote PowerShell sessions started working.

What my friend mentioned seems so relevant: “Why can’t our lives be just as predictable as computers? While there are some problems in a day, most of it is logical and if you know that logic, you can predict the outcome or fix the issue!”. Amen to that my friend.