For years, “AVD on-premises” needed a footnote. Usually, it meant Azure Local, or an Azure deployment with enough connections back to the datacenter to call it hybrid. That is no longer the whole story.
Microsoft lists Azure Virtual Desktop Hybrid as generally available in its September 2026 release notes. Session hosts can run on existing on-premises infrastructure, with Azure Arc connecting them to the AVD service. The April version of this article talked about a direction of travel. There is now a documented deployment model to assess.
My view has not changed on the central trade-off: you can keep the desktops close to your applications, but Azure still runs the control plane. That is useful. It is also a very different proposition from a self-contained, on-premises VDI platform.
The boundaries I would check first
Before discussing the benefits, I would put these requirements on the table. They can rule a design in or out much faster than a feature presentation.
- No Windows Enterprise multisession in AVD Hybrid. Microsoft's Hybrid matrix supports Windows 10/11 Enterprise, but explicitly excludes their multisession editions. Windows Server is the relevant supported route when evaluating shared server-based sessions. Do not import the Azure Local multisession story into this offer.
- Azure connectivity is still required. Session hosts need the required AVD URLs and Azure Arc endpoints. Keeping compute local does not turn AVD into a disconnected desktop service.
- You own host deployment and power state. AVD Hybrid does not provide VM provisioning, power management, autoscale, Start VM on Connect, or Session Host Configuration.
- Identity depends on the host OS. Windows client hosts can be Entra joined, AD DS joined, or hybrid joined. Windows Server hosts must be AD DS joined or hybrid joined; Entra-only join is not supported because of the RDS licensing-server dependency.
- Licensing has two layers. The Hybrid overview distinguishes the supported OS/user entitlement from the AVD Hybrid service user license. For Windows Server, check the documented RDS CAL with Software Assurance or RDS User Subscription License requirements. Owning the hardware does not settle the licensing question.
These are the documented boundaries checked on 27 October 2026, not a promise that every Windows image or existing hypervisor estate is ready to use unchanged. OS lifecycle, application support and infrastructure compatibility still need checking.
What has actually changed
The important change is placement. The Hybrid overview explicitly describes session hosts on an on-premises hypervisor that supports Windows VMs, as well as supported headless physical devices. This is no longer just an inference from Azure Arc's broader capabilities.
That physical-device option needs reading carefully. It is about dedicated, headless session hosts, such as rack-mounted systems, not enrolling somebody's everyday laptop as an AVD desktop.
I find this interesting because the infrastructure decision and the desktop-brokering decision no longer have to be the same decision. An organisation can keep a suitable local compute platform while adopting Microsoft's hosted desktop service. It still needs to establish who supports each layer, rather than treating “runs Windows” as an end-to-end support guarantee.
Arc connects the host. It does not run your datacenter.
The deployment sequence is quite straightforward: deploy a supported Windows machine, connect it to Azure Arc, create the AVD resources, then deploy the AVD Arc extension to install the components and register the host.
The host pool needs a managed identity, with Reader access to the resource group containing the Arc-enabled machines. That is a real configuration requirement, not a detail to leave until the first failed registration.
Microsoft operates the AVD service. Your team operates the hosts, hypervisor, capacity, storage and local network. Arc is the bridge between those responsibilities; it does not remove the second half of the job.
This is where I would spend time on an existing estate. How are images built? How are hosts drained and replaced? Who patches the underlying platform? What restores a failed profile share? The broker is managed, but those answers still belong to you.
Azure Local and AVD Hybrid are not interchangeable
AVD on Azure Local remains a separate, documented path. Its supported configurations include Windows Enterprise multisession, subject to the applicable platform, activation and licensing requirements. The broader Arc-enabled Hybrid offer does not include that capability.
That distinction can change the economics before any hardware comparison begins. A design based on pooled Windows 11 multisession cannot simply move to a different local hypervisor under the Hybrid label and assume the same session density or licensing model.
The comparison needs to start with the workload: single-user Windows desktops, shared Windows Server sessions, application compatibility, local infrastructure constraints, and the actual operating model. “On-premises AVD” is now too broad a label to make that decision.
Local workloads, not cloud independence
The strongest use case is still data gravity. If an application spends its day talking to a database in the datacenter, placing the session host beside that database can avoid moving the application's latency-sensitive traffic across a WAN.
Users still connect through the AVD experience using Windows App. A local host does not, by itself, prove a particular transport path, Shortpath capability or end-to-end latency. Those need validation with the chosen hosts, clients and network.
The same restraint applies to resilience and sovereignty. Local application and profile storage can be part of a locality design, but AVD resources and service dependencies remain in Azure. For a regulatory assessment, I would review the AVD data-location documentation, identity flows and operational access before describing the result as meeting a regulatory requirement.
Most importantly, I would test a loss of Azure connectivity. Existing-session behaviour, reconnects and new session launches are different cases. None should be replaced by the comforting but incorrect assumption that local compute means autonomous brokering.
Where I think it fits
I would take AVD Hybrid seriously for an organisation that wants Microsoft's desktop service but has a good reason to retain local compute: application latency, an existing infrastructure investment, or a staged migration that does not start with moving every workload to Azure.
I would be much less enthusiastic if the requirement were disconnected operation, Windows Enterprise multisession on an arbitrary hypervisor, or AVD-managed power and host lifecycle. Those are not small gaps around the edges. They affect the architecture.
The next useful conversation is therefore not “Can AVD run here?” It is “Which workloads fit, which responsibilities remain, and does the full cost still make sense?” Include local operations, resilience, user licensing and the Hybrid service license in that calculation.
The change since April is substantial: AVD Hybrid has moved from a promising direction to a generally available option with explicit boundaries. That makes it easier to evaluate, not automatically the right answer.
The desktops can live in your datacenter. The brain still lives in Azure. I see a credible place for that model, provided both halves of that sentence make it into the design.
Sources
- Microsoft: What's new in AVD — September 2026 Hybrid GA announcement.
- Microsoft: AVD Hybrid overview — supported hosts, OS/licensing matrix and management limitations.
- Microsoft: Deploy AVD Hybrid — Arc, identity, permissions and registration requirements.
- Microsoft: AVD on Azure Local — separate platform capabilities and constraints.