08 · Superviser, maintenir et reprendre Azure Virtual Desktop

Version : 1.1 · Date : 2026-10-22 · Domaine 4 de l'examen : Monitor and maintain an Azure Virtual Desktop infrastructure (10 à 15 %)

En une phrase : on collecte deux flux de journaux (diagnostic settings du service, Azure Monitor Agent sur les session hosts) pour les lire dans AVD Insights, on ajuste la capacité avec le load balancing et un scaling plan, on met à jour les hosts en remplaçant l'image plutôt qu'en patchant chaque VM, et on prépare la reprise : sauvegarder ce qui a un état (profils, postes personnels, images), redéployer ce qui n'en a pas, et prévoir une seconde région.

Ce chapitre suppose connus le host pool, le workspace et les application groups (03 · 1), FSLogix et Cloud Cache (02 · 10), les images et Azure Compute Gallery (04 · 5), RDP Shortpath et la qualité de connexion (01 · 5, 01 · 9). Azure Backup en général (vaults, soft delete, immutabilité, rôles) est traité dans SC-500 chapitre 03 : on n'y revient pas.

Ce que l'examen demande#

Bloc Monitor and maintain an Azure Virtual Desktop infrastructure du guide d'étude AZ-140 (compétences au 20/07/2026) :

1. Les bases avant de commencer#

1.1 Ce que Microsoft gère, ce que vous gérez#

Deux principes guident tout le domaine :

• un session host pooled est sans état (stateless) : il se redéploie depuis l'image, il ne se restaure pas ;
• un poste personnel (personal desktop) a un état (applications, données sur le disque) : il se sauvegarde et se réplique comme une VM classique.

1.2 Les rôles utiles au domaine 4#

Les rôles qui démarrent ou créent des VM s'attribuent à un service principal : la managed identity du host pool (system-assigned ou user-assigned) ou le service principal Azure Virtual Desktop (application ID 9cdead84-a844-4324-93f2-b2e6bb768d07). Pour l'attribuer, il faut Microsoft.Authorization/roleAssignments/write (Owner ou User Access Administrator).

2. Collecter les journaux des session hosts et du service#

2.1 Deux flux de données#

Les deux sont nécessaires : le premier dit ce que l'utilisateur a vécu (connexion, erreur, latence), le second pourquoi le host a souffert (CPU, mémoire, disque, FSLogix).

2.2 Les diagnostic settings du service#

Chemin : objet AVD (host pool, application group ou workspace) > Monitoring > Diagnostic settings > Add diagnostic setting, cocher les catégories, destination Send to Log Analytics workspace.

Règles à connaître :

• les événements de diagnostic arrivent quand l'activité est terminée ; seules les connexions ont des états intermédiaires (Started quand l'utilisateur lance, Connected quand il est sur la VM, Completed à la déconnexion) ;
• une erreur ServiceError = true vient du service : ouvrir un ticket Microsoft avec le CorrelationId ; false = problème côté client ou configuration ;
• les tables WVD ne supportent pas le plan Basic logs : elles sont en Analytics ;
• à grande échelle, appliquer les diagnostic settings par Azure Policy plutôt qu'à la main.

2.3 Azure Monitor Agent sur les session hosts#

Le plus simple : le configuration workbook d'AVD Insights (section 3.1), onglet Session host data settings, qui crée la DCR, installe l'AMA (extension de VM, avec une system-assigned managed identity) et associe les hosts. La DCR d'Insights collecte des compteurs de performance (processeur, mémoire, disque, User Input Delay per Session…) et des journaux Windows (System, Application, journaux Terminal Services et FSLogix). Une DCR créée par Insights porte un nom qui commence par microsoft-avdi-.

Piège : une session host update recrée les VM sans l'AMA. Prévoir une Azure Policy qui déploie l'agent et associe la DCR, sinon Insights perd les nouveaux hosts.

2.4 Analyser avec KQL#

Chemin : Log Analytics workspace > Logs (ou Azure Monitor > Logs avec le workspace en étendue).

Durée des connexions par utilisateur (relier Connected et Completed par CorrelationId) :

WVDConnections
| where TimeGenerated > ago(1d)
| where State in ("Connected", "Completed")
| summarize Debut = minif(TimeGenerated, State == "Connected"),
            Fin = maxif(TimeGenerated, State == "Completed") by CorrelationId, UserName, SessionHostName
| extend DureeMinutes = datetime_diff("minute", Fin, Debut)
| order by DureeMinutes desc

Erreurs les plus fréquentes, en séparant service et client :

WVDErrors
| where TimeGenerated > ago(7d)
| summarize Nombre = count(), Utilisateurs = dcount(UserName) by CodeSymbolic, ServiceError, Source
| order by Nombre desc

Utilisateurs à forte latence (RTT médian au-dessus de 150 ms) :

WVDConnectionNetworkData
| where TimeGenerated > ago(1d)
| join kind=inner (WVDConnections | where State == "Connected" | project CorrelationId, UserName) on CorrelationId
| summarize RttMedian = percentile(EstRoundTripTimeInMs, 50), Rtt95 = percentile(EstRoundTripTimeInMs, 95) by UserName
| where RttMedian > 150
| order by RttMedian desc

Version et mises à jour de l'agent AVD par host :

WVDAgentHealthStatus
| where TimeGenerated > ago(1d)
| summarize arg_max(TimeGenerated, AgentVersion, LastUpgradeTimeStamp, UpgradeState, UpgradeErrorMsg) by SessionHostName
| order by AgentVersion asc

3. Superviser avec Azure Monitor#

3.1 Azure Virtual Desktop Insights#

AVD Insights est un ensemble de workbooks Azure Monitor qui lisent les tables de la section 2. Accès : portail > Azure Virtual Desktop > Insights, ou https://aka.ms/avdi.

3.2 Les onglets et ce qu'ils montrent#

Seuils de latence d'Insights : moins de 100 ms idéal, qualité dégradée au-delà de 200 ms ; Microsoft conseille aussi un RTT de moins de 150 ms entre l'utilisateur et la région des session hosts.

3.3 Alertes et Service Health#

Exemple de requête d'alerte (plus de 20 erreurs de service en 15 minutes) :

WVDErrors
| where ServiceError == true
| summarize Nombre = count() by bin(TimeGenerated, 15m), _ResourceId
| where Nombre > 20

3.4 Personnaliser les workbooks d'Insights#

Les workbooks livrés par Microsoft sont en lecture seule. Pour les adapter :

1. ouvrir le workbook d'Insights, Edit puis Save As : choisir un nom, un abonnement, un groupe de ressources et une région ; c'est maintenant votre workbook (ressource Microsoft.Insights/workbooks) ;
2. Edit : ajouter une étape (Add > Add query, Add metric, Add parameters, Add text, Add group), écrire la requête KQL, choisir la visualisation (grid, chart, tiles, map) ;
3. réutiliser les parameters existants (abonnement, host pool, plage de temps) pour que la nouvelle étape suive les filtres ;
4. Done Editing, Save ; partager par Share (le lecteur doit avoir les droits sur le workbook et sur les données) ; épingler une visualisation sur un dashboard Azure si besoin.

Piège : une copie personnalisée ne reçoit plus les mises à jour du workbook Microsoft. Garder le workbook d'origine à côté et ne copier que ce qui manque.

4. Optimiser la capacité et la performance des session hosts#

4.1 Load balancing#

# Exemple (non exécuté) : passer un host pool en depth-first avec 10 sessions par host
az desktopvirtualization hostpool update \
  --resource-group rg-avd-prd \
  --name hp-avd-prd-01 \
  --load-balancer-type DepthFirst \
  --max-session-limit 10

• Un host pool personal n'a pas d'algorithme : l'utilisateur va toujours sur son poste.
• Créé en breadth-first sans valeur, le max session limit vaut 999999 : à corriger avant de passer en depth-first ou d'activer autoscale (qui l'exige).
• Autoscale ignore l'algorithme du host pool : il applique celui de chaque phase de son planning (section 5).

4.2 Max session limit et dimensionnement#

Recommandations Microsoft pour les hosts multi-session (Windows 10/11 Enterprise multi-session, Windows Server) :

• Microsoft recommande des VM de 4 à 24 vCPU pour le multi-session (au moins 4 cœurs) : trop petites, une session lourde pénalise les autres ; trop grosses, une panne touche beaucoup d'utilisateurs.
• Le max session limit se fixe à partir de ce ratio, puis se valide par un test de charge et par l'onglet Host Performance d'Insights.

4.3 Lire les signaux et agir#

5. Autoscale avec les scaling plans#

5.1 Power management ou dynamic autoscaling#

À l'examen, « autoscale » sans précision = power management.

5.2 Prérequis#

• Le rôle Desktop Virtualization Power On Off Contributor attribué à la managed identity du host pool ou au service principal Azure Virtual Desktop, à la portée de chaque abonnement qui contient des host pools et des session hosts : la page de création précise qu'une portée plus basse (groupe de ressources, host pool, VM) empêche autoscale de fonctionner correctement. La page de dépannage cite aussi host pool et groupe de ressources : à l'examen, répondre abonnement.
• Pooled : max session limit renseigné (pas 999999).
• Un seul outil de scaling : pas de scaling tool (Azure Automation + Logic Apps) ni d'outil tiers sur le même host pool.
• Le scaling plan est créé dans la même région que le host pool qu'il gère ; il ne fonctionne que dans son fuseau horaire.
• Un scaling plan par host pool ; un plan peut gérer plusieurs host pools du même type (pooled ou personal, type non modifiable après création).
• Pour PowerShell : module Az.DesktopVirtualization 4.2.0 ou plus.

5.3 Pooled host pools#

Comment il décide :

• il démarre un host dès que la capacité utilisée dépasse le seuil, dans n'importe quelle phase ;
• il arrête un host seulement s'il est sans session (sauf force logoff en ramp-down) et si l'arrêt ne fait pas dépasser le seuil ; jamais en ramp-up ;
• hosts nécessaires = CEILING(sessions ÷ (max session limit × capacity threshold)), en comptant les sessions déconnectées ; il garde le plus grand de ce nombre et du minimum de hosts.

Exemple : 6 hosts, max session limit 5, seuil 30 %, minimum 30 %. Au ramp-up, 2 hosts démarrent (30 % de 6 = 1,8, arrondi à 2), capacité 10. À 4 sessions, la capacité utilisée est 40 % > 30 % : un 3e host démarre (capacité 15, 27 %).

Pièges : pour un pooled, autoscale écrase le drain mode ; pendant une maintenance, poser l'exclusion tag sur les VM concernées. Une VM taguée compte toujours dans le calcul du minimum de hosts.

5.4 Personal host pools#

• Autoscale personal ne force jamais la déconnexion et ne met pas les postes en drain mode.
• Un poste démarré sur lequel personne ne se connecte est désalloué après une période d'inactivité.
• Hibernate exige que l'hibernation soit activée sur la VM (sinon autoscale ne fait rien) et n'est pas pris en charge avec FSLogix ni App Attach.
• Start VM on Connect est aussi une propriété du host pool (pooled ou personal), utilisable sans scaling plan, avec le rôle Power On Contributor (06 · 11).

5.5 Mise en œuvre#

Portail : Azure Virtual Desktop > Scaling plans > Create : Basics (région, fuseau horaire, Host pool type, Scaling method, exclusion tag), Schedules (une ligne par planning, un onglet par phase), Host pool assignments (cocher Enable autoscale).

PowerShell (exemple non exécuté, valeurs de démonstration) :

$plan = @{
    ResourceGroupName = 'rg-avd-prd'
    Name              = 'sp-avd-prd-01'
    Location          = 'francecentral'
    FriendlyName      = 'Scaling plan bureaux'
    HostPoolType      = 'Pooled'
    TimeZone          = 'Romance Standard Time'
    ExclusionTag      = 'excludeFromScaling'
    HostPoolReference = @(@{
        'hostPoolArmPath'    = '/subscriptions/<subscriptionId>/resourceGroups/rg-avd-prd/providers/Microsoft.DesktopVirtualization/hostPools/hp-avd-prd-01'
        'scalingPlanEnabled' = $true
    })
}
New-AzWvdScalingPlan @plan

$jours = @{
    ResourceGroupName             = 'rg-avd-prd'
    ScalingPlanName               = 'sp-avd-prd-01'
    ScalingPlanScheduleName       = 'semaine'
    DaysOfWeek                    = 'Monday','Tuesday','Wednesday','Thursday','Friday'
    RampUpStartTimeHour           = 7;  RampUpStartTimeMinute   = 0
    RampUpLoadBalancingAlgorithm  = 'BreadthFirst'
    RampUpMinimumHostsPct         = 20; RampUpCapacityThresholdPct = 60
    PeakStartTimeHour             = 9;  PeakStartTimeMinute     = 0
    PeakLoadBalancingAlgorithm    = 'DepthFirst'
    RampDownStartTimeHour         = 18; RampDownStartTimeMinute = 0
    RampDownLoadBalancingAlgorithm = 'DepthFirst'
    RampDownMinimumHostsPct       = 10; RampDownCapacityThresholdPct = 90
    RampDownForceLogoffUser       = $true
    RampDownWaitTimeMinute        = 30
    RampDownNotificationMessage   = 'Votre session sera fermée dans 30 minutes, enregistrez votre travail.'
    RampDownStopHostsWhen         = 'ZeroSessions'
    OffPeakStartTimeHour          = 20; OffPeakStartTimeMinute  = 0
    OffPeakLoadBalancingAlgorithm = 'DepthFirst'
}
New-AzWvdScalingPlanPooledSchedule @jours

# Vérifier l'association
(Get-AzWvdScalingPlan -ResourceGroupName 'rg-avd-prd' -Name 'sp-avd-prd-01').HostPoolReference |
    Format-List HostPoolArmPath, ScalingPlanEnabled

Pour un personal : New-AzWvdScalingPlanPersonalSchedule (paramètres RampUpStartVMOnConnect, RampUpAutoStartHost, actions de déconnexion et de fermeture par phase).

Terraform (ressource azurerm_virtual_desktop_scaling_plan, arguments vérifiés dans le registre, azurerm 5.10.0) :

# ==== Scaling plan pooled : jours ouvrés, rôle Power On Off Contributor pour le service AVD ====
data "azuread_service_principal" "avd" {
  client_id = "9cdead84-a844-4324-93f2-b2e6bb768d07" # service principal Azure Virtual Desktop
}

resource "azurerm_role_assignment" "avd_power" {
  scope                = data.azurerm_subscription.current.id # portée abonnement recommandée par Microsoft
  role_definition_name = "Desktop Virtualization Power On Off Contributor"
  principal_id         = data.azuread_service_principal.avd.object_id
}

resource "azurerm_virtual_desktop_scaling_plan" "bureaux" {
  name                = local.scaling_plan_name
  location            = azurerm_resource_group.avd.location # même région que le host pool
  resource_group_name = azurerm_resource_group.avd.name
  time_zone           = "Romance Standard Time"
  exclusion_tag       = "excludeFromScaling"

  schedule {
    name                                 = "semaine"
    days_of_week                         = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]
    ramp_up_start_time                   = "07:00"
    ramp_up_load_balancing_algorithm     = "BreadthFirst"
    ramp_up_minimum_hosts_percent        = 20
    ramp_up_capacity_threshold_percent   = 60
    peak_start_time                      = "09:00"
    peak_load_balancing_algorithm        = "DepthFirst"
    ramp_down_start_time                 = "18:00"
    ramp_down_load_balancing_algorithm   = "DepthFirst"
    ramp_down_minimum_hosts_percent      = 10
    ramp_down_capacity_threshold_percent = 90
    ramp_down_force_logoff_users         = true
    ramp_down_wait_time_minutes          = 30
    ramp_down_notification_message       = "Votre session sera fermée dans 30 minutes, enregistrez votre travail."
    ramp_down_stop_hosts_when            = "ZeroSessions"
    off_peak_start_time                  = "20:00"
    off_peak_load_balancing_algorithm    = "DepthFirst"
  }

  host_pool {
    hostpool_id          = azurerm_virtual_desktop_host_pool.bureaux.id
    scaling_plan_enabled = true
  }

  depends_on = [azurerm_role_assignment.avd_power] # sans le rôle, autoscale échoue en silence
}

La page du registre parle encore de préversion et d'un rôle personnalisé : c'est daté, Microsoft Learn documente le rôle built-in Desktop Virtualization Power On Off Contributor. Une association séparée existe aussi (azurerm_virtual_desktop_scaling_plan_host_pool_association) : utiliser l'une ou l'autre, pas les deux.

5.6 Suivre et dépanner l'autoscale#

• Activer la catégorie Autoscale dans les diagnostic settings du host pool : chaque évaluation arrive dans WVDAutoscaleEvaluationPooled (colonnes Config… = réglages de la phase en cours). Si ResultType == "Failed", joindre WVDErrors par CorrelationId.
• Insights propose une vue des opérations d'autoscale.

WVDAutoscaleEvaluationPooled
| where TimeGenerated > ago(1d) and ResultType == "Failed"
| join kind=leftouter (WVDErrors | project CorrelationId, CodeSymbolic, Message) on CorrelationId
| project TimeGenerated, _ResourceId, CodeSymbolic, Message

Causes classiques d'échec : rôle absent ou mal placé, max session limit à 999999, autre outil de scaling actif, VM verrouillée par une resource lock ou une policy, quota de cœurs atteint.

6. Gérer les sessions actives et les application groups#

6.1 Sessions et drain mode#

Chemin : host pool > Sessions (une ligne par session : utilisateur, host, état Active ou Disconnected, heure) et host pool

Session hosts.

Procédure de maintenance d'un host pooled : exclusion tag (si autoscale), drain mode, message, attente, log off des restants, maintenance, puis retrait du drain mode et du tag.

6.2 PowerShell#

# Exemples (non exécutés) : lister, prévenir, vider un host
$hp = @{ ResourceGroupName = 'rg-avd-prd'; HostPoolName = 'hp-avd-prd-01' }

Get-AzWvdUserSession @hp | Select-Object Name, UserPrincipalName, SessionState, CreateTime

Update-AzWvdSessionHost @hp -Name 'avd-prd-0.contoso.local' -AllowNewSession:$false   # drain mode

Send-AzWvdUserSessionMessage @hp -SessionHostName 'avd-prd-0.contoso.local' -UserSessionId 2 `
    -MessageTitle 'Maintenance' -MessageBody 'Fermeture de session dans 15 minutes.'

Disconnect-AzWvdUserSession @hp -SessionHostName 'avd-prd-0.contoso.local' -Id 2   # déconnecter
Remove-AzWvdUserSession @hp -SessionHostName 'avd-prd-0.contoso.local' -Id 2       # fermer la session

Après un changement de drain mode, attendre environ 60 secondes avant de relire l'état.

6.3 Application groups#

Ce qu'on surveille et gère au quotidien (la création est au chapitre 03 · 1, les applications au chapitre 07 · 2) :

Get-AzWvdApplicationGroup -ResourceGroupName 'rg-avd-prd' |
    Select-Object Name, ApplicationGroupType, HostPoolArmPath, WorkspaceArmPath
Get-AzRoleAssignment -Scope (Get-AzWvdApplicationGroup -ResourceGroupName 'rg-avd-prd' -Name 'ag-desktop').Id `
    -RoleDefinitionName 'Desktop Virtualization User'

7. Stratégie de mise à jour des session hosts#

7.1 Deux approches#

flowchart TD
    A[Host pool à mettre à jour] --> B{Type ?}
    B -->|Personal| C[Patch in-place : Windows Update for Business, Autopatch, Configuration Manager, Update Manager]
    B -->|Pooled| D{Session host configuration ?}
    D -->|Oui| E[Nouvelle image dans Compute Gallery puis Session host update]
    D -->|Non| F[Nouvelle image puis redéploiement des hosts ; à défaut Update Manager]
    E --> G[Tester sur un host pool de validation, garder l'image N-1]
    F --> G

7.2 Session host update#

Fonction d'un host pool avec session host configuration : elle remplace les hosts par de nouveaux, construits sur la configuration mise à jour (image, taille de VM, type de disque, security type : Standard, Trusted launch, Confidential, identifiants de jonction AD, enrôlement Intune, compte admin local, script PowerShell de configuration).

Déroulé :

1. un premier host, l'initial, est mis à jour seul pour valider le processus ;
2. puis les autres par batch (nombre de hosts indisponibles en même temps) ; exemple : 10 hosts, batch de 3 = l'initial puis 3 batches de 3, au moins 7 hosts disponibles à tout moment ;
3. pour chaque host : notification aux utilisateurs et attente (0 à 60 minutes), fermeture des sessions, drain mode, retrait du host pool (l'objet ordinateur AD est conservé), création d'une nouvelle VM nommée SessionHostName-DateTime avec le même hostname, ajout au host pool, puis suppression de l'ancienne VM.

7.3 Patch in-place#

• Azure Update Manager : évaluation périodique, maintenance configurations (fenêtres planifiées), patch à la demande ; la VM doit être en orchestration Customer Managed Schedules pour les fenêtres planifiées.
• Windows Update for Business / Windows Autopatch via Intune pour les hosts inscrits à Intune ; Configuration Manager pour les parcs existants.
• Avant une fenêtre de patch sur un pooled : exclusion tag + drain mode sur les hosts concernés, et une fenêtre hors des heures ouvrées ; les hosts doivent être démarrés (Start VM on Connect ne démarre pas une VM pour un patch).

7.4 L'agent Azure Virtual Desktop#

L'agent (et le side-by-side stack, l'agent boot loader) se met à jour automatiquement, par vagues (flights) étalées sur environ 5 jours. Scheduled Agent Updates permet de choisir quand :

7.5 Que recommander#

8. Plan de reprise après sinistre#

8.1 Le partage des responsabilités#

Le plan de reprise couvre quatre couches, chacune avec sa méthode :

Les chiffres de RPO et RTO sont des estimations du centre d'architecture : chaque plan doit être mesuré par un test.

8.2 Haute disponibilité dans une région#

Microsoft recommande les availability zones quand la région et la taille de VM les supportent, et du stockage ZRS pour les profils dans la même logique.

8.3 Personal host pools avec Site Recovery#

• Microsoft recommande Site Recovery pour les host pools personal (possible aussi en pooled) ; la région cible doit être alignée sur la reprise du stockage FSLogix.
• Architecture Azure to Azure : pas d'intégration directe à AVD, réplication VM par VM ; le host pool reste unique (pas de second host pool, ni de workspace supplémentaire).
• Failover et failback déclenchés par l'administrateur (portail, API, PowerShell), puis reprotect pour revenir.
• Ne pas utiliser le test failover de Site Recovery sur des session hosts : la VM dupliquée s'enregistre au control plane et entre en conflit avec l'originale. Tester plutôt en démarrant les hosts secondaires avec un groupe d'utilisateurs de test.
• Site Recovery et Azure Backup peuvent protéger la même VM.

8.4 Pooled host pools#

Second host pool dans la région de reprise, construit depuis la même image (replica de la gallery) :

• hot standby : hosts créés mais arrêtés (coût du stockage seulement) ou au minimum par un scaling plan ; un recovery plan Site Recovery peut orchestrer le démarrage ;
• app groups propres au second host pool ; à la bascule, retirer les affectations du host pool principal et affecter les utilisateurs au secondaire (ou les deux en active-active, chaque utilisateur sur une seule région) ;
• les deux host pools doivent rester alignés (image, applications, GPO, réglages RDP).

8.5 Les profils FSLogix#

Le détail de Cloud Cache est au chapitre 02 · 10. Les options de reprise :

Règles :

• GRS n'existe pas pour Azure Files Premium, ni pour le Standard avec large file shares activé : d'où Cloud Cache ;
• Cloud Cache : jusqu'à 4 emplacements ; il ne rend pas les ouvertures de session plus rapides (souvent un peu plus lentes) ;
• séparer Profile container et Office container ; ne pas rendre l'Office container résilient (il se reconstruit) ;
• rediriger les dossiers connus vers OneDrive (Known Folder Move) réduit ce qu'il faut protéger.

8.6 Tester et dérouler le plan#

sequenceDiagram
    participant Ops as Exploitation
    participant SH as Service Health
    participant B as Région B
    participant U as Utilisateurs
    SH->>Ops: Alerte Service issue région A
    Ops->>Ops: Décision de bascule (RTO, RPO)
    Ops->>B: Démarrer les hosts (scaling plan ou recovery plan)
    Ops->>B: Vérifier enregistrement des hosts (WVDHostRegistrations)
    Ops->>U: Affecter les utilisateurs aux app groups de B
    U->>B: Connexion, profil depuis l'emplacement Cloud Cache de B
    Ops->>Ops: Retour en A : même chemin à l'envers, puis reprotect

Le plan doit lister : déclencheur et décideur, ordre de démarrage (réseau, AD DS, DNS, stockage, hosts), comptes et groupes à réaffecter, vérifications (Insights, WVDConnections dans la région B), retour arrière, et la fréquence des tests.

9. Déploiement multi-région#

Ce que la région B doit avoir avant le sinistre :

• réseau (hub, spoke, peering, connectivité hybride), DNS, contrôleurs AD DS ou Microsoft Entra Domain Services si les hosts sont joints à un domaine ;
• quotas de cœurs suffisants et, pour les charges critiques, des capacity reservations ;
• replicas de l'image dans la Compute Gallery (au moins deux copies par région, ZRS si possible) ;
• stockage des profils, applications métier et données qu'utilisent les sessions ;
• supervision : un Log Analytics workspace commun aux deux régions donne une vue unifiée dans Insights, mais il tombe avec sa région ; un workspace par région est plus résilient.

10. Stratégie de sauvegarde#

10.1 Quoi sauvegarder#

10.2 Configurer sauvegarde et restauration#

Profils FSLogix sur Azure Files (portail : storage account > File shares > le partage > Backup) :

Profils sur Azure NetApp Files : snapshot policy (horaire, quotidienne, hebdomadaire) sur le volume, Azure NetApp Files backup pour une copie hors du volume, cross-region replication pour la reprise ; restauration d'un fichier depuis le dossier ~snapshot ou d'un volume depuis un snapshot.

Postes personnels (VM) :

Images :

• garder au moins la version N-1 dans la Compute Gallery pour revenir en arrière ; marquer une version Exclude from latest si elle ne doit plus être choisie par défaut ;
• replicas dans la région de reprise, stockage ZRS quand c'est disponible ;
• le pipeline (Azure VM Image Builder, Packer, scripts) en Git : il reconstruit l'image à l'identique (04 · 4).

11. Labs conseillés#

À faire dans un abonnement de test avec un host pool pooled de 2 hosts (D2s_v5 ou B-series) et un personal de 1 host. Coût : celui des VM pendant les heures de lab, l'ingestion Log Analytics (quelques centaines de Mo), le stockage Azure Files et le vault. Nettoyage : supprimer le groupe de ressources du lab, le scaling plan, le vault (désactiver le soft delete des éléments de test avant).

1. Insights de bout en bout : créer un workspace dédié, lancer le configuration workbook (diagnostic settings puis AMA et DCR), se connecter avec deux utilisateurs, exécuter les requêtes KQL de la section 2.4. Résultat attendu : après environ 15 minutes, les onglets Overview, Connection Performance et Host Performance se remplissent.
2. Workbook personnalisé : Save As du workbook Insights, ajouter une étape « erreurs de service par host pool » avec le paramètre de plage de temps, partager en lecture à un collègue. Résultat attendu : la nouvelle étape suit les filtres ; le collègue sans Log Analytics Reader ne voit pas les données.
3. Scaling plan pooled : rôle Power On Off Contributor, max session limit 2, seuil 50 %, minimum 50 %, une phase ramp-up qui commence dans 10 minutes ; connecter 2 puis 3 utilisateurs. Résultat attendu : le second host démarre au-delà du seuil ; WVDAutoscaleEvaluationPooled explique chaque décision. Poser l'exclusion tag sur un host et constater qu'il n'est plus touché.
4. Sessions et maintenance : drain mode sur un host, Send-AzWvdUserSessionMessage, puis Remove-AzWvdUserSession. Résultat attendu : les nouvelles connexions vont sur l'autre host ; la session fermée disparaît de la liste.
5. Sauvegarde des profils : sauvegarder le partage FSLogix (policy Snapshot), supprimer le VHDX d'un utilisateur de test déconnecté, le restaurer en item-level. Résultat attendu : l'utilisateur retrouve son profil à la connexion suivante.

12. Les pièges d'examen#

13. Scénarios d'entraînement#

1. Contoso a activé les diagnostic settings de ses host pools. Le support veut savoir quel host est saturé quand les utilisateurs se plaignent de lenteur, mais Insights n'affiche rien dans Host Performance. Que manque-t-il ?

Les données des session hosts : l'Azure Monitor Agent et la data collection rule d'Insights, à déployer depuis le configuration workbook (onglet Session host data settings). Les diagnostic settings ne couvrent que le service.

2. Un auditeur doit consulter Insights pour trois host pools sans pouvoir rien modifier. Quels rôles ?

Desktop Virtualization Reader sur les host pools (ou leur groupe de ressources) et Log Analytics Reader sur le workspace.

3. L'équipe veut ajouter à Insights un onglet des erreurs FSLogix et garder les mises à jour de Microsoft sur le reste. Que faire ?

Save As du workbook Insights dans un groupe de ressources de l'équipe, ajouter une étape de requête sur Event (journal FSLogix) avec les paramètres existants ; garder le workbook Microsoft d'origine en parallèle, car la copie ne reçoit plus ses mises à jour.

4. Un host pool pooled de 20 hosts D4s, en breadth-first, coûte trop cher la nuit et le week-end. Les utilisateurs arrivent entre 7 h et 9 h. Que mettre en place ?

Un scaling plan power management : rôle Power On Off Contributor à l'identité du host pool ou au service principal AVD (abonnement), max session limit renseigné, planning semaine (ramp-up 7 h breadth-first, peak 9 h, ramp-down 18 h avec notification puis force logoff ou ZeroActiveSessions, off-peak 20 h depth-first) et un planning week-end au minimum.

5. Pendant une maintenance, l'administrateur passe deux hosts en drain mode ; une heure plus tard, ils acceptent de nouveau des sessions. Pourquoi et comment l'éviter ?

Autoscale écrase le drain mode des pooled. Poser l'exclusion tag du scaling plan sur ces VM pendant la maintenance, puis le retirer.

6. Une agence d'architecture a des postes personnels avec GPU. Les utilisateurs se déconnectent sans fermer leur session le soir et la facture reste élevée. Que configurer ?

Un scaling plan personal : Start VM on Connect activé, et dans Disconnect settings un délai (par exemple 60 minutes) puis Deallocate. Pas d'hibernation si les postes utilisent FSLogix. Autoscale ne forcera pas la fermeture de session.

7. Fabrikam a un host pool pooled avec session host configuration et veut appliquer chaque mois les correctifs de sécurité sans dérive entre hosts. Quelle stratégie ?

Image-based servicing : construire chaque mois une nouvelle version d'image dans la Compute Gallery, la valider sur un host pool de test, puis lancer une session host update programmée hors heures ouvrées (batch adapté à la capacité, notification), autoscale désactivé pendant l'opération ; garder la version N-1.

8. Une banque héberge 300 postes personnels en France Central et exige une reprise en région secondaire avec un RPO de quelques minutes. Que proposer, et quel test éviter ?

Azure Site Recovery (Azure to Azure) vers la région appariée, le host pool restant unique ; dépendances (réseau, AD DS, DNS, quotas) prêtes en région B ; failover et failback VM par VM. Ne pas utiliser le test failover : tester en démarrant des hosts secondaires avec un groupe de test.

9. Un éditeur a deux host pools pooled en West Europe et North Europe et veut qu'un utilisateur retrouve son profil où qu'il se connecte après une panne régionale. Les profils sont sur Azure Files Premium. Quelle solution pour les profils ?

FSLogix Cloud Cache avec CCDLocations vers un partage dans chaque région (active-active ou primary / failover). Le GRS n'est pas disponible pour Azure Files Premium. Séparer Profile et Office container, Office container non répliqué.

10. Le RSSI demande une stratégie de sauvegarde AVD : profils sur Azure Files Premium, 50 postes personnels, 400 hosts pooled. Que sauvegarder ?

Azure Backup du partage des profils (vault dans la même région et le même abonnement, sauvegarde hors des heures d'ouverture de session, restauration item-level d'un VHDX) ; Azure VM backup des 50 postes personnels ; pas de sauvegarde des hosts pooled (sans état), mais des versions d'image dans la Compute Gallery avec replicas et le pipeline d'image dans Git.

11. Après une restauration d'un poste personnel avec Create new VM, l'utilisateur ne voit plus son bureau. Que vérifier ?

Que la nouvelle VM est enregistrée dans le host pool (agent AVD, WVDHostRegistrations) et que l'utilisateur lui est affecté ; l'ancienne VM peut encore figurer comme session host indisponible.

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

• Azure Monitor Baseline Alerts (AMBA) propose des alertes AVD prêtes à déployer (Policy initiative) pour démarrer vite.
• Cost Management : étiqueter les VM par host pool et suivre l'effet du scaling plan semaine après semaine.
• Capacity reservations dans la région de reprise pour garantir le démarrage des VM lors d'un incident régional.
• Le centre d'architecture (Multiregion BCDR for Azure Virtual Desktop) détaille les procédures de failover et de failback pour chaque modèle.
• Les mêmes requêtes KQL peuvent alimenter Microsoft Sentinel (connexions anormales, voir SC-500 chapitre 11).

15. Fiche à retenir#

• Deux flux : diagnostic settings (host pool, app group, workspace → tables WVD) + AMA et DCR sur les hosts (Perf, Event).
• Connexions : Started → Connected → Completed ; ServiceError = true = ticket Microsoft avec le CorrelationId.
• Insights : aka.ms/avdi, configuration workbook, workspace dédié, ~15 min de délai, 1 000 hosts en automatique, Desktop Virtualization Reader + Log Analytics Reader.
• Workbook : Save As puis éditer ; la copie ne reçoit plus les mises à jour.
• Load balancing : breadth-first (expérience) / depth-first (coût, exige le max session limit, 999999 par défaut).
• Dimensionnement multi-session : Light 6, Medium 4, Heavy 2, Power 1 utilisateurs par vCPU ; VM de 4 à 24 vCPU.
• Autoscale : rôle Power On Off Contributor (identité du host pool ou service principal AVD, abonnement), un plan par host pool, même région, fuseau du plan, pas d'autre outil.
• Pooled : 4 phases, capacity threshold et minimum % hosts ; démarre dans toute phase, n'arrête jamais en ramp-up ; force logoff en ramp-down seulement ; exclusion tag car autoscale écrase le drain mode.
• Personal : Start VM on Connect, VMs to start, actions après déconnexion / fermeture (0 à 360 min), jamais de force logoff ; Hibernate incompatible FSLogix et App Attach.
• Dynamic autoscaling = préversion, pooled avec session host configuration, crée et supprime des hosts.
• Sessions : drain mode (Allow new sessions = No), message, disconnect, log off ; rôles User Session Operator et Session Host Operator.
• Mises à jour : pooled = image + session host update (initial puis batches, 0 à 60 min de notification, ~20 min par host, autoscale désactivé) ; personal = WUfB / Autopatch / ConfigMgr / Update Manager.
• Agent : Scheduled Agent Updates, 2 fenêtres de 2 h, désactivé par défaut, critiques imposées, événement 3277.
• Reprise : personal = Site Recovery (host pool unique, pas de test failover) ; pooled = second host pool (hot standby ou actif) ; zones 99,99 %.
• Multi-région : active-passive à privilégier ; active-active = pooled seulement, Cloud Cache active / active ; dépendances et quotas en région B.
• Profils : Cloud Cache (4 emplacements max), pas de GRS en Premium ni avec large file shares, séparer Profile et Office container.
• Sauvegarde : Azure Files (vault même région et abonnement, Snapshot ou Vault-Standard, item-level), ANF snapshots, Azure VM backup des personnels, pas des pooled, images N-1 et replicas.

Références#

Toutes lues le 22/10/2026 :

• Study guide for Exam AZ-140
• Send diagnostic data to Log Analytics for Azure Virtual Desktop
• Log Analytics tables for microsoft.desktopvirtualization/hostpools
• Enable Insights to monitor Azure Virtual Desktop
• Use cases for Azure Virtual Desktop Insights
• Azure Virtual Desktop Insights glossary
• Azure Workbooks overview
• Create service health alerts
• Configure host pool load balancing
• Session host virtual machine sizing guidelines
• Autoscale scaling plans and example scenarios
• Create and assign an autoscale scaling plan (power management)
• Autoscale glossary et Autoscale FAQ
• Monitor Autoscale operations with Insights
• Assign Azure RBAC roles or Microsoft Entra roles to a service principal
• Built-in Azure RBAC roles for Azure Virtual Desktop
• Start VM on Connect
• Drain mode
• Terraform azurerm_virtual_desktop_scaling_plan
• Session host update for Azure Virtual Desktop
• Scheduled Agent Updates
• Azure Update Manager overview
• Azure Virtual Desktop disaster recovery concepts
• Business continuity and disaster recovery considerations for Azure Virtual Desktop
• Multiregion BCDR for Azure Virtual Desktop
• FSLogix container recovery and business continuity
• Storage options for FSLogix profile containers
• About Azure Files backup et Back up Azure Files
• About Azure VM backup
• Azure Site Recovery: Azure to Azure disaster recovery architecture