This chapter covers the process of generalizing and capturing Azure VM images, a critical skill for scaling VM deployments consistently. On the AZ-104 exam, this topic appears in approximately 10-15% of questions under Compute objective 3.1, focusing on creating and managing custom images. Understanding the difference between generalized and specialized images, the Sysprep and waagent tools, and the capture workflow is essential for passing the exam and for real-world Azure administration.
Jump to a section
Imagine a factory that produces software discs. To create a perfect copy of a disc, you first need a master disc that is 'generalized' — stripped of all unique identifiers like serial numbers, installation IDs, and user-specific data. This master is created by running a tool (Sysprep) that removes all computer-specific information, leaving a clean, reusable template. Once the master is created, it is 'captured' by placing it into a disc duplicator that reads every sector and produces an image file (VHD). This image can then be stored in a library (Azure Compute Gallery) and used to stamp out hundreds of identical discs (VMs) on demand. Each new disc gets its own unique serial number assigned during the first boot (specialization), just like a VM gets a new SID and computer name. The factory cannot use a disc that has already been personalized as a master — it must be generalized first. This mirrors Azure's requirement: you must generalize a VM (using Sysprep for Windows or waagent -deprovision for Linux) before capturing it to create reusable images.
What Are Generalized and Specialized Images?
In Azure, a VM image is a template used to create new VMs. There are two types: generalized and specialized. A generalized image has been stripped of all machine-specific information, such as the computer name, security identifiers (SID), user accounts, and logs. It is ready to be used as a template for creating many identical VMs, each of which will be 'specialized' during first boot (a process called 'specialization'). A specialized image retains all the machine-specific information from the source VM, including the computer name, SID, and installed applications. It is used when you need to create an exact replica of a VM, typically for disaster recovery or migration scenarios.
For the AZ-104 exam, you must know when to use each type. Generalized images are used for scaling out workloads (e.g., web servers, application servers) where each VM should be identical but have unique identity. Specialized images are used for cloning a specific VM, such as a domain controller or a server with complex configuration that you want to duplicate exactly.
The Generalization Process
Generalization is performed using operating system tools. For Windows VMs, the tool is Sysprep (System Preparation Tool). For Linux VMs, the tool is waagent -deprovision (for Azure Linux Agent) or cloud-init depending on the distribution.
Sysprep on Windows:
- Sysprep is located at %SystemRoot%\System32\Sysprep\sysprep.exe.
- To generalize a Windows VM, you run Sysprep with the /generalize and /oobe (Out-Of-Box Experience) switches. The /generalize switch removes machine-specific data, and /oobe configures the VM to boot into the Windows setup screen on next boot.
- The command: sysprep /generalize /oobe /shutdown — this will generalize the VM and then shut it down.
- Important: Sysprep must be run from within the VM after logging in as a local administrator. It is a one-way operation; once generalized, the VM cannot be booted normally again without going through OOBE.
- Sysprep requires that the Windows image be 'sysprep-able' — not all images (e.g., those with certain roles or apps) can be generalized. The exam may test that you cannot generalize a VM that has Active Directory Domain Services installed, for example.
waagent -deprovision on Linux:
- On Linux, the Azure Linux Agent (waagent) provides the deprovision command: sudo waagent -deprovision+user.
- The -deprovision switch cleans up machine-specific files (hostname, SSH host keys, resolv.conf, etc.). The +user option also removes the last provisioned user account (the one used to create the VM).
- After running, the VM is shut down. The command must be run with sudo.
- For cloud-init images, you may use cloud-init clean instead.
Capturing the Image
Once the VM is generalized and shut down, you can capture it to create an image. In the Azure portal, you navigate to the VM, click 'Capture', and provide:
Image name
Resource group
Optionally, automatically delete the source VM after capture (a checkbox)
The capture process creates a managed image resource (a Microsoft.Compute/images resource) in the specified resource group. This image is stored as a managed disk snapshot in the Azure platform. The image can then be used to create new VMs.
Azure CLI example:
az vm deallocate --resource-group myRG --name myVM
echo 'Generalizing...'
az vm generalize --resource-group myRG --name myVM
echo 'Capturing...'
az image create --resource-group myRG --source myVM --name myImagePowerShell example:
Stop-AzVM -ResourceGroupName myRG -Name myVM -Force
Set-AzVM -ResourceGroupName myRG -Name myVM -Generalized
New-AzImage -ResourceGroupName myRG -ImageName myImage -SourceVMId (Get-AzVM -ResourceGroupName myRG -Name myVM).IdImportant: The VM must be deallocated (stopped) before generalization and capture. The az vm deallocate command releases the VM's hardware lease. The generalization flag (az vm generalize) marks the VM as generalized in Azure's metadata. This is a separate step from running Sysprep inside the VM. If you forget to run Sysprep but mark the VM as generalized, the resulting image will boot into the old configuration (not OOBE) and may cause issues. Conversely, if you run Sysprep but forget to mark as generalized, Azure will not allow you to capture the VM.
Azure Compute Gallery (formerly Shared Image Gallery)
For enterprise-scale image management, Azure provides the Azure Compute Gallery (formerly Shared Image Gallery). This service allows you to store multiple versions of images, replicate them across regions, and share them with other subscriptions or tenants. The gallery is built on top of managed images and snapshots.
Key components: - Gallery: Top-level container for images. - Image Definition: A logical grouping of image versions, with metadata like OS type (Windows/Linux), publisher, offer, SKU, and whether it's generalized or specialized. - Image Version: A specific version of the image, stored as a managed disk snapshot. You can have multiple versions (e.g., 1.0.0, 1.0.1) and replicate them to different regions.
To create a gallery image, you first create a gallery, then an image definition, then an image version from a source (managed image, snapshot, or another version). The replication process copies the image to target regions; you can specify the number of replicas per region for high availability.
Interaction with Other Azure Services
VM Scale Sets: Custom images are often used with VMSS to ensure all instances are identical. You can reference a managed image or a gallery image version in the VMSS configuration.
Azure Policy: You can enforce that only approved images from a gallery are used to create VMs.
Azure Backup: Backed-up VMs can be restored as new VMs; you can choose to restore as a specialized or generalized image.
Azure Site Recovery: Replicated VMs can be used to create custom images after failover.
Defaults and Timers
Sysprep shutdown timeout: By default, Sysprep will wait up to 30 minutes for the generalization to complete before shutting down. If it times out, the process fails.
Azure VM generalization flag: This is a metadata flag; there is no timer. The flag persists until the VM is deleted or re-deployed.
Gallery image version replication: Replication can take a few minutes to hours depending on image size and number of regions. You can check replication status via CLI or portal.
Verification Commands
Check generalization status: az vm show --resource-group myRG --name myVM --query 'storageProfile.osDisk.osType' — this shows OS type; generalization flag is not directly exposed.
List managed images: az image list --resource-group myRG
List gallery images: az sig image-version list --resource-group myRG --gallery-name myGallery --gallery-image-definition myImageDef
Prepare the source VM
Ensure the source VM is running the latest updates and has all required applications installed. Remove any temporary files or user-specific data. For Windows, run Disk Cleanup. For Linux, clean package caches. This step ensures the image is clean and reduces size. The VM must be a managed disk VM; unmanaged disks are deprecated. Note that you cannot capture a VM that is part of a VMSS directly — you must capture one instance after generalizing it.
Generalize the OS
Log into the VM and run the generalization tool. For Windows: run `sysprep /generalize /oobe /shutdown` from an elevated command prompt. For Linux: run `sudo waagent -deprovision+user`. This process removes machine-specific identifiers. Sysprep clears the SID, computer name, and other unique data. waagent removes SSH host keys, hostname, and user accounts. After this, the VM will shut down automatically. Do not restart the VM after generalization; it must remain off.
Deallocate the VM
In Azure, stop the VM using `az vm deallocate` or the portal. This releases the hardware lease and stops billing for compute. The VM status changes to 'Stopped (deallocated)'. This is required before you can mark it as generalized. If you only stop (not deallocate), the VM retains its hardware reservation and cannot be captured.
Mark the VM as Generalized
Use `az vm generalize` or the portal to set the generalization flag. This tells Azure that the OS inside the VM has been generalized. Without this step, Azure will not allow you to create an image. The flag is stored in the VM's metadata. You can verify with `az vm show --query 'provisioningState'` but the generalization flag is not directly queryable via CLI; you must rely on the capture step to succeed.
Capture the Image
Use `az image create` or the portal to create a managed image from the generalized VM. Specify the image name and resource group. Optionally, check 'Automatically delete this VM after creating the image' if you no longer need the source. The capture process creates a `Microsoft.Compute/images` resource. This image can be used to create new VMs. The source VM is not deleted unless you choose that option, but it remains deallocated and generalized — you cannot start it again normally (it would boot into OOBE).
Distribute via Azure Compute Gallery
For production use, create an Azure Compute Gallery and add the captured image as an image version. Create a gallery, then an image definition (specifying OS type, publisher, offer, SKU, and whether it's generalized or specialized). Then create an image version from the managed image. You can replicate the version to multiple regions and set the number of replicas per region. This allows you to deploy VMs quickly in any region with low latency.
Scenario 1: Enterprise Web Farm Scaling
A large e-commerce company needs to deploy hundreds of identical web servers across multiple Azure regions for a global sales event. They create a custom Windows Server 2022 image with IIS, .NET Core, and all security patches pre-installed. The image is generalized using Sysprep and captured as a managed image. They then import it into an Azure Compute Gallery, create an image definition for 'Windows-WebServer', and publish version 1.0.0. Using Azure Policy, they mandate that all web VMs must use this image version. The image is replicated to three regions (West US, North Europe, Southeast Asia) with three replicas each. During the event, they use VMSS to auto-scale based on CPU load. The image deployment is consistent, and new VMs boot in under 5 minutes. A common misconfiguration is forgetting to disable Windows Defender real-time scanning during Sysprep, which can cause the process to hang.
Scenario 2: Dev/Test Lab Environment
A software development team uses Azure DevTest Labs to provide developers with pre-configured VMs. They create a base Linux image with Ubuntu 22.04, Docker, and development tools. They generalize it using waagent -deprovision+user and capture it. The image is stored in a gallery and shared with the DevTest Labs lab. Developers can create VMs from this image with custom artifacts added. The team must ensure that the image is updated monthly with security patches. They use a pipeline in Azure DevOps to automate: take the latest marketplace image, customize it, generalize, capture, and publish a new version. A pitfall is that waagent -deprovision removes the user account that was used to create the VM, so the resulting image has no default user — developers must specify a username/password during VM creation.
Scenario 3: Disaster Recovery with Specialized Images
A financial institution uses Azure Site Recovery to replicate on-premises SQL Server VMs to Azure. After a disaster, they fail over to Azure and need to create exact replicas of the SQL VMs for forensic analysis. They cannot use generalized images because the SQL Server configuration and instance names must be preserved. Instead, they create specialized images from the failed-over VMs. They stop the VM, do NOT generalize, and capture a managed image. This image retains the computer name, SID, and all application settings. They then deploy new VMs from this image for analysis. The challenge is that multiple VMs from the same specialized image will have the same SID, which can cause domain join issues. Therefore, specialized images are typically used for single-instance recovery, not scaling.
What AZ-104 Tests
Objective 3.1: 'Create and configure virtual machines' includes creating images from VMs, managing Azure Compute Gallery, and deploying VMs from custom images. Specific sub-objectives:
Implement the appropriate image strategy (generalized vs specialized).
Create and manage images using the portal, Azure CLI, and PowerShell.
Create and manage Azure Compute Gallery (formerly Shared Image Gallery).
Replicate images across regions.
Common Wrong Answers and Traps
Thinking you can capture a running VM: The VM must be deallocated and generalized. Candidates often try to capture while the VM is running or stopped (not deallocated). The exam will present a scenario where the VM is 'stopped' but not deallocated — the capture will fail.
Confusing generalized and specialized: A question might ask which image type to use for scaling out. The wrong answer is 'specialized' because it seems easier (no Sysprep). But specialized images cause SID conflicts and cannot be used for multiple identical VMs.
Forgetting to run Sysprep before capturing: The exam may describe a candidate who ran az vm generalize but did not run Sysprep inside the VM. The image will be created but the resulting VMs will not go through OOBE and may have incorrect configuration.
Assuming Linux uses Sysprep: Linux uses waagent or cloud-init, not Sysprep. The exam may list 'Sysprep' as an option for Linux — that is incorrect.
Overlooking the 'Automatically delete' checkbox: The exam may ask what happens if you check that box — the source VM is deleted after image creation. If you need to keep the source, uncheck it.
Specific Numbers and Terms
Sysprep switches: /generalize, /oobe, /shutdown.
waagent command: sudo waagent -deprovision+user.
CLI commands: az vm deallocate, az vm generalize, az image create, az sig create, az sig image-definition create, az sig image-version create.
Gallery components: Gallery, Image Definition, Image Version.
Replication: You can replicate to up to 50 regions per image version.
Image types: Generalized (default for gallery definitions) and specialized.
Edge Cases
Sysprep failure: If Sysprep fails, the VM may be in an inconsistent state. You must redeploy from a backup or recreate the image.
Domain-joined VMs: You cannot generalize a domain-joined VM; Sysprep will fail. You must unjoin the domain first.
Azure VM with unmanaged disks: Unmanaged disks are not supported for capture; you must migrate to managed disks.
Image from snapshot: You can create a managed image directly from a snapshot (of a generalized VM) without having the source VM.
How to Eliminate Wrong Answers
If the question asks about 'creating many identical VMs', look for 'generalized' and 'Sysprep' or 'waagent'.
If the question mentions 'preserving computer name and SID', it's specialized.
If the question involves 'Shared Image Gallery' (now Azure Compute Gallery), remember the hierarchy: Gallery -> Image Definition -> Image Version.
For replication, the answer should include 'replicate' and 'target regions'.
Commands: az vm deallocate before az vm generalize before az image create.
Generalization removes machine-specific info; specialization retains it.
Sysprep /generalize /oobe /shutdown is required for Windows VMs before capture.
waagent -deprovision+user is required for Linux VMs before capture.
The VM must be deallocated (stopped) before generalization and capture.
Capture creates a managed image resource; use Azure Compute Gallery for versioning and replication.
Azure Compute Gallery components: Gallery -> Image Definition -> Image Version.
Replicate images to multiple regions for low-latency deployments.
These come up on the exam all the time. Here's how to tell them apart.
Generalized Image
Removes machine-specific data (SID, computer name, etc.)
Requires Sysprep (Windows) or waagent -deprovision (Linux)
Used for scaling out multiple identical VMs
Boots into OOBE on first start
Can be used in VMSS and Azure Compute Gallery
Specialized Image
Retains all machine-specific data
No generalization tool required
Used for exact replication (migration, disaster recovery)
Boots directly to desktop/console
Not recommended for VMSS; may cause conflicts
Mistake
You can capture a VM while it is running.
Correct
The VM must be deallocated (stopped) and generalized before capture. Capturing a running VM is not supported; you will get an error.
Mistake
Sysprep is required for Linux VMs.
Correct
Linux VMs use `waagent -deprovision` or `cloud-init clean` to generalize. Sysprep is a Windows-only tool.
Mistake
A generalized image retains the computer name and SID.
Correct
Generalization removes computer name, SID, and other unique identifiers. The image becomes a clean template for new VMs.
Mistake
You can create a VM from a specialized image and then use it in a scale set.
Correct
Specialized images are not recommended for scale sets because they have duplicate SIDs and computer names, causing conflicts. Use generalized images for scale sets.
Mistake
The `az vm generalize` command runs Sysprep inside the VM.
Correct
The `az vm generalize` command only sets a metadata flag in Azure. You must run Sysprep inside the VM separately before running this command.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Generalized images have been stripped of machine-specific information like computer name and SID using Sysprep (Windows) or waagent (Linux). They are used as templates to create many identical VMs. Specialized images retain all the original VM's identity and are used for cloning a specific VM, such as for disaster recovery. The key exam point: generalized images boot into OOBE; specialized images boot directly to the desktop.
Log into the Windows VM, open an elevated command prompt, and run: `sysprep /generalize /oobe /shutdown`. This will generalize the OS and shut down the VM. After that, deallocate the VM using Azure CLI or portal, then run `az vm generalize` to mark it as generalized in Azure. Finally, capture the image with `az image create`.
No, the VM must be deallocated (stopped) before capture. Stopping the VM from within the OS is not enough; you must use Azure to deallocate it, which releases the hardware lease. The exam often tests this: 'stopped' vs 'deallocated'.
Azure Compute Gallery (formerly Shared Image Gallery) is a service for managing and sharing custom VM images at scale. It allows you to create multiple versions of an image, replicate them across regions, and share them with other subscriptions or tenants. It consists of a gallery, image definitions (metadata), and image versions (actual snapshots). For the exam, know the hierarchy and that you can replicate to up to 50 regions.
Technically, you can run Sysprep on a VM created from a specialized image, but it is not recommended because the image already has a unique SID. It's better to start from a generalized image. The exam may present a scenario where you need to create many VMs from a specialized image — the correct answer is to generalize first.
The VM will be marked as generalized in Azure, but the OS inside still has all its unique identifiers. When you capture and create new VMs from that image, they will not go through OOBE and may have duplicate SIDs and computer names, causing network and domain join issues. The exam will test that both steps are required.
Log into the Linux VM, run `sudo waagent -deprovision+user` (or `cloud-init clean`), which removes machine-specific data and shuts down. Then deallocate the VM, run `az vm generalize`, and capture with `az image create`. For gallery images, use `az sig image-version create`.
You've just covered Generalizing and Capturing VM Images — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?