Troubleshooting Single Sign On on a Windows Installation (2033208)
- Autodiscovery fails during the installation.
- The Single Sign On installation process fails.
- You encounter an error during the installation of Single Sign On that references the vCenter Inventory or Web Client.
If the Single Sign On installer shows an error stating that autodiscovery has failed, perform the following steps to correct the problem.
- Verify that network prerequisites are met.
- Verify that the DNS configuration is correct. View the logs at <SSO Server>\utils\logs\install.log and imsTrace.log, or at a command line run <SSO Server>\utils\ssocli configure-riat -a discover-is
and follow the prompts. If log messages include an error similar to
WARNING: Discovered address ‘<hostname>/<ip>' does not map to the same host in reverse lookup. Host: ‘<another hostname>/<same ip>
review the domain controller host DNS configuration and make any necessary changes.
- To expose any connectivity and trust problems, force the server to leave and then rejoin the domain.
- If your controllers have SSL enabled on their LDAP services, verify that the SSL certificate is still valid.
Even if autodiscovery fails, you can add the same Active Directory domain through Single Sign On in the Web Client later.
Single Sign On installation fails completely
If the Single Sign On installation fails completely, perform the following steps to correct the problem.
- Verify that all installation setup prerequisites are met.
- At the time the installation fails, the installer displays a message similar to ####: Installation failed due to.... Before you click OK, gather a Single Sign On support bundle to assist support in determining the problem, if you need to contact support. At a command line, run the following command/
C:\Windows\System32\cscript.exe "<SSO Server>\scripts\sso-support.wsf" /z
- View the logs in <SSO_SERVER>\utils\logs\imsTrace.log, install.log and %TEMP%\vminstall.log for details about the failure and possible solutions.
An error references the vCenter Server inventory or vSphere Web Client
Regardless of the cause, the vCenter Server and Web Client installers might indicate the error
Could not contact Lookup Service. Please check VM_ssoreg.log....
- Verify that the clocks on the machines running Single Sign On, vCenter Server, and the Web Client are synchronized.
- Determine the cause and solution by viewing the specific log file mentioned in the error message. In the message, system temporary folder refers to %TEMP%.
- Within the log file, search for the following messages. The log file contains output from all installation attempts. Locate the last message indicating Initializing registration provider...
Message Cause and Solution java.net.ConnectException: Connection timed out: connect Indicates that the provided IP address is incorrect, a firewall is blocking access to Single Sign On, or Single Sign On is overloaded.
Ensure that the Single Sign On port (by default 7444) is not blocked by a firewall, and that the machine on which Single Sign On is installed has adequate free CPU, I/O. and RAM capacity.
java.net.ConnectException: Connection refused: connect Indicates that the provided IP address or FQDN is incorrect and that Single Sign On has not started or has started within the past minute.
Verify that Single Sign On is working by checking the status of vCenter Single Sign On service (Windows) and vmware-sso daemon (Linux). Restart the service.
If this does not correct the problem, see the Recovery section of the vSphere Troubleshooting Guide.
Unexpected status code: 404. SSO Server failed during initialization Restart Single Sign On. If this does not correct the problem, see the recovery section of the troubleshooting guide. The error shown in the UI begins with Could not connect to vCenter Single Sign-on. You also see the return code SslHandshakeFailed.
This is an extremely uncommon error. It indicates that the provided IP address or FQDN that resolves to the Single Sign On host was not the one used when installing Single Sign On.
In %TEMP%\VM_ssoreg.log, locate the line containing
hostname in certificate didn't match: <install-configured FQDN or IP> != <A> or <B> or <C>
where A was the FQDN entered in when Single Sign On was installed, and B and C are system-generated allowable alternatives.
Correct the configuration to use the FQDN on the right of the != sign in the log file. In most cases, use the FQDN specified during Single Sign On installation. If none of the alternatives are possible in your network configuration, recover your Single Sign On SSL configuration.