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 migrationDescription
1. PréparationPré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écouverteCréez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. RéplicationConfigurez l’appliance cible sur Azure Stack HCI et sélectionnez les VMs à répliquer.
4. Migration et vérificationMigrez 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 :

ComposantSystèmes d’exploitation pris en charge
Environnement VMware sourceVMware vCenter Server version 8.0
VMware vCenter Server version 7.0
VMware vCenter Server version 6.7

VMware vCenter Server version 6.5
Appliance VMware Windows Server 2022
Environnement Azure Stack HCI cibleAzure Stack HCI, version 23H2
Appliance Azure Stack HCIWindows 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éographiesRégions
Asie-PacifiqueAsie Sud-Est, Asie Est
EuropeEurope Nord – Europe Ouest
États-UnisUSA Centre, USA Ouest2

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

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Azure 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 :

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.

Promptez votre base de données SQL !

En combinant les capacités de l’IA et des bases de données SQL, vous pouvez optimiser l’utilisation des ressources informatiques et humaines. Les utilisateurs peuvent obtenir des informations pertinentes plus rapidement et plus facilement, améliorant ainsi leur expérience globale. Enfin, l’intégration de l’IA permet d’explorer de nouvelles façons d’utiliser les données pour innover et rester compétitif.

Pourquoi établir une communication DB -> IA ?

Mettre en place une connexion entre une application, une base de données et un modèle d’IA présente plusieurs avantages :

Automatisation et Efficacité

  • Automatisation des tâches répétitives : L’IA peut automatiser des requêtes complexes et des analyses de données, réduisant ainsi le temps et les efforts nécessaires pour obtenir des informations pertinentes.
  • Réponses rapides et précises : En utilisant l’IA pour interroger la base de données, vous pouvez obtenir des réponses rapides et précises à des questions spécifiques sans avoir à écrire des requêtes SQL complexes.

Amélioration de la Prise de Décision

  • Analyses avancées : L’IA peut analyser de grandes quantités de données et identifier des tendances ou des anomalies que les humains pourraient manquer.
  • Prédictions et recommandations : Les modèles d’IA peuvent fournir des prédictions basées sur les données historiques et offrir des recommandations pour des actions futures.

Accessibilité et Utilisabilité

  • Interface utilisateur simplifiée : Les utilisateurs peuvent interagir avec la base de données via des prompts en langage naturel, rendant l’accès aux données plus intuitif et accessible même pour ceux qui ne maîtrisent pas le langage de base de données.
  • Support multilingue : Azure OpenAI peut comprendre et répondre dans plusieurs langues, ce qui est utile pour les entreprises internationales.

Sécurité et Conformité

  • Contrôle d’accès : Vous pouvez définir des niveaux d’accès pour différents utilisateurs, garantissant que seules les personnes autorisées peuvent interroger certaines parties de la base de données.
  • Surveillance et audit : Les interactions avec la base de données peuvent être surveillées et auditées pour assurer la conformité avec les régulations et les politiques internes.

Flexibilité et Évolutivité

  • Scalabilité : Azure offre des solutions évolutives qui peuvent gérer des volumes de données croissants sans compromettre les performances.
  • Intégration facile : Les services Azure sont conçus pour s’intégrer facilement avec d’autres outils et plateformes, facilitant ainsi l’expansion et l’adaptation aux besoins changeants de l’entreprise.

Mais comment y parvenir ?

Bien que la mise en place de cette interface puisse sembler complexe, elle est tout à fait réalisable avec une planification adéquate et les bonnes compétences.

Si vous avez une équipe technique compétente ou si vous pouvez faire appel à des experts, cela facilitera grandement le processus.

Configuration de la Base de Données

  • Création et gestion de la base de données : Assurez-vous que votre base de données est bien structurée et optimisée pour les requêtes que vous souhaitez exécuter.
  • Sécurité et accès : Configurez les permissions et les accès pour garantir la sécurité des données.

Intégration de l’Application

  • Développement de l’application : Utilisez un langage de programmation compatible (comme Python, C#, etc.) pour développer l’application qui interagira avec la base de données et l’IA.
  • API et connecteurs : Utilisez des API et des connecteurs pour permettre à l’application de communiquer avec la base de données SQL et les services Azure.

Configuration du Modèle d’IA

  • Choix du modèle : Sélectionnez le modèle d’IA approprié sur Azure OpenAI en fonction de vos besoins (par exemple, GPT-4).
  • Entraînement et ajustement : Si nécessaire, entraînez le modèle avec des données spécifiques à votre domaine pour améliorer sa précision.

Développement de l’Interface Utilisateur

  • Interface utilisateur : Créez une interface utilisateur intuitive qui permet aux utilisateurs de saisir des prompts en langage naturel.
  • Traitement des requêtes : Développez des mécanismes pour convertir les prompts en requêtes SQL et pour afficher les résultats de manière compréhensible.

Considérations Techniques

  • Compétences requises : Vous aurez besoin de compétences en développement logiciel, en gestion de bases de données et en IA.
  • Ressources : Assurez-vous d’avoir les ressources nécessaires, y compris le temps, le budget et l’infrastructure.
  • Maintenance : Préparez-vous à effectuer une maintenance régulière pour assurer la sécurité et la performance de l’application.

Outils et Services Utiles disponibles sur Azure

  • Azure SQL Database : Pour la gestion de la base de données.
  • Azure OpenAI Service : Pour l’intégration du modèle d’IA.

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

Etape 0 – Rappel des prérequis :

Afin de tester la mise en place d’une application entre Azure OpenIA et une base de données Azure SQL, nous allons avoir besoin de :

Etape I – Préparation du poste local :

Installez Visual Studio Code ou un éditeur de code similaire :

Téléchargez puis installez la version 6.0 de .NET, disponible via ce lien officiel :

Téléchargez et installez SQL Server Management Studio (SSMS) depuis cette page :

Afin de publier les 2 applications sur une URL publique, téléchargez ngrok, puis inscrivez-vous chez eux avec un compte gratuit :

Sur leur site, téléchargez l’installateur de ngrok :

Copiez la commande suivante affichée sous l’installateur pour configurer votre ngrok :

Depuis le dossier de téléchargement, ouvrez une invite de commande, puis lancez celle-ci afin de préparer votre configuration ngrok :

Le poste local est maintenant correctement configuré, la prochaine étape consiste à créer une base de données SQL avec de la données fictives sur notre souscription Azure.

Etape II – Création de la base de données Azure SQL :

Pour cela, rendez-vous sur la page du portail Azure afin de rechercher le service Azure SQL Database :

Cliquez-ici pour créer votre base de données SQL :

Nommez votre base de données Azure SQL, puis cliquez-ici pour créer une serveur de base de données Azure pour héberger notre base :

Nommez votre serveur Azure SQL, choisissez sa région, puis renseignez des identifiants SQL pour simplifier notre test :

Conservez votre environnement en Développement, réduisez la redondance de votre base de données SQL, puis cliquez sur Suivant :

Conservez les caractéristiques réseaux d’origine, puis cliquez sur Suivant :

Conservez les caractéristiques de sécurités d’origine, puis cliquez sur Suivant :

Ne configurez pas de source de données particulière, puis lancez la validation Azure :

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

Attendez environ 5 minutes, puis cliquez-ici pour accéder à votre base de données Azure SQL :

Copiez les informations de connexion à votre base de données SQL, celles-ci seront nécessaire par la suite :

Retournez sur la page principale de votre base de données SQL, puis cliquez sur votre serveur Azure SQL :

Dans la section réseau, activez l’option suivante, puis rajoutez votre adresse IP publique en exception Firewall afin de pouvoir connecter votre poste à la base de données SQL, puis cliquez sur Sauvegarder :

Rendez-vous sur la page GitHub suivante afin de récupérer le script de chargement d’une base de données SQL (Northwind) en exemple, puis cliquez-ici :

Téléchargez le script de chargement en cliquant sur le bouton suivant :

Une fois le script téléchargé, ouvrez SQL Server Management Studio sur votre poste :

Renseignez les informations reprises sur votre serveur Azure SQL créé précédemment, puis cliquez sur Connecter :

Cliquez-ici pour rechercher votre script SQL téléchargé précédemment :

Choisissez le script SQL, puis cliquez sur Ouvrir :

Une fois le script affiché dans une nouvelle fenêtre, cliquez sur Exécuter pour démarrer ce dernier :

Attendez environ 30 secondes que celui-ci se termine avec le message suivant :

Contrôlez dans la base de données Azure SQL créés en premier que les différentes tables sont présentes et que des données y sont stockées :

Nos données sont maintenant stockées dans notre base Azure SQL. Nous pouvoir maintenant mettre en place notre LLM grâce au service Azure OpenAI.

Etape III – Création du modèle Azure OpenAI :

Pour cela, retournez sur la page du portail Azure afin de rechercher le service Azure OpenAI :

Cliquez-ici pour créer votre service Azure Open AI ;

Renseignez les informations de base de ce dernier, puis cliquez sur Suivant :

Conservez les caractéristiques réseaux d’origine, puis cliquez sur Suivant :

Ajoutez au besoin des étiquettes, puis cliquez sur Suivant :

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

Attendez environ 1 minutes puis cliquez-ici pour accéder à votre service Azure OpenAI :

Copiez les 2 informations suivantes pour ouvrir un accès auprès de votre service Azure OpenAI :

Cliquez-ici pour ouvrir le portail Azure OpenAI Studio :

Cliquez-ici pour déployer un nouveau model :

Choisissez le type gpt-4, puis cliquez sur Confirmer :

Nommez votre déploiement, définissez une limite de tokens par minute qui convient, puis cliquez sur Déployer :

Attendez environ 1 minute le temps de déploiement de votre modèle :

L’infrastructure sur Azure est maintenant en place. Il nous nous reste qu’à configurer les applications web sur notre poste afin que celle-ci travaille avec le schéma de votre base de données et votre modèle AI.

Commençons par la version 1 proposée par Alex Wolf.

Etape IV – Configuration de l’application v1 :

Voici un lien vers son excellente vidéo présentant l’application v1, sa configuration, son code ainsi qu’une comparaison intéressante faite avec les services Search basés sur l’IA :

Rendez-vous sur un fork de la page GitHub d’Alex Wolf afin de télécharger l’application v1 sous format ZIP :

Un fois l’archive ZIP téléchargée, décompressez celle-ci dans le dossier local de votre choix :

Ouvrez votre éditeur de code local, puis cliquez-ici pour ouvrir le dossier de l’application v1 :

Ouvrez le dossier correspondant au dossier suivant :

Dans le dossier SchemaLoader\SchemaLoader ouvrez le fichier Program.cs, puis renseignez la connexion à votre base de données Azure SQL copiée précédemment :

N’oubliez pas de de modifier le mot de passe de votre compte SQL, puis sauvegardez :

Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier suivant, puis saisissez la commande ci-dessous :

dotnet build ".\SchemaLoader.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande ci-dessous :

dotnet run

Une fois l’application démarrée, copiez le texte généré par celle-ci et contenant le schéma de votre base de données Azure SQL :

Retournez sur votre éditeur de code, puis allez dans le dossier dbchatui, ouvrez le fichier DataService.cs, renseignez à nouveau la connexion à votre base de données Azure SQL, puis sauvegardez le fichier :

Allez dans le dossier dbchatui\Pages, ouvrez le fichier Index.cshtml.cs, copiez le schéma de votre base de données Azure SQL :

Cela donne la présentation suivante :

Toujours dans le fichier Index.cshtml.cs, renseignez les 3 informations suivantes pour connecter votre application à votre modèle Azure OpenAI, puis sauvegardez :

Rouvrez la fenêtre Windows Terminal, positionnez-vous dans le dossier suivant, puis saisissez la commande ci-dessous :

dotnet build ".\YourOwnData.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande ci-dessous :

dotnet run

Votre application v1 est maintenant démarrée. Copiez le numéro du port local ouvert pour cette application :

Ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :

Copiez l’URL publique générée par ngrok ci-dessous :

Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement de l’application v1. Ouvrez un navigateur web, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :

Commencez par tester une requête SQL simple en promptant une question basique :

L’application vous retourne d’abord sa compréhension de votre demande, et la transpose en une requête SQL correspondante :

Juste en dessous est affiché les enregistrement correspondants au résultat de la requête exécutée sur votre serveur de base de données Azure SQL :

Continuez en testant des prompts incluant des filtres, des classements, … :

Continuez en testant des prompts incluant des relations de tables et des filtres basés sur un raisonnement :

Tous ces prompts nous montrent l’immense potentiel de pouvoir prompter une IA qui a une connaissance du schéma de toute la base de données source, sans pour autant avoir la données en elles-mêmes.

Etape V – Configuration de l’application v2 :

Il existe une nouvelle application toujours développée par Alex Wolf dont la vidéo est juste là :

Le principe est le même, rendez-vous sur un fork de la page GitHub d’Alex Wolf afin de télécharger l’application v2 sous format ZIP :

Un fois l’archive ZIP téléchargée, décompressez celle-ci dans le dossier local de votre choix :

Ouvrez votre éditeur de code local, cliquez-ici pour ouvrir le dossier de l’application v2, renseignez les 3 informations suivantes pour connecter votre application à votre modèle Azure OpenAI, puis sauvegardez :

Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier suivant, puis saisissez la commande ci-dessous :

dotnet build ".\DBChatPro.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande ci-dessous :

dotnet run

Votre application v2 est maintenant démarrée. Copiez le numéro du port local ouvert pour cette application :

Ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :

Copiez l’URL publique générée par ngrok ci-dessous :

Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement de l’application v1. Ouvrez un navigateur web, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :

Renseignez la connexion à votre base de données Azure SQL copiée précédemment, puis cliquez-ici pour le schéma :

Cliquez sur Sauvegarder :

La connexion apparaît alors dans la liste des connexions existantes :

Retournez sur le premier onglet, puis commencez par tester une requête SQL simple en promptant une question basique :

L’application v2 vous retourne les enregistrement correspondants au résultat de la requête exécutée sur votre serveur de base de données Azure SQL :

Le second onglet affiche une requête SQL correspondante :

Le troisième onglet vous retourne la compréhension de votre demande comprise par le modèle IA :

Un historique des précédentes prompts est également disponible :

Il également possible de mettre des prompts en favoris :

Conclusion

En conclusion, l’utilisation de prompts pour interagir avec les bases de données représente une avancée importante, simplifiant l’accès aux informations et permettant une utilisation plus intuitive de SQL.

En expérimentant avec cette méthode, les utilisateurs peuvent améliorer leur efficacité et mieux exploiter leurs données.

Avec l’évolution rapide de ces technologies, maîtriser le langage des prompts pourrait devenir une compétence clé pour les professionnels de la donnée, ouvrant la voie à de nouvelles façons de gérer et analyser des volumes d’informations toujours croissants.

Orchestrez votre AVD

Avec la toute nouvelle fonctionnalité appelée Session host update d’Azure Virtual Desktop, Microsoft vient de lâcher une petite bombe dans la gestion des VMs AVD. Imaginez Azure Virtual Desktop remplaçant comme un grand des VMs obsolètes pour les remplacer par d’autres basées sur votre toute dernière image ? Vous ne rêvez pas, tout cela est maintenant disponible en préversion !

Comment faisait-on avant pour mettre à jour son AVD ?

Avant l’introduction de cette nouvelle fonctionnalité, la mise à jour des hôtes de session Azure Virtual Desktop (AVD) nécessitait une gestion manuelle plus intensive. Ce processus impliquait souvent plusieurs étapes, telles que :

  1. Planification des mises à jour : Identifier les hôtes de session nécessitant des mises à jour et planifier les fenêtres de maintenance.
  2. Exécution des mises à jour : Utiliser des scripts ou des outils pour appliquer les mises à jour sur chaque hôte de session.
  3. Vérification et validation : S’assurer que les mises à jour ont été appliquées correctement et que les hôtes de session fonctionnent comme prévu.

Ces étapes pouvaient être chronophages et nécessitaient une surveillance constante pour minimiser les interruptions de service et garantir la conformité des systèmes.

Qu’est ce que les nouvelles Mises à jour AVD ?

La nouvelle fonctionnalité simplifie ce processus en automatisant la gestion des mises à jour, réduisant ainsi la charge administrative et améliorant l’efficacité opérationnelle.

Microsoft nous décrit cette toute nouvelle fonctionnalité AVD en seulement quelques phrases :

La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session.

La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour.

Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.

Microsoft Learn

Que peut-on modifier dans une mise à jour AVD ?

Beaucoup de paramètres sont déjà modifiables d’une version à l’autre de votre environnement AVD :

  • Image de machine virtuelle
  • Taille de la machine virtuelle
  • Type de disque de machine virtuelle
  • Type de sécurité de la machine virtuelle
  • Informations d’identification de jonction de domaine Active Directory
  • Inscription à Microsoft Intune
  • Informations d’identification de l’administrateur local
  • Script PowerShell de configuration personnalisé

Quid des machines virtuelles AVD éteintes ou avec le mode de drainage ?

L’état d’alimentation et le mode de drainage existants des hôtes de session sont respectés. Vous pouvez effectuer une mise à jour sur un pool d’hôtes où tous les hôtes de session sont désalloués pour réduire les coûts.

Existe-t-il des limitations ?

Encore en préversion Microsoft nous liste les principales limitations juste ici :

  • La mise à jour de l’hôte de session est uniquement disponible dans le cloud Azure global. Il n’est pas disponible dans d’autres clouds, tels qu’Azure US Government ou Azure exploité par 21Vianet.
  • Pour les hôtes de session créés à partir d’une image partagée Azure Compute Gallery disposant d’un plan d’achat, le plan n’est pas conservé lorsque les hôtes de session sont mis à jour. Pour vérifier si l’image que vous utilisez pour vos hôtes de session dispose d’un plan d’achat, vous pouvez utiliser Azure PowerShell ou Azure CLI.
  • La taille du disque du système d’exploitation ne peut pas être modifiée pendant une mise à jour. Le service de mise à jour utilise par défaut la même taille que celle définie par l’image de la galerie.
  • Lors d’une mise à jour, vous ne pouvez pas ajouter d’autres hôtes de session au pool d’hôtes.
  • Si une mise à jour échoue, le pool d’hôtes ne peut pas être supprimé tant que la mise à jour n’est pas annulée.
  • Si vous décidez de créer une image extraite d’un hôte de session existant que vous utilisez ensuite comme image source pour la mise à jour de votre hôte de session, vous devez supprimer le dossier C:\packages\plugin avant de créer l’image. Dans le cas contraire, ce dossier empêche l’exécution de l’extension DSC qui joint les machines virtuelles mises à jour au pool d’hôtes.
  • Si vous utilisez Azure Virtual Desktop Insights, l’agent Azure Monitor ou l’agent Log Analytics n’est pas automatiquement installé sur les hôtes de session mis à jour. Pour installer l’agent automatiquement, voici quelques options :
  • Évitez de modifier une configuration d’hôte de session dans un pool d’hôtes sans hôtes de session en même temps qu’un hôte de session est créé, car cela peut entraîner un pool d’hôtes avec des propriétés d’hôte de session incohérentes.

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

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour de l’hôte de session pour Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’effectuer une demande à Microsoft via le formulaire suivant, dont le point le plus important à retenir est :

Please note, the session hosts and host pools in this preview cannot be used for any type of production workload.

Autrement dit : pas de tests sur un environnement de production 😎

Etape I – Préparation du domaine AD :

Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :

Nommez celui-ci, puis cliquez sur Suivant :

Considérer au besoin les différents services de sécurité, puis cliquez sur Suivant :

Validez le plan d’adressage réseau et sous-réseau, puis lancez la validation Azure :

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

Une fois le réseau virtuel déployé, recherchez le service Microsoft Entra Domain Services depuis la barre de recherche Azure :

Cliquez-ici pour créer ce service d’AD managé sur votre tenant :

Renseignez ses informations de base dont son nom et le SKU de type Standard, puis cliquez sur Suivant :

Validez les propriétés réseaux, puis cliquez sur Suivant :

Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :

Définissez le périmètre de synchronisation, puis cliquez sur Suivant :

Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :

Cliquez sur Créer pour lancez sa création :

Lisez l’avertissement sur le blocage de modifications après sa création, puis cliquez sur OK :

Attendez environ 30 minutes la première phase de déploiement des ressources Azure :

Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :

Comme vous le constatez, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :

Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée. Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :

Lancez-le diagnostique en cliquant sur Lancer :

Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :

Confirmez votre choix en cliquant à nouveau sur Réparer :

Vérifiez la disparition de la notification d’alerte sur votre domaine managé :

Retournez sur le réseau virtuel afin de vérifiez les adresses IP de votre service Entra Domain Services :

Le domaine AD managé est maintenant en place.

La nouvelle méthode de déploiement AVD exige le stockage des informations d’identification dans un Azure Key Vault. Avant de déployer notre environnement AVD de test, nous aurons donc besoin d’un coffre.

Etape II – Création du coffre Azure Key Vault :

Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Renseignez les informations de base, puis cliquez sur Suivant :

Activez les 2 options suivantes, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre coffre :

Attendez environ 2 minutes, puis cliquez-ici une fois le déploiement terminé :

Ajoutez les rôles RBAC suivants afin de pouvoir accéder à votre coffre ainsi qu’au service Azure Virtual Desktop via son application 9cdead84-a844-4324-93f2-b2e6bb768d07 :

Ajoutez également le rôle RBAC suivant pour l’application Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07) afin que cette dernière puisse créer et supprimer de nouvelles machines virtuelles :

Retournez dans votre coffre, puis cliquez sur le bouton suivant pour créer les différents secrets :

Créez les 4 secrets suivants un par un :

  • Compte de domaine (sous la forme admindomain@jlou.local)
  • Mot de passe du compte de domaine
  • Compte admin local VM
  • Mot de passe du compte admin local VM

Cela donne alors la liste de secrets suivante :

Tous les prérequis au déploiement sont maintenant en place. Nous allons pouvoir déployer un nouveau type d’AVD ayant un management automatisé.

Etape III – Déploiement de l’environnement AVD :

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

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

Choisissez un pool d’hôtes de type partagé ainsi que le management automatisé, puis cliquez sur Suivant :

Définissez le nombre de machines virtuelles créées ainsi que la région Azure :

Choisissez l’image OS et les caractéristiques techniques de vos machines virtuelles AVD :

Spécifiez le réseau virtuel adéquat :

Reprenez les informations du Key Vault contenant les informations d’identification du compte de domaine :

Reprenez les informations du Key Vault contenant les informations d’identification du compte administrateur local, puis cliquez sur Suivant :

Définissez un nouvel espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer l’assignation des utilisateurs :

Assignez les utilisateurs de test AVD à votre groupe d’application créé :

Vérifiez le bon statut de disponibilité de vos hôtes de session créées :

Afin de s’assurer du bon fonctionnement de notre environnement AVD, connectez-vous à l’URL web d’Azure Virtual Desktop, authentifiez-vous avec un utilisateur de test, puis ouvrez une session AVD :

Cliquez sur Autoriser :

Renseignez les informations de compte de votre utilisateur AVD :

Vérifiez la bonne ouverture de session Windows :

Constatez la présence d’une session AVD ouverte sur une des VM présentes à votre pool d’hôtes :

L’environnement Azure Virtual Desktop est maintenant fonctionnel. La prochaine étape consiste à créer une mise à jour de l’image et donc de déclencher le processus de création de VM et le suppression des anciennes.

Etape IV – Déploiement d’une mise à jour AVD :

Tout commence par la création d’une nouvelle mise à jour AVD, pour cela cliquez-ici :

Définissez ici les options d’Azure Virtual Desktop sur les machines virtuelles :

  • La case à cocher détermine si AVD doit supprimer les anciennes machines virtuelles une fois ces dernières correctement substituées par de nouvelles.
  • Le pas de travail par AVD sur les machines virtuelles. Dans mon exemple :
    • AVD commencera par tester la mise à jour sur 1 seule machine virtuelle.
    • Si la mise à jour a fonctionné, AVD continuera par mettre à jour 2 VMs.
    • AVD terminera par mettre à jour les 2 dernière VMs

Définissez vos paramètres, puis cliquez sur Suivant :

Apportez les modifications de taille, d’image ou d’autres paramètres sur votre template AVD, puis cliquez sur Suivant :

Planifiez la mise à jour AVD immédiatement ou programmée par la suite, puis cliquez sur Suivant :

Personnalisez au besoin le message d’information reçu par les utilisateurs encore connectés, puis lancez la validation Azure :

Une fois la validation Azure réussie, retrouvez en gras les modifications apportées, puis lancez la mise à jour AVD :

Une fois la mise à jour enclenchée, l’écran des machines virtuelles AVD vous affiche 2 informations sur le traitement en-cours :

  • Le processus de mise à jour vient de démarrer, aucune VM n’a encore été remplacée, le pourcentage de progression est donc de 0.00 %.
  • La version actuellement en place sur les machine virtuelle AVD n’est plus la plus récente.

Après un rafraîchissement de la page, Azure Virtual Desktop commence sa mise à jour sur une première machine virtuelle AVD. Cela est visible par l’activation du mode de drainage sur une seule VM :

A ce même moment, une nouvelle machine virtuelle, dont la racine du nom reprend celle qui sera remplacée, fait son apparition et est en cours de création :

Une fois la nouvelle machine virtuelle créée, AVD nous informe que la VM déjà en place est en cours d’arrêt:

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute la nouvelle machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :

La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :

L’ancienne machine virtuelle est alors supprimée, comme demandé dans la configuration de la mise à jour AVD :

Le pourcentage de progression passe alors à 20.00 %, en adéquation avec le fait qu’1 machine virtuelle sur 5 est correctement mise à jour. AVD continue le traitement activant le mode de drainage sur 2 machines virtuelles :

A ce même moment, 2 nouvelles machine virtuelles, dont la racine du nom reprend celles qui seront remplacées, font leur apparition en cours de création :

Une fois les nouvelles machines virtuelles créés, AVD nous informe que les 2 VMs déjà en place sont en cours d’arrêt :

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retirent les 2 anciennes machines virtuelles du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute les 2 nouvelles machines virtuelles au pool d’hôtes AVD et au domaine Active Directory :

Le pourcentage de progression passe alors à 60.00 %, en adéquation avec le fait que 3 machine virtuelle sur 5 sont correctement mises à jour. AVD continue le traitement activant le mode de drainage sur les 2 dernières machines virtuelles :

A ce même moment, 2 nouvelles VMs sont créées, l’ancienne VM sans session utilisateur est en cours d’arrêt, tandis que celle contenant une session utilisateur reste encore active :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle sans session du pool d’hôtes AVD, tandis que celle contenant une session utilisateur reste encore présente :

Un message d’information apparaît dans la session encore ouverte de l’utilisateur AVD :

Quelques minutes plus tard, la session AVD est terminée sans action de l’utilisateur :

Le pourcentage de progression passe alors à 80.00 %, en adéquation avec le fait qu’une seule machine virtuelle sur cinq n’est pas encore mise à jour :

Azure Virtual Desktop force la déconnexion afin de déclencher l’arrêt de la machine virtuelle AVD :

Après cela, Azure Virtual Desktop retire la dernière machine virtuelle du pool d’hôtes AVD :

Juste après, Azure Virtual Desktop ajoute la dernière machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Toutes les anciennes machines virtuelles AVD ont bien été supprimées :

La mise à jour est maintenant terminée car toutes les machines virtuelles ont maintenant et correctement été mise à jour :

L’utilisateur déconnecté peut alors tenter une reconnexion à AVD :

L’utilisateur constate alors le passage à une nouvelle version de son OS :

AVD ouvre la nouvelle session Windows sur 1 des 5 machines virtuelles du pool d’hôtes :

Conclusion

Cette fonctionnalité vous permet de maximiser l’efficacité et la flexibilité de votre infrastructure virtuelle. Grâce à des outils avancés et des stratégies éprouvées, vous pouvez améliorer la gestion de vos ressources, réduire les coûts opérationnels et offrir une expérience utilisateur optimisée. Découvrez par vous-même comment l’orchestration de votre AVD peut transformer votre environnement de travail virtuel.

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 :

  1. 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.
  2. 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.
  3. 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éristiqueH.264 (AVC)H.265 (HEVC)
Efficacité de compressionUtilise des macroblocs (16×16 pixels)Utilise des unités de codage (CTU) jusqu’à 64×64 pixels
Taille des fichiersPlus volumineuxRéduit la taille des fichiers jusqu’à 50%
CompatibilitéLargement pris en charge par de nombreux appareils et plateformesMoins largement pris en charge, mais le support est en croissance
Puissance de traitementNécessite moins de puissance de calcul pour le codage et le décodageNécessite plus de puissance de calcul pour le codage et le décodage
Cas d’utilisationStreaming, disques Blu-ray, diffusions HDTVVidéos haute résolution (4K, 8K), scénarios avec bande passante et stockage limités
Qualité vidéoBonne qualité vidéoMeilleure qualité vidéo au même débit binaire
Bande passanteNécessite plus de bande passanteNécessite moins de bande passante
AdoptionUniversellement 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 AzureAccélération GPU pour le rendu d’applicationAccélération GPU pour le codage d’imagesEncodage vidéo plein écran
Série NVv3Pris en chargeAVC/H.264HEVC/H.265
AVC/H.264
Série NVv4Pris en chargeNon disponiblePris en charge
NVadsA10 v5-seriesPris en chargeAVC/H.264HEVC/H.265
AVC/H.264
NCasT4_v3-seriesPris en chargeAVC/H.264HEVC/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 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 😎💪

💪Bastion Premium 💪

Comme tous les services Cloud, Azure Bastion continue d’évoluer et s’améliorer via l’ajout de nouvelles fonctionnalités très pratiques. Au travers de cet article, nous prendrons le temps de refaire un tour du service et de ses changements dans sa gamme et ses fonctionnalités, comme l’enregistrement automatique ou l’accès 100% privé.

Cet article n’est pas le premier à parler d’Azure Bastion sur ce blog, voici un lien vers celui écrit en 2023. Depuis cette date, le produit a subi quelques changements que nous aborderons ici.

Qu’est-ce qu’Azure Bastion ?

Côté Microsoft, le but de ce service de jump n’est pas changé :

Azure Bastion est un service PaaS entièrement managé que vous approvisionnez pour vous connecter en toute sécurité aux machines virtuelles via une adresse IP privée. Il fournit une connectivité RDP/SSH sécurisée et fluide à vos machines virtuelles, directement au travers du protocole TLS depuis le Portail Azure ou via un SSH natif ou un client RDP déjà installé sur votre ordinateur local. Quand vous vous connectez via Azure Bastion, vos machines virtuelles n’ont pas besoin d’adresse IP publique, d’agent ou de logiciel client spécial.

Microsoft Learn

Azure Bastion est donc toujours un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient sous Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

Bastion fournit une connectivité RDP et SSH sécurisée à toutes les machines virtuelles du réseau virtuel pour lequel il est approvisionné. Azure Bastion protège vos machines virtuelles contre l’exposition des ports RDP/SSH au monde extérieur, tout en fournissant un accès sécurisé à l’aide de RDP/SSH.

Microsoft Learn

J’ai également reposté la vidéo dédiée à Azure Bastion en français juste ici :

Quel est le principal point fort d’Azure Bastion ?

Un seul mot me vient tout de suite en tête : SECURITE.

Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.

De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.

Pour y voir plus clair, Microsoft met à disposition un tableau de ses principaux avantages :

AvantageDescription
RDP et SSH par le biais du portail AzureVous pouvez accéder directement à la session RDP et SSH directement dans le portail Azure via une expérience fluide en un seul clic.
Session à distance sur TLS et traversée de pare-feu pour RDP/SSHAzure Bastion utilise un client web basé sur HTML5 qui est automatiquement diffusé sur votre appareil local. Votre session RDP/SSH utilise TLS sur le port 443. Le trafic peut ainsi traverser les pare-feu de façon plus sécurisée. Bastion prend en charge TLS 1.2. Les versions antérieures de TLS ne sont pas prises en charge.
Aucune adresse IP publique n’est nécessaire sur la machine virtuelle Azure.Azure Bastion ouvre la connexion RDP/SSH à votre machine virtuelle Azure en utilisant l’adresse IP privée sur votre machine virtuelle. Vous n’avez pas besoin d’une adresse IP publique sur votre machine virtuelle.
Aucune contrainte liée à la gestion des groupes de sécurité réseau (NSG)Vous n’avez pas besoin d’appliquer des groupes de sécurité réseau sur le sous-réseau Azure Bastion. Comme Azure Bastion se connecte à vos machines virtuelles par le biais d’une adresse IP privée, vous pouvez configurer vos groupes de sécurité réseau pour autoriser RDP/SSH depuis Azure Bastion uniquement. Vous n’avez plus à gérer les groupes de sécurité réseau chaque fois que vous devez vous connecter de manière sécurisée à vos machines virtuelles. Pour plus d’informations sur les groupes de sécurité réseau, consultez Groupes de sécurité réseau.
Vous n’avez pas besoin de gérer un hôte Bastion distinct sur une machine virtuelleAzure Bastion est un service PaaS de plateforme entièrement géré d’Azure, renforcé en interne pour vous fournir une connectivité RDP/SSH sécurisée.
Protection contre l’analyse des portsVos machines virtuelles sont protégées contre l’analyse des ports par des utilisateurs malveillants, car vous n’avez pas besoin de les exposer à Internet.
Renforcement de la sécurité à un seul endroitAzure Bastion résidant au périmètre de votre réseau virtuel, vous n’avez pas à vous soucier du durcissement de la sécurité de chacune des machines virtuelles de votre réseau virtuel.
Protection contre les exploits zéro-dayLa plateforme Azure protège contre les exploits du jour zéro en assurant une sécurité durcie permanente et à jour pour Azure Bastion.

Mais combien coûte Azure Bastion ?

C’est à partir d’ici que les choses ont changé depuis mon dernier article. Il existe maintenant 4 SKUs disponibles pour Azure Bastion :

  • Développeur
  • Basic
  • Standard
  • Premium

Côté tarif, Microsoft met à disposition une table des tarif d’Azure Bastion sur cette page :

Pour bien se rendre compte des écarts de prix, cela donne les tarifs mensuels suivants :

Comme indiqué au-dessus, Azure Bastion en version Développeur est gratuit, mais votre accès unique repose alors sur une instance partagée d’Azure Bastion :

Pour les autres SKUs, Microsoft le dit et je vous le confirme : Azure Bastion est facturé dès que ce dernier est déployé peu importe son utilisation :

Azure Bastion est facturée toutes les heures à partir du moment où la ressource est déployée jusqu’à sa suppression, quelle que soit l’utilisation des données sortantes. La tarification horaire est basée sur la référence SKU sélectionnée, le nombre d’unités d’échelle configurées et les taux de transfert de données.

Tarification Microsoft

Quel SKU choisir pour Azure Bastion ?

Les fonctionnalités détermineront le SKU le plus adapté à votre besoin :

FonctionnalitéRéférence SKU DéveloppeurRéférence De baseRéférence StandardSKU Premium
Se connecter pour cibler les machines virtuelles dans les mêmes réseaux virtuelsOuiOuiOuiOui
Se connecter pour cibler les machines virtuelles dans les réseaux virtuels appairésNonOuiOuiOui
Prise en charge de connexions simultanéesNonOuiOuiOui
Accéder aux clés privées des machines virtuelles Linux dans Azure Key Vault (AKV)NonOuiOuiOui
Se connecter à une machine virtuelle Linux avec SSHOuiOuiOuiOui
Se connecter à une machine virtuelle Windows avec RDPOuiOuiOuiOui
Se connecter à une machine virtuelle Linux avec RDPNoNonOuiOui
Se connecter à une machine virtuelle Windows avec SSHNoNonOuiOui
Spécifier le port d’entrée personnaliséNoNonOuiOui
Se connecter à des machines virtuelles à l’aide de Azure CLINoNonOuiOui
Mise à l’échelle de l’hôteNoNonOuiOui
Charger ou télécharger des fichiersNoNonOuiOui
Authentification KerberosNonOuiOuiOui
Lien partageableNoNonOuiOui
Se connecter aux machines virtuelles via une adresse IPNoNonOuiOui

Note : Gardez en tête que pour vous pouvez monter en gamme le SKU de votre Azure Bastion, mais descendre vous sera impossible.

Comment mettre en place Azure Bastion ?

Rien de plus simple, quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités des 4 SKUs d’Azure Bastion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis :

Pour réaliser ce nouvel exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Mon environnement Azure de départ contient déjà 3 machines virtuelles :

Ces 3 machines virtuelles sont réparties sur 2 réseaux virtuels déployés dans 2 régions Azure :

Un appairage entre ces 2 réseaux virtuels est déjà en place :

Pour information, un déploiement rapide d’Azure Bastion est possible depuis une machine virtuelle :

Une autre méthode de déploiement rapide d’Azure Bastion est également disponible depuis un réseau virtuel :

Dans notre cas, nous allons personnaliser le déploiement d’Azure Bastion afin de pouvoir sélectionner le SKU Développeur.

Etape I – Déploiement d’Azure Bastion Développeur :

Comme indiqué en introduction, ce SKU gratuit fonctionne via une ressource Azure Bastion partagée et sécurisée :

L’intérêt principal d’utiliser ce SKU d’Azure Bastion est évidemment son prix, si aucune de ses limitations n’est bloquante pour vous :

  • Connexion impossible sur les réseaux virtuels appairée
  • Connexions simultanées impossibles
  • Authentification Kerberos impossible

Si cela vous convient, recherchez le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs suivants :

Sélectionnez le SKU Développeur :

Constatez la liste réduite des régions Azure disponibles pour ce SKU :

Choisissez votre réseau virtuel déjà en place, puis cliquez sur Suivant :

Constatez que toutes les fonctionnalités annexes sont indisponibles avec ce SKU, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre Azure Bastion :

Attendez environ 1 minute pour que le service soit accessible sur votre environnement :

Sur une machine virtuelle présente sur le même réseau virtuel qu’Azure Bastion, connectez-vous à celle-ci :

La session de bureau à distance Windows s’ouvre bien via le protocole RDP :

Constatez l’URL spécifique de cette session Bastion pointant sur une ressource CDN :

Tentez d’utiliser votre Azure Bastion Développeur sur une autre machine virtuelle présente sur un réseau virtuel appairé au premier, sans succès :

L’instance d’Azure Bastion Développeur déjà en place n’est pas reconnue.

Sur ce SKU, il est malgré tout possible de restreindre les sources des sessions Bastion :

Bien que son prix soit gratuit, Azure Bastion en version Développeur limite certains besoins. Pour la suite, nous allons donc le migrer vers une gamme supérieure.

Etape II – Déploiement d’Azure Bastion Basic :

A partir de ce niveau de SKU, l’instance Azure Bastion n’est plus partagée mais dédiée à votre infrastructure. Cette intégration s’accompagne d’un sous-réseau dédié aux instances Azure Bastion :

Comparé à Bastion en version Développeur, l’intérêt d’utiliser ce SKU d’Azure Bastion repose sur les arguments suivants :

  • Connexion au réseaux virtuels appairés
  • Connexions simultanées
  • Authentification Kerberos
  • Intégration du coffre Azure Key Vault pour les clefs Linux

Retournez sur l’instance d’Azure Bastion Développeur déjà en place, puis mettez à jour son SKU en cliquant comme ceci :

A ce moment-là, il vous est demandé de mettre en place une adresse IP publique à votre service Bastion, mais aussi de créer un sous-réseau dédié à ce dernier :

Cliquez-ici pour ajouter un nouveau sous-réseau :

Choisissez dans la liste Azure Bastion, modifiez au besoin l’adressage puis cliquez sur Ajouter :

Une fois le sous-réseau ajouté, cliquez sur la croix en haut à droite :

Une seule option est alors dégrisée avec ce SKU, cochez-là si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service soit mis à jour sur votre environnement :

Une fois votre Azure Bastion mis à jour, retournez sur une machine virtuelle Windows d’un réseau virtuel appairé, puis lancez une connexion via Bastion comme ceci :

Un nouvel onglet dans votre navigateur ouvre bien une session RDP de votre machine virtuelle :

Refaite le même test sur une machine virtuelle Linux :

Un nouvel onglet dans votre navigateur ouvre bien une session SSH de votre machine virtuelle :

Constatez le changement dans la nature de l’URL pointant cette fois sur un DNS dédié :

Des informations sur les sessions Bastion actuellement en cours sont également disponibles :

Des métriques sur les ressources de votre Azure Bastion sont également visibles :

Enfin, il est également possible de constater les 2 composants Azure déployée sur ce sous-réseau dédié :

Continuons de mettre à jour notre instance Azure Bastion vers un SKU plus avancé.

Etape III – Déploiement d’Azure Bastion Standard :

Comparé à Azure Bastion de base, l’intérêt ce SKU d’Azure Bastion repose sur les arguments suivants :

  • Connexions via adresse IP
  • Connexions Linux en RDP
  • Connexions Windows en SSH
  • Personnalisation du port d’entrée possible
  • Augmentation du nombre d’instances
  • Génération de lien partageable

De nouvelles options sont dégrisées avec ce SKU, cochez-les si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service soit mis à jour sur votre environnement :

Une fois votre Azure Bastion mis à jour, un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion.

Cliquez-ici pour créer votre premier lien partagé :

Choisissez la machine virtuelle cible, puis cliquer sur Appliquer :

Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :

Ouvrez un navigateur privé, puis collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur, puis cliquez-ici pour ouvrir la session :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance Windows :

Après avoir fermé la session Windows ouverte grâce au lien partagé, pensez à supprimer le lien généré :

Retournez sur la configuration d’Azure Bastion afin de faire varier le nombre d’instances, puis cliquez sur Appliquer :

Chaque instance peut prendre en charge 20 connexions RDP simultanées et 40 connexions SSH simultanées pour les charges de travail moyenne.

Si une instance supplémentaire est déployée, un coût additionnel est ajouté :

Azure Bastion propose de choisir le protocole et le port d’entrée pour les machines virtuelles :

Continuons de mettre à jour notre instance Azure Bastion vers un SKU plus avancé.

Etape IV – Déploiement d’Azure Bastion Premium :

Comparé à Azure Bastion Standard, l’intérêt d’utiliser ce nouveau SKU d’Azure Bastion repose sur les arguments suivants :

  • Enregistrement de session
  • Déploiement privé uniquement

Toutes les options sont alors dégrisées avec ce SKU, cochez-les si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service Bastion soit mis à jour sur votre environnement.

Enregistrement de session

Une fois mis à jour, copiez le nom DNS privé de votre service :

Afin de tester l’enregistrement de session d’Azure Bastion, il est nécessaire de créer un compte de stockage :

Une fois le compte de stockage créé, renseignez l’origine en reprenant le protocole https:// suivi du nom DNS privé de votre Azure Bastion.

Cela donne dans mon cas :

https://bst-9c038b3d-e74c-4838-9613-7a38c0f1fda3.bastion.azure.com

Cliquez ici pour créer un conteneur objet blob dédié :

Dans ce nouveau conteneur, créez une clef SAS avec les propriétés suivantes :

Copiez l’URL de votre nouvelle clef SAS :

Retournez sur votre service Azure Bastion afin de rajouter ce stockage :

Collez votre clef SAS, puis cliquez sur le bouton suivant :

Vérifiez l’absence de message d’erreur ou d’avertissement :

Testez l’enregistrement d’une session SSH en ouvrant une nouvelle connexion via Azure Bastion :

Après avoir terminé des manipulations dans votre session SSH, constatez l’apparition d’un blob sur le conteneur créé :

Constatez également l’apparition d’un enregistrement directement visualisable en cliquant ici :

L’enregistrement s’ouvre dans un nouvel onglet avec une barre de lecture :

Testez un second enregistrement pour une session RDP :

Azure Bastion Privé

Note : La mise en place d’une connexion 100% privée pour Azure Bastion déjà en place n’est pas possible après coup :

Il est donc nécessaire de commencer par supprimer votre Bastion déjà en place :

Une fois votre Bastion supprimé, vous pouvez également supprimer son adresse IP publique :

Le déploiement d’Azure Bastion en version privée se décide via la case à cocher suivante :

Une fois déployé, testez une connexion via cet Azure Bastion privé depuis un poste hors d’atteinte du réseau virtuel cible :

Constatez l’échec de cette tentative :

Afin de tester la connexion privée, j’ai créé un second Azure Bastion Standard sur un autre réseau virtuel appairé :

Puis j’ai activé la fonctionnalité lien partageable sur mon Bastion privé :

J’ai ensuite copié le lien partageable généré :

J’ai testé ce lien partageable privé, sans succès, sur mon poste local :

J’ai retesté avec succès ce même lien partageable privé depuis une session ouverte sur mon second Azure Bastion, dont le réseau virtuel est bien appairé à celui contenant mon Bastion privé :

Via cette méthode, j’ai pu me connecter sans souci à ma machine virtuelle de façon 100% privée :

Conclusion

Sécurité et simplicité sont les adjectifs qui définissent très bien Azure Bastion. Azure Bastion permet d’accéder en toute sécurité aux machines virtuelles via RDP/SSH sans nécessiter d’adresse IP publique, ce qui réduit considérablement les risques d’exposition aux menaces comme l’analyse de ports et les exploits zéro-day.

De plus, il centralise le renforcement de la sécurité en une seule couche, éliminant ainsi la nécessité de sécuriser individuellement chaque machine virtuelle. La flexibilité offerte par les différentes architectures et références SKU permet de s’adapter à divers besoins opérationnels tout en garantissant une connectivité fluide et sécurisée, même dans des configurations réseau complexes comme l’appairage de réseaux virtuels.

Améliorations Teams VDI

Microsoft vient d’annoncer il y a peu la disponibilité générale (GA) d’une nouvelle optimisation pour les communications Teams sur les environnements VDI (Azure Virtual Desktop, Windows 365) baptisée SlimCore. Nous allons voir dans cet article de quoi il en retourne, et comment la mettre en place.

Prenons un peu de temps pour resituer ce changement majeur pour la VDI.

Qu’est-ce que SlimCore ?

SlimCore est un moteur multimédia développé par Microsoft pour remplacer WebRTC (Web Real-Time Communication) dans certaines applications comme Microsoft Teams. Il gère l’audio, la vidéo et le partage d’écran dans le nouveau client Teams pour ordinateur, offrant de meilleures performances, qualité et fiabilité par rapport à WebRTC.

Les principaux avantages de SlimCore sont :

  1. Parité des fonctionnalités et performances : SlimCore permet à Teams sur l’infrastructure de bureau virtuel (VDI) d’avoir des fonctionnalités et des performances similaires à celles du client Teams natif, ce qui facilite l’ajout rapide de nouvelles fonctionnalités et la réduction des écarts présents avec WebRTC.
  2. Amélioration de la qualité des appels : SlimCore optimise les performances audio et vidéo, réduisant les problèmes tels que les interruptions d’appels et la latence.
  3. Mises à jour automatiques : SlimCore est mis à jour automatiquement, garantissant que le moteur multimédia reste compatible avec les dernières fonctionnalités de Teams, sans nécessiter d’intervention manuelle ou de mises à jour d’infrastructure.

SlimCore vs WebRTC ?

SlimCore est plus performant et optimisé pour Microsoft Teams, en particulier dans des environnements VDI, avec des mises à jour transparente et une intégration plus poussée dans l’écosystème Microsoft, tandis WebRTC est une solution plus flexible et ouverte, utilisée dans de nombreuses plateformes, mais avec des performances parfois limitées dans des environnements plus complexes comme le VDI :

CaractéristiqueSlimCoreWebRTC
Origine et usageMoteur multimédia propriétaire développé par Microsoft pour Teams. Utilisé dans le client natif et les environnements VDI.Standard ouvert largement utilisé pour les communications audio, vidéo et partage de données en temps réel via les navigateurs et applications.
Performances et qualitéOptimisé pour une qualité d’appel et de vidéo élevée, même en environnements VDI (réduction de la latence, des déconnexions, meilleure stabilité).Performance variable selon les configurations réseau et navigateur. Moins optimisé pour les environnements complexes comme VDI.
Support des fonctionnalitésPermet à Microsoft de déployer plus rapidement des nouvelles fonctionnalités dans Teams, sans limitation des standards externes.Les fonctionnalités sont limitées par le standard et peuvent évoluer plus lentement.
Mises à jour et compatibilitéMises à jour automatiques et transparentes par Microsoft, sans intervention de l’utilisateur ou de l’administrateur.Dépend des mises à jour des navigateurs et autres implémentations, ce qui peut entraîner des incompatibilités ou des retards.
Flexibilité et adoptionSpécifiquement intégré dans l’écosystème Microsoft, moins flexible en dehors de cet environnement.Très flexible et largement adopté par de nombreuses plateformes, adapté à une grande variété d’applications.
Optimisation pour VDIConçu pour garantir une parité de performances entre le client natif Teams et Teams sur VDI.Moins optimisé pour les environnements VDI, avec des écarts de performance par rapport aux clients natifs.
Déploiement des nouvelles fonctionnalitésFonctionnalités déployées plus rapidement via SlimCore directement dans Teams.Limité par les capacités de WebRTC, les fonctionnalités avancées peuvent prendre plus de temps à arriver.

Est-ce en rapport avec le nouveau Microsoft Teams ?

Cette évolution est en effet dans la suite de la refonte du client Teams de 2023, dont la GA date d’octobre de cette année-là. Voici quelques-unes des principales caractéristiques et avancées :

  • Performance améliorée : L’application est désormais deux fois plus rapide tout en consommant jusqu’à 50 % de ressources en moins.
  • Interface utilisateur simplifiée : Une interface plus soignée et réactive, facilitant la navigation et l’efficacité.
  • Notifications améliorées : Les notifications sont désormais entièrement gérées dans Teams, avec des paramètres plus personnalisables.
  • Comptes multiples : Vous pouvez facilement vous connecter à plusieurs comptes professionnels, scolaires et personnels sans avoir à vous déconnecter et vous reconnecter. Cela simplifie grandement la gestion des différents rôles et responsabilités.

Quels sont les quatre grands piliers de Teams VDI ?

C’est ici qu’intervient le remplacement de WebRTC, une technologie open-source utilisée pour le streaming audio et vidéo dans de nombreuses plateformes de collaboration, au profit de SlimCore, interne à Microsoft.

Microsoft en parle des avantages de ce changement juste ici :

  1. Nouvelles fonctionnalités : SlimCore, un nouveau moteur multimédia, remplace WebRTC dans Teams. Cela permet à Teams sur ordinateur et sur VDI (bureau virtuel) d’avoir les mêmes fonctionnalités. Même si toutes les nouveautés ne sont pas disponibles immédiatement sur VDI, nous ne sommes plus limités par WebRTC, ce qui permet d’ajouter les nouvelles options plus rapidement.
  2. Amélioration des performances : Les performances de Teams sur Windows sont maintenant disponibles pour VDI. Cela permet de rejoindre les réunions plus vite, de réduire les coupures d’appels et d’améliorer le succès lors des partages d’écran et des réunions, avec l’utilisation des codecs les plus récents.
  3. Mises à jour automatiques : Microsoft met à jour SlimCore automatiquement sur l’ordinateur de l’utilisateur. Cela se fait sans interruption et sans redémarrage lorsque Teams sur VDI est mis à jour. Ce système permet d’éviter que des versions récentes de Teams interagissent avec des composants anciens, garantissant une meilleure qualité.
  4. Support simplifié : Les administrateurs n’ont besoin de contacter que Microsoft pour tout problème avec Teams sur VDI, car nous gérons l’ensemble de la solution. Nous avons analysé les délais de résolution passés pour réduire la gravité et la fréquence des incidents, et nous investissons aussi dans des solutions de dépannage et d’auto-assistance avec des guides détaillés.

Quelles sont les fonctionnalités présentes dans cette optimisation ?

Microsoft propose une liste des nouvelles fonctionnalités liées à ce changement juste ici :

FonctionnalitéDisponible
1080pOui
Accélération matérielle sur le point de terminaisonOui
Vue Galerie 3×3 et 7×7Oui
Qualité de serviceOui
Suppression du bruitOui
CACHÉOui
Mode présentateurOui
Teams PremiumOui
(En attente : filigrane, mairies, décorer mon arrière-plan)
Effet d’arrière-plan chargé par l’utilisateurBientôt disponible
Zoom +/-Bientôt disponible

Quelles sont les versions Apps ou OS supportant déjà SlimCore ?

Pour que la bascule vers SlimCore se fasse, nous avons besoin au minimum de :

RequisVersion minimale
Nouveau client Teams24193.1805.3040.8975 (pour AVD/Windows 365)
24165.1410.2974.6689 (pour les VDA à session unique Citrix)
24243.1309.3132.617 (pour les VDA multisession Citrix)
AVD/Windows 365Application Windows : 1.3.252
Client Bureau à distance : 1.2.5405.0
CitrixVDA : application Citrix Workspace 2203 LTSR CU3 ou 2305 CR
: 2203 LTSR, 2402 LTSR ou 2302 CR
Poste localWindows 10 1809 (condition minimale de SlimCore)
Les objets de stratégie de groupe ne doivent pas bloquer les installations MSIX (voir Étape 3 : Préproduction et inscription de SlimCore MSIX sur le point de terminaison)

L’architecture s’en retrouve principalement modifiée côté client via l’ajout d’un nouveau plugin appelé MsTeamsPlugin.dll :

Comment cela se traduit-il au niveau de son installation ?

Microsoft nous explique les choses assez simplement :

Une fois qu’un plugin est « arrivé » chez le client, Teams envoie des instructions sur la version spécifique du moteur média dont il a besoin et le plugin fait le reste : il contacte le CDN public de Microsoft, télécharge un paquet MSIX et l’installe/enregistre automatiquement sur l’appareil de l’utilisateur. Pas de redémarrage ni de privilèges d’administrateur !

Microsoft Tech Community

Par défaut, MsTeamsPlugin télécharge et installe automatiquement la version appropriée du moteur multimédia SlimCore sans intervention de l’utilisateur ou d’un administrateur.

Voici ce que l’on retrouve au niveau local :

Get-AppXPackage *SlimCore*

Important : Microsoft stocke jusqu’à 12 versions de SlimCore VDI à des fins de compatibilité, et dans le cas où l’utilisateur accède à différents environnements VDI (par exemple, persistant, où les nouvelles mises à jour automatiques Teams se mettent à jour automatiquement et non persistants, où les nouvelles mises à jour automatiques Teams sont désactivées).

Enfin, la nouvelle solution pour VDI stocke des données spécifiques à l’utilisateur (journaux, les configurations et les modèles IA ou ML, …) sur le poste local au démarrage de Teams sur la session VDI :

Et quid d’une mise à jour Teams côté client ou VDI ?

Grâce à ce changement d’approche, Microsoft a là aussi prévu le coup :

Chaque fois que vous mettez à niveau Teams sur le serveur, une nouvelle version du moteur de médias est déployée sur le client. Plus aucune mise à jour n’est nécessaire sur votre pile VDI (serveur ou client). Les plugins sont compatibles en amont et en aval avec les versions de SlimCore, et les plugins nettoieront également les versions de SlimCore inutilisées ou obsolètes.

Microsoft Tech Community

Doit-on prévoir des modifications au niveau des réseaux ?

Certains changement sont à prévoir selon votre cas. Microsoft met à disposition un second schéma afin de comprendre ces nouveaux changements :

Comme le signale Microsoft, assurez-vous que l’appareil de l’utilisateur dispose d’une connectivité réseau (UDP et TCP) aux ID de point de terminaison 11, 12, 47 et 127 décrits dans URL et plages d’adresses IP Microsoft 365.

IDCatégorieERAdressesPortsRemarques
11Optimiser les besoinsOui13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/38UDP : 3478, 3479, 3480, 3481Processeurs multimédias et relais de transport 3478 (STUN), 3479 (audio), 3480 (vidéo), 3481 (partage d’écran)
12Autoriser obligatoireOui*.lync.com, *.teams.microsoft.com, teams.microsoft.com 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 52.238.119.141/32, 52.244.160.207/32, 2603:1027 ::/48, 2603:1037 ::/48, 2603:1047 ::/48, 2603:1057 ::/48, 2603:1063 ::/38, 2620:1ec :6 ::/48, 2620:1ec :40 ::/42TCP : 443, 80
47Valeur par défaut requiseNon*.office.netTCP : 443, 80Utilisé pour les téléchargements SlimCore et les effets d’arrière-plan
127Valeur par défaut requiseNon*.skype.comTCP : 443, 80

Comment vérifie-t-on si SlimCore est bien utilisé ?

Si toutes les exigences sont en place, SlimCore devrait être automatiquement utilisé dans Microsoft Team lors d’une session VDI. Un contrôle rapide est possible dans le client VDI.

Ouvrez votre client Teams sur votre session VDI, puis cliquez sur le bouton des paramètres :

Puis cliquez sur la fonctionnalité A Propos :

Conclusion

La mise en place de cette nouvelle optimisation Teams dédiée aux environnements VDI montre une priorisation chez Microsoft de ses produits VDI phares que son Azure Virtual Desktop et Windows 365.

La nouvelle optimisation basée sur SlimCore offre de meilleures performances, une configuration d’appel plus rapide, un partage d’écran plus fiable, moins de temps d’arrêt et des résolutions de cas plus rapides.

Offrant de meilleures performances et de nouvelles fonctionnalités telles que la vidéo en 1080p et les mises à jour automatiques, SlimCore a pour objectif est de réduire les problèmes techniques, d’améliorer la qualité des réunions et de simplifier la gestion pour les administrateurs IT.

Windows 11 avec Web Sign-in

Le Web Sign-in de Windows 11 est une fonctionnalité innovante qui permet aux utilisateurs de se connecter à leur appareil Windows en utilisant autre chose que le mot de passe pour s’identifier. Introduite avec la version 22H2, cette méthode de connexion dite Passwordless utilise l’application Microsoft Authenticator. Elle est particulièrement utile dans les environnements nécessitant des connexions rapides et sécurisées, tout en éliminant le besoin de mémoriser un mot de passe complexe.

Cet article est la suite de l’article écrit précédemment et consacré à la mise en place du Passwordless sur les comptes Microsoft 365. Voici un lien direct de ce dernier.

Plusieurs méthodes d’authentification et pour quoi faire ?

Il est en effet possible d’avoir des méthodes utilisées en tant que méthode principale, tandis que d’autres ne seront acceptées que dans le cadre de la MFA, comme le rappelle très justement Microsoft :

Certaines méthodes d’authentification peuvent être utilisées en tant que facteur principal lorsque vous vous connectez à une application ou un appareil, par exemple à l’aide d’une clé de sécurité FIDO2 ou d’un mot de passe. D’autres méthodes d’authentification sont disponibles uniquement comme facteur secondaire lorsque vous utilisez une authentification multifacteur Microsoft Entra ou une SSPR.

Microsoft Learn

Voici un tableau détaillant les différentes méthodes acceptées avec leur périmètre

MéthodeAuthentification principaleAuthentification secondaire
Windows Hello EntrepriseOuiMFA
Notification Push Microsoft AuthenticatorNonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Microsoft Authenticator sans mot de passeOuiNon
Clé d’accès dans Microsoft Authenticator (préversion)OuiAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Authenticator LiteNonMFA
Clef d’accès (FIDO2)OuiMFA
Authentification par certificatOuiMFA
Jetons matériels OATH (version préliminaire)NonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Jetons logiciels OATHNonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Méthodes d’authentification externes (préversion)NonMFA
Passe d’accès temporaire (TAP)OuiMFA
SMSOuiAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Appel vocalNonAuthentification multi-facteur et réinitialisation de mot de passe en libre-service
Mot de passeOuiNon

Quel est le rapport entre Web sign-in et Passwordless ?

Web Sign-in est donc une méthode principale de type Passwordless. Plusieurs articles sur ce blog parlent déjà d’autres méthodes Passwordless comme :

Voici d’ailleurs d’autres liens en anglais très intéressants :

Dois-je avoir une connexion internet active pour m’authentifier via Web Sign-in ?

La réponse est oui : Il faut disposer d’une connectivité internet active car l’authentification web Sign-in se fera obligatoirement par cette dernière.

A partir de quelle version Windows 11 Web Sign-in est compatible ?

Windows ProWindows EntrepriseWindows Pro Education/SEWindows Éducation
OuiOuiOuiOui

À compter de Windows 11, version 22H2 avec KB5030310, vous pouvez activer une expérience de connexion web sur Microsoft Entra appareils joints. Cette fonctionnalité est appelée Connexion web et déverrouille de nouvelles options et fonctionnalités de connexion.

Microsoft Learn

Dans cet article, je vous propose de mettre en place et de tester l’authentification Web Sign-in sur un poste Windows 11 via le Passwordless de l’application Microsoft Authenticator :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice consacré au web Sign-in Windows, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator

Souhaitant faire un test sur une version propre d’un poste sous Windows 11, j’ai choisi de le 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.

Mais avant cela, quelques configurations sont nécessaires au niveau du tenant.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin d’activer l’inscription automatique Windows, puis vérifiez le paramètre suivant :

Toujours sur le portail Entra ID, cliquez ici afin d’activer la méthode d’authentification principale via Microsoft Authenticator :

Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator (article explicatif) :

Notre tenant dispose de la configuration nécessaire pour profiter du web Sign-in via le Passwordless. Nous allons pouvoir continuer la configuration de Windows 11 via une VM créée sous Azure.

Etape II – Préparation de la machine virtuelle Hyper-V :

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

Cliquez-ici pour créer votre machine virtuelle 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 :

Cliquez sur Suivant :

Rajoutez un second disque pour stocker la VM Windows 11, puis cliquez sur Suivant :

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

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

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

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

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 Hyper-V :

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

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

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

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

Lancez la commande suivante pour lancer un redémarrage immédiat de votre VM 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 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 Suivant :

Cliquez sur Suivant :

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 III – Préparation de la machine virtuelle Windows 11 :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle, 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 Hyper-V :

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 :

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

Pensez à bien choisir Génération 2 :

Modifier la taille de la mémoire vive allouée à la VM 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 créée, modifiez sa configuration comme ceci :

Dans la section Sécurité, cochez la case suivante pour activer la puce 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 :

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 à installer Windows 11. Suivez toutes les étapes de l’installation.

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

Lancez l’installation de Windows 11 :

Attendez que le démarrage de l’installation se lance, puis 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 :

Attendez quelques minutes que le redémarrage se poursuivre :

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 OS sont disponibles :

Nommez votre machine virtuelle Windows 11 selon vos souhaits, puis cliquez sur Suivant :

Attendez quelques minutes la fin de la configuration :

Adaptez la configuration des paramètres de confidentialité, puis cliquez sur Accepter :

Attendez quelques minutes la seconde vérification des mises à jour OS :

Attendez enfin la finalisation de la configuration de Windows 11 :

Finaliser la sécurisation de votre poste en configurant Windows Hello en cliquant sur OK :

Définissez le code PIN de votre choix, puis cliquez sur OK :

Cliquez à nouveau sur OK :

Vous voilà enfin sur le bureau Windows de votre machine virtuelle Windows 11 :

L’environnement Windows 11 pour notre test est maintenant opérationnel. Afin de déployer la configuration Web Sign-in, nous allons la pousser via la console de gestion Intune.

Etape IV – Configuration Intune – Web Sign-in :

Rendez-vous à nouveau sur le portail Entra ID afin de vérifier que la machine virtuelle Windows 11 jointe grâce à notre utilisateur de test y figure bien :

Rendez-vous également sur le portail Intune afin de vérifier que la machine virtuelle Windows 11 y figure également :

Cliquez-ici pour créer une nouvelle police de configuration Windows :

Choisissez la configuration de profil suivante, puis cliquer sur Créer :

Nommez votre profil de configuration, puis cliquez sur Suivant :

Cliquez ici pour ajouter un ou des paramètres à votre profil :

Recherchez par mot clef, cliquez sur la catégorie suivante, puis choisissez le paramètre suivant :

Activez le paramètre repris, puis cliquez sur Suivant :

Cliquez sur Suivant :

Sélectionnez un groupe de machines en rapport avec le test, puis cliquez sur Suivant :

Vérifiez la configuration de votre profil, puis lancez sa création :

La nouvelle police de configuration apparaît alors dans la liste :

Continuer la configuration Intune via la création d’une seconde police de configuration si vous souhaitez désactiver l’ouverture de session Windows via le mot de passe.

Etape V – Configuration Intune – Passwordless :

Cliquez-ici pour créer une seconde police de configuration Windows :

Choisissez la même configuration de profil, puis cliquer sur Créer :

Nommez votre second profil de configuration, puis cliquez sur Suivant :

Recherchez par mot clef, cliquez sur la catégorie suivante, puis choisissez le paramètre suivant :

Activez le paramètre ci-dessous, puis cliquez sur Suivant :

Cliquez sur Suivant :

Sélectionnez un groupe de machines en rapport avec le test, puis cliquez sur Suivant :

Vérifiez la configuration de votre second profil, puis lancez sa création :

La seconde police de configuration apparaît alors dans la liste :

Cliquez ici pour voir le détail de son déploiement sur votre poste de test, attendez plusieurs minutes, puis rafraîchissez cette page plusieurs fois au besoin :

Afin d’accélérer le processus, vous pouvez déclencher une synchronisation Intune via le menu suivant sous Windows 11 :

Cliquez sur le bouton suivant, puis attendez environ 5 minutes :

Une fois la configuration correctement déployée, il ne nous reste qu’à tester l’ouverture de session Windows de notre utilisateur.

Alternative :

En alternative à Intune, il aurait été possible travailler sur le registre Windows pour agir directement sur la configuration Passwordless et Web Sign-in :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Authentication

Etape VI – Test d’authentification utilisateur :

Pour cela, fermez la session Windows 11 actuellement ouverte :

De retour sur la mire d’authentification, cliquez sur le bouton suivant afin de constater la différentes méthodes d’authentification autorisées :

Cliquez selon votre cas sur le bouton Sign in ou Web Sign in :

Constatez l’apparition d’une fenêtre d’authentification Entra ID vous proposant d’envoyer une notification sur votre Smartphone configuré comme Passwordless :

Sur votre smartphone, saisissez le nombre précédemment affiché :

Juste après, constatez la bonne ouverture de la session Windows 11 :

Enfin, ouvrez les propriétés Windows de votre compte de test afin d’y constater l’absence de méthode consacrée au mot de passe :

Conclusion

La fonctionnalité Web Sign-in de Windows 11 marque une avancée notable dans la sécurisation et la simplification des méthodes de connexion.

En éliminant l’usage des mots de passe traditionnels, elle permet aux utilisateurs de s’authentifier via un navigateur web en utilisant l’application Microsoft Authenticator.

Disponible à partir de la version 22H2 de Windows 11, cette solution s’inscrit dans la continuité de la stratégie Passwordless Cloud de Microsoft.

Enfin, Windows 11 web Sign-in est également compatible avec Temporary Access Pass 😎

Soyez Passwordless grâce à Microsoft Authenticator

Très souvent, la sécurité d’un périmètre ou d’un environnement focalise une attention particulière aux processus d’authentification ainsi qu’aux moyens mis à disposition aux utilisateurs pour y parvenir. Quelles méthodes, quelles conditions, quels protocoles mettre en place ? La MFA est un principe de base maintenant acquis pour tous et set présent dans une majorité de systèmes, mais le mot de passe reste alors encore de la partie.

Qu’est-ce que le Passwordless ?

Le concept de Passwordless (sans mot de passe) désigne une méthode d’authentification qui permet aux utilisateurs de se connecter à des systèmes ou des services sans avoir à utiliser un mot de passe traditionnel.

Autrement dit, le concept de Passwordless regroupe plusieurs méthodes d’authentification différentes, comme :

  • Passkey via Microsoft Authenticator
  • Push via Microsoft Authenticator
  • FIDO2
  • Windows Hello
  • SmartCard

Pourquoi vouloir se débarrasser du mot de passe ?

L’objectif principal du Passwordless est de réduire les risques de compromission liés aux mots de passe traditionnels, comme les attaques par hameçonnage (phishing), les vols de mot de passe, ou encore les mauvaises pratiques liées à la gestion des mots de passe (mots de passe faibles ou réutilisés).

Passwordless vs MFA ?

Passwordless et MFA (Multi-Factor Authentication) sont 2 méthodes d’authentification sécurisée, mais elles diffèrent dans leur approche et leur mise en œuvre.

Des fonctionnalités telles que l’authentification multifacteur (MFA) sont un excellent moyen de sécuriser votre organisation, mais les utilisateurs sont souvent frustrés par la couche de sécurité supplémentaire en plus de devoir mémoriser leurs mots de passe.

Les méthodes d’authentification sans mot de passe sont plus pratiques, car le mot de passe est supprimé et remplacé par quelque chose que vous avez ou quelque chose que vous êtes ou connaissez.

Microsoft Learn

Voici une comparaison entre ces 2 concepts :

CaractéristiquePasswordlessMFA (Multi-Factor Authentication)
Utilisation des mots de passeAucune utilisation de mot de passeUtilise souvent un mot de passe + autre facteur
SécuritéTrès sécurisé (aucun mot de passe à compromettre)Très sécurisé (nécessite plusieurs facteurs)
Expérience utilisateurFluide et simplifiéePeut être plus complexe (plusieurs étapes)
Technologie utiliséeBiométrie, clés de sécurité, lien magique, etc.Combinaison de mot de passe + SMS, email, biométrie
Exemples d’utilisationConnexion par empreinte digitale, lien magiqueConnexion par mot de passe + code SMS ou app Authenticator

Dans cet article, je vous propose de mettre en place et de tester l’authentification Passwordless via l’application Microsoft Authenticator sur smartphone pour une identité 365 :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la méthode Passwordless de Microsoft, il vous faudra disposer de :

  • Un tenant Microsoft
  • Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator

Important : à l’issue de cette démonstration, gardez en tête que votre smartphone sera enregistré (mais non managé) dans chaque tenant Microsoft où il sera utilisé pour se connecter en Passwordless.

Commençons par activer le service Passwordless sur le tenant 365.

Etape I – Configuration du tenant :

Pour cela, rendez-vous dans la section suivante de votre portail Entra, puis cliquez sur Microsoft Authenticator :

Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator :

Définissez le périmètre des utilisateurs concernés en laissant le mode d’authentification à Any ou Passwordless :

Basculez sur le second onglet afin d’activer ou non Microsoft Authenticator OTP :

L’option suivante exigeant de retaper le numéro affiché n’est pas modifiable :

Choisissez au besoin ou non d’afficher l’application demandant l’authentification Passwordless :

Choisissez au besoin ou non d’afficher la localisation du demandeur de l’authentification Passwordless :

Choisissez au besoin ou non d’afficher Microsoft Authenticator sur les applications de type Compagnon :

Enfin, cliquez sur Sauvegarder :

Afin de comprendre le fonctionnement du processus depuis l’enrôlement de départ de Microsoft Authenticator, il est préférable de créer un utilisateur de test.

Etape II – Configuration du l’utilisateur :

Toujours sur votre portail Entra, cliquez ici pour créer un nouvel utilisateur sur votre tenant Microsoft :

Renseignez-lui un UPN, un nom d’affichage, ainsi qu’un mot de passe temporaire, puis lancez la validation Entra :

Une fois la validation Entra réussie, lancez la création de votre utilisateur des test :

Une fois l’utilisateur créé, ouvrez le navigateur internet de votre choix en mode privé :

Rendez-vous sur la page office.com, puis cliquez ici pour vous authentifier :

Saisissez le nom de compte de votre utilisateur de test ainsi que son mot de passe provisoire :

Définissez un nouveau mot de passe :

Cliquez sur Oui :

Notre environnement 365 et notre utilisateur sont maintenant créé.

Passons maintenant à l’étape suivante qui consiste à associer Microsoft Authenticator à notre compte de test.

Etape III – Configuration MFA :

En haut à droite, cliquez ici pour afficher les propriétés de votre compte 365 :

Dans l’onglet dédié aux informations de sécurité, ajoutez une nouvelle méthode d’authentification :

Choisissez la méthode suivante pour configurer Microsoft Authenticator :

Installez au besoin l’application Microsoft Authenticator depuis un store d’applications, puis cliquez sur Suivant :

Cliquez sur Suivant :

Choisissez le type Compte professionnel ou scolaire :

Cliquez ici pour utiliser l’appareil photo afin de scanner le QR code :

Scanner le QR code présenté par Microsoft :

Une fois scanné, cliquez sur Suivant :

Une notification est alors envoyée à votre smartphone :

Saisissez le nombre précédemment affiché, puis cliquez sur Oui :

Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :

La méthode Microsoft Authenticator est maintenant correctement configurée sur votre compte de test, cliquez alors sur Suivant :

La méthode Microsoft Authenticator apparaît alors sur votre compte en tant que méthode dite MFA :

L’utilisateur de test est maintenant correctement configuré avec un mot de passe traditionnel et une méthode de sécurité de type MFA.

Etape IV – Configuration Passwordless :

Afin d’activer la méthode Passwordless, nous allons transformer le compte de test enregistré sur l’application Microsoft Authenticator.

Pour cela, ouvrez l’application Microsoft Authenticator, sélectionnez votre compte de test, puis cliquez ici pour activer la fonctionnalité Passwordless :

Microsoft vous informe que l’appareil sera inscrit dans le tenant ID correspondant, cliquez sur Continuer

Sur l’application Microsoft Authenticator, renseignez le mot de passe de votre compte de test :

Un nombre apparaît alors sur la fenêtre, ainsi qu’une notification Microsoft Authenticator, vous demandant de ressaisir ce dernier :

Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :

Cliquez ici pour confirmer l’enregistrement de votre smartphone sur le tenant ID concerné :

Microsoft Authenticator vous confirme le succès des opérations et de l’activation de la fonctionnalité Passwordless, cliquez alors sur Terminer :

Retournez sur le portail Entra afin de constater l’apparition de votre smartphone en tant que périphérique enregistré :

De retour sur les éléments de sécurité de votre utilisateur de test, la méthode Microsoft Authenticator s’est transformée de MFA à Passwordless :

Tout notre environnement de test est maintenant configuré. Il ne nous reste qu’à tester que la méthode Passwordless fonctionne correctement à la place du mot de passe.

Etape V – Test du Passwordless :

Rouvrez à nouveau un navigateur internet en mode privée :

Rendez-vous à nouveau sur la page office.com, puis cliquez ici pour vous authentifier :

Saisissez le nom de compte de votre utilisateur de test, puis, au lieu de renseigner son mot de passe, cliquez sur le choix suivant :

Microsoft envoie alors une notification sur le smartphone configuré comme Passwordless :

Ouvrez la notification Microsoft Authenticator, puis ressaisissez le nombre précédemment indiqué par Microsoft :

De retour sur votre navigateur, confirmez votre souhait de rester authentifié en cliquant sur Oui :

La page d’accueil d’Office 365 s’ouvre bien, l’utilisateur s’est correctement authentifié sans mot de passe :

Côté traçabilité, il est possible de retrouver des logs des authentifications Passwordless dans plusieurs écrans de Microsoft :

Côté utilisateur, via sa gestion de compte :

Côté Administrateur, via la vue des logs d’un utilisateur sur Entra ID :

Ou via une requête KQL après l’activation Log Analytics sur Entra ID :

SigninLogs
| where AuthenticationDetails has "passwordless"
| project TimeGenerated, UserPrincipalName, AuthenticationDetails , ResultDescription
| order by TimeGenerated desc

Conclusion

En conclusion, l’adoption du Passwordless avec Microsoft Authenticator constitue une avancée significative dans la sécurisation des environnements numériques tout en améliorant l’expérience utilisateur.

En éliminant la nécessité de mémoriser et de gérer des mots de passe, cette méthode réduit les risques liés aux compromissions, telles que les attaques de phishing ou le vol de mots de passe.

De plus, elle simplifie les processus d’authentification, rendant l’accès aux services plus fluide. Pour les entreprises, c’est une opportunité d’offrir un meilleur équilibre entre sécurité et facilité d’utilisation, tout en renforçant la confiance des utilisateurs dans la protection de leurs données.

Bref, aucune méthode n’est jamais parfaite 😎 :

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 WANType de HubConfigurations disponibles
De baseDe baseVPN de site à site uniquement
standardstandardExpressRoute
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 .

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 Suivant :

Cliquez sur Suivant :

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é :

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