Clone VM and Deploy it on VMware

Question

I created VM disks from Snapshots in Azure and used them in VMware. However when connected to the new VM, they clash with the original VM due to the copied configs even after changing the hostanem and IP

Answer 1

I think the snapshot is just the full copy of the os disk and the vm on vmware boots with the same state as the original. and the safe way is make a clean vm on vmware and attach that converted disk only as data and copy what u need.

Answer 2

The behavior is caused by cloning a Windows VM disk without properly generalizing or regenerating its identity (SID, machine ID, etc.). Even if hostname and IP are changed, the cloned guest can still share internal identifiers with the original, which leads to clashes (especially in domain/cluster scenarios or when security updates enforce stricter checks).

From the provided context, the supported and reliable way to avoid these conflicts is:

1. Do not reuse a raw copied disk as a new independent server without identity regeneration.
   • When VMs are cloned incorrectly, they can end up with identical SIDs/UUIDs. After certain security updates, this causes authentication and communication failures between machines.
2. Use proper cloning/customization mechanisms when creating the template/source VM:
   • In VMware or Hyper‑V environments, use sysprep/customization specs or templates with “Generate new identity” options so that each clone gets unique SIDs/UUIDs.
   • The context notes that issues appeared on servers that had identical SIDs due to a failed cloning process; the final fix was to rebuild those VMs correctly using sysprep and proper templates.
3. For already‑cloned disks that are conflicting:
   • The robust remediation is to rebuild the VM from a properly prepared template rather than continuing to run a direct disk copy.
   • For critical workloads (such as SQL Server clusters or domain controllers), the recommendation in the context was to perform fresh OS installs and reconfigure the applications to ensure supportability and avoid subtle identity issues.
4. If using domain controllers or clustered roles:
   • Follow the documented domain controller cloning process (for Hyper‑V/Windows Server) that uses New-ADDCCloneConfigFile and the VM‑Generation ID, rather than raw disk copies. This ensures the clone is recognized as a new DC and avoids duplicate identities.

In practice for this scenario (Azure snapshot → VMDK → VMware):

• Treat the disk as a source for data only, not as a fully formed, identity‑safe VM.
• Build a new VM in VMware from a clean, sysprepped template (or fresh install), then attach the converted disk as a secondary disk to copy data, instead of booting directly from the cloned system disk.
• For future migrations, prepare the Azure VM with sysprep/generalization or use a proper migration tool that regenerates machine identity on the target platform.

---

References:

• Virtualized Domain Controller Deployment and Configuration
• KB5065426 Security update - SQL Server Failover cluster (AlwaysOn) problems - Microsoft Q&A