Session Host Management Options in Native AVD
This post explores best practices for managing Azure Virtual Desktop implementations without third-party control planes.
Host pool management
Session host configuration is essentially a blueprint that configures session hosts as they are created, including:
- Session host configuration: blueprint for session host VMs
- Session host management policy: blueprint for lifecycle management including creation and updating host VMs
- Session host update: updates host VMs when the session host configuration is updated to ensure consistent behavior across the pool
- Autoscale: dynamically scales the number of host VMs in a host pool based on demand
Session host configuration
It includes properties like:
- VM name prefix, VM resource group, Avail. Zones
- VM image, VM size, OS Disk information
- VM location, VM tags, VM network settings
These settings and more are configured once and applied to those hosts created in the future. Changing the settings above will change the configuration of hosts that are deployed via Autoscaling.
If you modify the configuration while there are existing hosts in a pool, you must schedule the update action. If there’s none present, you’re good to go.
Session host management policy
A Session Host Management policy sets the update and creation behavior of the pool. When using Session Host configuration, at least one host management policy is required. A management policy is created once you enable Session Host Configuration, with the defaults shown here:
| Setting | Description | Default |
|---|---|---|
| Time zone | the time zone used to schedule updates | UTC |
| Max VMs removed during updates | the max number of session hosts to update concurrently (batch size) | 1 VM |
| Logoff delay (minutes) | the amount of time to wait after an update for users to be notified to sign out, before forcing logoffs | 2 minutes |
| Logoff message | the messaged displayed to users during update process | ”You will be signed out” |
| Leave in drain mode | whether newly created hosts should be left in drain-mode for post-deploy actions | False |
| Failed session host cleanup policy | whether to keep none, some, or all hosts that raise errors during deployment. Not applicable for updates (only creates) | KeepAll |
A couple of thoughts here:
- Max VMs removed during update: In larger host pools, this might be too slow. Batches of 3-5 hosts may be more appropriate. Balancing speed vs. user impact is the trade-off, but for certain zero-day updates or urgent resolutions there may be little flexibility.
- Logoff delay in minutes: For critical workloads, the default two-minute logoff delay might be too low. Again, depending on the urgency there may be little flexibility.
- Leave in drain mode: if images don’t require any post-deployment prep via Intune or SCCM, leave this false to allow rapid session host availability.
Standard management
Standard management is best suited alongside automated pipelines, custom deployment scripts, and management platforms like Hydra.
Microsoft calls out common admin tasks and processes in comparison with the Session Host Configuration approach.
- Creating and configuring session hosts can be done in the portal or other automation using a registration token. Admin must ensure the configuration is consistent across the pool, so automation is key even in native-Azure deployments.
- Scale session hosts can be configured using Azure Autoscale (e.g., Scaling Plans) to turn session hosts on and off based on schedules and usage demands
- Update session host images using automation pipelines or custom scripts as the Host Update capability is unavailable.
- Automatically powering on session hosts can still be achieved using the Power-on-Connect (Start VM on Connect) feature to enable end-users to turn on their session hosts as needed.
Working with Azure admin, many use the Azure Image Builder (or native Packer) in concert with Azure Compute Gallery, such that the latest image is always used in a host pool, and new hosts always inherit the latest and greatest changes as they are built.
Takeaways
In future articles, we’ll dig deeper into native autoscaling and the Session Host update (preview) capabilities within Azure. Because Hydra has powerful built-in image management capabilities, digging into AIB or Packer CI/CD pipelines won’t be a top focus.
Whatever we cover, we hope to see you there.