What's changed: Created AZ-140 Chapter 2 (Domain 1 second-half: host pool architecture (pooled/personal, breadth/depth load balancing, Windows Enterprise multi-session, RDS CAL/Windows access entitlement, resource organization, VM-capacity design); implementation (Azure portal wizard, registration token, PowerShell/Azure CLI/ARM templates/Bicep IaC, validation-environment flag); session-host images (manual/Sysprep, Azure VM Image Builder, Azure Compute Gallery versioning/replication, update lifecycle/recreate)).
2.3Session host images
Understand creating session-host images manually and with Azure VM Image Builder, modifying images and lifecycle management, applying OS/app updates, creating session hosts from custom images, and storing images with Azure Compute Gallery.
To mass-produce session hosts "with apps and settings baked in," use custom images. Building all hosts from the same golden image improves consistency and maintainability.
2.3.1Building images (manual / VM Image Builder)
Manually, start a VM, install apps/configure, generalize (Sysprep), then capture an image. For repetition/automation, use Azure VM Image Builder (declaratively define the build in a template and auto-run customization steps). VM Image Builder suits "build images reproducibly in code" and is more consistent than manual Sysprep.
2.3.2Azure Compute Gallery and lifecycle
Azure Compute Gallery (formerly Shared Image Gallery) provides image versioning, replication to multiple regions, and large-scale distribution to many VMs/subscriptions—superior to a single managed image for versioning and scale. Image lifecycle management cycles "apply OS/app updates → publish a new version → recreate (or add) session hosts on the new version → retire old versions gradually," propagating security updates to all hosts.
Cues: "build images reproducibly in code" = Azure VM Image Builder. "version images and distribute to multiple regions/large scale" = Azure Compute Gallery. Manual uses Sysprep to generalize. Updates cycle: publish a new version → recreate session hosts.
Watch the mix-ups: (1) VM Image Builder (build automation) and Compute Gallery (storage/versioning/distribution) differ in role and are used together. (2) Manual images must be generalized with Sysprep—skipping it causes SID-duplication issues on cloning. (3) Updating via "recreate from a new image version" is the AVD norm over "patch running hosts."
2.3.3Section summary
- Custom images = manual (generalize via Sysprep) or Azure VM Image Builder (build reproducibly in code)
- Azure Compute Gallery = image versioning / multi-region replication / large-scale distribution
- Updates propagate via the lifecycle: publish a new version → recreate session hosts
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to build a session-host image with apps/settings baked in, reproducibly from code via a template. Which is best?
Q2. You want to version custom images and replicate them to multiple regions for large-scale distribution. Which is best?
Q3. When creating a custom image manually, what step is essential to avoid SID-duplication issues on cloning?
Q4. What is the AVD norm for propagating OS/app security updates to session hosts?
Q5. Which correctly relates VM Image Builder and Azure Compute Gallery?