When you upgrade or patch vCenter Server 6.0 for Windows, you may see following symptoms:
“The older version of cis-upgrade-runner cannot be removed. Contact your technical support group.”
Or error code 1063:
“Installation of component VMware CIS upgrade runner failed with error code ‘1063’”
That means the vCenter Server installer cannot find MSI files of existing vCenter Server services. It could be following reasons:
- You delete MSI files in “Temp” folder of the profile you used to install vCenter Server.
- The account you used to login and install vCenter Server was roaming profile. The profile’s “Temp” folder was automatically deleted when you reboot/logoff the server.
vCenter Server 6.0 for Windows is consist of lot of standalone package. The upgrading process usually uninstall old packages, and then install newer packages. So the failure doesn’t impact to database or inventory data. You can re-initiate the upgrading again.
But you cannot manually uninstall old package since upgrading process brings down vCenter services first then uninstall old packages. If you already uninstalled old packages, the upgrading process will be stuck on bring down vCenter Services stage since some processes may already be removed. For example “vmware-python” it maps to “VMware vCenter Configuration Service”. If you manually uninstalled it before launch upgrading. It removes the service. Upgrading is not able to check status of the service.
Easiest way to get ride of this problem is
- Open Registry Editor (regedit) and go to the path: “HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products”
You would see lot of keys are there.
- Search keyword “vmware-“. These keys store package info of vCenter Server.
- Expand one of the keys. Go to “SourceList”.
- The value of “LastUsedSource” is path of MSI file of old vCenter Server installer.
For example my value is “m;1;X:\vcenter-server\packages\”.
- Make sure your server has the path mentioned in previous step (My case it’s X:\vcenter-server\packages\) and old MSI files are available in the path. If it’s a CD-ROM letter, you just need mount old vCenter Server image to the drive.
- Copy new vCenter Server image to a local folder, uncompresse and launch installer locally.
- Now the upgrading process can read original packages on the mentioned path in step 4. It will automatically remove old packages by the old MSI files.
There are two other workarounds. One is modify the value of “LastUsedSource” to reflect a new location of packages. But you still need the old MSI files be there. Another way is delete the key after you find it in step 2. (I never tested this way but it should work as it let vCenter Server installer thinks the server is brand new so installer can override the existing folders)
I also wrote another article for upgrading error on vCenter Server 5.5 for your reference:
CustomAction VM_InstallJRE returned actual error code 1624
Virtual appliance is future of how VMware delivery their product to customers. It’s pain to migrate from vCenter Server Windows version to virtual appliance. The only way was build up new virtual appliance and move everything out of Windows vCenter Server. The challenge is you lost data if you have integrated vCenter Server with other VMware products, or using DVS.
VMware released vCenter Server Migration Tool after VMworld 2016. It gave me confidence to give it a try. I assume vCenter Server is embedded SSO. I did the migration 2 or 3 times, following is summary of my experience. The migration tool only support migrate vCenter Server 5.5 windows edition to vCenter Server 6.0 U2.
- vCenter Server is more like core services today since lot of 3rd party software call vCenter API to interactive with VMs. You may have some products integrated with vCenter Server already. Please upgrade to vCenter 6 compatible version before migration.
- I suggest create a local account on source vCenter Server if your server is domain member. You can login back source vCenter by local account in case migration failed.
- vCenter Server Migration Tool applies temporary IP address on destination vCenter virtual appliance during migration. It’s used to communicate with source vCenter. Please register a temporary IP address for destination vCenter Server.
- A helper VM is required to run migration image. Please make sure you have a free Windows VM be ready to mount migration image.
- SQL database is exported to source vCenter Server if you want migrate performance and event data. So you need to make sure enough space on C: drive on source vCenter. The free space should be much bigger than vCenter database size.
- Of course you need a vCenter Server 6 license key since old key doesn’t support the version.
- Some cases show migration process stopped during export SQL database. That’s because memory of source vCenter is too small. Please make sure RAM of source vCenter should be equal or greater than destination vCenter Server.
- The other tricky is database table. You may see migration processes is completed but destination vCenter Server doesn’t come up, and no data actually imported. That’s because ‘checksum‘ column existing in table [dbo].[VMO_ResourceElementContent] in vCenter DB. You can run following SQL query to remove it before migration.
alter table dbo.VMO_ResourceElementContent drop column checksum;
The items above can be done anytime before the migration window. Following steps should be token during migration.
- You need to disable firewall and anti-virus software on old vCenter to avoid communication issue between Migration Assistant and new vCenter Server.
- To avoid any unstable, resource contention, or potential network connectivity lost issue, I suggest temporarily disable DRS and HA on source and destination cluster if they are virtual machine.
- Copy Migration Assistant from migration image to old vCenter.
- Take snapshot on old vCenter and backup database of old vCenter.
- Connect to console of source vCenter and run Migration Assistant.
- Mount vCenter Server 6 U2m image on helper VM. Launch vCenter migration. The migration process is straightforward. I wouldn’t introduce more here.
Basically you need to revert all the temporary changes made before. Such as delete snapshot and DB backup, enable DRS and HA, and disable vNIC on source vCenter Server to avoid any human error.