How to Configure Remote Desktop Web Access on Windows Server 2022

Introduction

Hyper-V checkpoints (previously called snapshots) allow you to capture the state of a virtual machine at a specific point in time and later revert to that state if needed. On Windows Server 2022, Hyper-V offers two checkpoint types — Standard and Production — each designed for different use cases. The PowerShell-based management tools for checkpoints (Checkpoint-VM, Get-VMCheckpoint, Restore-VMCheckpoint, Remove-VMCheckpoint) give administrators full control over the checkpoint lifecycle from the command line, making it straightforward to automate checkpoint management as part of maintenance workflows. This guide covers checkpoint types, creating and listing checkpoints, applying and deleting them, the underlying differencing disk mechanism, storage impact, and best practices for production environments.

Checkpoint Types: Standard vs Production

Hyper-V on Windows Server 2022 supports two checkpoint types, and the distinction is important for both data consistency and application compatibility:

Standard Checkpoints capture the VM’s memory state, device state, and disk state at the exact moment the checkpoint is taken. This includes the in-memory state of running applications and the OS. When you restore a Standard Checkpoint, the VM returns to exactly the state it was in — including any in-flight transactions, open network connections, or partially written data. This is useful for development and test VMs where you need a precise rollback point, but it is problematic for production VMs running databases or applications that rely on crash consistency, because the restored state may include memory that was not flushed to disk.

Production Checkpoints use the Volume Shadow Copy Service (VSS) on Windows guest VMs (or file system freeze on Linux guests) to create an application-consistent checkpoint. The guest OS flushes all pending writes to disk and quiesces application I/O before the checkpoint is captured. No memory state is saved — only the disk state. This means the VM behaves as if it had been cleanly shut down and restarted when restored, ensuring that databases and other I/O-intensive applications recover cleanly without corruption. Production Checkpoints are the default type in Windows Server 2022 Hyper-V.

Check or change the checkpoint type for a VM using PowerShell:

Get-VM -Name "WebServer01" | Select-Object Name, CheckpointType

Change to Production Checkpoints (fallback to Standard if VSS is unavailable):

Set-VM -Name "WebServer01" -CheckpointType Production

Change to Standard Checkpoints:

Set-VM -Name "WebServer01" -CheckpointType Standard

To use Production Checkpoints exclusively with no fallback to Standard:

Set-VM -Name "WebServer01" -CheckpointType ProductionOnly

Creating Checkpoints

The Checkpoint-VM cmdlet creates a new checkpoint for a VM. The VM can be running or stopped. For Production Checkpoints on a running VM, Hyper-V coordinates with the guest’s VSS provider to ensure consistency:

Checkpoint-VM -Name "WebServer01" -SnapshotName "Before-Patch-Tuesday-2025-05"

If you do not provide a -SnapshotName, Hyper-V generates a name based on the VM name and current timestamp. It is always better to use a descriptive name so you can identify checkpoints later:

Checkpoint-VM -Name "SQLServer01" -SnapshotName "Pre-SQL2022-CU12-$(Get-Date -Format 'yyyyMMdd-HHmm')"

To checkpoint all running VMs on the host (useful before a patch window):

Get-VM | Where-Object {$_.State -eq "Running"} | ForEach-Object {
    Checkpoint-VM -VM $_ -SnapshotName "Pre-Maintenance-$(Get-Date -Format 'yyyyMMdd')"
    Write-Host "Checkpoint created for $($_.Name)"
}

The cmdlet runs synchronously and returns when the checkpoint is complete. For large VMs with significant memory (if using Standard Checkpoints), this may take several seconds to minutes depending on RAM size and storage speed.

Listing Checkpoints

Use Get-VMCheckpoint to retrieve checkpoints for a VM. The output includes the checkpoint name, creation time, checkpoint type, and parent checkpoint ID (for checkpoint chains):

Get-VMCheckpoint -VMName "WebServer01"

To display all checkpoints for all VMs on the host:

Get-VM | ForEach-Object { Get-VMCheckpoint -VMName $_.Name } | Select-Object VMName, Name, CreationTime, CheckpointType | Format-Table -AutoSize

To find all checkpoints older than 30 days (helps identify stale checkpoints consuming storage):

Get-VM | ForEach-Object {
    Get-VMCheckpoint -VMName $_.Name
} | Where-Object { $_.CreationTime -lt (Get-Date).AddDays(-30) } | Select-Object VMName, Name, CreationTime

To get detailed information about a specific checkpoint including the parent checkpoint:

Get-VMCheckpoint -VMName "WebServer01" -Name "Before-Patch-Tuesday-2025-05" | Format-List *

Applying (Restoring) a Checkpoint

Restore-VMCheckpoint reverts the VM to the state captured in a checkpoint. If the VM is running, it will be powered off before the restore. This is a destructive operation — any changes made after the checkpoint was taken will be lost:

$checkpoint = Get-VMCheckpoint -VMName "WebServer01" -Name "Before-Patch-Tuesday-2025-05"
Restore-VMCheckpoint -VMCheckpoint $checkpoint -Confirm:$false

After restoring, start the VM manually if it should be running:

Start-VM -Name "WebServer01"

To combine retrieval and restoration in one pipeline:

Get-VMCheckpoint -VMName "WebServer01" -Name "Before-Patch-Tuesday-2025-05" | Restore-VMCheckpoint -Confirm:$false
Start-VM -Name "WebServer01"

If the VM has multiple checkpoints forming a chain (child checkpoints), restoring a parent checkpoint does not delete the child checkpoints — they remain but are disconnected from the current VM state. You can still restore them later, or delete them if they are no longer needed.

Deleting Checkpoints

Remove-VMCheckpoint deletes a checkpoint. The checkpoint’s differencing disk is merged back into the parent disk, which may take considerable time for large VMs with significant checkpoint data. The VM can remain running during this merge:

Get-VMCheckpoint -VMName "WebServer01" -Name "Before-Patch-Tuesday-2025-05" | Remove-VMCheckpoint -Confirm:$false

To delete all checkpoints for a VM:

Get-VMCheckpoint -VMName "WebServer01" | Remove-VMCheckpoint -Confirm:$false

Deleting a checkpoint that has child checkpoints will also remove the child checkpoints — Hyper-V cannot maintain a chain without its parent. To delete only checkpoints older than a specified date:

Get-VM | ForEach-Object {
    Get-VMCheckpoint -VMName $_.Name |
    Where-Object { $_.CreationTime -lt (Get-Date).AddDays(-14) } |
    Remove-VMCheckpoint -Confirm:$false
    Write-Host "Removed old checkpoints for $($_.Name)"
}

Note that Remove-VMCheckpoint initiates the merge operation but returns immediately. The actual disk merge runs in the background. You can monitor merge progress by watching the AVHD/AVHDX file sizes in the VM’s storage directory decrease over time.

Merging Checkpoints

When you delete a checkpoint, Hyper-V merges the differencing disk (the AVHDX file associated with the checkpoint) back into its parent disk. This process is called checkpoint merging. For a running VM, Hyper-V performs an online merge — it copies the differencing disk blocks to the parent while the VM continues running, with a brief pause at the end to complete the merge. This minimises downtime but requires sufficient disk I/O capacity on the storage subsystem.

You can force an immediate merge of all checkpoints for a VM by removing all checkpoints in sequence and then using the Merge-VHD cmdlet if needed for offline VHDX files. However, the standard Remove-VMCheckpoint approach is sufficient for most cases.

To verify that all checkpoint AVHDX files have been merged and cleaned up, check the VM’s storage files:

Get-VMHardDiskDrive -VMName "WebServer01" | Select-Object VMName, Path
Get-ChildItem -Path "C:Hyper-VVMsWebServer01" -Include "*.avhdx","*.avhd" -Recurse

If no AVHDX or AVHD files exist, all checkpoints have been fully merged.

Configuring Automatic Checkpoints

Windows Server 2022 Hyper-V includes an automatic checkpoints feature that creates a Production Checkpoint before any configuration change to a running VM (such as adding hardware). This is controlled per-VM via Set-VM:

Set-VM -Name "WebServer01" -AutomaticCheckpointsEnabled $true

Disable automatic checkpoints for a VM (recommended for production VMs where storage space is managed carefully):

Set-VM -Name "WebServer01" -AutomaticCheckpointsEnabled $false

Check the current automatic checkpoint setting for all VMs:

Get-VM | Select-Object Name, AutomaticCheckpointsEnabled | Format-Table -AutoSize

Disable automatic checkpoints for all VMs at once:

Get-VM | Set-VM -AutomaticCheckpointsEnabled $false

In production, automatic checkpoints should generally be disabled because they accumulate over time, consume disk space, and are not subject to a retention policy unless explicitly managed. Instead, create checkpoints deliberately as part of change management procedures.

Checkpoint Storage Impact and Differencing Disks

When a checkpoint is created, Hyper-V creates a new differencing disk (AVHDX file) linked to the current base disk (VHDX). All subsequent writes from the VM go to this AVHDX file rather than the base VHDX. The base disk becomes read-only for the duration the checkpoint exists.

The AVHDX file grows as the VM writes new data. In a worst case (where the entire disk is rewritten), the AVHDX file can grow to the same size as the original VHDX. Each additional checkpoint in the chain creates another AVHDX, creating a chain: VHDX → AVHDX1 → AVHDX2 → AVHDX3 → … (current). Deep checkpoint chains degrade VM I/O performance because each read must potentially walk the entire chain to find data that has not been overwritten in newer differencing disks.

Best practices for checkpoint storage:

Store VHDX and AVHDX files on fast storage (SSD or NVMe). Long checkpoint chains on spinning disks cause severe performance degradation. Limit checkpoint chains to 3-5 levels maximum. Check the current checkpoint file paths:

Get-VM -Name "WebServer01" | Select-Object -ExpandProperty SnapshotFileLocation

You can separate the checkpoint AVHDX storage location from the base VHDX by configuring the snapshot file location:

Set-VM -Name "WebServer01" -SnapshotFileLocation "D:CheckpointsWebServer01"

Checkpoints in Production Environments

Checkpoints are not a substitute for backups in production environments. A checkpoint only protects against logical errors (bad patches, misconfigurations) by providing a rollback point — it does not protect against hardware failure, storage corruption, or the loss of the entire Hyper-V host. Always maintain independent backups using Windows Server Backup, Azure Backup, or a dedicated backup solution.

Recommended production checkpoint strategy:

Before planned maintenance (patches, upgrades): Create a Production Checkpoint manually, apply changes, verify functionality, then delete the checkpoint after a validation window (typically 24-48 hours). Use descriptive names including the date and purpose:

Checkpoint-VM -Name "WebServer01" -SnapshotName "Pre-KB5034439-$(Get-Date -Format 'yyyyMMdd')"

Do not leave checkpoints running indefinitely in production. The longer a checkpoint chain grows, the more AVHDX data accumulates, the more storage is consumed, and the worse I/O performance becomes. A good workflow is: create checkpoint → apply change → verify → delete checkpoint within the same maintenance window.

For databases (SQL Server, AD DS), always use Production Checkpoints to ensure VSS consistency. Standard Checkpoints on database VMs risk restoring to a state with uncommitted transactions that the database engine will roll back on startup, potentially causing data loss in transactions that were committed after the checkpoint was taken.

Exporting a Checkpoint

You can export a VM from a checkpoint state without reverting the live VM. This is useful for creating a test copy from a specific point in time:

$checkpoint = Get-VMCheckpoint -VMName "WebServer01" -Name "Before-Patch-Tuesday-2025-05"
Export-VMSnapshot -VMCheckpoint $checkpoint -Path "D:VMExports"

The exported VM is a complete standalone copy that can be imported on another Hyper-V host for testing without affecting the live VM.

Conclusion

Hyper-V checkpoints on Windows Server 2022 are a powerful operational tool when used correctly. Production Checkpoints provide application-consistent state capture suitable for VMs running databases and critical services. PowerShell cmdlets (Checkpoint-VM, Get-VMCheckpoint, Restore-VMCheckpoint, Remove-VMCheckpoint) give administrators full control over the checkpoint lifecycle. By understanding the differencing disk mechanism, managing checkpoint storage thoughtfully, disabling automatic checkpoints in production, and treating checkpoints as a short-term change safety net rather than a backup strategy, you can use Hyper-V checkpoints effectively without compromising VM performance or storage capacity.