Wednesday, June 8, 2011

Errors when launching EMS after (re)deployment


After installing Exchange 2010 SP1 on all of the nodes in an environment, I was told that we were going to go with a different design, installing onto a different drive. The uninstall, and subsequent re-install to the other drive completed, and the installation went smoothly.  Everything seemed to be in order with Exchange...when using EMC.  When I launch EMS, however, I received the following error:

VERBOSE: Connecting to server.domain.com
[server.domain.com] Connecting to remote server failed with the following error message : The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic
.
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionOpenFailed
VERBOSE: Connecting to server.domain.com

I looked around for a bit and checked all of the normal things..

WinRM installed, configured and listening..check.

Powershell application pool started (and recycled)..check.

Validate Exchange-specific paths set to D:\ rather than C:\ in IIS...check.

Validate the kerbauth.dll is Local/Native to the PowerShell virtual directory, etc.. check.

Validated my account has remote PS rights..check.

At this point it definitely seemed to be either an IIS issue, or an authentication issue.  The fix turned out to be one of the values in "C:\Windows\System32\Inetsrv\config\ApplicationHost.config," specifically:

<globalModules>
     <add name="kerbauth" image="C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll">

As you can see, this value is set to C:\ rather than D:\.  Evidently uninstalling Exchange, and reinstalling it didn't change this value.  Upon changing this value, EMS suddenly started working, and all was well.

We chose to go through and uninstall Exchange, as well as IIS, and redeploy regardless to be on the safe side.  It seemed to be a small amount of work given that the systems were still pre-pilot, and there could potentially be more files that had not been updated.  This approach works just as well, though it is obviously more time consuming.

No comments: