How to Reset an Azure Virtual Machine to Factory Settings Using a Managed Disk

Azure does not have a single "factory reset" button. What it does have is something better: the OS Disk Swap — a method that swaps out the corrupted or misconfigured OS disk for a clean Windows Server managed disk without deleting the VM, its NICs, its IP addresses, or any attached data disks. Here is how it works, when to use it, and the exact steps to execute it safely.

Francis Avorgbedor

Azure Engineer

July 16, 2026

15 min read

Azure VMs · Windows Server · Real-World Fix

Methods to achieve a clean Windows Server installation on an existing Azure VM

~15min

Typical OS Disk Swap duration — VM retains its NICs, IPs, and data disks throughout

Data disks affected by an OS Disk Swap — data disks remain attached and untouched

Snapshot of the original OS disk you must take before starting — no exceptions

Introduction

Why Azure Does Not Have a Simple Factory Reset — and What to Do Instead

On a physical server, a factory reset means booting from installation media and reinstalling the operating system. Azure does not have a factory reset button, and for good reason — the concept of "factory settings" for a cloud VM is more nuanced. Your VM is not just its operating system. It is a collection of resources: the OS disk, data disks, network interface cards, public and private IP addresses, network security group associations, extensions, backup policies, and monitoring agents. A true factory reset that destroyed all of this to clean-install a new OS would eliminate most of what makes the VM valuable.

What engineers typically need when they reach for a "factory reset" is one of three things: a clean Windows Server installation because the current one is corrupted or infected; a fresh start after severe misconfiguration that cannot be cleanly reversed; or a known-good state restore after a security incident. All three of these can be achieved on Azure without deleting the VM — using the OS Disk Swap, which replaces only the OS disk while leaving everything else (NICs, IPs, data disks, resource group membership, monitoring configurations) intact.

This article covers three approaches: the OS Disk Swap (the recommended method for most scenarios), the Delete and Redeploy approach (for when you want to start completely fresh including a new VM), and the Mounted ISO reinstall (for reinstalling Windows Server without deleting the VM configuration). Each approach is documented with step-by-step instructions and the exact PowerShell and CLI commands used in production.

Choose Your Approach

Three Methods — Which One Is Right for Your Situation

Method 1 · Recommended

OS Disk Swap via Managed Disk

Create a new clean Windows Server managed disk from a marketplace image, then swap it in as the VM's OS disk. The VM keeps its NICs, IPs, data disks, extensions, and resource group membership.

Best for: corrupted OS, malware infection, severe misconfiguration, wanting a clean OS while keeping the VM's network identity.

Best choice for most scenarios

Method 2 · Nuclear option

Delete VM + Redeploy

Delete the VM (keeping disks and NICs), then redeploy a new VM using the retained NIC and data disks. Achieves a completely clean state. IP addresses may change unless using static allocation.

Best for: when you want a complete clean start, when the VM configuration itself is suspect, or when you need to change the VM size as part of the reset.

When you need a full fresh start

Method 3 · In-place reinstall

Mounted ISO Reinstall

Attach a Windows Server ISO as a managed disk to the VM, boot from it, and perform a clean installation that overwrites the existing OS partition. Similar to a bare-metal reinstall via iDRAC/iLO.

Best for: when you need to reinstall Windows Server in place without changing the disk or VM configuration. Requires Azure Serial Console access.

Alternative when OS disk must stay

Factor	Method 1: OS Disk Swap	Method 2: Delete + Redeploy	Method 3: ISO Reinstall
VM NIC / IP retained	✓ Yes — fully preserved	~ NIC kept if static IP set	✓ Yes — no change
Data disks retained	✓ Untouched	✓ Detach and reattach	✓ Untouched
Extensions / monitoring	~ Reinstall after swap	✗ Full redeploy needed	~ May survive or need reinstall
OS is truly clean/fresh	✓ Brand new managed disk	✓ New VM from image	✓ Overwrites OS partition
Time to complete	~15 minutes	~30–45 minutes	~60–90 minutes
Risk level	Low — reversible via snapshot	Medium — VM deleted	Medium — OS overwritten
Requires VM downtime	Yes — VM must be deallocated	Yes — VM deleted and recreated	Yes — boot from ISO
Azure Backup required pre-step	Snapshot of OS disk	Snapshot of all disks	Snapshot of OS disk

⚠ Take a Snapshot Before You Start — No Exceptions

All three methods are irreversible without a snapshot. Before executing any of these procedures, create a snapshot of the current OS disk. If the OS disk swap fails or the new disk has issues, the snapshot lets you restore the original state in minutes. A snapshot costs a few pence per day of storage and takes under three minutes to create. There is no valid reason to skip it.

For Method 2, also snapshot all data disks. For Method 3, snapshot the OS disk. The snapshot step is documented in Step 1 of each method below.

Method 1 — Recommended Approach

Method 1: OS Disk Swap — The Right Way to Factory Reset an Azure VM

The OS Disk Swap is the cleanest and safest approach to achieving a factory-fresh Windows Server installation on an existing Azure VM. It works by creating a new managed disk from a clean Windows Server marketplace image, stopping the VM, swapping the OS disk to the new clean disk, and restarting. The VM's NICs, private and public IPs, data disks, NSG associations, and resource group membership are completely unaffected.

Figure 1 — OS Disk Swap concept: what changes and what stays the same

Only the OS disk changes — all other VM resources remain exactly as they were. The VM name, IP addresses, and data disks are completely unaffected.

Figure 2 — OS Disk Swap process flow: six phases from snapshot to verification

The entire swap — phases 3 through 5 — typically completes in under 15 minutes. Phases 1 and 2 (snapshot and disk creation) take an additional 10–20 minutes.

1

Azure Portal → Disks → [OS Disk name] → Create snapshot

Create a snapshot of the current OS disk — your rollback safety net

In the Azure portal, navigate to your VM → Disks → click the OS disk name → Create snapshot. Name the snapshot with a clear timestamp: for example vm-prod-01-osdisk-snapshot-20260716. Select Full as the snapshot type (not incremental — you want a complete, standalone snapshot for rollback). Select Create. The snapshot creates in 2–5 minutes. Do not proceed until the snapshot shows as Succeeded in the portal. Alternatively, use PowerShell as shown below.

PowerShell — Step 1: Create a snapshot of the current OS disk# Variables — update for your environment $resourceGroup = "rg-prod"
$vmName = "vm-prod-01"
$location = "uksouth"
$snapshotName = "$vmName-osdisk-snapshot-$(Get-Date -Format 'yyyyMMdd')"

# Get the current OS disk resource ID $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
$osDiskId = $vm.StorageProfile.OsDisk.ManagedDisk.Id

# Create the snapshot configuration $snapshotConfig = New-AzSnapshotConfig `
  -SourceUri $osDiskId `
  -Location $location `
  -CreateOption Copy `
  -SkuName Standard_LRS

# Create the snapshot New-AzSnapshot -Snapshot $snapshotConfig -SnapshotName $snapshotName -ResourceGroupName $resourceGroup
Write-Host "Snapshot created: $snapshotName" -ForegroundColor Green

2

Azure Portal → Disks → Create → Image: Windows Server 2022 Datacenter

Create a new clean managed disk from a Windows Server marketplace image

Navigate to Disks → Create. Set the resource group and region to match your VM. Under Disk source, select Image. In the image search, find the Windows Server version you need — for example Windows Server 2022 Datacenter: Azure Edition. Select the appropriate generation (Gen 2 recommended for all new deployments). Set the disk size to match or exceed the current OS disk size (check the VM's Disks blade for the current OS disk size — the new disk must be the same size or larger). Select Review + create → Create. The disk creation takes 3–8 minutes.

Name the new disk clearly: vm-prod-01-osdisk-clean-20260716. This naming helps when you need to identify which disk is active in the portal.

PowerShell — Step 2: Create a new clean Windows Server managed disk from a marketplace image# Create a clean Windows Server 2022 managed disk from the Azure marketplace image $cleanDiskName = "$vmName-osdisk-clean-$(Get-Date -Format 'yyyyMMdd')"

# Get the Windows Server 2022 image reference $image = Get-AzVMImage -Location $location `
  -PublisherName "MicrosoftWindowsServer" `
  -Offer "WindowsServer" `
  -Sku "2022-Datacenter-Azure-Edition" | `
  Select-Object -Last 1 # Get the latest version

# Get the current OS disk size so the new disk matches $currentDiskSize = (Get-AzDisk -ResourceGroupName $resourceGroup `
  -DiskName $vm.StorageProfile.OsDisk.Name).DiskSizeGB

# Create the new clean disk configuration $diskConfig = New-AzDiskConfig `
  -Location $location `
  -CreateOption FromImage `
  -ImageReference @{Id = $image.Id} `
  -OsType Windows `
  -DiskSizeGB $currentDiskSize `
  -SkuName Premium_LRS # Use Standard_LRS for standard VM, Premium_LRS for premium-capable VM sizes

# Create the managed disk $cleanDisk = New-AzDisk -ResourceGroupName $resourceGroup -DiskName $cleanDiskName -Disk $diskConfig
Write-Host "Clean disk created: $($cleanDisk.Name)" -ForegroundColor Green

3

Azure Portal → VM → Overview → Stop (deallocate)

Stop and deallocate the VM

Navigate to your VM in the Azure portal → Overview → Stop. Confirm you want to stop the VM. Wait until the VM status shows Stopped (deallocated) — not just Stopped. A stopped but not deallocated VM still has compute resources allocated and may not allow disk swap operations. Deallocated means all compute is released. This typically takes 2–3 minutes. Alternatively, use PowerShell to ensure the VM is in the correct state.

4

Portal → VM → Disks → Swap OS Disk — OR — Use PowerShell (recommended)

Swap the OS disk to the clean managed disk

This is the critical step. In the Azure portal, navigate to the VM → Disks → Swap OS Disk. Select the clean managed disk created in Step 2. Select OK. Alternatively — and preferably for production environments — use PowerShell. The portal method works, but the PowerShell method provides a clear audit trail in your runbook log.

PowerShell — Steps 3 and 4: Stop VM, swap OS disk, start VM# Step 3: Stop and deallocate the VM Write-Host "Stopping VM: $vmName" -ForegroundColor Yellow
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force

# Verify VM is deallocated before proceeding $vmStatus = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Status
$powerState = ($vmStatus.Statuses | Where-Object {$_.Code -like "PowerState/*"}).DisplayStatus
Write-Host "VM Power State: $powerState" -ForegroundColor Cyan
# Expected: VM deallocated

# Step 4: Get the VM object and the clean disk object $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
$cleanDisk = Get-AzDisk -ResourceGroupName $resourceGroup -Name $cleanDiskName

# Swap the OS disk — point the VM to the new clean disk Write-Host "Swapping OS disk to: $cleanDiskName" -ForegroundColor Yellow
Set-AzVMOSDisk -VM $vm -ManagedDiskId $cleanDisk.Id -Name $cleanDisk.Name

# Apply the change to the VM in Azure Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
Write-Host "OS disk swapped successfully" -ForegroundColor Green

# Step 5: Start the VM with the new clean OS disk Write-Host "Starting VM with fresh OS disk..." -ForegroundColor Yellow
Start-AzVM -Name $vmName -ResourceGroupName $resourceGroup
Write-Host "VM started: $vmName — now running clean Windows Server" -ForegroundColor Green

5

Azure Portal → VM → Connect → RDP or Bastion

Connect to the VM and verify the fresh installation

After the VM starts, connect via RDP or Azure Bastion. The first boot of the clean OS disk takes 5–10 minutes to complete Windows Server initial configuration. You will be prompted to set a local Administrator password (or it will use the Admin credentials from the original VM deployment — this depends on how the marketplace image handles the first-boot agent). Once logged in, verify the OS version in System Properties: winver or systeminfo | findstr "OS Name". Confirm data disk drive letters are correct — the data disks were retained and should appear in Disk Management.

6

Post-swap configuration: reinstall extensions, rejoin domain, restore agents

The fresh OS disk does not carry any of the previous configurations, extensions, or agents. Post-swap, you must: rejoin the VM to the Active Directory domain if required; reinstall the Azure Monitor agent or Log Analytics agent; reinstall any custom VM extensions (Azure Backup agent, Defender for Cloud agent, custom script extensions); re-enable Azure Backup for the VM; and reconfigure any application workloads that were running on the VM. The data disks are all still attached — verify they are accessible and drive letters are assigned correctly in Disk Management before reinstalling applications.

✓ Rollback: How to Restore the Original OS Disk

If anything goes wrong with the new OS disk, roll back by running the same PowerShell swap procedure in reverse — pointing the VM back at the original OS disk (which still exists as an unattached managed disk). Alternatively, create a new managed disk from the snapshot taken in Step 1 and swap to that. The VM's NICs, IPs, and data disks are unaffected by either the forward or reverse swap.

Do not delete the old OS disk until you have validated the new disk for at least 48 hours. The old disk incurs minimal storage cost and provides your rollback path during that validation window.

Method 2 — Delete and Redeploy

Method 2

Method 2: Delete the VM and Redeploy — When You Need a Complete Fresh Start

If the OS Disk Swap is not sufficient — for example, when the VM's configuration itself is suspect or you need to change the VM size — deleting the VM (keeping the disks and NICs) and redeploying a new VM from scratch gives you the cleanest possible result. Azure separates the VM resource from its disk and network resources. Deleting the VM does not delete the OS disk, data disks, or NIC unless you explicitly select those options during deletion.

Figure 3 — Delete and Redeploy: what gets deleted, what gets retained, and how to reassemble

The critical step is unchecking "Delete OS disk", "Delete data disks", and "Delete NIC" during VM deletion — these checkboxes default to checked in the portal

1

VM → Overview → Delete → UNCHECK all delete options

Delete the VM resource — critically, retain all disks and NICs

Navigate to the VM in the Azure portal → Overview → Delete. The deletion confirmation dialog shows checkboxes for deleting OS disk, data disks, and NICs. Uncheck all three. Type the VM name to confirm and select Delete. The VM resource is deleted but all disks and NICs remain as independent managed resources. This takes 2–3 minutes. After deletion, verify the OS disk, data disks, and NIC still exist in the resource group under their respective resource types (Disks and Network Interfaces).

2

Azure Portal → Create a resource → Virtual Machine → Use existing disk or new image

Create a new VM, reusing the existing NIC

Navigate to Create a resource → Virtual Machine. On the Networking tab, under Network interface, select Use existing NIC and choose the retained NIC. This preserves the private IP address. On the Disks tab, for the OS disk select Create and attach a new disk from a Windows Server marketplace image — this is the fresh installation. After the VM is created, attach the data disks via VM → Disks → Attach existing disk for each data disk.

Method 3 — Mounted ISO Reinstall

Method 3

Method 3: Mounted ISO Reinstall — Reinstalling Windows Server In Place

This method mirrors what you would do on a physical server with iDRAC or iLO: attach an ISO file as a virtual DVD drive, configure the VM to boot from it, and run the Windows Server installer to overwrite the existing OS partition. On Azure, this is achieved by attaching a Windows Server ISO as a managed disk and using Azure Serial Console to initiate the boot sequence.

This method is appropriate when you specifically need to keep the same OS disk and reinstall Windows Server in place — for example, when auditing requirements mandate that the same disk resource ID appears in asset records, or when the OS disk encryption configuration must be preserved.

1

Create the Windows Server installation media as a managed disk

Azure's in-place upgrade documentation provides a PowerShell script to create a Windows Server installation media disk directly from Azure's hosted ISO. The same disk can be used to install Windows Server fresh. Run the script in Azure Cloud Shell or locally with the Az PowerShell module. The script creates a managed disk named Win2022UpgradeDisk (or whichever Windows Server version you specify) in your resource group. This takes 5–10 minutes.

PowerShell — Create Windows Server 2022 installation media disk (run in Azure Cloud Shell)# This script creates a managed disk containing the Windows Server 2022 installation media # Source: Microsoft Learn — Windows in-place upgrade for Azure VMs
$Location = "uksouth" # Must match your VM's region
$ResourceGroup = "rg-prod"
$DiskName = "WinServer2022-InstallMedia"

# Get the gallery image for Windows Server 2022 $Gallery = Get-AzGallery -GalleryName "CloudImgGalWindowsServer" -ResourceGroupName "AzureCloudEssentials"

# Create the installation media disk configuration $mediaConfig = @{
  Location = $Location
  CreateOption = 'FromImage'
  GalleryImageReference = @{Id = "/subscriptions/8a5f67d7-9d7b-4ae9-a4c2-a2c9f1200b81/resourceGroups/AzureCloudEssentials/providers/Microsoft.Compute/galleries/CloudImgGalWindowsServer/images/WindowsServer2022Datacenter/versions/latest"}
}

# Alternative: Use Azure's hosted Windows Server 2022 image directly $diskConfig = New-AzDiskConfig -Location $Location -CreateOption FromImage `
  -ImageReference @{Id = "/CommunityGalleries/AzureCommunity-c6c642fd-4c12-4d62-8028-3a8c5e9b9c4f/Images/WinServer2022-Install-Media/Versions/latest"} `
  -OsType Windows -DiskSizeGB 128 -SkuName Standard_LRS

New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig
Write-Host "Installation media disk created: $DiskName" -ForegroundColor Green

2

Azure Portal → VM → Disks → Attach existing disk → Select installation media disk

Attach the installation media disk to the VM as a data disk

Navigate to the VM → Disks → Attach existing disk. Select the WinServer2022-InstallMedia disk created in Step 1. Assign it a LUN number (for example, LUN 1). Select Save. The disk appears inside the VM as an additional drive (for example, D: or E: depending on what other disks are attached). This is the installation media — the equivalent of inserting a USB installer drive.

3

VM → Connect → Bastion or RDP → Navigate to installation media drive

Connect to the VM and launch the Windows Server setup from the installation media

Connect to the VM via RDP or Azure Bastion. Open File Explorer and navigate to the drive letter where the installation media disk was mounted (for example, D:\). Double-click setup.exe to launch the Windows Server Setup wizard. On the What do you want to do screen, select Install Windows only (advanced) — this performs a clean installation rather than an in-place upgrade. On the Where do you want to install Windows? screen, select the existing OS partition (typically Drive 0 Partition 2 — the Windows partition), select Format, and then select Next. The installer formats the OS partition and installs a clean copy of Windows Server.

The VM will restart multiple times during installation. Use Azure Bastion for reliable connectivity — RDP sessions will disconnect during restarts and you will need to reconnect after each one.

4

After installation: Detach the installation media disk

Detach the installation media disk after the installation completes

After Windows Server installation completes and the VM boots cleanly, navigate to the VM → Disks → detach the installation media disk. The installation media disk can be reused for other VMs but can only be attached to one VM at a time. Store it as a shared resource in your resource group for future use. Return to Azure and configure the VM: reset the local Administrator password via VM → Reset password, rejoin the domain, reinstall monitoring agents, and re-enable Azure Backup.

Post-Reset Configuration

What to Do After the Factory Reset — The Mandatory Post-Reset Checklist

Regardless of which method you used, a freshly installed Windows Server on an Azure VM requires a standard set of post-installation configuration steps before it is production-ready. These steps apply to all three methods.

Reset the local Administrator password — navigate to VM → Reset password in the Azure portal. Azure's VM Agent extension handles this without requiring a running OS session.
Verify data disk drive letters — open Disk Management (diskmgmt.msc) and confirm all data disks are online and have the expected drive letters. If drive letters changed, update application configuration accordingly.
Install Windows Updates — a fresh Windows Server installation from a marketplace image may be months behind on patches. Run Windows Update immediately and restart as required.
Rejoin the Active Directory domain — if the VM was domain-joined, the fresh OS is not. Rejoin using the domain credentials and the same computer account name (or create a new one if the old account was deleted during the incident that required the reset).
Reinstall the Azure Monitor Agent — navigate to VM → Extensions + applications → Add → search for Azure Monitor Agent. Install and configure the data collection rules to resume log streaming to Log Analytics.
Re-enable Azure Backup — navigate to Backup centre → Configure backup → Azure Virtual Machine. Select the Recovery Services vault and re-enable the backup policy for the VM.
Reinstall application workloads — reinstall the applications or server roles that were running on the VM. Data disks containing application data are still attached — only the OS installation needs to be re-done.

Key Takeaways

✓Azure does not have a single factory reset button — but the OS Disk Swap achieves the same outcome in ~15 minutes while preserving all VM networking, data disks, and resource group membership.

✓Always create a snapshot of the current OS disk before any reset method. The snapshot is your rollback path and takes under 3 minutes to create.

✓Use /COPY:DATSO Method 1 (OS Disk Swap) for most scenarios — it is the fastest, safest, and most reversible approach. Use Method 2 (Delete + Redeploy) only when you need to change the VM size or configuration, not just the OS.

✓When deleting a VM for Method 2, uncheck "Delete OS disk", "Delete data disks", and "Delete NIC" in the portal — these checkboxes default to checked and permanently delete those resources if not unchecked.

✓The new OS disk from the marketplace image does not carry any previous configurations — domain membership, monitoring agents, extensions, and application workloads must all be reinstalled after the reset.

✓Do not delete the old OS disk for at least 48 hours after the swap. It is your rollback path during the validation window and incurs negligible storage cost.

✓The installation media disk created for Method 3 can be reused across multiple VMs — store it as a shared resource in your resource group rather than deleting it after each use.

Frequently Asked Questions

Will the VM's private and public IP addresses change after an OS Disk Swap?

No. The OS Disk Swap does not affect the VM's network interface card or its IP allocations. If the VM has a static private IP and a static public IP, both are retained. If the public IP is dynamic, it may change on VM restart — convert it to static before the swap if you need it to remain the same.

Can I swap to a different version of Windows Server — for example from 2019 to 2022?

Yes. The OS Disk Swap supports swapping to a different Windows Server version. You can swap from a Windows Server 2019 disk to a Windows Server 2022 disk. The constraint is that you cannot change the OS type — you cannot swap a Windows OS disk for a Linux OS disk or vice versa. Also ensure the VM size supports the Windows Server version you are deploying — Windows Server 2025 requires a Gen 2 VM.

Does the OS Disk Swap work if the current OS disk uses Azure Disk Encryption?

Partially. If the current VM uses Azure Disk Encryption, the replacement OS disk being swapped in must also use Azure Disk Encryption — you cannot mix an encrypted VM with an unencrypted OS disk. For a clean marketplace-image disk, you would need to enable encryption on the new disk after the swap and before the next boot, or use a snapshot from a previously encrypted disk as the source for the new disk.

What happens to Azure Backup after an OS Disk Swap?

The existing Azure Backup policy for the VM remains associated with the VM resource — it is not deleted during the swap. However, the backup chain for the OS disk changes because the OS disk ID changes. The next backup after the swap will be a full backup of the new OS disk rather than an incremental backup. Re-enable or verify the backup policy in the Azure portal after the swap to confirm backups resume correctly.

Can I perform an OS Disk Swap on a VM that is part of an Availability Set?

Yes. The OS Disk Swap is supported for VMs in Availability Sets. The process is identical — stop/deallocate the VM, swap the disk, restart. The VM's Availability Set membership is not affected. For VMs in a Virtual Machine Scale Set, the approach is different — individual instance disk swaps in a Scale Set require reimaging the instance rather than swapping the disk.

Is the local Administrator password from the old OS disk preserved after a swap?

No. The fresh Windows Server disk from the marketplace image uses the Administrator credentials configured during the first boot. After the swap, use the Azure portal's Reset password feature (VM → Reset password) to set a new local Administrator password. This works via the Azure VM Agent and does not require an active RDP session.

Enterprise Azure & AI Engineering Playbooks

Search This Blog