Quick guide to enabling Start VM on Connect for Azure Virtual Desktop using the current built-in RBAC role and host-pool setting.
Azure Virtual Desktop has moved on since the first version of this post. The original article relied on a custom-role JSON file hosted in GitHub. Current Microsoft guidance is simpler: use the built-in Desktop Virtualization Power On Contributor role at the subscription scope, then enable the setting on the host pool.
Beginning: what Start VM on Connect actually does
Start VM on Connect reduces compute cost by allowing Azure Virtual Desktop to power on session hosts only when a user needs them. The trade-off is straightforward: the first connection to a powered-off host takes longer because Azure has to start the VM before the session can complete.
That makes the feature a good fit when:
- Personal desktops are often idle outside working hours
- Pooled hosts are intentionally deallocated to save cost
- You are comfortable with a short wait during cold starts
Middle: the current configuration path
1. Assign the built-in role at subscription scope
Go to the subscription that contains the host pool and session hosts, then open Access control (IAM).
Assign the built-in role:
Desktop Virtualization Power On Contributor
Assign it to the Azure Virtual Desktop service principal. The important point is the scope. This role should be assigned at the subscription level for the subscriptions that contain the session hosts. Assigning it only at resource-group or VM level can lead to inconsistent behaviour.
2. Enable the host-pool setting
Open Azure Virtual Desktop in the Azure portal, select the target Host pool, then open Properties and set:
Start VM on connect = Yes
Save the change and test with a user assignment that can launch a desktop or RemoteApp from that host pool.
3. PowerShell option
If you prefer PowerShell, enabling the host-pool setting is the clean part:
Update-AzWvdHostPool `
-ResourceGroupName '<resource-group>' `
-Name '<host-pool>' `
-StartVMOnConnect:$true
4. Optional legacy JSON reference
If you still want a JSON definition for review, change control, or documentation, I created a local equivalent here:
That file is a reference copy, not the preferred operational path. Use the built-in role unless you have a specific reason to maintain a custom definition.
End: what to validate after enabling it
Once enabled, validate three things:
- The Azure Virtual Desktop service principal has the correct role on the correct subscription.
- The host pool property is enabled.
- A test user can connect and trigger a powered-off session host to start.
If the VM does not start, check Azure Virtual Desktop diagnostics and confirm the role assignment scope first. In most failed deployments, the issue is not the host-pool toggle. It is the RBAC assignment.
Closing thoughts
The early custom-role approach worked, but it is no longer the cleanest route. This article now reflects the current Microsoft pattern while still preserving a local JSON file so the dead external script link is gone and the post remains self-contained.
