Lesson: Image Backup and Restore in Azure Virtual Desktop (AVD)

Introduction: Why Image Management Matters

In the context of Azure Virtual Desktop (AVD), the "image" acts as the foundation of your entire user experience. It contains the operating system, the specific applications your users need, and the configuration settings that define their workspace. When you manage AVD at scale, the image is not just a file; it is a living entity that requires versioning, testing, and, most importantly, a reliable recovery path. If an image update goes wrong—perhaps a faulty patch is applied or a critical software dependency is broken—the ability to revert to a known good state is the difference between a minor inconvenience and a catastrophic outage for your users.

Backup and restore strategies for AVD images are often overlooked until a crisis occurs. Many administrators focus heavily on user profile storage (FSLogix) or data backups, assuming that the virtual machine (VM) images are "disposable." While it is true that AVD host pools are designed to be dynamic and replaceable, rebuilding a custom image from scratch during an incident is time-consuming and prone to human error. This lesson explores how to implement a structured approach to backing up and restoring your gold images, ensuring your environment remains resilient and maintainable.

Understanding the Image Lifecycle

Before diving into the technical mechanics of backup and restore, we must understand the lifecycle of an AVD image. Most organizations use a "Golden Image" strategy, where a master VM is prepared, generalized via Sysprep, and then captured as an Azure Compute Gallery (ACG) Image Version. This process is cyclical: you create an image, deploy it, test it, and eventually update it.

When we talk about "backup" in this context, we are not necessarily talking about taking snapshots of production VMs, though that is part of the strategy. Instead, we are talking about protecting the image definition itself. If your Azure Compute Gallery becomes corrupted or if an image version is accidentally deleted, you lose the ability to scale your host pools. Therefore, your backup strategy must encompass both the storage of the image artifacts and the metadata that governs them.

Callout: Image vs. Snapshot It is important to distinguish between an Image Version and a VM Snapshot. A snapshot is a point-in-time copy of a specific VM's disk, often used for immediate recovery of a single machine. An Image Version, however, is a templated, generalized version of an OS used to deploy hundreds of VMs. Backing up an image means ensuring you have a permanent, immutable record that can be used to re-provision the entire fleet if necessary.

Strategies for Image Backup

There are three primary layers to backing up your AVD images. Implementing a comprehensive strategy requires addressing all three to ensure redundancy and recovery capability.

1. Azure Compute Gallery (ACG) Versioning

The most effective way to "back up" an image is through proper versioning in the Azure Compute Gallery. By treating each successful image build as a new version (e.g., 1.0.1, 1.0.2), you create a natural audit trail. If version 1.0.2 introduces a bug, you can instantly roll back your host pool configuration to point to version 1.0.1.

• Version Lifecycle Management: Use the "Exclude from latest" flag to prevent automated deployments from picking up a version that is currently undergoing testing.
• Replication: Configure the gallery to replicate images across multiple regions. This provides geographic redundancy; if one Azure region experiences a major service disruption, your images are already present in a secondary region, allowing you to deploy new host pools elsewhere.
• Immutability: Once an image version is published, it should be treated as read-only. Never attempt to "patch" an existing version; always create a new one.

2. Infrastructure-as-Code (IaC) Backups

If you are using tools like Bicep, Terraform, or PowerShell to build your images, the code itself is your backup. If your image build pipeline is stored in a version-controlled repository like GitHub or Azure DevOps, you have a historical record of exactly how that image was created.

• Scripted Builds: Keep your build scripts (e.g., Packer templates) in a repository. If the gallery is deleted, you can re-run the pipeline to recreate the images.
• Configuration Documentation: Document the exact OS version, patch level, and installed software list for every image version. This documentation serves as a "restore plan" if the automation fails.

3. Disk Snapshots and Storage

For the master VM used to create the image, you should maintain periodic snapshots of the OS disk. This is your "last resort" backup. If your build process fails halfway through, or if you lose the configuration of the master VM, a snapshot allows you to restore the master VM to its pre-failure state so you can resume the build process.

Note: Do not rely on VM snapshots as your primary deployment method. Snapshots are meant for recovery of the master VM, not for the mass deployment of AVD hosts. Always use the Azure Compute Gallery for deployment.

Step-by-Step: Protecting Your Image

To protect your images effectively, follow these steps to establish a robust workflow.

Step 1: Establish a Versioning Convention

Adopt a semantic versioning system (Major.Minor.Patch).

• Major: Significant changes (e.g., moving from Windows 10 to Windows 11).
• Minor: New applications or major feature updates.
• Patch: OS security updates or minor configuration tweaks.

Step 2: Configure Azure Compute Gallery Replication

When creating your Gallery, ensure you select multiple target regions. This is done during the resource creation phase:

1. Navigate to your Azure Compute Gallery.
2. Select Replication.
3. Add the desired regions.
4. Set the replica count to at least 2 in each region for high availability.

Step 3: Implement Automated Build Backups

Use a tool like HashiCorp Packer to define your image build. By storing these definitions in Git, you ensure that even if the Azure Portal is inaccessible or your subscription is compromised, you have the source code to recreate your environment.

// Example Packer block for an AVD image
{
  "builders": [{
    "type": "azure-arm",
    "image_publisher": "MicrosoftWindowsDesktop",
    "image_offer": "office-365",
    "image_sku": "21h2-evd-o365pp",
    "managed_image_resource_group_name": "AVD-Images-RG",
    "managed_image_name": "AVD-Golden-Image-v1-0-1"
  }]
}

Explanation: This code snippet demonstrates how to define the source image for an AVD build. By versioning this file in Git, you maintain a history of your image configurations.

Managing Image Restore Operations

Restoring an image is not about "fixing" a broken file; it is about reverting the environment to a known good state. There are two scenarios for restore:

Scenario A: Rollback of a Host Pool

If you have updated your host pool to a new image version and users are reporting issues, you need to revert the host pool to the previous version.

1. Identify the Target: Determine the previous, stable image version ID in your Azure Compute Gallery.
2. Update the Host Pool: In the Azure Portal, go to your Host Pool, select Properties, and update the Image property to point to the previous version.
3. Reprovision: You will need to either re-image existing VMs or, more safely, create a new host pool or session host collection using the old image and drain the current hosts.

Scenario B: Recovery from Gallery Loss

If the Azure Compute Gallery itself is corrupted or deleted, you must restore from your secondary region or your IaC definitions.

1. Re-provision the Gallery: Create a new Gallery in the same or a different region.
2. Re-run the Build Pipeline: Trigger your CI/CD pipeline (e.g., GitHub Actions or Azure DevOps) to rebuild the images using the stored templates.
3. Point Host Pools to New Images: Once the images are built and published to the new Gallery, update your host pools to point to the new Resource IDs.

Best Practices and Industry Standards

Following industry standards ensures that your AVD environment remains stable and audit-ready.

• Infrastructure as Code (IaC): Never build images manually in the portal. Use automated scripts to ensure repeatability.
• The "Golden Image" Principle: Maintain a single master VM that is never used for production. Only use this VM for the build process, then shut it down and deallocate it.
• Testing Cycles: Always deploy a new image version to a "Test" host pool before pushing it to production. Use a small group of pilot users to validate the image integrity.
• Monitoring: Use Azure Monitor to track the health of your host pools. If you see a spike in connection failures immediately after an image update, this serves as your trigger to initiate a rollback.
• Documentation: Maintain a changelog for every image version. This should include what patches were applied, what software was installed, and who approved the version.

Warning: Avoid "In-Place" updates. Never log into a production AVD VM to install a new application or update a driver. This creates "configuration drift," where your production VMs no longer match your base image. If you need a change, update the base image, create a new version, and redeploy.

Common Mistakes and How to Avoid Them

1. The "Single Region" Trap

Many administrators create their Azure Compute Gallery in only one region. If that region experiences a service outage, you cannot deploy new session hosts.

• Solution: Always replicate your gallery to at least two geographically distinct Azure regions.

2. Lack of Version Control

Manually naming images "GoldenImage-Final" or "GoldenImage-New" is a recipe for disaster. You eventually lose track of which image is actually in production.

• Solution: Use strict semantic versioning (e.g., 1.0.0, 1.0.1) and rely on the metadata provided by the Azure Compute Gallery.

3. Neglecting the Build VM

Administrators often forget to back up the master VM used to create the image. If the build process breaks, they have to start from scratch.

• Solution: Take a snapshot of the master VM disk after every successful build. If you need to make a change, restore the snapshot, apply the change, and capture a new version.

4. Over-reliance on Snapshots

Some organizations attempt to manage AVD by taking daily snapshots of all production VMs. This is expensive and does not scale well.

• Solution: Use FSLogix for user data and the Azure Compute Gallery for the OS layer. Keep the OS layer stateless and disposable.

Comparison: Image Management Approaches

Automation and Scripting for Image Maintenance

To truly excel at image maintenance, you should leverage PowerShell to manage your gallery versions. This allows you to quickly inspect your environment and perform bulk updates.

Listing Image Versions

Use the following PowerShell command to check the status of your image versions across your gallery. This is useful for identifying which versions are ready for deployment and which are stale.

# Get all image versions in a gallery
$galleryName = "MyAVDGallery"
$rgName = "AVD-Images-RG"
$galleryImageName = "Win11MultiSession"

Get-AzGalleryImageVersion -GalleryName $galleryName -ResourceGroupName $rgName -GalleryImageDefinitionName $galleryImageName

Cleaning Up Old Versions

To keep costs down and prevent confusion, you should periodically remove old image versions that are no longer in use. However, always ensure they are not currently assigned to a production host pool first.

# Delete a specific, outdated image version
$versionName = "1.0.0"
Remove-AzGalleryImageVersion -GalleryName $galleryName -ResourceGroupName $rgName -GalleryImageDefinitionName $galleryImageName -Name $versionName

Tip: Before deleting an image version, use the Get-AzWvdHostPool command to check if any host pools are currently referencing that image ID. Never delete an image that is currently in use by a production host pool.

Disaster Recovery (DR) Considerations

When planning for disaster recovery, the AVD image is a critical component. If your primary region goes offline, your DR strategy should include the ability to spin up your environment in a secondary region.

1. Cross-Region Replication: Ensure your Azure Compute Gallery is replicated to the DR region.
2. Infrastructure Replication: Use Bicep or Terraform to define your host pools, workspaces, and application groups. These files should be stored in a globally redundant Git repository.
3. Automated Failover: In a true DR event, you would use your IaC scripts to deploy the host pools in the DR region, pointing them to the replicated image versions in the DR gallery.
4. Verification: Periodically perform a "DR Drill" where you deploy a small host pool in your DR region to ensure the images are working and that your scripts are still valid.

Frequently Asked Questions (FAQ)

Q: Should I back up my AVD VMs?

A: No. AVD host pool VMs should be considered ephemeral. You should back up the "Gold Image" and the "User Profiles" (via Azure Files/FSLogix). The VMs themselves should be replaceable at any time.

Q: How often should I update my images?

A: You should aim for a monthly update cycle to align with Microsoft's "Patch Tuesday." This ensures your environment remains secure without requiring constant, disruptive changes.

Q: What if my image build fails?

A: Since you are using a master VM and snapshots, simply roll back the master VM to the snapshot taken before the build started. Investigate the logs, fix the error, and try again.

Q: Can I move an image between Galleries?

A: Yes, you can copy an image version from one gallery to another using the New-AzGalleryImageVersion command with the source image version ID.

Key Takeaways

To conclude this lesson, remember that image management is a discipline of consistency. AVD is a powerful service, but its utility depends entirely on the health of the images that drive it.

• Version Everything: Use semantic versioning for all image releases. Never overwrite existing image versions; always create new ones.
• Automate to Succeed: Rely on Infrastructure-as-Code (IaC) for image builds. This provides an audit trail and ensures your environment can be recreated from scratch if necessary.
• Replicate for Resilience: Always replicate your Azure Compute Gallery across multiple regions to protect against regional outages.
• Separation of Concerns: Keep your OS image, user profiles (FSLogix), and data (Azure Files) separate. This allows you to manage each layer independently and simplifies recovery.
• Test Before Deploy: Never push an image to production without testing it in a staging environment. Use pilot groups to validate that applications and settings function as expected.
• Treat VMs as Ephemeral: Do not rely on backups of individual session host VMs. If a VM fails, replace it using your proven, versioned gold image.
• Document the Lifecycle: Maintain a clear log of changes for each image version. This is invaluable during troubleshooting and essential for compliance audits.

By following these practices, you transform your AVD image management from a reactive, manual chore into a reliable, automated service. This stability is the bedrock upon which a productive and secure virtual desktop environment is built. When you treat your images with the same care as your production application code, you minimize downtime, simplify administrative overhead, and ensure a consistent experience for your end users.