When using the popular vCenter Converter tool for performing a Physical-to-Virtual (P2V) or Virtual-to-Virtual (V2V) migration of Microsoft Windows, the MachineGuid (HKLM->SOFTWARE->Microsoft->Cryptography->MachineGuid) can change based on your migration settings.
By default, the Reconfigure destination virtual machine option is selected to help ensure the converted virtual machine will properly start in the destination environment as outlined in the vCenter Converter documentation.
If you wish to preserve the MachineGuid, then you simply need to uncheck this box before starting the migration. For modern versions of Windows, this should not be a problem but if you are converting older releases, you should verify that converter workload will startup properly before utilizing this setting.
Furthermore, if you simply cloned a Windows VM in vSphere, the default behavior is to generate a new BIOS UUID which directly affects the MachineGUID. To prevent this behavior, you can add an additional VM Advanced Setting to "keep" the original BIOS UUID as outlined in VMware KB 1541 and this behavior is simliar to de-selecting the vCenter Converter setting based on my quick test.
Hi, would this also retain disk IDs (required for MSCS disks)?
Not sure, you'll have to try it out and see for your specific OS. For older OS, there's not been a way to globally identify disks, at least not in any reliable fashion. I think it was only in modern OSes that there's now a way via UUID but something you'll want to experiment with
I think I will - cheers!
Feel free to report back on your findings, especially for the version of operating systems
Hiya, I tried with 2003 64-bit - but it wouldn't start the VM after unchecking the re-configure box.
I have had problems with this in the past, including with Windows Server 2016, V2V from Hyper-V.
The MachineGuid is contained in the file names under C:\ProgramData\Microsoft\Crypto\Keys.
If the ID changes, Windows no longer finds the private keys of the certificates.
In my opinion, the MachineGuid should not be changed in the default setting.
Dude you're a lifesaver! I'm in the middle of a HyperV to VMware project and the Machine keys resetting has caused so many issues! Especially with IIS servers. I will definitely be trying this out.
What happens when you have a client that moves an Exchange server from host to host using the conversion tool, doesn't select keep and also deletes the original VM and it then breaks the machine? I have tried editing the bios.uuid and changing it to the extracted machineGUID, but that didn't fix things.
Currently, we are waiting on a restore, but I am afraid we will be right back in the same boat when creating a new VM and attaching the VMDK file.
FYI. Using the 6.4 Converter with Windows 2012, source and destination vCenters are the same. We are using the tool to minimize downtime on 6TB VMs moving from Intel to AMD and no shared storage (ROBO). Anyway, even though I do not reconfigure destination machine, the target VM has a new GUID before power on. I've tested that manually editing it back to the original and adding uuid.action = "keep" works, but this is contrary to your post. Also, a random observsatition when doing these V2V (vC 8u1d) is that after the target boots up, and the services get started (about 5 minutes), the converter application (running in converted guest) reconnects to vCenter and reverts back to snapshot.
Does not work with Server 2019, I converted from one free ESXi (6.7) to a new one (8.0.2). I tried without the "Reconfigure" tickbox mentioned above, with action.uuid = "keep" in source and destination vmx. Even when setting the uuid.bios manually to the old one and setting uuid.action = "keep" in the dest vmx file uuid.bios is not preserved during startup on the des ESXi host. Which makes a new software registration necessary in my case 🙁