Étiquette : Vm

FSLogix pour Entra ID !

Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.

Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.

Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.

Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.

Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :

Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.

Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :

Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.

Microsoft Techcommunity

Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :

Qu’est-ce qu’une identité cloud-only ?

Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.

Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?

Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».

Que change concrètement pour un architecte cloud ou un administrateur ?

Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.

Plusieurs vidéos sont également disponible pour vous aider à la tâche :

Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :

Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.

L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.

Etape I – Préparation de l’environnement :

Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :

Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :

Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :

Activation de l’identité Microsoft Entra directement sur le compte de stockage :

Activation du support Microsoft Entra Kerberos pour gérer l’authentification :

Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :

Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :

Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :

Attribution du consentement administrateur global pour autoriser l’application

Validation de l’autorisation accordée à l’application d’entreprise :

Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :

Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :

Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :

Activation du Single Sign-On directement dans les propriétés RDP :

Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

Confirmation que la clé de registre est bien apparue :

Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Vérification de la création de la clé de registre attendue dans Windows :

Application de la configuration complète FSLogix via les différentes clés de registre :

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f

Vérification de la création des clés de registre attendues pour FSLogix :

Alternative via Intune pour gérer ces mêmes paramètres sans script :

Redémarrage des machines virtuelles du host pool pour appliquer la configuration :

Etape II – Test de connexion AVD :

Attente du retour en ligne des machines dans l’environnement AVD :

Activation du mode de drainage sur la seconde machine pour préparer les tests :

Connexion avec l’utilisateur de test pour valider le fonctionnement :

Observation du démarrage du service FSLogix App Services à l’ouverture de session :

Création du dossier de profil FSLogix directement dans le file share :

Présence du fichier VHDx correspondant au profil utilisateur :

Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :

Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :

Inversion du mode de drainage sur les deux machines AVD :

Reconnexion avec l’utilisateur de test pour valider la bascule du profil :

Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :

Vérification que la permission générée pour l’utilisateur de test est bien présente :

Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.

Etape III – Configurations des permissions NTFS Access Control Lists :

Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :

Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :

Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :

Travis Roberts rencontre d’ailleurs le même souci que moi :

Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :

Le bouton Manage access est alors visible juste ici :

Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :

L’affichage des permissions NTFS Access Control Lists configurées par défaut :

Les permissions pour FSLogix doivent alors être reconfigurées comme telles :

Cela donne ceci sur le partage de fichier FSLogix :

Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.

Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.

Etape IV – Tests de performances :

J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :

  • Partage de fichiers sur un compte de stockage Premium joint à Entra ID
  • Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
  • Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput

Pour réaliser les mesures, nous utiliserons l’outil Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

  • Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
    • IOPS
    • Débit
  • Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID :

Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :

Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

  • -d900 : durée du test en secondes
  • -r : opérations de lecture/écriture aléatoires
  • -w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
  • -F4 : nombre de threads max
  • -o128 : longueur de la file d’attente
  • -b8K : taille du bloc
  • -Sh : ne pas utiliser le cache
  • -L : mesure de la latence
  • -c50G : taille du fichier 50 GB
  • E:\diskpsdtmp.dat : chemin du fichier généré pour le test
  • > IOPS-AvecEntra.txt : fichier de sortie des résultats

Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :

ScenarioIOPSBandwidth MB/s
Avec Entra ID12,446.88299.95
Sans Entra ID15,032.54341.17
Premium SSD v220,378.311,167.25

Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.

La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.

Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.

Conclusion

Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.

Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.

Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.

AVD encore sous Windows 10 22H2 ?

Pourquoi, en 2025, mettre à jour son AVD ronronnant encore et toujours sous Windows 10 22H2 ? Windows 10 ou 11, comme leurs prédécesseurs, reçoivent régulièrement plusieurs types de mises à jour (sécurité, correctifs de bugs, feature update, pilotes, …) . Bien que les Extended Security Updates soient gratuites pour les environnements AVD ou Windows 365 pendant encore une année, il ne faudrait pas trop traîner non plus. Mais … attention à BitLocker !

Voici d’ailleurs le lien vers la FAQ Microosft des Extended Security Updates (ESU) pour Windows 10.

Sous Windows 11, la fréquence des Feature Updates a changé par rapport à Windows 10. Depuis 2022, Microsoft publie une seule Feature Update par an, généralement au second semestre (H2) :

  • 21H2 → sortie en octobre 2021
  • 22H2 → sortie en septembre 2022
  • 23H2 → sortie en octobre 2023
  • 24H2 → sortie en septembre/octobre 2024

Mais, Microsoft ne maintient pas indéfiniment ses produits. La transition vers des versions plus récentes est donc inévitable :

SystèmeÉditionVersionDate de fin de support / fin de maintenance
Windows 10Windows 10 Enterprise
Windows 10 Enterprise multi-session
Windows 10 Education,
Windows 10 IoT Enterprise		20H29 Mai 2023
Windows 10Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation		21H213 juin 2024
Windows 10Enterprise
Education
Home
Pro
Enterprise 2015 LTSB
IoT Enterprise LTSB 2015		22H214 octobre 2025
Windows 10Enterprise and IoT Enterprise LTSBex. LTSC 202112 janvier 2027
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation		21H210 octobre 2023
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation		22H28 octobre 2024
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation		23H211 novembre 2025
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation		24H213 Octobre 2026
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation		25H212 Octobre 2027

Les versions Entreprise de Windows 11 ont toute une année de service en plus que leurs homologues respectives en version pro.

Comment les versions de Windows 10/11 sont disponibles sous Azure ?

Lors de la création d’une machine virtuelle sous Azure, Microsoft propose toujours plusieurs versions de Windows 10 ou 11, accessibles via le Marketplace Azure :

Un menu déroulant propose différentes versions et générations (Il est important de vérifier que la VM sélectionnée réponde aux conditions (hardware, Gen2, virt-TPM, Secure Boot…) car toutes les séries de VMs ne sont pas compatibles) :

On peut noter qu’il y a donc distinction entre les éditions clients (Pro, Enterprise). De plus, certaines images sont destinées à des usages spécifiques comme Windows 11 Enterprise multi‑session.

Qu’est-ce qu’Azure Update Manager, et peut-il m’aider ?

Azure Update Manager (AUM) est un service de Microsoft disponible sur Microsoft Azure, conçu pour gérer et superviser les mises à jour logicielles (patches) des machines, tant sous Windows que sous Linux, dans des environnements Azure, sur-premises ou multicloud via Azure Arc.

Grâce à Azure Update Manager, vous allez pouvoir :

  • Superviser la conformité des mises à jour pour les machines Windows et Linux, qu’elles soient dans Azure ou connectées via Azure Arc (on-premises ou multicloud).
  • Planifier des fenêtres de maintenance pour appliquer les patches.
  • Déployer un patch à la demande, ou d’un déploiement automatique selon une plage horaire définie.
  • Mettre en œuvre des mises à jour critiques et les suivre via le monitoring.
  • Gérer les droits via la granularité d’accès (RBAC) et d’autres fonctions de gouvernance Azure.

En ce qui concerne une machine virtuelle Azure avec un OS sous Windows 11, Microsoft est très clair sur ce point :

Automation Update Management ne fourni pas de prise en charge pour l’application de patchs à Windows 10 et 11. Il en va de même pour le Gestionnaire de mises à jour Azure. Nous vous recommandons d’utiliser Microsoft Intune comme solution pour maintenir les appareils Windows 10 et 11 à jour.

Microsoft Learn

Peut-on faire une upgrade d’une VM Azure Windows 10 existante ?

Oui, mais avant d’aller plus loin, sachez que Microsoft recommande déjà de ne pas le faire 🤣

Le processus de cet article entraîne une déconnexion entre le plan de données et le plan de contrôle de la machine virtuelle.

Les fonctionnalités Azure telles que la mise à jour corrective automatique de l’invité, les mises à niveau automatiques de l’image du système d’exploitation, la mise à jour corrective à chaud et le Gestionnaire de mise à jour Azure ne seront pas disponibles.

Pour utiliser ces fonctionnalités, créez une machine virtuelle à l’aide de votre système d’exploitation préféré au lieu d’effectuer une mise à niveau sur place.

Microsoft Learn

Microsoft ne recommande donc pas de faire une mise à niveau sur place pour une machine virtuelle Windows 10 ou 11 dans Azure pour des raisons techniques et structurelles.

Une mise à niveau sur place modifie profondément le système d’exploitation à l’intérieur de la VM sans qu’Azure en soit informé.

Résultat : La machine continue d’exister dans Azure avec les anciennes métadonnées d’image (Publisher, Offer, Plan, version, etc.), ce qui empêche Azure de reconnaître la nouvelle version de l’OS.

Et cela pose un ensemble de problèmes :

  • de gestion du cycle de vie
  • de sécurité et conformité (Azure Security Center/Azure Policy peuvent se tromper sur la version de l’OS)
  • du support Microsoft, car ce dernier s’appuie sur l’image déclarée dans Azure

Mais Microsoft propose pourtant la mise à niveau pour Windows Server ?

Il existe bien une procédure d’upgrade sur place pour Windows Server pour une VM Azure :

Passer d’une version antérieure de Windows Server à une version plus récente tout en conservant les rôles, données et applications.

Que recommande alors Microsoft pour gérer une MAJ sur Windows 10 ?

Microsoft recommande donc de créer une nouvelle VM avec le système d’exploitation cible, car les mises à jour directes peuvent empêcher certaines fonctionnalités Azure de fonctionner correctement.

Donc, la meilleure pratique consiste à :

  1. Déployer une nouvelle VM avec l’image du nouvel OS supporté.
  2. Migrer les applications, données, configurations vers cette nouvelle VM.
  3. Valider le bon fonctionnement, puis retirer l’ancienne VM.

Plusieurs vidéos tutorielles existent sur Internet pour proposer des mises à jour depuis Windows 10 :

Et quid du passage de la 22H2 à la 24H2 ?

Si malgré tout vous devez conserver votre image de base et effectuer une mise à jour vers Windows 11 24H2, vous risquez de rencontrer un problème de démarrage après la capture de votre image après un sysprep.

Lors du passage de Windows 10 22H2 ou Windows 11 22H2 vers la version 24H2, plusieurs administrateurs ont rencontré des écrans bleus ou des erreurs EFI (0xc000000f) juste après la capture d’image via Sysprep.

Le problème provient d’un bug dans le processus de Sysprep, qui modifie la configuration BCD lorsque BitLocker (ou le chiffrement automatique du périphérique) est actif.

Et le souci se manifeste à nouveau si on réactive BitLocker sans avoir corrigé la configuration BCD.

Résultat : l’image capturée devient partiellement chiffrée et inutilisable au déploiement.

Ce souci de démarrage est d’ailleurs confirmé dans les journaux de diagnostic Azure :

Pas de workaround possible ?

Pour éviter cela, il faut désactiver BitLocker avant le Sysprep. Une fois l’image déployée, BitLocker peut être réactivé proprement après correction de la configuration BCD. Ce comportement est spécifique aux builds 26100.x (Windows 11 24H2 et LTSC 2024) .

Voici d’abord une comparaison de l’état de BitLocker sur deux machines virtuelles Azure :

  • A droite : Windows 10 Multi-session 22H2
  • A gauche : Windows 11 Multi-session 24H2

La désactivation de BitLocker doit donc être complète et certaine avant de lancer Sysprep, sous peine de le voir se réactiver.

Afin de voir ce qu’il est possible de faire pour résoudre le souci de BitLocker , je vous propose au travers de cet article un pas à pas sur le processus complet :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests de mise à jour de VM, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une machine virtuelle à partir d’une image Windows 10/11 multi-session en 22H2, que nous allons mettre à jour dans la foulée.

Etape I – Création d’une VM W10 Multi-session 22H2 + MAJ 24H2 :

Pour cela, je commence par créer une machine virtuelle Azure en Windows 10 en 22H2 :

Une fois la machine virtuelle déployée, je vérifie la présence de mon application et de ma version actuelle de Windows :

J’ouvre PowerShell ISE en mode administrateur afin de vérifier l’état actuel de BitLocker :

  • Get-Service BDESVC : affiche l’état du service BitLocker Drive Encryption Service, qui gère le chiffrement BitLocker sur Windows.
  • manage-bde -status : affiche le statut détaillé du chiffrement BitLocker sur tous les lecteurs du système.
  • (Get-ComputerInfo).WindowsVersion : retourne la version majeure de Windows (ex. 10, 11, etc.).
  • (Get-ComputerInfo).OsBuildNumber : affiche le numéro de build du système d’exploitation Windows.
  • (Get-ComputerInfo).WindowsBuildLabEx : fournit la version complète du build Windows avec des informations additionnelles (branche, révision, date de compilation).
Get-Service BDESVC

manage-bde -status

(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsBuildNumber
(Get-ComputerInfo).WindowsBuildLabEx

Je télécharge ensuite l’ISO Windows 11 24H2 depuis Visual Studio :

Je lance l’installation de Windows 11 en 24H2 :

Je vérifie le maintien de la version Multi-session, puis je démarre l’installation :

L’installation progresse lentement mais sûrement :

Afin de m’assurer que la mise à jour est terminée, je vérifie les journaux de diagnostic Azure pour confirmer le bon démarrage de la machine virtuelle :

Je me connecte via Azure Bastion et je vérifie le statut de BitLocker :

Get-Service BDESVC

manage-bde -status

(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsBuildNumber
(Get-ComputerInfo).WindowsBuildLabEx

Le service de BitLocker BDESVC est maintenant démarré en 24H2 :

Je lance les commandes suivantes pour arrêter le service BitLocker BDESVC, mais aussi pour bloquer son changement de statut lors du sysprep :

# 1. Empêcher toute activation BitLocker automatique
reg add "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /t REG_DWORD /d 1 /f

# 2. Désactiver le service BitLocker
Set-Service -Name BDESVC -StartupType Disabled

# 3. Stopper le service s’il est actif
Stop-Service -Name BDESVC -Force

# 4. Vérifier que tout est propre
Get-Service BDESVC
manage-bde -status

La machine virtuelle est maintenant prête pour la capture. Avant cela je pourrais effectuer un snapshot. Je décide de continuer avec la commande Sysprep.

Etape II – Capture de l’image Windows 11 24H2 :

Je lance la commande Sysprep pour capturer cette nouvelle image 24H2 :

C:\Windows\System32\Sysprep\sysprep.exe /quiet /generalize /oobe /mode:vm /shutdown

Une fois Sysprep terminé, j’arrête complètement la machine pour qu’elle soit désallouée, puis je lance l’action de capture de l’image depuis le portail Azure :

Je crée une nouvelle image au sein de ma Azure Compute Gallery :

Avec cette nouvelle image en place, je déclenche la création d’une nouvelle machine virtuelle 24H2 à partir de celle-ci :

La nouvelle machine virtuelle est fonctionnelle, et cela est confirmé dans les journaux de diagnostic Azure :

Etape III – Réactivation de BitLocker :

Une fois la VM créée, je m’y connecte via Azure Bastion, puis je lance la vérification initiale de l’état du service BitLocker et du chiffrement :

Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host "WindowsVersion: $((Get-ComputerInfo).WindowsVersion)"
Write-Host "OS Build: $((Get-ComputerInfo).OsBuildNumber)"
Write-Host "BuildLabEx: $((Get-ComputerInfo).WindowsBuildLabEx)"
Write-Host ""
Start-Sleep -Seconds 3

Le statut du service BitLocker est toujours sur OFF comme attendu, et le disque OS se trouve toujours dans un état de déchiffrement :

Avant de pouvoir chiffrer le disque OS, nous avons besoin de corriger la configuration de BCD.

Je vérifie la configuration actuelle du BCD, corrige les entrées BCD liées à la partition système et au diagnostic mémoire :

# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

# --- Corrige les entrées BCD (selon le bug 24H2 /generalize)
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Write-Host ""
Start-Sleep -Seconds 2

# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

La correction est bien visible sur cette seconde partie de l’écran :

Je supprime la clé de registre PreventDeviceEncryption si elle est présente, je rétablis le service BitLocker en mode manuel, je le démarre, puis je contrôle à nouveau l’état du service BDESVC et de BitLocker :

# --- Nettoyage de la clé PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2

# --- Rétablir le service BitLocker (manuel + démarrage)
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Write-Host "Service BDESVC en cours d’exécution."
Write-Host ""
Start-Sleep -Seconds 2

# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2

J’attends environ 15 minutes la fin du chiffrement du disque OS :

Ensuite, j’active la protection BitLooker :

# --- Active BitLocker avec TPM (UsedSpaceOnly)
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly
Write-Host "BitLocker initialisé. Vérification du statut..."
Start-Sleep -Seconds 3
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2

Cette activation est visible par le petit cadenas présent dans les paramétrages BitLocker et dans l’explorateur de fichier, suivi éventuellement d’un avertissement pour me signaler que la protection est encore sur OFF :

Une fois le chiffrement en place, je remets en route la protection (clé TPM active, verrouillage à l’amorçage autorisé)”.

# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Write-Host "BitLocker réactivé avec succès."
Write-Host ""
Start-Sleep -Seconds 3

# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan

Cette validation est visible par la disparition de l’avertissement pour me signaler que la protection est maintenant sur ON :

Etape IV – Azure Virtual Desktop :

Je redémarre la machine virtuelle pour vérifier le bon fonctionnement du boot de Windows :

Une fois la VM redémarrée, je me reconnecte et confirme la présence de mon application, de la version 24H2 et de l’état actif de BitLocker sur cette machine virtuelle :

Je teste l’ajout de cette image dans un environnement Azure Virtual Desktop :

J’attends la fin de déploiement afin de constater la présence des VMs AVD comme étant disponibles :

Je passe sur chacune des machines pour lancer le script suivant en local ou à distance :

<#
.SYNOPSIS
  Répare la configuration BitLocker après Sysprep /generalize sur Windows 11 24H2.
  Corrige le BCD EFI et réactive BitLocker proprement.

.DESCRIPTION
  Ce script :
    1. Affiche l’état initial BitLocker et du service BDESVC
    2. Corrige les entrées BCD {current} et {memdiag}
    3. Supprime la clé PreventDeviceEncryption
    4. Rétablit le service BitLocker (mode Manuel)
    5. Démarre BDESVC et attend qu’il soit prêt
    6. Active BitLocker avec TPM (si nécessaire)
    7. Attend la fin du chiffrement (max 2h)
    8. Finalise avec Resume-BitLocker
#>

# --- FONCTIONS UTILITAIRES ---

function Wait-ForService {
    param (
        [string]$ServiceName,
        [int]$TimeoutSec = 120
    )
    Write-Host "Attente du service $ServiceName..." -ForegroundColor Yellow
    $sw = [Diagnostics.Stopwatch]::StartNew()
    while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
        $status = (Get-Service $ServiceName -ErrorAction SilentlyContinue).Status
        if ($status -eq 'Running') {
            Write-Host "Service $ServiceName opérationnel." -ForegroundColor Green
            return
        }
        Start-Sleep -Seconds 3
    }
    Write-Host "⚠️ Le service $ServiceName n’a pas démarré après $TimeoutSec secondes." -ForegroundColor Red
}

function Wait-ForEncryption {
    param (
        [string]$MountPoint = "C:",
        [int]$CheckIntervalSec = 15,
        [int]$TimeoutSec = 7200  # 2 heures
    )

    Write-Host "Attente de la fin du chiffrement BitLocker sur $MountPoint (timeout $($TimeoutSec/60) min)..." -ForegroundColor Yellow
    $sw = [Diagnostics.Stopwatch]::StartNew()

    while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
        $status = manage-bde -status $MountPoint | Select-String "Conversion Status"
        $percent = manage-bde -status $MountPoint | Select-String "Percentage Encrypted"
        $state = ($status -replace ".*:\s*", "").Trim()
        $progress = ($percent -replace ".*:\s*", "").Trim()

        Write-Host "État: $state | Progression: $progress"

        if ($state -match "Fully Encrypted|Used Space Only Encrypted") {
            Write-Host "✅ Chiffrement terminé sur $MountPoint" -ForegroundColor Green
            return
        }
        Start-Sleep -Seconds $CheckIntervalSec
    }

    Write-Host "⚠️ Le chiffrement sur $MountPoint n’est pas terminé après $($TimeoutSec/60) minutes." -ForegroundColor Red
    Write-Host "Le script continue, mais vérifie manuellement l’état avec 'manage-bde -status $MountPoint'." -ForegroundColor Yellow
}

# --- DÉBUT DU SCRIPT ---

Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 3

# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

# --- Corrige les entrées BCD
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Start-Sleep -Seconds 2

# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Start-Sleep -Seconds 2

# --- Supprime PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2

# --- Réactive BDESVC
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Wait-ForService -ServiceName "BDESVC"
Write-Host ""

# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Start-Sleep -Seconds 2

# --- Active BitLocker avec TPM si nécessaire
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
$bitlockerStatus = (manage-bde -status C: | Select-String "Conversion Status").ToString()

if ($bitlockerStatus -match "Encryption in Progress|Fully Encrypted|Used Space Only Encrypted") {
    Write-Host "ℹ️ BitLocker est déjà actif ou en cours de chiffrement sur C:. Aucune réactivation nécessaire." -ForegroundColor Yellow
} else {
    try {
        Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly -ErrorAction Stop
        Write-Host "BitLocker initialisé." -ForegroundColor Green
    } catch {
        Write-Host "⚠️ Impossible d’ajouter un protecteur TPM (probablement déjà présent) : $($_.Exception.Message)" -ForegroundColor Red
    }
}

Write-Host "Vérification du statut..."
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host ""

# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host "BitLocker réactivé avec succès." -ForegroundColor Green
Write-Host ""

# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan

Je redémarre la machine AVD pour vérifier son statut dans les journaux de diagnostic Azure :

Je teste également la connexion Azure Virtual Desktop avec un utilisateur :

Enfin, comme mon environnement est liée à Entra ID, je constate également la remontée automatqiue de ma clef de secours BitLocker dans Entra ID :

Conclusion

Cette expérience montre bien qu’une mise à jour in-place d’une image Windows 10/11 dans Azure n’est jamais anodine.
Entre la gestion du chiffrement BitLocker, les effets secondaires du Sysprep et les métadonnées Azure qui ne se mettent pas toujours à jour correctement, le risque d’image inutilisable est bien réel.

Le bon réflexe reste donc de désactiver BitLocker avant le Sysprep, de corriger la configuration BCD, puis de réactiver proprement la protection une fois la VM redéployée.
Cette approche garantit un chiffrement fonctionnel sans compromettre la capture ni le déploiement de l’image.

Mais il existe aujourd’hui une alternative plus élégante et performante : Encryption at Host.
Cette fonctionnalité permet de chiffrer les disques directement au niveau de l’hôte Azure, sans impliquer le service BitLocker à l’intérieur de la VM.

Résultat :

  • Moins de charge CPU côté invité,
  • Pas de dépendance au TPM virtuel,
  • Et une gestion centralisée du chiffrement dans Azure, plus simple à auditer et à maintenir.

C’est cette approche, à la fois plus moderne et plus légère, que nous verrons dans le prochain article.

On parlera en détail de la mise en œuvre d’Encryption at Host, de son impact sur les performances et des bonnes pratiques pour combiner sécurité et efficacité énergétique dans vos environnements AVD.

Mise en place d’une identité managée pour AVD

Dès ce mois de septembre 2025, Microsoft introduit l’identité managée (Managed identity) aux environnements Azure Virtual Desktop. Cet ajout permettra d’exécuter en toute sécurité des actions lors de la création, suppression et mise à jour des machines virtuelles du pool d’hôtes. Cette nouvelle identité managé, de type système ou utilisateur est encore en préversion, remplacera certains usages du bien connu service principal Azure Virtual Desktop, que l’on utilise jusqu’à présent sur Azure comme sur Entra.

A partir du 15 novembre 2025, toute configuration utilisant le système de gestion des mises à jour intégré à Azure Virtual Desktop devra obligatoirement être associée à une identité managée (Managed Identity) pour continuer à fonctionner.

Concrètement, cela signifie que l’ancien modèle basé sur le service principal AVD disparaît progressivement au profit d’une approche plus robuste, où les opérations de création, suppression et mise à jour des machines virtuelles, passent par une authentification native dans Microsoft Entra ID.

Voici le service principal que l’on utilise actuellement :

Pour les administrateurs, c’est une étape importante qu’il faut anticiper dès maintenant, car elle touche directement la gestion quotidienne des environnements AVD.

Pourquoi ce changement ?

Historiquement, AVD utilisait un service principal spécifique pour réaliser certaines actions sur les ressources Azure associées aux hôtes de session :

Une identité managée s’authentifie automatiquement auprès d’Entra ID sans qu’aucun mot de passe ou secret ne soit stocké dans vos scripts ou vos ressources. Cela réduit considérablement la surface d’attaque et améliore la conformité.

Côté gouvernance, tout passe par l’Azure RBAC, ce qui rend les permissions plus lisibles et plus faciles à auditer.

System-assigned ou User-assigned ? deux modèles possibles :

Azure propose deux types d’identités managées.

  • System-assigned : créée et rattachée directement au pool d’hôtes Son avantage principal est sa simplicité : elle vit et meurt avec la ressource. Si vous supprimez le pool d’hôtes , l’identité disparaît automatiquement.
  • User-assigned : ressource indépendante dans Azure que vous pouvez rattacher à un ou plusieurs pools d’hôtes. Elle est donc plus flexible, particulièrement utile dans des environnements complexes où plusieurs ressources doivent partager la même identité et les mêmes permissions. En revanche, elle demande une gestion supplémentaire : l’objet reste actif même si le pool d’hôtes est supprimé.

Quelles fonctionnalités AVD utiliseront cette identité managée ?

Pour le moment, toutes les fonctionnalités d’Azure Virtual Desktop ne basculent pas encore vers ce modèle. Seule la fonction de mise à jour d’un pool d’hotes est prévue actuellement :

Les autres fonctionnalités, telles que App Attach, Autoscale et Start VM on Connect s’appuient encore sur le service principal Azure Virtual Desktop :

Cela signifie que vous aurez peut-être à gérer une période de transition où les deux approches cohabitent.

Quels impacts pour vos environnements AVD existants et futurs ?

Pour les administrateurs AVD, ce changement implique de revoir la configuration des pool d’hôtes, en particulier ceux qui utilisent ou vont utiliser la session host configuration.

À partir de novembre 2025, il ne sera plus possible d’ajouter de nouveaux hôtes de session sans identité managée :

  • À partir du 19 septembre 2025, les nouveaux pools d’hôtes utilisant une configuration d’hôtes de session dans le portail Azure devront être créés avec une identité managée.
  • À partir du 15 octobre 2025, les pools d’hôtes existants avec une configuration d’hôtes de session ne pourront plus mettre à jour leur configuration tant qu’une identité managée n’aura pas été ajoutée.
  • À partir du 15 novembre 2025, les pools d’hôtes existants avec une configuration d’hôtes de session ne pourront plus créer de nouveaux hôtes de session tant qu’une identité managée n’aura pas été ajoutée.

Quels sont les rôles AVD nécessaires avec l’identité managée ?

Lorsqu’on assigne une identité managée à un pool d’hôtes AVD, il faut lui donner les bons rôles RBAC pour qu’Azure Virtual Desktop puisse automatiser les opérations sur les hôtes de session. Voici les rôles clés utilisés avec la session host configuration et leur utilité :

  • Desktop Virtualization Virtual Machine Contributor – Resource group of image gallery : Autorise l’accès à la Compute Gallery pour que l’identité managée puisse lire et utiliser les images servant de base au déploiement des VMs. Sans ce rôle, AVD ne peut pas provisionner une VM à partir de l’image de référence.
  • Desktop Virtualization Virtual Machine Contributor – Resource group for session hosts : Donne le droit de créer, mettre à jour et supprimer les machines virtuelles qui composent le pool d’hôtes. C’est le rôle central pour permettre à AVD de gérer le cycle de vie des hôtes de session.
  • Desktop Virtualization Virtual Machine Contributor – VNet / NSG : Permet à l’identité de connecter les cartes réseau des VMs au bon sous-réseau et d’appliquer les règles de sécurité (NSG). Ce rôle est indispensable pour que les hôtes de session soient correctement intégrés au réseau et puissent rejoindre le domaine ou accéder aux ressources.
  • Key Vault Secrets User – Domain join Key Vault : Autorise l’identité à récupérer les secrets nécessaires à la jointure au domaine, comme le mot de passe d’un compte de service stocké dans Azure Key Vault. Cela automatise le processus sans exposer les identifiants en clair.
  • Key Vault Secrets User – Admin account Key Vault : Permet à l’identité d’accéder aux identifiants administrateur stockés dans un Key Vault. Ces informations peuvent être nécessaires lors de la création ou de la configuration initiale des hôtes de session.

Pour illustrer concrètement la mise en place et l’utilisation d’une identité managée dans Azure Virtual Desktop, j’ai choisi de documenter deux scénarios distincts. Cela permettra de couvrir à la fois un environnement AVD neuf et un environnement AVD existant, afin que chacun puisse s’y retrouver selon sa situation.

Dans ce premier cas, je pars de zéro avec un déploiement complet d’Azure Virtual Desktop. Ce scénario illustre la nouvelle exigence imposée par Microsoft pour les nouveaux déploiements, et montre comment intégrer cette configuration proprement dès le départ.

Scénario I – Création d’un nouvel environnement AVD :

L’objectif est de créer un tout nouveau pool d’hôtes après le 19 septembre 2025, et en activant directement l’assignation d’une identité managée dès le processus de création.

Lors de la création de mon pool d’hôtes AVD, sur l’onglet Management, je constate que la case Identité managée est déjà cochée, ainsi que les permissions attribuées à cette identité :

Durant le déploiement, je vois les assignations de rôle automatiquement créées sur différentes ressources Azure pour cette identité managée :

Une fois l’environnement créé, la configuration de l’identité managée est visible directement dans les paramètres du pool d’hôtes :

En cliquant sur l’assignation de rôles, je peux voir les rôles effectivement appliqués sur les ressources du déploiement :

En vérifiant les rôles associés au pool d’hôtes, je constate la présence d’une identité managée de type system-assigned :

Dans le coffre Azure, je retrouve également cette identité managée avec les permissions nécessaires :

Afin de voir l’impact de celle-ci, je déclenche une mise à jour immédiate sur mon nouveau pool d’hôtes AVD :

La mise à jour se déclenche correctement :

Environ quinze minutes plus tard, la mise à jour se termine avec succès :

Les journaux montrent bien que c’est l’identité managée qui a été utilisée comme initiateur de la mise à jour :

Le deuxième test consiste maintenant à prendre un environnement AVD déjà déployé, avec un pool d’hôtes fonctionnel, et à lui associer une identité managée après coup.

Scénario II – Ajout d’une identité managée à un environnement AVD existant :

Ce scénario reflète les besoins de nombreuses organisations qui disposent déjà d’un parc en production AVD et qui doivent se mettre en conformité avant la date butoir de novembre 2025.

Sur mon environnement AVD déjà en place avant le 19 septembre 2025, je lance également une mise à jour via l’interface :

La mise à jour se déclenche correctement :

Après environ quinze minutes, la mise à jour se réalise avec succès :

Dans l’activité, je vois l’identité applicative AVD utilisée pour orchestrer l’opération.

Afin de mettre une identité managée sur mon ancien environnement AVD, je coche la case suivante sur ce pool d’hôtes, puis j’enregistre ma modification :

L’identité managée apparaît désormais dans la configuration du pool d’hôtes :

Une commande PowerShell permet de confirmer la présence de l’identité managée affectée au pool d’hôtes :

$parameters = @{
    Name = '<HostPoolName>'
    ResourceGroupName = '<ResourceGroupName>'
}

Get-AzWvdHostPool @parameters | Format-Table Name, IdentityType

Je constate cependant que cette identité n’a encore aucune assignation de rôle.

Malgré tout, je déclenche une mise à jour immédiate AVD :

Cette dernière échoue immédiatement :

Les journaux indiquent clairement que l’identité managée ne dispose pas des droits suffisants sur l’environnement AVD :

Je retourne dans la configuration et ajoute un par un les rôles nécessaires (Compute Gallery, Session Hosts, VNet/NSG, Key Vaults).

J’effectue l’opération autant de fois que nécessaire :

Je contrôle que les rôles sont bien en place sur le pool d’hôtes et sur le coffre associés :

Je relance la mise à jour du pool d’hôtes.

La mise à jour de mon environnement AVD se lance :

Après une quinzaine de minutes, la mise à jour est finalisée avec succès :

Les logs confirment que l’identité managée a bien été utilisée pour piloter la nouvelle mise à jour :

Conclusion

L’introduction des identités managées dans Azure Virtual Desktop marque une étape importante dans la sécurisation et la modernisation du service. Là où le service principal AVD imposait la gestion de secrets et une gouvernance parfois complexe, l’identité managée apporte une intégration native à Microsoft Entra ID et une simplification des processus.

Les deux scénarios que j’ai présentés montrent bien la dualité de la situation actuelle :

  • Pour les nouveaux environnements, l’identité managée est désormais intégrée par défaut, et il suffit de l’accepter et de valider les rôles nécessaires.
  • Pour les environnements existants, une phase d’adaptation est incontournable. Il faut ajouter manuellement l’identité managée, attribuer progressivement les bons rôles RBAC, et valider que toutes les opérations AVD critiques fonctionnent correctement.

Au-delà de l’exemple des mises à jour de pools d’hôtes, ce changement illustre surtout la direction que prend Microsoft : réduire la dépendance aux secrets et renforcer la sécurité par défaut. D’ici novembre 2025, l’identité managée sera obligatoire pour l’ensemble des environnements AVD utilisant la session host configuration.

Mon conseil : n’attendez pas la date butoir. Prenez le temps dès maintenant de tester, documenter et industrialiser vos déploiements AVD avec une identité managée. Cela vous évitera des blocages en production et vous assurera une transition fluide vers ce nouveau modèle de sécurité.

Accès sortant par défaut : Microsoft ferme le robinet en septembre 2025

Depuis toujours, Azure offrait une “porte de sortie cachée” vers Internet à toutes les machines virtuelles déployées dans un réseau virtuel sans configuration explicite : le fameux Accès sortant par défaut (Default Outbound Access). En clair, si vous créiez une VM sans NAT Gateway, sans Équilibreur de charge, sans IP publique attachée… eh bien Azure vous donnait quand même un accès internet de secours via une IP publique éphémère. Mais tout cela change bientôt !

À partir du 30 septembre 2025, cette facilité disparaît pour tous les nouveaux réseaux virtuels. Les workloads qui comptaient dessus devront désormais passer par des méthodes explicites de sortie (NAT Gateway, Load Balancer SNAT, ou IP publique directe).

Pas d’inquiétude donc pour vos environnements déjà en place ! Ce changement ne concerne pas les réseaux virtuels déjà déployés avant cette date. Mais une modernisation de ces derniers est à envisager afin de les harmoniser avec les nouveaux réseaux virtuels dépourvus de l’Accès sortant par défaut.

Qu’est-ce que l’Accès sortant par défaut ?

L’Accès sortant par défaut est une connectivité internet implicite que Microsoft Azure attribuait automatiquement aux machines virtuelles créées dans un réseau virtuel sans configuration explicite de sortie.

Dans Azure, lorsqu’une machine virtuelle (VM) est déployée dans un réseau virtuel sans méthode de connectivité sortante explicitement définie, une adresse IP publique sortante lui est automatiquement attribuée.

Cette adresse IP permet la connectivité sortante depuis les ressources vers Internet et vers d’autres points de terminaison publics au sein de Microsoft. Cet accès est appelé « accès sortant par défaut ».

Microsoft Learn

Comment et quand l’accès sortant par défaut était-il utilisé ?

Microsoft décrit ici l’ordre de résolution de la connectivité sortante d’une VM dans Azure par plusieurs tests chaque par ordre de priorité :

  • Firewall
    • NAT Gateway
      • IP publique
        • Équilibreur de charge
          • Accès sortant par défaut

L’accès sortant par défaut n’est donc qu’un dernier recours. Et après la fin septembre 2025, il disparaîtra pour les nouveaux réseaux virtuels, seules les méthodes explicites resteront.

Pourquoi Microsoft le retire ?

Microsoft met fin à ce mécanisme pour trois raisons principales :

  • La première est la sécurité : cette IP “fantôme” ne figurait souvent dans aucun inventaire, ce qui compliquait la gestion et exposait à des risques.
  • La deuxième est la stabilité : ces adresses publiques pouvaient changer sans prévenir, cassant certaines intégrations critiques avec des services externes.
  • Enfin, la troisième est la conformité : dans un contexte d’audit, il était difficile de tracer les flux sortants d’une VM utilisant ce mode implicite. L’objectif est donc de forcer les clients à adopter des méthodes explicites et maîtrisées de connectivité.

Voici un exemple concret avec un Accès sortant par défaut :

Vous déployez une VM, elle se met à parler à internet avec une IP que vous ne connaissiez pas, qui peut changer sans prévenir, et qui n’apparaît pas dans vos inventaires de sécurité. C’était cela l’Accès sortant par défaut.

Dès la fin septembre, Microsoft dit stop à cette approche :

En supprimant cette facilité, Microsoft pousse à adopter des designs réseau clairs, contrôlables et audités. Malgré la contrainte en tant que telle, cela reste une excellente nouvelle pour la gouvernance cloud.

Qui est impacté ?

Tout le monde. Mais seuls les nouveaux réseaux virtuels créés après le 30 septembre 2025 seront concernés :

Après le 30 septembre 2025, les nouveaux réseaux virtuels exigeront par défaut des méthodes de connectivité sortante explicites au lieu d’avoir un repli vers la connectivité d’accès sortant par défaut.

Azure Updates

Les réseaux existants continueront de fonctionner comme avant, mais Microsoft recommande déjà à tous les clients de migrer afin d’éviter les discordances entre les anciens et nouveaux réseaux virtuels :

Toutes les machines virtuelles (existantes ou nouvellement créées) dans les réseaux virtuels existants qui utilisent l’accès sortant par défaut continueront de fonctionner après cette modification. Cependant, nous vous recommandons vivement de passer à une méthode sortante explicite.

Azure Updates

Même confirmation sur le site Learn de Microsoft :

Aucune modification n’est apportée aux réseaux virtuels existants. Cela signifie que les machines virtuelles existantes et les machines virtuelles nouvellement créées dans ces réseaux virtuels continuent de générer des adresses IP sortantes par défaut, à moins que les sous-réseaux ne soient modifiés manuellement pour devenir privés.

Microsoft Learn

Quelles sont les alternatives recommandées ?

Afin de maintenir un accès internet à vos machines virtuelles, plusieurs services sont proposés par Microsoft selon vos besoins :

  • La solution de référence est le NAT Gateway, qui offre une connectivité sortante hautement disponible, scalable et simple à gérer.
  • Dans certains cas, on pourra également utiliser un Équilibreur de charge configuré avec des règles SNAT.
  • Pour des scénarios plus ponctuels, il reste possible d’associer une IP publique directement à une VM, même si cela n’est pas conseillé pour des environnements critiques.
  • Enfin, dans les architectures plus sécurisées, le trafic sortant peut être centralisé à travers un Azure Firewall, un proxy ou une appliance réseau virtuelle (NVA).

Comment préparer ma migration ?

La première étape est d’inventorier vos workloads et d’identifier ceux qui reposent encore sur ce mode implicite d’Accès sortant par défaut.

Ce script PowerShell parcourt toutes les souscriptions Azure et dresse, pour chaque réseau virtuels et sous-réseaux, l’état de l’option Accès sortant par défaut :

$results = New-Object System.Collections.Generic.List[object]
$subs = Get-AzSubscription -ErrorAction Stop

foreach ($sub in $subs) {
    Set-AzContext -SubscriptionId $sub.Id -Tenant $sub.TenantId | Out-Null
    $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue

    foreach ($vnet in $vnets) {
        foreach ($subnet in $vnet.Subnets) {
            $hasProp = $subnet.PSObject.Properties.Name -contains 'DefaultOutboundAccess'
            $raw = if ($hasProp) { $subnet.DefaultOutboundAccess } else { $null }

            $status = if ($raw -eq $false) { 'Disabled' } else { 'Enabled' }

            $results.Add([PSCustomObject]@{
                SubscriptionName = $sub.Name
                SubscriptionId   = $sub.Id
                ResourceGroup    = $vnet.ResourceGroupName
                VNet             = $vnet.Name
                Region           = $vnet.Location
                Subnet           = $subnet.Name
                DefaultOutbound  = $status
            }) | Out-Null
        }
    }
}

$results |
    Sort-Object SubscriptionName, ResourceGroup, VNet, Subnet |
    Format-Table -AutoSize

Ensuite, choisissez une stratégie adaptée :

  • Associez une passerelle NAT
  • Associez un équilibreur de charge
  • Associez une adresse IP publique
  • Ajoutez un pare-feu

Puis, testez ensuite vos flux réseau, notamment tout ce qui dépend de l’accès à Internet : mise à jour, activation Windows, appels API externes, DNS.

Quelles sont les limitations des subnets privés ?

Dans un sous-réseau privé entièrement fermé à Internet, certaines contraintes importantes impactent la bonne marche des machines virtuelles.

Plusieurs fonctionnalités essentielles demandent de mettre en place obligatoirement une méthode explicite de connectivité sortante.

  • Impossibilité d’utiliser les services Microsoft 365
  • Impossibilité d’activer le système d’exploitation
  • Impossibilité de mettre à jour le système d’exploitation via Windows Update
  • Impossibilité d’associer une machine virtuelle à Azure Virtual Desktop
  • Les routes configurées avec un next hop de type Internet deviennent inopérantes

Note : Les sous-réseaux privés ne s’appliquent pas non plus aux sous-réseaux délégués ou gérés utilisés par des services PaaS. Dans ces scénarios, c’est le service lui-même (par exemple Azure SQL, App Service, etc.) qui gère sa propre connectivité sortante.

Puis-je déjà désactiver l’Accès sortant par défaut avant septembre 2025 ?

Oui, il est déjà possible de désactiver ce mécanisme dans vos réseaux virtuels pour anticiper la transition.

Cela permet de vérifier vos workloads dans des conditions proches de ce qui deviendra la norme à partir de septembre 2025 et d’éviter les mauvaises surprises le jour où le support sera officiellement retiré.

Important : Il est nécessaire d’arrêter/désallouer les machines virtuelles concernées dans un sous-réseau pour que les modifications de l’Accès sortant par défaut soient prises en compte.

Une fois ces choses dites, je vous propose de tester cela depuis un environnement de démonstration afin de voir ce qu’il est actuellement possible de faire ou de ne pas faire de nôtre côté :

Maintenant, il ne nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Commençons par tester la connectivité à internet depuis un réseau Azure créé avant septembre 2025.

Test I – Connexion internet depuis un sous-réseau non privé :

Dans un réseau virtuel Azure déjà créé, j’ai commencé par créer un premier sous-réseau non privé :

J’ai crée une machine virtuelle sans adresse IP publique associée :

Une fois la VM démarrée, la machine obtient quand même un accès Internet sortant :

Et OneDrive se configure sans problème :

Tout fonctionne comme cela à toujours fonctionné. Passons maintenant à un test reposant sur un sous-réseau virtuel cette fois privé.

Test II – Connexion internet depuis un sous-réseau privé :

Sur ce même réseau virtuel, j’ai crée un second sous-réseau, avec l’option Private subnet cochée :

Une fois connecté à la machine virtuelle, dans les paramétrages Windows, l’état du réseau indique qu’il n’y a plus d’accès Internet :

Impossible d’ouvrir des sites web depuis le navigateur internet :

Windows Update échoue également à télécharger les mises à jour :

L’activation Windows ne se fait pas non plus :

Et cette fois, OneDrive refuse de se configurer :

Et pourtant, j’accède sans problème à un compte de stockage via son URL publique :

Tout montre que l’accès extérieur à Azure, y compris Microsoft 365, est bloqué dans ce sous-réseau privé.

Sur ce second sous-réseau, je décoche l’option précédemment activée, puis je sauvegarde :

Malgré cela, la machine n’a toujours pas retrouvé Internet :

Je tente même un redémarrage de la machine virtuelle depuis le portail Azure :

Mais après ce redémarrage, rien ne change côté accès Internet :

Après un arrêt complet puis un redémarrage manuel, la sortie vers Internet revient :

Cette fois, la VM a bien une IP publique éphémère pour sortir sur Internet :

Ce test nous montre l’impact de cette option sur les ressources externes accessibles à notre machine virtuelle. Continuons avec un test sur le comportement d’Azure Virtual Desktop dont les VMs seraient sur ce type de sous-réseau privé.

Test III – Connexion Azure Virtual Desktop depuis un sous-réseau privé :

Je dispose d’un environnement Azure Virtual Desktop contenant déjà plusieurs machines virtuelles dans le pool d’hôtes :

J’ai donc modifié le sous-réseau AVD pour qu’il soit privé :

J’ai ajouté une nouvelle machine virtuelle via le plan de mise à l’échelle AVD :

La création de la VM se déroule normalement et celle-ci apparaît :

Mais, elle n’a jamais rejoint automatiquement mon Active Directory :

Et elle n’a pas non plus intégré le pool d’hôtes AVD :

Enfin, au bout d’un certain temps, elle s’est même auto-supprimée :

Ce test nous montre qu’un environnement Azure Virtual Desktop déployé après septembre 2025 nécessitera des ressources supplémentaires pour fonctionner correctement.

Continuons nos tests en appliquant les méthodes proposées par Microsoft pour compenser le changement à venir.

Test IV – Connexion internet avec une adresse IP publique :

Je recoche l’option Private subnet sur mon 2ᵉ sous-réseau :

J’y crée une machine virtuelle, cette fois disposant d’une adresse IP publique associée :

La VM a bien accès à Internet, et l’IP vue depuis l’extérieur correspond à l’IP publique de la machine virtuelle :

Voici le coût de cette IP publique dans le Azure Pricing Calculator :

Il s’agit de la solution la plus économique pour retrouver un accès internet. Mais la question va se poser si un grand nombre de machines virtuelles existent. Si l’ajout d’une adresse IP publique sur une machine virtuelle n’est pas sans conséquence sur la sécurité.

Continuons avec le service Azure NAT Gateway.

Test V – Connexion internet avec Azure NAT Gateway :

Je crée un 3ᵉ sous-réseau privé, dédié cette fois à un test avec NAT Gateway :

Je déploie un service NAT Gateway et je lui assigne une IP publique :

Le nouveau sous-réseau privé est bien associé au service NAT Gateway :

Je crée une VM dans ce 3ᵉ sous-réseau :

Les tests montrent que la VM utilise bien l’adresse IP publique du NAT Gateway pour sortir sur Internet :

Je reproduis ensuite ce même test sur le sous-réseau dédié à Azure Virtual Desktop :

Je lance la création d’une 4ᵉ VM AVD :

Cette fois, la VM rejoint correctement mon Active Directory :

Elle est aussi intégrée automatiquement au host pool d’AVD, et devient accessible :

Voici le coût estimé par Azure Pricing Calculator pour un service NAT Gateway et son IP publique :

L’Azure NAT Gateway est un service géré qui permet aux machines virtuelles dans un sous-réseau privé de sortir sur Internet de manière sécurisée, performante et scalable.

Continuons avec le service Azure Firewall.

Test VI – Connexion internet avec Azure Firewall :

Je crée un 4ᵉ sous-réseau privé dédié cette fois à un test avec Azure Firewall :

Je crée aussi le sous-réseau spécifique réservé au service Azure Firewall :

Je déploie un Azure Firewall en SKU Basique pour ce test :

Deux adresses IP publiques sont automatiquement créées pour le Firewall :

Je configure une Firewall Policy avec plusieurs règles et adresses IPs cibles :

Je crée une nouvelle machine virtuelle sur ce nouveau sous-réseau privé :

Enfin je crée une table de routage associée à mon sous-réseau virtuel de test, dont le prochain saut envoie tout le trafic sortant vers l’adresse IP privée de mon Firewall Azure :

Les tests montrent que la sortie Internet se fait bien via l’IP publique de l’Azure Firewall :

Voici le coût estimé par Azure Pricing Calculator pour un service Azure Firewall et ses deux adresses IP publiques :

L’Azure Firewall a un rôle différent d’un NAT Gateway : ce n’est pas juste de la connectivité sortante, c’est une véritable appliance de sécurité managée par Microsoft. Mais d’autres appliances tierces auraient elles-aussi pu faire l’affaire.

Terminons avec un Équilibreur de charge Azure.

Test VII – Connexion internet avec Azure Load Balancer :

Je crée un 5ᵉ sous-réseau privé, cette fois pour tester Azure Load Balancer :

Je crée une nouvelle VM dans ce nouveau sous-réseau privé :

Je déploie un Équilibreur de charge et lui associe une IP publique :

La VM est ajoutée au backend pool :

Je configure une règle SNAT de sortie sur l’Équilibreur de charge :

En me connectant à la VM, je constate que la sortie Internet se fait bien via l’IP publique de l’Équilibreur de charge :

Voici le coût estimé par Azure Pricing Calculator pour un Équilibreur de charge et son adresse IP publique :

Ce service permet aux VM backend de sortir vers Internet sans IP publique dédiée, mais il est limité pour les gros volumes de connexions (NAT Gateway est plus adapté).

Conclusion

La fin de l’Accès sortant par défaut marque une étape clé dans la maturité du cloud Azure. Fini les “raccourcis” implicites : désormais, chaque sortie vers Internet devra être pensée, tracée et gouvernée.

Ce changement n’est pas une contrainte, mais une opportunité :

  • Opportunité de renforcer la sécurité en éliminant des flux fantômes.
  • Opportunité d’améliorer la stabilité et la prévisibilité des intégrations.
  • Opportunité de consolider vos architectures autour de designs réseau clairs, basés sur NAT Gateway, Azure Firewall ou un Équilibreur de charge.

Faites du NAT avec Azure VPN

Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?

Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.

Qu’est-ce que le NAT ?

Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.

Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :

Comment fonctionne le NAT ?

Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :

Le routage du trafic impacte alors le traffic de données dans les deux sens :

  • Sortant : le paquet quitte le réseau interne avec l’adresse publique.
  • Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.

Quels sont ses avantages et ses limites au NAT ?

Avantages

  • Économie d’adresses IPv4
  • Masquage du réseau interne (sécurité renforcée)
  • Contrôle centralisé du trafic sortant/entrant

Limites

  • Complexité de dépannage (tables de traduction)
  • Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
  • Impact potentiel sur la latence et le débit

SNAT vs DNAT ?

En pratique, le NAT (Network Address Translation) se décline en deux grands modes :

ModeAbréviationFonction principaleExemple d’usage
Source NATSNAT (Source NAT)Modifier l’adresse source et/ou le port d’une connexion sortanteVotre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway
Destination NATDNAT (Destination NAT)Modifier l’adresse de destination et/ou le port d’une connexion entranteInternet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080)
  • Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
  • Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.

Et le NAT dans Azure c’est possible ?

Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :

Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.

Microsoft Learn

Quels services Azure proposent du NAT ?

Oui, plusieurs services Azure permettant de faire du NAT entre votre réseau Azure et votre infrastructure on-premise :

Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?

La réponse est oui :

Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.

Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.

Microsoft Learn

Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :

Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :

  • NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
  • NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
  • Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
  • La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
  • Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
  • Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
  • Les mappages de ports peuvent servir pour les protocoles TCP et UDP.

Et en pratique ?

Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :

  • Le premier simulant un réseau on-premise
  • Le second correspondant à un réseau virtuel Azure

Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :

Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :

Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :

Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :

J’ai commencé par ajouter des règles NAT sur la passerelle Azure :

  • Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
    • adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
    • adresses externes = l’adressage IP translaté vu par votre réseau on-premise
  • Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
    • adresses internes = l’adressage IP configuré sur votre réseau on-premise
    • adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure

J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :

  • Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
    • adresses internes : l’adressage IP configuré sur ton réseau on-premise
    • adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
  • Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
    • adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
    • adresses externes = l’adressage IP translaté vu par ton réseau on-premise

Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :

  • L’une pour présenter le réseau on-premise à la passerelle Azure
  • L’autre pour présenter le réseau Azure la passerelle on-premise

La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :

La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :

J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.

Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.

J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :

Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :

Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :

Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :

Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :

Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :

Conclusion

Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses

Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.

Migrez vers Azure sans droits d’infra, c’est possible !

Réussir la migration d’une infrastructure IT nécessite un objectif clair, un plan d’action, des moyens humains et matériels, et …. , du temps devant soi. Mais il arrive que la migration ne soit pas un parcours de santé, mais plutôt jonché de contraintes impactant les stratégies décidés avant. Par exemple, que doit-on faire si la migration de VMs doit se faire finalement sans aucun accès au niveau hyperviseur ?

Différentes approches de migration ?

Lors d’une migration vers le cloud, plusieurs approches coexistent : le « lift-and-shift » (reprise à l’identique), la replatforming ou refactoring (adaptation partielle) et la reconstruction totale accompagnée de modernisation.

Si le lift-and-shift est souvent privilégié pour sa rapidité de mise en œuvre, il n’exploite pas pleinement les services cloud-native et peut engendrer un surcoût opérationnel à long terme.

À l’inverse, la refonte ou la reconstruction des applications, en recourant par exemple aux microservices, au serverless ou aux bases de données managées, permet d’améliorer la scalabilité, la résilience et l’agilité, tout en optimisant les coûts à terme.

Azure Migrate ?

Bien entendu, dans certains scénarios, notamment lorsqu’on fait face à des délais serrés, à des contraintes budgétaires ou à un manque de compétences, il est nécessaire de migrer en priorité les machines virtuelles existantes « telles quelles ».

On opte alors pour un lift-and-shift à l’aide d’outils comme Azure Migrate ou Azure Site Recovery, qui répliquent les VM sans toucher au code ni à l’architecture.

Pour vous donner un peu de matière, un ancien article parlant d’Azure Migrate vous détaille toutes les grandes étapes.

Mais que faire si l’accès à l’hyperviseur est restreint ?

Toutefois, si aucun niveau d’accès la couche hyperviseur n’est possible, la migration vers Azure s’en trouve alors un peu plus compliquée.

Dans le cadre d’Azure Migrate (et plus précisément du service de réplication Azure Site Recovery), on rencontre 2 rôles clés au sein de l’appliance de réplication déployée :

  • Serveur de traitement :
    • Installé par défaut sur le serveur de configuration, il reçoit les données de réplication envoyées par le Mobility Service installé sur vos machines sources.
    • Il optimise ces flux en effectuant de la mise en cache, de la compression et du chiffrement, puis les transmet vers votre compte de stockage Azure.
  • Serveur de cible principale :
    • N’est utilisé que lors du failback (reprise sur site) des machines dès lors qu’elles ont été basculées vers Azure.
    • Il reçoit alors les données répliquées en provenance d’Azure, reconstitue les disques (VHD/VMDK) et les écrit sur votre infrastructure on-premises pour restaurer les VM sur site.

En synthèse, le Process Server gère l’envoi optimisé des données vers Azure, tandis que le Master Target Server gère la réception et la restauration de ces mêmes données lors d’un retour en local.

En voyant cette excellente vidéo en mode tutoriel, je trouvais intéressant de tester par moi-même ce cas de figure, en partant d’un environnement VMware vers Azure, sans pouvoir utiliser l’accès hyperviseur.

Cet article est donc divisé en 2 démonstrations quasi-identiques :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de réaliser nos 2 tests de migration, nous allons avoir besoin de :

  • Un tenant Microsoft actif
  • Une souscription Azure valide
  • Un environnement hypervisé (Hyper-V ou VMware)

Commençons par effectuer l’exercice de migration en partant du principe que nous pouvons déployer une machine virtuelle jouant le rôle de d’appliance de réplication sur VMware.

Test I – Appliance de réplication VMware :

Sur votre console hyperviseur, créez une machine virtuelle de type Windows Serveur afin d’y installer par la suite notre appliance de réplication :

Connectez-vous à celle-ci avec un compte administrateur local :

Si besoin, installez un navigateur internet récent :

Connectez-vous au portail Azure, puis recherchez le service Azure Migrate :

Cliquez-ici pour commencer un nouveau projet de migration :

Cliquez-ici pour créer le projet de migration :

Renseignez les toutes informations demandées, puis cliquez sur Créer :

Cliquez sur Découvrir afin d’installer l’appliance de réplication :

Renseignez tous les champs, puis cliquez sur Créer les ressources :

Conservez les options suivantes :

Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :

Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :

Lancez l’installeur de l’appliance de réplication :

Attendez quelques minutes la fin de la décompression :

Conservez ce choix, puis cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Rechercher le fichier clef, puis cliquez sur Suivant :

Conservez ce choix, puis cliquez sur Suivant :

Attendez que tous les contrôles soit effectués, puis cliquez sur Suivant :

Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :

Si cela est votre cas, cochez cette case, puis cliquez sur Suivant :

Cliquez sur Suivant :

Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 10 minutes la fin de l’installation de l’appliance de réplication :

Cliquez sur Oui :

Collez cette passphrase dans un fichier texte, puis sauvegardez-le :

Une fois l’installation réussie, cliquez sur Terminer :

L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur de vos machines devant être migrées dans le cloud Azure :

Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’appliance de réplication :

Attendez le succès de l’opération via la notification suivante :

Constatez la création de ressources dans le groupe de ressources précédemment défini :

Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez l’exécutable ci-dessous :

C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository

Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y l’exécutable précédemment copié ainsi que le fichier texte contenant la passphrase :

Retournez sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée vers Azure :

Sur cette machine virtuelle à migrer, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :

$PSversiontable

Toujours depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication :

Toujours depuis votre machine virtuelle à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :

Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :

Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :

cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted

UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent  /CSType CSLegacy

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe  /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>

Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :

Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :

Exécutez cette commande pour installer l’agent :

Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :

Avant de continuer, vérifiez le succès des opérations :

Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :

Cliquez ensuite sur Répliquer :

Renseignez toutes les champs, puis cliquez sur Continuer :

Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :

Sélectionner les machines à migrer, puis cliquez sur Suivant :

Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :

Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :

Sélectionnez le type de disque à utiliser pour les machines à migrée, puis cliquez sur Suivant :

Lancez la réplication en cliquant sur Répliquer :

Les notifications suivantes apparaissent alors :

Des ressources Azure liées au projet de migration sont alors créées :

Le compte de stockage commence à recevoir les premières données liées à la réplication :

Dans le coffre Recovery, la réplication commence elle-aussi à être visible :

Environ 1 heure plus tard, celle-ci est terminée :

Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :

Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :

Définissez la destination cible, puis cliquez sur Continuer :

Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :

La notification suivante apparaît :

Quelques secondes plus tard, celle-ci affiche le succès du déclenchement de la migration :

Cette migration est visible sur notre projet Azure Migrate :

Le coffre Recovery nous indique que la migration est terminée :

Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :

Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :

# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name 'fDenyTSConnections' -Value 0

# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force

Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green

Collez ces commandes, puis lancez celles-ci :

Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :

Constatez l’ouverture de session Windows sur votre machine virtuelle migrée :

La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.

Continuons l’exercice de migration en partant cette fois du principe que nous ne pouvons pas créer une machine virtuelle jouant le rôle d’appliance de réplication sur l’hyperviseur, et que celle-ci doit donc alors être obligatoirement déployée sur Azure.

Test II – Appliance de réplication sur Azure :

Pour cette approche, commencez par créer un réseau virtuel Azure comprenant plusieurs sous-réseaux virtuels :

  • Un sous-réseau dédié à l’appliance de réplication.
  • Un sous-réseau dédié à Azure Bastion.
  • Un sous-réseau dédié à la passerelle VPN, pour connecter notre machine virtuelle à migrer à notre appliance de réplication hébergée sur Azure.

Créez une machine virtuelle ayant pour futur rôle l’appliance de réplication :

Connectez-vous à celle-ci via Azure Bastion :

Afin de connecter par la suite la machine virtuelle à migrer à l’appliance de réplication Azure, via une connexion Point à Site, des certificats sont nécessaires pour l’authentification IKEv2.

Pour cela, depuis l’appliance de réplication Azure, générez et exportez les certificats :

  1. Un certificat racine auto-signé (à exporter en .cer pour Azure)
  2. Un certificat client signé par ce root (à exporter en .pfx pour votre machine cliente)

Sur votre appliance de réplication Azure, ouvrez une fenêtre PowerShell, puis lancez le script suivant pour générer le certificat racine :

$rootCert = New-SelfSignedCertificate `
  -Type Custom `
  -KeySpec Signature `
  -Subject "CN=AzureP2SRootCA" `
  -KeyExportPolicy Exportable `
  -KeyLength 2048 `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -FriendlyName "Azure P2S Root CA" `
  -NotAfter (Get-Date).AddYears(10) `
  -HashAlgorithm sha256 `
  -KeyUsageProperty Sign `
  -KeyUsage CertSign

Exportez le certificat public au format CER :

Export-Certificate `
  -Cert $rootCert `
  -FilePath "C:\Certs\AzureP2SRootCA.cer"

Ouvrez le gestionnaire des certificats machines afin de constater sa présence :

Créer et exporter le certificat client signé par le certificat root :

$clientCert = New-SelfSignedCertificate `
  -Type Custom `
  -Subject "CN=AzureP2SClientCert" `
  -KeySpec Signature `
  -KeyExportPolicy Exportable `
  -KeyLength 2048 `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -Signer $rootCert `
  -FriendlyName "Azure P2S Client Cert" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2") `
  -NotAfter (Get-Date).AddYears(2)

Exportez la clef privée au format PFX :

$pwd = ConvertTo-SecureString -String "VotreMotDePasseComplexe!" -Force -AsPlainText
Export-PfxCertificate `
  -Cert $clientCert `
  -FilePath "C:\Certs\AzureP2SClientCert.pfx" `
  -Password $pwd

Ouvrez le gestionnaire des certificats utilisateurs afin de constater sa présence :

Afin d’enregistrer les données du certificat public dans Azure, exportez ce dernier depuis le gestionnaire des certificats utilisateurs :

Choisissez Non, puis cliquez sur Suivant :

Sélectionnez Format Base-64 encodé X.509 (.CER), puis cliquez sur Suivant :

Indiquez le chemin de sauvegarde, puis cliquez sur Suivant :

Ouvrez le fichier en base-64 avec un éditeur, puis copiez tout le texte (sauf -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----) :

Dans le portail Azure, rendez-vous sur la page de votre passerelle VPN, puis démarrez la configuration Point à Site :

Définissez un espace d’adressage, le type de tunnel en IKEv2, collez le texte en Base-64 que vous venez de copier dans Données du certificat racine, puis cliquez sur Enregistrer.

Après quelques instants, constatez la notification Azure suivante :

Télécharger le client VPN afin de configurer plus tard le client VPN Windows natif sur la machine virtuelle à migrer :

Toujours sur appliance de réplication Azure, recherchez le service Azure Migrate :

Cliquez-ici pour commencer un projet de migration :

Cliquez-ici pour créer un projet de migration :

Renseignez toutes les informations demandées, puis cliquez sur Créer :

Cliquez sur Découvrir afin d’installer l’appliance de réplication :

Renseignez tous les champs, puis cliquez sur Créer les ressources :

Conservez les options suivantes :

Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :

Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :

Une fois téléchargé, lancez l’installeur :

Attendez quelques minutes la fin de la décompression :

Conservez ce choix, puis cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Rechercher le fichier clef, puis cliquez sur Suivant :

Conservez ce choix, puis cliquez sur Suivant :

Attendez que les contrôles soit effectués, puis cliquez sur Suivant :

Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :

Si cela n’est pas votre cas, cochez cette case, puis cliquez sur Suivant :

Cliquez sur Suivant :

Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 10 minutes la fin de l’installation :

Cliquez sur Oui :

Collez cette passphrase dans un fichier texte, puis sauvegardez-le :

Une fois l’installation réussie, cliquez sur Terminer :

L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur des machines devant être migrées dans le cloud Azure :

Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’application de réplication :

Attendez le succès de l’opération avec la notification suivante :

Constatez la création de nouvelles ressources dans le groupe de ressources précédemment défini :

Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez seulement l’exécutable ci-dessous :

C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository

Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y :

  • L’exécutable précédemment copié
  • Le fichier texte contenant la passphrase

Rendez-vous sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée sur Azure :

Sur cette machine virtuelle, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :

Installez le certificat root dans le magasin Trusted Root Certification Authorities du gestionnaire des certificats machines :

Installez le certificat client dans le magasin Personal du certificats utilisateurs :

Installez la configuration VPN Windows précédemment téléchargée depuis la page Azure de la passerelle VPN :

Lancez la connexion VPN :

Cliquez sur Connecter :

Vérifiez le statut de la connexion VPN :

Depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication Azure :

Toujours depuis cette VM à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :

Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :

Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :

cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted

UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent  /CSType CSLegacy

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe  /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>

Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :

Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :

Exécutez cette commande pour installer l’agent :

Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :

Avant de continuer, vérifiez le succès des opérations :

Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :

Cliquez ensuite sur Répliquer :

Renseignez toutes les champs, puis cliquez sur Continuer :

Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :

Sélectionner les machines à migrer, puis cliquez sur Suivant :

Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :

Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :

Sélectionnez le type de disque à utiliser pour les machines à migrer, puis cliquez sur Suivant :

Lancez la réplication en cliquant sur Répliquer :

Les notifications suivantes apparaissent alors :

Le compte de stockage commence à recevoir les premières données liées à la réplication :

Dans le coffre Recovery, la réplication commence elle-aussi à être visible :

Environ 1 heure plus tard, celle-ci est terminée :

Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :

Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :

Définissez la destination cible, puis cliquez sur Continuer :

Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :

Quelques secondes plus tard, la notification suivante affiche le succès de déclenchement de la migration :

Cette migration est visible sur notre projet :

Le coffre Recovery nous indique que la migration est terminée :

Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :

Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :

# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name 'fDenyTSConnections' -Value 0

# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force

Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green

Collez ces commandes, puis lancez celles-ci :

Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :

Constatez l’ouverture de session Windows sur votre machine virtuelle migrée sur Azure :

La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.

Conclusion

En définitive, migrer vos VMs vers Azure sans droits d’infra reste une solution de « seconde main » qui dépanne en cas de contraintes fortes, mais elle ne doit pas devenir la norme.

Pour tirer pleinement parti du cloud, il sera toujours préférable de recréer vos ressources selon les principes cloud-native : refactoring des applications, adoption de services managés et optimisation des coûts.

À long terme, cette approche garantit une meilleure scalabilité, une résilience accrue et une plus grande agilité opérationnelle, tout en maîtrisant vos dépenses. Gardez donc cette méthode de contournement sous le coude, mais visez toujours la modernisation et l’optimisation complètes de votre stack dans Azure.

Migrez vos VMs de Gen1 à Gen2

Début février, Microsoft vient d’annoncer une nouvelle fonctionnalité en préversion pour migrer une machine virtuelle, de première génération vers la seconde. Cette bascule de génération est l’occasion de renforcer la sécurité (via Secure Boot et vTPM), d’améliorer les performances (temps de démarrage plus rapides) et d’offrir un support de disques de plus grande capacité. Tout cela, sans avoir besoin de reconstruire la machine virtuelle et en quelques clics.

Depuis quand la génération 2 est disponible sur Azure ?

Microsoft a annoncé la prise en charge des machines virtuelles de génération 2 depuis 2019, avec une généralisation progressive de leur déploiement par la suite.

Il y a quelques jours, Microsoft a annoncé la prévisualisation publique des machines virtuelles de génération 2 sur Azure. Les machines virtuelles de génération 2 prennent en charge un certain nombre de nouvelles technologies telles que l’augmentation de la mémoire, les Intel Software Guard Extensions (SGX) et la mémoire persistante virtuelle (vPMEM), qui ne sont pas prises en charge par les machines virtuelles de génération 1. Mais nous y reviendrons plus tard.

Thomas Maurer

Les machines virtuelles Gen1 restaient toujours utiles pour la migration d’environnements legacy, ou lorsque la compatibilité avec d’anciennes images était nécessaire.

En revanche, les VM Gen 2, avec leur firmware UEFI, offrent la possibilité d’exécuter des fonctionnalités modernes comme la virtualisation imbriquée.

Qu’est-ce que le Trusted Launch ?

Azure propose le lancement fiable pour améliorer de manière fluide la sécurité des machines virtuelles (VM) de génération 2. Le lancement fiable protège contre les techniques d’attaque avancées et persistantes. Le lancement fiable se compose de plusieurs technologies d’infrastructure coordonnées qui peuvent être activées indépendamment. Chaque technologie offre une couche de défense supplémentaire contre les menaces sophistiquées.

Microsoft Learn

Concrètement, Trusted Launch combine plusieurs technologies :

  • Secure Boot : Assure que seuls des composants logiciels signés et vérifiés sont autorisés à se charger pendant le démarrage.
  • vTPM (TPM virtuel) : Fournit une zone sécurisée pour stocker des clés cryptographiques et d’autres informations sensibles.
  • Measured Boot : Enregistre et vérifie les mesures du processus de démarrage pour détecter toute modification non autorisée.

Qu’est-ce que le Secure Boot ?

Le Secure Boot est donc une fonctionnalité de sécurité intégrée au niveau du firmware qui garantit que, lors du démarrage du système, seuls des composants logiciels authentifiés et signés numériquement (bootloader, pilotes, etc.) sont chargés.

Cela permet de prévenir l’exécution de code malveillant dès le démarrage, protégeant ainsi le système contre des attaques telles que les bootkits. En vérifiant l’intégrité et l’authenticité des éléments critiques, Secure Boot contribue à renforcer la sécurité globale de la machine.

Quelles sont les différences entre les 2 générations ?

Ce tableau permet ainsi de choisir la génération en fonction des besoins spécifiques en termes de sécurité, performance et compatibilité :

FonctionnalitéMachines virtuelles Gen 1Machines virtuelles Gen 2Exemple / Explication
1. Type de firmwareBIOSUEFIGen 2 utilise l’UEFI, permettant par exemple l’activation du Secure Boot.
2. Support des systèmes d’exploitation32 bits et 64 bitsExclusivement 64 bitsPour un déploiement Windows Server 2019, seule la Gen 2 est compatible en 64 bits.
3. Interface de disque de démarrageUtilise un contrôleur IDEUtilise un contrôleur SCSILe démarrage sur SCSI en Gen 2 offre de meilleures performances I/O.
4. Secure BootNon disponibleDisponibleLa sécurité est renforcée grâce au Secure Boot dans les VM Gen 2.
5. Virtualisation imbriquéeSupport limitéSupport amélioréPermet d’exécuter Hyper-V dans la VM Gen 2 pour des environnements de test.
6. Temps de démarrageDémarrage plus classiqueDémarrage généralement plus rapideUne VM Gen 2 peut démarrer plus vite grâce à l’architecture UEFI optimisée.
7. Taille maximale du disque systèmeLimité selon les anciens standardsSupport de disques système de plus grande tailleIdéal pour des OS nécessitant un volume de boot plus important.
8. Virtualisation basée sur la sécuritéNon supportéeSupportéePermet d’utiliser des fonctionnalités telles que Windows Defender Credential Guard.
9. Gestion de la mémoireStandardOptimisée pour des performances supérieuresAmélioration dans la gestion de la mémoire et la réactivité du système dans la Gen 2.
10. Support des périphériques modernesCompatible avec du matériel plus ancienConçu pour exploiter les dernières technologies matériellesPar exemple, intégration possible d’un TPM virtuel pour renforcer la sécurité.
11. Déploiement et gestionBasé sur des modèles plus anciensOptimisé pour une gestion moderne via Azure Resource ManagerFacilite l’intégration avec les nouvelles options de déploiement automatisé dans Azure.
12. Compatibilité des imagesCompatible avec un large éventail d’images anciennesRestreint aux images récentes optimisées pour UEFIGen 1 permet d’utiliser des images plus anciennes, alors que Gen 2 cible les OS modernes.

En résumé, le choix entre Gen1 et Gen2 se fera principalement en fonction des exigences de compatibilité et de sécurité :

  • Gen1 convient aux scénarios où l’héritage et la compatibilité avec des images plus anciennes priment.
  • Gen2 est privilégiée pour bénéficier d’une meilleure sécurité et de performances optimisées, notamment grâce aux fonctionnalités comme Secure Boot et le vTPM.

Puis-je utiliser des Gen1/Gen2 avec toutes les familles de machines virtuelles Azure ?

Non. Et pour vous aider, Microsoft vous met à disposition cette liste, disponible via ce lien.

Toutes les images OS sont-elles compatible avec Gen2 ?

Non. Les machines virtuelles Gen2 prennent en charge que certaines images OS :

  • Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012
  • Windows 11 Professionnel, Windows 11 Entreprise
  • Windows 10 Professionnel, Windows 10 Entreprise
  • SUSE Linux Enterprise Server 15 SP3, SP2
  • SUSE Linux Enterprise Server 12 SP4
  • Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS
  • RHEL 9,5, 9.4, 9.3, 9.2, 9.1, 9.0, 8.10, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 8.0, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0
  • Cent OS 8.4, 8.3, 8.2, 8.1, 8.0, 7.7, 7.6, 7.5, 7.4
  • Oracle Linux 9.3, 9.2, 9.1, 9.0, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 7.9, 7.9, 7.8, 7.7

Puis-je basculer une VM de Gen1 à Gen2, et inversement ?

Anciennement, il n’était pas possible de facilement convertir directement une VM existante de Gen1 vers Gen2, en raison des différences fondamentales au niveau du firmware et de la configuration des disques. Pour migrer vers une Gen2, il fallait alors bien souvent recréer la machine virtuelle dans la génération cible.

Qu’est-ce que MBR2GPT ?

MBR2GPT est un outil en ligne de commande de Microsoft qui permet de convertir un disque partitionné en MBR vers le format GPT sans perte de données, facilitant ainsi la transition d’un mode BIOS hérité vers un démarrage UEFI.

Depuis peu, Microsoft vient d’ajouter une fonctionnalité, encore en préversion, pour basculer de Gen1 à Gen2 en quelques clics, dont la source est disponible juste ici.

Enfin, voici d’ailleurs une vidéo de Microsoft parlant en détail de l’outil MBR2GPT :

Comme indiqué dans cette vidéo, l’outil MBR2GPT va travailler sur la conversation des partitions de l’OS :

Le processus sur Azure se fait en seulement quelques clics, et je vous propose de tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser ce test de conversation de génération (encore en préversion), il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons par créer une machine virtuelle de première génération.

Etape I – Création de la machine virtuelle Gen1 :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle compatible à la fois Gen1 et Gen2 :

Renseignez les informations de l’administrateur local, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion pour continuer.

L’étape suivante consiste à lancer l’utilitaire intégré MBR2GPT afin de valider et de transformer la partition du disque OS au format GPT, et aussi d’ajouter la partition système EFI requise pour la mise à niveau en Gen2.

Etape II – Transformation du disque OS depuis MBR vers GPT :

Une fois Azure Bastion correctement déployé, saisissez les identifiants renseignés lors de la création de votre machine virtuelle :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

Confirmez le statut du mode BIOS en Legacy :

Les propriétés du disque OS nous confirme l’utilisation du style de partition MBR (Master Boot Record) :

Depuis le menu Démarrer de votre machine virtuelle, puis cliquez sur Exécutez pour ouvrir le programme cmd :

Lancez la commande MBR2GPT suivante pour exécuter la validation MBR vers GPT :

MBR2GPT /validate /allowFullOS

Assurez-vous que la validation de l’agencement du disque se termine avec succès. Ne continuez pas si la validation du disque échoue :

Lancez la commande MBR2GPT suivante pour exécuter la conversion MBR vers GPT :

MBR2GPT /convert /allowFullOS

Obtenez le résultat suivant :

Cliquez-ici pour fermer votre session Windows :

Une fois la session Windows fermée, cliquez-ici pour fermer l’onglet ouvert pour Azure Bastion :

Depuis le portail Azure, arrêtez votre machine virtuelle :

Confirmez votre choix en cliquant sur Oui :

Quelques minutes plus tard, confirmez que la machine virtuelle est en état Arrêté (désallouée).

Encore en préversion, l’activation des mesures de sécurité sur la machine virtuelle n’est pas possible depuis le portail Azure. Il faut donc utiliser Azure Cloud Shell.

Etape III – Activation du vTPM et du Secure Boot :

Mais avant d’activer le vTPM et le Secure Boot sur notre machine virtuelle Azure, il est nécessaire d’activer la fonctionnalité Gen1ToTLMigrationPreview, encore en préversion, sur notre souscription Azure.

Pour cela, cliquez sur le bouton suivant pour ouvrir la fenêtre d’Azure Cloud Shell :

Une fois Azure Cloud Shell d’ouvert en mode PowerShell, saisissez la commande suivante afin de voir si celle-ci est déjà activée :

Get-AzProviderFeature -FeatureName "Gen1ToTLMigrationPreview" -ProviderNamespace "Microsoft.Compute"

Si la fonctionnalité Gen1ToTLMigrationPreview n’est pas encore activée, saisissez la commande suivante :

Register-AzProviderFeature -FeatureName "Gen1ToTLMigrationPreview" -ProviderNamespace "Microsoft.Compute"

Relancez la commande suivante afin de voir si celle-ci a fini son activation :

Get-AzProviderFeature -FeatureName "Gen1ToTLMigrationPreview" -ProviderNamespace "Microsoft.Compute"

Environ 10 minutes plus tard, le statut de la fonctionnalité devrait être comme ceci :

Toujours sur Azure Cloud Shell, saisissez la commande suivante afin de constater la présence de votre machine virtuelle Azure :

Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm

Activez le lancement UEFI en définissant -SecurityType sur TrustedLaunch :

Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Update-AzVM -SecurityType TrustedLaunch -EnableSecureBoot $true -EnableVtpm $true

Validez la mise à jour du profil de sécurité le dans la configuration de la VM :

# Following command output should be `TrustedLaunch 

(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.SecurityType

# Following command output should return `SecureBoot` and `vTPM` settings
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.Uefisettings

Le changement de génération de notre machine virtuelle est également visible sur le portail Azure :

De même que le profil de sécurité ainsi que les options activées (une fois que vous avez activé le Trusted launch, les machines virtuelles ne peuvent plus être ramenées au type de sécurité Standard) :

Ces options sont encore modifiables depuis l’écran ci-dessous (Microsoft recommande d’activer le Secure Boot si vous n’utilisez pas de pilotes personnalisés non signés) :

Redémarrez votre machine virtuelle :

Reconnectez-vous à celle-ci via le service Azure Bastion :

Constatez la bonne ouverture de session Windows :

Confirmez le statut du mode BIOS en UEFI, de même que l’activation du Secure Boot :

Relancer la validation de l’agencement du disque sur un disque déjà configuré en GPT provoquera une erreur logique :

Les propriétés du disque OS nous confirme l’utilisation du style de partition GUID (GPT), qui est un schéma de partitionnement moderne qui utilise des identifiants uniques (GUID) pour chaque partition :

Etape IV – Activation de services annexes :

Une fois la bascule en Gen2 effectuée, il n’est plus possible d’activer la sauvegarde via Azure Backup avec une police de type standard :

D’ailleurs, l’activation de la sauvegarde après le changement de Gen1 à Gen2 n’a posé aucun souci :

Il en a été de même pour l’activation de réplication pour une machine migrée de Gen1 à Gen2 :

Dans le cadre d’un test de failover, la nouvelle machine virtuelle, créée temporairement, est bien elle aussi en génération 2 :

La connexion via Azure Bastion sur cette machine virtuelle temporaire est bien fonctionnelle :

Conclusion

En conclusion, cette procédure toute simple et réalisée en quelques clics avec MBR2GPT nous démontre que migrer vos machines virtuelles de Gen1 à Gen2 représente bien plus qu’un simple changement de firmware :

  • Grâce à une sécurité renforcée avec Secure Boot et vTPM, des performances accrues et une prise en charge des disques de plus grande taille.
  • Adopter Gen2, c’est ainsi investir dans une plateforme plus robuste, performante et alignée avec les exigences actuelles de la sécurité informatique.

Windows Serveur 2025 PAYG

Microsoft innove pour Windows Serveur 2025 et propose de payer la licence via un abonnement paiement à l’utilisation (PAYG) grâce à Azure Arc ! Avec cette option, vous déployez une VM et payez uniquement pour l’utilisation. Cette fonctionnalité est facturée directement sur votre abonnement Azure. Vous pouvez désactiver le paiement à l’utilisation à tout moment. Enfin, le tarif semble assez intéressant 😎

Une vidéo de John existe déjà sur le sujet 🙏💪 :

Dans cet article, je vous propose de tester et surtout de voir combien cela coûte💰:

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de licence PAYG sur Windows Serveur 2025, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de tester cette fonctionnalité de licensing utilisant Azure Arc, nous allons avoir besoin de lier nos VMs de test à une souscription Azure présente sur notre tenant Microsoft.

Pour cela, je vous propose donc de simuler plusieurs VMs sous Windows Serveur 2025 grâce à un environnement Hyper-V créé sous Azure.

Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte Hyper-V :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle hôte :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3 :

Renseignez les informations de l’administrateur local, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows Serveur 2025), créée plus tard dans notre machine virtuelle Hyper-V, puis cliquez sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle Hyper-V :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :

Renseignez les identifiants renseignés lors de la création de votre VM Hyper-V :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM Hyper-V :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Sur celui-ci, créez un nouveau volume au format NTFS :

Une fois connecté sur votre machine virtuelle Hyper-V, ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux rôles suivants :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des rôles se termine :

Lancez la commande suivante pour lancer un redémarrage de votre VM Hyper-V :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour se reconnecter à celle-ci, toujours via Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel Hyper-V de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, et le serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Depuis la console Server Manager, ouvrez Hyper-V Manager :

Ouvrez le menu suivant :

Contrôlez la présence de votre switch virtuel créé précédemment :

L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle sous Windows Serveur 2025.

Etape II – Création de la machine virtuelle :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Serveur 2025, puis de lancer l’installation.

Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.

Dans mon cas, je suis passé par Visual Studio pour télécharger l’image au format ISO de Windows Serveur 2025 :

Attendez quelques minutes pour que le téléchargement se termine :

Une fois le fichier téléchargé, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows Serveur 2025 :

Cliquez sur Suivant :

Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :

Pensez à bien choisir Génération 2 :

Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO de Windows Serveur 2025 téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :

Une fois la machine virtuelle créée, cochez la case suivante pour activer TPM, puis augmenter le nombre de processeurs :

Double-cliquez sur votre machine virtuelle invitée, puis cliquez-ici pour lancer son démarrage :

La machine virtuelle est maintenant prête à recevoir Windows Serveur 2025. Suivez toutes les étapes de l’installation pour le configurer.

Etape III – Installation de Windows Serveur 2025 :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Définissez la langue de votre clavier, puis cliquez sur Suivant :

Lancez l’installation de Windows Serveur 2025 :

Cliquez-ici afin de ne pas renseigner de clef de licence Windows Serveur 2025 pour utiliser par la suite une licence en PAYG :

Choisissez une version Desktop, puis cliquez sur Suivant :

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

Lancez l’installation de Windows Serveur 2025 :

Attendez maintenant quelques minutes la fin de l’installation de Windows Serveur 2025 :

Attendez que le redémarrage se poursuivre :

Définissez un mot de passe à votre compte local, puis cliquez sur Suivant :

Déverrouillez la session Windows :

Renseignez à nouveau le mot de passe de votre compte administrateur pour ouvrir la session :

Adaptez la configuration des remontées télémétriques, puis cliquez sur Accepter :

Windows Serveur 2025 est maintenant installé sur notre machine virtuelle. Il nous faut maintenant configurer Azure Arc afin que la liaison avec Azure puisse mettre en place la licence PAYG.

Etape IV – Configuration d’Azure Arc :

Une fois la session Windows ouverte, ouvrez les paramètres systèmes depuis le menu Démarrer :

Constatez l’absence de licence Windows Serveur 2025 active, puis cliquez dessus :

L’erreur suivante concernant l’activation apparaît alors :

Ouvrez le programme de configuration d’Azure Arc déjà préinstallé :

Cliquez sur Suivant :

Attendez quelques instants afin que l’installation se finalise :

Une fois Azure ARC installé, cliquez sur Configurer :

Cliquez sur Suivant :

Cliquez-ici afin de générer un code d’activation à usage unique :

Copiez le code généré :

Rendez-vous sur la page web indiquée, puis collez le code précédemment copié :

Authentifiez-vous avec un compte Azure disposant des droits nécessaires :

Cliquez sur Suivant :

Sélectionnez Pay-as-you-go, puis cliquez sur Suivant :

Sur le dernier écran de la procédure de configuration, sélectionnez Terminer :

Constatez la bonne connexion à Azure Arc via l’icône de notification suivant :

La liaison via Azure Arc est maintenant opérationnelle, mais la licence Windows Serveur 2025 n’est pas encore appliquée sur votre machine virtuelle. Nous allons devoir terminer la configuration de celle-ci depuis le portail Azure.

Etape V – Gestion de la licence PAYG :

Retournez sur la page système d’activation de Windows afin de constater la présence d’un autre message d’erreur :

Retournez sur le portail Azure, puis cliquez sur la nouvelle ressource Azure représentant notre machine virtuelle et créée après la fin de la configuration d’Azure Arc :

Dans le menu Licences du volet gauche, cochez la case Pay-as-you-go with Azure, puis sélectionnez Confirmer :

Attendez quelques minutes afin de constater la bonne activation de celle-ci :

Cette information est également visible depuis la page principale de la ressource Arc :

Rouvrez la page système d’activation de Windows afin de constater la bonne activation de la licence Windows :

Afin de comprendre un peu mieux les mécanismes de licences PAYG via Azure Arc, j’ai créé au total 4 machines virtuelles sur mon serveur Hyper-V :

  • Machine virtuelle Windows Serveur Standard 4 cœurs,
  • Machine virtuelle Windows Serveur Standard 4 cœurs éteinte par la suite,
  • Machine virtuelle Windows Serveur Datacentre 4 puis 8 cœurs par la suite,
  • Machine virtuelle Windows Serveur Standard 12 cœurs.

J’y ai également configuré Azure Arc, et activé les licences Windows Serveur 2025 via ma souscription Azure :

Mon environnement de test est maintenant en place, il ne nous reste qu’à attendre plusieurs jours afin de comprendre les coûts facturés par Microsoft via ma souscription Azure.

Etape VI – Analyse des coûts de licence :

Afin de comprendre les coûts de facturation pour les différentes machines virtuelles fonctionnant sous Windows Serveur 2025 PAYG, je vous propose d’utiliser le Gestionnaire des coûts Azure :

Utilisez les différents filtres disponibles pour identifier les coûts qui vous intéressent :

Commençons par analyser les 7 premiers jours suivant la configuration de mon environnement de test :

Comme le montre le gestionnaire des coûts ci-dessus, ainsi que la documentation Microsoft ci-dessous, aucun frais de licence n’est facturé durant les 7 premiers jours :

En outre, vous pouvez utiliser le paiement à l’utilisation gratuitement pour les sept premiers jours après l’avoir activé en tant qu’essai.

Microsoft Learn

Pour plus de clarté, j’ai également transposé ces premiers résultats dans un tableau Excel :

J’ai continué avec les 3 jours suivants, cette fois facturés par Microsoft :

Comme le montre le gestionnaire des coûts ci-dessus, ainsi que la documentation Microsoft ci-dessous, des frais journaliers en fonction du nombre de cœurs de chaque VM sont facturés :

Pour plus de clarté, j’ai également transposé ces résultats dans un tableau Excel :

Deux informations sont intéressantes dans ce tableau :

  • La tarification par cœur Microsoft semble identique pour des machines sous licence Standard ou Datacentre.
  • Il semble que le prix $33.58 indiqué par Microsoft dans la documentation ne corresponde pas à un prix unitaire relevé par cœur, mais pour 2 cœurs :

J’ai ensuite effectué par la suite 2 modifications sur 2 de mes machines virtuelles de test :

  • Arrêt d’une machine virtuelle
  • Augmentation du nombre de cœurs

Pour plus de clarté, j’ai également transposé ces résultats dans un tableau Excel :

  • L’arrêt de la machine virtuelle le 24 décembre montre bien une baisse des coûts de licence pour les jours suivants.
  • Le passage de 4 à 8 cœurs indique bien un doublement des coûts de licences pour les jours suivants.

Voici enfin le même tableau Excel dans sa totalité

Conclusion

En résumé, cette nouvelle approche pour licencier des serveurs en dehors du cloud est facile à mettre en œuvre et semble très intéressante financièrement. Les tests ont montré qu’un arrêt de machine virtuelle réduit les coûts de licence, tandis que l’augmentation du nombre de cœurs entraîne une augmentation proportionnelle des coûts.

Ces observations soulignent l’importance de gérer judicieusement les ressources et les configurations de vos machines virtuelles pour toujours optimiser au mieux les coûts de licence.

Enfin, pour la gestion des licences Azure, il est fortement recommandé de considérer Azure Hybrid Benefit pour la majorité des machines virtuelles sous Windows pour maximiser les économies.

de VMware à Azure Local

La migration des machines virtuelles depuis VMware vers Azure Local via l’outil Azure Migrate a récemment été annoncée en préversion. Cette nouveauté chez Microsoft représente une avancée significative dans les migrations automatisées vers le cloud hybride. Cette nouvelle fonctionnalité d’Azure Migrate permet donc aux organisations de transférer leurs charges de travail sur site vers une infrastructure Azure Local tout en minimisant les interruptions.

Depuis quelques déjà, il existe sur le marché d’autres solutions externes qui proposent la migration de machines virtuelles hébergées sur VMware vers un cluster Azure Local :

Azure nous facilite donc la chose en l’intégrant dans Azure Migrate. En parlant d’Azure Migrate, un premier article sous forme d’exercice est disponible juste ici. Il vous permet de tester la migration de machines virtuelles Hyper-V vers Azure :

De façon générale, voici quelqu’un des principaux avantages à utiliser Azure Migrate :

  • Aucune préparation requise : La migration ne nécessite pas l’installation d’agents sur les machines virtuelles hébergés sous Hyper-V ou VMware.
  • Contrôle via le portail Azure : Les utilisateurs peuvent gérer et suivre toutes les étapes de leur migration directement depuis le portail Azure.
  • Flux de données local : Les données restent sur site pendant la migration, ce qui réduit les risques de latence.
  • Temps d’arrêt minimal : La solution permet de migrer les VMs avec un impact minimal sur les opérations en cours.

Aujourd’hui, nous sommes ravis d’annoncer l’avant-première publique de la fonctionnalité Azure Migrate permettant de migrer des machines virtuelles de VMware vers Azure Local, une amélioration significative de nos capacités de migration vers le cloud qui s’étend de manière transparente jusqu’à la périphérie, conformément à notre approche du cloud adaptatif.

Microsoft Tech Community

L’écran ci-dessous nous montre la section dédiée à la migration de ressources vers Azure Local :

Comment se passe la migration VMware -> Azure Local ?

Les grandes étapes d’une migration vers Azure Local sont très proches de celles vers Azure. Quelques étapes et composants nécessaires différent légèrement :

  • Un projet doit toujours être créé via Azure Migrate depuis le portail Azure
  • 2 appliances (VMware et Azure Local) doivent être créées et configurées
    • Une appliance virtuelle s’exécutant sur les serveurs VMware
    • Une seconde appliance virtuelle s’exécutant sur le cluster Azure Local

Voici les principales phases du processus de migration Azure Migrate :

Phase de migrationDescription
1. PréparationPréparez-vous à migrer en complétant les prérequis. Déployez et configurez votre cluster Azure Local. Créez un projet Azure Migrate et un compte de stockage Azure.
2. DécouverteCréez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. RéplicationConfigurez l’appliance cible sur Azure Local et sélectionnez les VMs à répliquer.
4. Migration et vérificationMigrez les VMs vers Azure Local et vérifiez leur bon fonctionnement après la migration.

Quels sont les systèmes d’exploitation pris en charge ?

Pour que cette migration puisse fonctionner, seulement certaines versions d’OS sont actuellement prises en charge :

ComposantSystèmes d’exploitation pris en charge
Environnement VMware sourceVMware vCenter Server version 8.0
VMware vCenter Server version 7.0
VMware vCenter Server version 6.7

VMware vCenter Server version 6.5
Appliance VMware Windows Server 2022
Environnement Azure Local cibleAzure Local, version 23H2
Appliance Azure LocalWindows Server 2022
Machine virtuelle invitée (Windows)Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2*
Machine virtuelle invitée (Linux)Red Hat Linux 6.x, 7.x
Ubuntu Server et Pro. 18.x
CentOS 7.x
SUSE Linux Enterprise 12.x
Debian 9.x

Microsoft liste toutes les conditions requises pour envisager cette migration juste ici.

Puis-je créer mon projet Azure Migrate dans toutes les géographies Azure ?

Pour le moment, les métadonnées de votre projet Azure Migrate peuvent être uniquement stockées dans une des géographies Azure suivantes pour les migrations vers Azure Local :

GéographiesRégions
Asie-PacifiqueAsie Sud-Est, Asie Est
EuropeEurope Nord – Europe Ouest
États-UnisUSA Centre, USA Ouest2

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Azure Local via Azure Migrate. Pour tout cela, il nous faut :

  • Un tenant Microsoft
  • Une souscription Azure active
  • Un environnement Azure Local opérationnel
  • Un environnement VMware opérationnel

Commençons par la création du projet sur Azure Migrate, puis la configuration de l’appliance sur l’environnement VMware.

Etape I – Configuration VMware :

Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

Sélectionnez le menu suivant, puis cliquez-ici pour créer votre projet de migration :

Renseignez les différentes informations de votre projet en prenant en compte les géographies supportant ce scénario de migration, puis cliquez sur Créer :

Une fois le projet créé, cliquez-ici afin d’installer une appliance sur l’environnement VMware :

Définissez la cible de migration comme étant sur Azure Local, puis la source comme étant VMware :

Nommez votre appliance VMware, puis cliquez ici pour générer une clef d’association (entre l’appliance et votre projet d’Azure Migrate) :

Une fois la clef générée, copiez la dans votre bloc-notes :

Lancez le téléchargement de votre appliance afin de pouvoir en disposer par la suite sur votre environnement VMware :

Afin d’y accéder plus facilement sur vSphere, vous pouvez créer un compte de stockage publique :

Dans ce compte de stockage, créez un conteneur blob :

Une fois l’image de l’appliance téléchargée localement, utilisez l’outil azcopy afin de déposer votre image OVA sur votre compte de stockage blob :

Vérifiez la présence de l’image OVA sur votre compte de stockage, puis cliquez dessus :

Récupérez l’URL blob de votre image OVA accessible publiquement :

Depuis votre console vSphere, cliquez-ici pour créer une nouvelle machine virtuelle via la fonction de template OVF :

Collez l’URL de votre image OVA, puis cliquez sur Suivant :

Confirmez votre confiance en cliquant sur Oui :

Nommez votre machine virtuelle appliance, ainsi que son dossier, puis cliquez sur Suivant :

Sélectionnez la ressource de calcul VMware adéquate, cochez la case de démarrage après création, puis cliquez sur Suivant :

Vérifiez toutes les informations dont l’OS utilisé par l’appliance VMware, puis cliquez sur Suivant :

Définissez la ressource de stockage VMware adéquate, puis cliquez sur Suivant :

Choisissez le réseau virtuel VMware adéquat, puis cliquez sur Suivant :

Vérifiez toutes les informations avant la création de la machine virtuelle, puis cliquez sur Finir :

Constatez la création de 2 tâches, puis attendez quelques minutes :

  • vSphere VMware rapatrie l’image OVA,
  • vSphere créé la machine virtuelle appliance

Une fois la VM créée, installez-y les outils VMware :

Cliquez sur Mettre à jour :

Une fois la VM démarrée, ouvrez la console web de celle-ci :

Attendez la finalisation de la préparation de Windows Server :

Acceptez les Termes et conditions :

Configurez le mot de passe du compte administrateur (clavier US), puis cliquez sur Finaliser :

Connectez-vous avec le mot de passe configuré juste avant :

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet :

Acceptez les Termes et conditions d’Azure Migrate :

Laissez faire la connexion entre votre appliance VMware et Azure :

Collez la clef de votre projet Azure Migrate, puis cliquez sur Vérifier :

Une fois vérifiée, attendez quelques minutes pour constater d’éventuelles mises à jour de l’appliance VMware :

Rafraîchissez la page au besoin si le système vous le demande :

Authentifiez-vous avec votre compte Azure :

Cliquez ici pour utiliser le mécanisme d’authentification Azure PowerShell pour l’appliance VMware :

Collez le code donné précédemment, puis cliquez sur Suivant :

Choisissez le compte Azure aux droits RBAC adéquats :

Cliquez sur Continuer pour autoriser l’authentification Azure :

Fermez la fenêtre de navigation internet :

Attendez quelques minutes le temps de l’enrôlement de l’appliance VMware dans Azure Migrate :

Comme indiqué récupérez l’applicatif VMware Virtual Disk Developpement Kit depuis une source internet, copiez le dossier, puis cliquez sur Vérifier :

Afin que l’appliance VMware puisse découvrir les machines virtuelles en fonctionnement sur vCenter, cliquez-ici pour ajouter les informations d’identification :

Cliquez ici pour ajouter des informations sur les VMs hébergées sur VMware à analyser :

Vérifiez que la validation s’est effectuée avec succès :

Comme nous n’avons pas besoin d’effectuer d’analyse d’applications particulières, désactivez cette fonction :

Cliquez ici pour démarrer la découverte des machines virtuelles sur VMware :

Mais, avant de retourner sur Azure, n’oubliez pas de renseigner et de valider les informations d’identification de votre cluster Azure Local :

La découverte est terminée et les résultats sont disponibles sur Azure :

Retournez sur le portail Azure afin de rafraîchir la page de votre projet Azure Migrate :

Quelques rafraîchissements plus tard, les serveurs VMware commencent à faire leur apparition :

La configuration VMware est maintenant terminée, nous allons pouvoir nous concentrer sur la seconde partie de la configuration dédiée à Azure Local.

Etape II – Configuration Azure Local :

Toujours sur votre projet Azure Migrate, cliquez alors sur le bouton Répliquer :

Renseignez les informations suivantes, puis cliquez sur Continuer :

  • Sélectionnez le type de service : Serveurs ou machines virtuelles (VM)
  • Sélectionnez la destination : Azure Local
  • Sélectionnez la source : VMware vSphere
  • Pour l’appliance Azure Migrate : l’appliance créée sur votre vCenter

Renseignez les informations de votre cluster Azure Local, puis cliquez sur Suivant :

Indiquez un nom pour l’appliance Azure Local, générez la clé, puis copiez cette dernière dans un bloc note :

Télécharger le fichier ZIP de votre appliance Azure Local :

À l’aide d’Hyper-V Manager, créez une nouvelle VM sous Windows Server 2022, avec 80 Go (min) de stockage sur disque, 16 Go (min) de mémoire et 8 processeurs virtuels sur un de vos nœuds Azure Local, puis démarrez celle-ci :

Une fois authentifié en mode administrateur sur cette appliance Azure Local, copiez et collez le fichier zip téléchargé.

En tant qu’administrateur, exécutez le script PowerShell suivant à partir des fichiers extraits pour installer l’appliance Azure Local :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
.\AzureMigrateInstaller.ps1

Choisissez l’option 4 :

Choisissez l’option 1 :

Choisissez l’option 1 :

Confirmez votre action avec Y :

Attendez quelques minutes la fin du traitement :

Confirmez votre action avec l’option A :

Confirmez votre action avec N :

Redémarrez la VM, reconnectez-vous avec le même compte administrateur, ouvrez Azure Migrate Target Appliance Configuration Manager à partir du raccourci du bureau, puis collez la clef précédemment copiée :

Attendez quelques minutes le temps de l’enrôlement de l’appliance Azure Local dans votre projet Azure Migrate, puis authentifiez-vous via Azure PowerShell :

Une fois l’appliance Azure Local enregistrée, sous Gérer les informations du cluster Azure Local, sélectionnez Ajouter des informations de cluster, puis cliquez sur Configurer :

Attendez quelques minutes la fin de la configuration :

Retournez sur le projet Azure Migrate depuis le portail Azure, puis cliquez-ici :

Constatez l’apparition l’appliance Azure Local, puis cliquez sur Suivant :

Choisissez la machine virtuelle à migrer sur votre cluster Azure Local, puis cliquez sur Suivant :

Définissez la configuration réseau et stockage de votre machine virtuelle migrée, puis cliquez sur Suivant :

Configurez le nombre de vCPU et la RAM, puis cliquez sur Suivant :

Sélectionnez les disques que vous souhaitez répliquer, puis cliquez sur Suivant :

Dans ce dernier onglet, assurez-vous que toutes les valeurs sont correctes, puis sélectionnez Répliquer :

Restez sur cette page jusqu’à la fin du processus (cela peut prendre 5 à 10 minutes). Si vous quittez cette page, les objets liés à la réplication ne seront pas entièrement créés, ce qui entraînera un échec de la réplication et, par la suite, de la migration.

Les 2 notifications Azure suivantes devraient alors s’afficher :

De retour sur votre projet Azure Migrate, vous pouvez suivre votre réplication depuis le menu suivant :

Une section dédiée à Azure Local est disponibles et affiche les réplications, les opérations et les événements, cliquez-ici pour avoir plus de détail sur la réplication en cours :

Les différentes étapes de réplication se suivent :

La progression via un pourcentage est même visible :

La phase finale de synchronisation des données arrive par la suite :

La prochaine étape consistera justement à faire la migration pour basculer notre VM vers Azure Local.

Etape III – Migration VMware -> Azure Local :

Une fois la réplication terminée, la machine virtuelle répliquée sur Azure Local est visible en cliquant ici :

Cliquez alors sur le statut de la machine virtuelle vous indiquant que la migration est prête :

Déclenchez la migration vers Azure Local en cliquant ici :

La notification Azure suivante apparaît alors :

Le travail de bascule planifiée est visible dans le menu suivant :

Les différentes étapes de migration vers Azure Local se suivent :

Rafraîchissez cette fenêtre plusieurs fois afin de constater le succès du processus :

Constatez l’apparition de la machine virtuelle migrée sur la page Azure de votre cluster Azure Local, puis cliquez dessus :

Copiez l’adresse IP privée de cette nouvelle machine virtuelle créée sous Azure Local :

Etape IV – Actions post-migration :

Dans mon scénario, j’ai utilisé une connexion Azure Virtual Desktop hébergé sur mon cluster Azure Local :

Une fois sur le réseau de votre Azure Local, ouvrez une connexion RDP vers l’adresse IP de votre machine virtuelle migrée :

Rentrez les identifiants de l’administrateur local, puis cliquez sur OK :

Constatez la bonne ouverture de session Windows sur votre machine virtuelle migrée :

Si la migration vous semble réussie, retournez sur votre projet Azure Migrate afin de déclarer la migration vers Azure Local comme étant complète :

Confirmez votre choix d’arrêt de réplication en cliquant sur Oui :

La notification Azure suivante apparaît alors :

L’action de Terminer la migration ne fera que nettoyer la réplication en supprimant le travail de suppression de l’élément protégé – cela n’affectera pas votre VM migrée.

Une fois la ressource migrée supprimée, elle est également supprimée de la vue Réplications. Vous verrez également le travail de migration de la VM disparaître de la vue Réplications :

Retournez sur la machine virtuelle sous Azure Local afin de finaliser l’intégration de cette VM dans l’hyperviseur Azure Local :

Il nous faut donc activer la gestion des invités pour la machines virtuelle migrée en y attachant l’ISO.

Pour cela, connectez-vous à un serveur Azure Local, puis exécutez la commande CLI suivante dans une fenêtre PowerShell sur la VM migrée pour laquelle l’agent invité doit être activé :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-vm-config-agent true

Affichez les informations de l’installeur de l’agent :

Installez l’ISO de l’agent invité sur la VM migrée comme suit :

$d=Get-Volume -FileSystemLabel mocguestagentprov;$p=Join-Path ($d.DriveLetter+':\') 'install.ps1';powershell $p

Activez la gestion de l’invité après que l’agent de l’invité a été installé de la manière suivante :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-agent true

Cette dernière étape n’a malheureusement pas fonctionné chez moi, comme l’indique encore le statut du management invité :

Le sujet est encore en discussion sur le forum Tech Community de Microsoft :

Nul doute que le souci va être corrigé sous peu ! Une page de résolution des problèmes a aussi été créée par Microsoft juste ici, ainsi qu’une FAQ.

Conclusion

En choisissant de migrer de VMware vers Azure Local, les entreprises s’engagent dans une transformation stratégique qui allie flexibilité et modernité.

Cette transition permet non seulement de consolider les ressources locales avec la puissance d’Azure, mais aussi de réduire les coûts opérationnels et de simplifier la gestion des infrastructures hybrides.

Orchestrez votre AVD

Avec la toute nouvelle fonctionnalité appelée Session host update d’Azure Virtual Desktop, Microsoft vient de lâcher une petite bombe dans la gestion des VMs AVD. Imaginez Azure Virtual Desktop remplaçant comme un grand des VMs obsolètes pour les remplacer par d’autres basées sur votre toute dernière image ? Vous ne rêvez pas, tout cela est maintenant disponible en préversion !

Comment faisait-on avant pour mettre à jour son AVD ?

Avant l’introduction de cette nouvelle fonctionnalité, la mise à jour des hôtes de session Azure Virtual Desktop (AVD) nécessitait une gestion manuelle plus intensive. Ce processus impliquait souvent plusieurs étapes, telles que :

  1. Planification des mises à jour : Identifier les hôtes de session nécessitant des mises à jour et planifier les fenêtres de maintenance.
  2. Exécution des mises à jour : Utiliser des scripts ou des outils pour appliquer les mises à jour sur chaque hôte de session.
  3. Vérification et validation : S’assurer que les mises à jour ont été appliquées correctement et que les hôtes de session fonctionnent comme prévu.

Ces étapes pouvaient être chronophages et nécessitaient une surveillance constante pour minimiser les interruptions de service et garantir la conformité des systèmes.

Qu’est ce que les nouvelles Mises à jour AVD ?

La nouvelle fonctionnalité simplifie ce processus en automatisant la gestion des mises à jour, réduisant ainsi la charge administrative et améliorant l’efficacité opérationnelle.

Microsoft nous décrit cette toute nouvelle fonctionnalité AVD en seulement quelques phrases :

La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session.

La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour.

Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.

Microsoft Learn

Que peut-on modifier dans une mise à jour AVD ?

Beaucoup de paramètres sont déjà modifiables d’une version à l’autre de votre environnement AVD :

  • Image de machine virtuelle
  • Taille de la machine virtuelle
  • Type de disque de machine virtuelle
  • Type de sécurité de la machine virtuelle
  • Informations d’identification de jonction de domaine Active Directory
  • Inscription à Microsoft Intune
  • Informations d’identification de l’administrateur local
  • Script PowerShell de configuration personnalisé

Quid des machines virtuelles AVD éteintes ou avec le mode de drainage ?

L’état d’alimentation et le mode de drainage existants des hôtes de session sont respectés. Vous pouvez effectuer une mise à jour sur un pool d’hôtes où tous les hôtes de session sont désalloués pour réduire les coûts.

Existe-t-il des limitations ?

Encore en préversion Microsoft nous liste les principales limitations juste ici :

  • La mise à jour de l’hôte de session est uniquement disponible dans le cloud Azure global. Il n’est pas disponible dans d’autres clouds, tels qu’Azure US Government ou Azure exploité par 21Vianet.
  • Pour les hôtes de session créés à partir d’une image partagée Azure Compute Gallery disposant d’un plan d’achat, le plan n’est pas conservé lorsque les hôtes de session sont mis à jour. Pour vérifier si l’image que vous utilisez pour vos hôtes de session dispose d’un plan d’achat, vous pouvez utiliser Azure PowerShell ou Azure CLI.
  • La taille du disque du système d’exploitation ne peut pas être modifiée pendant une mise à jour. Le service de mise à jour utilise par défaut la même taille que celle définie par l’image de la galerie.
  • Lors d’une mise à jour, vous ne pouvez pas ajouter d’autres hôtes de session au pool d’hôtes.
  • Si une mise à jour échoue, le pool d’hôtes ne peut pas être supprimé tant que la mise à jour n’est pas annulée.
  • Si vous décidez de créer une image extraite d’un hôte de session existant que vous utilisez ensuite comme image source pour la mise à jour de votre hôte de session, vous devez supprimer le dossier C:\packages\plugin avant de créer l’image. Dans le cas contraire, ce dossier empêche l’exécution de l’extension DSC qui joint les machines virtuelles mises à jour au pool d’hôtes.
  • Si vous utilisez Azure Virtual Desktop Insights, l’agent Azure Monitor ou l’agent Log Analytics n’est pas automatiquement installé sur les hôtes de session mis à jour. Pour installer l’agent automatiquement, voici quelques options :
  • Évitez de modifier une configuration d’hôte de session dans un pool d’hôtes sans hôtes de session en même temps qu’un hôte de session est créé, car cela peut entraîner un pool d’hôtes avec des propriétés d’hôte de session incohérentes.

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour de l’hôte de session pour Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’effectuer une demande à Microsoft via le formulaire suivant, dont le point le plus important à retenir est :

Please note, the session hosts and host pools in this preview cannot be used for any type of production workload.

Autrement dit : pas de tests sur un environnement de production 😎

Etape I – Préparation du domaine AD :

Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :

Nommez celui-ci, puis cliquez sur Suivant :

Considérer au besoin les différents services de sécurité, puis cliquez sur Suivant :

Validez le plan d’adressage réseau et sous-réseau, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Une fois le réseau virtuel déployé, recherchez le service Microsoft Entra Domain Services depuis la barre de recherche Azure :

Cliquez-ici pour créer ce service d’AD managé sur votre tenant :

Renseignez ses informations de base dont son nom et le SKU de type Standard, puis cliquez sur Suivant :

Validez les propriétés réseaux, puis cliquez sur Suivant :

Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :

Définissez le périmètre de synchronisation, puis cliquez sur Suivant :

Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :

Cliquez sur Créer pour lancez sa création :

Lisez l’avertissement sur le blocage de modifications après sa création, puis cliquez sur OK :

Attendez environ 30 minutes la première phase de déploiement des ressources Azure :

Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :

Comme vous le constatez, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :

Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée. Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :

Lancez-le diagnostique en cliquant sur Lancer :

Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :

Confirmez votre choix en cliquant à nouveau sur Réparer :

Vérifiez la disparition de la notification d’alerte sur votre domaine managé :

Retournez sur le réseau virtuel afin de vérifiez les adresses IP de votre service Entra Domain Services :

Le domaine AD managé est maintenant en place.

La nouvelle méthode de déploiement AVD exige le stockage des informations d’identification dans un Azure Key Vault. Avant de déployer notre environnement AVD de test, nous aurons donc besoin d’un coffre.

Etape II – Création du coffre Azure Key Vault :

Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Renseignez les informations de base, puis cliquez sur Suivant :

Activez les 2 options suivantes, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre coffre :

Attendez environ 2 minutes, puis cliquez-ici une fois le déploiement terminé :

Ajoutez les rôles RBAC suivants afin de pouvoir accéder à votre coffre ainsi qu’au service Azure Virtual Desktop via son application 9cdead84-a844-4324-93f2-b2e6bb768d07 :

Ajoutez également le rôle RBAC suivant pour l’application Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07) afin que cette dernière puisse créer et supprimer de nouvelles machines virtuelles :

Retournez dans votre coffre, puis cliquez sur le bouton suivant pour créer les différents secrets :

Créez les 4 secrets suivants un par un :

  • Compte de domaine (sous la forme admindomain@jlou.local)
  • Mot de passe du compte de domaine
  • Compte admin local VM
  • Mot de passe du compte admin local VM

Cela donne alors la liste de secrets suivante :

Tous les prérequis au déploiement sont maintenant en place. Nous allons pouvoir déployer un nouveau type d’AVD ayant un management automatisé.

Etape III – Déploiement de l’environnement AVD :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Choisissez un pool d’hôtes de type partagé ainsi que le management automatisé, puis cliquez sur Suivant :

Définissez le nombre de machines virtuelles créées ainsi que la région Azure :

Choisissez l’image OS et les caractéristiques techniques de vos machines virtuelles AVD :

Spécifiez le réseau virtuel adéquat :

Reprenez les informations du Key Vault contenant les informations d’identification du compte de domaine :

Reprenez les informations du Key Vault contenant les informations d’identification du compte administrateur local, puis cliquez sur Suivant :

Définissez un nouvel espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer l’assignation des utilisateurs :

Assignez les utilisateurs de test AVD à votre groupe d’application créé :

Vérifiez le bon statut de disponibilité de vos hôtes de session créées :

Afin de s’assurer du bon fonctionnement de notre environnement AVD, connectez-vous à l’URL web d’Azure Virtual Desktop, authentifiez-vous avec un utilisateur de test, puis ouvrez une session AVD :

Cliquez sur Autoriser :

Renseignez les informations de compte de votre utilisateur AVD :

Vérifiez la bonne ouverture de session Windows :

Constatez la présence d’une session AVD ouverte sur une des VM présentes à votre pool d’hôtes :

L’environnement Azure Virtual Desktop est maintenant fonctionnel. La prochaine étape consiste à créer une mise à jour de l’image et donc de déclencher le processus de création de VM et le suppression des anciennes.

Etape IV – Déploiement d’une mise à jour AVD :

Tout commence par la création d’une nouvelle mise à jour AVD, pour cela cliquez-ici :

Définissez ici les options d’Azure Virtual Desktop sur les machines virtuelles :

  • La case à cocher détermine si AVD doit supprimer les anciennes machines virtuelles une fois ces dernières correctement substituées par de nouvelles.
  • Le pas de travail par AVD sur les machines virtuelles. Dans mon exemple :
    • AVD commencera par tester la mise à jour sur 1 seule machine virtuelle.
    • Si la mise à jour a fonctionné, AVD continuera par mettre à jour 2 VMs.
    • AVD terminera par mettre à jour les 2 dernière VMs

Définissez vos paramètres, puis cliquez sur Suivant :

Apportez les modifications de taille, d’image ou d’autres paramètres sur votre template AVD, puis cliquez sur Suivant :

Planifiez la mise à jour AVD immédiatement ou programmée par la suite, puis cliquez sur Suivant :

Personnalisez au besoin le message d’information reçu par les utilisateurs encore connectés, puis lancez la validation Azure :

Une fois la validation Azure réussie, retrouvez en gras les modifications apportées, puis lancez la mise à jour AVD :

Une fois la mise à jour enclenchée, l’écran des machines virtuelles AVD vous affiche 2 informations sur le traitement en-cours :

  • Le processus de mise à jour vient de démarrer, aucune VM n’a encore été remplacée, le pourcentage de progression est donc de 0.00 %.
  • La version actuellement en place sur les machine virtuelle AVD n’est plus la plus récente.

Après un rafraîchissement de la page, Azure Virtual Desktop commence sa mise à jour sur une première machine virtuelle AVD. Cela est visible par l’activation du mode de drainage sur une seule VM :

A ce même moment, une nouvelle machine virtuelle, dont la racine du nom reprend celle qui sera remplacée, fait son apparition et est en cours de création :

Une fois la nouvelle machine virtuelle créée, AVD nous informe que la VM déjà en place est en cours d’arrêt:

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute la nouvelle machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :

La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :

L’ancienne machine virtuelle est alors supprimée, comme demandé dans la configuration de la mise à jour AVD :

Le pourcentage de progression passe alors à 20.00 %, en adéquation avec le fait qu’1 machine virtuelle sur 5 est correctement mise à jour. AVD continue le traitement activant le mode de drainage sur 2 machines virtuelles :

A ce même moment, 2 nouvelles machine virtuelles, dont la racine du nom reprend celles qui seront remplacées, font leur apparition en cours de création :

Une fois les nouvelles machines virtuelles créés, AVD nous informe que les 2 VMs déjà en place sont en cours d’arrêt :

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retirent les 2 anciennes machines virtuelles du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute les 2 nouvelles machines virtuelles au pool d’hôtes AVD et au domaine Active Directory :

Le pourcentage de progression passe alors à 60.00 %, en adéquation avec le fait que 3 machine virtuelle sur 5 sont correctement mises à jour. AVD continue le traitement activant le mode de drainage sur les 2 dernières machines virtuelles :

A ce même moment, 2 nouvelles VMs sont créées, l’ancienne VM sans session utilisateur est en cours d’arrêt, tandis que celle contenant une session utilisateur reste encore active :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle sans session du pool d’hôtes AVD, tandis que celle contenant une session utilisateur reste encore présente :

Un message d’information apparaît dans la session encore ouverte de l’utilisateur AVD :

Quelques minutes plus tard, la session AVD est terminée sans action de l’utilisateur :

Le pourcentage de progression passe alors à 80.00 %, en adéquation avec le fait qu’une seule machine virtuelle sur cinq n’est pas encore mise à jour :

Azure Virtual Desktop force la déconnexion afin de déclencher l’arrêt de la machine virtuelle AVD :

Après cela, Azure Virtual Desktop retire la dernière machine virtuelle du pool d’hôtes AVD :

Juste après, Azure Virtual Desktop ajoute la dernière machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Toutes les anciennes machines virtuelles AVD ont bien été supprimées :

La mise à jour est maintenant terminée car toutes les machines virtuelles ont maintenant et correctement été mise à jour :

L’utilisateur déconnecté peut alors tenter une reconnexion à AVD :

L’utilisateur constate alors le passage à une nouvelle version de son OS :

AVD ouvre la nouvelle session Windows sur 1 des 5 machines virtuelles du pool d’hôtes :

Conclusion

Cette fonctionnalité vous permet de maximiser l’efficacité et la flexibilité de votre infrastructure virtuelle. Grâce à des outils avancés et des stratégies éprouvées, vous pouvez améliorer la gestion de vos ressources, réduire les coûts opérationnels et offrir une expérience utilisateur optimisée. Découvrez par vous-même comment l’orchestration de votre AVD peut transformer votre environnement de travail virtuel.