Trustez votre Entra Domain Services

Anciennement appelé AADDS pour Azure Active Directory Domain Services, ce service a lui aussi subi le renommage d’Entra ID de 2023. Très facile à déployer et à maintenir, le domaine managé de Microsoft a tout pour plaire. Mais depuis quelques temps, peu d’évolutions lui ont été apportées. Dean Cefola de la Cloud Academy refait parler de lui et des possibles trusts pour notre plus grand plaisir.

Pour commencer, quelques notions intéressantes sur ce service managé par Microsoft :

Qu’est-ce que Microsoft Entra Domain Services ?

Grâce à Entra Domain Services, il va vous être possible de générer rapidement et facilement un domaine AD, au sens classique du terme, managé par Microsoft et à partir de votre Entra ID :

Microsoft Entra Domain Services offres des services de domaine managé, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos et NTLM. Vous utilisez ces services de domaine sans avoir à déployer, gérer et apporter des correctifs aux contrôleurs de domaine dans le cloud.
Microsoft Learn

La partie de gauche de ce schéma nous montre le potentiel de synchronisation d’Entra Domain Services depuis des données stockées dans Entra ID :

Mais alors quelles sont les différences entre un AD DS classique, Entra ID et Entra Domain Services ?

Cet article ne date pas d’hier mais répond très bien à la question !

Afin de rentrer directement dans le vif du sujet, voici donc la vidéo de Dean ayant servi de base à cet article ainsi que le tutoriel officiel de Microsoft :

Vous l’aurez compris, le but est donc tester le trust entre un environnement on-premise et un domaine managé par Microsoft hébergé sous Azure. Grâce à cette approche séparée, chaque domaine impactera en premier lieu sa localité, tout en ayant des adhérences avec les annexes.

Afin de bien comprendre la mise en place du trust entre le domain Active Directory on-premise et le service managé Entra Domain Services, je vous propose de réaliser ce petit exercice :

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer plusieurs ressources détaillées par la suite.

Etape I – Création du domaine managé Entra Domain Services :

Commençons par créer notre service de domaine active Directory managé. Pour cela, rechercher le service Microsoft Entra Domain Services sur votre portail Azure :

Cliquez-ici pour créer le service managé sur votre tenant :

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

Validez ses 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 la création de toutes les ressources Azure :

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

La notification Azure suivante apparaît en haut à droite de votre portail :

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 ici, 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 :

Constatez la présence d’une notification Azure impactant votre réseau virtuel :

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

Afin de gérer plus facilement le partage côté domaine managé, vous pouvez créer une machine virtuelle Azure sur le même réseau que votre domaine managé avec la fonctionnalité suivante :

Enfin, rendez-vous sur la console d’administration de Microsoft 365 afin de créer un utilisateur de test Cloud :

Notre domaine managé par Microsoft est configuré dans sa partie initiale.

Nous allons reproduire maintenant une seconde configuration pour notre domaine AD non managé et représentant un environnement on-premise.

Etape II – Création du domaine non managé Active Directory :

Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :

Ajoutez un disque secondaire pour les dossiers systèmes AD, puis cliquez sur Suivant :

Prenez soin de définir un réseau virtuel différent du domaine managé, retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Retournez sur le réseau virtuel nouvellement créé par la machine virtuelle afin de renseigner l’adresse IP locale de votre VM en tant que serveur DNS, puis Sauvegardez :

Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :

Une fois connecté, rendez-vous dans le Gestionnaire des disques :

A l’ouverture du gestionnaire des disques, il vous est proposé d’initialiser le disque de données :

Par la suite créez un nouveau volume simple :

Puis formatez ce dernier en NTFS :

Continuez en ajoutant un nouveau rôle à votre Windows via Server Manager :

Cliquez sur Suivant :

Cochez les 2 rôles ci-dessous, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 5 minutes que l’installation des 2 rôles se termine :

Démarrez la promotion de ce serveur en tant que contrôleur de domaine AD :

Créez une nouvelle forêt locale :

Définissez un mot de passe DSRM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Renseignez la lettre de votre disque de données, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Quelques minutes plus tard, Windows vous avertit d’une déconnexion imminente :

Attendez quelques minutes qu’Azure Bastion vous reconnecte une fois la machine virtuelle redémarrée avec le compte administrateur de domaine :

Attendez la fin de l’initialisation pendant environ 5 minutes :

Vérifiez la présence de votre domaine AD dans la console Server Manager :

Enfin, créez une nouvelle OU ainsi qu’un nouvel utilisateur local à votre domaine AD :

Continuons la suite de l’exercice en reliant les deux réseaux virtuels Azure entre eux.

Etape III – Appairage des réseaux virtuels :

Sélectionnez le réseau virtuel contenant votre domaine managé par Microsoft :

Ajoutez un appairage de réseau virtuel comme ceci :

Configurez votre appairage comme-ci, puis cliquez sur Ajouter :

Les deux notifications Azure suivantes devraient apparaître :

Vérifiez le changement de statut de votre appairage :

Le lien réseau est maintenant opérationnel. La suite consiste à élaborer la relation de confiance entre les deux domaines Active Directory.

Etape IV – Mise en place du Trust Active Directory :

Copiez les 2 adresses IPs présentes sur votre domaine managé par Microsoft :

Sur votre contrôleur de domaine local, ouvrez l’outil DNS :

Ajoutez un nouveau transit conditionnel via un clic droit :

Reprenez le nom de votre domaine managé, ajoutez-y ses deux adresses IPs, cochez la case suivante, puis cliquez sur OK :

Testez le bon transfert des requêtes du domaine managé via la commande suivante :

nslookup jloudev.cloud

Toujours sur votre contrôleur de domaine, ouvrez le menu suivant :

Rendez-vous dans les propriétés de votre domaine :

Dans l’onglet suivant, cliquez sur Nouveau Trust :

Cliquez sur Suivant :

Reprenez le nom de votre domaine managé, puis cliquez sur Suivant :

Définissez le trust au niveau de la forêt, puis cliquez sur Suivant :

Activez le trust bidirectionnel, puis cliquez sur Suivant :

Configurez le trust simplement pour ce domaine, puis cliquez sur Suivant :

Cliquez sur Suivant :

Définissez un mot de passe trust, puis cliquez sur Suivant :

Cliquez sur Suivant :

N’activez pas le trust sortant, puis cliquez sur Suivant :

Cliquez enfin sur Terminer :

Vérifiez la présence du lien dans le tableau des trusts :

Continuons avec la configuration de trust sur le domaine managé par Microsoft.

Etape V – Mise en place du Trust Entra Domain Services :

Pour cela, retournez sur la page Azure de votre domaine managé par Microsoft, puis ajoutez le trust par le menu suivant :

Renseignez les informations dont les adresses IP de vos serveurs DNS / AD, puis cliquez sur Sauvegarder :

Confirmez votre choix en cliquant sur OK :

Quelques minutes plus tard, le trust apparait bien comme côté Entra Domain Services :

La liaison Trust est maintenant opérationnelle des 2 côtés. Avant de tester les accès, il est nécessaire d’inscrire les droits sur les 2 partages de fichiers.

Etape VI – Configuration du partage Active Directory :

Retournez dans la gestion de l’Active Directory afin d’y créer un nouveau groupe contenant à la fois notre utilisateur AD et notre utilisateur Cloud comme ceci :

Créez un nouveau dossier sur votre serveur local, puis ajoutez ce nouveau groupe AD avec des droits en modification :

Sur l’onglet de Partage cliquez sur le Partage avancé :

Activez le partage, puis définissez les permissions :

Ajoutez le même groupe AD avec les droits suivants :

Il ne nous reste qu’à répéter cette opération sur le second partage Cloud.

Etape VII – Configuration du partage Entra Domain Services :

Retournez dans la gestion AD d’Entra Domain Services afin d’y créer là aussi un nouveau groupe contenant à la fois notre utilisateur AD et notre utilisateur Cloud comme ceci :

Créez un nouveau dossier sur votre serveur Cloud, puis ajoutez ce même groupe Cloud avec des droits en modification :

Sur l’onglet de Partage, cliquez sur le Partage avancé :

Activez le partage, puis définissez les permissions :

Ajoutez le même groupe Cloud avec les droits suivants :

Tout est enfin prêt pour passer aux tests utilisateurs. Croisons les doigts ! 🤞

Etape VIII – Test d’accès Active Directory :

Créez une nouvelle machine virtuelle sous Windows 11 et jointe au domaine Active Directory, puis ouvrez une session avec votre utilisateur de test via Azure Bastion :

Renseignez le chemin d’accès du partage réseau Cloud dans l’explorateur Windows, constatez la bonne authentification, puis créez une fichier pour vérifier les droits en écriture :

Effectuons maintenant un second test côté Entra Domain Services.

Etape IX – Test d’accès Entra Domain Services :

Créez une seconde machine virtuelle sous Windows 11 et jointe cette fois au domaine managé par Microsoft, puis ouvrez une session avec votre utilisateur de test via Azure Bastion :

Renseignez le chemin d’accès du partage réseau local dans l’explorateur Windows, constatez la bonne authentification, puis créez une fichier pour vérifier les droits en écriture :

Conclusion :

L’accès aux 2 partages de fichiers fonctionnent sans souci 😎 ! La mise en place de trust est grandement facilité depuis le service Entra Domain Services. Il s’agit d’une raison supplémentaire d’utiliser ce service, tout en prenant soin de mesurer ces différences juste ici.

VM – Traquez les changements

Azure est une excellente plateforme pour déployer rapidement et facilement des ressources IT. Seulement, la phase de déploiement de ressources ne représente que la première partie du travail d’une infrastructure. Bien souvent, plusieurs agents ou équipes interviendront sur ces mêmes ressources Azure. Un système de suivi des changements apparait alors comme très utile pour traquer efficacement les modifications faites par les uns et par les autres.

Qu’est-ce que le Suivi des modifications et inventaire (Change Tracking et Inventory) ?

En quelques mots, le Suivi des modifications et inventaire va vous permettre de comprendre les modifications faites sur vos ressources Azure, mais aussi à l’intérieur de celles-ci.

Voici un exemple de 2 vues disponibles retraçant différents types de modifications :

Le Suivi des modifications et inventaire effectue le suivi des modifications apportées aux machines virtuelles hébergées sur Azure, locales et d’autres environnements cloud pour vous aider à identifier les problèmes opérationnels et environnementaux liés aux logiciels gérés par le gestionnaire de package de distribution.
Microsoft Learn

On y retrouve donc des modifications de registres, de fichiers, de programmes et bien d’autres encore.

Que pouvons-nous traquer dans le Suivi des modifications et inventaire ?

A ce jour, plusieurs éléments sont traçables au travers du Suivi des modifications et inventaire. Voici la liste des modifications traçables :

Logiciels Windows
Logiciel Linux (packages)
Fichiers Windows et Linux
Clés de Registre Windows
Services Windows
Démons Linux

Doit-on payer pour utiliser Suivi des modifications et inventaire ?

Oui. En effet, le Suivi des modifications et inventaire est un service payant. Il repose sur stockage appelé Log Analytics Workspace pour stocker les données liées aux modifications. Comme à chaque fois, le Log Analytics Workspace est facturé au Go de données écrites.

Niveau agent : AMA ou MMA, lequel choisir ?

Microsoft avait annoncé la préversion de Suivi des modifications et inventaire via l’agent AMA en janvier 2023. L’agent AMA prend le pas sur l’agent LOA pour des raisons de sécurité, de fiabilité, et facilite également les multi-environnements. De plus, il n’est plus nécessaire d’intégrer un compte Azure Automation.

D’ailleurs Microsoft a également annoncé une date de retrait pour MMA/LOA :

Actuellement, le suivi des modifications et l’inventaire utilisent Log Analytics Agent et son retrait est prévu d’ici le 31 août 2024. Nous vous recommandons d’utiliser Azure Monitoring Agent comme nouvel agent de prise en charge.
Microsoft Learn

Agent, Extension, Kesako ?

Il existe des différences entre un agent et une extension. Microsoft apporte sur cette page quelques infos bien utiles :

Agent : Il s’agit d’une application légère, toujours en cours d’exécution (le plus souvent exécutée en tant que service/daemon), qui collecte des informations auprès de la machine et les transmet quelque part ou maintient l’état de la machine elle-même en fonction d’une certaine configuration.
Extension : Dans Azure, les extensions fournissent des tâches de configuration et d’automatisation post-déploiement sur les VM Azure. Les extensions peuvent faire partie de la définition de la VM elle-même, et donc être utilisées pour déployer quelque chose dans le cadre du déploiement de la ressource hôte elle-même. Dans le cas d’Azure Monitor, il existe des extensions qui déploient l’agent de surveillance dans le cadre du déploiement de la VM/VMSS.
AzureMonitoringWindowsAgent : Il s’agit de l’extension la plus récente et la plus recommandée d’Azure Monitor Agent (AMA) pour une VM. Elle est disponible pour les VM Windows avec le nom AzureMonitoringWindowsAgent. De même, AzureMonitorLinuxAgent est le nom de l’extension pour l’AMA sur la VM Linux.
MMAExtension : C’est le nom de l’extension qui installe l’ancien agent sur la VM Windows. L’agent lui-même est appelé Log Analytics Agent ou LA Agent, également appelé « Microsoft Monitoring Agent » ou MMA. Pour les machines virtuelles Linux, cette extension installe un paquetage d’agent appelé OMSAgentforLinux.

Enfin, cette page détaille les différences techniques des agents en relation avec Azure Monitor.

Afin de bien comprendre ce que le Suivi des modifications et inventaire d’Azure est capable de faire avec un agent AMA, je vous propose de suivre ce petit exercice :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur le Suivi des modifications et inventaire d’Azure, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer une machine virtuelle.

Etape I – Préparation de l’environnement :

Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

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

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Les notifications suivantes devraient apparaitre :

Sans attendre la fin du déploiement d’Azure Bastion, recherchez le service Log Analytics Workspace :

Cliquez-ici pour déployer votre Log Analytics Workspace :

Renseignez tous les champs dont son nom devant être unique sur Azure :

Attendez maintenant que le Log Analytics Workspace et Azure Bastion soient entièrement déployés pour continuer cet exercice.

Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :

Notre environnement de base est maintenant en place. Nous allons pouvoir continuer en activant le service Suivi des modifications et inventaire.

Etape II – Activation du Suivi des modifications et inventaire :

Pour cela, retournez sur votre machine virtuelle afin d’activer le Suivi des modifications et inventaire en utilisant un agent AMA :

La mise en place de ce service déploie 2 extensions sur votre machine virtuelle et vous invite à patienter :

Quelques minutes plus tard, consultez les extensions installées sur votre machine virtuelle :

Afin que toutes les modifications soient bien prises en compte dans le Suivi des modifications et inventaire, je vous conseille d’attendre 30 minutes avant de continuer la suite de cet exercice.

Etape III – Sauvegarde des évènements Azure :

La sauvegarde d’évènements Azure est utile afin de bien comprendre par exemple les modifications faites directement sur les ressources Azure.

Pour cela, cliquez sur le menu suivant dans votre machine virtuelle :

Puis cliquez-ici :

Enfin cliquez-ici pour connecter votre journal d’activité Azure :

Quelques secondes plus tard, constatez le bon changement du statut de la connexion :

Effectuez ensuite un changement de taille de votre machine virtuelle :

Attendez que le redimensionnement soit terminé :

Quelques minutes plus tard, constatez l’apparition d’une ligne d’évènement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi des fichiers Windows.

Etape IV – Sauvegarde du suivi de fichiers Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de fichiers Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez le fichier correspondant à votre règle de suivi :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi du registre Windows.

Etape V – Sauvegarde du suivi du registre Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de registre Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez la clef de registre correspondante à votre règle :

Quelques minutes plus tard, constatez l’apparition d’une ligne de changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en ajoutant le suivi des services Windows.

Etape VI – Sauvegarde du suivi de services Windows :

Modifiez si besoin la fréquence des remontées d’informations sur les services Windows :

Sur votre machine virtuelle de test, lancez le script PowerShell d’installation suivant :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Attendez la fin de l’installation du rôle IIS :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en modifiant la sauvegarde du suivi des modifications du contenu de fichiers.

Etape VII – Sauvegarde du suivi des modifications du contenu de fichiers :

Avant d’activer la fonction du suivi des modifications de fichiers, recherchez le service des comptes de stockage Azure :

Créez un compte de stockage dédié à la fonction du suivi de modification des fichiers :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du compte de stockage, puis attendez environ 1 minute :

Une fois le compte de stockage créé, retournez dans la configuration du Suivi des modifications et inventaire afin d’y ajouter ce dernier :

Choisissez votre compte de stockage, puis cliquez sur Sauvegarder :

Retournez sur votre compte de stockage, puis ouvrez le conteneur suivant créé automatiquement par le Suivi des modifications et inventaire :

Cliquez-ici pour ajouter des droits RBAC sur ce conteneur blob :

Choisissez le rôle ci-dessous, puis cliquez sur Suivant :

Ajoutez l’identité managée de votre machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de l’assignation RBAC :

Modifiez le contenu d’un fichier de texte présent sur votre machine virtuelle de test, puis retournez sur votre compte de stockage afin de constater le téléversement du fichier modifié quelques minutes plus tard :

Terminons les tests du Suivi des modifications et inventaire en installant un logiciel sur la machine virtuelle.

Etape VIII – Inventaire des logiciels :

Téléchargez par exemple Google Chrome depuis une source officielle :

Lancez son installation :

Quelques minutes plus tard, Google Chrome apparait bien dans le Suivi des modifications et inventaire en tant qu’application installée :

Conclusion

Bien que le Suivi des modifications et inventaire soit très intéressant dans certains scénarios, je ne sais pas ce que l’avenir va donner sur cet outil Microsoft.

Un autre outil très intéressant et accessible sans aucun déploiement est le Change Analysis. Cet outil ne fait pas la même chose que le Suivi des modifications et inventaire.

Comme la copie d’écran ci-dessous le montre, Change Analysis est un moyen simple et rapide de voir les changement de propriétés effectués sur une ressources Azure :

Pour rester sur le sujet, John Savill a également fait une vidéo très intéressante sur la gestion des modifications Azure et les alertes possibles :

Enfin, un autre outil présent nativement dans Azure pourra vous aider dans votre investigation Azure, il appelé Resource Explorer :

Windows Server 2025 🪟

Depuis seulement quelques jours, La nouvelle release de Windows Server s’appelle maintenant Windows Server 2025 ! Seulement disponible via le programme Windows Server Insider, la version Build v26040 de Windows Server 2025 promet de nouvelles fonctionnalités comme le Hotpatching pour tous ou encore Active Directory et SMB en version Next Gen, et sûrement encore plein d’autres à découvrir.

Cette annonce de Windows Server 2025 a été faite sur le site TechCommunity juste ici.

De précédentes annonces concernant Windows Server avaient été annoncées durant le dernier Ignite juste là :

Je ne vais pas rentrer tout de suite dans les détails de Windows Server 2025, que je ne connais pas encore car je ne l’ai pas testé. Mais je trouvais intéressant de partager avec vous une méthode de déploiement facile et rapide du dernier OS de Microsoft sur Azure.

En effet, et comme vous pouvez vous en doutez, ce dernier n’est pas encore directement accessible via le portail Azure lors de la création d’une machine virtuelle.

D’où mon petit exercice très rapide sur le sujet :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

La suite se passera par l’inscription au programme Windows Insider.

Etape I – Programme Windows Insider :

Afin de récupérer l’image de la dernière version disponible de Windows Server 2025, il est donc nécessaire de s’inscrire au programme Windows Insider (de Windows Server).

La documentation officielle de Microsoft l’explique bien et est accessible via ce lien :

Vous pouvez vous inscrire directement Programme Windows Insider via cette page, en utilisant un compte Microsoft Entra ou même un compte personnel Microsoft :

Lisez les informations du programme, puis acceptez ses termes si vous êtes d’accord :

Cliquez-ici pour rejoindre la page dédiée à Windows Server :

Choisissez la version suivante de Windows Server afin de pouvoir l’installer sous Azure :

Sélectionnez la seule langue disponible actuellement, puis cliquez sur Confirmer :

Cliquez-ici pour commencer le téléchargement du fichier au format VHDX :

Attendez quelques minutes la fin du téléchargement sur votre poste :

Une fois téléchargé, le fichier VHDX doit être converti en VHD pour être exploité sous Azure.

Etape II – Préparation du fichier image VHD :

En effet Azure ne support que le format VHD. Nous allons donc devoir effectuer une conversion de format. Cela est possible facilement en PowerShell.

Note : Pour utiliser la commande Convert-VHD, les outils Hyper-V sont nécessaires.

Ouvrez PowerShell, puis lancez la commande suivante pour convertir le fichier téléchargé au format VHDX en fichier au format VHD :

Convert-VHD –Path c:\2025\Windows_InsiderPreview_ServerDatacenter_Azure_Edition_en-us_VHDX_26040.vhdx –DestinationPath c:\2025\Windows_InsiderPreview_ServerDatacenter_Azure_Edition_en-us_VHDX_26040.vhd -VHDType Fixed

Attendez environ 5 minutes que le traitement de conversion se termine :

Une fois le fichier image converti au format VHD, ouvrez le portail Azure, puis recherchez le Service de stockage :

Créez un nouveau compte de stockage Azure en cliquant ici :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, démarrez la création de la ressource :

Environ 1 minute plus tard, cliquez-ici pour vous connecter au nouveau compte de stockage :

Créez un nouveau contenaire blob :

Nommez-le puis lancez sa création :

Dans ce contenaire blob, cliquez sur Téléverser :

Sélectionnez votre fichier VHD, choisissez le format Page Blob, puis cliquez sur Téléverser :

La notification Azure suivante doit apparaitre :

Suivez l’évolution de l’envoi vers Azure en bas à droite de l’écran :

Attendez environ 15 minutes que l’envoi vers Azure se termine :

Une fois l’envoi vers Azure terminé, cliquez sur votre blob pour en copier l’URL :

Votre source est enfin prête. Nous allons maintenant créer une galerie d’images de VM en faisant appel à notre fichier blob.

Etape III – Création de la galerie d’images :

Pour cela, commencez par rechercher le service Azure suivant :

Créez une nouvelle galerie d’images VM en cliquant ici :

Nommez votre galerie d’images VM, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour démarrer la création de la ressource :

Environ 1 minute plus tard, la galerie d’images VM est créée, puis cliquez ici :

Cliquez-ici pour créer une nouvelle définition d’image VM :

Renseignez tous les champs nécessaires, puis lancez la validation Azure :

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

Environ 2 minutes plus tard, cliquez-ici pour ajouter une nouvelle version :

Cliquez-ici pour ajouter une nouvelle version à votre définition d’images VM :

Renseignez les champs et reprenez pour le disque OS l’URL du blob copiée précédemment :

Lancez la validation Azure :

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

Environ 10 minutes plus tard, cliquez-ici pour retourner sur votre version :

Notre environnement est enfin prêt, nous allons maintenant créer notre première machine virtuelle sous Windows Server 2025.

Etape IV – Création de la machine virtuelle :

Cliquez-ici pour créer une nouvelle machine virtuelle à partir de cette image :

Renseignez tous les champs de base :

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

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’IP publique de votre VM, puis cliquez sur Suivant :

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

Une fois la validation Azure réussie, cliquez-ici pour lancer la création de la ressource :

Environ 5 minutes plus tard, cliquez-ici pour consulter la machine virtuelle créée :

Dans la foulée, déployez le service Azure Bastion afin de pouvoir ouvrir une connexion RDP :

Attendez 5 minutes la création du service Azure Bastion :

Etape V – Test et connexion :

Une fois le service Azure Bastion déployé, ouvrez une session RDP par ce dernier :

Définissez la politique d’envoi de données à Microsoft :

Depuis Server Manager, vérifiez la bonne version de votre Windows Server :

Depuis Paramètres, vérifiez la bonne version de votre Windows Server :

De retour sur Azure, profitez-en pour installer Windows Admin Center :

Attendez environ 1 minute que l’extension Windows Admin Center soit installée :

Vérifiez sa bonne installation par cet écran :

Ajoutez votre utilisateur Entra ID le rôle RBAC suivant :

Ajoutez une IP publique et une règle entrante NSG pour pouvoir vous connecter à Windows Admin Center depuis le portail Azure :

Ouvrez une connexion à Windows Admin Center :

Vérifiez la bonne disponibilité des informations via Windows Admin Center :

Redémarrez par le portail Azure votre VM si Windows Admin Center reste trop longtemps sur cette page :

Conclusion

Microsoft continue de faire avancer Windows Server dans sa gamme de produit OS, et promet à coup sûr de belles choses à venir 😎. Quand j’aurais pris le temps de faire mes tests dessus🤣, comptez sur moi pour d’autres articles à suivre !

Déplacez votre VM dans une Zone Azure

Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.

Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏

Annoncé le 12 décembre dernier sur blog Azure, cette fonctionnalité dédié aux machines virtuelles vient compléter la récente annonce datée d’octobre sur l’Expansion zonale des Azure VMSS.

Voici d’ailleurs un schéma montrant l’intégration de 3 zones au sein d’une seule région Azure :

Microsoft a déjà mis à disposition la documentation sur ce nouveau type de migration :

En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :

Scénario	Assistance technique	Détails
Machine virtuelle à instance unique	Prise en charge	Le déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge.
Machines virtuelles au sein d’un groupe à haute disponibilité	Non pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniforme	Non pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexible	Non pris en charge
Régions prises en charge	Prise en charge	Seules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région.
Machines virtuelles déjà situées dans une zone de disponibilité	Non pris en charge	Le déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité.
Extensions de machine virtuelle	Non pris en charge	Le déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible.
Machines virtuelles avec lancement fiable	Prise en charge	Réactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentielles	Prise en charge	Réactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles de 2e génération (démarrage UEFI)	Prise en charge
Machines virtuelles dans des groupes de placement de proximité	Prise en charge	Le groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale.
VM spot (machines virtuelles de basse priorité)	Prise en charge
Machines virtuelles avec hôtes dédiés	Prise en charge	L’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activée	Prise en charge
Machines virtuelles créées à partir d’images de la Place de marché	Prise en charge
Machines virtuelles créées à partir d’images personnalisées	Prise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)	Prise en charge
Stratégies RBAC de machine virtuelle	Non pris en charge	Le déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Machines virtuelles utilisant l’accélération réseau	Prise en charge

Pourquoi migrer dans une Zone de disponibilité Azure ?

Les avantages à utiliser les zones de disponibilité Azure sont les suivants:

Pour des raisons de besoins de fiabilité et de performance.
Pour une reprise après sinistre sans compromettre la résidence des données.

Pour rappel, la SLA sera différente si la VM est toute seule, ou si elle est accouplée à une autre VM dans une Availability Set ou Availability Zone :

Afin de se faire une meilleure idée sur cette migration, je vous propose de réaliser un petit exercice, dont les tâches seront les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :

Un tenant Microsoft
Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).

Etape I – Préparation de la VM Régionale :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Ouvrez une ou plusieurs applications en enregistrant le travail effectué :

Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.

Etape II – Déplacement de la VM Régionale dans une Zone :

Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :

Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.

Cliquez-ici pour démarrer le processus de migration :

Choisissez la zone cible pour la migration :

Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :

Une notification Azure apparaît également :

Un nouveau groupe de ressources est créé par cette même occasion :

Des droits RBAC sont également générés au niveau de la souscription Azure concernée :

Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :

Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :

Création d’un nouveau groupe de ressources
Création de nouvelles ressources pour tous les objets existants
Modification des noms des ressources

La validation entraine une seconde vérification des paramètres modifiés :

Une nouvelle notification Azure apparait indiquant que le traitement est en cours :

Environ 30 secondes plus tard, le traitement de validation se termine :

Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :

Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :

Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :

La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :

Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :

Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :

Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :

Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :

La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3

Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :

Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :

De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :

Etape III – Contrôle de la VM zonée :

Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :

Vérifiez la présence de la zone 3, puis cliquez sur le Editer :

Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :

Cette information de zone de notre machine virtuelle est aussi disponible ici :

Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :

Redéployer un service Azure Bastion
Utiliser l’adresse IP publique
Appairer les 2 réseaux virtuels entre eux

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :

Vérifiez la présence du travail effectué précédemment :

Etape IV – Nettoyage des ressources non zonées :

Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.

Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :

Groupe de ressources contenant l’ancienne machine virtuelle
Groupe de ressource contenant les composants liés à la migration

La suppression d’un groupe de ressources Azure s’effectue très simplement :

Confirmez l’ordre de suppression :

Conclusion

Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.

On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎

Azure Site Recovery pour des serveurs sur site

En cas de sinistre informatique, il n’y a aucun moyen de savoir ce qui peut frapper ou comment votre l’infrastructure peut en être affectée. Toutefois, en adoptant une approche réfléchie de la planification en cas de catastrophe, vous créer une tranquillité d’esprit si votre entreprise devait être confrontée à un sinistre.

Azure Site Recovery : permet d’assurer la continuité de l’activité en maintenant l’exécution des charges de travail et applications métier lors des interruptions. Site Recovery réplique les charges de travail s’exécutant sur des machines virtuelles et physiques depuis un site principal vers un emplacement secondaire.

En cas d’interruption au niveau de votre site principal, vous basculez vers un emplacement secondaire, depuis lequel vous pouvez accéder aux applications. Quand l’emplacement principal est de nouveau fonctionnel, vous pouvez effectuer une restauration automatique vers celui-ci.
Microsoft Learn

Voici une vidéo qui parle des mécanismes d’Azure Site Recovery :

Afin de se faire une meilleure idée sur Azure Site Recovery, je vous propose de réaliser un petit exercice combinant Azure Site Recovery et Hyper-V :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Site Recovery, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Important : Pour cela, je vous propose de simuler deux serveurs sous Windows Server 2019 grâce à un environnement virtualisé de type Hyper-V hébergé lui sur Azure

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

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

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

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs de base de votre machine virtuelle Hyper-V :

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

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

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

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

Cliquez ensuite sur Suivant :

Retirez l’adresse IP publique (pour des questions de sécurité), puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 3 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle Hyper-V :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

La configuration Azure est maintenant terminée, la suite va se passer sur la machine virtuelle Hyper-V.

Etape II – Configuration Hyper-V :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

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 rôles se termine :

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

Shutdown -R

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

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

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

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

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

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

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 :

L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble deux machine virtuelles :

Windows Server 2019 pour jouer le rôle d’Appliance Azure Site Recovery
Windows Server 2019 pour jouer le rôle d’un serveur on-premise

Etape III – Création des machines virtuelles (Appliance / SRV) :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Server 2019 afin de créer la machine virtuelle Appliance, puis d’y installer l’OS.

Toujours sur la machine virtuelle hôte (Hyper-V), ouvrez le navigateur internet Microsoft Edge.

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

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

Depuis votre VM hôte (Hyper-V), rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre première machine virtuelle Appliance :

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 :

Pensez à bien choisir Génération 2 :

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

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

Cliquez sur Suivant :

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

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

Modifiez le nombre de processeurs virtuels, puis cliquez sur OK :

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

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

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

Lancez l’installation de Windows Server 2019 :

Choisissez une version suivante de Windows Server 2019, puis cliquez sur Suivant :

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

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

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

Attendez maintenant que l’installation de Windows Server 2019 commence :

En attentant que l’installation de Windows Server 2019 se finisse sur la machine virtuelle Appliance, créez une seconde machine virtuelle appelée et SRV de génération 1 :

De la même manière que pour la VM appliance, lancez l’installation de Windows Server 2019 sur la VM SRV :

Une fois les deux installations terminées, définissez un mot de passe pour le compte administrateur local :

Sur les 2 VMs, renseignez le mot de passe administrateur pour ouvrir une sessions Windows :

Désactivez la sécurité Internet Explorer, puis cliquez sur OK :

Depuis Internet Explorer, recherchez puis installez Edge :

Nous deux machines virtuelles sont correctement installées. La suite consiste à mettre en place l’appliance d’Azure Site Recovery.

Etape IV – Configuration Azure Site Recovery :

Retournez sur le portail Azure afin de créer le Coffre de restauration (Azure Recovery Vault) :

Renseignez les informations de base de votre Coffre de restauration, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de Coffre de restauration, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez-ici pour commencer la configuration de Coffre de restauration :

Préparer l’infrastructure on-premise en cliquant ici :

Cliquez sur le lien suivant afin d’ouvrir la documentation Microsoft :

Copiez le lien ci-dessous (ou ici) afin de télécharger l’appliance dédiée à Azure Site Recovery :

Collez ce lien dans la machine virtuelle Appliance, puis attendez la fin du téléchargement :

Une fois l’archive ZIP téléchargé, ouvrez le dossier contenant celle-ci :

Avant de décompresser l’archive ZIP, débloquez celle-ci grâce à la case suivante, puis cliquez sur OK :

Lancez l’extraction dans le dossier de votre choix :

Attendez environ 3 minutes que l’archive ZIP se décompresse en totalité :

Sur la machine virtuelle Appliance, ouvrez une session PowerShell, puis positionnez-vous le dossier où l’archive ZIP a été extraite :

Lancez la commande PowerShell suivante :

.\DRInstaller.ps1

Confirmez la réponse avec Y :

Attendez environ 2 minutes que le traitement PowerShell se termine :

Vérifiez qu’aucune erreur n’a été remontée dans la fenêtre PowerShell :

Toujours sur la VM Appliance, retrouvez le dossier Software créé à la racine du disque Q afin de modifier ses propriétés :

Dans l’onglet Partage, cliquez sur le bouton Partager :

Confirmez les utilisateurs voulus, puis cliquez sur Partager :

Copiez le chemin du partage puis fermez la fenêtre de configuration du partage :

Lancez les 2 actions suivantes respectivement sur les deux VMs :

Sur la machine virtuelle Appliance, ouvrez Microsoft Azure Appliance Configuration Manager (présent sur le bureau )
Sur la machine virtuelle SRV, utilisez l’explorateur Windows pour vous rendre sur le chemin du partage activé précédemment

Sur la VM Appliance, vérifiez le bon fonctionnement réseau ainsi que les préconisations minimales, puis cliquez sur Continuer :

Attendez le contrôle de version, puis cliquez sur Continuer :

Cliquez sur Sauvegarder :

Cliquez sur Continuer :

Coller la clef précédemment présentée sur votre Coffre de restauration Azure, puis cliquez sur Login :

La fenêtre suivante s’ouvre afin que vous puissiez copier le code d’identification dans Azure :

Renseignez ce code dans la fenêtre d’authentification Azure, puis cliquez sur Suivant :

Renseignez vos identifiants Azure :

Réussissez le challenge MFA si nécessaire :

Cliquez sur Continuer afin d’autoriser la configuration avec Azure :

Vérifiez la confirmation Azure :

Attendez que l’enregistrement sur Azure se termine :

Cliquez sur Continuer :

Cochez la case suivante puis cliquez sur Continuer :

Ajoutez les informations relatives (identifiants / IP) à la machine virtuelle SRV :

Une fois ces informations renseignées, cliquez sur Continuer :

Comme indiqué, attendez jusqu’à 30 minutes que le traitement se termine :

En attendant, lancez l’installation de l’agent sur la machine virtuelle SRV disponible sur le partage réseau activé précédemment :

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

Une fois l’installation terminée, cliquez ici pour configurer l’agent :

Copiez les détails de la machine virtuelle SRV dans le bloc-notes :

Créez sur le partage réseau un fichier texte contenant les détails de la machine virtuelle SRV, collez le contenu de ce fichier texte sur la machine virtuelle Appliance, puis téléchargez le fichier de configuration :

Sauvegardez le fichier de configuration téléchargé précédemment sur le partage réseau, puis insérez le dans la configuration de la machine virtuelle SRV :

Lancez le traitement de configuration, puis attendez environ 1 minute :

Cliquez sur terminer une fois tous les voyants au vert :

De retour sur Azure, vérifiez la bonne configuration de l’infrastructure de reprise dans le Coffre de restauration :

La configuration d’Azure Site Recovery est maintenant terminée. La prochaine étape consiste en la mise en place de la réplication vers Azure.

Etape V – Activation de la réplication :

Activez la réplication de votre VM SRV via le menu suivant :

Choisissez votre VM SRV dans la liste des machines à répliquer, puis cliquez sur Suivant :

Cliquez sur Suivant :

Renseignez tous les champs ci-dessous, puis cliquez sur Suivant :

Activez la réplication Azure :

Une première notification Azure apparaît pour vous signaler la mise en place des ressources :

Puis une seconde notification Azure apparaît pour vous indiquer le démarrage de la réplication de votre VM SRV :

Un clic sur cette notification nous affiche toutes les étapes et travaux réalisés au sein du Coffre de restauration :

Environ 10 minutes, une nouvelle notification nous indique le succès de la configuration de réplication :

Cliquez ici pour suivre l’avancement de la réplication des données vers Azure :

La machine virtuelle SRV est maintenant répliquée dans Azure. Nous allons maintenant pouvoir tester la réplication ASR via la fonction de bascule (failover).

Etape VI – Test de la réplication :

Environ 45 minutes après, la machine virtuelle SRV est enfin répliquée dans Azure et son statut change en Protégée :

Consultez les informations dont le RPO :

Consultez le schéma complet de réplication ASR :

Vérifiez et modifiez ci-dessous les informations VM et réseau :

Vérifiez et modifiez ci-dessous les informations des disques :

De retour sur la machine virtuelle SRV, créez un fichier image, puis enregistrez-le sur le bureau :

Attendez environ 10 minutes, puis lancez l’opération de bascule vers Azure :

Cochez la case suivante, plus cliquez-ici :

Confirmez votre action en cliquant ici :

Une nouvelle notification Azure apparaît pour vous indiquer la création de la machine virtuelle SRV dans Azure :

Consultez le nouveau groupe de ressources Azure créé pour la réplication :

Attendez la seconde notification Azure vous indiquant le succès du traitement de bascule :

Rafraichissez la page du groupe de ressources créé par ASR afin de constate la présence de la nouvelle machine virtuelle SRV :

Vérifiez la configuration CPU / Mémoire :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

Lancez le script PowerShell suivant afin d’activer le service de bureau à distance :

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Environ 30 secondes plus tard, le traitement est exécuté avec succès :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les mêmes identifiants administrateurs :

Réouvrez le fichier image créé précédemment avant la bascule :

Conclusion :

Malgré une mise en place un peu longue et des exigences de puissance CPU / Mémoire concernant la machine virtuelle appliance, la mise en place d’Azure Site Recovery a bien fonctionné. Que demandez de plus 😎🥳

❄️Faites hiberner vos VMs ⛄

Peu importe l’architecture IT choisie, celle-ci coûtera toujours « trop cher » aux yeux de clients potentiels. Le Cloud n’échappe pas à cette règle, et demande donc tous les efforts possibles pour maitriser au mieux les coûts des ressources déployées. Microsoft annonce en préversion publique une fonctionnalité dédiée à la mise en veille des machine virtuelles : l’hibernation.

Qu’est-ce que l’hibernation ?

Hibernation : état d’hypothermie régulée, durant plusieurs jours ou semaines qui permet aux animaux de conserver leur énergie pendant l’hiver. Durant l’hibernation, les animaux ralentissent leur métabolisme jusqu’à des niveaux très bas, abaissant graduellement la température de leur corps et leur taux respiratoire, et puisent dans les réserves de graisse du corps qui ont été stockées pendant les mois actifs.
Wikipedia

Azure voit les VMs de la même manière que les mammifères 🤣:

Lorsqu’on hiberne une VM Azure : ce dernier échange avec l’OS afin de stocker le contenu de la mémoire de la VM sur le disque du système d’exploitation, puis désalloue la VM.
Lorsque la VM est redémarrée et sort d’hibernation : le contenu de la mémoire est retransféré du disque OS vers la mémoire. Cela permet alors de retrouver les applications et processus en cours d’exécution.

Combien coûte une machine virtuelle démarrée ?

Pour rappel, les coûts d’une machine virtuelle avaient déjà été détaillés dans cet article : Comprenez les coûts d’une ressource Azure.

En quelques lignes, une machine virtuelle allumée regroupe les principaux coûts suivants :

Le Calcul (CPU/Mémoire): le coût du service calcul va dépendre de sa taille, donc de sa technologie, de son nombre de coeurs et de sa taille de mémoire.
Le Stockage (Disques): Bien souvent, de l’information a besoin d’être stockée dans une architecture. Qu’elle soit utilisée par le service de calcul, mise à disposition pour des accès externes ou pour des besoins de sauvegarde, le stockage disposera généralement de 3 variables : taille (Go; To), débit (Mo/sec; Go/sec) et puissance transactionnelle (IOPS).
Le Réseau (Carte réseau): Une VM Azure a besoin de communiquer avec des utilisateurs ou d’autres ressources IT. Comme pour le stockage, la tarification réseau repose sur des variables : taille de la bande passante et le volume de données en transition.
La licence logicielle (OS): Là encore, la VM Azure sera souvent exploitée par un système d’exploitation et/ou logiciel, dont certains fonctionnent sous licence payante. Dans l’exemple des licences Microsoft, comme Windows Server ou SQL Server, la tarification Azure repose sur la taille du service de calcul, comme le nombre de coeurs des machines virtuelles.

Combien coûte une machine virtuelle éteinte ?

Une machine virtuelle même si les ressources sont désallouées coûte toujours :

Le Stockage (Disques) est une resource constamment allouée.
Le Réseau (Carte réseau): certaines ressources, comme les adresses IP publiques, peuvent être constamment allouées.

Combien coûte une machine virtuelle en hibernation ?

De la même manière que dans un état désalloué, la machine virtuelle continuera de coûter pour le stockage utilisé par les disques et aussi certaines ressources réseaux.

Pourquoi utiliser l’hibernation au lieu d’éteindre la VM ?

Microsoft nous détaille des scénarios envisageables pour ce mode Pause :

Les postes de travail virtuels, le développement/test et d’autres scénarios où les machines virtuelles n’ont pas besoin de fonctionner 24 heures sur 24 et 7 jours sur 7. Les systèmes dont les temps de démarrage sont longs en raison d’applications gourmandes en mémoire.
Microsoft Learn

Quelles sont les VMs compatibles avec le mode Hibernation ?

Plusieurs limitations à l’hibernation sont ainsi actuellement en vigueur, et vont certainement évoluer par la suite :

Ne s’active pas sur des VMs déjà déployées
Aucun redimensionnement SKU possible sur des VMs ayant la fonctionnalité hibernation
Fonction d’hibernation est non désactivable après l’activation
Limitations de compatibilité selon l’OS :
- Linux (dépourvue de Trusted Lunch) :
  - Ubuntu 22.04 LTS
  - Ubuntu 20.04 LTS
  - Ubuntu 18.04 LTS
  - Debian 11
  - Debian 10 selon noyau
- Windows (page file hors disque D):
  - Windows Server 2022
  - Windows Server 2019
  - Windows 10/11 (Pro / Enterprise / multisession)
Uniquement certains SKUs supportent actuellement l’hibernation :
- Dasv5-series
- Dadsv5-series
- Dsv5-series
- Ddsv5-series

Important : Comme pour une VM désallouée, le risque est toujours présent lors du redémarrage si la VM hibernée, car elle nécessite des ressources potentiellement non disponibles à l’instant T.

Afin de se faire une meilleure idée sur l’hibernation d’Azure, je vous propose de réaliser un petit exercice combinant 2 exemples de VMs. Nous allons détailler toutes les étapes nécessaires, de la configuration aux tests :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur l’hibernation de machines virtuelles Azure, il vous faudra disposer des éléments suivants :

Un tenant Microsoft
Une souscription Azure valide

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

Avant de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’activer cette dernière sur la souscription Azure concernée.

Pour cela, rendez-vous dans le portail Azure, sur la page des fonctionnalités en préversion de votre souscription, puis effectuez une activation en recherchant celle-ci comme ci-dessous :

Attendez environ une minute que votre demande soit acceptée par Microsoft :

La notification suivante vous indique alors le succès de l’opération :

La suite consiste maintenant à créer une première machine virtuelle compatible et avec l’hibernation activée.

Etape II – Création d’une machine virtuelle compatible :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant bien une image OS Windows 11 Pro, puis cliquez ici pour afficher les tailles de VMs :

Choisissez la taille de votre VM parmi l’une des séries suivantes :

Dasv5-series
Dadsv5-series
Dsv5-series
Ddsv5-series

Si la case d’hibernation est toujours grisée, attendez encore 10-20 minutes avant de retenter l’opération de création :

Si la case d’hibernation est disponible, cochez celle-ci, définissez un compte administrateur local, bloquer les ports entrants, cochez la case concernant le droit de licence, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 3 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Consultez l’extension automatiquement installée sur votre VM pour rendre fonctionnel l’Hibernation d’Azure :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :

La notification suivante vous indique alors le succès de la création d’Azure Bastion :

Notre première machine virtuelle est enfin prête. Afin de bien mesurer l’impact de l’hibernation d’Azure, connectons-nous à la VM pour y ouvrir différents programmes.

Etape III – Test de l’hibernation :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Attendez que la session Windows 11 s’ouvre avec le compte local :

Cliquez sur Suivant :

Cliquez sur Accepter :

Ouvrez plusieurs applications sans enregistrer les travails effectués :

Rendez-vous sur la page Azure de votre machine virtuelle, puis cliquez sur Hiberner :

Confirmez votre choix en cliquant sur Oui :

Attendez environ 1 minute :

La session ouverte via Bastion se retrouve alors automatiquement déconnectée, cliquez sur Fermer :

La notification suivante vous indique alors le succès de l’opération d’hibernation :

Un nouveau statut apparaît alors sur votre première machine virtuelle :

Afin de redémarrer la première VM, cliquez-ici :

Attendez environ 1 minute que la première VM soit redémarrée :

Réouvrez à nouveau une session via Azure Bastion avec les mêmes identifiants :

Constatez la réapparition des applications ouvertes avec les travails non enregistrés :

Cette première étape nous montre la facilité de mise en place de l’hibernation et l’intérêt potentiel pour les charges de travail variables ou discontinues.

Continuons cet exercice avec une seconde machine virtuelle créée cette fois-ci sans l’option d’hibernation.

Etape IV – Création d’une machine virtuelle incompatible :

Renseignez les informations de base relatives à votre seconde VM en choisissant bien une image OS Windows 11 Pro, puis en ne cochant pas la case hibernation :

Une fois la seconde VM créée, vérifiez que la fonction Hiberner est bien grisée pour celle-ci :

Ouvrez la page Azure du disque OS de celle-ci afin de créer un snapshot de ce dernier :

Renseignez les informations de base relatives à votre snapshot, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour consulter le snapshot de votre disque :

Cliquez-ici pour créer un nouveau disque OS à partir de ce snapshot :

Renseignez les informations de base relatives à ce nouveau disque OS, puis lancez la validation Azure :

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

Continuons avec une troisième machine virtuelle créée cette fois-là avec l’option d’hibernation :

Arrêtez cette troisième machine virtuelle via la fonction d’arrêt :

Confirmez votre choix en cliquant sur Oui :

Toujours sur cette troisième VM, allez sur la page des disques afin de basculer vers le disque précédemment généré depuis le snapshot de la seconde VM :

Choisissez le seul disque disponible et issu du snapshot, puis cliquez sur OK :

La notification suivante vous indique alors le succès de l’opération de bascule des disques OS :

Redémarrer la troisième machine virtuelle Azure :

Une fois redémarrée, vérifiez la présence de la fonctionnalité Hiberner :

Consultez l’extension installée sur votre troisième VM :

Afin de vérifier que l’hibernation Azure fonctionne bien sur cette nouvelle VM issue du snapshot de la seconde, connectons-nous à celle-ci pour y ouvrir différents programmes.

Etape V – Test de l’hibernation :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la seconde VM :

Attendez que la session Windows 11 s’ouvre avec le compte local :

Cliquez sur Suivant :

Cliquez sur Accepter :

Ouvrez une ou plusieurs applications sans enregistrer les travails effectués :

De retour sur la page Azure de votre troisième machine virtuelle, puis cliquez sur Hiberner :

Confirmez votre choix en cliquant sur Oui :

Encore une fois, la session ouverte via Bastion se retrouve automatiquement déconnectée, cliquez sur Fermer :

La notification suivante vous indique alors le succès de l’opération d’hibernation :

Le statut apparaît alors sur votre troisième machine virtuelle, cliquez-ici afin de la redémarrer :

Attendez environ 1 minute que la VM soit redémarrée :

Réouvrez à nouveau une session via Azure Bastion avec les mêmes identifiants :

Constatez là encore la réapparition des applications ouvertes et les travails non enregistrés :

Conclusion

La fonction d’hibernation marque ici une vraie différence dans la gestion offline de machine virtuelle. Plus pratique que l’arrêt complet dans bon nombre de situations, l’hibernation pourrait devenir la norme en s’intégrant de la manière native dans beaucoup de service Azure, comme les groupe de machines virtuelles identiques ou encore Azure Virtual Desktop.

Attendons de voir la suite 😎💪

Azure Virtual Desktop + GPU = 🏎️

Cela faisait longtemps que je voulais tester une machine virtuelle disposant d’une carte graphique puissante dans un environnement Azure Virtual Desktop. Il arrive que des besoins graphiques soient présents dans certains projets. Il est actuellement impossible de les satisfaire via Windows 365, mais Azure Virtual Desktop ne dit pas son dernier mot ! Presque tous les types de machine virtuelles Azure y sont disponibles.

Commençons par quelques rappels qui ne nous feront pas de mal 😎

Qu’est-ce qu’une machine virtuelle Azure ?

Vous pouvez lire mon article dédié aux VMs Azure ou regarder cette vidéo en français :

Qu’est-ce qu’une machine virtuelle GPU Azure ?

L’idée est la même que pour une machine virtuelle classique, avec en plus une ou plusieurs cartes graphiques adaptées selon les besoins des utilisateurs :

Les tailles de machine virtuelle au GPU optimisé sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples ou fractionnaires. Ces tailles sont conçues pour des charges de travail de visualisation, mais également de calcul et d’affichage graphique intensifs.
Microsoft Learn

Quels sont les GPUs disponibles sur Azure ?

Comme pour les autres machines virtuelles, les VM avec GPU sont organisées sous forme de séries, dont voici quelques exemples :

Peut-on créer une machine virtuelle GPU dans toutes les régions Azure ?

Malheureusement non, certaines régions ne disposent pas de VMs GPU, ou seulement certains SKUs y sont disponibles :

Pour nous aider, Microsoft a mis à disposition une page de documentation dédiée aux VMs GPU sous Azure Virtual Desktop. Plusieurs sujets y sont justement abordés :

Comme bien souvent, Dean Cefola de l’Azure Academy a lui-aussi posté il y a quelques années une vidéo YouTube parlant de ce sujet très intéressant :

Afin de se faire une meilleure idée sur le rendu possible de l’ensemble GPU + AVD, je vous propose de réaliser un petit exercice combinant ces 2 services. Nous allons détailler toutes les étapes nécessaires de la configuration aux tests de plusieurs applications :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les VMs GPU via Azure Virtual Desktop, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Note importante : pour effectuer des tests GPU sur Azure, une souscription MSDN ne sera pas acceptée.

En effet, les machines virtuelles graphiques sont restreintes et le Support de Microsoft n’a pas souhaité octroyer des quotas sur ma souscription Azure MSDN. J’ai donc utilisé une souscription Azure payante pour réaliser ces tests GPU.

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

Comme indiqué précédemment, les souscriptions Azure sont restreintes dans la création de machines virtuelles dédiées aux besoins graphiques :

Cela est permet d’éviter un engorgement inutile de ces VMs très spécifiques, mais également les mauvaises surprises au moment de recevoir la facture Azure.

Il est donc nécessaire de relever le quota d’une des séries de VMs GPU pour réaliser cet exercice. Dans mon cas, je suis parti sur la série Standard NCASv3_T4.

Pour cela, rendez-vous dans le portail Azure, puis sur la page des quotas de votre souscription Azure, puis effectuez une demande d’élévation des quotas, en cliquant à droite sur la série de VMs de votre choix :

*8 vCPU me semblent suffisant pour créer une ou deux petites machines virtuelles GPU.*

Attendez environ une minute que votre demande soit acceptée par l’IA de Microsoft :

Nous voici maintenant autorisé à créer 2 VMs GPU Standard NC4as T4 v3, équipées chacune d’un processeur AMD EPYC 7V12 et d’une carte graphique NVIDIA Tesla T4.

Continuons maintenant à créer une première VM GPU dans le but de préparer une image modèle pour Azure Virtual Desktop.

Etape II – Création d’une machine virtuelle GPU :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant bien une image OS Windows 11 en version 22H2 :

Choisissez la taille Standard NC4as T4 v3, puis définissez un compte administrateur local :

Bloquer les ports entrants, car nous utiliserons le service Azure Bastion, cochez la case concernant le droit de licence, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources de la VM GPU, puis attendez environ 5 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle GPU :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

*Voici un lien vers l’article dédié à Azure Bastion.*

Attendez environ 5 minutes qu’Azure Bastion soit déployé pour continuer cet exercice :

Une fois qu’Azure Bastion a fini son déploiement, ouvrez une session de bureau à distance via ce dernier en utilisant les identifiants administrateurs renseignés lors de la création de la VM GPU :

Cliquez sur Suivant :

Cliquez sur Accepter :

La machine virtuelle est enfin déployée et accessible. Intéressons-nous maintenant à la configuration additionnelle que requière une VM GPU.

Etape III – Post-configuration GPU 1/2 :

Pour que la carte graphique soit pleinement exploitée, il est nécessaire d’installer un pilote adapté. Microsoft en parle juste ici.

Par un clic droit sur le menu Démarrer, ouvrez le Gestionnaire des périphériques Windows :

Notez l’absence de la carte NVIDIA Tesla T4, et la présence d’une carte graphique encore non identifiée dans les autres périphériques :

Comme Microsoft le propose dans sa documentation, Azure propose d’installer un pilote adapté à votre carte graphique au travers d’une extension à votre machine virtuelle :

Les extensions de machines virtuelles Azure sont de petites applications qui permettent de configurer les machines virtuelles après leur déploiement.
Microsoft Learn

Dans notre cas, l’extension de pilote GPU NVIDIA pour Windows installera les pilotes GPU appropriés à votre NVIDIA Tesla T4.

Pour installer cette extension, rendez-vous sur le menu suivant de votre machine virtuelle, puis cliquez sur Ajouter :

Choisissez dans la liste le pilote GPU dédié aux cartes graphiques NVIDIA :

Lancez la validation Azure :

Une fois la validation Azure réussie, lancez l’installation de l’extension :

Attendez environ 1 minute :

Une fois le déploiement terminé, cliquez-ici :

Constatez le bon provisionnement de votre extension GPU NVIDIA :

Retrouvez cette même information sur la page de votre machine virtuelle Azure :

Retournez sur le Gestionnaire des périphériques Windows afin de constater le changement :

Notez malgré tout la date assez ancienne du pilote de la carte graphique NVIDIA :

Ouvrez également le Gestionnaire des tâches Windows afin de constater l’absence de métriques dédiés au GPU :

Il semble assez évident que l’extension disponible sur Azure n’est pas des plus à jour pour poursuivre, et risque peut-être même de dégrader les performances lors des tests.

Aussi je vous propose de lire la page suivante de la documentation Microsoft et concernant l’installation des pilotes sur les machines virtuelles graphiques hébergées sur Azure :

Sur cette page, il en ressort que la carte graphique Standard NC4as T4 v3 supporte elle-aussi le pilote GRID en version 16.1, compatible Windows 11 et facilement téléchargeable par ce lien.

Une fois téléchargé sur votre VM GPU, ouvrez l’installeur du pilote GRID :

Confirmez le dossier de décompression au niveau local :

Attendez environ 30 secondes que la décompression se termine :

L’installation du Pilote GRID démarre alors automatiquement :

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

Cliquez sur Suivant :

Constatez la suppression des pilotes NVIDIA apportée par l’extension de machine virtuelle :

Attendez environ 2 minutes que l’installation se termine :

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

Rouvrez le Gestionnaire des tâches Windows afin de constater l’apparition d’une section GPU :

Rouvrez le Gestionnaire des périphériques Windows afin de constater le changement de la date du pilote de la carte graphique NVIDIA Tesla T4 :

L’utilitaire nvidia-smi nous confirme les mêmes informations :

La première partie de la configuration GPU est enfin terminée. D’autres optimisations déjà rappelées sur cette page Microsoft doivent également être mise en place pour une bonne prise en charge de la session de bureau à distance.

Etape IV – Installation d’applications de test :

Afin d’effectuer quelques tests graphiques, je vous propose d’installer 2 applications sur votre image AVD :

AutoCAD : logiciel de conception assistée par ordinateur en 2D et 3D payant, mais disponible en version d’essai juste ici. La création d’un compte est nécessaire chez AutoDesk pour obtenir cette version d’essai.
FurMark : logiciel de stress-test léger mais très intensif pour les cartes graphiques et les GPU sur la plate-forme Windows.

Installation d’AutoCAD :

Une fois sur la page web des essais, cliquez-ici pour définir une utilisation personnelle d’AutoCAD, puis cliquez sur Suivant :

Choisissez la version d’AutoCAD souhaitée, puis cliquez sur Suivant :

Ouvrez l’installateur web téléchargé par le ce lien :

Attendez environ 30 secondes que la décompression se termine :

L’installation d’AutoCAD s’ouvre alors :

Définissez le dossier d’installation d’AutoCAD, puis cliquez sur Installation :

Attendez environ 10 minutes le temps qu’AutoCAD s’installe sur votre machine virtuelle :

Une fois l’installation correctement terminée, cliquez-ici pour fermer le programme :

Installation de FurMark :

Continuer avec l’installation de FurMark, disponible sur cette page :

Cliquez-ici pour lancer l’installation de FurMark :

Une fois l’installation terminée, décochez les cases, puis cliquez sur Terminer :

Notre image AVD est maintenant terminée. Il ne nous reste plus qu’à Généraliser notre machine virtuelle afin de pouvoir l’importer dans Azure Virtual Desktop.

Etape V – Préparation du modèle AVD :

Pour cela, lancez la commande Sysprep :

Ouvrez le programme Sysprep :

Configurez-le comme ceci, puis cliquez sur OK :

Attendez que Sysprep commence le travail de nettoyage :

Constatez la fermeture de la session de bureau à distance ouverte via Azure Bastion, puis cliquez sur Fermer :

Une fois la machine virtuelle en statut Arrêtée, cliquer sur Arrêter afin d’en changer le statut en Arrêtée (désallouée) :

Confirmez votre action en cliquant sur Oui :

Attendez que le traitement d’arrêt complet se termine pour que le statut de la VM GPU change :

Cliquez sur Capturer pour créer une image de votre machine virtuelle modèle :

Configurez les options de capture comme ceci :

Définissez toutes les informations relatives à la version de votre image juste ici, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création d’image de la VM :

Attendez environ 10 minutes que le traitement se termine :

Notre image Windows 11 customisée est enfin prête :

Etape VI – 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 :

Définissez les options de base de votre environnement AVD, puis cliquez sur Suivant :

Ajoutez une VM GPU AVD, puis choisissez dans la liste des OS l’image créée précédemment :

Réutilisez la même taille de VM GPU que celle précédemment utilisée :

Joignez votre VM GPU AVD à Entra ID et à Intune, 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 entièrement terminé, cliquez-ici pour continuer sa configuration :

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

Afin d’économiser sur la consommation Azure, ajoutez un scaling plan qui pilotera la VM GPU AVD selon les besoins de connexion :

Donnez-lui un nom, placez-le dans la même région Azure que votre pool d’hôtes AVD, puis cliquez sur Suivant :

Ajoutez un ou plusieurs plannings selon vos besoins, sachant qu’une journée de la semaine ne peut être présent que dans un seul planning

Sélectionnez les jours de la semaine correspondant à vos besoins, puis cliquez sur Suivant :

L’onglet suivant reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs ci-dessous, puis de cliquer sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Ajouter :

Ajoutez si-besoin un second calendrier pour les autres jours, puis cliquez sur Suivant :

Rattachez votre pool d’hôtes à la configuration en n’oubliant pas de cocher la case pour l’activer, puis cliquez ici pour lancer la validation Azure :

Une fois la validation Azure réussie, cliquez sur Créer pour valider la configuration :

Rajoutez les rôles RBAC suivants au niveau du groupe de ressources Azure contenant votre environnement AVD :

Permettre à Azure Virtual Desktop de pouvoir allumer et éteindre les VMs AVD
Permettre à notre utilisateur de test de voir l’espace de travail AVD
Permettre à notre utilisateur de test d’ouvrir une session Windows AVD

La suite de la configuration GPU peut s’effectuer via une configuration poussée par Intune.

Etape VII – Post-configuration GPU 2/2 :

D’autres configurations sont nécessaires sur les VM GPU AVD pour que la session Windows ouverte via le protocole RDP tire pleinement partie des performances GPU.

Dans le cas d’un Azure Virtual Desktop sous Windows 11, nous devons nous intéresser aux 2 configurations suivantes :

Nous pouvons très facilement terminer cette configuration via la mise en place d’un profil de configuration Intune. Pour cela, nous avons besoin de créer un groupe Entra ID pour affecter le profil de configuration GPU à notre VM AVD GPU :

Continuons sur le portail Intune pour créer notre profil de configuration Windows, cliquez sur Créer une nouvelle Police :

Continuez comme ceci :

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

Cliquez sur Ajouter un paramètre :

Rechercher les 2 paramètres GPU suivants :

Ajoutez également ce troisième paramètre GPU suivant :

Activez ces 3 paramètres comme ceci :

Cliquez sur Suivant :

Ajoutez le groupe Entra ID contenant votre VM GPU AVD, puis cliquez sur Suivant :

Terminez la création de votre police de configuration.

Retournez sur la VM GPU AVD, puis lancez une synchronisation forcée pour accélérer le déploiement du profil de configuration :

Environ 15 à 30 minutes plus tard, la police de configuration GPU créée sur Intune apparaît bien comme installée sur la VM GPU AVD :

La configuration GPU est maintenant en place, il ne nous reste maintenant qu’à tout vérifier sur la VM GPU AVD grâce à notre utilisateur de test.

Etape VIII – Vérification de la configuration GPU :

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 :

Authentifiez-vous encore une fois avec un compte AVD de test :

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

Microsoft nous explique ici comment vérifier les configurations appliquées depuis Intune :

Pour cela, ouvrez le Journal des évènements présent sous Windows :

Recherchez le journal suivant :

Journaux des applications et services
- Microsoft
  - Windows
    - RemoteDesktopServices-RdpCoreCDV
      - Opérationnel

Constatez la bonne présence des 2 ID suivants :

162 : L’encodeur matériel AVC est bien activé
170 : La session de bureau à distance utilise bien l’encodage vidéo plein écran (AVC 444)

La fonctionnalité UDP a été déployée sur l’ensemble des environnements AVD (L’impact du protocole dans un environnement dédié au bureau à distance est majeur) :

Tout semble maintenant en ordre, il nous reste qu’à tester les performances GPU via différents outils, comme par exemple :

AutoCAD
FurMark
Clipchamp

Etape IX – Test AutoCAD :

Ayant installé AutoCAD dans l’image AVD, il ne nous reste plus qu’à trouver des exemples de fichiers. Plusieurs sites en proposent, dont le site AutoDesk :

Une fois téléchargé, l’ouverture du fichier se fait assez facilement dans AutoCAD :

La navigation 3D se fait de manière très fluide sans aucune saccade gênante :

Continuons les tests avec FurMark.

Etape X – Test FurMark :

FurMark propose toutes sortes de benchmarks. Un test de 10 minutes montre bien la montée en charge et en température de la carte NVIDIA Tesla T4 :

Finissons les tests applicatifs avec Clipchamp.

Etape XI – Test Clipchamp :

En juillet 2023, Microsoft avait été annoncé via un post sur leur blog l’intégration de Clipchamp dans la suite Microsoft 365. Voici une courte vidéo d’introduction :

Vous trouverez Clipchamp depuis la page d’accueil des applications 365 :

Je me suis amusé à construire une petite vidéo et j’ai joué avec quelques fonctionnalités très sympa, sans avoir ressenti de latence durant les manipulations :

D’autres tests seront à prévoir selon les applications voulues.

Etape XII – Arrêt automatique de la VM GPU AVD :

Depuis juillet 2023, Azure Virtual Desktop continue d’évoluer et propose l’arrêt automatique des VMs pour les environnements individuels. Un article avait déjà été écrit sur le sujet juste ici.

Cette approche est particulièrement intéressante pour les machine virtuelles avec GPU quand les besoins sont ponctuels et limités.

La mise à l’échelle automatique pour notre pool d’hôtes AVD étant déjà configuré, il nous reste qu’à fermer la session de notre utilisateur de test AVD :

Environ 15 minutes plus tard, le statut de la VM AVD GPU change bien en désalloué, ce qui confirme bien le fonctionnement complet du Start and Stop dans notre environnement de test :

Comme le journal d’activités Windows le montre, l’arrêt de la machine virtuel est bien provoqué par Azure Virtual Desktop :

Conclusion :

Je souhaite commencer ma conclusion par la satisfaction personnelle d’avoir écrit cet article, qui me trottait dans la tête depuis plusieurs mois déjà 🤣. Je suis également très content des performances obtenues et du bon ressentit utilisateur quand il s’agit de besoins graphiques exigeants.

Nul doute que cela ne remplacera pas à 100% les machines graphiques locales, mais la disponibilité, la flexibilité et la sécurité du Cloud sont de vrais arguments au moment du remplacement d’un parc de machines avec GPU.

Updatez vos VMs vers Windows Server 2022

La date 10 octobre 2023 arrive à grand pas ! Non ce n’est pas l’anniversaire d’un de vos proche que vous auriez oublié … mais bien la Fin de support programmée pour Windows Server 2012 et 2012R2. A partir de cette date, plus aucune mise à jour de sécurité ne sera disponible sans l’achat des ESUs (Extended Security Updates), ou suite à une migration vers Azure ou Azure Stack HCI (solution de Cloud hybride proposé par Microsoft). 😥😥

Years

Months

Pour continuer de plomber l’ambiance, voici d’ailleurs le calendrier des échéances passées et futures :

Que peut-on faire dans ce cas ?

Comme déjà indiqué dans cet article, plusieurs solutions s’offrent déjà à vous :

Migrer vers une nouvelle version Windows ou SQL plus récente.
Acheter les Mises à jour de sécurité étendue (ESUs).
Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.

Un article dédié aux ESUs devrait arriver sous peu, tandis que 2 autres concernant la migration vers Azure existent déjà :

Il nous reste donc à parler de la mise à jour de l’OS lui-même. Cela tombe bien, car Dean Cefola de l’Azure Academy vient justement de publier une vidéo traitant de ce sujet :

Important : Bien évidement, les opérations décrites dans cette vidéo et dans mon article ne concernent que la seule mise à jour de l’OS. Il est certain que tous les projets comporteront éventuellement une migration vers le Cloud, mais également d’innombrable tests de compatibilité pour les applications déjà en place.

Aussi, je vous propose dans cet article de vous intéresser aux différentes méthodes de mise à jour possibles et décrites par Dean. Voici les grandes étapes de cet exercice :

Ces étapes sont également disponibles dans l’article de Microsoft Learn :

Une mise à niveau sur place vous permet de passer d’un ancien système d’exploitation à un plus récent, tout en conservant inchangés vos paramètres, vos rôles serveur et vos données. Cet article vous explique comment faire passer vos machines virtuelles Azure à une version ultérieure de Windows Server en utilisant une mise à niveau sur place.
Microsoft Learn

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la mise à jour vers Windows Server 2022, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Je vous propose de créer plusieurs machines virtuelles dans le but de réaliser 4 tests :

Etape I – Création de l’environnement de test :

Pour cela, commencez par déployer une première machine virtuelle sur Azure. Rendez-vous sur le portail d’Azure, puis utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien une image Windows Server 2012 R2 :

Définissez un compte administrateur local, bloquer les ports entrants (nous utiliserons le service Azure Bastion), puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

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

Sans attendre que le déploiement soit entièrement terminé, il vous est possible, depuis le réseau virtuel Azure de déployer le service Azure Bastion :

Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice :

Continuez en déployant 3 autres machines virtuelles Azure afin de pouvoir effectuer les 4 tests. Vous devriez avoir les VMs suivantes :

Windows Server 2012R2 x 3
Windows Server 2016 x 1

Notre environnement de départ est maintenant en place, nous allons pouvoir préparer nos VMs à installer la mise à jour OS Windows Server 2012.

Etape II – Sauvegarde et Préparation :

Mais avant cela, il est vivement conseillé de faire une sauvegarde. Depuis la machine virtuelle de votre choix, il est facile de faire une sauvegarde d’un disque via la fonction Snapshot.

Pour cela, recherchez le disque OS d’une VM de test, puis cliquez dessus :

Sur ce disque OS, cliquez-ici pour créer un snapshot de celui-ci :

Donnez-lui un nom et une performance, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du snapshot de la VM, puis attendez environ 30 secondes :

Le snapshot est maintenant visible comme un élément indépendant de la machine virtuelle Azure. Nous nous en servirons plus tard dans le cadre d’une restauration vers Windows Server 2012R2 :

Comme le rappelle la documentation Microsoft, la mise à niveau sur place nécessite l’ajout d’un second disque contenant les éléments d’installation.

Depuis le portail Azure, cliquez sur Azure Cloud Shell, puis configurez-le à votre guise :

Une fois Azure Cloud Shell démarré en mode PowerShell, lancez le script ci-dessous en prenant soin de modifier si besoin le groupe de ressources et la région Azure :

#
# Customer specific parameters 

# Resource group of the source VM
$resourceGroup = "vmmigrate-rg"

# Location of the source VM
$location = "WestEurope"

# Zone of the source VM, if any
$zone = "" 

# Disk name for the that will be created
$diskName = "WindowsServer2022UpgradeDisk"

# Target version for the upgrade - must be either server2022Upgrade or server2019Upgrade
$sku = "server2022Upgrade"


# Common parameters

$publisher = "MicrosoftWindowsServer"
$offer = "WindowsServerUpgrade"
$managedDiskSKU = "StandardSSD_LRS"

#
# Get the latest version of the special (hidden) VM Image from the Azure Marketplace

$versions = Get-AzVMImage -PublisherName $publisher -Location $location -Offer $offer -Skus $sku | sort-object -Descending {[version] $_.Version	}
$latestString = $versions[0].Version


# Get the special (hidden) VM Image from the Azure Marketplace by version - the image is used to create a disk to upgrade to the new version


$image = Get-AzVMImage -Location $location `
                       -PublisherName $publisher `
                       -Offer $offer `
                       -Skus $sku `
                       -Version $latestString

#
# Create Resource Group if it doesn't exist
#

if (-not (Get-AzResourceGroup -Name $resourceGroup -ErrorAction SilentlyContinue)) {
    New-AzResourceGroup -Name $resourceGroup -Location $location    
}

#
# Create Managed Disk from LUN 0
#

if ($zone){
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
                                   -CreateOption FromImage `
                                   -Zone $zone `
                                   -Location $location
} else {
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
                                   -CreateOption FromImage `
                                   -Location $location
} 

Set-AzDiskImageReference -Disk $diskConfig -Id $image.Id -Lun 0

New-AzDisk -ResourceGroupName $resourceGroup `
           -DiskName $diskName `
           -Disk $diskConfig

Note : J’ai également modifié le script de Microsoft pour créer le disque en Standard SSD et non en Standard HDD. Cela me permet d’activer la fonction de disque partagé pour pouvoir l’utiliser en simultané sur 3 VMs maximum :

Lancez le script, attendez environ 30 secondes, puis constatez le succès de déploiement de celui-ci :

Sur ce nouveau disque, activez la fonction de disque partagé afin de l’utiliser sur plusieurs VMs :

Retournez sur votre première machine virtuelle afin de l’ajouter en tant que disque de données, puis cliquez sur Appliquer :

Faites-en de même pour une seconde machine virtuelle :

Enfin, faites-en de même pour une troisième machine virtuelle :

Nos 3 premières virtuelles sous Windows Server 2012R2 sont enfin prêtes. Il ne nous reste qu’à lancez les installations de Windows Server 2022 sous différentes formes.

Etape III – Tests d’installation sur place de Windows Server 2022 :

Test A – Windows Server 2012R2 + Installation GUI :

Commençons par l’installation depuis l’interface GUI.

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Constatez la présence du disque F, correspondant au média d’installation de Windows Server 2022 :

Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable

Attendez environ 1 minute que l’installation se mette en route :

L’installation passe en revue la configuration de votre machine virtuelle :

Attendez encore une fois une minute environ :

Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :

Attendez encore une fois une minute environ :

L’installation se poursuit en vous avertissant de redémarrages possibles :

L’utilisateur est naturellement déconnecté durant la suite du processus de mise à jour :

Cliquez sur Reconnecter et attendez environ 15 bonnes minutes que l’installation se termine :

Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre première machine virtuelle est bien mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un second cas de mise à jour lancée depuis le portail Azure.

Test B – Windows Server 2012R2 + Installation via Azure Run Command :

Sur votre seconde machine virtuelle de test, rendez-vous dans le menu suivant :

Lancez la commande suivante, puis cliquez sur Exécuter :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet

Attendez environ 15 minutes, sans vous fier au statut Complet de l’écran ci-dessous :

Suivez si besoin la charge CPU de votre VM depuis la fenêtre des métriques :

Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre seconde machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un troisième cas de mise à jour lancée depuis une extension de machine virtuelle.

Test C – Windows Server 2012R2 + Installation via Virtual Machine Extension :

Préparer localement un fichier de script PS1 avec le code suivant :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet

Sur votre troisième machine virtuelle de test, rendez-vous dans le menu suivant :

Choisissez Custom Script Extension, puis cliquez sur Suivant :

Cliquez-ici :

Choisissez le compte de stockage utilisé pour Azure Cloud Shell :

Créez un nouveau conteneur pour le stockage objet :

Nommez-le, puis cliquez sur Créer :

Téléversez votre script :

Sélectionnez votre script :

Cliquez-ici :

Attendez que le déploiement du script se termine :

Suivez si besoin son statut :

Environ 15 minutes plus tard, le statut du script est terminé :

Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre troisième machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un dernier cas de mise à jour lancée depuis une machine virtuelle déjà sous Windows Server 2016.

Test D – Windows Server 2016 + Installation GUI :

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable

Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :

L’installation se poursuit en vous avertissant de redémarrages possibles :

Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre machine virtuelle en 2016 est correctement mise à jour en version Windows Server 2022.

Etape IV – Retrait du disque d’installation :

Une fois l’installation terminée, il ne nous reste plus qu’à retirer le disque d’installation monté sur les machines virtuelles mises à jour :

Cliquez sur Appliquer :

Attendez quelques secondes la notification Azure :

Constatez la disparition du disque F :

Etape V – Restauration de la sauvegarde :

Dans le cas d’un bug au moment de la mise à jour ou après tout autre déconvenue, il est possible de repartir du snapshot généré avant la mise à jour.

Commencez par éteindre la machine virtuelle à restaurer :

Attendez quelques secondes la notification Azure :

Depuis le snapshot, cliquez-ici pour créer un nouveau disque OS :

Nommez-le, choisissez sa taille et sa performance, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du disque :

Retournez sur une des machines virtuelles de test, puis cliquez-ici pour intervertir les disques OS :

Choisissez le nouveau disque, puis lancez le traitement en cliquant sur OK :

Attendez quelques secondes la notification Azure :

Redémarrer la machine virtuelle restaurée :

Ouvrez une session via Azure Bastion :

Attendez la fin de chargement de session :

Constatez le retour à l’ancienne version de Windows Server depuis Server Manager :

Conclusion

Le processus de mise à jour depuis une VM déjà sur Azure vers une version plus récente de Windows Server est des plus simples. Nul doute que la mise à jour de l’OS est la partie émergée de l’iceberg. D’autres tests avant la mises à jour devront être effectués pour vérifier la bonne compatibilité des applications et des services installés.

Alertez-vous grâce à Azure Monitor

Nombreuses sont les applications critiques et, comme souvent, les équipes IT ont besoin de remontées d’alertes ou de notifications pour résoudre les interruptions de services le plus rapidement possible quand cela se produit. Mais chaque système ou application ne peuvent à eux seul être leur propre système d’alertes. C’est ici qu’intervient Azure Monitor.

*Merci à Dave pour cette idée d’article 😎*

Azure Monitor est une solution de monitoring complète qui permet de collecter et d’analyser des données de télémétrie en vue d’y répondre, à partir de vos environnements cloud et locaux.

Azure Monitor collecte et agrège les données de chaque couche et composant de votre système sur plusieurs abonnements et locataires Azure et non-Azure.
Microsoft Learn

Azure Monitor intègre aussi des règles d’alerte afin de prévenir les personnes concernées de données dépassants certains seuils ou lors d’évènements majeurs :

S’appuyer sur Azure Monitor pour constituer des mécanismes d’alertes, pour les environnements Cloud ou sur site, est une approche pertinente est simplifiera grandement la chaîne des actions correctives qui s’en suit.

Afin de tester les règles d’alerte d’Azure Monitor sur un cas concret, nous allons créer une machine virtuelle, dans laquelle nous configurons une petite tâche planifiée Windows.

La non-exécution périodique de la tâche planifiée Windows sera le vecteur d’alerte dans Azure Monitor :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les règles d’alerte d’Azure Monitor, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

La source de notre alerte sera directement configurée sur une machine virtuelle Azure.

Etape I – Déployez une machine virtuelle Azure :

Commencez par déployer une VM. Pour cela, rendez-vous sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

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

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

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

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour vous connecter à la VM :

Cliquez sur le bouton suivant pour déployer le service Azure Bastion :

Cliquez-ici pour configurer Azure Bastion :

Cliquez sur le bouton suivant pour déployer automatiquement le service Azure Bastion :

Attendez qu’Azure Bastion soit déployé pour continuer cet exercice.

Notre machine virtuelle est maintenant déployée et est accessible. Nous allons maintenant nous y connecter afin de configurer une tâche planifiée via le planificateur de tâches Windows.

Etape II – Configurez une tâche planifiée Windows :

Cette action basique va nous montrer comment une tâche planifiée exécutée localement va remonter des informations visibles directement depuis Azure Monitor.

Ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Cliquez sur Suivant pour terminer la configuration de Windows 11 :

Modifiez si besoin les options listées, puis cliquez sur Accepter :

Ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :

Créez une nouvelle Tâche planifiée :

Nommez votre Tâche planifiée, cochez les cases suivantes, puis passez sur le second onglet :

Ajoutez-y un déclencheur :

Choisissez le motif de déconnexion avec un délai de 30 minutes, ou moins si besoin, puis passez sur l’onglet suivant :

Sur l’onglet des actions, ajoutez le lancement du programme Shutdown, avec les arguments suivants :

/f /s /t 0

Validez la création de la Tâche planifiée en cliquant sur OK :

Activez l’historique des tâches planifiées afin de faire remonter l’information dans les journaux d’évènements de Windows :

Vérifiez que votre nouvelle tâche planifiée est bien présente dans la liste, et est active :

Notre environnement de départ est maintenant en place. Nous pouvons vérifier que notre tâche planifiée s’exécute correctement en :

Attendant quelques minutes que la session de bureau à distance ouverte via Azure Bastion déconnecte l’utilisateur pour cause d’inactivité.
Déconnectant directement votre utilisateur de test depuis le menu Démarrer.

Dans mon cas, j’attends que Bastion fasse le travaille à ma place :

Une fois la session déconnectée, retournez sur la liste de vos machines virtuelles Azure afin de vérifier le changement de statut de celle-ci :

Démarrez votre machine virtuelle afin de vous y reconnecter par la suite :

Confirmez votre action en cliquant sur Oui :

Environ 30 secondes plus tard, la notification Azure suivante vous indique que votre VM est correctement démarrée :

Relancez votre session Windows via Azure Bastion :

Confirmez la bonne exécution de votre tâche planifiée grâce à l’information Dernier lancement :

Ouvrez également les journaux d’évènements Windows :

Parcourez l’arborescence suivante pour constater l’historisation de votre tâche planifiée :

Applications and Services Logs
- Microsoft
  - Windows
    - TaskScheduler
      - Operational

Votre environnement de test Windows est maintenant configuré.

Pour qu’Azure Monitor vous alerte sur l’exécution (ou l’absence d’exécution) de la tâche planifiée, il est nécessaire de remonter une partie des journaux d’évènements Windows dans Azure.

Etape III – Paramétrez la remontée de journaux Windows :

Pour créer notre alerte Azure, nous devons commencer par stocker les informations liées à notre tâche planifiée Windows. Il nous faut donc les stocker, quelque part dans Azure, et les alimenter par les journaux d’évènements Windows.

Nous allons avoir donc besoin d’un espace de travail Log Analytics :

Un espace de travail Log Analytics constitue un environnement unique pour les données de journaux provenant d’Azure Monitor et d’autres services Azure, comme Microsoft Sentinel et Microsoft Defender pour le cloud. Chaque espace de travail possède son propre référentiel de données et sa propre configuration, mais peut combiner des données provenant de plusieurs services.
Microsoft Learn

Le schéma ci-dessous montre de façon assez simple le fonctionnement des services Azure, piochant les données stockées dans des tables, elles-mêmes stockées dans l’espace de travail Log Analytics :

Pour cela, retournez sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre premier espace de travail Log Analytics :

Renseignez les informations de base, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour mettre en place la connexion avec votre VM Windows :

Dans la section des Agents, copiez le lien web pointant vers l’agent Windows en version 64 bits :

Retournez sur la session de bureau à distance de votre VM, puis collez le lien web dans Edge :

Attendez que l’agent MMA (Microsoft Monitoring Agent) se télécharge, puis cliquez-ici pour lancer son installation :

Cliquez sur Suivant :

Cliquez sur Accepter :

Cliquez sur Suivant :

Cochez la première case, puis cliquez sur Suivant :

Sur la page de votre LAW (espace de travail Log Analytics), copiez l’ID de votre espace et une des deux clefs :

Collez ces deux informations dans les champs correspondants, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ une minute que l’installation se termine :

Cliquez sur Terminer pour refermer l’installation :

Attendez quelques minutes, puis rafraichissez la page suivante plusieurs fois afin de voir la bonne connection entre notre LAW et notre machine virtuelle de test :

Cliquez sur le bouton suivant afin d’ajouter le journal d’évènement relatif aux tâches planifiées Windows dans les remontées LAW :

Recherchez dans la liste le journal suivant, cochez toutes les cases, puis sauvegardez la configuration :

Microsoft-Windows-TaskScheduler/Operational

La notification Azure suivante vous indique la bonne prise en compte de ce journal :

La connexion entre notre tâche planifiée Windows et Azure est maintenant correctement établie.

Maintenant, il va nous falloir patienter plusieurs minutes afin que les prochaines remontées relatives à notre tâche planifiée de test se fassent correctement.

Etape IV – Testez votre remontée grâce à Azure KQL :

Avant de configurer l’alerte dans Azure Monitor, il est nécessaire de vérifier la présence de données dans LAW. Pour cela, nous allons utiliser le langage KQL dans notre requête sur LAW.

Le langage de requête Kusto (KQL) est un outil permettant d’explorer vos données et d’y découvrir des modèles, d’identifier des anomalies et des valeurs hors norme, de créer une modélisation statistique, etc. La requête utilise des entités de schéma organisées dans une hiérarchie similaire aux SQL : bases de données, tables et colonnes.
Microsoft Learn

Il est possible de faire des requêtes KQL directement depuis votre espace de travail Log Analytics.

Recherchez la section Logs, saisissez la requête KQL suivante afin de rechercher une trace antérieure de notre tâche planifiée Windows :

Event
| where RenderedDescription contains "Deconnexion" and RenderedDescription contains "successfully finished"

Le résultat de notre requête sera bien évidement vide, puisque la configuration de l’agent MMA a été faite après le premier test de notre tâche planifiée :

**Deconnexion** est le nom de ma tâche planifiée.

Attendez quelques minutes que la session de bureau à distance via Azure Bastion vous déconnecte pour cause d’inactivité :

30 minutes après la déconnexion de votre utilisateur, la machine virtuelle devrait s’éteindre au niveau OS.

Et quelques minutes plus tard, la requête KQL lancée précédemment devrait donner cette fois ci un résultat :

Afin de configurer notre alerte Azure, il est nécessaire de convertir le résultat de cette requête KQL en nombre (compteur).

En effet, dans notre exemple, notre alerte Azure doit nous informer si la machine virtuelle ne s’est pas éteinte de la journée (0).

Modifiez la requête KQL précédente comme ceci :

Event
| where RenderedDescription contains "Deconnexion" and RenderedDescription contains "successfully finished"
| count

Dans mon environnement, la tâche planifiée Deconnexion a bien été exécutée déjà 2 fois :

Tout est maintenant prêt pour configurer notre alerte Azure.

Etape V – Créez votre alerte sur Azure Monitor :

Les alertes vous permettre de détecter et de résoudre des problèmes avant que les utilisateurs ne les remarquent en vous informant de manière proactive quand les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application.

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor.
Microsoft Learn

Depuis votre fenêtre de requête KQL, cliquez-ici pour créer votre Alerte Azure :

La nouvelle fenêtre reprend la requête KQL précédemment affichée :

Définissez la méthode d’analyse de cette nouvelle alerte et aussi son seuil de déclenchement, puis cliquez sur Suivant :

Sous la section des Actions, cliquez-ci dessous pour créer un groupe d’actions :

Nommez-le, puis passer sur l’onglet suivant :

Dans l’onglet Notifications, définissez un type de notification Email, nommez-le également, puis renseignez une adresse email à cibler :

Cliquez sur Créer votre groupe d’actions :

De retour sur votre règle d’alerte, cliquez sur Suivant :

Nommez votre règle d’alerte Azure, puis cliquez sur Suivant :

Une fois la validation Azure réussie, lancez la création de l’alerte :

La création d’une alerte Azure entraine l’envoi immédiat d’un premier email informant la mise en place de celle-ci aux destinataires présents dans le groupe d’actions associé :

Comme notre alerte Azure est configurée par intervalle d’analyse de 24 heures, j’ai attendu quelques peu avant de recevoir le second email suivant :

Le contenu du second email nous indique bien que la tâche planifiée sur notre machine Windows n’a pas été exécutée durant la période donnée :

En effet, l’exécution de la tâche planifiée est journalisée dans Windows, lui-même connecté à notre Log Analytics workspace. La valeur à zéro de la requête KQL indique donc l’absence de lancement, et correspond surtout le seuil d’alerte configuré.

Conclusion

Ce petit exercice nous a montré le véritable potentiel des règles d’alerte d’Azure Monitor, et l’intérêt de stocker les évènements et les métriques de nos ressources Cloud ou sur site.

Afin d’aller plus loin sur ce sujet, je ne peux que vous conseiller de regarder cette autre vidéo, dédiée aux Règles de traitement des alertes :

VM : Connectez-vous avec Azure AD

Il est possible depuis longtemps de se connecter à une session Windows via un compte Azure AD, que cela concerne Windows 10/11 ou Windows Server. Pour cela, une jointure à Azure AD est nécessaire et l’article l’expliquant est disponible juste ici. Seulement sur Azure, les choses sont légèrement différentes. Je trouvais donc intéressant de vous en écrire un article dessus.

En effet, lors de la création d’une machine virtuelle Azure, il est possible de la joindre directement à Azure AD au travers d’une extension. Cette jointure va vous permettre de vous y connecter en bureau à distance via votre compte Azure AD.

Mais certaines choses sont à respecter pour que cela fonctionne, et c’est pour cela que j’ai écrit cet article, car bien souvent on bloque et on tourne en rond.

Dans celui-ci, vous trouverez toutes les étapes nécessaires, de la création à la connexion à la machine virtuelle, en passant par une règle d’accès conditionnel d’Azure AD :

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

Etape I – Déploiement de la machine virtuelle Azure :

Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer une première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

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

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Cochez la case Azure AD, cela coche automatiquement la case Identité, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour terminer la configuration de vm :

Cliquez sur le bouton suivant pour déployer le service Azure Bastion :

Deux notifications apparaissent concernant le déploiement de Bastion :

N’attendez pas qu’Azure Bastion soit déployé pour continuer les prochaines actions.

Toujours sur votre VM de test, allez dans le menu suivant afin d’ajouter un rôle sur votre utilisateur de test :

Ajoutez-lui le rôle suivant pour que celui-ci soit autorisé à se connecter en bureau à distance sur la VM :

Rendez-vous sur la page des périphériques d’Azure AD suivante afin de constater la bonne jointure de votre VM de test :

*Voici un article abordant les différents types de jointure Azure AD.*

Comme ma machine virtuelle de test tourne sur Windows Server, celle-ci n’est pas présente dans la gestion MDM Intune :

Quelques minutes plus tard, Azure Bastion devrait être entièrement déployé :

Sur votre machine de test, ouvrez une session Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Vérifiez que la session s’ouvre bien :

Saisie la commande suivante dans une fenêtre CMD :

dsregcmd /statut

Vérifiez encore une fois la bonne jointure à Azure AD :

Etape II – Tests avec Azure AD :

Tentez de vous connecter à votre VM en utilisant le compte Azure AD de votre utilisateur de test via Azure Bastion :

Constatez le message d’erreur d’Azure Bastion :

Tentez de vous connecter à votre VM en utilisant le compte Azure AD de votre utilisateur de test précédé de la mention AzureAD\ :

Constatez une seconde fois le même message d’erreur d’Azure Bastion :

Sur la session Bastion ouverte avec le compte administrateur, ouvrez l’éditeur de registre Windows, puis rendez-vous au chemin suivant :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Modifiez les deux clefs suivantes en changeant leur valeur par zéro :

SecurityLayer
UserAuthentication

Il est possible de faire via un script PowerShell, exécutable depuis le portail Azure :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1

Retentez une connexion à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :

Constatez cette fois-ci la bonne ouverture de votre session Windows :

Afin de renforcer la sécurité de vos utilisateurs, la mise en place d’une connexion renforcée via MFA est indispensable. Voici d’ailleurs plus articles intéressants à ce sujet :

Bien souvent, la question se pose sur l’ouverture de session Windows avec un compte Azure AD protégé par une MFA. Pour cela, nous allons tester l’impact de l’accès conditionnel sur notre utilisateur

Etape III – Test avec accès conditionnel MFA :

Pour cela, rendez-vous à la page d’Azure AD suivante afin d’y créer une règle d’accès conditionnel pour notre utilisateur de test :

Ajoutez votre utilisateur de test dans le public cible :

Dans un premier temps, intégrez l’ensemble des applications cloud dans cette police d’accès conditionnel :

Autorisez l’accès sous la condition de réussir le challenge MFA, activez la police puis sauvegardez la :

Avant de tester la solution sur l’ouverture de session Windows, il est nécessaire de configurer la MFA pour notre utilisateur de test.

Comme la police d’accès conditionnel est très récente, il est préférable d’attendre environ 5 minutes que celle-ci soit correctement appliquée pour notre utilisateur.

Rendez-vous en navigation privée sur la page office.com, puis authentifiez-vous :

Comme on pouvait s’y attendre, il est nécessaire de remplir les informations MFA dès à présent.

Choisissez la méthode MFA qui vous arrange, puis configurez-là :

Fermez le navigateur privé, puis réouvrez-en un afin de vérifier que le challenge MFA est bien présent et correctement configuré :

Retournez sur le portail Azure, rouvrez une session Windows avec les mêmes identifiants que lors du test précédent :

Constatez la présence de ce message bloquant provenant du challenge MFA :

Et cela malgré l’indication des succès dans le log des authentifications d’Azure AD de notre utilisateur de test :

Afin de contourner le problème lié à la MFA sur le compte Azure AD, retournez dans la police d’accès conditionnel créée précédemment afin de lui y ajouter l’exclusion suivante, puis sauvegardez :

Retendez encore une fois d’ouvrir une session Windows avec les mêmes identifiants que lors du test précédent :

Constatez cette fois-ci le succès et l’absence de blocage au moment de l’ouverture de session.

Un rapide whoami en ligne de commande nous confirme bien la connexion au compte Azure AD :

Conclusion

Finalement, les opérations nécessaires à la connexion à la VM via Azure AD ne sont pas très compliquées. Notez ici qu’il s’agit d’un simple test et que la grande majorité d’environnement de production nécessiteront des mesures de sécurité supplémentaires.

Voici d’ailleurs un article très intéressant à ce sujet : La sécurité de votre Azure. Bonne lecture !