Building Session Host Images
Create custom session host images manually with Sysprep or automatically with Azure VM Image Builder — pre-install apps, harden security, and deploy consistent VMs.
Why custom images matter
Think of a custom image like a meal-prep container.
Instead of cooking from scratch every time (installing apps on every VM), you prepare the meal once, portion it into containers (the image), and store them in the fridge (Azure). When you need a new VM, you just reheat a container — everything is already inside and ready to go.
Without meal prep, you would spend hours installing the same apps, settings, and updates on every new VM. With a custom image, a new session host can be ready in minutes instead of hours.
Two ways to build images
You have two main approaches for building custom images:
- Manual image creation — Build a VM, configure it by hand, run Sysprep, capture it.
- Azure VM Image Builder — Define the image as a template, let Azure build it automatically.
Both produce the same result: a generalised image you can deploy session hosts from. The difference is how much manual effort is involved.
Manual image creation — step by step
Here is the workflow for building an image manually:
Step 1 — Create a source VM
Deploy a VM in Azure using a marketplace image as your starting point. For most AVD deployments, start with Windows 11 Enterprise multi-session (with or without Microsoft 365 Apps).
Step 2 — Install and configure everything
Connect to the VM via RDP and set it up exactly how you want your session hosts to look:
- Install line-of-business applications
- Apply security baselines and Group Policy settings
- Install agents (monitoring, antivirus, FSLogix)
- Run Windows Update to apply all patches
- Optimise for VDI (disable unnecessary services, remove bloatware)
- Configure registry settings, default user profile, and Start menu layout
Step 3 — Run Sysprep
Sysprep (System Preparation Tool) removes machine-specific information from the VM so it can be used as a template for new VMs. Think of it as wiping the serial number off a car so it can be re-registered.
Run Sysprep from the VM:
C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown| Flag | What it does |
|---|---|
| /oobe | Sets Windows to show the Out-Of-Box Experience on next boot (Azure handles this automatically) |
| /generalize | Removes unique identifiers — SID, computer name, hardware-specific drivers |
| /shutdown | Shuts down the VM after Sysprep completes (required before capture) |
Step 4 — Capture the image
After Sysprep shuts down the VM:
- In the Azure portal, go to the VM and click Capture.
- Choose whether to create a managed image or add it to an Azure Compute Gallery.
- Azure reads the VM disk and creates a reusable image.
The source VM is no longer usable after generalisation — it is consumed by the capture process.
🎧 Mia’s scenario: “When Horizons Health needed session hosts with the EHR (Electronic Health Records) software pre-installed, I built a VM manually — installed the EHR client, the radiology viewer Dr. Patel uses, and our antivirus agent. Ran Sysprep, captured it, and now every new session host has everything ready from the first boot.”
Common Sysprep issues and troubleshooting
Sysprep can fail for several reasons:
- UWP/Microsoft Store apps: Some built-in apps prevent Sysprep from completing. The error log is at
C:\Windows\System32\Sysprep\Panther\setuperr.log. You may need to remove problematic apps withRemove-AppxPackagebefore running Sysprep. - Sysprep count limit: Windows has a limit of running Sysprep up to 1001 times on the same installation — but you should never need that many. A fresh marketplace image has a clean count.
- Running services: Some third-party services can interfere. Stop them before running Sysprep.
- Antivirus agents: Some AV software hooks deeply into the OS and conflicts with generalisation. Check your vendor’s guidance for Sysprep compatibility.
The exam may ask about Sysprep troubleshooting — know where the error logs are located and that UWP apps are a common cause of failure.
Azure VM Image Builder
Azure VM Image Builder (AIB) automates the entire image creation process. Instead of manually logging into a VM and running commands, you define a template that describes what the image should look like.
How Image Builder works
The process follows a simple pipeline: Source then Customise then Distribute.
- Source: Start from a marketplace image, an existing managed image, or an existing image version from a Compute Gallery.
- Customise: Apply changes using one or more customisation steps.
- Distribute: Output the finished image to a managed image, a Compute Gallery, or a VHD file.
Customisation steps
Image Builder supports several customisation types:
| Step Type | What it does | Example |
|---|---|---|
| PowerShell | Run PowerShell scripts on the image | Install applications, configure settings |
| Shell | Run shell commands (Linux) | Not used for Windows AVD images |
| Windows Update | Apply Windows updates | Bake in the latest patches |
| Windows Restart | Restart the VM between steps | Required after some installations |
| File | Copy files into the image | Configuration files, license keys |
A typical AVD image template might look like:
- Source: Windows 11 Enterprise multi-session from marketplace
- Customise: Run PowerShell script to install LOB apps
- Customise: Run Windows Update
- Customise: Windows Restart
- Customise: Run PowerShell script to apply VDI optimisations
- Distribute: Output to Azure Compute Gallery
🏢 Raj at TerraStack: “We have a CI/CD pipeline that triggers Image Builder every month after Patch Tuesday. It grabs the latest Windows image, installs our 12 corporate apps, applies security baselines, runs updates, and publishes to our Compute Gallery. No human touches the image. Consistent every time.”
| Aspect | Manual Image Creation | Azure VM Image Builder |
|---|---|---|
| Process | RDP into VM, install manually, Sysprep, capture | Define a template, Image Builder automates everything |
| Repeatability | Low — depends on human following same steps | High — template is version-controlled and deterministic |
| Sysprep handling | You run Sysprep manually | Image Builder runs Sysprep automatically |
| Time to build | Hours (manual work) | 30-90 minutes (automated, depends on customisations) |
| Error prone | High — missed steps, inconsistent configs | Low — same template produces same image every time |
| Best for | One-off images, learning, prototyping | Production pipelines, monthly patching, enterprise scale |
| CI/CD integration | Difficult | Native — trigger builds from Azure DevOps or GitHub Actions |
| Cost | VM running time during build | VM running time during build (same — AIB uses a temporary VM) |
Deep dive: Image Builder template structure
An Image Builder template is an ARM resource of type Microsoft.VirtualMachineImages/imageTemplates. The key sections are:
- source: Defines the starting image (publisher, offer, SKU, version for marketplace images).
- customize: An array of customisation steps executed in order.
- distribute: Where the output goes — typically a
SharedImagedistribution targeting an Azure Compute Gallery.
AVD also offers custom image templates within the AVD portal experience. These are a simplified wrapper around Image Builder that lets you build images without writing JSON templates directly.
Image types: managed image vs Compute Gallery
When you capture an image, you have two storage options:
| Type | Description | Limitations |
|---|---|---|
| Managed image | A single image resource in one region | No versioning, no replication, limited to 20 simultaneous VM deployments, being deprecated in favour of galleries |
| Azure Compute Gallery image | Stored in a gallery with definitions and versions | Supports versioning, multi-region replication, up to 1,000 simultaneous deployments, the recommended approach |
Best practice: Always use Azure Compute Gallery for production. Managed images are legacy and have significant scale limitations.
Creating a session host from a custom image
Once your image is in a Compute Gallery, deploying session hosts from it is straightforward:
- Azure portal: When creating a host pool or adding session hosts, select “Image” and browse to your gallery image.
- ARM/Bicep: Reference the image version ID in the VM resource’s
storageProfile.imageReference. - PowerShell: Use the
-ImageReferenceIdparameter when creating VMs.
The deployed VMs are independent copies — changes to the source image do not affect running session hosts. To update session hosts, you build a new image version and deploy new VMs from it.
🎧 Mia’s tip: “I always test a new image by deploying one session host to our validation host pool first. Tom and I log in, check the EHR app, verify printing works, and confirm the update did not break anything. Only then do I roll it out to the production pools.”
Exam tip: Manual vs Image Builder decision
The exam often presents scenarios and asks you to choose between manual image creation and VM Image Builder. The decision factors are:
- Scale and frequency: If you build images monthly or have many host pools, use Image Builder.
- One-off or prototype: Manual is fine for a single test image.
- Compliance and audit: Image Builder provides a repeatable, auditable template — better for regulated environments.
- CI/CD integration: Only Image Builder integrates naturally with pipelines.
If the question mentions “repeatable,” “automated,” or “pipeline,” the answer is Image Builder. If it mentions “quick test” or “single image,” manual is acceptable.
Raj wants to build AVD session host images automatically every month after Patch Tuesday, integrated with TerraStack's CI/CD pipeline. Which approach should he use?
Mia runs Sysprep on a VM she prepared for imaging, but it fails with an error. Where should she look first to diagnose the issue?
Which image storage option should you use for production AVD deployments that span multiple Azure regions?
🎬 Video coming soon
Building Session Host Images
Next up: Image Lifecycle and Compute Gallery — manage image versions, automate distribution across regions, and build a production-grade image pipeline with testing and deprecation.