During my first migration from VMware vCenter 6.0 to VMware vCenter 6.5 Virtual appliance, the migration failed. The migration installation UI would shutdown the source VM, and numerous errors would occur afterwards when the destination vCenter appliance would try finishing configuration.
If you were monitoring the source vCenter server, during the export process, one would notice that an error pops up while compressing the source data. The error presented is generated from Windows creating an archive (zip file), the error reads: “The compressed (zipped) folder is invalid or corrupted.”. The entire migration process halts until you dismiss this message, with the entire migration ultimately failing (at first it appears to continue, but ultimately fails).
If you continued, and had the migration fail. You’ll need to power off the failed (new) vCenter appliance (it’s garbage now), and you’ll need to power on the source (original) vCenter server. The active directory trust will no longer exist at this point, so you’ll need to log on with a local (non-domain) account (on the source server), and re-create the computer trust on the domain using the netdom command:
netdom resetpwd /s:SERVERNAMEOFDOMAINCONTROLLER /ud:DOMAIN\ADMINACCOUNT /pd:*
After re-creating the trust, restart the original vCenter server. You have now reverted to your original vCenter instance and can retry the migration.
Now back to the main issue. I tried a bunch of different things and wasted an entire evening (checking character lengths on paths/filenames, trying different settings, pausing processes in case timeouts were being hit, etc…) however finally I noticed that the compression archive would crash/fail on a file called “vum_registry”.
VUM brings VMware Update Manager to mind, which I do have installed, configured, and running.
I went ahead and uninstalled VMware Update Manager off my source server (as it’s easy enough to re-configure from scratch after the migration). I then proceeded to initiate a migration. To my surprise, the “data to migrate” went from 7.9GB to 2.4GB. This is a huge sign that something was messed up with my VMware update manager deployment (even though it was working fine). I’m assuming there were either filenames that were too long (exceeded the 260 character limit on paths and filenames), special characters were being used where they shouldn’t, or something else was messed up.
After the uninstall of Update Manager, the migration completed successfully. Leave a comment!
[…] A note on a problem I dealt with during the migration process (which involved exporting VMware Update Manager from the source server) can be found here: http://www.stephenwagner.com/?p=1115 […]
Thanks; I had this same problem. I managed to abort the migration task before the AD trust was removed though, so all I had to do was reboot the vcenter server, uninstall VUM and give it another go.. running now!
I had the same issue. Uninstalling VUM was not enough for me. Probably an issue with the uninstaller but I had to take the VUM Database offline before the error disappeared. Hopefully this will help others.
Hi – if I uninstall the Update Manager the migration assistant pre-checks fail (the very first time) saying something about an internal error with Update Manager and I can’t get any further. It looks like the plugin is still in the web client which I can disable but it’s like it hasn’t uninstalled it properly. Or is this usual behaviour? I didn’t check the databases after uninstalling so to confirm, will the UpdateManager DB still be there after uninstall? If so I could try taking it offline before attempting again. Have tried this 3 times already. Grrrr……
Hi all, I’ve the same problem but uninstalling vum and taking offline vum database didn’t help.. data decreases a lot but error is always on file vum_registry.csv 🙁
Hi OrsoBianco,
You’ll notice up a few comments, you’ll notice “KoenVB” suggested taking the VUM database offline. Try giving that a shot.
Also, did you restart the server after the uninstallation of VUM?
Cheers,
Stephen
Hi, I’ve already tried with vum db offline with no success, but finally I’ve found the cause!
Previous attempt has created vum_registry.csv and so on files (for example a vum…zip file) but when you do a new test, those files remain in the temp directory (for example c:\users\myuser\appdata\…\vmwaremigrationassistant\….\) and a new attempt does not delete that garbage, they will be used even if vum is uninstalled!
I’ve deleted those files and everything works fine!
Thanks 🙂
That’s great! I’m glad you figured it out.
And thank you for posting the details on your fix, as I’m sure it’ll be able to help others!
I also had to take the VUM database offline, just uninstalling VUM wasn’t enough. For what it’s worth, I had my vCenter and VUM databases on a separate SQL server.
Just ran across this issue today. Thank you for all the time you just saved me tracking down the issue.
Had the same issue. VMware support had suggested uninstalling VUM, but didn’t mention taking the database offline. After doing that, and cleaning out the migration assistant directory, the migration succeeded.
Thanks!
Glad to hear it worked out!
Thanks, saved my butt. I also had to unregister vcIntegrity extension.
Glad it helped!
Cheers
[…] The migration first failed with a error that was helpfully detailed by another person here […]
Hello, I’ve been reading this comments and I compiled some of the issues people have been having into with VUM uninstall issues into a detailed blog post, and I also referenced your original post. Check it out if you are having VUM issues —
http://opsandautomation.com/2017/10/17/windows-vmware-vcenter-6-0-to-6-5-vcsa-migration-issues/
[…] seen VMware VUM cause numerous issues over the years with upgrades. VUM has caused issues upgrading from earlier versions to 6.x, and in this case it caused this issue upgrading to vCSA 7.x as […]