VMware Cloud Community
HIsgett
Enthusiast
Enthusiast

Error 29107 Upgrading vCenter to 5.1

I get the following error at the end of the vCenter upgrade/install while Registering with vCenter Single Sign On. What can I do to overcome this?

Error 29107. The service or solution user is already registered. Check Vm_ssoreg.log in system temporary folder for details. 

Reply
0 Kudos
52 Replies
frZe
Contributor
Contributor

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;

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100909...

And place it in C:\ProgramData\VMware\VMware VirtualCenter\SSL I was able to complete the upgrade.

Hope this works out for you.

Reply
0 Kudos
HIsgett
Enthusiast
Enthusiast

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....

Reply
0 Kudos
LarryBlanco2
Expert
Expert

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.

Larry B.

Reply
0 Kudos
LarryBlanco2
Expert
Expert

Make a backup of the DB B4 upgrading. U just may need to revert back.

Larry  

Reply
0 Kudos
Bless2blopez
Contributor
Contributor

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.

Reply
0 Kudos
tsmori
Enthusiast
Enthusiast

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?

Reply
0 Kudos
tsmori
Enthusiast
Enthusiast

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.properties
INFO  com.vmware.vim.install.impl.RegistrationProviderImpl] Intializing registration provider...
INFO  com.vmware.vim.install.impl.RegistrationProviderImpl] Getting SSL certificates for https://myhost :7444/lookupservice/sdk
DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Establishing socket connection to  myhost /myip:7444. Timeout is 60000
DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Creating VMODL client for LookupService
DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Getting the locations of SSO admin server and STS
INFO  com.vmware.vim.install.impl.RegistrationProviderImpl] Getting SSL certificates for https:// myhost :7444/sso-adminserver/sdk
DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Establishing socket connection to  myhost /myip:7444. Timeout is 60000
DEBUG com.vmware.vim.install.impl.RegistrationProviderImpl] Creating client for SSO Admin on address: https://myhost :7444/sso-adminserver/sdk
ERROR com.vmware.vim.install.cli.commands.RegisterSolutionCommand] A solution user with same subject DN is already registered
com.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.

Reply
0 Kudos
tsmori
Enthusiast
Enthusiast

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.

Reply
0 Kudos
DSeaman
Enthusiast
Enthusiast

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.

Derek Seaman
Reply
0 Kudos
Duco
Enthusiast
Enthusiast

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 ...

Duco

Reply
0 Kudos
qiskevin
Contributor
Contributor

tsmori -

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.

Duco -

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.

Kevin

Reply
0 Kudos
tsmori
Enthusiast
Enthusiast

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.

http://communities.vmware.com/message/2115464

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.

Reply
0 Kudos
GTO455
Enthusiast
Enthusiast

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!

Reply
0 Kudos
bedobash
Enthusiast
Enthusiast

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.

Reply
0 Kudos
sevoadm
Contributor
Contributor

Hello Evereybody,

i experienced the exact same Error, and i got it working with just deleting all Content from the SSL Folder of vCenter Server.

But dont forget to Backup all Data before.

Greetz Sebastian

Reply
0 Kudos
Skullcandy
Contributor
Contributor

We attempted sevo's fix after using Derek Seaman (DSeaman) blog and found that it prompted as a new install, rather then an upgrade. We decided to give this a shot after pulling down a fresh copy of our database. Install proceeded to about the same point where we hit a new error that had to do with the Inventory Service not being properly registered. This leaves us back where we were.

Has anyone found the fix for this as of today?

Reply
0 Kudos
DSeaman
Enthusiast
Enthusiast

Skullcandy, I have an open ticket with VMware regarding the Error 26002 inventory service registration problem. Not a peep back yet on a possible resolution. Smiley Sad

Derek Seaman
Reply
0 Kudos
doubleH
Expert
Expert

Thank you for your message. I am currently out of the office and will return September 20.

For support related issues please contact the IT Service Desk servicedesk@camhydro.com or x2700.

Thank you

Heath

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points
Reply
0 Kudos
GrandmasterPhil
Contributor
Contributor

Skullcandy -

Yes, you can delete the SSL certificates as suggested earlier.  But if you followed the blog guide, then you also copied your custom SSL certificates to the Inventory service.  I had to uninstall the Inventory Service, delete the SSL certificates from the Inventory\SSL folder, then reinstall the Inventory Service.

This got me past the Inventory Registration page, and a successful install.

Hope this helps.

Reply
0 Kudos