I recently upgraded a test environment to vSphere 5.1 and came across and issue with single sign on. The upgrade to 5.1 went fine, it was only when I rebooted the vCenter server (a week or so later), that I became aware of the problem.
After a reboot the vCenter service wouldn’t start, though many of the other vSphere services, including SSO had apparently started without issue.
Checking the vpxd logs revealed the following error message:
[SSO][SsoCertificateManagerImpl]’] [CreateAdminSsoServiceContent] Failure while trying to connect to SSO Admin server: No connection could be made because the target machine actively refused it.
So, at this point it looked as though vCenter couldn’t connect to the SSO service, despite that service being running. After checking the port that SSO listens on, I ran a netstat -a | find 7444 to see if the service was listening. This didn’t return any results:
Why wasn’t the process listening? Digging around for a while I came across a suggestion related to SQL Express and dynamic ports. It appears that the SSO install identifies the port on which to speak to SQL when it is installed. If that port changes, in the case of SQL being configured to use dynamic ports, then the SSO service will break when/if the port changes. Which is what had happened here when I rebooted the server.
What’s the solution?
First, stop the SSO service. Then change the port that SQL server is configured to use. Go to SQL Server Configuration Manager > TCP/IP > IP ALL > then remove port in Dynamic Ports and type 1433 in TCP port:
Next, restart the SQL express service.
From a CMD prompt go to: C:\Program Files\VMware\Infrastructure\SSOServer\utils
Then run the following command:
ssocli configure-riat -a configure-db –database-host hostname_of_vcenter –database-port 1433 -m SSO_Admin_Password
Finally, edit the following configuration file with the new port details. Replace the port number with the new value in the line that begins with db.url=:
C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties
Now we can reboot vCenter, and all should be working again. We can check that SSO is now listening by running the netstat command again:
The vCenter service should also now have started successfully. WooHoo!