Why Azure Doesn’t Do Full Image Management Natively, and How to Fill the Gap
October 2, 2025
In the world of cloud desktops, virtual machines, and scalable workloads, “image management” often gets over-simplified. Many folks think: “That’s easy! I’ll build a VM image, push it somewhere, and then all my hosts will use it.” However, in practice, real enterprise needs go well beyond that.
You need to coordinate image rollouts across host pools, orchestrate refresh windows, validate health, support rollback, handle cross-region deployments, and more.
Microsoft gives you powerful building blocks in Azure, such as the VM Image Builder and Azure Compute Gallery, which are great for infrastructure, but it doesn’t give you the full orchestration engine that AVD truly requires. That’s the gap–enterprises need the glue that ties those pieces together to manage an AVD image lifecycle reliably at scale.
Azure’s Native Image Capabilities: What You Get (and What You Don’t)
What Azure Gives You
- VM Image Builder is an Azure service that removes much of the complexity of building customized VM images. You declare your source image, customization scripts, and distribution targets (Compute Gallery, managed image, VHD), and the service handles provisioning, executing customizations, Sysprep/generalization, and publishing.
- When integrated with Azure Compute Gallery, images published by Image Builder can be versioned, replicated, and shared across regions/subscriptions. Compute Gallery supports various features: replication (across regions), versioning, controlling which version is “latest,” and managing limits on image definitions, versions, and galleries.
- You can tag non-production image versions as “Test” to prevent new deployments from defaulting to it.
- Azure docs provide example templates, automation scripts, and integration with DevOps pipelines.
What Azure Doesn’t Handle: The Orchestration Gaps
| Enterprise Need | Native Azure Support | Gap / What’s Missing |
| Coordinated Host Refresh / Rollout | None – Azure doesn’t orchestrate replacing existing VMs in host pools outside of autoscaling. | You must script or manage host-by-host and manage health checks or sequencing. |
| Health Checks & Validation | None | No built-in safeguards (e.g., “only decommission old host if new one is healthy”). |
| Rollback / Fallback | Partial via image versioning | The process to transition back is not smooth. |
| Scheduling / Change Windows | None | No built-in windowing or image deployment wizards. |
| State Tracking / Drift Detection | Very limited | Fails to capture host-to-version mapping in an integrated way. |
While Azure takes care of image building, storage, and replication, you’ll still need to manage the deployment and maintenance of those images across fleets yourself, or with the help of a third-party tool.
The Orchestration Gap: Why It Matters
Imagine you have a fleet of session hosts in an Azure Virtual Desktop (AVD) environment. You release a patched “golden image” version. What comes next?
- You need to roll out the new image to host pools, ideally without disrupting users.
- You want to validate that the new hosts are healthy (boot, app load, logon) before retiring the old ones.
- You may need to pause or rollback deployments if issues show up.
- You might wish to do phased rollouts (e.g., pilot pool, then full prod rollout).
- In multi-region or multi-subscription setups, you must coordinate region-by-region.
- You also need to track and report which host is on what version (aka, drift detection).
Without orchestration, you end up with scripts, manual steps, or ad-hoc procedures, which can lead to broken rollouts, partial failures, or service disruption. Community voices resonate with this. One Reddit user wrote:
“We use Hydra … it lets you create Images without destroying the original Master Image VM … if you want to revert, just choose the Version … and rebuild.”
Hydra docs describe “Replace vs Recreate” strategies for various use cases:
- Replace: roll out a new session host first; once it’s healthy, delete the old one.
- Recreate: immediately delete and rebuild the host in place (useful in certain scenarios, such as quickly recreating a host in drain mode).
These are the kinds of orchestrated behaviors enterprises need for safe, repeatable image lifecycles.
Azure Image Builder and Compute Gallery are powerful building blocks, but they’re not the full enterprise solution that AVD needs. Enterprises don’t just need to create images. They need to deploy them safely, validate them continuously, and roll back quickly if something breaks. That requires orchestration: coordinated host refresh, health checks, phased rollouts, and clear visibility into which version is running where.
This is the missing layer of “full image management” in Azure. Recognizing that gap is the first step. From there, organizations can explore orchestration strategies, whether through custom automation or specialized platforms.
Want to learn more about how Hydra can help you bring control, safety, and repeatability into the AVD image lifecycle? Get a demo today!
Hydra
