03 · Host pools et session hosts : planifier, dimensionner, déployer, licencier

Version : 1.1 · Date : 2026-10-22 · Domaine 1 de l'examen : Plan and implement an Azure Virtual Desktop infrastructure (40 à 45 %)

En une phrase : un host pool regroupe des VM identiques (les session hosts) ; des application groups publient un bureau ou des applications de ce host pool ; un workspace les présente aux utilisateurs. Tout le reste (pooled ou personal, load balancing, taille des VM, licences, IaC) consiste à choisir les bons réglages de ces quatre objets.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude AZ-140 (compétences mesurées au 20 juillet 2026), blocs Plan host pools and session hosts et Implement host pools and session hosts :

Ce chapitre s'appuie sur le chapitre 01 (réseau, service AVD) et renvoie au chapitre 02 (FSLogix), au chapitre 04 (images), au chapitre 05 (jonction au domaine, RBAC), au chapitre 06 (RDP properties), au chapitre 07 (RemoteApp, App Attach) et au chapitre 08 (autoscale, supervision, mises à jour).

1. Les objets Azure Virtual Desktop et leurs liens#

1.1 Quatre objets, une chaîne#

Les host pools, application groups et workspaces sont des service objects (metadata) : ils vivent dans une région Azure (celle choisie à la création) et sont indépendants de la région des VM.

1.2 Les règles des application groups (très demandées)#

• Desktop : disponible pour les host pools pooled et personal ; un seul Desktop application group par host pool. Le portail le crée automatiquement avec le host pool.
• RemoteApp : pooled uniquement ; plusieurs RemoteApp application groups possibles sur un même host pool. Un utilisateur assigné à plusieurs RemoteApp application groups du même host pool voit l'union des applications.
• Preferred app group type (réglage du host pool : Desktop, RemoteApp) : si un utilisateur est assigné à la fois au Desktop et à un RemoteApp application group du même host pool, il ne voit que le type préféré. Pour lui donner les deux, il faut deux host pools.
• Une session peut être active, disconnected ou pending ; une reconnexion revient toujours à la session existante.

À retenir : donner l'accès = assigner l'utilisateur ou le groupe à l'application group, et enregistrer cet application group dans un workspace. Sans workspace, l'utilisateur ne voit rien ; sans assignation non plus.

1.3 Les limites du service à connaître#

2. Organiser les ressources : management groups, abonnements, resource groups#

Le Cloud Adoption Framework (scénario AVD) et l'AVD landing zone accelerator donnent le modèle de référence. La page CAF dédiée à AVD est marquée comme dépréciée (retrait annoncé le 30/10/2026) : la suite est dans l'accélérateur (github.com/Azure/avdaccelerator) et le guide de conception de l'Architecture Center ; les principes ne changent pas.

2.1 Management groups et abonnements#

Pour un public externe (clients d'une offre SaaS) : Microsoft recommande un tenant et un abonnement séparés pour les utilisateurs d'organisations différentes ; un abonnement séparé est aussi la bonne pratique avec le per-user access pricing (section 6).

2.2 Resource groups par rôle#

Bonne pratique complémentaire : des tags (centre de coût, host pool, environnement) sur toutes les ressources, pour suivre les coûts dans Cost Management (section 10).

3. Choisir le système d'exploitation des session hosts#

3.1 Les OS pris en charge (64 bits uniquement)#

Non pris en charge pour les session hosts : OS 32 bits ; éditions N, KN, LTSC ; Ultra disks pour le disque OS ; ephemeral OS disks ; Virtual Machine Scale Sets ; VM Arm64.

Windows Enterprise multi-session est un OS client qui accepte plusieurs sessions interactives simultanées : il n'existe que sur Azure Virtual Desktop (et Azure Local). Il offre l'expérience Windows 11 (Microsoft 365 Apps, Teams, Store) avec la densité d'un serveur RDS.

3.2 La recommandation, cas par cas#

Points techniques à connaître :

• Windows 11 exige Trusted launch (ou confidential VM) : c'est le security type par défaut quand on crée des session hosts depuis le portail.
• Pas de mise à niveau sur place d'un OS (Windows 10 vers 11, Server 2022 vers 2025) : on redéploie depuis une nouvelle image (chapitre 04).
• Windows Server : installer le rôle RD Session Host (Install-WindowsFeature -Name RDS-RD-Server -Restart) avant d'installer l'agent AVD quand on enregistre la VM à la main.
• Mises à jour mensuelles : sur multi-session, Microsoft recommande l'image (Azure Compute Gallery, session host update) plutôt que Windows Update en place ; sur Windows Server, Azure Update Manager ; sur personal, Windows Update ou Windows Autopatch.
• Azure Virtual Desktop Hybrid (session hosts sur site gérés par vous) ne prend pas en charge le multi-session, l'autoscale, Start VM on Connect ni la session host configuration.

4. L'architecture du host pool#

4.1 Pooled ou personal#

Le type du host pool (Pooled ou Personal) se choisit à la création et ne se change pas (en Terraform, le modifier recrée la ressource).

4.2 Personal : assignation automatique ou directe#

• Plusieurs bureaux personnels pour un même utilisateur (Assign multiple desktops to a single user) : seulement avec l'assignation Direct, coché à la création du host pool (load balancer type MultiplePersistent au lieu de Persistent). L'utilisateur voit chaque bureau séparément dans son feed.
• Une VM personal attribuée peut être désassignée ou réattribuée (portail ou PowerShell), par exemple au départ d'un employé.

4.3 Load balancing (pooled)#

• Max session limit : nombre maximum de sessions par session host ; valeur par défaut et maximum 999 999. Avec depth-first, garder 999 999 revient à tout envoyer sur la même VM : Azure Advisor recommande de la régler.
• La limite peut être dépassée ponctuellement en cas de forte charge simultanée ; la baisser ne déconnecte pas les sessions existantes.
• Seuls les session hosts Available et non drainés reçoivent de nouvelles sessions ; une reconnexion revient toujours au session host qui porte la session, même en drain mode.
• Personal : le load balancer type est Persistent (ou MultiplePersistent) ; pas de max session limit.

4.4 Deux approches de gestion : standard ou session host configuration#

La session host configuration décrit les VM : image (Marketplace ou Azure Compute Gallery), taille, préfixe de nom (10 caractères maximum, 15 avec le suffixe), resource group, disque OS, jonction au domaine (identifiants dans Key Vault), réseau, région et zones, security type, boot diagnostics, script personnalisé, tags. La session host management policy règle les mises à jour : fuseau horaire (UTC par défaut), nombre de VM retirées à la fois (1), délai de déconnexion (2 minutes, de 0 à 60), message aux utilisateurs, maintien en drain mode, nettoyage des VM en échec (KeepAll par défaut).

Avec une managed identity (system ou user-assigned) sur le host pool, il faut lui donner Desktop Virtualization Virtual Machine Contributor et Key Vault Secrets User sur les secrets d'identifiants. La création peut aller jusqu'à 500 VM d'un coup (selon les quotas).

Statut au 22/10/2026 : les pages Deploy Azure Virtual Desktop (mise à jour du 30/09/2026) et Host pool management approaches ne marquent plus la session host configuration comme préversion, et l'exigence d'un validation environment a disparu. Restent en préversion : les cmdlets PowerShell de ce type de host pool (module Az.DesktopVirtualization en version preview, 5.3.0 ou plus) et, selon sa page de dépannage, session host update. Région exclue : West US 3.

flowchart TD
    A["Les utilisateurs ont-ils besoin<br/>d'une VM attitrée ?"] -->|Oui| P["Personal<br/>Windows 11 Enterprise"]
    A -->|Non| B["Pooled<br/>Windows 11 Enterprise multi-session"]
    P --> P1{"VM précise ou<br/>plusieurs bureaux ?"}
    P1 -->|Oui| P2["Assignment type Direct"]
    P1 -->|Non| P3["Assignment type Automatic"]
    B --> C{"Session hosts sur Azure<br/>et cycle de vie délégué ?"}
    C -->|Oui| D["Session host configuration<br/>management type Automated"]
    C -->|"Non : Azure Local, VM existantes"| E["Standard<br/>registration key"]
    D --> F["Breadth-first ou depth-first<br/>+ max session limit"]
    E --> F

4.5 Validation environment#

Un host pool marqué validation environment reçoit les mises à jour du service AVD avant les autres : on y détecte une régression avant qu'elle touche la production. Il doit ressembler à la production (même image, mêmes applications) et être utilisé régulièrement (vrais utilisateurs ou tests automatisés). Le réglage se change à tout moment (Properties > Validation environment, validate_environment en Terraform, validationEnvironment en Bicep).

4.6 Deployment scope et emplacements particuliers#

5. Dimensionner : performance et capacité#

5.1 Les repères Microsoft pour le multi-session#

Règles qui accompagnent ces repères :

• Multi-session : 4 vCPU est le minimum stable ; rester entre 6 et 24 vCPU par VM (au-delà, plusieurs VM moyennes valent mieux qu'une grosse : moins d'impact d'une panne, meilleure granularité de l'autoscale).
• Single-session (personal) : Light 2 vCPU / 8 Go, Medium 4 vCPU / 16 Go, Heavy 8 vCPU / 32 Go.
• Profils FSLogix : compter 30 Go par utilisateur au départ ; avec Cloud Cache, partir d'un ratio de 2 utilisateurs par vCPU (Cloud Cache consomme plus de ressources locales).
• Ces chiffres sont des points de départ : seuls un test de charge avec les vraies applications et la mesure en production (Azure Virtual Desktop Insights, compteurs CPU, mémoire, User Input Delay) donnent la bonne densité.

Exemple de calcul : 400 utilisateurs Medium, 70 % de connexions simultanées au pic, VM D8s_v5 (8 vCPU) : 280 sessions ÷ (8 × 4 = 32 sessions par VM) ≈ 9 VM au pic, plus 1 ou 2 VM de marge (maintenance, panne) ; max session limit = 32 si depth-first.

5.2 Les familles de VM#

Disque OS : Premium SSD (ou Standard SSD pour les labs) ; Ultra disks et ephemeral OS disks non pris en charge.

5.3 GPU#

• Les séries NC, NCv2, NCv3, ND, NDv2 (calcul CUDA, IA) ne conviennent pas comme session hosts : pas d'accélération de l'interface Windows.
• NVIDIA : installer les pilotes GRID (pas CUDA), de préférence par l'extension NVIDIA GPU Driver ; AMD : pilotes AMD fournis par Azure. HEVC exige GRID 16.2 ou plus récent.
• Une VM NVIDIA inclut une licence GRID jusqu'à 25 utilisateurs simultanés.
• Activer ensuite l'accélération par stratégie de groupe (rendu GPU, encodage H.264/AVC 444, HEVC) : détails au chapitre 06.

5.4 Capacité : quotas, limites du service et zones#

6. Licences : choisir le modèle, puis le configurer#

6.1 Deux familles de coûts#

Azure Virtual Desktop coûte : (1) la consommation Azure (VM, disques, stockage, réseau, Log Analytics), toujours facturée, et (2) le droit d'accès des utilisateurs, qui dépend de qui ils sont et de l'OS des session hosts.

6.2 Le per-user access pricing#

• Il faut inscrire (enroll) un abonnement Azure : Azure Virtual Desktop > Per-user access pricing. La facturation apparaît ensuite sur la facture Azure de cet abonnement.
• Deux offres : Apps (RemoteApp seulement) et Desktops + apps ; prix fixe par utilisateur, facturé seulement pour les utilisateurs qui se sont connectés dans le mois, une seule fois par utilisateur et par période.
• Il facture tous les utilisateurs qui se connectent aux host pools de l'abonnement inscrit, y compris ceux qui ont déjà une licence : placer les utilisateurs internes dans un abonnement non inscrit.
• Il inclut les droits FSLogix ; il ne couvre pas le calcul Azure.
• Les licences ne traversent pas les tenants (seule exception citée : Microsoft Entra ID P1 dans une organisation multitenant).
• Un abonnement Dev/Test permet les tests de recette sans licence, jamais la production.

6.3 Configurer les licences sur les session hosts#

Licence Windows des VM (OS client) : avec une licence éligible, la VM tourne sans payer la licence Windows du prix pay-as-you-go, à condition que la propriété LicenseType = Windows_Client soit posée. Elle l'est automatiquement quand les session hosts sont créés par le service AVD (portail AVD, session host configuration) ; à poser soi-même pour une VM créée autrement (template, Terraform, image importée).

# Poser la licence Windows client sur une VM existante (session Azure déjà ouverte avec Connect-AzAccount)
$vm = Get-AzVM -ResourceGroupName 'rg-avd-compute' -Name 'avd-sh-0'
$vm.LicenseType = 'Windows_Client'
Update-AzVM -ResourceGroupName 'rg-avd-compute' -VM $vm

# Vérifier les VM déjà licenciées
Get-AzVM | Where-Object LicenseType -eq 'Windows_Client' | Select-Object ResourceGroupName, Name, LicenseType

az vm update --resource-group rg-avd-compute --name avd-sh-0 --license-type Windows_Client

En Terraform : license_type = "Windows_Client" sur azurerm_windows_virtual_machine ; en Bicep : licenseType: 'Windows_Client' dans les propriétés de la VM.

Windows Server :

1. La licence Windows Server de la VM : Windows_Server (Azure Hybrid Benefit, si vous avez des licences avec Software Assurance), sinon licence incluse dans le prix de la VM. Limite connue : des VM Windows Server créées par le processus de host pool peuvent recevoir un mauvais license type, à vérifier.
2. Les RDS CAL : un RDS license server (rôle Remote Desktop Licensing, CAL installées et activées) joignable par les session hosts ; sur chaque session host, par GPO (Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing) : Use the specified Remote Desktop license servers et Set the Remote Desktop licensing mode (Per User ou Per Device), stockés sous HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (LicenseServers, LicensingMode). Sans license server, les connexions sont refusées à la fin de la période de grâce de 120 jours (lecture : GetGracePeriodDays() de la classe WMI Win32_TerminalServiceSetting).

Azure Local : activer les VM (Azure verification for VMs pour Windows Enterprise multi-session et Windows Server 2022 Datacenter: Azure Edition, méthodes d'activation habituelles pour les autres).

7. Créer un host pool et ses session hosts avec le portail#

Rôles minimums sur le resource group : Desktop Virtualization Host Pool Contributor (host pool, registration key), plus Virtual Machine Contributor pour créer les VM (Azure, Extended Zones) ou Azure Stack HCI VM Contributor (Azure Local). Ne pas désactiver WinRM sur l'image : l'ajout de session hosts par le portail utilise PowerShell DSC.

Azure Virtual Desktop > Host pools > Create :

Ensuite :

1. Application groups > le Desktop application group créé > Assignments : ajouter les utilisateurs ou groupes.
2. Pour des RemoteApp : créer un application group RemoteApp, ajouter des applications (au moins un session host allumé et disponible), l'assigner, l'ajouter au workspace (chapitre 07).
3. Session hosts joints à Microsoft Entra ID : donner Virtual Machine User Login (ou Administrator Login) aux utilisateurs et régler la RDP property d'authentification Entra (chapitre 05).
4. Vérifier que les session hosts passent en statut Available (Session hosts).

Ajouter des session hosts plus tard (standard) : Host pool > Session hosts > Add reprend la configuration ; il faut garder la même taille, image et identité que les VM existantes (le portail génère une registration key pour l'occasion).

8. Automatiser : PowerShell, Azure CLI, ARM, Bicep et Terraform#

Toutes les commandes supposent une session déjà ouverte (Connect-AzAccount, az login) : aucun identifiant dans le code. Le module PowerShell est Az.DesktopVirtualization ; l'extension CLI desktopvirtualization s'installe au premier appel.

8.1 PowerShell#

# Host pool pooled en gestion standard
$hp = @{
    Name                  = 'hp-avd-prd-01'
    ResourceGroupName     = 'rg-avd-service'
    Location              = 'westeurope'
    HostPoolType          = 'Pooled'
    LoadBalancerType      = 'DepthFirst'
    MaxSessionLimit       = 16
    PreferredAppGroupType = 'Desktop'
    ValidationEnvironment = $false
    StartVMOnConnect      = $true
}
New-AzWvdHostPool @hp

# Desktop application group, workspace, puis enregistrement de l'application group dans le workspace
$hpId = (Get-AzWvdHostPool -Name 'hp-avd-prd-01' -ResourceGroupName 'rg-avd-service').Id
$ag = New-AzWvdApplicationGroup -Name 'ag-avd-prd-01-desktop' -ResourceGroupName 'rg-avd-service' -Location 'westeurope' `
    -ApplicationGroupType 'Desktop' -HostPoolArmPath $hpId
New-AzWvdWorkspace -Name 'ws-avd-prd' -ResourceGroupName 'rg-avd-service' -Location 'westeurope'
Register-AzWvdApplicationGroup -ResourceGroupName 'rg-avd-service' -WorkspaceName 'ws-avd-prd' -ApplicationGroupPath $ag.Id

# Donner l'accès à un groupe Entra ID
New-AzRoleAssignment -ObjectId '{objectId-du-groupe}' -RoleDefinitionName 'Desktop Virtualization User' `
    -ResourceName 'ag-avd-prd-01-desktop' -ResourceGroupName 'rg-avd-service' `
    -ResourceType 'Microsoft.DesktopVirtualization/applicationGroups'

# Registration key valable 8 heures (1 heure minimum, 27 jours maximum), puis lecture
New-AzWvdRegistrationInfo -ResourceGroupName 'rg-avd-service' -HostPoolName 'hp-avd-prd-01' `
    -ExpirationTime $((Get-Date).ToUniversalTime().AddHours(8).ToString('yyyy-MM-ddTHH:mm:ss.fffffffZ'))
$token = (Get-AzWvdHostPoolRegistrationToken -ResourceGroupName 'rg-avd-service' -HostPoolName 'hp-avd-prd-01').Token

Pour une session host configuration : New-AzWvdHostPool avec -ManagementType 'Automated' et une managed identity (-IdentityType 'SystemAssigned'), puis New-AzWvdSessionHostConfiguration et New-AzWvdSessionHostManagement. Le paramètre -DeploymentScope (regional host pools) demande la version préliminaire du module (5.4.5-preview).

8.2 Azure CLI#

az desktopvirtualization hostpool create \
  --name hp-avd-prd-01 --resource-group rg-avd-service --location westeurope \
  --host-pool-type Pooled --load-balancer-type BreadthFirst \
  --preferred-app-group-type Desktop --max-session-limit 16

# Personal, assignation automatique
az desktopvirtualization hostpool create \
  --name hp-avd-dev-01 --resource-group rg-avd-service --location westeurope \
  --host-pool-type Personal --load-balancer-type Persistent \
  --preferred-app-group-type Desktop --personal-desktop-assignment-type Automatic

hostPoolArmPath=$(az desktopvirtualization hostpool show --name hp-avd-prd-01 \
  --resource-group rg-avd-service --query id --output tsv)
az desktopvirtualization applicationgroup create --name ag-avd-prd-01-desktop \
  --resource-group rg-avd-service --location westeurope \
  --application-group-type Desktop --host-pool-arm-path "$hostPoolArmPath"
az desktopvirtualization workspace create --name ws-avd-prd --resource-group rg-avd-service

# Registration key, puis lecture
az desktopvirtualization hostpool update --name hp-avd-prd-01 --resource-group rg-avd-service \
  --registration-info expiration-time="$(date -u -d '+8 hours' +%Y-%m-%dT%H:%M:%S.%7NZ)" registration-token-operation="Update"
az desktopvirtualization hostpool retrieve-registration-token --name hp-avd-prd-01 \
  --resource-group rg-avd-service --query token --output tsv

8.3 Enregistrer une VM à la main (agent et BootLoader)#

Pour une VM créée hors du portail AVD (template, Terraform, image importée) :

1. Vérifier l'accès aux URL requises (outil Azure Virtual Desktop Agent URL Tool, chapitre 01).
2. Windows Server : installer le rôle RD Session Host et redémarrer.
3. Installer l'agent avec la clé, puis le BootLoader :

msiexec /i Microsoft.RDInfra.RDAgent.Installer-x64-{version}.msi /quiet REGISTRATIONTOKEN={registration-key}
msiexec /i Microsoft.RDInfra.RDAgentBootLoader.Installer-x64-{version}.msi /quiet

Quatre composants apparaissent : Remote Desktop Agent Boot Loader, Remote Desktop Services Infrastructure Agent, Remote Desktop Services Infrastructure Geneva Agent, Remote Desktop Services SxS Network Stack. La clé ne sert qu'à l'enregistrement : la VM obtient ensuite un machine token. Une VM éteinte plus de 90 jours perd ce token et doit être réenregistrée (l'allumer au moins 20 minutes tous les 90 jours l'évite).

Dépannage : événement 3277 (INVALID_REGISTRATION_TOKEN, EXPIRED_MACHINE_TOKEN) dans le journal Application ; clés IsRegistered et RegistrationToken sous HKLM:\SOFTWARE\Microsoft\RDInfraAgent ; après une nouvelle clé : Restart-Service RDAgentBootLoader.

8.4 ARM templates et Bicep#

Les types : Microsoft.DesktopVirtualization/hostPools, applicationGroups, workspaces (dernière version d'API non préliminaire lue : 2025-10-10). Microsoft publie un exemple de démarrage rapide (Creates AVD with Microsoft Entra ID Join) et des Azure Verified Modules (avm/res/desktop-virtualization/host-pool).

// ==== Objets de service AVD : host pool pooled, Desktop application group, workspace ====
param location string = resourceGroup().location
param hostPoolName string = 'hp-avd-prd-01'
param tokenExpiration string = dateTimeAdd(utcNow(), 'PT8H') // utcNow() n'est permis qu'en valeur par défaut d'un paramètre

resource hostPool 'Microsoft.DesktopVirtualization/hostPools@2025-10-10' = {
  name: hostPoolName
  location: location
  properties: {
    hostPoolType: 'Pooled'
    loadBalancerType: 'DepthFirst'
    maxSessionLimit: 16
    preferredAppGroupType: 'Desktop'
    validationEnvironment: false
    startVMOnConnect: true
    registrationInfo: {
      expirationTime: tokenExpiration
      registrationTokenOperation: 'Update'
    }
  }
}

resource desktopAppGroup 'Microsoft.DesktopVirtualization/applicationGroups@2025-10-10' = {
  name: '${hostPoolName}-desktop'
  location: location
  properties: {
    applicationGroupType: 'Desktop'
    hostPoolArmPath: hostPool.id
  }
}

resource workspace 'Microsoft.DesktopVirtualization/workspaces@2025-10-10' = {
  name: 'ws-avd-prd'
  location: location
  properties: {
    applicationGroupReferences: [
      desktopAppGroup.id // l'enregistrement dans le workspace se fait ici
    ]
  }
}

Les VM se déclarent ensuite comme toute VM (Microsoft.Compute/virtualMachines avec licenseType: 'Windows_Client'), plus une extension qui installe l'agent avec la clé. Ne jamais sortir la registration key en output : la récupérer au moment du déploiement et la passer comme paramètre @secure().

Autres propriétés utiles de hostPools : personalDesktopAssignmentType, customRdpProperty, agentUpdate (fenêtres de mise à jour de l'agent), publicNetworkAccess. managementType (Automated ou Standard), deploymentScope et les options RDP Shortpath n'existent que dans les API preview (depuis 2025-11-01-preview) : la GA 2025-10-10 les a retirées, et azurerm (qui utilise la GA) ne les expose pas.

8.5 Terraform#

Ressources du provider hashicorp/azurerm (version 5.10 lue sur le registre) :

# ==== Objets de service AVD : host pool, registration info, Desktop application group, workspace ====
resource "azurerm_virtual_desktop_host_pool" "prd" {
  name                     = "hp-avd-prd-01"
  resource_group_name      = azurerm_resource_group.service.name
  location                 = azurerm_resource_group.service.location
  type                     = "Pooled"     # Personal ou Pooled ; changer recrée le host pool
  load_balancer_type       = "DepthFirst" # BreadthFirst, DepthFirst ; Persistent ou MultiplePersistent pour Personal
  maximum_sessions_allowed = 16           # pooled seulement, de 0 à 999999
  preferred_app_group_type = "Desktop"
  validate_environment     = false
  start_vm_on_connect      = true

  scheduled_agent_updates {
    enabled = true
    schedule {
      day_of_week = "Saturday"
      hour_of_day = 2 # fenêtre de 2 heures, deux blocs schedule au maximum
    }
  }
}

# Clé renouvelée toutes les 8 heures sans créer de différence à chaque plan (timestamp() en créerait une)
resource "time_rotating" "avd_token" {
  rotation_hours = 8
}

resource "azurerm_virtual_desktop_host_pool_registration_info" "prd" {
  hostpool_id     = azurerm_virtual_desktop_host_pool.prd.id
  expiration_date = time_rotating.avd_token.rotation_rfc3339
}

resource "azurerm_virtual_desktop_application_group" "prd_desktop" {
  name                = "ag-avd-prd-01-desktop"
  resource_group_name = azurerm_resource_group.service.name
  location            = azurerm_resource_group.service.location
  type                = "Desktop" # RemoteApp seulement sur un host pool Pooled
  host_pool_id        = azurerm_virtual_desktop_host_pool.prd.id
}

resource "azurerm_virtual_desktop_workspace" "prd" {
  name                = "ws-avd-prd"
  resource_group_name = azurerm_resource_group.service.name
  location            = azurerm_resource_group.service.location
}

resource "azurerm_virtual_desktop_workspace_application_group_association" "prd_desktop" {
  workspace_id         = azurerm_virtual_desktop_workspace.prd.id
  application_group_id = azurerm_virtual_desktop_application_group.prd_desktop.id
}

• Arguments Required du host pool : name, resource_group_name, location, type, load_balancer_type ; pour Personal, personal_desktop_assignment_type (Automatic ou Direct) devient obligatoire.
• Une seule ressource registration_info par host pool (sinon résultats incohérents). Son attribut token est stocké dans le state : state distant chiffré à accès restreint, durée de clé courte, tout output marqué sensitive = true.
• Les VM : azurerm_windows_virtual_machine avec license_type = "Windows_Client" et une extension (DSC ou script) qui installe l'agent avec le token ; ou mieux, la session host configuration, qui supprime la gestion du token.
• Accès : azurerm_role_assignment du rôle Desktop Virtualization User sur l'application group.

9. Configurer le host pool et les session hosts#

9.1 Les réglages du host pool#

9.2 Les réglages des session hosts#

Séquence de maintenance d'une VM pooled : drain mode → message aux utilisateurs → attente de la fin des sessions (ou déconnexion) → maintenance ou remplacement → sortie du drain mode. La session host configuration automatise cette séquence (délai de déconnexion, message, nombre de VM traitées à la fois).

9.3 Les statuts à connaître#

L'API connaît aussi des statuts détaillés : NotJoinedToDomain, DomainTrustRelationshipLost, SxSStackListenerNotReady, FSLogixNotHealthy, Disconnected.

10. Les coûts#

Outils : le module Azure Virtual Desktop de l'Azure Pricing Calculator (calcul, stockage, utilisateurs, heures, concurrence, per-user access pricing, réservations) ; Microsoft Cost Management après le déploiement, avec des tags sur les ressources AVD ; AVD Insights pour mesurer l'usage réel et ajuster.

11. Labs conseillés#

Dans un abonnement de test et un tenant de test, avec un VNet qui a un accès sortant vers les URL AVD (voir chapitre 01) et des utilisateurs de test licenciés (essai Microsoft 365 E3 ou E5). Coût : une ou deux VM D4s_v5 quelques heures, des disques Premium SSD, rien de cher si tout est supprimé le jour même. Nettoyage à la fin de chaque lab : supprimer les resource groups rg-avd-lab-* (le host pool ne se supprime qu'une fois ses session hosts retirés).

Lab 1. Un host pool pooled complet par le portail.

1. Host pools > Create : Pooled, breadth-first, max session limit 4, validation environment Yes, 1 VM Windows 11 Enterprise multi-session, D4s_v5, jointe à Microsoft Entra ID, workspace créé et Desktop application group enregistré.
2. Assigner deux utilisateurs de test ; leur donner Virtual Machine User Login sur le resource group des VM.
3. Se connecter avec Windows App ou le client web (https://windows.cloud.microsoft).
4. Résultat attendu : le session host est Available ; les deux sessions apparaissent sur la même VM ; Get-AzVM ... | Select LicenseType affiche Windows_Client sans rien avoir fait.

Lab 2. Load balancing et drain mode.

1. Ajouter une deuxième VM au host pool (Session hosts > Add).
2. Breadth-first : ouvrir deux sessions, constater qu'elles se répartissent ; passer en depth-first, max session limit 2 : les deux nouvelles sessions vont sur la même VM.
3. Mettre la VM occupée en drain mode ; déconnecter puis reconnecter un utilisateur : il revient sur la même VM ; un troisième utilisateur part sur l'autre.
4. Résultat attendu : comportement conforme à la section 4.3.

Lab 3. Enregistrer une VM à la main.

1. Créer une VM Windows 11 Enterprise multi-session hors d'AVD dans le même VNet (Trusted launch).
2. Générer une registration key de 2 heures ; installer l'agent puis le BootLoader avec la clé (section 8.3).
3. Vérifier IsRegistered = 1 sous HKLM:\SOFTWARE\Microsoft\RDInfraAgent et le statut Available dans le portail.
4. Vérifier le LicenseType : vide (VM créée hors du service) ; le poser à Windows_Client.

Lab 4. Le même déploiement en IaC.

1. Avec le code Terraform de la section 8.5 (ou le Bicep de la section 8.4) dans un resource group rg-avd-lab-iac : host pool, registration info, Desktop application group, workspace, association, role assignment Desktop Virtualization User.
2. Relancer un plan : aucune différence (grâce à time_rotating).
3. Résultat attendu : le workspace apparaît dans le feed de l'utilisateur, vide tant qu'aucun session host n'est enregistré.

Lab 5. Un host pool personal en assignation Direct.

1. Créer un host pool Personal, assignation Direct, Assign multiple desktops to a single user coché, 2 VM Windows 11 Enterprise.
2. Attribuer les deux VM au même utilisateur.
3. Résultat attendu : deux bureaux distincts dans son feed ; un autre utilisateur assigné à l'application group n'obtient rien tant qu'aucune VM ne lui est attribuée.

12. Les pièges d'examen#

13. Scénarios d'entraînement#

1. Contoso a 600 employés de bureau (charge Medium), Microsoft 365 E3, 60 % de connexions simultanées au pic. Elle veut le coût le plus bas. Que recommander (OS, type de host pool, algorithme, taille indicative) ?

Windows 11 Enterprise multi-session, host pool pooled, profils FSLogix. Depth-first avec une max session limit calculée (D8s_v5 : 8 vCPU × 4 = 32) et autoscale : 360 sessions ÷ 32 ≈ 12 VM au pic, plus une marge. Aucune licence d'accès à acheter (E3 éligible) ; licence Windows des VM couverte (Windows_Client).

2. Les développeurs de Fabrikam doivent installer leurs outils et garder leur environnement. Chacun a parfois besoin de deux VM (Windows 11 et une version de test). Quelle configuration ?

Host pool personal, Windows 11 Enterprise, assignation Direct avec Assign multiple desktops to a single user (MultiplePersistent). Chaque VM est attribuée nominativement ; mises à jour en place.

3. Un utilisateur est assigné au Desktop application group et au RemoteApp application group Office du host pool HP1. Il ne voit que le bureau. Pourquoi ? Comment lui donner les deux ?

Le preferred app group type de HP1 est Desktop : c'est le seul type affiché quand les deux sont assignés sur le même host pool. Publier les RemoteApp depuis un second host pool (ou ne lui assigner qu'un des deux).

4. Un éditeur publie son logiciel de gestion à 2 000 clients externes via AVD et refuse de leur demander une licence Microsoft. Ses propres équipes testent sur la même plateforme. Quel modèle ?

Per-user access pricing (offre Apps si seules des RemoteApp sont publiées) sur un abonnement inscrit dédié aux clients, session hosts Windows 11 Enterprise multi-session. Les équipes internes, déjà licenciées, utilisent un abonnement non inscrit ; sinon elles seraient facturées aussi. Tenant et abonnement séparés conseillés pour des clients d'organisations différentes.

5. Une application métier n'est supportée que sur Windows Server 2022. L'entreprise a des RDS CAL per user avec Software Assurance. Que faut-il mettre en place côté licences ?

Session hosts Windows Server 2022 (rôle RD Session Host), Azure Hybrid Benefit (Windows_Server) si la Software Assurance couvre les licences Windows Server, un RDS license server avec les CAL installées, et sur les session hosts la GPO Use the specified Remote Desktop license servers + licensing mode Per User. Le per-user access pricing ne s'applique pas.

6. L'équipe plateforme déploie les VM avec Terraform et constate des factures Windows au tarif pay-as-you-go alors que tous les utilisateurs ont Microsoft 365 E5. Pourquoi, et comment corriger ?

Le LicenseType n'est posé automatiquement que pour les VM créées par le service AVD. Ajouter license_type = "Windows_Client" sur azurerm_windows_virtual_machine (ou Update-AzVM / az vm update --license-type Windows_Client sur l'existant).

7. Après une coupure, un session host éteint depuis 100 jours redémarre mais reste Unavailable ; l'événement 3277 indique EXPIRED_MACHINE_TOKEN. Que faire ?

Le machine token a expiré (plus de 90 jours éteinte). Générer une nouvelle registration key, la mettre dans la clé de registre RegistrationToken (ou réinstaller l'agent avec REGISTRATIONTOKEN=), passer IsRegistered à 0 si besoin, puis Restart-Service RDAgentBootLoader. À l'avenir, allumer ces VM régulièrement ou les retirer du host pool.

8. Une organisation veut que les nouvelles images soient appliquées automatiquement aux VM d'un host pool pooled Azure, avec remplacement progressif hors des heures de travail et sans gérer de registration key. Quelle approche, et quelle contrainte de création ?

Un host pool avec session host configuration (management type Automated) et une session host management policy (planning, nombre de VM retirées à la fois, délai de déconnexion), mises à jour par session host update. Le choix se fait à la création du host pool et ne se change pas ; pooled et Azure seulement ; identifiants de jonction dans Key Vault.

9. Le bureau d'études doit faire tourner une application de CAO en multi-session. L'équipe propose des VM NC24ads_A100_v4. Bonne idée ?

Non : les séries NC de calcul (A100, H100, NCv3…) visent CUDA et l'IA, sans accélération de l'interface Windows. Prendre NVadsA10 v5 (GPU partiel ou complet) ou NCasT4_v3, avec les pilotes GRID, puis activer le rendu et l'encodage GPU par stratégie de groupe ; licence GRID jusqu'à 25 utilisateurs simultanés.

10. Contoso déploie AVD dans trois pays et veut un modèle d'organisation des ressources. Que recommander ?

Sous le management group Landing zones, un abonnement AVD (ou un par région si les quotas l'imposent) et un abonnement de services partagés (Azure Compute Gallery, Key Vault). Dans chaque abonnement AVD, des resource groups par rôle : service objects, compute, network, storage. Un host pool par région, au plus près des utilisateurs ; réseau raccordé au hub de l'abonnement Connectivity ; pas de management group par environnement ; tags pour les coûts.

14. Pour aller plus loin (au-delà de l'examen)#

• AVD landing zone accelerator (github.com/Azure/avdaccelerator) : déploiement Bicep ou Terraform complet et revu (réseau, identité, stockage, supervision, images), bonne base pour un projet réel.
• Azure Verified Modules pour AVD (Bicep et Terraform) : modules maintenus par Microsoft pour host pool, application group, workspace, scaling plan.
• Regional host pools (préversion) : pour des exigences de résidence des metadata.
• Azure Virtual Desktop Hybrid : session hosts sur votre propre infrastructure, sans multi-session ni autoscale.
• Comparer avec Windows 365 : Cloud PC personnel au prix fixe par utilisateur, sans gestion des host pools ; AVD reste plus souple (multi-session, RemoteApp, choix des VM, coût à l'usage).

15. Fiche à retenir#

• Chaîne : workspace → application group → host pool → session hosts ; l'accès = assigner les utilisateurs à l'application group (Desktop Virtualization User).
• Un Desktop application group par host pool ; plusieurs RemoteApp, pooled uniquement ; un application group = un host pool + un workspace.
• Desktop + RemoteApp du même host pool pour un même utilisateur : seul le preferred app group type s'affiche.
• Pooled = multi-session, FSLogix, redéploiement par image ; personal = 1:1, mises à jour en place. Le type ne change pas.
• Personal : Automatic ou Direct ; plusieurs bureaux par utilisateur = Direct seulement.
• Breadth-first : au hasard parmi la moitié la moins chargée ; depth-first : le plus chargé sous la max session limit (défaut et maximum 999 999, à régler).
• Standard (tous les cas, Azure Local) ou session host configuration (pooled, Azure, Automated, choix définitif, pas de registration key ; plus marquée préversion, cmdlets PowerShell encore en preview).
• Registration key : 1 heure à 27 jours ; machine token perdu après 90 jours éteinte ; agent puis BootLoader ; événement 3277.
• Non pris en charge : 32 bits, N/KN/LTSC, Ultra disk OS, ephemeral OS disk, VM Scale Sets, Arm64 ; Windows 11 = Trusted launch par défaut.
• Repères multi-session par vCPU : Light 6, Medium 4, Heavy 2, Power 1 ; VM de 6 à 24 vCPU (4 minimum) ; profils 30 Go.
• GPU : NVadsA10 v5, NVv3, NCasT4_v3 (pilotes GRID) ; NVv4 retirée le 30/09/2026 ; pas de NC/ND de calcul.
• Limites : 10 000 session hosts par host pool, 400 host pools par workspace, 1 300 workspaces par tenant, 500 RemoteApps par application group.
• Licence interne OS client : M365 E3/E5/A3/A5/F3/Business Premium, Windows Enterprise E3/E5, Education A3/A5, VDA per user ; Windows Server : RDS CAL avec SA ou RDS USL + license server.
• Externes : per-user access pricing (abonnement inscrit, Apps ou Desktops + apps, OS client seulement), qui facture aussi les internes de l'abonnement.
• LicenseType Windows_Client : automatique via le service AVD, à poser soi-même sinon.
• Resource groups séparés : service objects, compute, network, storage, shared ; AVD sous Landing zones ; pas de management group par environnement.
• Terraform : type, load_balancer_type obligatoires ; une seule registration_info par host pool ; token dans le state ; association workspace ↔ application group par une ressource dédiée.
• Coûts : densité, depth-first, autoscale, Start VM on Connect, réservations ou savings plan, Dev/Test, Azure Pricing Calculator (module AVD), tags.

Références#

Toutes lues le 22/10/2026 sur Microsoft Learn, sauf mention :

• Guide d'étude de l'examen AZ-140
• Azure Virtual Desktop terminology
• Preferred application group type behavior for pooled host pools
• Host pool load balancing algorithms
• Configure host pool load balancing
• Configure personal desktop assignment
• Host pool management approaches
• Deploy Azure Virtual Desktop (standard et session host configuration)
• Add session hosts to a host pool
• Session host update
• Configure a host pool as a validation environment
• Regional host pools
• Azure Virtual Desktop on Azure Local
• Azure Virtual Desktop on Azure Extended Zones
• Azure Virtual Desktop Hybrid overview
• Prerequisites for Azure Virtual Desktop (operating systems and licenses)
• Windows update management methodologies for session hosts
• Understanding Extended Security Updates for Windows 10 on AVD
• Security recommendations for Azure Virtual Desktop
• Session host virtual machine sizing guidelines
• Enable GPU acceleration for Azure Virtual Desktop
• NVadsA10 v5 sizes series
• NVv4-series retirement
• Azure Virtual Desktop service limits
• Save costs with Azure Reserved VM Instances
• Licensing Azure Virtual Desktop
• Apply a Windows license to session host virtual machines
• License your RDS deployment with client access licenses
• Understand and estimate costs for Azure Virtual Desktop
• Configure Start VM on Connect
• Troubleshoot the Azure Virtual Desktop agent
• Cloud Adoption Framework : Azure Virtual Desktop
• Microsoft.DesktopVirtualization hostPools (Bicep, ARM)
• Configure Azure Virtual Desktop with Terraform
• Module Az.DesktopVirtualization : New-AzWvdHostPool
• az desktopvirtualization (Azure CLI)
• Registre Terraform, provider hashicorp/azurerm 5.10.0 : azurerm_virtual_desktop_host_pool, azurerm_virtual_desktop_application_group, azurerm_virtual_desktop_workspace, azurerm_virtual_desktop_workspace_application_group_association, azurerm_virtual_desktop_host_pool_registration_info