Recently, a customer of mine decided that it’s time to upgrade to vCenter 4.1. So he took a backup of the database and blew away the 32-bit Windows server. He then installed Windows 2008 R2, SQL Server Express 2008 R2 with Advanced Services and imported the DB back in – created a 64-bit DSN, and started installing vCenter. You then choose to upgrade the database to 4.1…
… only to be told that vCenter won’t install without your old certificates in the All Users profile which can be found in
- Windows 2000/2003/XP: c:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
- Windows 2008/2008/Vista/7: c:\programdata\VMware\VMware VirtualCenter\SSL
VMware’s vCenter installer says you can’t do it unless you have a certificate back up or have already imported the certificates into the new server at the default locations (above)
That’s a lie. You can do it. You just have to accept that it’s going to be a little bit more manual and you’ll have to reconnect all your ESX/i hosts afterwards.
Here’s how to do it:
- Blow away your restored database (but keep the backup)
- Create a new database with a SQL db_owner user identical to the username of the SQL db_owner user on the old server.
- Create a new SQL 64-bit DSN
- Install vCenter as a brand new install.
- Stop the VMware VirtualCenter service
- Stop the VMware WebServices service
- Open SQL Management Studio and restore the backed up DB over the top of the new DB
- If you are using SQL authentication open a new query window and execute the following statement:
sp_change_users_login “auto_fix”, ‘vmware’
This marries the orphaned SQL db_owner in the database to the newly created login in point 2 above - Open the command prompt and in the installation directory of VirtualCenter, run the following:
vpxd -p
You will be asked to input a password – use the same password as that of the SQL db_owner user for your database. This re-initializes/re-encrypts the database with the newly installed certificates and removes references to the old certificates which got blown away during the OS reinstall.
At this point you can fire up your vCenter and reconnect all your hosts – this is a manual task but once finished, everything will be fine.
What I haven’t been tested is the effect of doing this on plugins such as Update Manager that share column space in the vCenter DB (yes you can separate the DBs but not all people do). Thankfully, a quick google revealed this document in VMware’s KB which might help – it has to do with the password defaults for certificates, not the password defaults for the DB, so I might be leading you up the wrong alley.
Nonetheless, this neatly avoids the issue of restores, or having to re-implement all the customisations in your VC (including dvSwitches).
Cheers,
Leo
