Microsoft AZ-140: Résilience, récupération et migration — 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

La planification de la résilience, de la récupération et de la migration pour Azure Virtual Desktop (AVD) vise à maintenir la productivité des utilisateurs en cas de pannes régionales, à protéger les données (profils, images, applications), à orchestrer le basculement des dépendances et à assurer une transition prévisible depuis les services Bureau à distance (RDS) traditionnels. Les conceptions efficaces séparent le plan de contrôle AVD sans état (stateless) des plans de données avec état (stateful), utilisent une automatisation reproductible pour les reconstructions, définissent des objectifs de récupération clairs pour chaque composant et valident les performances réelles par la découverte et la modélisation de la capacité.

Architecture régionale, accès utilisateur et basculement

Plans de contrôle et de données : Les services de broker, d’accès web, de diagnostic et de gestion d’AVD sont résilients au niveau mondial. Les hôtes de session, les pools d’hôtes, les images et le stockage sont spécifiques à une région et doivent être conçus pour le basculement.
Stratégie en cas de panne régionale :
- Créez un pool d’hôtes dans une région secondaire par cohorte d’utilisateurs avec la même famille de tailles de VM et la même lignée d’images. Répliquez les images vers la région secondaire à l’aide d’Azure Compute Gallery.
- Publiez des groupes d’applications identiques (RemoteApp et/ou Bureau) dans les deux régions et assignez les utilisateurs aux deux, en définissant le pool principal comme pool par défaut et le secondaire comme cible de reprise d’activité (DR).
- Maintenez les hôtes de DR dans un état de veille froide (cold) ou tiède (warm). Pour les hôtes en pool, effectuez un scale-in à zéro ou mettez-les hors tension, puis appuyez-vous sur les plans de mise à l’échelle et la fonctionnalité Start VM on Connect pour minimiser les coûts en régime permanent.
Accès des utilisateurs pendant les pannes :
- Le service AVD achemine les demandes de connexion vers des hôtes de session sains. Lorsque vous placez le pool d’hôtes principal en mode drainage (drain mode) ou qu’il est indisponible, les nouvelles connexions sont négociées vers le pool secondaire si les utilisateurs y ont des affectations.
- Informez les utilisateurs que les sessions ouvertes dans la région défaillante seront déconnectées ; la reconnexion s’effectuera sur la région disponible.
Parité des images et des applications MSIX app attach :
- Utilisez Azure Image Builder et Azure Compute Gallery (SIG) avec la réplication régionale pour les images.
- Stockez les paquets MSIX app attach dans des emplacements de stockage résilients qui sont accessibles depuis les deux régions et répliquez le contenu vers la région secondaire (par ex., la réplication inter-régions d’ANF ou la réplication de compte de stockage).
Dépendances réseau et d’identité :
- Assurez-vous que le DNS et l’identité (Active Directory ou Azure AD DS) sont joignables depuis les deux régions. Pour Azure AD DS, configurez les paramètres DNS du VNet sur les adresses IP du domaine managé dans chaque VNet régionalisé qui nécessite une jonction au domaine et une résolution de noms.
- Validez le comportement de RDP Shortpath entre les régions ; basculez sur la connexion inversée (reverse connect) si l’UDP est bloqué.

Exemple pour répliquer une version d’image dans deux régions :

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

Objectifs de récupération et rôles de protection des données

Définissez des RTO/RPO distincts par composant :

Pools d’hôtes et hôtes de session :
- En pool : Traitez les hôtes de session comme éphémères. Le RTO est de quelques minutes (redéploiement automatisé), le RPO est N/A (pas d’état sur l’hôte). Ne vous fiez pas aux sauvegardes de VM pour la récupération ; redéployez à partir de l’image et utilisez l’autoscaling.
- Personnel : Si l’état de l’utilisateur réside sur le disque du système d’exploitation, protégez-le avec Azure Backup ou Azure Site Recovery (ASR). Préférez déporter l’état utilisateur vers des profils FSLogix pour simplifier la reprise d’activité (DR).
Images :
- RPO quasi nul pour la disponibilité des images grâce à la réplication de Compute Gallery ; RTO en minutes pour déployer de nouveaux hôtes. Maintenez les pipelines d’images de référence (golden images) versionnés et reproductibles.
Profils et caches Office (FSLogix) :
- RPO : de quelques minutes à quelques heures selon les planifications de réplication et de sauvegarde ; RTO : quelques minutes pour monter dans la région secondaire si Cloud Cache est configuré, sinon le temps de restaurer le volume/partage et de rediriger les sessions.
Applications :
- Pour les applications intégrées à l’image, alignez-vous sur les RTO/RPO de l’image. Pour MSIX app attach, alignez-vous sur la réplication du stockage des paquets et le temps de réenregistrement.

Azure Backup et ASR :

Azure Backup :
- Sauvegardez les partages Azure Files qui hébergent les conteneurs de profil FSLogix et ODFC. Utilisez des instantanés (snapshots) fréquents pour atteindre les objectifs de RPO ; restaurez un VHD/VHDX individuel ou un partage complet. Communiquez que les instantanés sont cohérents en cas de plantage (crash-consistent) pendant que les utilisateurs sont connectés ; pour des restaurations de précision, effectuez une copie/renommage hors bande du conteneur d’un utilisateur et demandez à l’utilisateur de se reconnecter.
- Sauvegardez les disques OS des bureaux personnels lorsque c’est nécessaire. Les hôtes en pool ne nécessitent généralement pas de sauvegardes de VM.
Azure Site Recovery :
- Utilisez ASR pour les composants d’infrastructure avec état (stateful) qui sont critiques pour AVD (par ex., serveurs de gestion, serveurs de licences le cas échéant, serveurs LOB) et pour les pools d’hôtes personnels lorsque la préservation de l’état de la VM est requise.
- Évitez ASR pour les hôtes AVD en pool ; le redéploiement à partir de l’image/des plans de mise à l’échelle est plus rapide et moins coûteux.

Résilience du stockage des profils, Cloud Cache, sauvegarde et restauration

Options de stockage pour FSLogix :
- Azure NetApp Files (ANF) : IOPS les plus élevés/latence la plus faible à grande échelle ; prend en charge la réplication inter-régions pour la reprise d’activité (DR). Idéal pour les parcs très importants ou les fortes demandes de simultanéité et d’E/S de profil.
- Azure Files Premium : Partages de fichiers PaaS sur SSD avec ZRS pour la résilience intra-régionale ; excellent équilibre entre performance et administration. Pour la DR inter-régions, combinez avec Cloud Cache et la sauvegarde/restauration au niveau du partage ou concevez des partages bi-régionaux.
- Storage Spaces Direct (S2D) sur IaaS : À n’utiliser que si le PaaS n’est pas une option viable. Nécessite un minimum de trois VM sans témoin cloud (Cloud Witness) pour le quorum. La charge opérationnelle est plus élevée que pour les alternatives PaaS.
Cloud Cache :
- Configurez plusieurs fournisseurs (par ex., deux points de terminaison Azure Files ou ANF dans des zones/régions différentes). Lors d’une panne régionale, FSLogix continue de fonctionner avec les fournisseurs survivants, avec une cohérence à terme (eventual consistency) pour les écritures mises en cache.
- Exemple de configuration :

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

Modèles de sauvegarde et de restauration :
- Mettez en œuvre des instantanés Azure Backup toutes les heures ou toutes les quelques heures pour les partages de profils. Pour un profil utilisateur corrompu, isolez le VHDX actuel, restaurez l’instantané précédent vers un autre emplacement, puis copiez ou rattachez le conteneur de l’utilisateur.
- Pour ANF, utilisez les instantanés et la réplication inter-régions ; restaurez au niveau du volume ou un fichier unique via le répertoire des instantanés.
Tests :
- Incluez la validation du montage/rattachement, les simulations de corruption et la restauration au niveau de l’utilisateur dans les exercices de reprise d’activité (DR).

Trafic, DNS et basculement des dépendances

Dépendances applicatives :
- De nombreuses applications AVD dépendent d’API HTTP/S, de front-ends web ou de bases de données. Concevez-les avec un équilibrage de charge global et des déploiements régionaux afin que le basculement des dépendances ne bloque pas les utilisateurs dans des sessions par ailleurs saines.
Azure Front Door et Traffic Manager :
- Utilisez Azure Front Door pour l’équilibrage de charge global de couche 7 HTTP/S, le WAF et le routage basé sur le chemin des dépendances applicatives utilisées par les utilisateurs AVD. Associez-le à des backends redondants entre les zones dans chaque région.
- Utilisez Azure Traffic Manager pour l’équilibrage de charge basé sur le DNS pour les points de terminaison non-HTTP qui sont publics et prennent en charge les sondes d’intégrité.
DNS privé et résolution de noms :
- Centralisez les redirecteurs conditionnels à l’aide d’Azure DNS Private Resolver pour router les requêtes entre les environnements sur site, les réseaux virtuels Azure et les domaines gérés. Publiez des enregistrements avec un TTL faible pour les points de terminaison qui pourraient nécessiter un basculement rapide.
- Pour les points de terminaison de stockage qui ne peuvent pas basculer nativement de manière transparente, envisagez des points de terminaison à double nom, abstraits derrière un DNS interne, pour basculer entre les partages principaux et de reprise d’activité (DR) lors d’un incident.
QoS réseau et accès :
- Donnez la priorité au trafic AVD en temps réel (UDP/TCP) sur les réseaux WAN ; ajustez la QoS sur les routeurs de succursale pour garantir que les classes de trafic AVD disposent d’une bande passante suffisante afin de réduire les erreurs de connexion et la latence.
- Validez l’accessibilité de Shortpath et les ouvertures de ports dans le pare-feu ; assurez-vous que la planification de la bande passante de sortie correspond à la simultanéité et à la combinaison des charges de travail.

Migration depuis RDS, découverte, densité et capacité

Évaluation de RDS :
- Inventoriez les Connection Brokers, les RD Gateways, RD Web, les RD Session Hosts, RD Licensing et les serveurs de fichiers/magasins de profils. Documentez les GPO, la configuration de FSLogix et les méthodes de livraison des applications.
- Faites correspondre les rôles aux constructions AVD : pools d’hôtes, espaces de travail, groupes d’applications, stockage de profils et courtage géré par AVD ; éliminez le besoin de RD Gateway et de Broker dans Azure.
Azure Migrate et découverte :
- Utilisez l’appliance Azure Migrate pour découvrir les VM RDS existantes, les bases de référence de performance et les dépendances. Identifiez les relations application-serveur pour le placement des hôtes de session AVD et la gravité des données.
Analyse de la densité d’utilisateurs :
- Élaborez des modèles de densité par charge de travail (utilisateurs de tâches/de connaissance/avancés). Déduisez le nombre de sessions par VM en utilisant les bases de référence de CPU ready, de pression mémoire et d’E/S de profil. Validez avec des benchmarks pilotes sur des références (SKU) de VM candidates (par ex., Dv5/Esv5/Dasv5, avec GPU pour les graphiques).
- Utilisez l’Azure Virtual Desktop Experience Estimator pour sélectionner les régions offrant la plus faible latence entre l’utilisateur et l’hôte.
Modélisation de la capacité :
- Convertissez la densité en nombre d’hôtes par pool avec un tampon N+1 et une marge pour la maintenance. Définissez les seuils de scale-out et le nombre minimum/maximum d’hôtes dans les plans de mise à l’échelle. Envisagez les réservations de capacité pour un coût prévisible et des cœurs garantis dans les régions très sollicitées.
- Assurez-vous que les quotas d’abonnement et régionaux (vCPU, cœurs par famille, adresses IP, cartes réseau, disques) sont augmentés à l’avance ; soumettez les demandes d’augmentation de quota le plus tôt possible.

Basculement, coexistence, quotas et runbooks

Planification du basculement :
- Exécuter une coexistence en parallèle : maintenir RDS opérationnel pendant que AVD intègre les pilotes. Publier les mêmes applications dans les deux systèmes, mais orienter les utilisateurs par cohorte.
- Cohortes pilotes : commencer par l’équipe informatique et les adopteurs précoces, étendre aux départements représentatifs, puis procéder à un déploiement général. Utiliser les retours pour affiner les images, les paramètres FSLogix et la mise à l’échelle.
- Retour arrière : maintenir les chemins d’accès RDS jusqu’à ce que les critères d’acceptation soient remplis. Garder les profils utilisateur rétrocompatibles ou fournir un chemin de réinitialisation de profil par cohorte.
Préparation opérationnelle :
- Clés d’enregistrement : lors de l’intégration de machines virtuelles existantes dans des pools d’hôtes, générer une clé d’enregistrement et les joindre via l’agent AVD ; automatiser via Azure Image Builder et des scripts de post-provisionnement.
- Hygiène des espaces de travail et des groupes d’applications : publier des groupes d’applications selon le principe du moindre privilège ; séparer Desktop et RemoteApp ; conserver les groupes d’applications de reprise d’activité (DR) assignés mais visuellement moins mis en avant si nécessaire.
Runbooks et automatisation :
- Créer des runbooks de continuité d’activité et de reprise après sinistre (BCDR) qui couvrent :
  - La déclaration de l’incident et la mise en mode drainage des pools principaux.
  - La mise à l’échelle des pools de reprise d’activité (DR) et la vérification de la parité des images.
  - Le basculement du stockage des profils via Cloud Cache ou une redirection DNS.
  - La validation des dépendances applicatives critiques via Front Door/Traffic Manager.
  - La communication aux utilisateurs et au centre de services.
  - Le retour en arrière lorsque la région principale est restaurée.
- Implémenter les runbooks à l’aide d’Azure Automation ou de Functions avec des contrôles d’accès basés sur les rôles et des approbations de changement.
Coûts et réservations :
- Utiliser les Savings Plans et les Capacity Reservations pour les charges de travail de base stables ; conserver la capacité de débordement en paiement à l’utilisation (pay-as-you-go) avec la mise à l’échelle automatique. Planifier l’arrêt des pools de non-production en dehors des heures de bureau.

Scénario de problème pratique

Adobe doit s’assurer que les équipes de création et de support peuvent travailler en continu pendant une panne régionale lors de la migration d’une ferme RDS sur site vers Azure Virtual Desktop, avec des centaines de téraoctets de profils itinérants et des charges de travail graphiques exigeantes.

Découverte et établissement de la ligne de base

Utiliser Azure Migrate pour inventorier les hôtes RDS, les partages de profils et les dépendances des applications métier (LOB), et pour capturer les modèles de CPU/mémoire/IO pour les cohortes graphiques et de support.
Pourquoi : Les lignes de base empiriques permettent de définir des cibles de densité d’utilisateurs et une sélection de SKU de VM précises, minimisant ainsi le surprovisionnement.

Concevoir l’architecture régionale

Créer des pools d’hôtes principaux dans West US 2 avec des NVadsA v5 compatibles GPU pour les créatifs et des Dv5 pour le support ; déployer des pools secondaires dans Central US.
Répliquer les images via Azure Compute Gallery ; stocker les paquets MSIX dans ANF avec la réplication inter-régions.
Pourquoi : Assure la parité des ressources de calcul et des applications entre les régions avec des performances prévisibles.

Renforcer l’identité et le DNS

Configurer le DNS du VNet sur les adresses IP d’Azure AD DS où les hôtes de session rejoindront le domaine ; déployer Azure DNS Private Resolver pour transférer les requêtes entre l’environnement sur site et Azure.
Pourquoi : Une résolution de noms fiable entre les régions permet la connexion et l’accès aux applications pendant un basculement.

Implémenter des profils résilients

Utiliser Azure NetApp Files pour FSLogix avec des snapshots et une réplication inter-régions ; activer FSLogix Cloud Cache en le pointant vers les volumes ANF principaux et de reprise d’activité (DR).
Pourquoi : ANF fournit les IOPS/latence requis par les créatifs ; Cloud Cache et la réplication inter-régions (CRR) assurent la continuité en cas de défaillance d’une région.

Orchestrer le basculement des dépendances

Exposer les API web des applications métier (LOB) avec Azure Front Door et configurer des backends déployés régionalement ; utiliser Traffic Manager pour tous les points de terminaison publics non-HTTP.
Pourquoi : Maintient les points de terminaison des applications accessibles depuis n’importe quelle région AVD sans reconfiguration.

Établir les objectifs de récupération et la protection

Définir un RTO de quelques minutes pour les hôtes en pool (reconstruction), de quelques heures pour les bureaux personnels (le cas échéant, protégés par Azure Backup/ASR), et un RPO de 15 minutes pour les profils via les snapshots ANF ; sauvegarder les partages Azure Files de la cohorte de support s’ils sont utilisés.
Pourquoi : Des objectifs spécifiques à chaque composant alignent les coûts sur l’impact métier.

Piloter et coexister

Intégrer 100 utilisateurs du support et 50 créatifs sur AVD ; maintenir RDS publié en parallèle. Valider la densité, la stabilité des profils et les performances des applications. Itérer sur les politiques de mise à l’échelle et les paramètres FSLogix.
Pourquoi : Les pilotes contrôlés réduisent les risques liés aux choix d’image, de stockage et de mise à l’échelle automatique.

Basculement et exercice de reprise d’activité

Générer des clés d’enregistrement AVD pour étendre les pools ; assigner les groupes d’applications de reprise d’activité (DR) à tous les utilisateurs. Exécuter un exercice de reprise d’activité : drainer le pool principal, mettre à l’échelle le pool de DR, valider la continuité de Cloud Cache et basculer les dépendances applicatives via Front Door.
Pourquoi : Prouve la capacité de basculement de bout en bout, y compris les profils et les dépendances, avant la migration complète.

Quotas, réservations et automatisation

Augmenter au préalable les quotas régionaux de vCPU et de GPU ; acheter des Capacity Reservations pour les ressources GPU et CPU de base ; implémenter des runbooks Azure Automation pour le drainage, la mise à l’échelle, le basculement du stockage et les communications.
Pourquoi : Garantit la capacité pendant les incidents et supprime les étapes manuelles lors d’événements stressants.

Migration complète et plan de retour arrière

Migrer les cohortes restantes par vagues sur deux semaines ; maintenir l’accès RDS comme chemin de retour arrière avec des points de décision clairs pour chaque vague.
Pourquoi : Un basculement progressif réduit les risques et préserve une solution de repli immédiate en cas de problèmes inattendus.

← Surveillance · Tous les domaines

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