Check retained machine identity before reusing an Azure Windows OS disk

Source facts

Microsoft’s specialized-disk workflow creates a new Azure Windows VM around an existing operating-system disk. The resulting guest keeps the original computer name and other machine-specific identifiers, including CMID; duplicated identifiers can affect applications. The portal procedure requires the selected disk to be unattached. Microsoft also documents creating a snapshot-derived disk while retaining the original as a fallback. Microsoft Learn.

Applicability

Use this review for a particular retained Windows installation, not an empty VM or a generalized-image rollout. Identify whether the request replaces a failed VM or creates a separate copy. Ask the application owner which stored machine identifiers matter to that purpose.

DSE recommendation

Treat the specialized disk as an existing machine identity and approve its intended replacement or copy role before starting the new VM. Record the source VM, selected disk, proposed Azure resource name, and expected guest identity separately. Decide how the source installation will be isolated during the test. Prefer an approved snapshot-derived working disk when preserving the original is part of the recovery plan.

Verification

Before accepting the replacement, inspect its guest computer name and application-specific identity, then compare them with the planned outcome. Exercise the application in the approved network context and investigate any duplicate-identity warning. Keep the disk lineage and resource identifiers with the recovery record. Do not discard the preserved source solely because the new Azure resource reports successful creation.

Official references

Microsoft Learn: Attach an existing OS disk to a VM. Source reviewed September 9, 2026.