VMware Cloud Community
pgn674
Enthusiast
Enthusiast
Jump to solution

Error When Installing SSO 5.5 On New Machine

I have been trying to install VMware vCenter Single Sign-On 5.5.0 from VMware-VIMSetup-all-5.5.0-1312299.iso, and like some others I am having trouble. I am installing on a brand new Windows Server Datacenter 2008 R2 SP1 64-bit VM.

The first time I ran the installer, I got to the vCenter Single Sign-On Prerequisites screen, and realized that my network settings on the new machine were a little off. So I canceled the installer, fixed my networking, started the installer again, and this time I got the message "DNS resolution is successful."

So, I continued on my way. I select "vCenter Single Sign-On for your first vCenter Server", it starts installing, the status gets to "Configuring SSO Components...", and then it shows "Rolling back action:", then "vCenter Single Sign-On Setup Wizard ended prematurely because of an error." All subsequent install attempts have resulted in the same thing.

I've seen some proposed solutions elsewhere, and I have tried:

  • Rename C:\ProgramData\VMware\CIS to CIS.old
  • Run (VMware-VIMSetup-all-5.5.0-1312299.iso)\Single Sign-On\prerequisites\VMware-python.msi (Tried in right click menu: Repair, and also Uninstall then Install)
  • In "HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Infrastructure", there is no SSOServer

I have attached vim-sso-msi.log and vminst.log from %TEMP%. I also found a vminst.log from one directory above %TEMP%; I've attached that too as vminst-Temp.log in case it's useful.

Looking at the logs, in vim-sso-msi.log this is near the end:

MSI (c) (28:DC) [14:08:39:385]: Note: 1: 1708

MSI (c) (28:DC) [14:08:39:385]: Product: vCenter Single Sign-On -- Installation failed.

MSI (c) (28:DC) [14:08:39:385]: Windows Installer installed the product. Product Name: vCenter Single Sign-On. Product Version: 5.5.0.297. Product Language: 1033. Manufacturer: VMware, Inc.. Installation success or error status: 1603.

This is towards the middle:

MSI (s) (38:A0) [14:07:41:006]: Executing op: ActionStart(Name=BootstrapAll,,)

Action 14:07:41: BootstrapAll.

MSI (s) (38:A0) [14:07:41:022]: Executing op: CustomActionSchedule(Action=BootstrapAll,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)

MSI (s) (38:88) [14:07:41:037]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2A01.tmp, Entrypoint: VmSetupExecuteBootstrap

MSI (s) (38:5C) [14:07:41:037]: Generating random cookie.

MSI (s) (38:5C) [14:07:41:053]: Created Custom Action Server with PID 1724 (0x6BC).

MSI (s) (38:FC) [14:07:41:178]: Running as a service.

MSI (s) (38:FC) [14:07:41:193]: Hello, I'm your 64bit Elevated custom action server.

Action 14:07:41: PostInstallScripts. Configuring SSO Components...

PostInstallScripts: PostInstallScripts

PostInstallScripts: PostInstallScripts

CustomAction BootstrapAll returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

Action ended 14:08:00: InstallFinalize. Return value 3.

In vminst-Temp.log, I see this, but I'm not sure whether it's relevant:

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 LDAP Utils : VmSetupMakeLdapsConnection

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 Attempting ldap_sslinit...

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 Attempting ldap_connect...

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 Attempting ldap_bind_s...

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 Unable to make LDAPS connection. Error :1326

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 VmSetupUpdateVmdirCert error: 1603

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 VmSetupVmdirCert error: 1603

%TEMP% is C:\Users\Administrator.MCI\AppData\Local\Temp\2

I got vminst-Temp.log from C:\Users\Administrator.MCI\AppData\Local\Temp

Does anybody have any ideas on what I can try, or any more information that would help?

Tags (4)
35 Replies
pgn674
Enthusiast
Enthusiast
Jump to solution

himmie, are you sure you are having the same error that I did? I found that the true error for me was code 1326, and was located in a file named vminst.log that is located one directory above %TEMP% (for me, this is C:\Users\Administrator.MCI\AppData\Local\Temp\). This is not the same file that the installer automatically opens after a failed install attempt. The error I was getting was:

VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 Unable to make LDAPS connection. Error :1326

Now, I am getting:

VMware Single Sign-On-build-1302472: 10/10/13 23:31:05 Attempting ldap_sslinit...

VMware Single Sign-On-build-1302472: 10/10/13 23:31:05 Attempting ldap_connect...

VMware Single Sign-On-build-1302472: 10/10/13 23:31:05 Attempting ldap_bind_s...

VMware Single Sign-On-build-1302472: 10/10/13 23:31:10 Entering function: VmSetupStartService

VMware Single Sign-On-build-1302472: 10/10/13 23:31:10 Entering function: VmSetupWaitForServiceStart

And it continues on to success.

Here is what led me to the solution: I thought perhapse my base Windows VM image was somehow corrupt, so I tried creating a brand new image, and installed Windows Server Datacenter 2008 R2 with SP1 64Bit English onto it. Then, after only changing the time and time zone, enabling Remote Desktop, and installing WinCDEmu, I tried installing SSO. And it failed the same way.

Then, maybe because I had just recently set the password for the local Windows Administrator account on this new VM, I thought I might as well try that same password during the SSO install, even tough nothing says that's a requirement. And, lo and behold, it worked.

I have tried it on that VM cloned from the base VM, and on the VM that already had vCenter 5.1 installed, and using the local Windows Administrator password worked.

BTW, I had tried creating some other passwords, thinking maybe one of my characters was messing things up, but more simple passwords still failed the installer. Only the password that matched the one for the local Windows Administrator account worked.

Since I got this working for myself, I am going to mark this thread as answered.

Reply
0 Kudos
pgn674
Enthusiast
Enthusiast
Jump to solution

Here is the documentation for the password asked for by the SSO installer. I found it in a document called vSphere Installation and Setup (vsphere-esxi-vcenter-server-55-installation-setup-guide.pdf).

5  Set the password for the vCenter Single Sign-On administrator account.

   This is the password for the user administrator@vsphere.local. vsphere.local is a new domain that is created by vCenter Single Sign-On. After installation, you can log in to vCenter Single Sign-On and in to vCenter Server as adminstrator@vsphere.local.

   By default, the password must have at least eight characters, at least one lowercase character, one uppercase character, one number, and one special character. See the vSphere Security documentation for information about changing the password policy. The following characters are not supported in passwords: non-ASCII characters, semicolon (;), double quotation mark ("), single quotation mark ('), circumflex (^), and backslash (\).


No mention of the password needing to be the same as the local Windows Administrator account.


And here is the screen that asks for a password:


SSO_Password.png

Reply
0 Kudos
pgn674
Enthusiast
Enthusiast
Jump to solution

So I think I just discovered the true reason it was failing. In the documentation above, they say that ;"'^\ are not valid characters in a password. But, they missed a character: The space. I was using a space character in my password.

I tried out the installer a bunch of times. When one of the above invalid characters is used, the installer continues anyway. And then throws a 1326 in that other log file I mentioned. Using a space does the same thing. And it's not like they aren't checking the password at all. If you don't meet the complexity requirements that's in their documentation, then you get this notice:

SSO_Password_Complexity.png

I don't know why they accept invalid characters in the installer. And I don't know why they missed listing the space character as an invalid character in their documentation. It is an ASCII character, after all (0x20).

I did try a couple other passwords long ago, but I think it was before I found this documentation, so I may have used one of the other invalid characters. Or maybe I used another invalid character that is undocumented. If space is not documented as an invalid character, then who knows how many other invalid characters there are?

And so, I say to all who believe they are having the same problem that I did:

First, make sure it's the same problem. Verify that you are getting an error code 1326 in the other vminst.log file, located one directory above %TEMP%. If you cannot find 1326, then you probably have a different problem.

Then, try other passwords. Don't use the documented invalid characters. And keep in mind that there may be other undocumented invalid characters.

The password does not need to be identical to the local Windows Administrator account's password. It just can't contain any undocumented invalid characters.

Reply
0 Kudos
Terry3
Contributor
Contributor
Jump to solution

Vmware has had a problem developing installers since at least 4.1. Back then we had an issue where Vcenter installer automatically chose the logged in account to run the service. You had to change the service after the installation, there was no way to specify the service account. So if your service account doesn't have login interactive permissions, you have to login and install as one who does, then flip the service to use the proper account. I had a case open with VMware and it was never resolved, was advised this is how it's going to be.

But the hypervisor itself is damn amazing, so I'll deal with these small issues. Better than virtualizing Windows on Windows...

Reply
0 Kudos
himmie
Contributor
Contributor
Jump to solution

HI pgn674,

Yeah I was getting that same error as well. "VMware Single Sign-On-build-1302472: 09/25/13 14:08:00 Unable to make LDAPS connection. Error :1326"

Did a webex with VMware tech and he indicated that it was a bug and that the error are reported to be fixed in 5.5.1 however did not have a release date for that at this time.

I am at the point now, where I am going to do a clean install of 5.1 and then wait for the 5.5.1 to get released. I needed to move it into Oracle anyways, so here is a good chance to do that. Glad you were able to get it going with the same password though.

Reply
0 Kudos
pgn674
Enthusiast
Enthusiast
Jump to solution

There is a KB article covering this issue now: VMware KB: Installing vCenter Single Sign-On 5.5 fails if the password for administrator@vsphere.loc.... Looks like it was created on October 11, the day after I figured out the true cause. In it, they give an expanded list of invalid characters: &;"'^\ !

Reply
0 Kudos
Bleeder
Hot Shot
Hot Shot
Jump to solution

Does anyone know why the SSO 5.5 install is trying to communicate over port 10112 during an upgrade of a multi-site SSO 5.1 install?  Allowing that port through all my firewalls is what fixed this problem for me.

Reply
0 Kudos
ziggyk
Contributor
Contributor
Jump to solution

resurento's solution also helped me upgrade my vCenter 5.0 installation to 5.5.

My SSO installation was failing.  The error log said: "BootstrapAll returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)Action ended 8:52:39: InstallFinalize. Return value 3."

I did the following:

1. Rebooted the server.

2. Deleted all the content in the folder %programdata%\VMware\CIS

3. Manually installed Vmware-python package from CD in folder: Single Sign-On\prerequisites\VMware-python.msi.

4. I started a Simple install again and the installation completed successfully.

Reply
0 Kudos
Hitchman_10
Contributor
Contributor
Jump to solution

Hola.!   Referente a todo lo comentado esta duda, de igual forma intentamos hacer lo en un Windows server 2008 r2, pero causaba muchos problemas de instalación  el VMware 5.5 u1 Single Sing-On. Pero una Opción que fue bastante buena fue instalarlo en Windows Server 2012. No presento problema alguno.  La verdad es que ninguna de la soluciones que dan ayuda. (Lo siento).

1.- De igual forma se instalo primero  VMware-OpenSSL (D:\Single Sign-On\prerequisites)

2.- Y después VMware-python (D:\Single Sign-On\prerequisites)

3.- Por ultimo se instala  VMware-SSO-Server   (D:\Single Sign-On)

Single.png

Reply
0 Kudos
hnguyen101
Contributor
Contributor
Jump to solution

I have spent the last 48 hrs on the phone with vMWare support about this issue.  I had similar problems with installing SSO.  It kept rolling back every time and vMWare support spent hours on the phone with me trying everything to solve this issue.  They even tried to refer me to Microsoft Support and stated that it was an MSI install issue.  Anyways, I was able to resolve the problem by clearing the CIS folder.  DO NOT DELETE THAT FOLDER.  We did that several times and it didn't work.  You must leave the CIS folder, but delete the contents in there.  Run the python perquisite install and re-run SSO install again. 

Thanks again.

Reply
0 Kudos
ErikCarlseen
Contributor
Contributor
Jump to solution

I don't think this (having the SSO admin password be the same as the local / domain administrator password) is supposed to be an official requirement either, but I was banging my head on this thing for awhile and tried this suggestion... and, heck, it worked. It could be something related to the composition of my other password (who knows)? My only comment to VMWare is: "EXCEPTION HANDLING WITH RELEVANT ERROR MESSAGES - HAVE YOU HEARD OF IT???"

stfconsulting
Enthusiast
Enthusiast
Jump to solution

We are battling the same issue as I write this. Just tried to match the .local administrator password with the vcenter server local admin and that did not fix it either. Still working with VMware support. Will post fix once we figure it out.

Reply
0 Kudos
ErikCarlseen
Contributor
Contributor
Jump to solution

We've gone through this a couple of times now, and the only straightforward thing we've noticed is that installations that are not integrated with Active Directory have lots of problems and those that are integrated with Active Directory seem to go smoothly. At least for us.

Reply
0 Kudos
stfconsulting
Enthusiast
Enthusiast
Jump to solution

At this point we are going to walk away from the existing server and build a new one / migrate DBs. Not worth the effort of putting more time into an older install. So wierd that the SSO install can go that bad that vmware themselves cannot figure out how to fix it.

Reply
0 Kudos
mjha
Hot Shot
Hot Shot
Jump to solution

I am also facing the similar kind of issue. Here is my environment details:

O.S: Server 2008 R2 Enterprise (My base machine)

Domain Controller + DNS : Server 2003 standard running inside vmware workstation 11.0 which is installed on server 2008 base machine

Network Settings:

On server 2008: VMnet8 has been configured with 192.168.0.x network

server 2003 VM: Network has been selected as custom and VMnet8 (NAT) has been selected

I can ping my domain controller using both IP and Name from server 2008 machine

I can ping my server 2008 machine using both IP and Name from server 2003 machine

server 2008 has been joined to domain

I tried installing VC using both Domain Admin and Local administrator but it is not installing and failing in very first stage (after sso configuration dialogue it rolls back)

If i remove server 2008 machine from domain then installation is going smooth.

Can anyone help me here.

Please consider marking this answer "correct" or "helpful" if you think your query have been answered correctly. Manish Jha | Operations Support Engineer | vCloud Air Operations vExpert 2015-17 | vExpert-NSX | vExpert-Cloud | VCAP6-DCV | VCP6-DCV | RHCE-7 Website : http://vstellar.com
Reply
0 Kudos
JohnSmith420
Contributor
Contributor
Jump to solution

Hey,

Thank you for posting your question. I understand that you’re receiving error 1603 during program installation.

You may have to verify security permissions of Program Files (x86) and Program Files folders. Make sure administrative privileges are provided to these folders- located in system drive, usually drive C:\.

A setup program sometimes require short file name creation. The problem arises when your Registry settings determine this feature is disabled. Modify your computer’s Registry very carefully and set NtfsDisable8dot3NameCreation=0 (Remember, 0 indicates this feature will not be disabled). Here is guide on modifying this string located in root Local Machine sub key.

Another possibility is that the Windows Installer service has been stopped. In this case, the program installation fails with an error. Restart the service using Windows Service Management tool, i.e. Services.msc

Thanks and Regards,

John Smith

Reply
0 Kudos