Clone VM and Deploy it on VMware

Question

Clone VM and Deploy it on VMware

Donald Motsoai 0

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

0 comments

3 answers

Your answer

Answer 1

Hello @Donald Motsoai ,

Thanks for sharing the details this behavior is expected in the scenario you described.

Even though you changed the hostname and IP, the issue still occurs because when a VM is created from an OS disk snapshot, it is a byte-for-byte copy of the original system. This means the cloned VM retains the same internal machine identity, including the Security Identifier (SID) and other system-level identifiers.

Think of it this way:

The hostname/IP is just the label
The SID is the machine’s unique identity

So even after renaming, both machines still appear identical at a deeper level, which leads to conflicts—especially in domain or network environments.

To resolve this properly, the OS must be generalized using Sysprep before reuse.

Here is the recommended flow:

Create a temporary VM from the snapshot
- This keeps your original VM unchanged.
- Confirm the VM boots normally.
Run Sysprep on the temporary VM
Open an elevated Command Prompt and run:
```
   rd /s /q C:\Windows\Panther
```
- This removes machine-specific identity (including SID).
- The VM will automatically shut down when complete.
- Do not restart it after Sysprep.
Microsoft also recommends generalizing a VM before creating reusable images to remove machine-specific information.
- Convert the generalized disk to VMDK
- Create a new VM in VMware
- Ensure VMware generates a new MAC/UUID (do not reuse original IDs)
On first boot, the VM should go through OOBE (first-time setup). A new SID will be generated automatically

Validation

After deployment, you can confirm the identity is unique by running:

whoami /user

Compare the SID with the original VM — they should now be different.

Notes

Always run Sysprep on a copy, not the production VM (the process is irreversible)
Do not clone the following workloads using this method:
- Domain Controllers
- Failover clusters / SQL AlwaysOn nodes

These require dedicated deployment methods rather than disk cloning.

Changing hostname/IP alone doesn’t resolve the issue because the underlying system identity (SID) remains the same.
Running Sysprep (/generalize) on a copy of the VM ensures a new, unique identity and prevents these conflicts.

References
https://learn.microsoft.com/en-us/azure/virtual-machines/generalize
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep-command-line-options?view=windows-11

Thanks,
Manish.

Manish Deshpande 8,135 Reputation points Microsoft External Staff Moderator

2026-06-30T13:37:58.37+00:00

Hello @Donald Motsoai

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.

Answer 2

kagiyama yutaka 5,330

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.

0 comments

Answer 3

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:

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.
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.
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.
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: