Up to this point, I’ve deployed several net new instances of vCenter Server 5.5 and of course its essential components including Single Sign-On, Inventory Service, next generation Web Client, and the legacy vSphere Client. Most of these deployments leveraged the vCenter appliance. Using the appliance is a very easy to deploy vCenter because all of the essential components are pre-installed in the appliance and only need to be configured.
One area I hadn’t tackled much yet are upgrades of existing Windows-based vCenter environments to vSphere 5.5. Having recently completed an inline upgrade of vCloud Director 5.1.2 to 5.5, it was now time to upgrade said vCloud’s underlying vSphere 5.1 (Update 1a I believe) virtual infrastructure. Prior to starting the upgrade, I took the necessary precautions of getting a point in time snapshot of the vCenter Server, the vCloud Director Cells, and the Microsoft SQL Server databases for each (three total: SSO, vCenter, and vCD). I accomplished this using array based snapshots – in this case Dell Compellent Storage Center Replays.
I launched autorun from the vCenter 5.5 installation media. I opted for the custom installation and started with the Single Sign-On (SSO) upgrade from 5.1 to 5.5. During the installation, I was met with
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.
In this particular environment, self-signed certificates from VMware were in use. I know that this environment was deployed new less than two years ago and a verification of the SSL certificates in use proved that none were expired. But because SSO and vCenter are such integral components to vCloud Director, I didn’t want to proceed without further vetting this out.
Google.
Upgrade from vSphere 5.1 to vSphere 5.5 rolls back after importing Lookup Service data (2060511) – This KB article describes a situation in which Warning 25000 results when a registry value on the existing Windows-based SSO 5.1 server does not match a field on the SSL certificate. The resolution involves simply changing the registry value to match that which is on the SSL certificate. I won’t repeat the details because you can read the KB article yourself. Furthermore it didn’t resolve the problem in this case because the field on my SSL certificate and the registry key were an identical match.
Upgrading to VMware vCenter Single Sign-On 5.5 displays the error: Warning 25000 (2061478) – This KB article describes a problem for which there is no resolution. However, there is a workaround and that involves changing service_id and service.properties files. More detail is available in the KB article and again the symptoms in the log files weren’t a close match.
The Trouble With SSL Certificates and Upgrading to VMware SSO 5.5 – Then I took a look at Michael Webster’s blog article on precisely the same error message. Michael briefly discusses the two SSL certificate deployment models and then digs into VMware KB 2060511 mentioned above. While the information in Michael’s blog article reassured me I was not alone in my journey, KB 2060511 didn’t solve my problem either. But sometimes the value of blog articles is not only in the original author’s content, but also in the follow up comments from the readers. Such was the case here. A number of Michael’s readers responded by saying they were essentially in the same boat I’m in – it sounds like KB 2060511, but in the end this article doesn’t have the solution because there was nothing wrong with their SSO registry values. The readers found no choice but to push onward beyond Warning 25000 with fingers crossed. As it turned out in my as well as with some others, Warning 25000 was benign in nature and the installation completed successfully with no rollback.
In summary, this blog post does not represent global authority to ignore Warning 25000. Rather it is meant to highlight one particular scenario where Warning 25000 may present itself and the actions that were taken to work through the problem. I can’t stress enough the importance of the SSO component of vCenter going forward. If any conclusion can be drawn here, it is that a backup of the infrastructure components should be secured before committing to the upgrade steps. In this case, snapshots are the quickest and easiest method to provide data protection and recovery. Although vSphere snapshots would work in some deployment architectures, recovering an environment when the environment being upgraded is managing the snapshots could be a challenge. That is why I chose an out of band array based snapshot in this instance.
I would also like to point out in closing that vSphere 5.5 is still relatively new and VMware appears to still be chasing down all possible causes, resolutions, and workarounds to Warning 25000. New information as well as VMware KB articles may develop subsequent to this writing so it may be worth continuing your own Google searching beyond this point.
Have a great week!
