AVD Golden Image Management: Build, Version, and Roll Out Without Breaking Users

By David, 2026-10-01

A golden image is the one place where a small mistake reaches every user at once. Push a version with a broken driver, a half-applied update or a stale FSLogix agent, and by the next morning every pooled host that rebuilt overnight carries it. Most AVD teams don't struggle to build an image. They struggle with everything after: knowing what belongs in it, numbering versions so anyone can tell what's running, getting a new version onto a host pool without kicking people off, and getting back to the last good one when something breaks.

This guide covers the whole lifecycle, vendor-neutral first: what goes in the image and what doesn't, three ways to build it, versioning and replication in Azure Compute Gallery, a rollout pattern that drains before it replaces, and a monthly checklist you can adopt as-is.

The short version: keep the image to what every user on the pool needs and what can't be installed later: the OS, its updates, Microsoft 365 Apps, the AVD and FSLogix agents, and security tooling. Deliver everything else at runtime. Build it the same way every time, publish each build as a numbered version in Azure Compute Gallery, test it on a small pool before production, roll it out in batches that drain first, and keep the previous version until the new one has run a full working week.

Microsoft details below reflect Microsoft Learn as of October 2026, with links in the Sources section at the end.

New to AVD? What Is Azure Virtual Desktop? explains host pools, session hosts and FSLogix first.

1. What belongs in the image, and what's delivered at runtime

Every item in the image is a promise: every host built from it carries it, and every update to it means a new image version. So the question for each component isn't "does everyone need this?" but "is the image the cheapest place to keep it current?"

Two rules follow from the table. Keep the image boring: it holds the things that are slow to install, needed before sign-in or required on every host. Make hosts disposable: if replacing a host would lose something, that something belongs in a profile, a policy or a runtime install, not on the host.

The app column is a whole decision on its own. App delivery on AVD compares baking apps into the image, installing them with WinGet at deploy time and App Attach, app type by app type.

2. Three ways to build the image

Manual build and Sysprep

The classic approach: create a VM from a Windows 11 Enterprise multi-session image in Azure Marketplace (or Windows Server, for the cases in Windows 11 multi-session vs Windows Server), sign in, install and configure what the table above puts in the image, then generalize it and capture it.

Generalizing with Sysprep removes machine-specific information so many VMs can be built from one image. Microsoft's guidance for Azure (Deprovision or generalize a VM) has a few points that catch people out:

• Sysprep is one-way. Once a VM is generalized it can't be restarted. If you want to keep the build VM for next month, take a snapshot of its OS disk, create a VM from the snapshot, and generalize that copy instead.
• The command is sysprep.exe /generalize /shutdown, run as administrator from %windir%\system32\sysprep. Delete C:\Windows\Panther first if it exists, because logs from earlier Sysprep runs can make it fail. Custom answer files aren't supported.
• Decrypt drives and check apps first. Sysprep needs fully decrypted drives, and some security agents, Store apps and virtualization agents either don't support Sysprep or need a documented preparation step.

The most common Sysprep failure on Windows 11 is a Store app that was updated or installed for one user but not provisioned for all of them. Sysprep refuses to generalize, and setupact.log in C:\Windows\System32\Sysprep\Panther names the package. Remove that package for the user (or remove its provisioning), and don't sign in to the build VM with personal accounts that pull Store updates.

Manual builds are fine for a first image or a small estate. Their weakness is reproducibility: six months later, nobody remembers exactly what was clicked.

Azure VM Image Builder and AVD custom image templates

Azure VM Image Builder runs the build for you from a template: a source image, a list of customization steps and a distribution target. It creates a temporary build VM, runs the steps, generalizes the result with Sysprep and publishes it.

For AVD, Microsoft wraps it in custom image templates in the Azure Virtual Desktop portal (Custom image templates). The source can be an Azure Marketplace image, an existing Azure Compute Gallery image, a managed image or another template, and the output goes to Azure Compute Gallery, a managed image or both. Built-in scripts cover the common AVD steps: language packs and the default language, time zone redirection, disabling Storage Sense, installing and configuring FSLogix, RDP Shortpath, screen capture protection, Teams optimizations, session timeouts, adding or removing Office apps, and applying Windows updates. You can add your own scripts as long as the build VM can download them.

The trade-off is iteration speed. Each change means editing the template and running a full build, which takes a while and can fail late. In return, every image is reproducible from the template, and the template itself can live in source control.

Scripted builds

Some teams script the whole pipeline instead, with Packer, Bicep or Terraform, and PowerShell, run from Azure DevOps or GitHub Actions. That gives full control over every step and fits teams that already run infrastructure as code. It also means owning the pipeline, its credentials and its failures. Our AVD deployment automation guide covers what a pipeline like that should include.

Whichever you pick, script the customizations. Even a "manual" build is far easier to repeat when the installs and settings are a PowerShell script you run on the build VM rather than a page of notes.

3. Versioning in Azure Compute Gallery

Azure Compute Gallery is where AVD images should live. It organizes them in three levels (Store and share images in Azure Compute Gallery):

• Gallery: the repository, with access controlled by Azure RBAC.
• Image definition: one kind of image, for example "Windows 11 multi-session, finance pool". It records the OS, whether images are generalized or specialized, the Hyper-V generation and the security type (such as Trusted Launch). You can't change those properties after the definition is created, so a move to a new security type means a new definition.
• Image version: one build, and what VMs are actually created from.

Version numbers are always MajorVersion.MinorVersion.Patch. When a deployment asks for latest, Azure picks the highest major, then minor, then patch. A scheme that works for AVD:

• Major for a new OS release (Windows 11 24H2 to 25H2).
• Minor for each monthly build.
• Patch for an out-of-band fix to that month's build.

So 2.10.0 is the October build on 25H2, and 2.10.1 is a fix to it. Put what changed in the image definition's release notes, or in your own change log, at the moment you publish.

Three properties you can still change after publishing make rollouts safer:

• Exclude from latest. Publish a new version with this set, and anything that deploys "latest" keeps getting the previous one until you clear it. That's how you test a version without production picking it up.
• End-of-life date. Informational only: VMs can still be built from a version past its date. It's still useful for marking which versions are on their way out.
• Target regions and replica counts. These can be changed after publishing, so you can add a recovery region later.

Replication copies each version to the regions you choose. Microsoft recommends at least three replicas for production images, plus one replica for every 20 VMs you create at the same time (Azure Compute Gallery overview). Storage is charged per replica, per region, on the image's occupied size, so it's worth keeping only recent versions replicated widely. Two more recommendations from the same page: keep production and test images in separate galleries, and put a resource lock on the production gallery so nobody deletes the version every host was built from.

The other replication choice is the mode. Standard (full) replication copies the image to every target region and suits production. Shallow replication skips the copy so a version is ready in about a minute, but isn't meant for building many VMs at once. Full vs shallow image replication covers when to use each, with a build-on-shallow, ship-on-full pattern that works well.

4. Rolling a new image onto a host pool

A new image version does nothing until hosts are built from it. Pooled hosts aren't patched in place: you replace them. The safe pattern has four steps.

Drain

Turn on drain mode for the hosts you're about to replace. Users already signed in keep working, and new connections go to other hosts. Then decide how long to wait. A pool used from 9 to 5 often empties on its own overnight. A 24-hour pool needs a deadline, a message to users still signed in and, eventually, a sign-out. Whatever you choose, write it down so users know what to expect.

Replace

Build new hosts from the new version, joined to the same directory and registered with the same host pool, then remove the old ones. Do it in batches so the pool always has enough capacity: replacing 2 or 3 hosts of 10 at a time keeps 70 to 80% of the pool serving users. Replace one host first, on its own, as a canary. If it fails to build, join the domain or register with the pool, you've lost one host, not a batch.

Microsoft's built-in option is session host update, for host pools that use a session host configuration (Session host update). It works the same way: it updates one session host first, then the rest in batches of the size you set. For each batch it sends your message to signed-in users, waits the time you set, signs out anyone still connected, drains and removes the hosts, and creates new ones with the same host names. Microsoft notes three things to plan for: autoscale must be off for the duration, anything added to hosts by hand disappears, and as of October 2026 it's available only in the global Azure cloud, not in Azure Government.

Verify

A host that boots isn't proof of a healthy image. Before the next batch, check on a new host:

• It shows as Available in the host pool, with the expected agent version.
• A test user can sign in, the FSLogix profile attaches, and logon time is in line with the old hosts.
• Microsoft 365 Apps activate, Teams media optimization reports as connected, and your line-of-business apps start.
• Security and monitoring agents report in as this host, not as the image or a duplicate.

Make the last check a habit. Duplicate device IDs from an agent that wasn't prepared for imaging are one of the most common image bugs, and they don't show up until the second host is built.

Roll back

The rollback plan is simple if you planned for it: keep the previous version in the gallery and replicated, point the host pool back at it, and replace the affected hosts again. That only works if the old version still exists, so never delete the last known-good version until the new one has run a full working week in production. If you used exclude from latest while testing, set it on the bad version as well, so new hosts stop picking it up while you fix it.

5. Patch cadence and a monthly image checklist

Microsoft releases Windows security updates on the second Tuesday of each month (Patch Tuesday), and Microsoft 365 Apps on its own channel schedule. A monthly image build aligned to Patch Tuesday keeps hosts current without making the image a weekly chore. A rhythm that works for most estates:

• Week 1 (Patch Tuesday): build the new version and publish it to the test gallery, or with exclude from latest set.
• Week 1–2: roll it to a test or pilot pool with real users. Run the verification checks above.
• Week 2–3: roll production pools in batches, out of hours where you can.
• Week 4: retire the version from two months ago, keeping the previous one for rollback.

An out-of-band build replaces this only for an actively exploited vulnerability or a broken agent. Between builds, fast-moving apps are patched at runtime with WinGet, which is the reason they're kept out of the image.

Monthly image checklist:

1. Start from the current build VM (or a fresh Marketplace image for a new OS release), not from a production host.
2. Apply Windows cumulative updates and the latest servicing stack, and reboot until no updates remain.
3. Update Microsoft 365 Apps, FSLogix, Teams and the WebRTC redirector service to their current supported versions.
4. Update in-image apps and security agents, following each vendor's imaging guidance.
5. Run your cleanup: temp files, Windows Update cache, unneeded Store apps for new users.
6. Check drives are decrypted and remove any Store app updated for a single user.
7. Snapshot the build VM so next month starts from it.
8. Generalize a copy with Sysprep and capture it as the next version number, with release notes.
9. Replicate to every region your pools run in, with enough replicas for your largest scale-out.
10. Test on a pilot pool: sign-in, profiles, apps, agents, logon time.
11. Roll production in batches, canary first, drain before replace.
12. Keep last month's version until this one has run a full working week. Then retire the one before it.

Top 10 Azure Virtual Desktop mistakes covers several of the ways image management goes wrong in production.

How Atlas AVD handles imaging and rollout

Atlas AVD runs the lifecycle above from one console, in your own Azure subscription and your own Azure Compute Gallery. Here's what each step looks like, and where Atlas stops so you can plan around it.

Build. In Imaging you pick a source VM and an image definition, and Atlas suggests the next version number. With Sysprep on, Atlas snapshots the source VM, builds a temporary copy, generalizes that copy and captures it, so the source VM is never modified and is still there for next month. The build can pre-install the AVD agent (installed but not registered, so a new host only has to register with its pool), FSLogix (the app only, with no configuration) and new Teams with the WebRTC redirector. Atlas doesn't run Windows Update during the build, so patch the source VM first; and it captures a VM rather than running Azure VM Image Builder.

Version and replicate. Each build is published as a new image version in your gallery, to the regions you choose, with Standard (Full) or Shallow replication, and you can add regions to a version later. Every build keeps its full build log in the history, and release notes are kept per version. See Image Management.

Pin. Each host pool deploys from the image you select, either pinned to a version or left on Latest, which means the highest version number not excluded from latest. VM Provisioning builds every new host from that version, joins it to Entra ID or Active Directory, runs the pool's WinGet installs and confirms the host has registered before it reports success.

Roll out. When a new version is published, the Outdated Image view lists the hosts still on an older one. Re-Image All replaces them in one of three ways:

• Immediate: empty hosts are replaced now, and the rest as soon as their sessions end.
• Rolling Replace (Zero Downtime): Atlas builds the replacement first and drains the old host. The old host is deleted only once its replacement is ready and its last user has signed out, a few hosts at a time. If a replacement fails, the old host goes back into service.
• Scheduled: each host is replaced when it reaches zero sessions.

None of them forces anyone off: a draining host waits for its users. A per-pool Auto switch goes one step further and re-images outdated hosts on its own as they empty, re-checking the live session count immediately before it acts. To take hosts out of service without replacing them, DrainGuard™ drains them and waits for sessions to end before it acts, on the Professional plan and above.

Roll back. Pin the pool back to the previous version and run Re-Image All again. Atlas doesn't have a one-click rollback button, which is one more reason to keep last month's version until the new one has proven itself.

What stays outside the image. Browsers and other fast-moving apps are installed when each host is built, from the pool's WinGet list in the Application Catalog. How Atlas AVD uses WinGet covers patching them between image builds.

Image Management is included on every Atlas AVD plan, including Community. To see how it fits a full deployment, start with AVD deployment automation.

FAQ

What is a golden image in Azure Virtual Desktop?

A golden image is the standard VM image every session host in a host pool is built from. It holds Windows, its updates, Microsoft 365 Apps, the AVD and FSLogix agents and the apps every user needs. It's generalized with Sysprep and stored as a version in Azure Compute Gallery, so every new host starts identical.

What should be in an AVD golden image?

The OS and its updates, Microsoft 365 Apps with shared computer activation, the AVD agent, FSLogix, Teams optimizations, security and monitoring agents, and large stable apps every user needs. Fast-moving apps, apps only some users need, settings and user data are better delivered at runtime through WinGet, App Attach, policy and FSLogix.

How do I update an AVD golden image?

Build the next version from your build VM or template, apply updates and app changes, generalize a copy with Sysprep and publish it to Azure Compute Gallery as a new version number. Test it on a pilot pool, then replace production hosts in batches, draining each batch first, and keep the previous version for rollback.

How often should I update my AVD image?

Monthly, aligned to Patch Tuesday, suits most estates, with an out-of-band build only for an actively exploited vulnerability or a broken agent. Patch fast-moving apps between builds with WinGet instead of rebuilding the image for each update.

Should I use Azure VM Image Builder or a manual build with Sysprep?

A manual build with Sysprep is quickest for a first image or a small estate. Azure VM Image Builder, through AVD custom image templates, gives you reproducible builds from a template, at the cost of slower iteration. Large teams that already run infrastructure as code often script the whole pipeline.

How do I roll back a bad AVD image?

Keep the previous image version in Azure Compute Gallery and replicated to your regions. Point the host pool back at that version and replace the affected hosts, draining them first. Set "exclude from latest" on the bad version so new hosts don't pick it up while you fix it.

Sources

• Microsoft Learn: Deprovision or generalize a VM before creating an image
• Microsoft Learn: Custom image templates in Azure Virtual Desktop
• Microsoft Learn: Store and share images in Azure Compute Gallery
• Microsoft Learn: Azure Compute Gallery overview
• Microsoft Learn: Session host update in Azure Virtual Desktop
• Microsoft Learn: Install Microsoft 365 Apps on a custom VHD image