Build AVD host pool configs with session host templates, scaling plans, application groups, domain join, and RDP properties.
Build AVD host pool configs with session host templates, scaling plans, application groups, domain join, and custom RDP properties.
Required Fields
hostPoolNameresourceGrouphostPoolTypeloadBalancerTypemaxSessionLimitsessionHosts.vmTemplate.vmSizesessionHosts.vmTemplate.numberOfVMsOutput will appear here...The builder validates that hostPoolName, resourceGroup, hostPoolType, loadBalancerType, maxSessionLimit, sessionHosts.vmTemplate.vmSize, and sessionHosts.vmTemplate.numberOfVMs all resolve before accepting the JSON as a valid combined host pool, session host, application group, and scaling plan definition; it can't verify the referenced subnet actually has capacity for the requested numberOfVMs or that the scalingPlan's schedule times don't conflict with agentUpdate's maintenance windows, those are only surfaced at actual deployment and runtime.
Build an Azure Virtual Desktop host pool combining hostPoolType (Pooled vs Personal), loadBalancerType (BreadthFirst spreads new sessions across the most session hosts, DepthFirst fills one host before moving to the next), session host VM templates, and a scalingPlan with time-based ramp-up/peak/ramp-down/off-peak schedules each using a potentially different load-balancing algorithm. The scalingPlan's per-period algorithm choice is deliberate: BreadthFirst during ramp-up spreads the morning login surge evenly to avoid overloading any single host as users sign in, while DepthFirst during peak and off-peak consolidates sessions onto fewer hosts, letting the scaling plan actually deallocate the now-empty hosts to save cost, a mismatch (like DepthFirst during ramp-up) works against what each period is trying to achieve.
Match load-balancing algorithm to the schedule period's actual goal, BreadthFirst for ramp-up (spread the login surge), DepthFirst for peak and off-peak (consolidate for cost), a mismatched algorithm per period works against the scaling plan's own cost and performance intent.
rampDownMinimumHostsPct set too high defeats much of the cost benefit of a scaling plan, verify it's actually low enough to let genuinely idle capacity deallocate overnight, not just nominally 'scaled down' while still running most hosts.
customRdpProperties settings (like redirectprinters or drivestoredirect) have real security and bandwidth implications, review each enabled redirection setting deliberately rather than copying a broad default RDP property string from an unrelated environment.
BreadthFirst distributes new sessions evenly across all available session hosts (spreading load thin), while DepthFirst fills up one host to its maxSessionLimit before routing new sessions to the next host. BreadthFirst is generally better for balanced resource usage per host; DepthFirst is better for cost optimization since it lets you actually power off and deallocate hosts that end up with zero sessions once consolidation is complete.
Yes, for VM compute costs specifically, a session host that's stopped and deallocated (not just idle) stops accruing compute charges, though the OS disk continues to incur storage cost while deallocated. This is why DepthFirst during rampDown/offPeak matters, it consolidates sessions onto fewer hosts so the rest can actually be deallocated, rather than leaving many lightly-loaded hosts running and billing.
It's primarily designed for and most commonly used with Personal host pools, where a specific user is assigned to a specific, potentially-powered-off VM. For Pooled host pools, the scaling plan's own schedule-based logic typically handles host availability instead, since sessions aren't tied to one specific host the way Personal assignments are.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.