How to Use Hydra to Automate the Entire Azure Virtual Desktop Management Process

September 29, 2026

Hydra is a robust platform designed to automate management of Windows in the Cloud, that simplifies disjointed Azure Portal workflows down to a few clicks, and even better, repeatable automation.

This blog will cover, from a bird’s eye view, how Hydra can be used to automate the entire Azure Virtual Desktop management process, starting from initial deployments to Day 2 operations.

Onboarding: Discover Existing Environments or Build New Ones

Hydra is easily deployed from the Azure Marketplace, which simplifies the implementation process. After a wizard walks through the deployment, you’ll need to create a Service Principal within your Azure tenant(s). This provides Hydra with the visibility to manage Azure Virtual Desktop related cloud resources.

For existing implementations, there is no import process. The Service Principal will discover existing workspaces, host pools, and application groups. It will discover your compute galleries; even existing user sessions.

For greenfield environments, Hydra offers the ability to create foundational workspaces, host pools, and application groups, just as you would via the Azure Portal, PowerShell, or IaC.

You can even perform assignment tasks in Hydra, assigning end-users to the required desktops or RemoteApp groups

Configuring Host Pools: Set Once, Inherit Everywhere

Now that Hydra’s built (or discovered) your host pools, it’s time to configure them. Rather than defining session host configuration in Terraform or PowerShell scripts, you can set them once in Hydra’s intuitive New Session Host Rollout page. Any machines deployed in this host pool, manually or via autoscaling scale-out actions,will inherit these settings including naming schema, networking, and the underlying image.

Hydra simplifies directory joins, supporting cloud-native and Hybrid directory setups. Enrolling in Intune is a single checkbox, just like it is to install the Hydra Agent. The screenshot below shows only a subset of the available configuration options.

Cutting AVD Costs with Autoscaling and Auto-Shutdown

Hydras offers several levers to pull for cost optimization. Most importantly, autoscaling and auto-shutdown. Hydra’s auto-scaling options vary based on the pool type. Before describing them, it’s important to know that Hydra has two types of machines.

Permanent vs. Temporary Hosts

Permanent hosts are those created manually by an admin,they were created outside Hydra in an existing environment, or they were created in Hydra, just not by the autoscaling engine.

Temporary hosts are created through Hydra’s autoscaling engine, based on configured settings. These are often treated as burstable capacity, only created as needed, and deleted when no longer necessary.  

Permanent hosts are always power-managed which means if autoscaling rules dictate more capacity is needed, Hydra will always seek to power on permanent machines before creating any temporary ones. If there are no machines to support additional demand, Hydra will then create temporary hosts which are deleted during scale down.

Dynamic Autoscaling for Pooled Host Pools

Pooled host pools are designed to offer non-persistent, dynamic desktop allocation, often paired with FSLogix for user profile storage. As such, many organizations decide to utilize dynamic autoscaling.

In addition to default settings (not shown below), Hydra offers the ability to create granular schedules that align to your usage patterns. Based on the period, admins can define the number of minimum hosts that are required, and the number of buffer sessions that capacity needs to support.

Power Management for Personal Host Pools

As personal host pools are typically treated as persistent machines, Hydra does not perform the same dynamic autoscaling. Instead, it uses a power management approach.

Hydra (or another management layer) can set Session Timeouts that determine how long to wait before disconnecting an idle session. Based on the configurable schedules shown below, Admins can determine how long to wait before deallocating a disconnected session.

For example,  if a more aggressive shutdown policy is required over the weekend, while for user-experience reasons, a longer window is used during the week.

Users can continue using Power-on-Connect to start their machines through their Windows App, but IT has the added ability to tighten costs.

Disk Swapping: Stop Paying Premium for Powered-Off VMs

As an additional cost saving measure, Hydra can automatically swap disk types. Most organizations use either Premium or Standard SSD, which is more expensive than the Standard HDD SKU. But, when VMs are not in use, there’s no need to pay for Premium. With Disk Swapping enabled, whenever Hydra powers off a machine, it will swap it to HDD,and will swap it back to the defined disk SKU before it powers back on.

Creating Images Without Touching the Golden Master

Hydra enables a streamlined approach to image management by allowing image creation from any machine in the connected tenants, including existing session hosts that are already joined to a pool. This also supports using the latest Marketplace images, for example Windows 11 Multi-Session.

During image creation, Hydra creates a temporary VM behind the scenes. This temporary VM is an exact copy of the golden master and is where sysprep and generalization occurs.

This means that the Golden Master is left untouched, and you can avoid the numerous snapshots and redeployments that would be required otherwise. It’s purpose-built to feel familiar for veteran VDI admins, with a process very similar to the one used in MCS or Instant Clone deployments.

Hydra can also run PowerShell scripts on the Golden Master prior to cloning, which streamlines patching, app installs, policy customization and more. While not every application offers silent installs, this is another way Hydra can save your team time by creating a defined automated process.

Rolling Out New Images: Replace or Recreate

Once new images are built, Hydra offers two ways to streamline rollouts:

• Using the Replace option will roll out a new session host, with the updated host pool settings (i.e., the new image). Once Hydra confirms that the new host is healthy, it will delete the original host targeted for replacement. This is the safer option of the two, since availability is confirmed before deletion.
• Using the Recreate option will immediately delete and recreate the session host(s) with the same name. This may be desired in environments where creating hosts with new names is limited. It’s also handy for quickly pre-staging some hosts with a new image for production pilot purposes, such as OS updates.

For more information on this, please visit our documentation.

User Sessions: Observability for the Help Desk

Another important area is observability, especially after rolling out a new image. Hydra’s User Sessions page catalogs every session across Desktops and RemoteApps, in every tenant that Hydra is connected to.

Usually leveraged by the Help Desk, Hydra can streamline forced logoffs or disconnections, saving a trip to the Azure Portal or your jumpbox. In the event of a corrupted FSLogix profile, containers can be deleted from the file share, too.

The Hydra Agent provides valuable telemetry from the host and client, while also providing a real-time process list that can terminate processes.

Beyond the Basics: Azure Local, FSLogix, and Script Schedules

While we’ve covered the most common requirements of an Azure Virtual Desktop management platform, there are numerous other capabilities. Here are a few:

• Managing Azure Local and AVD Hybrid deployments
• FSLogix File Share autoscaling & file handle cleanup
• Script schedules, for patching or automated image orchestration

If you’re interested in learning more or want to see the product live, schedule a demo here or check out a Trial in the Azure Marketplace!