What Microsoft AVD Hybrid Actually Means
The term gets thrown around for several architectures, and that causes confusion. Let me break down what people are actually referring to when they say “Microsoft AVD hybrid”:
AVD Hybrid (the official product): Session hosts run on your existing on-premises infrastructure or physical Windows Server machines. Azure Arc connects those machines to Azure, and the AVD Arc extension registers them with an AVD host pool. The Azure portal still gives you one management view.
AVD on Azure Stack HCI: Session hosts run on Microsoft’s hyperconverged platform. This is technically a hybrid model, but it’s more tightly integrated with Azure than using your existing VMware or Hyper-V clusters.
Hybrid identity: Users and session hosts span on-premises Active Directory and Microsoft Entra ID. This is common across all AVD deployments, not specific to where the hosts live.
Hybrid networking: AVD resources talk to on-premises applications through VPN or ExpressRoute. Again, common pattern regardless of session-host location.
I’ve seen marketing slides conflate all four. They’re related design choices, but they’re not the same thing. You can have hybrid identity without using Microsoft AVD hybrid session hosts.
The Architecture Behind Microsoft AVD Hybrid
Here’s what the stack looks like when you actually build this:
| Layer | What lives here | Who manages it |
|---|---|---|
| User identity | Microsoft Entra ID authentication, usually synced from AD DS | You (identity team) |
| AVD control plane | Host pools, application groups, brokering, monitoring | Microsoft (Azure service) |
| Hybrid management | Azure Arc agents connecting on-prem machines to Azure | You (infrastructure team) |
| Session hosts | Windows desktops or servers running wherever you decide | You (compute and OS) |
| Profile storage | FSLogix containers on Azure Files, NetApp, or file servers | You (storage team) |
| Network connectivity | Routing between users, Azure services, identity, apps | You (network team) |
The critical distinction: Microsoft provides the AVD service. You provide the compute, storage, and most of the infrastructure.
Users authenticate through Microsoft Entra ID. Then, depending on your design, they sign in to Entra-joined, hybrid-joined, or domain-joined session hosts. The session-host traffic doesn’t necessarily hairpin through Azure—it can go direct to the user once the connection is brokered.
Why Organizations Choose Microsoft AVD Hybrid
Honestly, most organizations would prefer full Azure if they could. Moving everything to the cloud is operationally simpler in the long run. But the world doesn’t work that way.
Here’s what actually drives Microsoft AVD hybrid adoption:
Data Residency and Sovereignty
I’ve worked with European healthcare providers who can’t move patient data to Azure due to regulatory interpretation. They’re not necessarily right, but legal signed off on keeping desktops on-prem. Microsoft AVD hybrid let them modernize the delivery model without waiting for regulatory clarity.
Same story in financial services, government, and some manufacturing. The data can’t leave the country or the facility.
Latency to Critical Applications
Manufacturing ERP systems, clinical imaging platforms, trading applications—these often can’t tolerate the extra 20-50ms from an Azure region. Placing session hosts in the same data centre as those applications keeps round-trip times under 5ms.
I saw one deployment where they kept CAD workstations on-prem because the PLM database was local, but moved standard office desktops to Azure. Mixed model, same management plane.
Existing Hardware Investment
You’ve got three more years on a UCS chassis or a Dell VxRail cluster. Finance won’t approve writing off the asset. Microsoft AVD hybrid turns that depreciated hardware into AVD session hosts.
It’s not the most elegant reason, but it’s the most common one in 2026.
Regulatory Constraints
Some industries have regulators who haven’t caught up with cloud models. Banking supervisors in certain jurisdictions still want to see “where the computer is.” Microsoft AVD hybrid gives you the physical location while adopting modern identity, monitoring, and access control.
Operational Familiarity
If your infrastructure team has been running VMware for 15 years, they know how to troubleshoot it. They know the capacity model. They know the failure modes. Microsoft AVD hybrid doesn’t force them to relearn everything immediately.
That’s a conservative reason, but change management is real.
Microsoft AVD Hybrid vs. Azure Stack HCI
People confuse these constantly. Let me clarify:
| Aspect | Microsoft AVD Hybrid | AVD on Azure Stack HCI |
|---|---|---|
| Infrastructure | Use your existing VMware, Hyper-V, or physical servers | Requires Azure Stack HCI deployment |
| Azure Arc | You Arc-enable individual VMs or servers | Integrated into Stack HCI management |
| Hardware flexibility | Broad—whatever Microsoft supports | Requires validated hardware configurations |
| VM lifecycle | Use existing vSphere, SCVMM, or manual processes | More integrated with Azure workflows |
| Best for | Reusing existing datacenter investments | Standardized Azure-integrated infrastructure |
| Cost model | Use what you own | New hardware purchase + licensing |
Azure Stack HCI is essentially Azure infrastructure that you run in your building. It’s tightly integrated, well-supported, and expensive. Microsoft AVD hybrid is more about connecting what you already have.
If you’re starting fresh, Stack HCI is probably the better long-term bet. If you’re extending existing infrastructure, Microsoft AVD hybrid is more practical.
Licensing: The Part Everyone Gets Wrong
AVD licensing has always been confusing. Microsoft AVD hybrid adds another layer.
User Access Rights
Each user needs an eligible license. The common ones are:
- Microsoft 365 E3, E5, F3, or Business Premium
- Windows 10 or 11 Enterprise E3 or E5
- Windows 10 or 11 Education A3 or A5
- Windows Virtual Desktop Access per-user licenses
This hasn’t changed. If your users have M365 E3, you’re covered for access rights.
Microsoft AVD Hybrid Service Fee
Here’s the new part: Microsoft charges a service fee for the Azure management and orchestration of Microsoft AVD hybrid. This is separate from the user access rights.
It’s also separate from your on-premises hardware costs, Arc licensing, storage, networking, profiles, monitoring, backup, and everything else. The service fee covers the AVD control plane and hybrid management capabilities.
Microsoft’s pricing documentation outlines this, but it’s not a simple per-user or per-VM number—it depends on your configuration and usage.
Windows Server Licensing
If you’re using Windows Server session hosts (multi-session desktops), you need Windows Server licenses with Software Assurance or subscription licenses. This is standard Server licensing, not AVD-specific.
If you’re running Windows 10 or 11 Enterprise multi-session on-premises through Microsoft AVD hybrid, the licensing gets more complex. Check with your Microsoft licensing specialist before building anything.
What the Real Total Cost Looks Like
When I build a TCO model for Microsoft AVD hybrid, I’m accounting for:
- User access rights (M365 E3 in most cases)
- AVD Hybrid service fee
- On-premises server hardware (or existing depreciation)
- Hypervisor licensing (VMware, Hyper-V, etc.)
- Windows Server or Windows Enterprise licensing
- Storage (SAN, NAS, or Azure Files)
- Network infrastructure and bandwidth
- Azure Arc-enabled servers (per-server fee)
- Monitoring and management tools
- Backup and disaster recovery
- Power, cooling, and datacenter space
- Support and operational staffing
The Azure compute costs go away or reduce significantly. Almost everything else stays or shifts.
Identity Design for Microsoft AVD Hybrid
Getting identity right is critical. AVD always authenticates users through Microsoft Entra ID first. Then the session host needs to accept that authentication.
In my experience, most Microsoft AVD hybrid deployments use one of three patterns:
Pattern 1: Hybrid Join with AD DS Synchronization
Session hosts are joined to on-premises Active Directory and registered with Microsoft Entra ID (hybrid join). Users are synchronized from AD DS to Entra using Microsoft Entra Connect.
This is the most common pattern in 2026. It works with existing AD infrastructure, group policies, and file permissions. The trade-off is that you’re maintaining both identity systems.
Pattern 2: Microsoft Entra Join
Session hosts are joined only to Microsoft Entra ID. Users authenticate purely through Entra. No on-premises domain controllers required.
I’ve used this for greenfield deployments or organizations trying to eliminate AD DS. The challenge is application compatibility—some line-of-business apps still expect domain membership.
Pattern 3: Traditional AD DS Domain Join
Session hosts are domain-joined to AD DS. Users still authenticate to AVD through Microsoft Entra ID, then sign in to the session host using synchronized or federated credentials.
This is the legacy pattern. It works, but you’re not taking advantage of modern conditional access and device compliance as effectively.
What Needs to Match Between Systems
If you’re using hybrid identity, the user principal name or security identifier needs to align between AD DS and Microsoft Entra ID. Mismatches cause authentication failures that are annoying to troubleshoot.
I’ve debugged too many deployments where someone changed the UPN suffix in AD but didn’t update the Entra Connect sync rules. Users can’t sign in, and the error messages are unhelpful.
Azure Arc: The Glue in Microsoft AVD Hybrid
Azure Arc is what makes Microsoft AVD hybrid possible. It’s the agent and management framework that connects on-premises machines to Azure.
When you deploy Microsoft AVD hybrid, you:
- Deploy the on-premises VM or configure the physical server
- Install the Azure Arc Connected Machine agent
- Authenticate the machine to your Azure subscription
- Install the Azure Virtual Desktop Arc extension
- Register the machine with an AVD host pool
Arc creates an Azure resource representation of the machine. From the Azure portal, it looks almost like an Azure VM. You can see it in resource groups, apply policies, run extensions, and monitor it.
Permissions and Identity for Arc
Arc uses either a service principal or a managed identity to authenticate the machine to Azure. Microsoft has been pushing toward managed identities for new deployments since late 2025.
According to Microsoft’s current documentation, new host pools using session-host configuration in the Azure portal must use a managed identity from September 19, 2025. Existing host pools using session-host configuration must add a managed identity before updating that configuration from October 15, 2025.
This is a better security posture than long-lived service-principal secrets, but it requires planning. The managed identity needs appropriate role assignments, and you need to document what happens if that identity is deleted or the assignment is removed.
Arc Connectivity Requirements
Arc-enabled machines need outbound HTTPS connectivity to several Azure endpoints. You can’t run Microsoft AVD hybrid in a completely air-gapped environment.
The machine needs to reach:
- Azure Arc service endpoints
- Microsoft Entra ID
- Azure Resource Manager
- Extension and package repositories
- Monitoring and telemetry endpoints
If you’re using a proxy, the Arc agent needs to be configured for it. I’ve had firewall teams block specific subdomains, breaking Arc health reporting while leaving basic connectivity working. Monitor the Arc agent status actively.
Infrastructure and Connectivity Requirements
Let’s be clear: Microsoft AVD hybrid is not an offline solution. You’re not building a disconnected VDI environment. The architecture depends on reliable connectivity to Azure.
What Session Hosts Need to Reach
- Azure Virtual Desktop service endpoints
- Microsoft Entra ID authentication
- Azure Monitor (if you’re using it)
- Domain controllers (for hybrid or domain-joined hosts)
- DNS servers
- Profile storage (Azure Files, NetApp, or file servers)
- Certificate revocation lists
- Windows Update or WSUS
- Antivirus and security updates
- Application servers and databases
That’s a lot of dependencies. Network design matters.
Bandwidth and Latency Considerations
User-to-session-host traffic should have under 150ms round-trip latency for acceptable experience. Under 50ms is better. Under 20ms is ideal.
If users are remote and session hosts are on-premises, the traffic path depends on your design. Direct routing from user to session host avoids Azure entirely once the connection is brokered. Forced-tunnel designs can add latency.
Profile access is latency-sensitive. If FSLogix containers are on Azure Files and session hosts are on-premises, you need consistent, low-latency connectivity to Azure. I’ve seen 30-second logon delays because someone put profiles on a storage account in the wrong region.
Profile Management: FSLogix in a Hybrid World
FSLogix profile containers give users a consistent experience across pooled session hosts. In Microsoft AVD hybrid deployments, profile design becomes more complex because you’re choosing between cloud and on-premises storage.
Profile Storage Options
| Storage location | Best for | Watch out for |
|---|---|---|
| Azure Files Premium | Cloud-hosted hosts or low-latency ExpressRoute | Latency from on-premises locations; cost at scale |
| Azure NetApp Files | High-performance workloads; large concurrent user counts | Regional availability; higher cost; minimum size commitment |
| On-premises file servers | Microsoft AVD hybrid session hosts in the same datacenter | Capacity planning; backup; high availability |
| On-premises NAS/SAN | Existing enterprise storage; familiar operations | SMB configuration; permissions; latency to cloud components |
The rule I follow: put profiles close to session hosts. If hosts are on-premises, profiles should usually be on-premises too. If you’re running a mixed model with Azure and on-premises hosts, you might need profiles in both locations.
Identity and Permissions
FSLogix containers use SMB file shares with specific NTFS permissions. The session host computer account and user account need appropriate access.
In a hybrid identity model, confirm that AD DS domain membership, Entra hybrid join, Kerberos authentication, and file permissions all align. I’ve debugged deployments where profile access failed because the session host couldn’t authenticate to the file server using its hybrid-joined identity.
Scaling and Capacity in Microsoft AVD Hybrid
Azure-hosted AVD lets you autoscale by creating and deleting VMs. Microsoft AVD hybrid is different—you’re working with finite on-premises capacity.
How Autoscaling Works
AVD autoscaling can start and stop existing session hosts based on session demand. This reduces compute costs in Azure. On-premises, it reduces power consumption and software licensing costs if you’re using per-core licensing.
What it doesn’t do on-premises: dynamically create new VMs. You need to pre-provision capacity.
Some organizations use a hybrid scaling model: on-premises hosts for baseline capacity, Azure hosts for overflow. That requires designing host pools, application groups, and connection logic carefully.
Capacity Planning
I plan on-premises AVD capacity using:
- Peak concurrent users (95th percentile, not max-ever)
- Sessions per host based on workload profiles
- N+1 or N+2 for host failure
- Maintenance windows (patching, hardware replacement)
- Growth projection over 2-3 years
For a 500-user deployment with 8 users per host at peak, that’s 63 hosts. Add N+2 for resilience (65 hosts). Add 10% for maintenance windows (72 hosts). Add 20% for three-year growth (86 hosts).
That’s real capacity planning, not marketing math.
Security in Microsoft AVD Hybrid Deployments
Hybrid architectures expand the attack surface. You’ve got on-premises session hosts, Azure services, synchronized identities, and network paths to protect.
Core Security Controls
- Multifactor authentication: Require MFA for all AVD access. Use Conditional Access to enforce it.
- Privileged Identity Management: Time-bound, just-in-time administrative access to AVD resources and session hosts.
- Endpoint protection: Antivirus, EDR, and security monitoring on session hosts.
- Network segmentation: Separate session hosts from production servers and limit lateral movement.
- Least-privilege access: Users should not be local admins on session hosts. Separate administrative roles.
- Application control: Use AppLocker or similar for sensitive environments.
- Disk encryption: BitLocker or equivalent on session hosts where supported.
- Patching: Automated, tested, regular patching of guest OS and applications.
- Monitoring: Centralized logging and alerting for authentication, Arc agent health, host performance, and security events.
What You’re Still Responsible For
Microsoft provides the AVD service. They don’t secure the on-premises session hosts, the hypervisor, the network, or the physical datacenter. That’s on you.
Hybrid identity synchronization can become a security weakness if not properly configured. Compromising on-premises AD can lead to compromising Entra ID, and vice versa in some scenarios.
Availability and Disaster Recovery
Hybrid architecture introduces failure modes in both Azure and your datacenter.
What Can Go Wrong
- Loss of Azure connectivity (Arc health, authentication, profile access)
- Loss of the on-premises datacenter (power, cooling, network, hardware)
- Loss of domain controllers (authentication failure for domain-joined hosts)
- Loss of profile storage (logons fail or users get temporary profiles)
- Arc agent failure (host becomes unmanageable from Azure)
- Azure service disruption (rare, but it happens)
- Hypervisor or cluster failure (session-host unavailability)
- Certificate expiration (Kerberos, SSL, code signing)
- Credential expiration or sync failures (users can’t authenticate)
Resilience Strategies
A production-grade Microsoft AVD hybrid deployment should have:
- Multiple session-host pools across physical locations or clusters
- Replicated profile storage with documented failover procedures
- Backup domain controllers and DNS in multiple sites
- Documented recovery-time objectives (RTO) and recovery-point objectives (RPO)
- Regular testing of failure scenarios
- Azure-based recovery hosts for datacenter-level failure (if acceptable)
- Spare on-premises capacity for N+1 or N+2 host failure
- Monitoring with automated alerting on critical paths
I test disaster recovery by actually failing things. Not during business hours, obviously, but scheduled tests where we shut down clusters, disconnect networks, or simulate Arc agent failures. Documented procedures don’t mean anything until they’ve been executed under pressure.
Real-World Deployment Patterns
Let me describe three actual deployments (anonymized) that represent common Microsoft AVD hybrid use cases.
Pattern A: Financial Services Desktop Isolation
A bank needed to provide desktop access to contract developers working on trading systems. Regulatory requirements prohibited contractors from accessing production networks or taking data off-site.
Solution: Microsoft AVD hybrid session hosts on-premises, isolated in a separate VLAN. Azure-based authentication and conditional access. Developers connected from home using the Windows App. Sessions were recorded. No data left the datacenter.
Result: Passed audit, reduced physical access requirements, improved developer experience compared to previous remote-access tools.
Pattern B: Manufacturing with Mixed Workloads
A manufacturer had 800 office users and 200 shop-floor supervisors. Office users could move to cloud desktops. Supervisors needed low-latency access to MES systems on the factory floor.
Solution: Two host pools. Office users on Azure-hosted AVD. Supervisors on Microsoft AVD hybrid session hosts in the factory datacenter, co-located with MES servers. Same Azure management plane, same identity system, different host locations.
Result: Office users got better disaster recovery and flexible capacity. Supervisors got consistent low-latency performance. IT team managed both pools from the same portal.
Pattern C: Healthcare with Data Sovereignty
A hospital group in Europe needed to modernize desktop delivery but couldn’t move patient data to Azure due to legal interpretation of GDPR and local healthcare regulations.
Solution: Microsoft AVD hybrid on existing VMware infrastructure. Profiles and data remained on-premises. Azure provided the management plane, identity, and conditional access. Deployed in phases starting with administrative users.
Result: Modernized authentication and access control. Centralized management. Maintained regulatory compliance. Bought time to reassess full cloud migration once legal clarity improved.
Common Mistakes and How to Avoid Them
I’ve seen enough Microsoft AVD hybrid deployments go sideways that I can predict the failure modes.
Mistake 1: Underestimating Connectivity Requirements
“It’s on-premises, so we don’t need internet.” Wrong. Session hosts need reliable connectivity to Azure. Arc breaks, authentication fails, monitoring stops. Plan for outbound connectivity, DNS resolution, and firewall rules as carefully as you would for cloud-hosted resources.
Mistake 2: Ignoring Profile Latency
Putting FSLogix containers on Azure Files when session hosts are on-premises adds 50-100ms to every file operation. Users get 20-second logons and slow application startups. Keep profiles close to hosts.
Mistake 3: Mixing Management Responsibilities Without Documentation
The Azure team thinks infrastructure owns the VMs. The infrastructure team thinks Azure owns them because they’re in AVD. Nothing gets patched, monitored, or backed up properly. Document who owns what explicitly.
Mistake 4: Skipping Pilot Testing
Deploying 500 hosts based on documentation and hope. Always pilot with real users, real applications, and realistic scenarios. Find the profile issues, application compatibility problems, and authentication quirks before production rollout.
Mistake 5: Over-relying on Autoscaling
Azure AVD autoscaling can create and delete VMs. Microsoft AVD hybrid can start and stop pre-provisioned hosts. Expecting dynamic scaling without planning capacity leads to resource exhaustion during peaks.
Recommended Deployment Sequence
Based on what actually works:
- Define workload boundaries: Which users, applications, data classifications, and latency requirements drive the hybrid decision?
- Choose infrastructure: Existing hypervisor, Azure Stack HCI, physical servers, or a combination?
- Validate licensing: Confirm user access rights, Windows licensing, Azure service fees, and third-party costs with Microsoft or a specialist.
- Design identity: Entra join, hybrid join, domain join, or mixed? Document authentication flows and test them.
- Design connectivity: Routing, DNS, firewall rules, proxy configuration, profile access, and application paths. Document and test.
- Build a reference image: Hardened, minimal, automated build process. Include applications, security baselines, and monitoring agents.
- Deploy a pilot host pool: 5-10 hosts, 20-30 representative users, demanding applications. Test for two weeks minimum.
- Arc-enable test machines: Confirm extension deployment, registration, managed identity permissions, and monitoring.
- Test profiles and applications: Measure logon time, application startup, Teams performance, printing, file access, and session reliability.
- Test failure modes: Disconnect Azure, stop domain controllers, fail profile storage, break Arc connectivity. Document what happens and how to recover.
- Automate lifecycle: Infrastructure-as-code, image management, host registration, decommissioning. Reduce manual intervention.
- Roll out in waves: Add 50 users per week, monitor, adjust. Don’t rush.
What’s Coming in 2026 and Beyond
Microsoft’s direction for Microsoft AVD hybrid points toward deeper integration and broader flexibility.
Managed identities are becoming mandatory for newer host-pool configurations. This is good—it reduces credential management and improves security posture.
Session-host configuration is moving toward declarative management, reducing drift and standardizing deployment. This makes Microsoft AVD hybrid operationally closer to cloud-native AVD.
Azure Arc is expanding beyond simple connectivity. Policy enforcement, security scanning, and more granular monitoring are becoming standard.
Profile scenarios are broadening. Microsoft has been improving FSLogix support for cloud-only identities, external users, and more complex hybrid scenarios.
The trend is clear: Microsoft is separating the management plane from the compute location. You choose where desktops run. They provide consistent management.
Frequently Asked Questions
Does Microsoft AVD hybrid move the entire AVD service on-premises?
No. The AVD management and brokering service remains in Azure. Only the session-host compute runs on-premises. Users still authenticate through Microsoft Entra ID, and management happens through the Azure portal.
Can I use any hypervisor with Microsoft AVD hybrid?
Microsoft describes support for existing on-premises hypervisors and physical Windows Server devices, but “any hypervisor” isn’t unlimited. Verify supported operating systems, Arc requirements, and Microsoft’s current support matrix before deploying. Most organizations use VMware vSphere or Microsoft Hyper-V.
Do I still need an internet connection?
Yes. Session hosts need connectivity to Azure services, identity systems, and profile storage. Microsoft AVD hybrid keeps compute on-premises, but it’s not an air-gapped architecture. Arc agents, authentication, and management all require Azure connectivity.
Is Microsoft AVD hybrid cheaper than Azure-hosted AVD?
Not automatically. You reduce or eliminate Azure compute costs, but you retain or introduce costs for hardware, datacenter operations, virtualization licensing, storage, support, power, and capacity reserves. Run a total-cost-of-ownership analysis for your specific workload.
Can I mix Azure and on-premises session hosts?
Yes. Separate host pools can run in different locations. This is common for mixed workloads where some users need low-latency access to on-premises applications and others don’t. Same management plane, different compute locations.
How does disaster recovery work?
You’re responsible for on-premises resilience (N+1 capacity, clustering, backup power). For datacenter-level failure, some organizations maintain an Azure-based recovery host pool. Profile storage needs replication or backup with documented recovery procedures. Test your DR plan regularly.
Final Thoughts on Microsoft AVD Hybrid
Microsoft AVD hybrid solves real problems for organizations that can’t or won’t move all compute to Azure. It’s not a workaround or a compromise—it’s a legitimate architecture for specific use cases.
The key is understanding what you’re signing up for. You get Azure-based management and identity. You keep infrastructure ownership, capacity planning, and most operational responsibilities.
Done well, Microsoft AVD hybrid gives you modern desktop delivery with data locality and infrastructure control. Done poorly, it combines the complexity of both models without the benefits of either.
Start with a clear understanding of why hybrid is necessary. Pilot thoroughly. Document ownership boundaries. Monitor everything. And plan for the day when you might migrate those workloads to full Azure.
Leave a Reply