de VMware à Azure Stack HCI

La migration des machines virtuelles depuis VMware vers Azure Stack HCI 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 HCI 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 Stack HCI :

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 Stack HCI, 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 Stack HCI :

Comment se passe la migration VMware -> Azure Stack HCI ?

Les grandes étapes d’une migration vers Azure Stack HCI 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 Stack HCI) 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 Stack HCI

Voici les principales phases du processus de migration Azure Migrate :

Phase de migration	Description
1. Préparation	Préparez-vous à migrer en complétant les prérequis. Déployez et configurez votre cluster Azure Stack HCI. Créez un projet Azure Migrate et un compte de stockage Azure.
2. Découverte	Créez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. Réplication	Configurez l’appliance cible sur Azure Stack HCI et sélectionnez les VMs à répliquer.
4. Migration et vérification	Migrez les VMs vers Azure Stack HCI 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 :

Composant	Systèmes d’exploitation pris en charge
Environnement VMware source	VMware 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 Stack HCI cible	Azure Stack HCI, version 23H2
Appliance Azure Stack HCI	Windows 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 Stack HCI :

Géographies	Régions
Asie-Pacifique	Asie Sud-Est, Asie Est
Europe	Europe Nord – Europe Ouest
États-Unis	USA 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 Stack HCI via Azure Migrate. Pour tout cela, il nous faut :

Un tenant Microsoft
Une souscription Azure active
Un environnement Azure Stack HCI 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 Stack HCI, 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 Stack HCI :

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 Stack HCI.

Etape II – Configuration Azure Stack HCI :

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 Stack HCI
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 Stack HCI, puis cliquez sur Suivant :

Indiquez un nom pour l’appliance Azure Stack HCI, générez la clé, puis copiez cette dernière dans un bloc note :

Télécharger le fichier ZIP de votre appliance Azure Stack HCI :

À 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 Stack HCI, puis démarrez celle-ci :

Une fois authentifié en mode administrateur sur cette appliance Azure Stack HCI, 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 Stack HCI :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
.\AzureMigrateInstaller.ps1

Choisissez l’option 4 :

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 Stack HCI dans votre projet Azure Migrate, puis authentifiez-vous via Azure PowerShell :

Une fois l’appliance Azure Stack HCI enregistrée, sous Gérer les informations du cluster Azure Stack HCI, 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 Stack HCI, puis cliquez sur Suivant :

Choisissez la machine virtuelle à migrer sur votre cluster Azure Stack HCI, 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 Stack HCI 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 Stack HCI.

Etape III – Migration VMware -> Azure Stack HCI :

Une fois la réplication terminée, la machine virtuelle répliquée sur Azure Stack HCI 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 Stack HCI 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 Stack HCI 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 Stack HCI, puis cliquez dessus :

Copiez l’adresse IP privée de cette nouvelle machine virtuelle créée sous Azure Stack HCI :

Etape IV – Actions post-migration :

Dans mon scénario, j’ai utilisé une connexion Azure Virtual Desktop hébergé sur mon cluster Azure Stack HCI :

Une fois sur le réseau de votre Azure Stack HCI, 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 Stack HCI 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 Stack HCI afin de finaliser l’intégration de cette VM dans l’hyperviseur Azure Stack HCI :

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 Stack HCI, 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 Stack HCI, 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 :

Planification des mises à jour : Identifier les hôtes de session nécessitant des mises à jour et planifier les fenêtres de maintenance.
Exécution des mises à jour : Utiliser des scripts ou des outils pour appliquer les mises à jour sur chaque hôte de session.
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.

AVD : Enfin les 60 FPS !

Azure Virtual Desktop propose depuis longtemps la possibilité d’exploiter des machines virtuelles avec GPU pour des traitements graphiques plus ou moins gourmands. Mais des limitations persistaient, et notamment le nombre de FPS que l’utilisateur pouvait obtenir via sa connexion en bureau à distance. Et tout cela vient de changer avec une nouvelle préversion proposée par Microsoft !

H.265 vs H.264 ?

HEVC (High Efficiency Video Coding), également appelé H.265. Cela permet une compression de données de 25 à 50 % par rapport à AVC/H.264, pour la même qualité vidéo ou une meilleure qualité avec la même vitesse de transmission que si la vidéo était encodée avec AVC/H.264.

Microsoft Learn

L’accélération GPU dans Azure Virtual Desktop améliore l’expérience utilisateur pour trois composants :

Rendu d’application accéléré par GPU : Le GPU aide à afficher des graphismes plus rapidement dans une session à distance. Par exemple, si vous utilisez une application de dessin, les images se dessineront plus vite et seront plus fluides.
Encodage d’images accéléré par GPU : Le protocole RDP (Remote Desktop Protocol) encode les graphismes pour les envoyer à votre appareil. Par exemple, si une partie de l’écran change souvent, comme une vidéo, elle est encodée avec le codec AVC (H.264) pour une transmission plus efficace.
Encodage de vidéos plein écran : Pour des applications exigeantes comme la modélisation 3D, le CAD/CAM, ou l’édition vidéo, un profil vidéo plein écran offre une meilleure qualité d’image et une fréquence d’images plus élevée. Cela utilise plus de bande passante et de ressources. Vous pouvez choisir d’encoder avec :
- AVC/H.264 : Un codec standard pour la vidéo.
- HEVC/H.265 : Un codec plus efficace qui compresse les données de 25 à 50 % mieux que l’AVC/H.264, offrant la même qualité vidéo avec moins de bande passante.

Caractéristique	H.264 (AVC)	H.265 (HEVC)
Efficacité de compression	Utilise des macroblocs (16×16 pixels)	Utilise des unités de codage (CTU) jusqu’à 64×64 pixels
Taille des fichiers	Plus volumineux	Réduit la taille des fichiers jusqu’à 50%
Compatibilité	Largement pris en charge par de nombreux appareils et plateformes	Moins largement pris en charge, mais le support est en croissance
Puissance de traitement	Nécessite moins de puissance de calcul pour le codage et le décodage	Nécessite plus de puissance de calcul pour le codage et le décodage
Cas d’utilisation	Streaming, disques Blu-ray, diffusions HDTV	Vidéos haute résolution (4K, 8K), scénarios avec bande passante et stockage limités
Qualité vidéo	Bonne qualité vidéo	Meilleure qualité vidéo au même débit binaire
Bande passante	Nécessite plus de bande passante	Nécessite moins de bande passante
Adoption	Universellement adopté	Gagne en popularité, mais fait face à des obstacles de licence

En résumé, si vous avez besoin d’une meilleure compression et travaillez avec des vidéos haute résolution, H.265 est la meilleure option. Cependant, pour une compatibilité plus large et des exigences de traitement plus faibles, H.264 reste un choix logique.

Quelles machines virtuelles Azure sont compatibles ?

La bonne nouvelle est que si vous activez l’accélération matérielle HEVC/H.265 et AVC/H.264, mais que HEVC/H.265 n’est pas disponible sur l’appareil local, alors AVC/H.264 sera alors utilisé à la place.

Microsoft vous liste sur son site les familles de machines virtuelles Azure supportant partiellement ou totalement H.265 :

Taille de la machine virtuelle Azure	Accélération GPU pour le rendu d’application	Accélération GPU pour le codage d’images	Encodage vidéo plein écran
Série NVv3	Pris en charge	AVC/H.264	HEVC/H.265 AVC/H.264
Série NVv4	Pris en charge	Non disponible	Pris en charge
NVadsA10 v5-series	Pris en charge	AVC/H.264	HEVC/H.265 AVC/H.264
NCasT4_v3-series	Pris en charge	AVC/H.264	HEVC/H.265 AVC/H.264

Contraintes importantes :

Contraintes AVD :
- Compatible uniquement Windows 10 et Windows 11
- Les machines virtuelles Azure des séries NC, NCv2, NCv3, ND et NDv2 ne sont généralement pas appropriées comme hôtes de session. Ces tailles de machine virtuelle sont adaptées aux outils de calcul ou de Machine Learning hautes performances spécialisés, comme ceux créés avec NVIDIA CUDA. Elles ne prennent pas en charge l’accélération GPU pour la plupart des applications ni pour l’interface utilisateur Windows.
- Désactivation obligatoire de la redirection multimédia sur vos hôtes de session.
- Groupe d’applications de bureau RemoteApp non pas pris en charge.
Contraintes sur le poste local :
- GPU compatible HEVC (H.265)
- Code Microsoft HEVC installé (inclus à partir de Windows 11 22H2)
- Windows App, version 1.3.278.0 ou ultérieure.
- Application Bureau à distance, version 1.2.4671.0 ou ultérieure.

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

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de FPS sur Azure Virtual Desktop, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Commençons d’abord par vérifier en premier la compatibilité H.265 du poste local.

Etape I – Vérifications H.265 du poste local :

Sur votre poste, ouvrez Windows PowerShell, puis exécutez la commande suivante pour vérifier la présence du codec HEVC :

get-appxpackage *hevc*

Ouvrez maintenant au choix votre application Remote Desktop ou Windows App afin de vérifier les versions :

La configuration locale semble bonne, continuons maintenant sur Azure afin de mettre en place un environnement de test avec GPU.

Etape II – Création de l’environnement Azure Virtual Desktop :

Voici un rappel des familles de machines virtuelles dont les GPUs NVIDIA sont compatibles :

Avant de pouvoir déployer un environnement GPU pour Azure Virtual Desktop, nous avons donc besoin de disposer de quotas sur notre souscription. Pour cela, rendez-vous dans le portail Azure :

Pour mon exemple, j’ai choisi de créer mon environnement AVD sur une machine virtuelle de la familles NCasT4_v3, dont j’ai précédemment augmenté les quotas :

Une fois les quotas en place, nous avons besoin d’avoir un réseau virtuel Azure.

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Configurez-le comme ceci, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Choisissez une taille de VM GPU :

Joignez votre VM à votre réseau virtuel et à Microsoft Entra ID :

Définissez un administrateur local, puis cliquez sur Suivant :

Créez un 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 terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Définissez sur le groupe de ressources les droits RBAC suivants pour votre utilisateur de test AVD :

Notre environnement Azure Virtual Desktop GPU est maintenant en place. La prochaine étape consiste à installer la configuration graphique de base, afin que la carte NVIDIA soit reconnue par Windows et pleinement exploitée.

Etape III – Configuration GPU de l’environnement AVD :

Important :

Pour les tailles des machines virtuelles avec un GPU NVIDIA, seuls les pilotes NVIDIA GRID prennent en charge l’accélération GPU pour la plupart des applications et l’interface utilisateur Windows. Les pilotes NVIDIA CUDA ne prennent pas en charge l’accélération GPU pour ces tailles de machine virtuelle. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU NVIDIA sur les machines virtuelles de série N exécutant Windows et n’oubliez pas d’installer le pilote GRID. Si vous installez le pilote en utilisant l’Extension de pilote GPU NVIDIA, le pilote GRID est automatiquement installé pour ces tailles de machine virtuelle. Pour l’accélération matérielle HEVC/H.265, vous devez utiliser le pilote GPU NVIDIA GRID 16.2 (537.13) ou version ultérieure.

Pour les tailles des machines virtuelles avec un GPU AMD, installez les pilotes AMD fournis par Azure. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU AMD sur les machines virtuelles de série N exécutant Windows.

Microsoft Learn

Ouvrez la page de votre machine virtuelle AVD de test afin de déployer le service Azure Bastion sur votre réseau virtuel :

Une fois Azure Bastion correctement déployé, ouvrez une session via ce dernier avec le compte administrateur local de la machine virtuelle :

Sur votre VM AVD, ouvrez la page suivante de la documentation Microsoft proposant l’installation de pilotes GRID :

Une fois l’installeur GRID téléchargé sur votre VM GPU, ouvrez ce dernier, puis confirmez le dossier de décompression au niveau local :

Après une rapide vérification du système, cliquez sur Accepter et Continuer :

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

Une fois l’installation terminée avec succès, cliquez sur Fermer :

Ouvrez l’exécuteur de commande Windows pour ouvrir l’éditeur de stratégie de groupe locale :

Naviguez dans l’arborescence suivante :

Administrative Templates
- Windows Components
  - Remote Desktop Services
    - Remote Desktop Session Host
      - Remote Session Environnment

Afin de profiter de la performance du GPU de notre machine virtuelle, activez les polices locales suivantes :

Afin de tester le nombre de FPS, installez FurMark 2. Pour cela, rendez-vous sur la page web suivante afin de télécharger l’installeur :

Lancez l’installation de FurMark 2, cochez la première case, puis cliquez sur Suivant :

Renseignez le répertoire d’installation, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Suivant :

Cliquez sur Terminer :

La configuration GPU de base est maintenant en place. Nous allons pouvoir tester l’impact sans et avec la configuration additionnelle.

Etape IV – Test utilisateur SANS :

Si besoin, téléchargez le client Remote Desktop depuis cette page officielle Microsoft.

Ouvrez l’application avec votre utilisateur de test AVD, puis lancez l’application de bureau à distance :

Acceptez la demande d’autorisation pour autoriser les connexion RDP vers la VM GPU AVD :

Depuis le menu Démarrer, ouvrez l’application FurMark 2 :

Démarrez le test GPU :

Pendant que FurMark 2 poursuit son test, contrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :

La configuration actuelle limite actuellement le nombre de FPS à 30. Testons maintenant avec la configuration additionnelle.

Etape V – Test utilisateur AVEC :

Pour s’assurer que la fonction débridant les 60 FPS est correctement activée, les clés de registre suivantes doivent être définies sur chaque VM hôte de session.

Ouvrez Windows PowerShell, puis exécutez les commandes suivantes :

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v HEVCModePreferred /t REG_DWORD /d 1

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW /t REG_DWORD /d 1

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DisplayRefreshRate /t REG_DWORD /d 60

Ouvrez l’observateur d’événements Windows et accédez au journal suivant :

Journaux des applications et services
- Microsoft
  - Windows
    - RemoteDesktopServices-RdpCoreCDV
      - Operational

Recherchez l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise HEVC, ce qui n’est pas encore le cas ici :

Fermez la session utilisateur d’Azure Virtual Desktop :

Relancez la session de bureau à distance :

Réouvrez l’observateur d’événements Windows, puis accédez au journal suivant :

Journaux des applications et services
- Microsoft
  - Windows
  - RemoteDesktopServices-RdpCoreCDV
    - Operational

Recherchez à nouveau l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise bien HEVC, ce qui maintenant le cas ici :

Rouvrez l’application FurMark 2, et recontrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :

Bravo ! Le nombre de FPS a fait un sacré bon !

Conclusion

Grâce à l’accélération GPU et à l’utilisation des codecs HEVC/H.265 et AVC/H.264, les utilisateurs peuvent désormais bénéficier d’une expérience graphique fluide et de haute qualité, même pour des applications exigeantes comme la modélisation 3D ou l’édition vidéo.

Cette mise à jour d’Azure Virtual Desktop marque un tournant pour les utilisateurs nécessitant des performances graphiques élevées, tout en offrant une meilleure compression et une utilisation plus efficace de la bande passante 😎💪

Azure WAN

Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎

Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.

Qu’est-ce qu’Azure WAN ?

Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.

Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.

Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.

Microsoft Learn

Voici quelques-unes des fonctionnalités principales :

Connectivité de branche (via l’automatisation de la connectivité à partir d’appareils partenaires Virtual WAN, comme SD-WAN ou CPE VPN).

Connectivité VPN de site à site.

Connectivité VPN d’un utilisateur distant (point à site).

Connectivité privée (ExpressRoute).

Connectivité multicloud (connectivité transitive pour les réseaux virtuels).

Interconnectivité ExpressRoute des VPN.

Routage, Pare-feu Azure et chiffrement pour la connectivité privée.

Microsoft Learn

Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.

Dans quel cas considérer Azure WAN ?

Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.

Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.

Quels SKUs sont disponibles pour Azure WAN ?

Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.

A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :

Type de Virtual WAN	Type de Hub	Configurations disponibles
De base	De base	VPN de site à site uniquement
standard	standard	ExpressRoute VPN utilisateur (point à site) VPN (site à site) Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel Pare-feu Azure NVA est un WAN virtuel

Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :

Connexion entre les hubs
Connectivité ExpressRoute
Connectivité VPN utilisateur/point à site
Connectivité de réseau virtuel à réseau virtuel Azure
Azure Firewall

Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :

Quels sont les autres coûts liés au services Azure WAN ?

La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.

Dans l’image ci-dessous, pas loin de 13 différents types de transfert sont facturés par Microsoft :

Pour y voir plus clair sur le trafic réseaux d’Azure WAN, Microsoft propose différents scénarios concrets disponibles juste là.

Tarification de la liaison :

Microsoft communique également via leur site web le détail tarifaire complet des liaisons réseaux possibles :

Tarification de la données en transit :

Microsoft nous rappelle ici les différents prix au Go de données transférées entre des réseaux sur Azure et/ou sur site :

Afin de comprendre comment déployer Azure WAN, j’ai décidé de recréer une petite infrastructure réseau, répartie sur plusieurs régions Azure :

Par manque de temps et de connaissances, je n’ai pas testé Firewall et la fonctionnalité BGP sur mon test d’Azure WAN.

Mon test d’Azure WAN :

Mon environnement WAN de test est constitué des éléments Azure suivants :

1 Azure WAN avec 2 Azure Hub :

4 réseaux virtuels Azure contenant chacun une machine virtuelle :

2 VPN Gateway Site à Site :

2 VPN Gateway Point à Site avec une configuration P2S VPN globale WAN :

J’ai recréé sur Azure différentes ressources pour simuler deux environnements sur site :

2 réseaux en connexion site à site avec 2 passerelles VPN :

2 réseaux en connexion point à site avec des PCs équipés du client Azure VPN :

Afin d’effectuer mes tests de connectivités entre tous ces réseaux, j’ai également déployé les machines virtuelles suivantes :

Afin d’avoir une vue d’ensemble de l’infrastructure WAN, Microsoft propose une cartographie fidèle avec toutes les liaisons internes et externes :

Toute la configuration WAN côté infrastructure Azure peut s’effectuer directement depuis la page du portail Azure dédiée à mon Azure WAN.

Configuration WAN :

Pour arriver à ce résultat, une fois le WAN déployé, j’ai créé ici les 2 hubs suivants :

J’ai activé les liaisons suivantes via la configuration de mon WAN :

Configuration des 2 hubs :

Pour chacun des 2 hubs, j’ai activé les passerelles VPN Site à Site et Point à Site (30 minutes d’attente par liaison) :

Connexions aux 4 réseaux virtuels Azure :

Depuis la page d’Azure WAN, j’ai connecté les 4 réseaux virtuels internes à mon infrastructure Azure à mes 2 hubs :

J’ai utilisé la route par Default pour chacune des liaisons :

Connexions aux réseaux locaux Site à site :

Depuis la page Azure WAN, j’ai créé 2 sites physiques respectivement connectés à mes 2 hubs :

Pour chacun des 2 sites, j’ai indiqué leur plan d’adressage respectif :

Une fois les 2 liaisons VPN Site à Site déployées et connectées, ces dernières sont alors bien respectivement visibles sur les 2 hubs :

Une fois toutes les connexions internes et externes en place, les différentes routes sont bien visibles sur chacun de mes 2 hubs :

Connexions Points à site :

Toujours sur la page Azure WAN, j’ai mis en place une configuration unique concernant le type de tunnel et la méthode d’authentification Entra ID :

Afin d’assurer une authentification via Entra ID, j’ai mis en place un tunnel Point à Site de type OpenVPN :

Comme mon précédent article parlant déjà du VPN Point à Site, j’ai configuré les informations suivantes en relation avec mon tenant Microsoft :

J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :

La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :

Poste 1 :

Poste 2 :

Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :

Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.

Tests des accès :

Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :

J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :

J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :

Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
Serveur ayant une connexion Site à Site ouverte sur le même hub
Serveur ayant une connexion Site à Site ouverte sur l’autre hub
Serveurs ayant un appairage de réseau virtuel sur le même hub
Serveurs ayant un appairage de réseau virtuel sur l’autre hub

Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪

Surveillance des liaisons :

Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.

Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :

De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.

J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :

A peine les tests créés, Connection Monitor affiche les résultats :

Différentes informations sont disponibles sur ces tests :

Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :

A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :

Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :

Azure Monitor affiche également les 2 alerte déclenchée :

Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :

Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :

Quelques minutes plus tard, les alertes générées sont automatiquement résolues :

De retour sur Connection Monitor, tous les tests repassent alors en vert :

Conclusion

En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.

Migrez un ancien OS Windows sur le Cloud Azure

De mon côté, l’aventure IT a commencé en décembre 1995 avec mon tout premier ordinateur : un 486 SX-33 développé par Intel. Je ne saurais me rappeler de sa quantité de mémoire vive, mais je pense que je pouvais les compter sur les doigts d’une seule main 🤣.

Plus sérieusement, que ce passe-t-il si une application métier, toujours fonctionnelle et devant perdurer, doit être migrée au plus vite pour une raison X ?

Microsoft a peut-être une réponse grâce au le service Azure Migrate :

Azure Migrate offre un service simplifié de migration, de modernisation et d’optimisation pour Azure. Toutes les étapes de pré-migration telles que la détection, les évaluations et le dimensionnement des ressources locales sont incluses pour l’infrastructure, les données et les applications. L’infrastructure extensible d’Azure Migrate permet d’intégrer des outils tiers, ce qui augmente l’étendue des cas d’utilisation pris en charge.

Microsoft Learn

Pour vous faire une meilleure idée d’Azure Migrate, un atelier exercice dédié à la migration vers Azure conçu par Microsoft avait déjà été détaillé sur ce blog juste ici.

Comme le montre le schéma ci-dessous, l’objectif de cet exercice est de migrer plusieurs serveurs virtuels gérés sous un serveur Hyper-V vers le Cloud Azure :

Qu’est-ce que Disk2vhd ?

Il s’agit d’un petit utilitaire très pratique développé par Mark Russinovich et disponible dans la suite Sysinternals :

Disk2vhd est un utilitaire qui crée des versions VHD (Virtual Hard Disk – Microsoft’s Virtual Machine disk format) de disques physiques à utiliser dans Microsoft Virtual PC ou Microsoft Hyper-V virtual machines (VMs). La différence entre Disk2vhd et d’autres outils physiques à virtuels est que vous pouvez exécuter Disk2vhd sur un système en ligne.

Microsoft Learn

Disk2vhd utilise la capacité d’instantané de volume de Windows, introduite dans Windows XP, pour créer des instantanés cohérents à un instant donné des volumes que vous souhaitez inclure dans une conversion. Vous pouvez même demander à Disk2vhd de créer les VHD sur des volumes locaux, même ceux en cours de conversion (bien que les performances soient meilleures lorsque le VHD se trouve sur un disque différent de ceux en cours de conversion).

Microsoft Learn

Au travers de ce nouvel article, je souhaitais tester avec vous la copie de plusieurs serveurs physiques fonctionnant sous d’anciens OS afin de tester un portage rapide et simple vers Azure :

~~Windows XP Professional~~
Windows 7 Professional x64
Windows 10 Enterprise x64
Windows Server 2008 R2 x64
Windows Server 2012 R2 x64
Windows Server 2016 x64

Pour cela, cet article repose sur la méthode de préparation d’un fichier VHD proposée par Microsoft et exposée juste ici, dont les principales commandes de préparation sont disponibles sur mon GitHub.

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

N’ayant pas d’anciens serveurs physiques à disposition, j’ai choisi de les simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.

Il est en effet possible dans Azure 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 (Hyper-V) :

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, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées :

Conservez les options par défaut, puis cliquez sur OK :

Cliquez ensuite 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 hôte (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, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Une fois connecté sur votre machine virtuelle hôte (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 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage immédiat de votre VM hôte (Hyper-V) :

Shutdown -R

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

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

Lancez le script suivant afin de créer un switch virtuel dans 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, couplé au 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

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (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 :

Cliquez sur Suivant :

Cliquez sur Terminer :

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape II – Création de la machine virtuelle invitée :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :

Stockez le fichier ISO sur le disque F de votre VM hôte (Hyper-V) :

Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :

Cliquez-ici pour créer votre machine virtuelle invitée :

Cliquez sur Suivant :

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

Choisissez Génération 1 :

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 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 invitée créée, modifiez sa configuration comme ceci :

Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows, puis cliquez sur OK :

Répétez les mêmes opérations pour les autres OS dont vous souhaitez tester la migration vers Azure :

Double-cliquez sur votre machine virtuelle invitée :

Cliquez-ici pour lancer le démarrage de la VM invitée :

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

Lancez l’installation de Windows :

Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows :

Choisissez une version Desktop de Windows, puis cliquez sur Suivant :

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

Sélectionnez l’installation personnalisée de Windows :

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

Attendez maintenant que l’installation de Windows commence :

Lancez le redémarrage de la machine virtuelle invitée :

Donnez à nom si nécessaire à votre compte local Windows et un mot de passe :

La machine virtuelle invitée avec l’ancien OS Windows est maintenant en place. Comme pour une machine physique, nous allons maintenant générer un fichier VHD afin de pouvoir préparer l’OS à être remonté sur Azure.

Avant cela, quelques modifications sont nécessaires.

Etape III – Génération du fichier VHD :

Sur votre VM hôte (Hyper-V), créez un nouveau dossier contenant une ou plusieurs versions de l’outil Disk2vhd selon l’ancienneté de l’OS concerné :

Windows Server 2012, 2016, Windows 10 -> Disk2vhd v2.02
Windows Server 2008 R2, Windows 7 -> Disk2vhd v1.6

Partagez ce dossier sur le réseau :

Créez un second dossier dédié au VHD généré par l’outil Disk2vhd, puis partagez ce dossier sur le réseau :

Depuis la machine virtuelle invitée, ouvrez l’application Disk2vhd depuis le premier partage, puis sauvegardez votre fichier VHD sur le second partage :

Le traitement VSC peut prendre entre 5 minutes et 2 heures :

Le message de succès apparaît alors à la fin du traitement :

Effectuez ces mêmes opérations de génération du fichier VHD pour chacun des OS comme ceci :

Fermez la session utilisateur de votre machine virtuelle invitée :

Eteignez également votre machine virtuelle invitée :

Effectuez ces opérations d’arrêt pour chacune des machines virtuelles invitées :

Les machines virtuelles de départ sont maintenant toutes éteintes. Avant de pouvoir transférer le fichier VHD vers Azure, il est nécessaire d’effectuer plusieurs opérations au niveau de l’OS, mais également du fichier VHD.

Etape IV – Préparation du fichier VHD :

Pour cela, nous allons recréer de nouvelles machines virtuelles identiques, dans lesquelles nous allons passer plusieurs commandes PowerShell.

Toujours sur Hyper-V Manager, cliquez-ici pour créer une nouvelle machine virtuelle invitée :

Cliquez sur Suivant :

Modifier les informations suivantes, puis cliquez sur Suivant :

Choisissez Génération 1 :

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

Utilisez le même switch que précédemment, puis cliquez sur Suivant :

Rattachez le nouveau disque VHD généré via Disk2vhd, puis cliquez sur Suivant :

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

Une fois la machine virtuelle invitée créée, modifiez le nombre de processeurs virtuels, puis cliquez sur OK :

Répétez les mêmes opérations pour les autres OS, puis double-cliquez sur une nouvelle machine virtuelle invitée :

Cliquez-ici pour lancer le démarrage de la VM invitée :

Depuis le menu Démarrer, recherchez Windows PowerShell ISE en mode administrateur :

Confirmez le risque sécuritaire en cliquant sur Oui :

Ouvrez le fichier de script suivant, disponible sur mon GitHub :

Lancez la commande System File Checker (SFC) afin de vérifier les fichiers systèmes Windows :

sfc.exe /scannow

Quelques minutes plus tard, SFC vous confirme le succès du contrôle :

Lancez la commande netsh afin de réinitialiser les paramètre proxy :

netsh.exe winhttp reset proxy

Ouvrez via CMD en mode administrateur afin de lancez l’utilitaire Diskpart :

diskpart.exe
san policy=onlineall
exit

Configurez l’heure UTC pour Windows :

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation -Name RealTimeIsUniversal -Value 1 -Type DWord -Force
Set-Service -Name w32time -StartupType Automatic

Modifiez le profil d’alimentation en performances hautes :

powercfg.exe /setactive SCHEME_MIN
powercfg /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOIDLE 0

Réinitialisez les variables systèmes par défaut :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TEMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force

Réinitialisez par défaut certains services Windows :

Get-Service -Name BFE, Dhcp, Dnscache, IKEEXT, iphlpsvc, nsi, mpssvc, RemoteRegistry |
  Where-Object StartType -ne Automatic |
    Set-Service -StartupType Automatic

Get-Service -Name Netlogon, Netman, TermService |
  Where-Object StartType -ne Manual |
    Set-Service -StartupType Manual

Activez le service bureau à distance RDP :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name fDenyTSConnections -Value 0 -Type DWord -Force

Validez le port par défaut 3389 pour le protocole RDP :

L’auditeur écoute sur chaque interface réseau :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name LanAdapter -Value 0 -Type DWord -Force

Configurez le mode d’authentification au niveau du réseau (NLA) pour les connexions RDP selon l’OS :

Pour Windows Server 2012, 2016 et pour Windows 10 :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1 -Type DWord -Force

Pour Windows Server 2008 R2 et pour Windows 7 :

Set-Itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -value '0'
Set-Itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -value '0'

Définissez la valeur keep-alive :

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name KeepAliveEnable -Value 1  -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name KeepAliveInterval -Value 1  -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name KeepAliveTimeout -Value 1 -Type DWord -Force

Définissez les options de reconnexion :

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name fDisableAutoReconnect -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name fInheritReconnectSame -Value 1 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name fReconnectSame -Value 0 -Type DWord -Force

Limitez le nombre de connexions simultanées :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name MaxInstanceCount -Value 4294967295 -Type DWord -Force

Supprimez tous les certificats auto-signés liés à l’écoute RDP :

if ((Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp').Property -contains 'SSLCertificateSHA1Hash')
{
    Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SSLCertificateSHA1Hash -Force
}

Activez le pare-feu Windows sur les 3 profils réseaux (domaine, standard et public) :

Set-NetFirewallProfile -Profile Domain, Public, Private -Enabled True

Ouvrez l’explorateur de fichiers Windows, cliquez sur le menu Réseau, puis changez l’option suivante :

Activez l’option suivante :

Convertissez la connexion actuelle en réseau privé :

Activer le service à distance PowerShell :

Activez les règles de pare-feu suivantes pour autoriser le trafic RDP :

Activez la règle des requêtes ping à l’intérieur du réseau virtuel :

Créez les règles suivantes entrantes et sortantes point vers le service DNS d’Azure :

Ouvrez CMD en mode administrateur afin de lancer l’utilitaire Diskpart :

chkdsk.exe /f

Lancez le redémarrage de la machine virtuelle invitée :

N’appuyez sur aucune touche afin de lancer le contrôle du disque :

Attendez la fin de traitement :

Réouvrez la session Windows de votre machine virtuelle invitée :

Ouvrez CMD en mode administrateur afin de définir les paramètres des données de configuration de démarrage (BCD) :

cmd

bcdedit.exe /set "{bootmgr}" integrityservices enable
bcdedit.exe /set "{default}" device partition=C:
bcdedit.exe /set "{default}" integrityservices enable
bcdedit.exe /set "{default}" recoveryenabled Off
bcdedit.exe /set "{default}" osdevice partition=C:
bcdedit.exe /set "{default}" bootstatuspolicy IgnoreAllFailures

#Enable Serial Console Feature
bcdedit.exe /set "{bootmgr}" displaybootmenu yes
bcdedit.exe /set "{bootmgr}" timeout 5
bcdedit.exe /set "{bootmgr}" bootems yes
bcdedit.exe /ems "{current}" ON
bcdedit.exe /emssettings EMSPORT:1 EMSBAUDRATE:115200

exit

Réouvrez Windows PowerShell ISE en mode administrateur :

Activez la collecte des journaux d’erreur :

# Set up the guest OS to collect a kernel dump on an OS crash event
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Type DWord -Force -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name DumpFile -Type ExpandString -Force -Value "%SystemRoot%\MEMORY.DMP"
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name NMICrashDump -Type DWord -Force -Value 1

# Set up the guest OS to collect user mode dumps on a service crash event
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
if ((Test-Path -Path $key) -eq $false) {(New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting' -Name LocalDumps)}
New-ItemProperty -Path $key -Name DumpFolder -Type ExpandString -Force -Value 'C:\CrashDumps'
New-ItemProperty -Path $key -Name CrashCount -Type DWord -Force -Value 10
New-ItemProperty -Path $key -Name DumpType -Type DWord -Force -Value 2
Set-Service -Name WerSvc -StartupType Manual

Vérifiez que le référentiel Windows Management Instrumentation (WMI) est toujours cohérent :

winmgmt.exe /verifyrepository

Assurez-vous qu’aucune autre application que TS n’utilise le port 3389 :

netstat.exe -anob | findstr 3389

Vérifiez les mises à jour Windows :

Lancez le redémarrage de la machine virtuelle invitée :

Depuis votre machine virtuelle hôte (Hyper-V), vérifiez la bonne ouverture de session RDP :

Eteignez votre machine virtuelle invitée :

Notre machine virtuelle invitée est maintenant prête à être migrée vers Azure. Pour cela, nous allons utilisez la commande PowerShell Add-AzVhd.

Etape V – Création de la machine virtuelle Azure :

Depuis le portail Azure, créez un nouveau groupe de ressources pour la machine virtuelle invitée dans le Cloud :

Depuis votre machine virtuelle hôte (Hyper-V), connectez-vous à votre environnement Azure via PowerShell ISE :

Lancez les commandes PowerShell Azure suivantes afin de créer un disque managé Azure depuis le fichier VHD local :

Add-AzVhd -LocalFilePath C:\data.vhd -ResourceGroupName rgname -Location eastus -DiskName newDisk

Une première étape de détection commence alors :

Suivi du calcul de Hash :

Pour finir par le transfert vers Azure :

Retournez sur le groupe de ressources Azure créé précédemment, constatez la présence d’un disque managé, puis cliquez dessus :

Cliquez ici pour créer la machine virtuelle :

Renseignez les informations de base :

Choisissez la taille de votre VM, puis cliquez sur Suivant :

Sur l’onglet Réseau, reprenez le même réseau virtuel que celui utilisé pour votre machine virtuelle Hyper-V, puis lancez la validation Azure :

Une fois la validation Azure passée, lancez la création des ressources :

Attendez quelques minutes le succès de la création de votre VM, puis cliquez ici :

Attendez quelques minutes le démarrage complet de votre VM :

Vérifiez le bon démarrage de votre VM en actualisant si besoin plusieurs fois le screenshot suivant :

Constatez la présence de l’avertissement Azure suivant :

Renseignez les identifiants renseignés lors de la création de votre VM invitée :

Constatez la bonne ouverture de session Windows :

Une fois la session Windows ouverte, installez l’agent pour les machines virtuelles Azure disponible sur cette page GitHub :

Exécutez le fichier MSI d’installation depuis une session PowerShell avec les droits administrateurs :

Cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Attendez quelques minutes la fin de l’installation de l’agent :

Cliquez sur Terminer :

Quelques minutes plus tard, constatez la disparition de l’alerte Azure sur votre VM :

Vérifiez la bonne relation entre le management Azure et votre VM via le menu suivant :

La commande suivante doit vous retourner la configuration IP renseignée sur votre VM :

Effectuez un test d’arrêt de votre machine virtuelle :

Confirmez votre action en cliquant sur Oui :

Effectuez un test de démarrage de votre machine virtuelle :

Vérifiez le succès des 2 opérations via les notifications Azure :

Cliquez-ici pour rouvrir la session Windows ouverte précédemment via Azure Bastion :

Effectuez les mêmes opérations pour les autres anciens OS à tester :

Conclusion

Par cette démonstration, un portage rapide et en urgence de certaines anciennes versions Windows, client ou serveur, est parfaitement possible. Quelques manipulations de préparation sont nécessaires, mais ces dernières sont fonctionnelles pour les OS suivants :

Windows 7 Professional x64
Windows 10 Enterprise x64
Windows Server 2008 R2 x64
Windows Server 2012 R2 x64
Windows Server 2016 x64

Autopilot v2 💪💻🚨

Vous commencez enfin à maîtriser le service Autopilot de Microsoft et vous vous en servez déjà pour déployer vos postes ? Cela tombe très bien ! Microsoft vient justement de sortir il y a quelques mois la Préparation de l’appareil Windows Autopilot. Peut-on parler de cette nouvelle fonctionnalité comme d’un Autopilot en version 2 ? Oui et non, mais cela va encore plus démocratiser Intune auprès des services IT.

Cet article est donc une suite logique à un autre article détaillant la méthode Autopilot v1, déjà en place depuis assez longtemps. Au travers de ce nouvel écrit, nous allons tester l’intégration d’un PC via cette nouvelle méthode Autopilot v2, dont le nom officiel chez Microsoft est Préparation de l’appareil Windows Autopilot.

Quelles sont les différences entre Autopilot v1 et Autopilot v2 ?

Le fait de les appeler v1 et v2 un choix personnel afin de gagner en clarté, ce qui ne veut pas dire que la seconde est un remplacement complet de la première. Voici d’ailleurs une comparaison v1/v2 rédigée par Microsoft :

Fonctionnalité	Windows Autopilot préparation de l’appareil (Autopilot v2)	Windows Autopilot (Autopilot v1)
Fonctionnalités	Prise en charge des environnements Government Community Cloud High (GCCH) et ministère de la Défense (DoD). Expérience d’approvisionnement plus rapide et plus cohérente. Informations de surveillance et de résolution des problèmes en quasi-temps réel.	Prise en charge de plusieurs types d’appareils (HoloLens, Salle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Modes pris en charge	Piloté par l’utilisateur;	Piloté par l’utilisateur; Préprovisionné. Déploiement automatique. Appareils existants.
Types de jointure pris en charge	Rejoindre Microsoft Entra.	Rejoindre Microsoft Entra. Jointure hybride Microsoft Entra.
Inscription de l’appareil requise ?	Non.	Oui.
Que doivent configurer les administrateurs ?	Stratégie de préparation des appareils Windows Autopilot. Groupe de sécurité de l’appareil avec le client d’approvisionnement Intune en tant que propriétaire.	Profil de déploiement Windows Autopilot. Page d’état d’inscription (ESP).
Quelles configurations peuvent être fournies lors de l’approvisionnement ?	Basé sur l’appareil uniquement pendant l’expérience out-of-box (OOBE).Jusqu’à 10 applications essentielles (métier), Win32, Microsoft Store, Microsoft 365). Jusqu’à 10 scripts PowerShell essentiels.	Basé sur l’appareil pendant l’ESP de l’appareil. Basé sur l’utilisateur pendant l’ESP utilisateur. N’importe quel nombre d’applications.
Résolution des problèmes de création de rapports &	Rapport de déploiement de la préparation de l’appareil Windows Autopilot : Affiche tous les déploiements de préparation des appareils Windows Autopilot. Davantage de données disponibles. Quasiment en temps réel.	Rapport de déploiement Windows Autopilot : Affiche uniquement les appareils inscrits sur Windows Autopilot. Pas en temps réel.
Prend en charge les applications métier et Win32 dans le même déploiement ?	Oui.	Non.
Versions prises en charge de Windows	Windows 11, version 23H2 avec KB5035942 ou version ultérieure. Windows 11, version 22H2 avec KB5035942 ou version ultérieure.	Toutes les versions actuellement prises en charge du canal de disponibilité générale De Windows 11.Toutes les versions actuellement prises en charge du canal de disponibilité générale Windows 10.

Mais cette nouvelle méthode pourrait correspondre à certains scénarios comme le suggère Microsoft :

Conditions requises	Windows Autopilot préparation de l’appareil (Autopilot v2)	Windows Autopilot (Autopilot v1)
Government Community Cloud High (GCCH) et Environnements du ministère de la Défense (DoD)	✅	❌
Scénario piloté par l’utilisateur	✅	✅
Scénario pré-provisionné	❌	✅
Scénario de déploiement automatique	❌	✅
Scénario d’appareils existants	❌	✅
Prise en charge de la réinitialisation d’Autopilot	❌	✅
Jonction Microsoft Entra	✅	✅
Jonction Microsoft Entra hybride	❌	✅
Réinitialisation de Windows Autopilot	❌	✅
Windows 11	✅	✅
Windows 10	❌	✅
Déployer des applications Win32 et métier dans le même déploiement	✅	❌
Configuration et expérience de déploiement plus simples	✅	❌
Personnalisation étendue du déploiement et expérience OOBE	❌	✅
Aucune exigence de pré-phaser les appareils	✅	❌
Installer plus de 10 applications pendant OOBE	❌	✅
Exécuter plus de 10 scripts PowerShell pendant OOBE	❌	✅
Surveillance en quasi-temps réel	✅	❌
Empêcher l’utilisateur d’accéder au Bureau jusqu’à ce que les configurations basées sur l’utilisateur sont appliquées	❌	✅
Prise en charge d’HoloLens	❌	✅
Prise en charge des salles de réunion Teams	❌	✅
Interface de configuration du microprogramme d’appareil (DFCI) Prise en charge de la gestion	❌	✅
Autopilot dans la cogestion	❌	✅

Pourquoi changer ce qui marche déjà ?

Comme le rappel l’excellent billet écrit sur le site de Synapsys, Microsoft a souhaité faire évoluer son service Autopilot créé en 2017 afin de pouvoir supporter un plus grand nombre d’appareils. Cela va permettre de gérer le provisionnement des Cloud PC Windows 365 ou pour des clients dont le tenant est sur une instance Gov du Cloud Microsoft :

Windows Autopilot Device Preparation vise à simplifier encore plus le déploiement des périphériques, en optimisant le temps global de préparation de celui-ci et en améliorant notamment la résolution des problématiques qui peuvent survenir pendant le déploiement ainsi que le reporting.

Synapsys-groupe

Et bien sûr, plus besoin du hash 😎 :

La grosse nouveauté comparée à Windows Autopilot est qu’il n’est plus nécessaire d’importer le hash matériel pour pouvoir bénéficier du service. Autre nouveauté, le profil de déploiement sera à déployer sur un profil utilisateur et non machine.

Synapsys-groupe

Ai-je besoin de licences spécifiques pour Autopilot v2 ?

Comme il est rappelé dans la documentation Microsoft, Autopilot v2 a besoin des mêmes licences que pour Autopilot v1. Voici une liste non exhaustive de licences ou combinaison de licences possibles :

Licence Microsoft 365 Business Premium
Licence Microsoft 365 F1 ou F3
Licence Microsoft 365 Academic A1, A3 ou A5
Licence Microsoft 365 Entreprise E3 ou E5
Licence Enterprise Mobility + Security E3 ou E5
Licence Intune pour l’éducation
Licence ID Microsoft Entra P1 ou P2 + Licence Microsoft Intune

Afin de se faire une meilleure idée sur Autopilot v2, je vous propose un petit exercice à réaliser sur une souscription Azure.

Dans cet exercice, nous allons effectuer les étapes suivantes :

Microsoft a même mis à disposition un très bon tutoriel pour Autopilot v2 juste ici :

Etape 0 – Rappel des prérequis :

Afin de tester la fonctionnalité d’intégration proposée via Autopilot v2, nous allons avoir besoin de :

Un tenant Microsoft
Une souscription Azure valide
Une ou des licences contenant Intune et Azure AD Premium P1
Une Image OS de Windows 11, version 22H2 ou 23H2 générée après avril 2024 ou avec le KB5035942

Etape I – Configurer l’inscription automatique Windows à Intune :

Commençons par la configuration sur Entra ID.

Pour que la préparation des appareils Windows Autopilot (Autopilot v2) fonctionne, les appareils doivent être en mesure de s’inscrire automatiquement dans Intune. L’inscription automatique des appareils dans Intune peut être configurée automatiquement dans le portail Azure

Microsoft Learn

La méthode d’inscription à Intune avec Autopilot v2 ne diffère pas de la première : il est nécessaire de configurer une inscription automatique à Intune depuis le portail Entra ID.

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis cliquez sur cela :

Définissez le périmètre de l’inscription automatique MDM à Intune, puis cliquez sur Sauvegarder :

Restons sur le portail d’Entra ID afin d’autoriser les utilisateurs à joindre des machines à Intune.

Etape II – Autoriser les utilisateurs à joindre des appareils :

Pour rappel, il existe plusieurs types de jointures possibles à Entra ID, dont voici un lien vers un précédent article. Avec Autopilot v2, les utilisateurs ont toujours besoin d’être autorisé à joindre des postes à Entra ID.

Pour que la préparation des appareils Windows Autopilot fonctionne, les utilisateurs doivent être autorisés à joindre des appareils à l’ID Microsoft Entra.

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis activez cette option :

Continuons avec la création d’un premier groupe Entra ID dédié aux postes Intune.

Etape III – Créer un groupe d’appareils Entra ID :

La préparation des appareils Windows Autopilot utilise un groupe d’appareils dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Le groupe d’appareils spécifié dans la stratégie de préparation des appareils Windows Autopilot est le groupe d’appareils dans lequel les appareils sont ajoutés automatiquement pendant le déploiement de la préparation de l’appareil Windows Autopilot

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis créer un groupe dédié aux appareils automatiquement inscrits par Autopilot v2 :

Ajoutez le propriétaire Intune Provisioning Client ou avec son principal de service dont l’ID est le suivant : f1346770-5b25-470b-88bd-d5744ab7952c :

N’ajoutez aucun membre manuellement, puis cliquez sur Créer :

Continuons avec la création d’un second groupe Entra ID dédié aux utilisateurs Intune.

Etape IV – Créer un groupe d’utilisateurs Entra ID :

La préparation de l’appareil Windows Autopilot utilise un groupe d’utilisateurs dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Les utilisateurs membres du groupe d’utilisateurs spécifié dans la stratégie de préparation de l’appareil Windows Autopilot sont les utilisateurs qui reçoivent le déploiement de la préparation de l’appareil Windows Autopilot.

Microsoft Learn

Pour cela, restez sur le même menu qui précédemment d’Entra ID, puis créer un second groupe cette fois dédié aux utilisateurs concernés par le processus Autopilot v2 :

Ajoutez des membres manuellement ou dynamiquement en correspondance avec vos utilisateurs Autopilot v2, puis cliquez sur Créer :

Continuons avec la configuration de postes sous Intune.

Etape V – Affectation de la configuration Intune :

Pendant l’expérience OOBE (out-of-box experience) avant que l’utilisateur final ne soit connecté pour la première fois, la préparation de l’appareil Windows Autopilot permet de déployer jusqu’à :

10 applications managées

10 scripts PowerShell

Pour que les applications s’installent et que les scripts PowerShell fonctionnent correctement, ils doivent être affectés au groupe d’appareils créé pour la préparation des appareils Windows Autopilot.

Microsoft Learn

J’ai souhaité dans mon cas créer différents scénarios d’installation d’applications :

Applications intégrées au processus Autopilot v2 :
- Microsoft Company Portal (Windows Store)
- Global Secure Access (EXE)
Applications obligatoires pour les postes Intune :
- Google Chrome (MSI)
- Microsoft 365 Apps (Microsoft 365 Apps)
Applications disponibles pour les utilisateurs Intune :
- Adobe Acrobat Reader DC (Windows Store)
- Mozilla Firefox (Windows Store)
- Notepad X (Windows Store)

Pour cela, rendez-vous dans le menu suivant d’Intune, puis rajoutez vos applications concernées :

J’ai également rajouté un script PowerShell, mais que je ne souhaite pas intégrer dans le processus Autopilot v2 car les applications installées ou les scripts PowerShell qui s’exécuteront systématiquement dans un contexte système.

Il ne nous reste maintenant qu’à créer la stratégie de préparation des appareils Windows Autopilot.

Etape VI – Création de la stratégie de préparation des appareils Windows Autopilot :

La stratégie Autopilot spécifie la façon dont l’appareil est configuré pendant l’installation de Windows et ce qui est affiché pendant l’expérience OOBE (out-of-box experience).

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Intune, puis cliquez sur le menu suivant :

Cliquez sur Créer :

Cliquez sur Suivant :

Nommez votre profil, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux postes Intune via Autopilot v2, puis cliquez sur Suivant :

Définissez les paramètres de configuration Autopilot v2 :

Personnalisez l’expérience OOBE :

Ajoutez les applications intégrées dans le processus Autopilot v2 :

Ajoutez si besoin les scripts intégrés dans le processus Autopilot v2, puis cliquez sur Suivant :

Modifiez les tags au besoin, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Cliquez sur Sauvegarder :

La configuration Autopilot v2 est maintenant terminée, il ne nous reste qu’à créer une machine virtuelle Hyper-V sur Azure pour ensuite créer des machines sous Windows 11.

Etape VII – 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 (Hyper-V) :

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

Choisissez une taille de machine virtuelle présente dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la machine virtuelle Windows 11, créée plus tard dans notre machine virtuelle hôte (Hyper-V) :

Conservez les options par défaut, puis cliquez sur OK :

Cliquez ensuite 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 hôte (Hyper-V) :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les 2 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 2 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 dans Hyper-V, et 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 :

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 :

Cliquez sur Suivant :

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

Etape VIII – Création de la machine virtuelle Windows 11 :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin d’y installer l’OS.

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

Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :

Choisissez la langue désirée, puis cliquez sur Confirmer :

Cliquez sur la version 64 bits pour lancer le téléchargement :

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

Depuis votre VM Hyper-V, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows 11 :

Cliquez sur Suivant :

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

Pensez à bien sélectionner Génération 2 :

*Comme indiqué, cette option ne sera plus modifiable par la suite*.

Modifiez la taille de la mémoire vive allouée à la VM Windows 11, puis cliquez sur Suivant :

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

Cliquez sur Suivant :

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

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 11 :

Une fois la machine virtuelle Windows 11 créée, modifiez sa configuration comme ceci :

Dans la section Sécurité, cochez la case suivante pour activer TPM :

Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :

Double-cliquez sur votre machine virtuelle Windows 11 :

Cliquez-ici pour lancer le démarrage de la VM Windows 11 :

Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :

Attendez que le chargement se termine :

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

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

Lancez l’installation de Windows 11 :

Choisissez une version de Windows 11, puis cliquez sur Suivant :

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

Sélectionnez l’installation personnalisée de Windows 11 :

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

Attendez maintenant que l’installation de Windows 11 commence :

Lancez le redémarrage de la machine virtuelle Windows 11 :

Tout est bon, il ne nous reste plus qu’à voir si nouvelle méthode d’Autopilot v2 prend bien la suite de la configuration une fois l’utilisateur 365 authentifié.

Etape IX – Test Autopilot v2 :

Attendez quelques minutes que le redémarrage se termine :

Une fois l’interface Windows 11 affichée, sélectionnez le pays adapté, puis cliquez sur Oui :

Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :

Ajoutez si besoin un second clavier :

Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :

Le traitement peut être plus ou moins long :

Un redémarrage est même possible :

Afin que le processus Autopilot v2 fonctionne, configurez votre Windows 11 avec un des utilisateurs appartenant au groupe créé pour les utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Windows 11 se connecte alors au compte 365 pour en comprendre la configuration Autopilot v2 :

Le processus de préparation des appareils Windows Autopilot démarre alors :

Une fois le traitement terminé, cliquez sur Accepter :

Si besoin, déverrouillez la session Windows pour continuer :

Attendez la fin de configuration Windows :

Vous voilà enfin sur le bureau Windows 11 !

Attendez quelques minutes afin de voir le Company Portal s’installer automatiquement :

Le client Global Secure Access, est lui aussi installé automatiquement, ouvrant une fenêtre authentification avec possibilité SSO :

Environ 20 minutes plus tard, d’autres applications comme ceux liés à la suite Office, s’installent également de façon automatique :

Prenons en exemple l’installation manuelle de Mozilla Firefox :

L’installation manuelle via le Company Portal ne prend que quelques secondes :

Et l’application Firefox s’ajoute bien dans menu Démarrer de Windows :

Le script configuré en dehors de la Préparation de l’appareil Windows Autopilot (Autopilot v2) s’exécute bien dans le contexte utilisateur :

Enfin côté portail Intune, Microsoft propose également un nouveau rapport afin de surveiller l’état des déploiements Autopilot v2 :

Conclusion

J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible de cette nouvelle méthode Autopilot v2. Bien entendu, et comme le rappelle Microsoft, ce nouveau type de déploiement ne pourra pas encore prendre en compte tous les scénarios ou toutes les configurations.

Modifiez la langue de votre VM

Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.

Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.

Microsoft préconise cette approche pour AVD :

À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.

Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.
Microsoft Learn

La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.

En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.

Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.

Voici donc les quelques chapitres dans mon article :

Etape 0 – Rappel des prérequis :

Pour réaliser mon test, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Commençons par créer une machine virtuelle sous Windows 11.

Etape I – Création d’une machine virtuelle :

Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :

Comme attendu, l’écran de démarrage est par défaut en anglais :

L’interface utilisateur l’est également :

Allons voir dans Language et région :

Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :

Seul le pack Anglais (USA) semble installé :

Cela se confirme par la commande suivante :

Get-InstalledLanguage

Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :

Le pays est là encore défini sur USA, peu importe le région Azure utilisée :

De façon logique, le formatage Anglais (USA) y est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA) :

Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.

Etape II – Modification de la langue via script :

Commençons par ouvrir une fenêtre PowerShell ISE :

Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :

Get-InstalledLanguage

Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :

$regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
$RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
$Language : modifier au besoin le language (liste)
$GeoId : Zone géographique (liste)
$TimeZone : Fuseau horaire par défaut (liste)

# Script to define regional settings on Azure Virtual Machines deployed from the market place
# Author: Created by Alexandre Verkinderen, modified by Jean-Loup Orgitello
# Blogpost: https://mscloud.be/configure-regional-settings-and-windows-locales-on-azure-virtual-machines/
#
########################################

#variables
$regionalsettingsURL = "https://raw.githubusercontent.com/jlou07/CHLang/main/CHRegion.xml"
$RegionalSettings = "C:\Region.xml"
$Language = "fr-CH"
$GeoId = "223"
$TimeZone = "W. Europe Standard Time"

#LanguagePack Suisse
Install-Language $Language

#downdload regional settings file
$webclient = New-Object System.Net.WebClient
$webclient.DownloadFile($regionalsettingsURL,$RegionalSettings)

#LanguagePack USA
unInstall-Language "en-US"
Start-sleep -Seconds 120

# Set languages/culture. Not needed perse.
Set-WinSystemLocale $Language
Set-WinUserLanguageList -LanguageList $Language -Force
Set-Culture -CultureInfo $Language
Set-WinHomeLocation -GeoId $GeoId 
Set-TimeZone -id $TimeZone

# Set Locale, language etc. 
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"$RegionalSettings`""

# restart virtual machine to apply regional settings to current user. 
Start-sleep -Seconds 40
Restart-Computer

L’installation d’un pack de langue prend environ 5 minutes :

La suite du script est assez rapide, à l’exception des 2 pauses ajoutées et d’un redémarrage OS :

L’ajout du pack de langue Français (Suisse) entraine également l’ajout du pack de langue Français (France).

Une fois le script terminé, la machine virtuelle redémarre toute seule comme indiqué dans le script :

Il ne nous reste qu’à vérifier l’impact sur notre utilisateur local.

Etape III – Contrôle des changements :

Reconnectez-vous à l’utilisateur après le redémarrage du script :

L’écran de démarrage est maintenant en Français (Suisse):

L’interface utilisateur l’est également :

Allons voir encore une fois dans Langue et région :

Seul le Français (Suisse) est disponible pour notre utilisateur administrateur :

Seul le pack Français (Suisse) semble cette fois installé :

Vérifions une dernière fois le ou les packs de langue installés via le script par la commande PowerShell suivante :

Get-InstalledLanguage

Presque toutes les features et le clavier correspondant semblent correctement installés pour notre pack de langue :

Le pays est maintenant encore défini sur Suisse, comme voulu :

De façon logique, le formatage Suisse est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Tout est maintenant bien configuré en Français (Suisse) :

Conclusion

Certaines bonnes vieilles méthodes continuent encore de marcher. Dites-moi dans les commentaires si vous appliquez d’autres moyens pour y parvenir 😎

Associez un disque éphémère à votre AVD

Les disques éphémères existent depuis déjà quelques années sur Azure. Mais est-ce qu’un environnement de bureau à distance comme Azure Virtual Desktop associé à ce type de disque est possible ? Si oui, qu’est-ce que cela donne en termes de performances, mais également quelles en seraient les contraintes ?

Qu’est-ce qu’un disque éphémère sur Azure ?

Contrairement aux disques persistants, les disques éphémères sont :

temporaires et ne conservent pas les données au-delà du cycle de vie de la machine virtuelle.
Ils offrent généralement des performances supérieures aux disques persistants car ils sont directement attachés à l’hôte physique sous-jacent.
Ils sont également sujets à la perte de données en cas de panne de la machine virtuelle ou de redémarrage.
Leur prix est inclus dans le coût de la taille de la machine virtuelle.
Leur taille dépend exclusivement de la taille de la machine virtuelle choisie.
Peut se présenter sous deux formes possibles : cache ou disque temporaire (D).

L’excellente vidéo de John Savill vous permettra de bien comprendre le principe des différents disques éphémères sur Azure :

Quels sont les risques à utiliser un disque éphémère ?

Ces disques sont souvent utilisés pour des charges de travail temporaires qui ne nécessitent pas de stockage permanent ou pour des applications qui peuvent reconstruire leurs données en cas de perte.

Il est donc essentiel de sauvegarder les données importantes sur des disques persistants ou d’autres services de stockage Azure si la persistance des données est nécessaire.

Voici 2 pages utiles pour mettre en pratique les disques éphémères :

Comparé à un disque de système d’exploitation standard, un disque éphémère offre une latence plus faible pour les opérations de lecture/écriture et permet une réinitialisation plus rapide des machines virtuelles.
Microsoft Learn

Enfin, Microsoft a mis à disposition la FAQ suivante sur Microsoft Learn.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur Azure Virtual Desktop combiné à plusieurs types de disque :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les disques éphémères intégrés à un Azure Virtual Desktop, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Préparation de l’environnement AVD :

Avant de pouvoir déployer un environnement Azure Virtual Desktop, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Cliquez-ici pour accéder à votre réseau virtuel :

Dans le menu suivant, cliquez ici pour déployer Azure Bastion :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Choisissez le type Partagé pour l’environnement AVD, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Sélectionnez la taille de VM suivante ainsi que le disque OS en Premium SSD :

Note : comme vous pouvez le voir, il n’est pas possible depuis l’interface actuelle d’AVD d’y spécifier un disque OS éphémère.

Joignez votre VM à Microsoft Entra ID, puis cliquez sur Suivant :

Créez un 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 terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

Vérifiez la présence d’un disque OS managé Premium SSD, puis cliquez-dessus :

Vérifiez les caractéristiques du disque :

Notre environnement Azure Virtual Desktop est maintenant en place. Nous devons maintenant rajouter 2 machines virtuelles supplémentaires pour comparer les performances des disques :

Création d’une VM AVD avec un disque éphémère cache
Création d’une VM AVD avec un disque éphémère temporaire

Commençons par la machine virtuelle dont le disque OS sera sur le cache.

Etape II – Création d’une VM AVD avec un disque éphémère CACHE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre seconde machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v3 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le cache, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre seconde VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre seconde machine virtuelle :

Vérifiez également la jointure à Entra ID depuis la session Bastion et grâce à la commande suivante :

dsregcmd /status

Quelques secondes plus tard, le statut de votre seconde VM passe en disponible :

Continuons avec la création de la troisième VM dont le disque OS sera sur la partition temporaire.

Etape III – Création d’une VM AVD avec un disque éphémère TEMPORAIRE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre troisième machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v5 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le temporaire, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre troisième VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre troisième machine virtuelle :

Quelques secondes plus tard, le statut de votre troisième VM passe en disponible :

Nos 3 machines virtuelles sont maintenant opérationnelles. Pourtant nous ne voyons qu’un seul disque en tant que ressource Azure :

Pourtant le disque OS est bien présent sur la seconde VM :

Le disque OS est également bien présent sur la troisième VM, dont les IOPS sont très très élevés :

Pour nous y connecter avec des utilisateurs AVD, nous devons maintenant rajouter des droits à des utilisateurs de test sur celles-ci.

Etape IV – Connexions aux VMs de l’environnement AVD :

Sur ce même groupe de ressources, ajoutez les deux rôles Azure RBAC suivants pour vos utilisateurs de test :

Ouvrez ensuite le client Remote Desktop puis authentifiez-vous avec 3 utilisateurs différents :

Ouvrez ensuite 3 sessions AVD de telle façon à ce que chacun se retrouve seul sur une VM :

Sur chacune des 3 sessions AVD :

Ouvrez le gestionnaire des disques afin de constater les différentes tailles des partitions.
Téléchargez l’exécutable DiskSpd via ce lien Microsoft, puis décompressez l’archive ZIP à la racine du disque C.

Lancez le moniteur de ressources Windows.
Ouvrez une fenêtre PowerShell en mode administrateur, puis exécutez les 2 scripts de tests suivants :

.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L C:\diskpsdtmp.dat > IOPS.txt
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L C:\diskpsdtmp.dat > Throughput.txt

Machine virtuelle AVD avec disque OS Premium SSD :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

Voici un tableau affichant les informations de la VM D8s v3 :

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien la soustraction de 300 Go – 128 Go, soit environ 172 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Voyons ensemble les différentes de performances des 3 machines virtuelles AVD.

Etape V – Synthèse des résultats :

Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :

j’ai également synthétisé tous mes résultats Throughput dans le tableau ci-dessous :

Conclusion

Il n’y a rien à dire, l’écart de performances entre ces 3 types de disque est très impressionnant ! Et cet écart se creuse encore plus si on change la taille de la machine virtuelle TEMP en D16ds v5 :

De plus, j’ai utilisé le Calculateur Azure afin de comparer les prix des 3 types de disque selon les performances relevées plus haut :

Enfin, Microsoft nous rappelle certaines contraintes liées à l’utilisation de disque OS éphémères :

Un redimensionnement de la machine virtuelle avec un disque éphémère fera perdre toute la donnée modifiée :

Il n’est pas possible de désallouer les ressources machines quand un disque éphémère est utilisé :

Il n’est pas possible de sauvegarder une machine virtuelle quand un disque OS éphémère est utilisé :

En somme, ces points ne devraient pas être des blocages pour des environnements Azure Virtual Desktop dans la mesure où ces derniers, généralement, ne stockent pas d’informations utilisateurs et sont constitués à partir d’une golden image 😎🙏.

Azure Virtual Desktop sur Azure Stack HCI

Bonne nouvelle ! Azure Stack HCI 23H2 est maintenant disponible en GA. La 23H2 simplifie grandement la configuration et le déploiement des clusters HCI. Autre bonne nouvelle, AVD est aussi en GA sur Azure Stack HCI ! Si tester Azure Virtual Desktop via une solution cloud hybride et sans acheter quoi que ce soit vous intéresse, cet article est fait pour vous !

Un premier article avait déjà été écrit sur ce blog à propos d’Azure Stack HCI. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :

Peut-on tester Azure Stack HCI sans investir dans du matériel physique ?

La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Stack HCI directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.

Qu’est-ce qu’Azure Arc Jumpstart ?

Il s’agit de solutions de type bac à sable proposées par Microsoft :

L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.
Azure Arc Jumpstart

Comme le montre la page suivante, beaucoup de scénarios y sont proposés :

Mais qu’est-ce qu’HCIBox ?

En quelques mots : il vous permet d’essayer Azure Stack HCI directement dans Azure :

HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Stack HCI et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Stack HCI et la technologie Azure Arc sans avoir besoin de matériel physique.
Azure Arc Jumpstart

Combien coûte le service HCIBox ?

Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.

Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :

Enfin, une FAQ de la HCIBox est disponible juste ici.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Stack HCI construit dans une HCIBox elle-même hébergée sur Azure :

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

Etape I – Préparation de l’environnement Azure :

Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.

Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :

Note : Si cela n’est pas le cas, le stylo à droite vous permet de créer une demande de modification de quota. Cette demande sera traitée automatiquement ou génèrera un ticket de support chez Microsoft.

Ouvrez ensuite Azure Cloud Shell via le bouton situé dans la barre en haut de votre portail Azure :

Si l’ouverture d’Azure Cloud Shell est une première sur votre environnement Azure, il vous sera demandé de créer un compte de stockage comme le montre l’exemple ci-dessous :

Une fois Azure Cloud Shell ouvert en PowerShell, exécuter la commande suivante afin de recréer le référentiel Azure Arc Jumpstart sur votre compte de stockage :

git clone https://github.com/microsoft/azure_arc.git

Vérifiez la version installée d’Azure CLI avec la commande ci-dessous. Celle-ci doit être supérieure ou égale à la version 2.56.0 :

az --version

Dans le cas où plusieurs souscriptions Azure sont en place sur votre tenant, utilisez la commande suivante afin d’identifier la souscription actuellement sélectionnée :

az account list --query "[?isDefault]"

Utilisez la commande suivante et disponible ici pour changer au besoin la souscription :

az account set

Utilisez la commande suivante afin de vérifier le bon changement de sélection :

az account list --query "[?isDefault]"

Utilisez la commande suivante afin de vérifier que les quotas liés à la région Azure et à la famille de VMs soient suffisants :

az vm list-usage --location westeurope --output table

Créez un principal de service Azure (SP) disposant d’un contrôle d’accès (RBAC) de propriétaire sur la souscription Azure, prenez soin de sauvegarder les 3 valeurs en sortie :

az ad sp create-for-rbac -n "JumpstartHCIBox" --role "Owner" --scopes /subscriptions/$subscriptionId

Vérifiez cette création depuis la page des droits RBAC de votre souscription Azure :

Profitez-en pour Enregistrer le fournisseur de ressources suivant sur votre souscription Azure :

Le statut du fournisseur de ressources change durant cette phase :

Environ 30 secondes plus tard, le statut du fournisseur de ressources change encore une fois :

De retour sur Azure Cloud Shell, mettez à jour la dernière version de Bicep

az bicep upgrade

Récupérez l’identifiant d’objet du fournisseur de ressources Azure Stack HCI de votre tenant :

az ad sp list --display-name "Microsoft.AzureStackHCI Resource Provider"

Votre environnement est maintenant configuré pour commencer le déploiement des ressources Azure de votre HCIBox.

Etape II – Déploiement des ressources Azure :

Pour cela, récupérez le template au format JSON disponible à cette adresse afin de modifier les informations suivantes :

spnClientId : Votre identifiant de principal de service Azure
spnClientSecret : Votre secret de principal de service Azure
spnTenantId : Votre identifiant de tenant Azure
spnProviderId : Votre identifiant de fournisseur de ressources Azure Stack HCI
WindowsAdminUsername : Nom d’utilisateur de l’administrateur
windowsAdminPassword : Mot de passe de l’administrateur
logAnalyticsWorkspaceName : Nom unique pour l’espace de travail HCIBox Log Analytics
deployBastion : Option pour déployer ou non Azure Bastion

Téléversez le fichier template au format JSON modifié sur Azure :

Déplacez le fichier template dans le dossier Bicep :

mv ./main.parameters.json ./azure_arc/azure_jumpstart_hcibox/bicep/

Positionnez-vous également dans ce même dossier :

cd ./azure_arc/azure_jumpstart_hcibox/bicep/

Lancez la commande suivante afin de créer un groupe de ressources dans la région Azure de votre choix :

az group create --name "jlohci"  --location "westeurope"

Lancez la commande suivante afin de déployer les ressources Azure de votre HCIBox :

az deployment group create -g "jlohci" -f "main.bicep" -p "main.parameters.json"

Suivez le déploiement des ressources Azure depuis le nouveau groupe de ressources créé :

Environ 30 minutes plus tard, les ressources Azure de votre HCIBox sont enfin déployées :

Les ressources Azure servant à votre HCIBox sont maintenant en place :

L’étape suivante va consister à déployer différents serveurs nécessaires à votre Cluster Azure Stack HCI. Pour cela, nous utiliserons un script PowerShell déjà préparé.

Etape III – Déploiement des nœuds connectés via Azure Arc :

Pour lancer ce script, nous devrons ouvrir une session RDP sur la machine virtuelle hôte. Pour cela recherchez la machine virtuelle suivante, puis cliquez sur celle-ci :

Démarrez une session RDP via le service Azure Bastion en utilisant les identifiants renseignés dans le template JSON :

Une fois que vous vous êtes connecté en RDP, le script PowerShell s’ouvre automatiquement :

Ce script prendra au total entre 1 et 2 heures avec 10 différentes étapes.

Téléchargement des fichiers VHDX de l’OS Azure Stack HCI :

Configuration de la virtualisation :

Création de la VM de management sous Hyper-V :

Création des 2 VMs représentants les 2 nœuds Azure Stack HCI :

Démarrage des 3 machines virtuelles :

Configurations réseaux et stockages :

A l’intérieur même de la machine virtuelle de management, déploiement d’une autre VM dédiée au réseau :

Finalisation du déploiement de l’infrastructure Azure Stack HCI dont l’enrôlement de nos 2 serveurs sur Azure via Azure Arc:

Comme indiqué plus haut, le script PowerShell se ferme automatiquement à la fin :

Si le script vous affiche une ou plusieurs erreurs, différents journaux d’évènements sont disponibles dans le dossier suivant :

C:\HCIBox\Logs\

Il existe également une page officielle de Troubleshoot juste ici :

Log file	Description
C:\HCIBox\Logs\Bootstrap.log	Output from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.log	Output of New-HCIBoxCluster.ps1 which configures the Hyper-V host and builds the HCI cluster, management VMs, and other configurations.
C:\HCIBox\Logs\Generate-ARM-Template.log	Log output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.log	Log output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.log	Log output from tools installation during bootstrap

Afin de bien vérifier la connexion à Azure, recherchez le service Azure Arc via la barre du portail Azure :

Vérifiez que les deux nœuds HCI sont présents dans Azure Arc :

Vérifiez que les deux nœuds ont correctement installé avec succès les trois extensions suivantes :

TelemetryAndDiagnostics
AzureEdgeLifecycleManager
AzureEdgeDeviceManagement

Vérifiez également sur le second nœud la présence de ces 3 extensions :

Enfin comme le montre l’image ci-dessous, votre Cluster Azure Stack HCI n’est pas encore déployé :

Azure Stack HCI utilise un processus en 2 étapes pour valider et déployer des clusters Azure Stack HCI dans Azure à l’aide d’un modèle ARM.

Etape IV – Déploiement du cluster Azure Stack HCI :

Avant cela, commencez par ajouter à votre compte Entra ID les 2 rôles Entra ID suivants :

Administrateur Key Vault
Contributeur au compte de stockage

Retournez sur la session RDP ouverte via Azure Bastion, ouvrez l’explorateur de fichiers, faites un clic droit sur le dossier HCIBox, puis ouvrez-le dans VSCode :

Cliquez-ici pour continuer :

Vérifiez que le fichier hci.parameters.json est correct et sans valeurs de paramètre -staging :

Toujours sur la machine virtuelle hôte, ouvrez le portail Azure avec votre identifiant Entra ID, puis rechercher le service suivant :

Sélectionnez Construire votre propre modèle dans l’éditeur :

Collez le contenu du fichier hci.json dans l’éditeur, puis cliquez sur Enregistrer :

Cliquez sur Editer les paramètres :

Collez le contenu de hci.parameters.json dans l’éditeur, puis cliquez sur Enregistrer :

Renseignez votre groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, exécutez le template ARM :

Attendez que ce dernier soit terminé :

Environ 15 minutes plus tard, cliquez-ici pour ouvrir à nouveau votre groupe de ressources :

Cliquez sur la nouvelle ressource Azure représentant votre cluster Azure Stack HCI :

Un bandeau vous indique que la validation est réussie mais que le déploiement n’est pas encore effectué. Cliquez-ici pour le lancer :

La mise en place du template ARM vous amène directement sur l’onglet suivant, lancez la validation Azure :

Une fois la validation Azure réussie, lancez le déploiement des ressources, puis attendez :

Suivez l’avancement du déploiement du cluster Azure Stack HCI via le menu suivant :

Environ 2 heures plus tard, cette même page vous indique la fin du déploiement du cluster Azure Stack HCI :

Retournez sur la page principale de votre cluster Azure Stack HCI afin de lancer au besoin les mises à jour disponibles (2402) :

Lancez la mise à jour 2402 comme ceci :

Cliquez sur Suivant :

Lancez l’installation de la mise à jour :

Suivez l’avancement de la mise à jour de votre cluster via le menu suivant :

Environ 2 heures plus tard, cette même page doit vous indiquer la fin de la mise à jour sur de votre cluster Azure Stack HCI :

Votre cluster Azure Stack HCI est enfin installé et à jour. Nous allons maintenant pouvoir nous intéresser à son contenu, à savoir :

les images OS
les réseaux logiques

Etape V – Images OS et réseaux logiques d’Azure Stack HCI :

Avant de pouvoir créer des machines virtuelles sur votre cluster HCI à partir du portail Azure, vous devez créer des images de VM qui peuvent être utilisées comme base. Ces images peuvent être importées de la place de marché Azure ou fournies directement par l’utilisateur.
Azure Arc Jumpstart

Cliquez-ici pour importer une image à partir de la Marketplace d’Azure :

Dans mon exemple, j’importe les deux images OS suivantes :

Windows 11 Enterprise multisession + Microsoft 365 Apps, version 23H2
Windows Server 2022 Datacenter: Azure Edition

La première étape consiste à télécharger sur votre cluster les deux images OS :

Environ 2 heures plus tard, le téléchargement des 2 images est terminé :

Comme nous le rappelle Azure Arc Jumpstart, Le réseau de la HCIBox comprend un sous-réseau 192.168.200.0/24 étiqueté VLAN200 :

Network details
Subnet	192.168.200.0/24
Gateway	192.168.200.1
VLAN Id	200
DNS Server	192.168.1.254

Ce réseau est conçu pour être utilisé avec les VMs Arc sur HCIBox. Pour utiliser ce réseau préconfiguré, vous devez créer une ressource réseau logique qui correspond à ce sous-réseau.

Depuis la VM hôte ouverte en RDP, ouvrez le script PowerShell suivant afin de créer le réseau logique sur votre cluster Azure Stack HCI :

Une fois le script correctement exécuté, le réseau logique est visible sur le portail Azure juste ici :

Les information de sous-réseau, de passerelle et de serveur DNS sont bien reprises :

Tous les éléments de configuration sont maintenant en place pour commencer la création de machines virtuelles dans votre cluster Azure Stack HCI.

Avant de déployer un environnement Azure Virtual Desktop, je vous propose de créer une machine virtuelle fonctionnant sous Windows Server 2022.

Etape VI – Déploiement d’une machine virtuelle Windows Server 2022 :

Depuis la page de votre cluster Azure Stack HCI, cliquez-ici pour créer votre première machine virtuelle :

Choisissez un groupe de ressources, donnez un nom à votre VM, puis sélectionnez Standard pour le type de sécurité :

Sélectionnez l’image Windows Server que vous avez téléchargée précédemment, puis définissez sa taille et sa mémoire :

Cochez la case suivant, puis définissez un compte administrateur local :

Joignez la VM au domaine AD créé pour votre Azure Stack HCI, puis cliquez sur Suivant :

Inutile d’ajouter d’autres disques de données, cliquez sur Suivant :

Cliquez-ici pour ajouter une carte réseau :

Nommez la carte réseau, sélectionnez le réseau logique créé précédemment, choisissez la méthode d’allocation sur Automatique, puis cliquez sur Ajouter :

Cliquez sur Suivant :

Ajoutez au besoin des tags, puis cliquez sur Suivant :

Cliquez sur Créer :

Comme pour une ressource Azure classique, vous pouvez suivre toutes les étapes du déploiement :

Environ 20 minutes plus tard, cliquez-ici pour apercevoir les propriétés de votre VM :

Copiez l’adresse IP privée de votre nouvelle VM :

Depuis la session ouverte via Azure Bastion, ouvrez une session Hyper-V sur la machine virtuelle de management :

Utilisez le compte suivant :

Ouvrez une session RDP via l’adresse IP privée de votre nouvelle VM tout en utilisant un compte de domaine :

Constatez la bonne ouverture de session sur votre machine virtuelle Windows Server 2022 :

Le test d’une machine virtuelle individuelle fonctionne bien. Il ne nous reste plus qu’à tester le déploiement d’un environnement Azure Virtual Desktop sur votre cluster Azure Stack HCI.

Etape VII – Déploiement d’Azure Virtual Desktop :

Avant de pouvoir déployer votre environnement Azure Virtual Desktop. Il est conseillé de synchroniser les identités Active Directory avec Entra ID.

Pour cela, ouvrez une session Hyper-V à votre contrôleur de domaine de démonstration :

Utilisez le compte de domaine suivant :

Créez une nouvelle OU, des utilisateurs de test et un groupe dédié à Azure Virtual Desktop :

Téléchargez et installez Microsoft Entra Connect via ce lien direct :

Depuis la page des utilisateurs d’Entra ID, vérifiez la bonne synchronisation de vos utilisateurs et votre groupe AVD :

Retournez sur la page de votre cluster Azure Stack HCI, puis cliquez-ici pour déployer votre environnement Azure Virtual Desktop :

Renseignez les informations de base de votre pool d’hôtes Azure Virtual Desktop, puis cliquez sur Suivant :

Ajoutez un ou des VMs Azure Stack HCI à votre AVD en reprenant l’image Windows 11 Enterprise multisession :

Définissez sa taille, sa mémoire et son réseau logique :

Joignez-la au domaine Active Directory, renseignez le compte d’administrateur local, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

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

Attendez environ 1 heure :

L’image ci-dessous vous montre l’apparition des VMs AVD :

Seulement, et contrairement au déploiement de la première VM sous Windows Server 2022, le management invité n’est pas automatiquement installée sur les VMs AVD :

Afin d’éviter un échec de votre déploiement AVD, actualiser la page de votre machine virtuelle AVD régulièrement afin d’activer le management invité dès que cela est possible :

Attendez environ 2 minutes le temps de la préparation :

Copiez le script suivant pour sa mise en place :

Récupérez l’adresse IP privée de votre VM AVD :

Depuis la VM de management, ouvrez une session RDP avec le compte administrateur local :

Collez le script sur la VM AVD :

Sur le portail Azure, activez le management invité de votre VM dès que cela est possible :

Suivez l’activation du management invité par le menu suivant :

Rafraichissez la page plusieurs fois si nécessaire :

Environ 30 minutes plus tard, le déploiement de votre AVD doit se terminer :

Consultez votre pool d’hôtes AVD depuis le portail Azure :

Vérifiez également la bonne apparition de vos VMs AVD dans votre Active Directory :

Ajoutez votre groupe Entra ID synchronisé à votre AVD en tant qu’utilisateurs AVD :

Démarrez votre client Remote Desktop, puis ouvrez une session AVD sur un utilisateur de test :

Renseignez à nouveau le mot de passe de votre utilisateur :

Attendez quelques secondes l’ouverture de votre session Azure Virtual Desktop :

Conclusion

Grâce à la HCIBox, nous avons rapidement et facilement pu se rendre compte de l’écosystème hybride proposé par Microsoft pour une de leurs solutions phares : Azure Virtual Desktop.

Important : Attention tout de même à ne pas trop dépenser de crédits pour votre HCIBox. pensez à supprimer ou éteindre vos ressources une fois vos tests terminés :

Ce rappel des coûts de la HCIBox m’amène à une autre question :

Est-il rentable de faire fonctionner Azure Virtual Desktop sur Azure Stack HCI quand d’autres solutions on-premise existent également ?

Les avis de la communauté sont partagés, comme l’article écrit par PureRDS :

Plusieurs coûts sont en effet présents pour un Azure Virtual Desktop hébergé sur Azure Stack HCI.

Coûts licences utilisateurs :

Coûts licences infra :

Enfin voici quelques vidéos pour vous faire votre propre opinion 😎 :

FSLogix sont nos amis 🙏!

FSLogix est une excellente solution pour assurer la gestion des profils de vos utilisateurs. Très souvent utilisé dans différents types d’environnement VDI, FSLogix s’adapte très bien et très facilement à Azure Virtual Desktop. Mais la configuration de FSLogix a besoin d’être manipulée avec précaution pour ne pas devenir un cauchemar pour vos utilisateurs et par ricochet sur vous.

Un précédent article sur ce blog parle déjà de la mise en place de la solution FSLogix au sein d’un environnement Azure Virtual Desktop, dont voici le lien.

La solution FSLogix en quelques mots & vidéos :

Azure Virtual Desktop recommande les conteneurs de profil FSLogix. FSLogix est société acquise par Microsoft en novembre 2018. Elle propose une solution de conteneurisation des profils utilisateurs en itinérance, utilisable dans une large gamme de scénarios sous format VHD ou VHDX. Avec FSLogix, vous allez pouvoir réaliser les actions suivantes pour vos utilisateurs :

Centralisation des profils utilisateurs Azure Virtual Desktop
Dissociation possible entre les conteneurs Office365 avec les conteneurs profils utilisateurs
Gestion des applications visibles ou non via la fonction AppMasking
Contrôle des versions JAVA
Customisation de l’installation via de nombreuses règles ou via GPO
Sans les conteneurs de profil FSLogix, OneDrive Entreprise n’est pas pris en charge dans les environnements RDSH ou VDI non persistants

Un grand merci à Dean Cefola de l’Azure Academy pour cette playlist YouTube très complète autour de FSLogix :

Il est important de comprendre que la configuration FSLogix dépendra de beaucoup de paramètres, et qu’il est difficile d’en établir une adaptée à tous les cas d’usages.

Durant l’écriture de cet article, j’ai retrouvé un grand nombre de documentations utiles à une meilleure compréhension de FSLogix, dont certaines proviennent Microsoft Learn :

Mais aussi d’autres sources non-Microsoft :

Ce nouvel article a donc pour but de partager avec vous une problématique FSLogix possible ainsi qu’une méthode de résolution :

Pour des questions de confidentialité, l’environnement présent ci-dessous est une copie approchante de l’environnement réel du client concerné.

Etape 0 – Contexte :

Je suis intervenu sur un environnement Azure Virtual Desktop sur lequel les utilisateurs se plaignaient d’être constamment obligés de se réauthentifier à leurs outils Microsoft 365 à chaque ouverture :

Cela concernait les outils de productivités (Word, Excel, PowerPoint), mais également les outils de collaborations (Outlook, OneDrive, Teams). La gêne pour les utilisateurs était donc évidente.

Voici une description des ressources Azure déjà en place :

Domain managé Entra Domain Services
Environnement AVD avec 2 hôtes
Stockage des profiles FSLogix sur un Azure File Share + sauvegarde
Gestion des images via une Azure compute gallery
Accès RDP via Azure Bastion

Voici le groupe de ressources Azure contenant le domaine managé Microsoft :

Voici le groupe de ressources Azure contenant l’environnement AVD et le compte de stockage utilisé pour les profils FSLogix :

Voici le groupe de ressources Azure contenant l’image Windows 11 stockée dans une Azure compute gallery :

Voici une vue de l’environnement Azure Virtual Desktop :

Voici une vue des groupes Entra ID en relation avec Azure Virtual Desktop :

Voici une vue du compte stockage contenant le partage de fichiers dédié aux profils FSLogix :

Voici le paramétrage indiquant que le compte de stockage est joint au domaine managé Microsoft et les droits RBAC de base pour le partage :

Concernant la partie administration d’AVD, je retrouve bien des droits d’administration RBAC plus élevés et dédiés à la configuration des droits NTFS :

La sauvegarde concernant la partie FSLogix est également bien en place :

Sur ce même compte de stockage dédié à FSLogix, l’accès réseau Internet est bien coupé :

En lieu et place, un point d’accès privé pour connecter le compte de stockage au réseau virtuel AVD :

En me connectant avec un compte administrateur sur l’environnement AVD, j’ai pu vérifier que les droits NTFS appliqués au partage de fichiers FSLogix étaient bien cohérent :

Enfin les règles de registres implémentés directement sur la VM AVD et donc sur l’image reprennent les recommandations de base de Microsoft, disponible juste ici :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

L’environnement semble bon, et le problème semble à priori en relation avec les tokens.

L’étape suivante est alors la reproduction sur problème rencontré par les utilisateurs d’Azure Virtual Desktop.

Etape I – Premier test d’un l’utilisateur impacté :

Pour cela, j’utilise le client Remote Desktop sur Windows afin d’ouvrir une session AVD sur un utilisateur impacté :

Je renseigne les identifiants :

La session Windows 11 s’ouvre bien et indique un chargement du profil via la solution FSLogix :

Le dossier du profil est bien présent sur le partage de fichier Azure comme indiqué dans la configuration registre Windows :

J’ouvre une première fois l’outil Power Point :

Je m’identifie dans l’application avec un compte Microsoft 365 correctement licencié :

L’authentification d’Office 365 fonctionne bien et sans erreur :

Je ferme et réouvre la session Azure Virtual Desktop avec ce même utilisateur :

Je réouvre PowerPoint et je constate le besoin de réauthentification systématique, comme dans toutes les autres applications Microsoft 365 :

Par le bais de l’explorateur Windows, je me rends dans le dossier suivant pour ouvrir l’application frxtray :

C:\Program Files\FSLogix\Apps\
- frxtray.exe

J’affiche les différents journaux d’évènements à la recherche d’erreurs potentielles, sans succès :

Afin de poursuivre mon investigation, je décide d’appliquer la stratégie suivante :

Création d’une nouvelle machine virtuelle AVD depuis la dernière image
Mise à jour de l’OS Windows 11
Mise à jour des applications Office 365
Mise à jour de FSLogix

Pour cela, je commence par créer cette nouvelle machine virtuelle Azure.

Etape II – Création d’une première VM image AVD :

Je créé une nouvelle machine virtuelle en prenant soin de sélectionner la dernière image AVD en Windows 11 personnalisée et stockée dans la galerie :

Une fois créée, je m’y connecte en utilisant le service Azure Bastion :

Je lance toutes les mises à jour Windows 11 disponibles :

Pour effectuer les mises à jour d’Office365, je réactive la règle de registre suivante :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
- UpdatesEnabled
  - True

J’ouvre un programme Office 365 et lance la recherche des mises à jour :

J’attends le message suivant signifiant la bonne installation des mises à jour Office 365 :

Je retourne dans le registre Windows pour remettre la valeur suivante :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
- UpdatesEnabled
  - False

Dans la liste des applications installées, je vérifie et désinstalle si besoin l’ancienne version de FSLogix :

Je redémarre la machine et retourne sur le site officiel de Microsoft pour y télécharger la dernière version de FSLogix :

J’en profite pour parcourir les notes des dernières versions de FSLogix :

Et la suite se passe de commentaire 🤣.

Etape III – Identification de la cause :

J’en profite pour parcourir les bogues connus de FSLogix :

Et je tombe sur celui-ci 😎 :

Microsoft propose également une résolution juste ici :

Je décide donc de rajouter cette clef de registre sur mon image AVD à jour :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles
- RoamIdentity
  - 1

La correction est maintenant appliquée sur ma machine virtuelle image. Je décide donc de créer une nouvelle image contenant les mises à jour Windows 11, Office 365 et FSLogix, mais également la correction apportée par la clef de registre.

Etape IV – Création d’une seconde VM image AVD :

Sur la machine virtuelle image, je lance la commande Sysprep suivante selon la documentation Microsoft :

Sysprep /generalize /oobe /mode:vm /shutdown

Sysprep s’exécute et m’invite à patienter quelques minutes :

La session de bureau à distance ouverte via Azure Bastion se ferme quand la machine virtuelle commence sa phase d’extinction :

Quelques secondes plus tard, le portail Azure affiche bien la machine virtuelle image comme étant arrêtée, je décide donc de l’arrêter complètement :

Une fois entièrement désallouée, je lance la capture :

Je créé une nouvelle version dans la galerie utilisée précédemment, et attends environ 20 minutes que le traitement se termine :

L’environnement Azure Virtual Desktop est maintenant prêt pour recevoir une nouvelle machine virtuelle à partir de cette image.

Etape V – Création d’une nouvelle hôte AVD :

Je retourne sur la page de mon pool d’hôte AVD afin d’y ajouter une nouvelle VM comme ceci :

Je reprends la même taille de VM qu’utilisée précédemment tout en choisissant la dernière version de mon image, puis lance la création des ressources Azure :

Environ 10 minutes plus tard, une nouvelle hôte apparaît dans mon environnement Azure Virtual Desktop. Enfin j’active le mode Drain sur les autres machines virtuelles encore sous ancienne version d’image AVD :

Il ne me reste plus maintenant qu’à retester avec le compte d’un utilisateur impacté pour constater un changement après plusieurs réouvertures d’une session AVD.

Etape VI – Second test d’un l’utilisateur impacté :

J’utilise à nouveau le client Remote Desktop sur Windows afin d’ouvrir une session AVD sur un utilisateur de test :

Après plusieurs connexions / déconnexions, l’authentification 365 persiste bien dans les différentes applications 365. Pour en être sûr, plusieurs tests sont effectués dans les applications Word, Excel, PowerPoint, Outlook, OneDrive, Teams. 😎💪

Conclusion

Dans mon cas le problème a été résolu car plusieurs informations ont été partagées sur des forums IT et sur la documentation Microsoft. Cela n’est pas toujours le cas et peut engendrer une certaine frustration quand aucune solution n’est trouvée.

Néanmoins, je souhaitais partager avec vous au travers de cet article une approche assez classique dans la résolution de souci liée à des produits IT en général (chose que l’on ne fait pas toujours, moi le premier)

Lire les documentations officielles 😎
Ne pas touchez aux environnements de productions
Mettez à jour les OS (Windows 11)
Mettez à jour les applications (Office 365)
Mettez à jour les intermédiaires (FSLogix)
Appliquez les méthodes correctives préconisées par les éditeurs