Azure Virtual Desktop Hybrid for On-Premises VDI

Introduction

Azure Virtual Desktop Hybrid gives organizations another path between traditional on-premises VDI and fully Azure-hosted desktops. This article explains how the architecture works, how Azure Arc connects local session hosts to AVD, what changes for existing VDI infrastructure, and which limitations remain. It also examines when Hybrid AVD makes sense and what IT teams should evaluate before adopting it.

What Is Azure Virtual Desktop Hybrid?

Azure Virtual Desktop Hybrid is a deployment model where the Azure Virtual Desktop service is still hosted and managed by Microsoft in Azure, but the Windows session hosts delivering the desktops and apps are on-premises.

Microsoft uses Azure Arc to establish connectivity between environments. All supported on-premises computers will be Azure Arc-enabled servers. Then, the Azure Virtual Desktop Arc extension installs the required AVD components and registers this computer as a session host in an AVD host pool.

Everything is more or less the same for the end user as if they were using AVD hosted in Azure. Users access the assigned desktops or apps via Windows App. However, the difference is that the Windows workload will be delivered from the customer’s infrastructure and not from Azure compute.

So there is a separation of infrastructure where:

Component	Where It Runs	Who Manages It
AVD service and brokering	Azure	Microsoft
Host pools, application groups and assignments	Azure	Customer configures them
Windows session hosts	On-premises	Customer
Hypervisor or physical infrastructure	On-premises	Customer
Session-host OS and applications	On-premises	Customer
Local networking and storage	On-premises	Customer
Azure Arc integration	Azure + on premises	Shared dependency

The main takeaway here is that "hybrid" is a description of the distribution of distinct elements in the VDI architecture. Azure Virtual Desktop, in and of itself, never became a fully on-premises solution.

How Does Azure Virtual Desktop Hybrid Work?

The architecture starts with the machines that deliver desktops or applications. Organizations provide supported Windows virtual machines or supported headless physical devices on their own infrastructure.

The Azure Connected Machine agent registers each session host with Azure Arc. An Azure Virtual Desktop Arc extension can then install the required AVD components and register the machine with an AVD host pool.

Azure Arc does not provide or manage the underlying virtual machine. The session host is part of the organization's local infrastructure, which means that the organization's IT team is responsible for the session host's lifecycle, capacity and underlying virtualization platform.

When a user connects, Azure Virtual Desktop provides the service-side capabilities to discover resources, authenticate access and mediate the session. The actual Windows workload runs on the local session host.

This architecture separates the AVD service from the session hosts, differentiating Hybrid AVD from both. traditional on-premises VDI and standard Azure-hosted AVD: Microsoft manages the cloud service, but the customer continues to operate the compute infrastructure.

How Does Hybrid AVD Change an Existing On-Premises VDI Environment?

For existing VDI environments, the challenge is not only if current servers can be retained in the datacentre, but which layers of the existing architecture were retained, which AVD replaced, and which operational responsibilities were retained by the organisation.

Existing Compute Can Remain On Premises

Unlike a full Azure AVD migration, where session-host compute moves to Azure, this requires no changes to existing session hosts in the datacentre.

Organizations can take advantage of supported Windows virtual machines on their preferred hypervisor in their on-premises datacentres. This can be useful in cases where there is substantial existing virtualisation infrastructure, or applications are heavily dependent on existing on-premises systems.

The presence of existing hardware does not imply that the VDI environment is unchanged, however. Session hosts must be brought into compliance with Microsoft's specifications and enrolled as Azure Arc-enabled before they can be used with Azure Virtual Hybrid Desktop.

The VDI Control Plane Moves to Azure

The most significant architectural differences appear above the session hosts.

Instead of operating the full desktop delivery stack in-house, the organization consumes the Azure Virtual Desktop platform. Microsoft exposes core components of the service for resource discovery, brokering, and gateway connectivity.

Organizations retain responsibility for configuring host pools, application groups, workspaces and user entitlements, but these resources are now part of the AVD architecture. Prior on-premises brokers, gateways and management components may no longer need to perform the same functions.

Local Infrastructure Management Remains

Shifting the service layer to Azure does not make the supporting infrastructure Microsoft-managed.

IT teams retain responsibility for provisioning, patching and maintaining local hardware, operating systems, applications, networking, storage and the underlying virtualization platform. Microsoft explicitly documents that Azure Virtual Desktop Hybrid does not provision on-premises session host VMs or manage their power state.

Hybrid AVD should be understood as a redistribution of VDI responsibilities rather than a hand-off of the entire solution stack to Microsoft.

In which case does it make sense to keep AVD session hosts on premises?

If Azure already provides the AVD service, going the route of putting that session host into Azure might seem the easiest path. Hybrid comes into play when there's a technical, cost or operational justification for keeping workloads in the datacentre.

Legacy Applications and Local Dependencies

The applications being virtualised are often Windows apps that rely heavily on local databases, file shares, authentication services, peripherals or other backend systems.

You don't gain much by putting the session host in Azure but leaving the app dependencies on-premises, since you'll just add network latency to the mix. Staying close to the back end avoids having to rip up the application architecture just to change where end users connect from.

This is especially true of legacy line-of-business applications that were designed to work in a local area network environment.

Data Location and Infrastructure Requirements

Some companies need certain workloads or data to reside on infrastructure under their control for regulatory, contractual or operational reasons.

Hybrid AVD allows desktop and app processing to stay local while using Azure for the desktop delivery service. IT teams should nevertheless carefully analyse this architectural option against their compliance requirements since the hybrid model still relies on Microsoft Azure.

Existing Datacenter Investment

Organizations with available spare capacity in servers, storage and virtualization resources may have little immediate incentive to change that.

Hybrid AVD could allow such companies to acquire new capacity in waves where existing compute resources continue handling workloads while the control plane is transformed around it. The architecture also lends itself to iterative modernisation since different workloads can be migrated at different paces.

Workloads Sensitive to Backend Latency

For some applications, the proximity of the session host to the resources it consumes is more important than the proximity of the session host to the end user.

Applications that make frequent calls to local databases, storage systems or other infrastructure may not perform as well if these dependencies are distributed across a WAN. By keeping the Windows session local, the proximity to these resources can be maintained.

When Hybrid AVD May Not Be the Right Fit

The value of keeping session hosts on premises is reduced if the organization's objective is to eliminate datacentre infrastructure rather than maintain it. In such a scenario, the use of Azure-hosted AVD may better fit the desired operating model.

IT teams should also consider if they actually need the Azure Virtual Desktop service model at all. If the primary requirement is the secure publishing of centralized Windows applications or desktops while retaining direct infrastructure control, an Azure-dependent VDI control plane could introduce unnecessary architectural complexity.

Does Hybrid AVD Eliminate VPNs and RD Gateways?

Azure Virtual Desktop eliminates many of the complexities of external connectivity by allowing organisations to avoid exposing individual session hosts to the internet or deploying a standard Remote Desktop Gateway (RD Gateway) for AVD.

AVD uses Microsoft's service infrastructure to connect through the Microsoft service. The default transport uses TCP-based reverse connect, while RDP Shortpath can negotiate a UDP-based transport if the network and configuration support it.

For organizations that currently have a VDI environment that uses an inbound Remote Desktop Protocol (RDP) connection as well as other methods such as VPN access or locally managed RD Gateways for remote access this could significantly change the architecture of the external access.

Network connectivity requirements are not eliminated. On-premises session hosts still need to connect to the appropriate Azure services, while applications need reliable access to local dependencies. Connectivity considerations such as DNS, identity, firewall configuration, routing and resiliency are therefore still important design elements.

What Are the Limitations of Azure Virtual Desktop Hybrid?

Hybrid AVD offers deployment flexibility, but there are some important differences from Azure-hosted AVD that can impact architecture and operations.

Microsoft currently defines several session host management capabilities as unsupported for Hybrid AVD:

• Power management
• Azure Virtual Desktop Autoscale
• Start VM on Connect
• Session Host Configuration

Enterprises would be responsible for providing these capabilities through their hypervisor, scripts, automation or other tools.

Additionally, the OS support is different as there is no support for Azure Virtual Desktop Hybrid with Windows 10 Enterprise multi-session and Windows 11 Enterprise multi-session. This is a significant difference because multi-session Windows client operating systems are a key feature of Azure hosted AVD.

Licensing requirements should also be reviewed carefully considering the intended operating system and use case. It should be confirmed whether requirements for Microsoft's Azure Virtual Desktop Hybrid licensing apply beyond existing VDI, Remote Desktop Services or Microsoft 365 licenses.

Finally, having local session hosts does not make AVD deployment cloud independent, as the Microsoft managed Azure Virtual Desktop service continues to be an integral part of the architecture.

Azure-Hosted AVD vs Hybrid AVD vs Traditional On-Premises VDI

Final version of the sentence (rewritten, using different words, with some sentences changed in structure or length):

	Traditional On-Premises VDI	Azure Virtual Desktop Hybrid	Azure-Hosted AVD
Session hosts	On-premises	On-premises	Azure
VDI service/control plane	Usually customer/vendor infrastructure	Microsoft AVD in Azure	Microsoft AVD in Azure
Local hypervisor required	Typically yes	Yes for VM-based hosts	No
Local compute management	Customer	Customer	Not applicable to local compute
Native AVD VM lifecycle features	No	Limited	Broader support
Proximity to local applications	High	High	Depends on network design
Azure dependency	Product-dependent	Yes	Yes
Azure compute consumption	No	Not for local session hosts	Yes

Thus, hybrid AVD has a middle ground architecture, where the workloads are delivered from the cloud (managed by Microsoft), but the local compute is customer managed.

Such an architectural choice is only justifiable if there is a benefit of keeping the workloads local.

How Should IT Teams Evaluate a Move to Hybrid AVD?

A Hybrid AVD assessment should start not with Azure but with workloads and dependencies.

Identify which applications and desktops must be kept on premises and document their dependencies on databases, file services, identity systems, peripherals, storage and other infrastructure. This makes it possible to establish whether maintaining session hosts on premises has any architectural merit.

The current state of the VDI stack should be mapped to the AVD model. Which brokers, gateways and management services will be replaced by Azure Virtual Desktop? What operational responsibilities will remain?

Session host lifecycle management is a key consideration. If the existing VDI platform includes automatic provisioning, start/stop or scaling of VMs, assess whether those capabilities are available in Hybrid AVD rather than presuming that the Azure control plane will replace them.

Identity, networking, licensing, resiliency and operational responsibilities should be evaluated as a group. The goal is not only to determine whether existing machines can be registered with Azure Virtual Desktop, but whether separating VDI infrastructure between Azure and the datacentre will produce a simpler and more sustainable environment.

Looking for a simpler way to deliver Windows applications and desktops?

Hybrid AVD can make sense when an organization specifically wants Azure Virtual Desktop while keeping session hosts on premises. But not every organization needs to split its desktop-delivery architecture between an Azure-managed service and locally managed compute.

Where the requirement is primarily to publish Windows applications or full desktops securely from existing Windows infrastructure, TSplus Remote Access provides a more direct alternative. Organizations can deliver applications and desktops through RDP-compatible or browser-based HTML5 access while retaining control over where the supporting infrastructure runs.

Conclusion

Azure Virtual Desktop Hybrid provides a middle ground between traditional on-premises VDI and Azure-hosted AVD. It moves key desktop-delivery services to Azure while allowing Windows session hosts and their workloads to remain within existing infrastructure.

The deciding factor is whether keeping those workloads local provides a clear technical or operational benefit. IT teams should evaluate application dependencies, infrastructure management, networking, licensing and Azure dependency together before deciding whether Hybrid AVD genuinely simplifies their VDI environment.