Sunday, February 21, 2010

Exchange Management Console/Shell errors

Today I encountered a new error when configuring an Exchange 2010 server for a client. The Exchange server was installed on machine that was also a domain controller.
When I was trying to connect to Exchange 2010 Management Console you I’ve got the following error:

I tried to access the Exchange 2010 installation using the shell and I’ve got the same error:
VERBOSE: Connecting to Rombiosrv01.rombiomedica.local
[rombiosrv01.rombiomedica.local] Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [] PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed
Searching through eventlog, I found the event 10154:
The WinRM service failed to create the following SPNs: WSMAN/Rombiosrv01.rombiomedica.local; WSMAN/Rombiosrv01.
Additional Data
The error received was 8344: %%8344.
User Action
The SPNs can be created by an administrator using setspn.exe utility.

First thing I tried was to check if "WinRM IIS Extension” was installed and surprised it wasn’t.
To add “WinRM IIS Extension”, you have to use “Add features” from Server Manager. After you install the extension, you have to reboot the server and run (with elevated rights) "winrm quickconfig” to configure it.

The second thing I found out was that if you install Exchange 2010 on a domain controller you will lose some permissions and you have to add them manually. If you get the same error, using ADSI Editor, check the Properties of the AD object for this server in the Domain Controllers OU. On the Security tab, check if NETWORK SERVICE has the Validated Write to Service Principal Name permission.
Now, the System event log was clean, but I still coudn't manage the server.

Third thing, and the easiest one, was to check if everything was working fine within IIS and surprise: the default web site was stopped. I tried to start it without success. Soon I found out that the HTTPS port was used by another application. Once I solved this problem, the server was fully operational.

If the steps above does not succed, check if you have the .NET Extensibility role services for IIS installed.  You can read more here

1 comment:

  1. Hey, just wanted to say thanks! The default web site was stopped. You fixed my problem.