Image Lifecycle and Compute Gallery
Plan and implement image lifecycle management — versioning, multi-region replication, testing with validation pools, and production-grade image pipelines using Azure Compute Gallery.
The image lifecycle
Think of image management like a bakery production line.
Every month, you bake a fresh batch of bread (build a new image). Before selling it to customers, a taste tester tries it (validation host pool). If it is good, it goes on the shelves (production). Last month’s bread gets moved to the clearance rack (deprecated). Very old bread gets thrown out (deleted).
You also ship bread to multiple stores (regions). Each store keeps a few loaves on the shelf — you do not bake separately for each store, you replicate from the main bakery.
The five stages of image lifecycle
Every image goes through these stages:
| Stage | What happens | Who is involved |
|---|---|---|
| Build | Create a new image version — install apps, apply patches, optimise settings | Image Builder or manual process |
| Test | Deploy the image to a validation host pool, verify apps and performance | IT team, pilot users |
| Distribute | Replicate the image version to all required Azure regions | Azure Compute Gallery handles replication |
| Deploy | Create new session hosts from the tested image, drain old session hosts | Automation pipeline or admin |
| Deprecate | Mark old image versions as end-of-life, eventually delete them | Gallery version management |
🏢 Raj at TerraStack: “We run this cycle monthly. Image Builder creates the new version on the second Wednesday (Patch Tuesday). Thursday it deploys to our validation pool. Friday, Andrea’s EA and two power users test it. Monday, we roll it to production if it passes. Old image versions get deprecated after 90 days.”
Update strategy — bake, don’t patch
The recommended approach for AVD session host updates is image replacement, not in-place patching:
- Build a new image version with the latest OS patches and app updates baked in.
- Deploy new session hosts from the new image to the host pool.
- Drain old session hosts — set them to drain mode so no new sessions land on them.
- Remove old session hosts once all users have logged off.
This approach ensures every session host is identical and eliminates configuration drift (where VMs gradually become different because patches apply inconsistently).
When in-place patching makes sense
Image replacement is the gold standard, but in-place patching (Windows Update, WSUS, Intune) is sometimes used for:
- Personal host pools: Each user has a dedicated VM with personalised settings — replacing it would lose their customisations.
- Emergency security patches: A critical zero-day that cannot wait for the next image build cycle.
- Small deployments: A pool with 2-3 session hosts where image pipelines are overkill.
For pooled host pools at any meaningful scale, image replacement is always preferred.
Azure Compute Gallery — the image warehouse
Azure Compute Gallery organises your images in a three-level hierarchy:
Gallery
The top-level container. Typically you create one gallery per team or environment (e.g. gal_avd_production, gal_avd_dev). A gallery lives in a resource group and a region, but the images inside it can be replicated to other regions.
Image definition
A logical grouping within a gallery. An image definition describes the category of image — not a specific version. It includes metadata like:
- OS type: Windows or Linux
- OS state: Generalised (Sysprep’d) or Specialised
- Publisher, offer, SKU: Descriptive metadata (e.g. publisher: “TerraStack”, offer: “AVD”, SKU: “Win11-MultiSession-M365”)
- Recommended VM sizes: Guidance for consumers (not enforced)
Think of it as a product listing — “Windows 11 multi-session with Office” — without specifying which month’s build.
Image version
A specific build of an image definition. Each version has a version number (e.g. 1.0.0, 1.1.0, 2025.06.01) and contains the actual VM disk(s). This is what you deploy session hosts from.
Hierarchy summary: Gallery contains Image Definitions. Image Definitions contain Image Versions. You deploy VMs from a specific Image Version.
| Aspect | Managed Image (Legacy) | Azure Compute Gallery |
|---|---|---|
| Versioning | No — single image, no history | Yes — multiple versions per definition with version numbers |
| Multi-region replication | No — must manually copy to other regions | Yes — define target regions and Azure replicates automatically |
| Simultaneous deployments | Limited to 20 VMs at once | Up to 1,000 VMs at once (with sufficient replicas) |
| Organisation | Flat — one image resource per capture | Hierarchical — gallery, definitions, versions |
| Sharing | Same subscription only | Share across subscriptions, tenants, or publicly via community gallery |
| Lifecycle management | Manual deletion | End-of-life dates, exclude from latest, auto-deprecation |
| Recommendation | Avoid for new deployments | Use for all production AVD images |
Image replication across regions
When you create an image version in a Compute Gallery, you specify target regions and the number of replicas per region. Azure copies the image to each target region.
Key rules for replication:
- Always include the source region as a target — this is required.
- More replicas means more simultaneous deployments — each replica supports about 20 concurrent VM creations. If you deploy 100 session hosts at once, you need at least 5 replicas in that region.
- Replication takes time — a large image may take 30-60 minutes to replicate to distant regions. Plan for this in your pipeline.
- Storage cost — you pay for storage in each target region. Keep replica counts reasonable.
🏢 Raj’s multi-region setup: “TerraStack has offices in Sydney and Auckland. Our gallery replicates every image version to Australia East and New Zealand North with 3 replicas each. Session hosts in both regions deploy from a local copy — no cross-region traffic and fast provisioning.”
Version management best practices
As you build new images monthly, the gallery accumulates versions. Here is how to manage them:
Keep N versions, deprecate the rest
Set an end-of-life date on old image versions. After the end-of-life date, the version cannot be used to create new VMs (but existing VMs are unaffected). A typical policy: keep the current version and two previous versions, set end-of-life on anything older.
Exclude from latest
Each image definition has a concept of “latest” — when a consumer deploys without specifying a version number, they get the latest. You can set exclude from latest on a version to prevent it from being picked up automatically. This is useful for:
- Images still being tested (not yet promoted to production)
- Hotfix images that should not become the new default
Naming conventions
Use a date-based versioning scheme for clarity:
2025.06.01— June 2025 monthly build, first revision2025.06.02— June 2025, second revision (hotfix)
This makes it obvious which image is current and when it was built.
Exam tip: Gallery replication and deployment scale
The exam tests whether you understand the relationship between replicas and deployment scale. If a question says “you need to deploy 200 session hosts simultaneously from a gallery image,” you need to calculate: 200 VMs / 20 per replica = 10 replicas in that region. If you only have 2 replicas, deployments will be throttled and slow.
Testing images with validation host pools
Before rolling a new image to production, deploy it to a validation host pool — a small pool designated for testing:
- Build the new image version.
- Deploy 1-2 session hosts to the validation pool from the new image.
- Have pilot users (or your IT team) log in and test critical applications.
- Verify printing, audio, clipboard, profile loading, and line-of-business apps.
- If tests pass, promote the image to production pools.
- If tests fail, investigate and build a corrected image — do not push to production.
🏛️ JC at the Federal Department: “Director Walsh mandates that every image goes through our validation pool. Aisha’s security team runs compliance scans, and three staff members test the approved software list. Nothing goes to production without sign-off. It adds a day to the cycle, but it has saved us from two broken patches this year.”
Replacing session hosts with a new image
Once an image passes validation, here is the production rollout:
- Deploy new session hosts from the new image version into the production host pool.
- Drain old session hosts — set Allow new sessions to No.
- Wait for users to log off — or send a notification with a deadline.
- Remove old session hosts — delete the VMs, their disks, and NICs.
- Verify — confirm the pool is healthy with all new session hosts available.
This can be fully automated with PowerShell scripts or Azure DevOps pipelines. The key is to never delete old hosts before new ones are confirmed healthy.
Image optimisation
Before finalising an image, optimise it for VDI performance:
| Optimisation | What to do | Why |
|---|---|---|
| Disable unnecessary services | Turn off services like Print Spooler (if not needed), Xbox services, Consumer Experience | Reduces CPU and memory footprint per session |
| Remove bloatware | Uninstall built-in apps users do not need (Solitaire, Tips, etc.) | Smaller image size, fewer updates, cleaner UX |
| Disable scheduled tasks | Turn off tasks that run per-user and waste resources in multi-session | Reduces background CPU usage |
| Optimise visual effects | Reduce animations, transparency, and visual effects | Improves responsiveness on bandwidth-limited connections |
| Configure Windows Update | Disable auto-update on session hosts (updates come via new images) | Prevents unexpected reboots and bandwidth spikes |
Microsoft provides the Virtual Desktop Optimisation Tool (on GitHub) that applies many of these optimisations automatically.
Deep dive: The VDI Optimisation Tool
The Virtual Desktop Optimisation Tool is an open-source PowerShell script collection from Microsoft that disables unnecessary services, removes built-in apps, and configures Windows for optimal multi-session performance. You run it as a customisation step during image creation — either manually or as an Image Builder PowerShell step.
The tool is configurable — you can choose which optimisations to apply based on your environment. For example, if your users need the Microsoft Store, you can skip that optimisation.
Always test optimised images thoroughly. Aggressive optimisations can break applications that depend on disabled services.
Raj needs to deploy 200 session hosts simultaneously in Australia East from a Compute Gallery image. The gallery currently has 2 replicas in that region. What should Raj do?
JC's team builds a new image version every month. They want to keep the last three versions available and prevent older versions from being used for new VMs. What should they configure?
Which of the following are valid reasons to use in-place patching instead of image replacement for AVD session hosts? (Choose two)
🎬 Video coming soon
Image Lifecycle and Compute Gallery
Next up: Identity Scenarios for AVD — moving into Domain 2, we explore Microsoft Entra ID join, hybrid join, and Active Directory Domain Services for AVD session hosts and how identity choices affect your architecture.