After a lot of debugging I found that in my case it was the certificate which was the issue.
After regenerating a new certificate according to;
And place it in C:\ProgramData\VMware\VMware VirtualCenter\SSL I was able to complete the upgrade.
Hope this works out for you.
I think the upgrade was set to fail to begin with for some reason. It took uninstalling everything, restoring the database, reinstalling the version of vCenter that was running and then starting the upgrade again. This time the upgrade completed successfully. I dunno....
I too encountered this error. Could not find anything in SSO or it's logs. Ended up uninstalling everything, restoring the DB, reinstalling the previous version (Version 5.0U1), and reinstalling 5.1 afterwards.
It worked without a hitch then.
Make a backup of the DB B4 upgrading. U just may need to revert back.
I had the same error as well. As stated by others I had to uninstall all vCenter 5.0 update 1 components except update manager and reinstall 5.0 update1. I also had to uninstall the inventory service and the SSO server. In my case all three components, SSO, inventory service, and vCenter was installed on the same host.
I also could not find any logs for the SSO. I do not use the default certificates which get installed by vCenter for the production environment but when I did the re-install I did not update the certificate. I left everything at default and proceeded with the upgrade to vCenter 5.1
Server OS: Windows Server 2008 R2 SP1
Database: MS SQL Server 2005 SP4
I hope VMware responds with a way to avoid this problem. I got a second instance of vCenter to upgrade.
I've hit this too. I reverted to a snapshot and re-installed everything, but I hit the error again. I cannot imagine what service or solution user would already be registered. I found some scripts in the SSOserver folder to list the services, but services and solutions seem to be different things and I don't know which User it would be talking about. The only user is the one the SSO service creates.
Maybe because I installed everything as a local administrator and not with a Domain account?
I tried to run this on my test stack and I hit the same error. I'm pretty sure it has something to do with the certificates. I created all new CA signed certs and had updated all my components prior to the upgrade and they all worked fine.
The error in the logs states the following:DEBUG com.vmware.vim.install.cli.RegTool] Executing command: registerSolution -d https://myhost:7444/lookupservice/sdk -ip C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool\vcsso.properties -r read -u admin@System-Domain -p *****DEBUG com.vmware.vim.install.cli.commands.util.ParserUtil] Parsing properties file: C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool\vcsso.propertiesINFO com.vmware.vim.install.impl.RegistrationProviderImpl] Intializing registration provider...INFO com.vmware.vim.install.impl.RegistrationProviderImpl] Getting SSL certificates for https://myhost :7444/lookupservice/sdkDEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Establishing socket connection to myhost /myip:7444. Timeout is 60000DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Creating VMODL client for LookupServiceDEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Getting the locations of SSO admin server and STSINFO com.vmware.vim.install.impl.RegistrationProviderImpl] Getting SSL certificates for https:// myhost :7444/sso-adminserver/sdkDEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Establishing socket connection to myhost /myip:7444. Timeout is 60000DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Creating client for SSO Admin on address: https://myhost :7444/sso-adminserver/sdkERROR com.vmware.vim.install.cli.commands.RegisterSolutionCommand] A solution user with same subject DN is already registeredcom.vmware.vim.sso.admin.exception.DuplicateSolutionCertificateException: A solution user with same subject DN is already registered
Since the error boils down to the vCenter install attempting to register a solution user with the same subjectDN, I can only assume it's getting that from the SSL cert. I just don't understand why it's a duplicate and why the hell it matters and why it kills the install, especially at a point where it cannot roll back to the original vCenter.
It's also really frustrating that there isn't any way to interact with the SSO service except through vCenter.
Just to follow up with this in case anyone is following it. On my test stack, I was able to complete the "simple install" by restoring the original VMware self-signed certificates to vCenter, Inventory Service and the Web Client Server.
Clearly the problem stems from either a problem with my Microsoft CA certs, or the CA itself. I attempted to re-do the certificates making sure to include the SubjectAltName as this is required for vCenter and making sure to use a modified version of the Web Server certificate that supports that attribute, but it still gave me that error.
I'm pretty sure the certificates are correct, so it's possible that the modified web server profile on my CA is wrong somehow.
I'm in the same boat. After much troubleshooting, I do concur that it appears to related to certificates. When I was encoutering the problem I was installing the customized SSL certs (from a MS 2008 R2 CA) after each component (SSO, inventory, etc.) per their certificate guide PDF. I would then get stuck on the error the OP has and fail.
If, however, I started with a fresh VM from my template and did a complete install without touching any SSL certs vCenter Server would install without a problem. So clearly installing the trusted certs from the MS CA (or maybe any CA, I don't know) along the way caused the problem.
Had the same problem here.
Replaced the wilcard certificate I had installed with the original certificates that where installed during installation, for both the vCenter Server and the Inventory Service.
This time my upgarde succeeded.
I read somewhere SSO uses teh common name in the certificate for a service to uniquely identify the service. Since I had a wildcard certificate installed, it probably used the same common name for both the Inventory Service and later on the vCenter Server, so then complains the service is allready known ...
This would mean I can not use my wildcard certificate anymore ...
We had been encountering the same problem, and we too replaced our CA-signed certs with the default ones we had previously backed up. This allowed us to do the upgrade using the simple install process. Before restoring the default certs, we tried generating new self-signed certs, which didn't work. We also tried uninstalling vCenter Server, deleting everything out of all SSL folders (vCenter Server, Inventory, Web Client), and then re-installing vCenter Server. In that case new certs were generated, but we still got the error when upgrading. After restoring the default certs and successfully upgrading, I took a look at the SSL certs for the various components, and they were different. I didn't try it, but I wonder if when I generated the new self-signed certs, if using a unique Subject for each service would also have solved the problem... That may be something to try for those folks who are having this problem but no longer have the default certs.
I opened a ticket with VMware on this problem, and one of the things they told me is that they do not support wildcard certs. They suggested using a CA-signed non-wildcard cert for vCenter itself, and leaving the individual ESXi hosts as self-signed.
Clearly there's a problem using certificates from a Windows 2008 R2 CA. Everything I've read about upgrading to View 5.1 was to update all the SSL certificates and I'm sure some of you have followed the blogs and documentation on how to do this. Following those directions you end up using the same SSL certificate for vCenter and the Inventory service (and the Web Server).
To try and get past Error 29107, I created new SSL certificates and changed the Organization for each in the Subject, setting one to vCenter and another to Inventory. Restarted services and everything seemed to work just fine.
Now when I run the simple install, I get a new error, Error 26002. Setup Failed to register VMware vCenter Server to VMware vCenter Inventory Service. And the install again just fails and rolls everything back.
There's also at least one community post regarding this error and the fix is the same, restore to self-signed certs.
This is a problem for me because to update to View 5.1, I've already updated all my SSL certificates. Eventually, when View is updated to support vCenter 5.1, I'm going to want to upgrade, but I'm going to encounter this unless VMware figures it out. I put a ticket in, but I feel like I got the brush off regarding the issue.
I'm having the same installation issue with error 29107. I also ran in the 29155-Identity source discovery error.
I happen to have 2 sets of certs for my system; one set was created on the system itself and the other using OpenSSL. The cert created on the system was created in error so we were using the OpenSSL cert. We have a Windows 2008 CA as well.
We also have multiple DNS domains- an AD domain (ad.local) and a "company" domain (mycompany.com) and use both interchangeably.
For cert created on the system itself, I used the AD domain as the primary name with the company domain as an alternate name when submitting the request. For the OpenSSL cert I created, I used the company domain as the primary name and the AD domain as the alternate name.
The initial upgrade failed using the OpenSSL certs with the company domain. After researching and coming upon this thread, I re-ran the setup using the AD domain cert and the upgrade completely successfully. When I tried to replace the AD domain cert with the company domain cert after the upgrade, vCenter would not start.
Good thing this instance of vCenter I'm ruinning is a VM and not in production yet, or else I would have been screwed. My prod vCenter server is on physical hardware.
This is a huge issue for us. We use CA signed certs for vCenter as well as all of our ESXi hosts. I'm putting off all upgrades until this is fixed.
I cannot believe that VMware told some folks to use self-signed certs, especially when their own hardening guide tells you to replace them!
My entire experience trying to upgrade a physical "lab" vCenter 5.0 setup was abysmal. Upgrade failed with this error, I couldn't find the original certificates, so after completely uninstalling everything, and deleting the contents of the SSL folder, I was able to complete a regular install. However, SSO wasn't working correctly with Active Directory, and I continued to experience errors (unable to delete [AD Group] principals from SSO groups) and other bizarre behavior. After 5 hours of trying numerous things to get vCenter and SSO to talk, I gave up and rolled everything back.
I'll try the simple install on a standalone VM just to get it up and running, but I have NO confidence that SSO is fit for general production use AT ALL in its current state.