Error 29107 Upgrading vCenter to 5.1

[HIsgett]

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. 

[GTO455]

So dumb question here...

If you have everything running on one server; vCenter Server, vCenter Single Sign On, the Lookup Service, the Inventory Service, and Update Manager, do you have to create certs for all of these services now? Or can you just use the cert you generated for the system itself for all of these services?

In past versions, I just created one certificate for the system that ran vCenter, Inventory Service and Update Manager all on one system. I replaced the VMware self generated certs with the my local CA signed cert and all was well. (Of course other steps were involved including updating the DB and update Manager, but nothing compared to this upgrade).

Edit: I should probably add that I am uusing a local CA cert with multiple SAN's (Subject Alternate Names) including 2 different domains and the server shortname. From reading the VMware documentation on certificates, this doesn't seem to be an issue, but......

Cert looks like this.....

• Issued To: vcenterserver.myproddomain.com

Subject Alternate Names:

• vcenterserver
• vcenterserver.myADdomain.com
• vcenterserver.myproddomain.com

[GrandmasterPhil]

GTO - people are having problems using a single certificate; there is a rumor that they have to be different.  I don't know of anyone who has a working solution with one cert.  I've switched to just system generated certs (see below).

SkullCandy - amending my previous post, I got the product installed, but the VCenter Service kept crashing and restarting.  The logs suggested this was due to trying to download a STS Certificate (probably one of the custom generated ones done during the original SSO installation).

SO:

If you followed the procedure to do the certificates, my final upgrade fix was to uninstall VCenter, Inventory, and SSO service.  Delete all SSL certificates from the ProgramData\SSL folders (there are 3 places to look, two for VMware itself and one for intentory service).  Then reinstall the three components - SSO, Intentory, VCenter.  It regenerates the certificates and WORKS.

Phil

[GTO455]

Well, I'm glad you got it working and that's great for those who can use the VMware generated certs, but I can't.

The security policy here requires certs from our local CA. Besides, it makes for a cleaner install and you don't get those annoying untrusted cert notifications when using a trusted cert.

[GrandmasterPhil]

Makes sense, but you'll have to wait for a definitive fix before upgrading.   VMware really screwed v5.1 upgrades; it's Symantec-esq.

[bedobash]

for a new install, or a non-production upgrade, reverting all certificates to self-signed, and then upgrading from 5.0U1 to 5.1 is a feasible option to get a function 5.1 deployment.

VMware has published a document on replacing all 5.1 certificates with CA/ECA signed certificates. Has anyone tried to execute this document following successful 5.1 upgrade/install?

I'm much more concerned with upgrading production 4.1 with CA signed certificates to 5.1. Reverting production to self-signed certificates is NOT the answer. VMware needs to fix this ASAP.

[GTO455]

That's kind of what Derek's blog does, it marries the upgrade with the VMware cert guide and the VMware upgrade guide. It is a very detailed write up and done well.

I ended up trying the upgrade again yesterday using the individual components (SSO, Inventory, vCenter instead of the Simple Install) and a mixture of the upgrade guide, the certificate replacement guide and Derek's blog. I ran into an issue binding the certs to the three services (Part 3 of Derek's blog) and rolled back. Of course that 29155-Identity source discovery error popped up again as well, but at least you can get by that. I think I'm on my 3rd attempt now.

This upgrade is definitely not for the faint of heart, and it seems like it is way more difficult than it should be.

In my opinion, I think VMware should have broken this up a bit more, possibly leaving the SSO option for after the vCenter upgrade, or introducing it later on in the year as a separate application. It should never have been bundled with this upgrade; it is making things too difficult.

[DSeaman]

I'll be updating my vCenter 5.1 series with input from Terafirma and some additional testing I'll be doing this weekend. You are right..this is way harder than it should be.

[Skullcandy]

We went ahead and rebuilt from scratch using Derek's guide, minus the portions regarding certificates. This build went smooth until we went to add Update Manager following the completion of vCenter. For reasons that make no sense the service account were trying to use is being rejected by the Update Manager install. Either their is a local machine perm were missing or vCenter has added some new area for plug-in permissions in 5.1 that we have been unable to find.

[amasonc]

I took the exact same approach as Skullcandy, I used Derek's guide to install vCenter  Single Sign On, upgrade vCenter Inventory Service, and vCenter Server.  Which went fine as well but when I attempt to upgrade Update Manager it will error out every time stating it cannot register the extension with the vCenter Server.  I followed all steps in VMware KB1003468 but the install still fails.

[DSeaman]

Wanted to update everyone on the SSL status. Currently I can't get a working vCenter using trusted certificates. I got around the vCenter install problem by leaving the Inventory certificate alone (replacing SSO seemed OK). But, then when trying to replace the vCenter certs and doing the hokey web browser method invokation dance the registration batch file fails with a certificate error about unable to read a file. But Process Monitor shows Java is successfully opening and reading the file. Replace the certs with the default certs and the file is magically readable and the registration works.

So right now the entire SSL replacement process seems quite broken. I think only VMware can fix it by issuing an update of some type. I've added warnings to my blog posts about the SSL issues and recommend people skip the SSL replacment process until VMware can fix all these issues.

[KlausK]

My upgrade experience from 5.0 to 5.1 was abysmal as well. I never could get the SSO service installed on my vCenter server machine, so it lives somewhere else now. That's good from a security point of view, but the SSO service performance is very bad.

I've also read the various comments regarding the certificate issues with great interest. I, too, embarked on replacing the self signed ones. I decided to leave the SSO certs alone and the only way I could get the vCenter Server and Inventory service to register properly was to:

* Completely uninstall vCenter Server and the Inventory service.

* Create certificates with different common names (I used "vCenter Service" and "Inventory Service") with the FQDN of the server set in the SAN attribute of the certificate. After that I put them into the respective locations on the server.

* Reinstalled the Inventory and the vCenter Server service.

If you use the same certificate for all services, registration will fail.

I hope this helps

[DSeaman]

So from what I'm hearing you say, you basically pre-populated the SSL certificate locations for the inventory and vCenter service, so when you re-installed it automatically used your trusted certs?

[KlausK]

Exactly.

[DSeaman]

That was my last resort....did yet another install with failed certificate replacement AFTER the service in question was installed. I'll wipe my lab again and see if pre-populating everything works for me as well.

I did create unique certs for each service as well, based on Terafirma's discovery.

[KlausK]

It was my last resort as well. I discovered this after messing around with it for more than 4 days. I find it quite amazing that the certificate is used as a "primary key" in the registration process, especially since by default it uses self-signed certs. I'd love to have a word with the person who had that idea...

[DSeaman]

Amazingly, the SSO certificate replacement process does appear to work as advertised. But like you found out, the Inventory Service and vCenter replacement procedures are horribly broken. 

[KlausK]

After I read through the paper of the procedure to replace the SSO certificates, I decided to not even touch that one, as my users would not see the effect of it anyway. I was disgusted enough already by my upgrade experience.

One more thing regarding setting up security in SSO and ESXi: Do not under any circumstances use AD groups in permissions on your ESXi machines in vCenter. Performance of evaluating AD groups directly will result in

• very slow vCenter Server startup times (5 - 10 minutes depending on the amount of groups)
• timouts when logging in (9 out of 10 times it will fail)

My workaround for that was to create groups in SSO and assign AD users to these groups. It's still slow, but at least it works.

I also found that in order to keep performance up, I need to reindex the RSA database on a regular basis, especially after making changes to permissions. That one really amazes me, since that database has very few tables and is no more than 10 MB.

[DSeaman]

Pre-populating the SSL certificates did NOT work for me. The vCenter server installer still died with Error 26002.Setup failed to Register VMware vCenter server to VMware vCenter Inventory Service.

In my "subject" value for each certificate I have a different "OU" value. One is "InventoryService" and the other is "vCenterServer". The other values (CN, O, L, S, C) are all the same. Are you saying you changed the CN value to be descriptive of the service and not the FQDN of the server?

Exactly which value did you change in your SSL certs, when viewing them in Windows Explorer?

[KlausK]

The common name needs to be different, i.e. the CN value.

The actual hostname (as the FQDN) will be specified in the Subject Alternative Name. If you are issuing certs from a Mirosoft CA, you need to first enable it to use the SAN attribute. After that you can specify the SAN either in the CSR directly (if you use OpenSSL to generate the CSR) or in the CertSrv util when requesting the certificate as an additional attribute (Syntax: SAN:DNS=<FQDN of server>).

if you look at the self-signed cert generated by the installer, they do it exactly in that fashion.

[aSmoot]

I encountered this same problem in our lab, vCenter upgrade to 5.1 failed at end with this error message.  I found a workaround using a method discussed here, but I haven't studied the logs or found root cause yet.  My scenario was this:

• In 2011 -New, clean install of vCenter 5.0 with vCenter Server, Inventory Service and Web Client all on same VM
• Replaced certs for all three services with same cert from internal CA (Win 2008)
• Today - Unregistered, then uninstalled Web Client service to move to another machine in prep for 5.1 upgrade
• Installed SSO service with no issue
• Upgraded Inventory Service with no issues, same certs left in place
• Backed up the certs for vCenter as instructed by VMware guide
• Installed vCenter Server upgrade to 5.1 (database and existing service detected) which bombed at end with 29107 error.
• Tried upgrade again, but vCenter service gone and not detected.   Database still seen as upgrade

To Fix

• Uninstall Inventory Service
• Delete SSL folder from Inventory Service directories to remove the certs I installed
• Reinstalled 5.1 Inventory Service which generated to self-signed certs
• Ran vCenter Server 5.1 installation again, this time it succeeded all the way through.
• vCenter appears to be intact and upgraded fine.

Note: At the step where you add account or security group to SSO service to administrator, be sure to change that to your VMwareAdmins or ESX Admins security group in AD and use the UPN.    This dialog will default to the local Administrators group and will not work from what I saw on other pages.

I will update this when I have more.