Tag: AVD Hybrid

  • Azure Virtual Desktop Hybrid Is GA. Microsoft Built Half of It on Purpose.

    Azure Virtual Desktop Hybrid Is GA. Microsoft Built Half of It on Purpose.

    I’ve had the same conversation three times this year, with three different customers who all have the same problem. They’re on Citrix, or Horizon, running on hardware they already own (VMware, Nutanix, or Hyper-V), and they don’t want to move to Azure Local. Azure Local means buying a specific validated hardware list from Dell or HPE and running Microsoft’s own hyperconverged stack on top of it. It’s a real product, but it’s a big, separate purchase, and for a lot of these customers, it’s the wrong answer to “get me off Citrix.”

    Azure Virtual Desktop Hybrid went generally available on 1 September 2026, and it’s built for exactly that gap. If you’re running AVD or thinking about running it, and you’ve got hardware you’re not ready to walk away from, this is worth fifteen minutes of your attention. Here’s what it actually is, why Microsoft only built it out to a certain point, and what that means for anyone deploying it without a partner behind them.

    What AVD Hybrid actually is

    Strip away the branding and it’s simple: the AVD control plane (brokering, the web/gateway service, Windows App connections) stays in Azure. The session hosts don’t. You run them on your own hardware, on whichever hypervisor you already have, and register them with Azure using an Azure Arc-enabled agent. Microsoft’s own description is blunt about it: you can run session hosts “on your preferred on-premises hypervisor that supports Windows virtual machines.” No certified hardware list, no proprietary stack to buy. You put the Arc agent on a VM, install the AVD extension, and it shows up in your host pool next to your cloud-hosted hosts.

    That’s the whole pitch, and it’s a genuinely different shape to Azure Local. Azure Local extends Azure’s control plane and management stack into your datacenter on hardware Microsoft has validated. AVD Hybrid does something narrower: it lets your control plane stay entirely in Azure while the compute stays wherever you already have it.

    Users connect the same way they do to any AVD session host: through Windows App, over the same protocol, with the same UI. That consistency is one of the things Microsoft calls out directly, and it’s not a small thing: your helpdesk doesn’t need a second runbook for “if it’s a hybrid session.”

    Why you’d actually use it

    Three scenarios have come up with real customers:

    You’ve got Citrix or Horizon on hardware you’re not ready to sunset. Modernising the broker and connection layer without a forklift migration to cloud compute is a genuinely attractive middle step, especially if that hardware still has years of depreciation left on it.

    Latency-sensitive or data-gravity workloads. CAD, medical imaging, anything where the session traffic needs to stay close to a local dataset. RDP ShortPath still gets you the local-network transport benefit, just without a public cloud hop for the compute.

    Regulated or sovereignty-constrained environments. Some organisations genuinely can’t put certain workloads in public cloud yet, for real regulatory reasons rather than habit. AVD Hybrid lets them get Azure’s management and identity story without moving the data.

    What it doesn’t solve is “we don’t want to touch the cloud at all.” The control plane is Azure, full stop, and your session hosts still need outbound connectivity back to Azure for brokering and management. If the objection is philosophical rather than data-residency-driven, this isn’t the escape hatch.

    The pros and cons, honestly

    Pros:

    • Uses hardware you already own, with no forced capex into a validated Azure Local hardware list
    • Arc-based registration is identity-driven and outbound-only over TCP 443; no inbound firewall holes, no site-to-site VPN required
    • One consistent user experience (Windows App) whether the host is in Azure, on-prem via Hybrid, or a Windows 365 Cloud PC
    • A genuine gradual migration path: move workloads to Azure compute later, on your own schedule, without changing how users connect

    Cons:

    • Windows 11 and Windows 10 Enterprise multi-session isn’t supported on Hybrid. Microsoft’s own licensing table for AVD Hybrid marks it “Not Supported,” full stop. If you want multiple users sharing session hosts on-prem, you’re on Windows Server with an RDS Client Access Licence, which is the same licensing weight Citrix and Horizon customers already carry today. It’s not a cost reduction on that front.
    • You still need reliable connectivity back to Azure. This isn’t an offline mode.
    • And the big one: Microsoft’s own documentation is explicit that AVD Hybrid “doesn’t provision or manage virtual machine state,” which means four things you’d normally take for granted on Azure-hosted AVD simply aren’t there.

    The gap Microsoft left, and why it’s deliberate

    That last point is worth sitting with, because it’s not a bug, it’s the design. Microsoft’s Learn documentation lists exactly what’s missing on a Hybrid host pool: power management, autoscale, Start VM on Connect, and Session Host Configuration. Their own words: “Organizations are responsible for deploying and managing their on-premises session hosts using hypervisor tools, scripts, partner solutions, or other tools.”

    Read that sentence again. Microsoft built the control plane, the Arc registration path, and the identity model, then explicitly handed off VM lifecycle management to whoever owns the hypervisor underneath: you, your scripts, or a partner. That’s not an oversight; it’s the same logic behind Azure Arc generally. Microsoft owns the thin registration and identity layer that has to be consistent everywhere, and leaves the deep, hypervisor-specific automation to the people who already know that hypervisor. Building native Nutanix AHV, VMware, and Hyper-V automation into the AVD product itself would mean maintaining three separate hypervisor integrations inside a first-party Microsoft product. That’s not where their engineering effort is best spent, and building AVD Hybrid this way is what let it ship across any hypervisor at GA rather than one.

    The practical result: without a partner layer on top, running AVD Hybrid at any real scale means someone on your team is scripting VM provisioning, image updates, and capacity management by hand, against whichever hypervisor API you’re on. That’s exactly the operational overhead most of these customers were trying to get away from when they started looking at moving off Citrix in the first place.

    What Nerdio Manager is doing about it

    This is where I have a direct line of sight, because Nerdio was a launch partner on AVD Hybrid alongside Microsoft. Nerdio Manager for Enterprise’s Hybrid support launched with Nutanix AHV as the first supported hypervisor, timed to Microsoft’s GA. What it adds on top of the bare Arc registration: image management (create, update, and deploy gold images for Hybrid session hosts the same way you would for Azure-hosted ones), automation for repeatable provisioning workflows, monitoring across your whole Windows cloud estate (Azure, Azure Local, and now Hybrid) from one console, and cost/utilisation reporting that spans all three.

    Nerdio hasn’t published a public timeline, but VMware and Hyper-V support are the expected next hypervisors after Nutanix, and I’d expect the same direction Nerdio already applies to Azure and Azure Local host pools: bring the automation Microsoft deliberately left out (autoscale, power management, lifecycle orchestration) up to the same standard, regardless of which hypervisor sits underneath. That’s the layer that turns “Microsoft gave you a registration path” into “you can actually run this without a team of scripters.”

    The takeaway

    AVD Hybrid GA is a genuinely useful option if you’ve got on-prem hardware you’re not ready to retire and a real reason (latency, sovereignty, depreciation schedule) to keep compute local while modernising everything around it. Just go in knowing Microsoft built the identity and control-plane layer, and left the VM lifecycle layer as someone else’s job. Check whether that someone is going to be you, with scripts, or a partner, before you commit a migration plan to it.

    If you’re running Citrix or Horizon on hardware you’re not ready to sunset, what’s actually stopping you from testing this? Genuinely curious whether it’s the licensing gap on multi-session, or something else entirely.