Hydra Proxy Deep Dive: Bringing Azure Local and AVD Hybrid Under One Control Plane
September 10, 2026
If you manage Azure Virtual Desktop, your environment may no longer be 100% cloud-native. Data residency requirements, latency-sensitive workloads, and existing infrastructure investments are driving more EUC (end-user computing) teams to run session hosts on-premises, whether on Azure Local, a Hyper-V cluster, or VMware vSphere.
At the same time, users still expect the familiar AVD control plane and Microsoft Entra ID experience.
That is the gap the Hydra Proxy is designed to close.
Hydra normally runs as an Azure App Service and communicates with Azure Resource Manager. The Hydra Proxy extends that reach into your private data center, allowing Hydra to orchestrate hypervisors that have no direct connectivity (ExpressRoute or VPN Gateway) to Azure.
In this article, we’ll look at what the Hydra Proxy does, how it is architected, and how to configure it for the two scenarios it currently supports:
- Azure Local, which is generally available
- AVD Hybrid on Hyper-V, which is generally available
- AVD Hybrid on vSphere, available in private preview as of Hydra 2.8.0
Why Use a Proxy? The Outbound Connection Model
Hydra provides a single control plane for provisioning, imaging, autoscaling, and session management across Azure Virtual Desktop. In a typical Azure deployment, those operations are performed through Azure APIs.
The challenge arises when the underlying infrastructure sits inside a private network.
Hyper-V and vSphere environments, as well as the nodes behind an Azure Local deployment, typically have no inbound internet connectivity. That is intentional and often required from a security perspective.
Rather than requiring customers to open firewall ports into their data center, Hydra reverses the connection model.
The Hydra Proxy is installed on a Windows Server inside the private network. It establishes an outbound WebSocket/HTTPS connection to the Hydra instance:
https://<your-hydra-instance>.azurewebsites.net
Once the connection is established, Hydra can send instructions through that channel, and the proxy executes the required actions locally. No inbound firewall rule is required.
Technically, the Hydra Proxy is the Hydra Agent running in a specific mode. If you’re already familiar with Hydra Agents on session hosts, the overall model should feel familiar.
What the Hydra Proxy Is Responsible For
The Hydra Proxy performs different tasks depending on the deployment scenario.
For AVD Hybrid on Hyper-V or vSphere, the proxy can:
- Start, stop, and restart VMs
- Delete VMs and their disks
- Create new VMs and session hosts, including:
- Azure Connected Machine Agent (ARC) installation
- AVD Agent installation
- Domain join for both Active Directory and Microsoft Entra ID
- Azure Monitoring Agent installation, when selected
- Image existing Golden Master VMs from your local hypervisor
For imaging, the Golden Master must already have the Azure Connected Machine Agent installed.
For Azure Local, the proxy primarily enables local image creation, which Azure does not support natively. Day-to-day host management, including autoscaling, session handling, and host replacement, works automatically once a custom location is available and does not require additional proxy-specific configuration.
One architectural detail is worth keeping in mind: a single Hydra Proxy installation can support multiple custom locations and nodes, and multiple proxy instances can be deployed for redundancy.
The important design rule is that clusters and standalone nodes should not be mixed within the same Hybrid Location.
Scenario 1: AVD on Azure Local (GA)
If your session hosts already run on Azure Local, with Azure Stack HCI 22H3 or later and a resource bridge configured, there is relatively little additional configuration required.
Hydra treats a custom location much like an Azure region. It automatically discovers the available networks and presents them as rollout targets.
From Hydra’s perspective, there is very little difference between an Azure Cloud host and an Azure Local host. In theory, a single host pool can even contain both.
Where the Proxy Is Required: Imaging
The primary role of the Hydra Proxy in an Azure Local deployment is imaging.
Hydra’s imaging model clones the Golden Master rather than modifying the source VM directly. This keeps the original Golden Master available for future updates and image creation.
For Azure Local, however, the source image must be an Azure Cloud VM. Azure Local VMs cannot currently be used as imaging sources.
The process is:
- Build your Golden Master in Azure Cloud using a Windows 11 multi-session marketplace image.
- Patch and configure the VM.
- Open Image Builder and select Create an Image.
- Choose the target resource group.
- Select the Azure Local custom location.
The image is then transferred to the custom location. From that point forward, Hydra filters the image by location, helping prevent accidental deployment across regions.
Current Azure Local Limitations
There are several limitations to consider when designing an Azure Local deployment:
- Power-On-Connect is not available for Azure Local hosts.
- Disk type changes are not supported.
- Golden images cannot be sourced directly from an Azure Local host.
Scenario 2: AVD Hybrid on Hyper-V (GA) and vSphere (Private Preview)
AVD Hybrid on Hyper-V and vSphere is the newer capability, introduced with Hydra 2.8.0.
This scenario requires more configuration than Azure Local because the underlying hypervisors have no native Azure integration. The Hydra Proxy therefore handles the interaction between Hydra and the local infrastructure, including VM operations, domain joining, and Azure Arc onboarding.
Preparing the Hypervisor Layer
Before configuring Hydra, the Hyper-V or vSphere environment must be prepared for proxy-based management.
Hyper-V Requirements
Hyper-V nodes, whether clustered or standalone, require the following.
Consistent network switches
Every node must have at least one network switch with the same name.
VM storage
One or more local folders must be available for storing VMs.
The following identities require Full Control permissions:
- SYSTEM
- SERVICE
- Administrators
Examples include:
- C:\LocalStorage for standalone nodes
- C:\ClusterStorage\UserStorage_1 for cluster storage
Image gallery storage
You also need a location for storing sysprepped VHDX files.
For standalone servers, this can be a local folder. For multi-node clusters, use a cluster share or file server share.
If you use a network share:
- Grant Everyone Full Control at the share level so that NTFS permissions remain responsible for access control.
- Ensure every node can access the share using the appropriate security context.
vSphere Requirements
For vSphere, create a service account with the permissions normally required for a linked-clone or instant-clone deployment.
Login VSI points to Omnissa’s vCenter permissions documentation as a useful baseline when designing a least-privilege permission model.
Installing the Proxy Binaries
The Hydra Proxy installation process is similar for Azure Local and AVD Hybrid. However, AVD Hybrid support requires Hydra Proxy binaries version 4.4.0 or later, which are shipped alongside Hydra 2.8.0.
The general process is:
- Enable Hydra Proxy (Support Preview) in Global Settings.
- Enable it again at the Tenant level.
- Download the proxy package.
- Copy the installation command from the Tenant menu.
- Create a folder, for example:
C:\Program Files\Login VSI\Hydra Proxy
- Extract the archive into that folder.
- Create a HydraProxy.json file alongside the proxy binaries.
- Configure your custom locations in that file.
Before installing the proxy as a scheduled task, run it interactively without the -i flag.
This allows you to verify that the proxy connects successfully and can read VMs from the configured nodes before moving to the production-style scheduled task configuration.
Configuring HydraProxy.json
The HydraProxy.json file defines one or more custom locations, which Hydra exposes as Hybrid Locations for rollout and imaging.
The following example includes both Hyper-V and vSphere configurations:
{
“CustomLocations”: [
{
“LocationType”: “HyperV”,
“LocationId”: “almere-datacenter”,
“LocationName”: “Almere”,
“ClusterName”: “HYPERV-ALMERE.almere.nl”,
“ClusterNodes”: [
“HYPERV-ALMERE-0.almere.nl”,
“HYPERV-ALMERE-1.almere.nl”,
“HYPERV-ALMERE-2.almere.nl”
],
“ClusterShares”: [
“C:\\LocalStorage”,
“D:\\ClusterStorage\\UserStorage_2”
],
“Networks”: [
{ “Name”: “External-vSwitch” },
{ “Name”: “Internal High Security” }
],
“ImageGalleries”: [
{
“Name”: “Default”,
“GalleryLibraryPath”: “C:\\LocalStorage\\Images\\Repository.json”
},
{
“Name”: “AdvancedRemote”,
“GalleryLibraryPath”: “C:\\LocalStorage\\Images\\Repository-Secure.json”
},
{
“Name”: “On-Share”,
“GalleryLibraryPath”: “\\\\HYPERV-ALMERE-0\\Images-FileShare\\Repository-Share.json”
}
]
},
{
“LocationType”: “vSphere”,
“LocationId”: “almere-vsphere-01”,
“LocationName”: “Almere vSphere”,
“ClusterName”: “almlabvc01.lvsilabs.com”,
“ApiVersion”: “8.0.3.0”,
“Networks”: [
{ “Name”: “VM Network” }
],
“ClusterShares”: [
“datastore1”,
“datastore2”
],
“ClusterNodes”: [
“AVD-Hosts”,
“Templates for AVD”,
“Test”
],
“ImageGalleries”: [
{ “Name”: “Default” }
]
}
]
}
Understanding the Configuration Fields
LocationType
LocationType tells the proxy which orchestration path to use.
The supported values include:
- HyperV
- AzureLocal, used in Azure Local scenarios
- vSphere
ClusterName
For Hyper-V, ClusterName identifies the failover cluster that represents the Hybrid Location.
Use the cluster’s FQDN when working with a cluster. Leave the value empty for standalone servers.
For vSphere, this field contains the FQDN of the vCenter management server.
ImageGalleries.GalleryLibraryPath
For Hyper-V, GalleryLibraryPath points to the JSON repository used by the image gallery.
The file must not already exist. Hydra creates it automatically. Alternatively, you can create the file yourself and initialize it with:
[]
vSphere image galleries
The vSphere configuration is simpler.
ImageGalleries currently supports a single “Default” entry, which represents the vCenter folder used for imaging resources.
ClusterShares
The meaning of ClusterShares depends on the platform:
- Hyper-V: local or cluster folder paths
- vSphere: datastore names
Handling Credentials
By default, the Hydra Proxy runs under the context in which it is launched.
This is generally sufficient for Hyper-V. For vSphere, however, explicit credentials are mandatory because vSphere authentication requires them.
Credentials are configured per Hybrid Location using HydraAgent.exe.
The tool distinguishes between credentials stored for your current interactive session and credentials used by the scheduled task that typically runs the proxy.
:: Same context as the person configuring it
HydraAgent.exe ProxyAuthenticationCurrent set “Germany-NRW-DC01” “.\HyperVAdmin” “SuperSecretPassword”
HydraAgent.exe ProxyAuthenticationCurrent list
HydraAgent.exe ProxyAuthenticationCurrent delete “Germany-NRW-DC01”
:: For the running scheduled task, as a local administrator
HydraAgent.exe ProxyAuthentication set “Germany-NRW-DC01” “.\HyperVAdmin” “SuperSecretPassword”
HydraAgent.exe ProxyAuthentication list
HydraAgent.exe ProxyAuthentication delete “Germany-NRW-DC01”
The credentials are stored in Windows Credential Manager.
For troubleshooting, you can also view the live log stream from a running proxy:
HydraAgent.exe ShowLogs
This is particularly useful when validating a new Hybrid Location.
Wiring Up the AVD Host Pool
Once the proxy is connected and your custom locations appear in Hydra, several Azure-side configuration steps are required for AVD Hybrid.
- Create the host pool with the validation environment option enabled.
- Ensure the Hydra service principal has the required role, such as Login VSI’s custom Hydra – Resource Access Role, or an equivalent role.
- Enable a system-assigned managed identity on the host pool in the Azure Portal.
Hydra is expected to automate this step in a future release.
- Create a dedicated service principal for Azure Arc onboarding, for example:
ARC.Onboarding
Create a client secret and record the application ID.
- Create or reuse a resource group for Azure Arc objects.
- Grant the ARC.Onboarding service principal the Azure Connected Machine Onboarding role on that resource group.
- Add the host pool’s managed identity as a Reader on the same resource group.
This resource group becomes the landing zone where the Azure Arc objects for hybrid session hosts are registered.
Building the Golden Master
Hybrid session hosts still start from a captured image, so the process begins with a Golden Master.
The workflow is similar to a standard Hydra imaging process, with several hybrid-specific requirements.
- Create a VM on the Hyper-V node or vSphere cluster.
- Before continuing, rename the computer hostname so that it matches the VM name.
This is an important requirement and is easy to overlook.
- Patch the VM and install your applications as usual.
- For vSphere only: apply a generic KMS client activation key:
- slmgr /ipk <generic-product-key>
This is required because there is no Azure-native licensing path in this scenario.
- Install the Azure Connected Machine Agent (ARC).
- Onboard the VM into the same resource group configured for Azure Arc objects.
Once the VM is registered, it appears under Azure Arc → Machines and is ready to be captured as an image.
Capturing Images and Rolling Out Hosts
The imaging workflow will feel familiar if you have already used Hydra’s Image Builder.
- Open Image Builder.
- Select your tenant and Hybrid Location.
- Choose the Golden Master from the VM list.
- Select the Target Image Gallery that matches a gallery name configured in HydraProxy.json.
- Click Create Image.
The proxy captures the image, stores it in the configured location, and registers it in the gallery’s JSON repository.
vSphere Snapshot Images
vSphere includes an additional option: snapshot images.
When you capture a snapshot image, Hydra deploys the resulting session hosts as linked clones rather than full copies.
Configuring Session Host Rollout
Configure New Session Host Rollout on the host pool as you normally would.
To enable the hybrid-specific configuration fields, select a network switch that belongs to a Hybrid Location.
The available options differ slightly between Hyper-V and vSphere:
| Field | Hyper-V | vSphere |
| Image | Available images for the location | Images and deployable snapshots using linked clones |
| Storage target | Cluster Storage Path or Auto | Data Store or Auto |
| Placement | Node or Auto, using least-loaded placement | Folder configured in the proxy |
| ARC join | Service principal and secret | Service principal and secret |
There are also two operational details worth considering.
First, Login VSI currently recommends against using incremental disks for Hyper-V rollouts because of performance considerations.
Second, the local administrator username is not yet configurable during rollout. The username is inherited from the Golden Master.
The password you configure, however, is applied to every local administrator account during rollout.
Once the configuration is saved, the host pool behaves like any other AVD host pool. Start, stop, restart, and rollout actions work through the same Hydra experience used for native Azure VMs.
Known Limitations to Plan Around in Hydra 2.8.0
Both feature sets continue to evolve, but as of Hydra 2.8.0, the following limitations should be considered during the design phase:
- AVD Hybrid currently works only with Azure Global. Government cloud tenants are not yet supported.
- The configured local administrator username for a rollout is ignored and inherited from the Golden Master.
- All local administrator accounts on newly deployed hosts are reset to the configured administrator password.
- Azure Local imaging can use only Azure Cloud VMs as image sources. Existing Azure Local VMs cannot be used as Golden Masters.
- Power-On-Connect is not available for Azure Local host pools.
The Bigger Picture: One Control Plane for Cloud and On-Premises AVD
The Hydra Proxy removes much of the operational divide between cloud-hosted and on-premises AVD infrastructure.
Whether session hosts run on Azure Local, a Hyper-V cluster, or vSphere, administrators can continue to use Hydra for many of the same day-to-day operations, including imaging, autoscaling, session management, and scripting.
The proxy provides the connection between Hydra and private infrastructure without requiring inbound connectivity to the data center.
If you’re evaluating Hydra for a hybrid or sovereign-cloud AVD design, start small.
Begin with a single node or a lab cluster. Validate the proxy connection, test the imaging workflow end to end, and confirm rollout behavior before expanding into a production deployment.
Both Azure Local and AVD Hybrid capabilities continue to evolve from release to release, so review the Hydra Update Center before each deployment.
Hydra Proxy support for AVD Hybrid is currently in private preview. If you’re testing the capability, Login VSI is actively seeking feedback on both the feature set and the documentation. Any issues or gaps you encounter are worth reporting.
Hydra
