Lesson: Modifying and Updating Azure Virtual Desktop (AVD) Session Host Images

Introduction: The Lifecycle of a Session Host Image

In the realm of Azure Virtual Desktop (AVD), the session host image is the foundation upon which your entire user experience rests. It contains the operating system, the installed applications, specific configurations, and security patches required for your users to perform their daily tasks. However, an image is not a static artifact; it is a living entity that must evolve alongside your organization’s needs. Whether it is a new version of Microsoft 365, a security patch released on Patch Tuesday, or a custom line-of-business application update, the ability to effectively modify and update these images is a critical skill for any AVD administrator.

Why does this matter so much? If your image management strategy is flawed, you end up with "configuration drift," where different session hosts in the same pool behave differently, leading to unpredictable user experiences and troubleshooting nightmares. Furthermore, an outdated image is a security liability. By mastering the art of image modification and updating, you ensure that your AVD environment remains secure, performant, and consistent. This lesson will guide you through the manual and automated processes required to keep your AVD infrastructure current and reliable.

The Core Concept: Golden Images vs. Automated Pipelines

Before we dive into the "how," we must address the "what." In AVD, we typically work with a "Golden Image" (or "Master Image"). This is a reference virtual machine (VM) that has been optimized, patched, and configured exactly how you want your end-user environment to look. Once this image is prepared, you create an image version, which is then used to deploy your session host VMs.

Manual vs. Automated Updating

There are two primary ways to approach image updates:

1. Manual Updates: You log into your master VM, install updates, run cleanup scripts, and then generalize the image using Sysprep. This is fine for small environments with one or two images, but it is prone to human error and difficult to document.
2. Automated Pipelines (e.g., Azure Image Builder): You define your image configuration in a template file (JSON or Bicep). Azure Image Builder automatically builds a VM, applies your updates, runs your custom scripts, and distributes the resulting image. This is the gold standard for enterprise environments.

Callout: Image Management Strategy When deciding between manual and automated methods, consider the frequency of your updates. If you update your image once per year, manual processes might suffice. If you have a monthly patch cycle or frequent application updates, investing in an automated pipeline will save hundreds of hours of manual labor and significantly reduce the risk of configuration errors.

Step-by-Step: Updating a Master Image Manually

If you are just starting out or managing a small footprint, manual image updates are the first step to understanding the workflow. Follow this process to ensure your image remains healthy.

Step 1: Starting the Master VM

Never try to modify an image that is currently in use by a host pool. Always locate your original Master VM. If it is deallocated, start it up. If it is already deleted, you will need to create a new VM from the last known good image version.

Step 2: Applying Updates and Software

Once logged into the VM, perform your necessary updates. This usually involves:

• Windows Updates: Run the standard update tool to ensure the OS is patched.
• Application Updates: Update browsers, productivity suites, or custom software.
• Configuration Changes: Modify Registry keys, Group Policy settings, or local services as required.

Step 3: Cleaning Up the Image

Before you finalize the image, you must remove unnecessary files to keep the disk footprint small. Delete temporary files, clear the browser cache, and remove any local user profiles created during the update process.

Tip: The Importance of Cleanup Failing to clean up temporary files and logs after updating an image leads to "disk bloat." Over time, your images will grow unnecessarily large, increasing storage costs and potentially slowing down the deployment time for new session hosts in your pool.

Step 4: Generalizing with Sysprep

This is the most critical step. Sysprep (System Preparation Tool) removes unique system information, such as the computer name and security identifiers (SIDs), preparing the OS for duplication.

Open the Command Prompt as an Administrator and run: C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

This command tells Windows to generalize the system, prepare it for the Out-of-Box Experience (OOBE), and shut down the machine once finished. Once the VM is shut down, you are ready to capture it as a new image version.

Automating with Azure Image Builder (AIB)

Azure Image Builder (AIB) is built on HashiCorp Packer but is native to Azure. It allows you to define an image build process that is repeatable and consistent.

The AIB Workflow

1. Source: You define the source (e.g., a Marketplace Windows 11 image).
2. Customize: You provide scripts (PowerShell, Bash) to install software or change settings.
3. Distribute: You define where the image goes (Shared Image Gallery/Azure Compute Gallery).

Example: AIB Configuration (JSON snippet)

The following is a simplified example of an AIB template that installs software via PowerShell:

{
  "type": "PowerShell",
  "name": "InstallSoftware",
  "inline": [
    "Write-Host 'Installing corporate applications...'",
    "Start-Process 'C:\\Temp\\setup.exe' -ArgumentList '/silent' -Wait",
    "Remove-Item -Path 'C:\\Temp\\setup.exe'"
  ]
}

Best Practices for AIB

• Modularize Scripts: Don't write one massive script. Create small, reusable PowerShell scripts for specific tasks (e.g., Install-Chrome.ps1, Configure-Registry.ps1).
• Use Variables: Use variables for file paths, version numbers, and configuration settings to make your templates flexible.
• Version Control: Store your AIB JSON templates and PowerShell scripts in a Git repository. This provides an audit trail of every change made to your images.

The Role of Azure Compute Gallery (ACG)

The Azure Compute Gallery (formerly Shared Image Gallery) is the central repository for your images. It manages image versioning, replication, and sharing.

Versioning Strategy

When you update an image, you should never overwrite an existing version. Instead, create a new version (e.g., 1.0.0 becomes 1.0.1). This allows you to:

• Rollback: If a new image version causes issues, you can instantly revert your host pool to the previous version.
• Staging: You can deploy the new version to a small "test" host pool before rolling it out to the entire organization.

Warning: Overwriting Versions Never attempt to overwrite an existing image version in the Azure Compute Gallery. If you discover a bug in version 1.0.1, create 1.0.2 and deprecate 1.0.1. Overwriting causes metadata mismatches and can crash existing deployment pipelines.

Practical Example: Updating a Host Pool

Once you have your new image version in the Azure Compute Gallery, you need to apply it to your host pool. This process is known as "reimaging."

1. Navigate to the Host Pool: In the Azure portal, go to your AVD Host Pool.
2. Select Session Hosts: You will see a list of VMs.
3. Update/Reimage: You can choose to update the image for the entire pool.
4. Drain Mode: Before you start, set your existing session hosts to "Drain Mode." This prevents new users from connecting while you prepare to swap the image.

Code Example: Updating a Host Pool via PowerShell

Using the Az module, you can trigger an update for your session hosts:

# Define your variables
$resourceGroupName = "AVD-RG"
$hostPoolName = "Finance-HostPool"
$imageReference = "/subscriptions/.../galleries/MyGallery/images/Win11-Gold/versions/1.0.2"

# Update the Host Pool to point to the new image
Update-AzWvdHostPool -ResourceGroupName $resourceGroupName -Name $hostPoolName -ImageId $imageReference

Note: This command updates the reference for the pool. Existing VMs will need to be re-imaged or replaced depending on your specific configuration requirements.

Best Practices and Industry Standards

1. Optimize for Performance

A common mistake is installing too many background services on a master image. Every service consumes CPU and RAM. Disable unnecessary Windows services (e.g., Print Spooler if not needed, Bluetooth services, etc.) to squeeze more performance out of your session hosts.

2. Use FSLogix for Everything

Do not store user data or application-specific configurations on the local disk of the image. Always use FSLogix Profile Containers. This keeps your image "thin" and makes it easier to replace because the user's data lives in a separate VHDX file on an Azure File Share.

3. Security Hardening

Apply CIS Benchmarks or Microsoft Security Baselines to your master image. This includes disabling unnecessary protocols (like SMBv1), enabling Windows Defender Application Control, and configuring strong password policies.

4. Consistent Naming Conventions

Use a clear naming convention for your image versions. A format like YYYY.MM.DD or MAJOR.MINOR.PATCH is standard. For example, 2023.10.15 tells you exactly when the image was last updated, which is invaluable during troubleshooting.

Comparison: Manual vs. Automated Image Management

Common Pitfalls and How to Avoid Them

Pitfall 1: "Ghosting" Configurations

Sometimes, administrators forget to remove local user accounts or cached credentials from the master image. This is a security risk.

• The Fix: Always run a script to clear local profiles and registry keys during the image preparation phase. Use the Sysprep /generalize command to ensure the machine is truly "blank."

Pitfall 2: Forgetting to Update Integration Components

When you update the OS, you might inadvertently break the AVD agent or the FSLogix software.

• The Fix: Always include a step in your update script to verify the status of the AVD Agent service and the FSLogix service. If possible, use a script to download the latest versions of these installers every time you build a new image.

Pitfall 3: Ignoring Disk Space Requirements

Azure images have limits on disk size, and larger disks cost more money.

• The Fix: Use "Disk Cleanup" and "Compact" tools during the image build process. If you find your image is growing too large, investigate which application is taking up the most space and see if it can be offloaded to a network location or handled via App Attach.

Advanced Topic: MSIX App Attach

In modern AVD, you don't necessarily need to install every application into your master image. With MSIX App Attach, you can keep your master image "clean" and "thin" by mounting applications dynamically as the user logs in.

• Benefits:
  • Faster image build times.
  • Simplified image updates (just update the MSIX package, not the whole VM).
  • Easier application management.

If your organization has a large catalog of software, transitioning to App Attach is a major productivity booster for the IT team.

Troubleshooting Image Issues

Even with the best planning, things go wrong. If your session hosts fail to join the domain or the AVD agent fails to register after an update, check these common areas:

1. Sysprep Failures: Check C:\Windows\System32\Sysprep\Panther\setupact.log. This file usually contains the specific error that caused the Sysprep process to fail.
2. Agent Logs: Check C:\ProgramData\Microsoft\RDInfraAgent\Logs on the session host. This is where you will find the "why" behind registration failures.
3. Networking/DNS: Ensure the master image can reach the domain controller and the Azure management endpoints during the build process. If the image cannot reach the internet to pull updates, the build will hang.

Note: The "Golden Rule" of AVD Images Never perform a "live" update on a session host VM that is currently serving users. If you need to patch a host, either replace it with a new one from a updated image or perform the update during a maintenance window where the host is removed from the load balancing rotation.

Comprehensive Key Takeaways

1. Treat Images as Code: Move away from manual, click-heavy processes. Use Azure Image Builder and version control (Git) to manage your image configurations. This ensures that every update is documented and reversible.
2. Always Use Versioning: Never overwrite an image in the Azure Compute Gallery. Create new versions so that you can roll back instantly if an update causes unexpected issues in production.
3. Prioritize Image "Thinness": Keep your master image as small as possible. Use FSLogix for user profiles and consider MSIX App Attach for application delivery. This reduces storage costs and improves deployment speed.
4. Automate Cleanup and Generalization: A clean image is a reliable image. Always automate the cleanup of temporary files and ensure that Sysprep is executed correctly to prevent SID conflicts and configuration drift.
5. Test Before You Deploy: Never push a new image version directly to your production host pool. Always deploy to a "User Acceptance Testing" (UAT) pool first to verify that applications work as expected and that the AVD agent initializes correctly.
6. Maintain a Maintenance Window: Even with automated systems, image updates require careful orchestration. Use drain mode and blue-green deployment strategies to ensure users are not interrupted during your update cycles.
7. Monitor Your Logs: When things go wrong, the logs are your best friend. Familiarize yourself with the location of AVD agent logs and Sysprep logs to diagnose issues quickly.

By following these practices, you transform image management from a stressful, reactive task into a predictable, automated process. This allows you to focus on more strategic initiatives, knowing that your AVD infrastructure is robust, secure, and always up to date. Remember, the goal is not just to get the image working, but to build a system that can be reliably updated and managed for years to come.