We are in the midst of upgrading vCenters to 5.5 from 5.0. The biggest difference is the inclusion and requirement for SSO server.
The default install of the SSO server is simply enough. After install SSO, we would go ahead to install vCenter server (or upgrade it), it would fail during installation. The reason for failure is the vCenter service would fail to start up with the domain system account. Logging on from web sphere client, we could see that the default computer domain (let’s call this MYAD), which is also the same domain as the system account, was not added as the identity source in SSO. As a result, the system account could not authenticate via SSO and service will not start during installation. Once we added the domain into SSO, the services started up fine. So this is indeed a case of missing identity source in SSO.
During SSO installation, you can select to add the default domain during installation. However, in our case, this never worked. So we had to fire a support question to vmware support. After some weeks of logs and testing, this is what they concluded:
“Based on the uploaded logs, SSO cannot get domain controller info and trust info via DsGetDcName and DsEnumerateDomainTrusts windows APIs and this is causing the delay in finishing up the process of retrieving the domain join status. Installer needs the the domain join info in order to add the current machine’s domain as an IDP. In your setup, by the time we get all the DC and trust info, installer had already asked for that detail and it can’t get it. So it completes the installation without adding the IDP.
Our Engineering team has confirmed that this behavior is by design. I know that you would want this process to be automated, however, they are recommending to use the article http://kb.vmware.com/kb/2063424 to add the Identity Sources after the installation.”
In summary, because our domain has too many trusts, including some that are behind firewall and it took too long to collect the information during installation. Hence, SSO is designed to give up but mark installation as completed. The problem with this is that SSO install should at least warn you that the domain is not successfully added and save the headache of folks installing vCenter server afterwards but scratching their heads why it failed.
So we loaded up the batch files provided and copied all files to c:\vdcidentitysource (note that this path was in the original article, it was later amended because I found the issue with it). So when I executed “sso-add-native-ad-idp.cmd myad.com”, I got the following message:
Error: Could not find or load main class com.vmware.identify.migration.ImporterToSSo2
As this was a test environment, I revert to previous snapshot and ensure I have a really clean environment, installed SSO and executed the batch file again. Again I had the same issue. Anyhow, I found out the issue was a flaw logic in the sso_import.cmd file which sso-add-native-ad-idp.cmd calls AND also because we had installed SSO on D drive but the instructions wants you to execute from C drive.
The error occurs in the last 2 lines of sso_import.cmd:
%JAVA% -cp migrationtool.jar;exporttool.jar;"%SSO_INST_DIR%vmware-identity-idm-interface.jar";"%SSO_INST_DIR%vmware-identity-idm-client.jar";"%SSO_LIB_DIR%commons-codec-1.4.jar";"%SSO_INST_DIR%lib"\*;"%SSO_INST_DIR%\". ^
-ea com.vmware.identity.migration.ImporterToSSO2 %1 %2
The line “cd %SSO_IMP_DIR%” assumes that the current drive in the command prompt is the same as the drive in the variable %SSO_IMP_DIR%. So if your command prompt is “C:\>” and the variable is “c:\temp”, then “cd c:\temp” will change directory successfully, but if the variable is “d:\temp”, “c:\>cd d:\temp” will just change the directory in d: but will not change the current directory, you will still remain in “c:\>” prompt. As a result the java execute will end up in error.
So to execute the KB correctly, you need to place the source in the same volume as where SSO is installed. VMware support guys updated the KB after I found out this issue. 🙂
Now, executing the KB to add the missing IDP was not an instant solution, In our environment, we had to run this 3-4 times before we could successfully get the domain added as I was constantly getting “machine is not properly joined” error.
Addendum: On of our vCenter 5.0 servers, we had to deselect “add default domain” during SSO installation for it to install successfully. Selecting to add the default domain (i.e. our firm’s domain and trust) caused the install Wizard to hang at “Configuring SSO Components…” forever… No idea what caused this as there were not errors reported in the install or sso logs