Microsoft AZ-140: Architecture et conception du service Azure Virtual Desktop — Guide d'étude

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Virtual Desktop Specialty AZ-140 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Azure Virtual Desktop (AVD) est un service de virtualisation de bureaux et d’applications géré par Microsoft qui sépare le plan de contrôle du service de votre plan de données spécifique au locataire. Le service négocie les connexions sécurisées, tandis que vous possédez et exploitez les machines virtuelles hôtes de session, l’identité, le stockage et les réseaux. La conception d’une architecture efficace implique de mapper l’expérience utilisateur, l’identité, la livraison d’applications, la capacité, la résilience et le contrôle des coûts dans un modèle de déploiement cohérent qui peut être validé et déployé par étapes sans perturber les utilisateurs.

Architecture du service : Plan de contrôle vs Plan de données

• Plan de contrôle (géré par Microsoft) :

  • Les services Web Access, Gateway et Broker authentifient les utilisateurs, énumèrent les ressources et orchestrent les sessions à connexion inversée sur TLS 443. Ils sont distribués mondialement et mis à jour par Microsoft.
  • Les services Diagnostics et Insights collectent la télémétrie des connexions, l’état de santé et le statut de l’agent.
  • Les API de gestion basées sur ARM définissent les pools d’hôtes, les groupes d’applications et les espaces de travail, y compris les plans de mise à l’échelle et « Start VM on Connect ».

• Plan de données (géré par le client) :

  • Les hôtes de session (Windows 10/11 Entreprise multi-session ou mono-session) dans vos abonnements et VNets.
  • L’identité et la résolution de noms via AD DS, Azure AD DS ou Entra ID avec le mode de jonction approprié. Les hôtes de session doivent pouvoir résoudre les services de domaine ; configurez le DNS du VNet sur les contrôleurs de domaine ou les adresses IP d’Azure AD DS plutôt que sur un DNS public.
  • L’état et le cache utilisateur (conteneurs de profil et Office FSLogix) sur Azure Files Premium ou Azure NetApp Files (ANF), ou moins couramment sur des serveurs de fichiers IaaS ou Storage Spaces Direct (S2D).
  • Le réseau (VNets, peering, VPN/ExpressRoute, NSG, UDR, sortie), avec QoS et orientation du chemin pour minimiser la latence et la gigue sur UDP/TCP 443.
  • La gestion des images avec Azure Compute Gallery et Azure Image Builder, et les contrôles opérationnels tels que la mise à l’échelle automatique et les fenêtres de maintenance.

Le trafic du plan de contrôle est sortant depuis les hôtes de session ; aucun point de terminaison public entrant n’est requis sur les VM hôtes. Cela réduit la surface d’exposition et simplifie les règles de pare-feu.

Concepts de base et livraison d’applications

• Pool d’hôtes : Un ensemble logique d’hôtes de session avec un emplacement de ressource défini (région des métadonnées), une politique d’équilibrage de charge et un mode d’affectation (groupé ou personnel). Un pool d’hôtes contient par défaut un groupe d’applications de type Bureau et peut avoir plusieurs groupes RemoteApp.

• Groupe d’applications (app group) :

  • Bureau : Présente un bureau Windows complet à partir du pool. Un seul groupe d’applications de type Bureau est autorisé par pool d’hôtes.
  • RemoteApp : Publie des applications individuelles. Vous pouvez créer plusieurs groupes RemoteApp par pool.
  • Un utilisateur ne doit pas être affecté à la fois au groupe Bureau et à un groupe RemoteApp du même pool d’hôtes. Utilisez des pools distincts pour éviter les conflits d’expérience entre applications et bureaux.
  • Un groupe d’applications est associé à exactement un espace de travail. L’espace de travail et le groupe d’applications doivent partager le même emplacement de ressource AVD.

• Espace de travail : Le conteneur destiné à l’utilisateur qui agrège les groupes d’applications de plusieurs pools dans des flux de ressources pour les clients AVD. Le RBAC sur les groupes d’applications contrôle qui voit quelles applications/bureaux. Maintenez les emplacements des métadonnées alignés lors de l’enregistrement des groupes d’applications dans les espaces de travail.

• Stratégie d’image : Pour les pools groupés multi-session, utilisez les images de la marketplace Windows 10/11 Entreprise multi-session ou une image personnalisée généralisée dans une Azure Compute Gallery. Pour les pools personnels, utilisez les images Windows 10/11 Entreprise mono-session. Généralisez toujours les VM sources avant de capturer les images pour supprimer l’état spécifique à l’utilisateur et à la machine.

Types de pools d’hôtes, affectation, mises à jour et gestion de l’alimentation

• Pools d’hôtes groupés vs personnels :

  • Groupé : Plusieurs utilisateurs simultanés par VM. Optimisez pour la densité et le coût avec un équilibrage de charge en largeur d’abord (Breadth-first) ou en profondeur d’abord (Depth-first). Utilisez FSLogix pour les profils.
  • Personnel : Un utilisateur par VM avec un état dédié. Méthodes d’affectation :
    • Automatique : La première connexion lie de manière permanente un utilisateur à une VM non affectée.
    • Directe : L’administrateur mappe les utilisateurs à des hôtes de session spécifiques.

• Pools de validation vs de production :

  • L’indicateur de pool de validation inscrit le pool dans les anneaux (rings) de pré-version de l’agent AVD. Utilisez un petit pool de validation par image/région pour tester les mises à jour de l’agent AVD, de l’OS et des applications avec des utilisateurs pilotes.
  • Modèle de déploiement par étapes :
    1. Valider l’image et l’agent dans un pool de dev/test.
    2. Piloter dans un pool de validation avec un sous-ensemble d’utilisateurs.
    3. Étendre progressivement aux pools de production, région par région.
    4. Drainer et appliquer les correctifs aux hôtes de manière incrémentielle pour éviter les temps d’arrêt.

• Autoscale et Start VM on Connect :

  • Autoscale (plans de mise à l’échelle) planifie la capacité, applique des seuils de session, draine les hôtes inactifs et désalloue les VM pour minimiser les coûts tout en préservant l’expérience utilisateur.
  • Start VM on Connect met sous tension les VM désallouées lorsqu’un utilisateur tente de se connecter. Exigences opérationnelles :
    • Activer une identité managée affectée par le système sur le pool d’hôtes et accorder le rôle Contributeur à la mise sous/hors tension de la virtualisation de bureau sur le groupe de ressources des hôtes de session ou les VM.
    • Les VM doivent être désallouées pour économiser les coûts de calcul ; une VM « arrêtée » mais allouée continue de générer des frais et n’offre aucun avantage de démarrage à froid.
    • Fonctionne avec les pools groupés et personnels ; le démarrage à froid ajoute plusieurs minutes de délai de connexion.
    • Seules les connexions initiées par le client via AVD s’appliquent ; le RDP direct n’est pas pris en charge.
    • Coordonner avec Autoscale pour s’assurer qu’un nombre minimum d’hôtes est préchauffé pour les périodes de pointe.

Équilibrage de charge, planification de la capacité, enregistrement et santé

• Algorithmes d’équilibrage de charge :

  • En largeur d’abord (Breadth-first) : Répartit les sessions de manière uniforme sur les hôtes disponibles. Idéal pour des performances constantes et une marge de manœuvre mémoire.
  • En profondeur d’abord (Depth-first) : Remplit un hôte jusqu’à sa limite maximale de sessions avant de passer au suivant. Maximise les désallocations pour réduire les coûts, mais risque des effets de voisinage bruyant si les limites sont trop élevées.

• Limite maximale de sessions et densité d’utilisateurs :

  • Définissez une limite maximale de sessions par VM pour plafonner les sessions simultanées et protéger l’expérience utilisateur (UX), en particulier avec l’algorithme Depth-first.
  • Estimez la densité en évaluant les charges de travail cibles : le CPU limite souvent la densité multi-session. En règle générale :
    • Productivité légère : 6 à 10 sessions/vCPU sur des références (SKU) multi-sessions modernes et correctement optimisées.
    • Productivité moyenne : 4 à 6 sessions/vCPU.
    • Graphiques ou charges lourdes en données : 1 à 3 sessions/vCPU.
  • Planification de la capacité :
    • Hôtes requis = ceil((Utilisateurs × simultanéité) ÷ sessions-par-hôte).
    • Ajoutez une réserve N+1 ou une marge de manœuvre en pourcentage pour le basculement et les fenêtres de maintenance.
    • Réseau : Estimez 300–500 Kbps par session légère, 1–2 Mbps pour une session moyenne, 3–5+ Mbps pour une session lourde. Seuls les utilisateurs au bureau transitent en épingle à cheveux (hairpin) par l’accès Internet de l’entreprise ; les utilisateurs distants se connectent directement à AVD.
    • QoS : Priorisez UDP/TCP 443 vers les passerelles AVD ; une allocation insuffisante provoque des réponses lentes et des erreurs de connexion.

• Sélection du stockage FSLogix :

  • Azure NetApp Files fournit les IOPS les plus élevés et la latence la plus faible à l’échelle de l’entreprise (pour des dizaines de milliers d’utilisateurs) avec une surcharge de gestion minimale.
  • Azure Files Premium offre des partages SMB sur SSD avec une authentification basée sur AD ou Entra Kerberos, équilibrant performance et coût pour la plupart des déploiements.
  • Les alternatives IaaS (S2D SOFS) nécessitent au moins trois VM sans Cloud Witness et imposent une surcharge opérationnelle ; à n’utiliser que lorsque les options PaaS ne sont pas viables.

• Jetons d’enregistrement, enregistrement de l’hôte de session et santé de l’agent :

  • Avant d’ajouter des VM existantes à un pool d’hôtes, générez un jeton d’enregistrement. L’agent AVD et le chargeur de démarrage enregistrent la VM à l’aide de ce jeton ; ensuite, l’hôte est lié au pool et le jeton peut expirer.
  • Maintenez la santé de l’agent au vert en surveillant l’état du service, la version de la pile SxS et le signal de pulsation (heartbeat) via AVD Insights et Log Analytics. Mettez les hôtes en mode drainage pendant l’application des correctifs pour empêcher de nouvelles sessions.
  • Astuce de dépannage rapide : Au sein d’une session utilisateur, utilisez les compteurs RemoteFX Graphics (Frames Skipped/Second) du Moniteur de performance pour isoler les problèmes de rendu côté serveur, réseau ou client.

Exemple de PowerShell pour l’enregistrement et la santé :

# Generate a time-limited registration token
New-AzWvdRegistrationInfo `
  -ResourceGroupName 'rg-avd' `
  -HostPoolName 'hp-pooled' `
  -ExpirationTime (Get-Date).AddHours(8)

# Review host state, drain mode, and session counts
Get-AzWvdSessionHost `
  -ResourceGroupName 'rg-avd' `
  -HostPoolName 'hp-pooled' |
  Select-Object Name, Status, AllowNewSession, Sessions

• Considérations sur le DNS et la jonction au domaine :

  • Lors de l’utilisation d’Azure AD DS, configurez les serveurs DNS du VNet sur les adresses IP du domaine managé afin que les hôtes de session puissent localiser les contrôleurs de domaine pour l’enrôlement Windows et Kerberos/NTLM.
  • Pour AD DS en mode hybride, configurez chaque VNet hébergeant des hôtes de session pour utiliser les adresses IP des contrôleurs de domaine sur site (au moins deux pour la résilience). Assurez-vous que les redirecteurs conditionnels ou les résolveurs prennent en charge les points de terminaison privés Azure s’ils sont utilisés.

• Conception régionale et l’Estimateur d’expérience :

  • Choisissez les régions du pool d’hôtes en fonction de la latence aller-retour la plus faible depuis les emplacements des utilisateurs, mesurée avec l’Azure Virtual Desktop Experience Estimator. Effectuez des tests depuis les sous-réseaux réels des utilisateurs pendant les heures de pointe et les heures creuses.
  • Colocalisez le stockage FSLogix et les services de domaine avec les hôtes de session pour minimiser les allers-retours SMB. Évitez les montages de profil inter-régions.
  • Pour les déploiements multi-régions, alignez les emplacements des métadonnées entre le pool d’hôtes, les groupes d’applications et les espaces de travail ; utilisez des pools distincts par région pour l’autonomie et le basculement échelonné.

Scénario de problème pratique

Siemens AG doit fournir des charges de travail de CAO et de productivité à des ingénieurs à Munich, Chicago et Singapour tout en minimisant les coûts et en garantissant des performances élevées.

1. Cartographier les cohortes d’utilisateurs, les charges de travail et les régions

• Identifier trois cohortes : CAO intensive (GPU requis), productivité standard et sous-traitants avec des besoins purement applicatifs. Mesurer la latence depuis chaque site avec l’AVD Experience Estimator.
• Pourquoi : Les pools basés sur des cohortes préviennent les effets de voisinage bruyant et permettent d’utiliser des familles de VM de taille appropriée et un comportement de mise à l’échelle adapté à chaque charge de travail. Les mesures de latence guident le placement régional.

2. Concevoir les pools d’hôtes régionaux et la livraison d’applications

• Créer trois pools d’hôtes régionaux par cohorte en Europe de l’Ouest, Est des États-Unis et Asie du Sud-Est. Utiliser :
  • Des GPU NVadsA10 v5 pour la CAO (en pool, Breadth-first, limite maximale de sessions plus basse).
  • Des séries D/E pour la productivité (en pool, Depth-first pour maximiser les désallocations en heures creuses).
  • Des pools RemoteApp uniquement pour les sous-traitants publiant des applications spécifiques.
• Enregistrer les groupes d’applications RemoteApp et de bureau dans des espaces de travail régionaux correspondant à l’emplacement des ressources de chaque pool.
• Pourquoi : La ségrégation des pools par charge de travail et par région optimise les performances et les coûts tout en maintenant des habilitations applicatives claires.

3. Mettre en œuvre l’identité et le DNS

• Pour l’UE et les États-Unis, effectuer une jonction de domaine à un AD DS sur site synchronisé avec Entra ID. Configurer le DNS personnalisé de chaque VNet pour pointer vers deux contrôleurs de domaine régionaux pour la résilience. À Singapour, déployer Azure AD DS et configurer le DNS du VNet sur les adresses IP du domaine managé pour éviter la dépendance au WAN.
• Pourquoi : Des contrôleurs de domaine locaux et une configuration DNS de VNet correcte garantissent une résolution Kerberos fiable et des ouvertures de session rapides ; Azure AD DS réduit la charge opérationnelle là où un AD sur site n’est pas présent.

4. Optimiser l’état utilisateur et le stockage

• Utiliser Azure NetApp Files pour les cohortes de CAO et de productivité à haute simultanéité ; utiliser Azure Files Premium pour les sous-traitants. Placer le stockage dans la même région que les pools d’hôtes et activer les conteneurs de profil FSLogix avec Cloud Cache pour les utilisateurs de CAO qui se déplacent entre deux bureaux proches.
• Pourquoi : ANF offre la latence la plus faible et les IOPS les plus élevés pour les charges de travail lourdes ; Azure Files Premium réduit les coûts pour les utilisateurs plus légers. La colocalisation évite la latence SMB inter-régions.

5. Capacité, mise à l’échelle automatique et Start VM on Connect

• Établir des cibles de densité à partir de tests pilotes (par ex., CAO 1–2 sessions/vCPU, productivité 4–6 sessions/vCPU). Configurer des plans de mise à l’échelle automatique avec une montée en charge en journée et un drainage/désallocation en dehors des heures de travail. Activer Start VM on Connect avec une identité managée affectée par le système sur chaque pool d’hôtes et accorder le rôle Desktop Virtualization Power On Off Contributor sur les groupes de ressources des hôtes de session.
• Pourquoi : La mise à l’échelle automatique et Start VM on Connect minimisent les dépenses de calcul tout en préservant l’expérience utilisateur ; l’identité et l’attribution de rôle permettent au service de démarrer les VM de manière fiable.

6. Déploiement échelonné et validation

• Marquer un petit pool d’hôtes de validation par région pour recevoir les mises à jour de l’agent en avance. Cadence de correctifs : validation → pilote → production. Utiliser le mode drainage pendant l’application des correctifs et appliquer des limites maximales de sessions adaptées à chaque charge de travail et algorithme.
• Pourquoi : Des anneaux de déploiement contrôlés évitent les régressions à l’échelle du service ; le mode drainage maintient les sessions pendant la maintenance des hôtes.

7. Réglage du réseau et de la QoS

• S’assurer que les routeurs des succursales priorisent UDP/TCP 443 vers les points de terminaison AVD avec des allocations de bande passante suffisantes. Supprimer tout trafic en épingle à cheveux (hairpin) via VPN pour les utilisateurs distants afin que les utilisateurs à domicile se connectent directement à AVD.
• Pourquoi : Les flux multimédias d’AVD dépendent du port 443 ; une QoS sous-provisionnée provoque des réponses lentes et des coupures de connexion.

En alignant les types de pools, les groupes d’applications, l’identité, le stockage, la mise à l’échelle et le placement régional sur les cohortes et les zones géographiques de Siemens, la conception atteint des performances prévisibles, une sécurité opérationnelle grâce aux anneaux de validation, et une efficacité des coûts via une gestion intelligente de l’alimentation et des contrôles de densité.

Tous les domaines · Identité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →