In the first part of this blog post, I’ll share my lessons learned from testing the new session Host update feature in Azure Virtual Desktop. This powerful feature simplifies updating session hosts in a host pool.
Introduction
Updating session hosts in an existing host pool can be a demanding task. In a golden image scenario, which is still used in many AVD environments, the process typically requires first creating a new version of the image. Once a new image version has been created administrators often will perform a rolling update by deploying extra session hosts from the latest image version side-by-side with the “old” ones in the existing host pool and drain those last ones. Once the changes have been validated, the old session hosts will be removed from the host pool and eventually deleted.
When done manually, this process involves lots of steps and is time consuming. Of course, manual steps can be fully automated through scripting and Infrastructure as Code. However, this requires quite some extra knowledge.
So, how can we simplify the update process?
The good news is that with the release of Session Host Update, besides of the image creation part, all of the above steps are taken care of by this new feature.
Session host update provides a built-in automated way to update all session hosts in an Azure Virtual Desktop host pool. This feature enables you to update the VM disk type, OS image, and other configuration properties through a linked Session Host Configuration. This allows us to completely automate the process of deallocating, deleting existing session hosts and replacing them with new hosts based on a new version of an updated session configuration.
How to configure?
Start with the correct host pool type
Host pools need to be of the type Automated, this means that this new feature can’t be activated on existing host pools which are of the type Standard.
As you can see in the image, no options are available to manage the session host configuration.
So, in case you want to start using session host update, you will have to deploy additional host pools and eventually decom the existing ones.
Please note the extra buttons that appear to manage the Session Host Configuration and update.
How can I define the management type?
Azure Portal
Wen creating a new host pool select Yes for the option Create Session Host Configuration
Bicep
In Bicep you control the type by the property managementType.
Below an example of code snippet used to deploy a host pool.
resource hostPool 'Microsoft.DesktopVirtualization/hostPools@2024-08-08-preview' = {
name: hostPoolName
location: location
properties: {
hostPoolType: hostPoolType
loadBalancerType: loadBalancerType
preferredAppGroupType: preferredAppGroupType
managementType: managementType
}
}All details can be found in the Bicep reference documentation.
Create a Session Host Configuration
Azure Portal
Once you’ve selected the option Session Host Configuration, in the next blade you will have the option to define the session host configuration itself.
The rest of the host pool creation process remains the same as for standard host pools.
Bicep
The Session Host Configuration can also be defined through Bicep.
Below an example.
// Define the host pool Session Host Configuration
param sessionHostConfigProperties object
resource sessionHostConfig 'Microsoft.DesktopVirtualization/hostPools/sessionHostConfigurations@2024-08-08-preview' = {
parent: hostPool
name: sessionHostConfigProperties.name
properties: sessionHostConfigProperties
}
All further details around the properties can be found in the Bicep reference documentation.
Review the Session Host Configuration
Once the deployment of your host pool is finished, you can view and edit your configuration in the Azure Portal
When you click View you can check all settings for the host pool. Below an example how this looks like.
When you click Edit, a new Window will open, which will allow you to plan a Session Host Update, but more about this in part 2.
What I’ve noticed
Empty host pools
Host pools can still be created without session hosts, which can be added later. This can be interesting when combined with dynamic scaling plans.
No more availability sets
I’ve noticed that there is no option anymore to define an availability set. Only availability zones can be configured. You can also choose to not use any of the zones.
Limited session naming control
A session host prefix can be defined, but the suffix numbering can’t be controlled. Session hosts will be numbered avdsh-0, avdsh-1, avdsh-2 and so on.
Only AD join support
At the time of writing this blog, Session Host Configuration can only be configured for AD joined session hosts.
Key Vault required
A key vault is required in which secrets are defined for:
- AVD session host local admin username
- AVD session host local admin password
- AVD domain join service account username
- AVD domain join service account password
The AD domain join UPN expects a certain syntax for the AD account that will join the session hosts
Syntax that needs to be used:
username@yourdomain.local
No extension control
The domain join process is handled by the AVD agent and not anymore by a domain join extension. With other words, you won’t notice anything in the Azure Portal concerning the domain join process.
Azure Policy
In case you want to deploy extra extension or applications during session host deployment, use Azure Policy. Examples could be Azure monitor agent or the dependency agent.
No Personal Pools support
Session Host Update is not available for Host pools of the type personal. As you can see below, no extra option appears.
Manual process
Adding session hosts to an automated host pool is only supported by Microsoft through the Azure Portal. More details can be found here.
Conclusion
I am quite enthousiast about this new option, because I believe that it drastically simplifies the process of updating AVD session hosts without the need of custom automation in place.
In combination with the tools like Azure Image Builder, the complete process from image building to deployment can become a very powerful solution.
The session host configuration also guarantees consistency across your session hosts as they are deployed through the same image and configuration.
In Part 2, which will come soon, I will describe my findings around the actual update process.
