Microsoft has announced that enhanced host pool management for Azure Virtual Desktop is now generally available. In short: you can now create a host pool with a session host configuration, and the platform takes over the work of creating and updating session hosts for you. I set it up in my own tenant, and in this post I will walk through the setup step by step, including two gotchas the wizard will not warn you about.

What actually changes

With a standard host pool, you deploy session hosts yourself and keep them updated yourself. A host pool with a session host configuration flips that model:

• Session host configuration: one definition of what every session host should look like: image, VM size, OS disk, network, domain join and the local admin credentials.
• Session host management policy: how changes roll out: batch size, logoff behavior and the time zone used for scheduling.
• Session host update: when you change the image or configuration, Azure Virtual Desktop replaces the session hosts for you, batch by batch.
• Autoscale can create and delete session hosts based on demand, not just start and stop them.

There is also no registration token to manage anymore: the service handles agent registration itself.

Before you start

• Only pooled host pools support session host configuration.
• You choose the management approach when the host pool is created. An existing host pool cannot be converted, and you cannot switch back.
• The local administrator credentials for the session hosts must come from Azure Key Vault: the wizard only offers Key Vault references, not inline username and password fields.

Step 1: Prepare the Key Vault

Create a Key Vault with two secrets, one for the VM admin username and one for the password. Do this before you open the host pool wizard: the wizard caches the vault list when it loads.

If your vault uses the access policy permission model, you must also grant the Azure Virtual Desktop service access to read secrets:

az keyvault set-policy -n kv-tm-avd-prod-001 \
  --object-id <AVD-provider-object-id> \
  --secret-permissions get list

Step 2: Basics

In the Azure portal, go to Azure Virtual Desktop, select Host pools and select Create.

Pick Pooled, and set Create Session Host Configuration to Yes. This is the decision that enables the whole feature set. Set your load balancing algorithm and max session limit as usual.

Step 3: Session hosts

You can set the number of session hosts to 0 and still define the full configuration. That is exactly what makes this approach nice to prepare in advance, since autoscale or a later update can create the hosts. I used the Windows 11 Enterprise multi-session 25H2 image with Microsoft 365 Apps, Trusted launch, a name prefix, my virtual network and Microsoft Entra ID join.

At the bottom of the tab, the virtual machine administrator account is referenced from Key Vault: two dropdowns for the vault and secret holding the username, and two for the password.

Step 4: Management

The wizard assigns a system-assigned managed identity to the host pool and shows exactly which roles it will get, including Desktop Virtualization Virtual Machine Contributor on the session host resource group and Key Vault Secrets User on the credential vault. You need Owner or User Access Administrator rights for these role assignments to succeed.

Step 5: Review and create

Validation checks the configuration, and the deployment creates the host pool, the application group and the session host configuration.

On the host pool overview you can now see Uses Session Host Configuration: Yes, and the toolbar has new Start, Restart and Stop commands that operate on the whole pool.

Two gotchas from my deployment

1. Key Vault access: portal validation passed, but the deployment failed with UnableToAccessKeyVaultSecret. The role assignments the wizard creates are Azure RBAC, so if your vault runs the access policy permission model, the Azure Virtual Desktop provider has no access. Grant it an access policy as shown in step 1 and redeploy.
2. VM size restrictions: my subscription had no access to Standard_D2as_v5 in West Europe, which also only surfaced at deployment time. Check availability first with: az vm list-skus -l westeurope –query "[?name=='Standard_D2as_v6'].restrictions"

Read the GA announcement and the host pool management approaches documentation for the full details, including how session host update handles drain, logoff and rollback.