Intro
I will create the session hosts in this part of my blog series about Azure Virtual Desktop (AVD) and Bicep. The session hosts are the workers in an AVD environment, and therefore, also one of the places we spent most of our time on optimizations and management. For this article, I will focus on the standard image from the Microsoft marketplace, but I expect to do more articles on how to manage an AVD image. I made a blog post last year about how to get started with Packer for Azure images, which works well for AVD.
Prerequisites
You will need to have an AVD Host pool, Workspace, and Desktop application groups already created. If you do not have these in place, you can look at the previous articles in the series.
Session hosts
As mentioned in the intro section, the hosts are the workers for AVD. Session hosts run Windows and can be both Windows Client and Windows Server. Most customers I have worked with have used Windows 11 for their AVD environments because they want the same user experience on both physical and virtual machines. Windows 10/11 can run multiple users on the same virtual machine; before AVD, this was only possible on Windows Server operating systems. Windows 10/11 can only run multiuser configurations if deployed in Azure or Azure Local hardware. This limitation is a Microsoft licensing limit, so any attempt to run it otherwise will violate that license agreement.
Deployment description for session hosts
AVD has multiple ways of running session hosts; you can run personal or pooled (multiuser) desktops and have these devices joined to an on-premises domain, Entra ID, or Azure domain services. For this article, I will showcase how to do deployments for joining an on-premises domain, but in later articles, I will show how to allow for Entra ID machines as well. Currently, AVD users are required to synchronize from an on-premises domain or Azure domain services due to the storage account access lists not supporting NFTS with Entra ID only.
The process for deploying the session hosts will be as follows.
- Create a new registration key on the host pool
- Create a new virtual machine in Azure
- Join the new machine to the Active Directory domain
- Install the AVD agents with the registration key
After these steps, the virtual machine is up and running, and users can start logging into AVD and running their applications from there.
Bicep modules
First, I will create a module for availability set so session hosts are not all placed in the same update and fault domain.
param availabilitysetname string
param location string
param platformFaultDomainCount int = 2
param platformUpdateDomainCount int = 5
resource availabilitySet 'Microsoft.Compute/availabilitySets@2024-07-01' = {
name: availabilitysetname
location: location
properties: {
platformFaultDomainCount: platformFaultDomainCount
platformUpdateDomainCount: platformUpdateDomainCount
}
sku: {
name: 'Aligned'
}
}
Next, I will create a new module for the session hosts. This module is rather large, but some needed resources require some lines of code. I will try to split the code up below and explain what each part is performing.
The first step is networking. Below are three parameters for locating the subnet I need for the VM’s network interface. I do a lookup with these values and then use the subnet.id output when I create the network interface. As you can see in the code, I am using a loop to generate the number of network interfaces I need for the virtual machines. Each virtual machine will have one network interface, so I am using the same variable for input to the loop.
param subnet_name string
param virtual_network_name string
param virtual_network_resource_group_name string
resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
name: virtual_network_name
scope: resourceGroup(virtual_network_resource_group_name)
}
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-05-01' existing = {
name: subnet_name
parent: vnet
}
resource nic 'Microsoft.Network/networkInterfaces@2024-05-01' = [for i in range(0, session_hosts_count): {
name: 'nic-${vm_prefix}-${i + 1}'
location: location
tags: tags
properties: {
ipConfigurations: [
{
name: 'ipconfig1'
properties: {
subnet: {
id: subnet.id
}
privateIPAllocationMethod: 'Dynamic'
}
}
]
}
}]
After I create my network interface, I can make the virtual machine. Below are the parameters I use for the virtual machine and the code for creating the virtual machine resources. The parameters are straightforward: only a limit of 11 characters for the vm_prefix and a selection of trusted or standard launches for the virtual machine. I have set the default to trusted launch to enable security by default.
param session_hosts_count int
@description('Virtual machine prefix name. max number of characters is 11.')
@maxLength(11)
@minLength(1)
param vm_prefix string
param local_admin_username string
@secure()
param local_admin_password string
param ou_path string
@allowed([
'Standard'
'TrustedLaunch'
])
param securityType string = 'TrustedLaunch'
param vm_size string = 'Standard_D2s_v5'
resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = [for i in range(0, session_hosts_count): {
dependsOn:[
nic[i]
]
name: '${vm_prefix}-${i + 1}'
location: location
tags: tags
properties: {
licenseType: 'Windows_Client'
hardwareProfile: {
vmSize: vm_size
}
availabilitySet: {
id: resourceId('Microsoft.Compute/availabilitySets', '${availabilityset.name}')
}
osProfile: {
computerName: '${vm_prefix}-${i + 1}'
adminUsername: local_admin_username
adminPassword: local_admin_password
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsDesktop'
offer: 'office-365'
sku: '24h2-avd'
version: 'latest'
}
osDisk: {
createOption: 'FromImage'
managedDisk: {
storageAccountType: 'Standard_LRS'
}
}
}
networkProfile: {
networkInterfaces: [
{
id: nic[i].id
}
]
}
securityProfile: (securityType == 'TrustedLaunch') ? {
uefiSettings: {
secureBootEnabled: true
vTpmEnabled: true
}
securityType: 'TrustedLaunch'
} : null
}
}]
After the machine creation, I can join it to the domain. As shown below, I have a few parameters and then run an Azure virtual machine extension that executes the domain join. This process is the same as we have done for joining machines to Active Directory for many years. I am using the same loop to join the machines to Active Directory.
param domain string
param domain_join_username string
@secure()
param domain_join_password string
resource domainjoinsessionhosts 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = [for i in range(0, session_hosts_count): {
name: '${vm[i].name}/JoinDomain'
location: location
properties: {
publisher: 'Microsoft.Compute'
type: 'JsonADDomainExtension'
typeHandlerVersion: '1.3'
autoUpgradeMinorVersion: true
settings: {
name: domain
ouPath: ou_path
user: domain_join_username
restart: true
options: 3
}
protectedSettings: {
password: domain_join_password
}
}
dependsOn: [
vm[i]
]
}]
The module’s last part is adding the newly created machines to the AVD host pool. The code below shows that I first ran the host pool module I used before, then took the registration token output to install the AVD agent on the virtual machines and join them to the host pool.
param host_pool_name string
module hostpool 'avd_hostpool.bicep' = {
name: 'hostpool'
params: {
location: location
name: host_pool_name
tags: tags
}
}
resource avdagentsessionhosts 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = [for i in range(0, session_hosts_count): {
name: '${vm[i].name}/AddSessionHost'
location: location
properties: {
publisher: 'Microsoft.Powershell'
type: 'DSC'
typeHandlerVersion: '2.73'
autoUpgradeMinorVersion: true
settings: {
modulesUrl: 'https://raw.githubusercontent.com/Azure/RDS-Templates/master/ARM-wvd-templates/DSC/Configuration.zip'
configurationFunction: 'Configuration.ps1\\AddSessionHost'
properties: {
hostPoolName: hostpool.name
registrationInfoToken: hostpool.outputs.registrationInfoToken
}
}
}
dependsOn: [
domainjoinsessionhosts[i]
]
}]
Bicep deployment code
The modules above are the logic behind deploying session hosts, so in this section, I will use those modules and keep my exposed code as simple as possible. Now, with session hosts, it is hard to keep the amount of code low since there are a lot of inputs needed to create them, but the code below is my attempt to keep it as simple as possible.
targetScope = 'subscription'
param availabilityset_name string = 'avail-level4'
param domain string = 'domain.com'
param domain_join_username string = 'domain-join@domain.com'
@allowed([
'Production'
'Test'
])
param environment string = 'Production'
param host_pool_name string = 'level4'
param local_admin_username string = 'localadmin'
param key_vault_name string = 'kv-level4'
param key_vault_resource_group_name string = 'rg-level4-shared-services'
param key_vault_subscription_id string = ''
param location string = 'WestEurope'
param name string = 'level4'
param ou_path string = 'OU=HostPool1,OU=AVD,DC=Domain,DC=Com'
param session_hosts_count int = 1
param subnet_name string = 'snet-avd-hostpool'
param tags object = {
Owner: 'IT'
Environment: environment
}
param virtual_network_name string = 'vnet-avd'
param virtual_network_resource_group_name string = 'rg-avd-network'
param vm_prefix string = 'level4'
param vm_size string = 'Standard_D2s_v3'
resource rg_hostpool 'Microsoft.Resources/resourceGroups@2024-07-01' existing = {
name: 'rg-${name}'
}
resource kv 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
name: key_vault_name
scope: resourceGroup(key_vault_subscription_id,key_vault_resource_group_name)
}
module avd_session_hosts 'Modules/avd_session_host.bicep' = {
name: 'avd_session_hosts'
scope: rg_hostpool
params: {
tags: tags
subnet_name: subnet_name
availabilityset_name: availabilityset_name
compute_gallery_image_name: compute_gallery_image_name
domain: domain
domain_join_username: domain_join_username
domain_join_password: kv.getSecret('domain-join-password')
host_pool_name: host_pool_name
local_admin_password: kv.getSecret('local-admin-password')
local_admin_username: local_admin_username
location: location
ou_path: ou_path
session_hosts_count: session_hosts_count
virtual_network_name: virtual_network_name
virtual_network_resource_group_name: virtual_network_resource_group_name
vm_prefix: vm_prefix
vm_size: vm_size
}
}
Deployment
Deploying this Bicep code is done the same way we have been doing it so far. I am still doing a subscription deployment, but creating session hosts could also be done on a resource group level.
New-AzSubscriptionDeployment -Name "AVD-SessionHosts" -Location "WestEurope" -TemplateFile .\session_hosts.bicep
Login to AVD
Since all the requirements for AVD are complete, I can log into my desktop and see the applications I need. Since we only deployed a marketplace image, this is, for now, just Windows 11 with Office365 installed.
GitHub repository
I have uploaded all the code for this blog series to my public GitHub repository. You can find it here:
Summary
With this post completed, we can log in to AVD and use applications on the remote desktop. Before we can call this a real production AVD, a few items remain on the list, but I will address those in later blog posts.
In this post, I have shown one of the more complicated sections of doing AVD with code, but overall, it is not too complex. In the next post, I have a minor update for the session hosts. This update will allow me to use custom images for the session hosts, which fits well with the next part: creating a custom image with a few applications installed.
As always, feedback is welcome, and if I missed some points, please let me know.