If you’re upgrading from vSphere 5.1 to vSphere 5.5 and you ARE NOT using Custom CA SSL Certificates then you might run into an error. The error will be encountered during the upgrade of SSO, and specifically the Lookup Service, and only occurs in specific conditions, such as when using the default VMware Self-Signed Certificates. If you run into this problem your upgrade process will roll back, but leave behind some upgrade files that need to be cleaned up. This article will briefly touch on the recommended solution to this problem.
Many of you will recall the many articles that I wrote regarding updating the default self-signed SSL Certificates in vSphere 5.0 and 5.1 to Custom CA Certificates. If you haven’t seen these articles and you’re interested in SSL Security you can check out Updating CA SSL Certificates in vSphere 5.1 and Updating CA SSL Certificates in vSphere 5. To make the process of updating certificates easier VMware created the VMware Certificate Automation Tool and VMware Partner VSS Labs created vCert Manager. If you’re using CA Signed Certificates for your SSL communications between the various vCenter components then you won’t strike the problem I described above. So now might be a good time to review my previous articles and/or use one of the automation solutions that are available.
This issue during the upgrade from vCenter 5.1 to vCenter 5.5 is described in the VMware KB Article – Upgrade from vSphere 5.1 to vSphere 5.5 rolls back after importing Lookup Service data (2060511). You will likely see an error such as “Warning 25000. Please verify that the SSL certificate for your vCenter Single Sign-On 5.1 SSL is not expired. If it did expire, please replace it with a valid certificate before upgrading to vCenter Single Sign-On 5.5.” or the vCenter Upgrade will simply fail and roll back. In the vim-sso-msi.log you will see an error message like the following:
“Action 10:06:03: PostInstallScripts. Importing Lookupservice data…
CustomAction DoUpdateAndMigrateTasks returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)”
As described in the VMware KB this issue does not affect you if:
- You are using custom certificates (recommended)
- You are using the vCenter Server Virtual Appliance (only applies to the Windows version of vCenter Server)
- You are performing a fresh install of vCenter Server 5.5
- You are upgrading from:
- vCenter Server 5.0
- vCenter Server 4.x
- a fresh install of vCenter Server 5.1 Update 1a or later
For the recommended fix please refer to the VMware KB – Upgrade from vSphere 5.1 to vSphere 5.5 rolls back after importing Lookup Service data (2060511). The fix will require modifying the Windows Registry. Before any upgrade of vCenter is attempted it is recommended that you take a backup and potentially have a snapshot in place for the vCenter Database and the vCenter Server system itself so you have a point you can roll back to. This should be standard practice in most VMware environments, as should testing the upgrade process, as should upgrading test environments and management environments before upgrading production. Given that this impacts environments that have self-signed certificates it has the potential to impact a large number of customers, however as it only impacts customers upgrading from vCenter 5.1 prior to version Update 1a to vCenter 5.5, the number of impacted customers is reduced.
The easiest way to get around this problem if you’re using vCenter 5.1 would be to either run through the registry fix described in the KB article. Upgrading to vCenter 5.1 U1b will not correct the issue as it doesn’t correct the certificate. You may also choose to completely rebuild your vCenter with a fresh install of vCenter 5.5 against your existing database. Alternatively you may choose to update your vCenter Server to use CA Signed Certificates, which will also improve the security of your critical management infrastructure. Regardless of the option you choose make sure you have a backup of the vCenter Database and vCenter so you can roll back if needed.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.