Non cet article n’est pas un doublon du précédent, appelé Faites hiberner vos VMs, et parlant d’une méthode astucieuse pour ne pas entièrement éteindre une VM lorsque l’on souhaite réduire les coûts. Vous l’aurez compris, Microsoft propose également l’hibernation de VM pour son produit VDI phare : Azure Virtual Desktop.
Ça y est, l’Ignite de Microsoft est juste terminé ! Beaucoup de news très intéressantes ont été annoncées concernant Azure. Je vous invite d’ailleurs à lire le Book of news de cette édition 2023.
Concernant l’hibernation d’Azure, voici quelques petits rappels :
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.
Si l’envie vous prend d’en savoir un peu plus, je vous invite à lire l’article de la semaine dernière. Enfin, une toute nouvelle vidéo de Dean parle de l’hibernation dans un environnement AVD, le combo ultime :
Inutile de reparler en détail de l’hibernation, comme toujours je vous propose de réaliser un petit exercice, combinant AVD et l’hibernation.
Pour réaliser cet exercice d’hibernation sur des VMs Azure Virtual Desktop, il vous faudra disposer de :
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 un environnement AVD et avec l’hibernation activée.
Etape II – Déploiement de l’environnement AVD :
Avant cela, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :
Nommez celui-ci, puis cliquez sur Vérifier:
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :
Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :
Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :
Choisissez le type Personnel pour l’environnement AVD, puis cliquez sur Suivant :
Confirmez la sécurité de la VM comme ceci :
Choisissez dans la liste des images Microsoft l’image Windows 11 version 22H2, sélectionnez une VM de Séries Dsv5, puis cochez la case Hibernation :
Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :
Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer sa configuration des rôles RBAC :
Ajoutez-y les 3 rôles RBAC suivants à un utilisateurs de test AVD et à l’application Azure Virtual Desktop :
Nous devons rajouter un rôle Azure RBAC pour permettre à Azure Virtual Desktop (ou anciennement Windows Virtual Desktop) de pouvoir allumer et éteindre les VMs AVD :
De retour sur votre pool d’hôte AVD, activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :
Ajoutez le scaling plan qui pilotera la VM individuelle selon les besoins de connexion, puis cliquez sur Créer :
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.
L’onglet suivant reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs ci-dessous, puis de cliquer sur Suivant :
Heure de début : heure correspondant au début de la phase.
Démarrage de la VM : permet à l’utilisateur de pouvoir démarrer une VM éteinte pendant la phase. Cette option prend le pas sur la configuration renseignée dans le pool d’hôtes.
VMs à démarrer : propose de démarrer automatiquement des VMs si nécessaire dès le début de la phase, ou pas.
Paramètres de déconnexion : permet d’effectuer l’hibernation ou non.
Paramètres de fermeture de session : permet d’effectuer l’hibernation ou non
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 :
Cliquez sur Suivant pour continuer :
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 :
Attendez 1 minute que la configuration soit déployée :
Notre environnement AVD combiné à l’hibernation est enfin prêt, il ne nous reste plus qu’à utiliser un utilisateur pour tester les différentes phases de ce nouvel état.
Etape III – Test de l’hibernation :
Dans mon environnement de démonstration AVD, la machine virtuelle individuelle est déjà démarrée.
Depuis votre poste, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :
Lancez l’application de bureau à distance, puis authentifiez-vous encore une fois avec un compte AVD de test :
Validez la délégation en cliquant sur Oui :
Ouvrez une ou plusieurs applications sans enregistrer les travails effectués :
Fermez la session AVD en utilisant la croix du bureau à distance :
Confirmez le choix de déconnexion en cliquant sur OK :
A ce moment précis, la machine virtuelle AVD est toujours en statut Disponible :
Environ 10 minutes plus tard, son statut commence à changer :
Environ 1 minute plus tard, son statut AVD bien changé :
De retour dans la listes des machines virtuelles Azure, le statut d’hibernation est bien confirmé :
Afin de confirmer le bon retour des programmes ouvert, recliquez à nouveau sur l’application de bureau à distance, puis attendez le démarrage effectif de la VM AVD :
Environ 2 minutes plus tard, la session Windows se réouvre alors avec les programmes précédemment ouverts et non sauvegardés :
Conclusion :
La fonction d’hibernation annoncée il y seulement quelques jours est un atout non négligeable dans la gestion offline de machine virtuelle. Aucun doute que ce statut est plus pratique que l’arrêt complet dans un environnement Azure Virtual Desktop. Les utilisateurs de machines AVD individuelles seront sans aucun doute ravi ne pas devoir fermer et ouvrir toutes leurs applications tous les jours 😎
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.
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.
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.
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 :
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.
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 😎
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.
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 :
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 :
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.
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 :
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.
Azure Virtual Desktop intègre OneDrive depuis déjà quelques années, que ce soit via le bureau à distance ou les applications sous RemoteApp. Mais Microsoft améliore l’expérience utilisateur dans le cadre des applications lancées RemoteApp (publication d’applications sans bureau Windows).
En effet, il est possible de monter la ressource OneDrive liée au compte AVD automatiquement sur le poste local ! Concrètement, l’utilisateur ouvre son application RemoteApp et aura accès à OneDrive depuis son application ou son poste local.
Vous pouvez utiliser Microsoft OneDrive avec une RemoteApp dans Azure Virtual Desktop (preview), ce qui permet aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp. Lorsqu’un utilisateur se connecte à une RemoteApp, OneDrive peut être lancé automatiquement en tant que compagnon de la RemoteApp.
Pour mes tests, je n’ai eu besoin d’installer FSLogix, mais nul doute que la dernière version de celui-ci doit être installée pour que la gestion des profils en itinérance se fasse correctement avec le nouveau comportement de OneDrive.
Afin d’en savoir un peu plus, je vous propose de réaliser un petit exercice ensemble :
Pour réaliser cet exercice sur OneDrive au travers Azure Virtual Desktop en mode RemoteApp, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Déploiement de l’environnement AVD :
Avant tout chose, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :
Une fois le déploiement terminé, cliquez-ici pour y déployer le service Azure Bastion :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Sans attendre la fin du déploiement d’Azure Bastion, créez une machine virtuelle en Windows 11 sur le même réseau virtuel, sans y configurer d’options particulières :
Cette VM de test va nous servir à simuler notre poste local où nous lancerons l’application AVD en RemoteApp.
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 :
Activez l’option Validation de l’environnement AVD, puis cliquez sur Suivant :
Choisissez dans la liste des images Microsoft l’image Windows 11, version 22H2 :
Indiquez le nombre de VMs AVD, puis réutilisez le réseau virtuel Azure créé précédemment :
Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :
Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer sa configuration :
Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :
Créez un nouveau groupe d’applications AVD pour effectuer le test de l’application ouverte en RemoteApp :
Renseignez les informations de base, puis cliquez sur Suivant :
Ajoutez une application accessible depuis le menu Démarrer de votre VM AVD, puis cliquez sur Suivant :
Inutile de renseigner des utilisateurs à notre groupe d’applications, cliquez sur Suivant :
Associez votre nouveau groupe d’applications à votre espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du groupe d’applications AVD, puis attendez environ 1 minute :
Une fois le déploiement terminé, cliquez sur le groupe de ressources commun à tous les déploiements antérieurs :
Ajoutez-y les 2 rôles RBAC suivants à un ou plusieurs utilisateurs de test AVD :
Retournez sur la machine virtuelle de test simulant le poste local, puis ouvrez une session de bureau à distance via Azure Bastion, en utilisant les identifiants administrateurs renseignés lors de la création de celle-ci :
Depuis cette VM, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :
Lancez l’application configurée en RemoteApp :
Authentifiez-vous encore une fois avec un compte AVD de test :
Constatez l‘absence de configuration OneDrive dans l’application RemoteApp, mais aussi au niveau de la VM de test simulant le poste local :
Fermez l’application en RemoteApp.
Nous environnement de départ est en place. Nous allons pouvoir effectuer la configuration cible en commençant par l’installation de OneDrive.
Etape II – Configuration de OneDrive :
Depuis votre portail Azure, ouvrez une seconde session Bastion sur la VM AVD, en utilisant les identifiants administrateurs renseignés lors de la création celle-ci :
Retournez sur le portail Azure afin de récupérer le Tenant ID de votre tenant :
Retournez sur la fenêtre PowerShell de votre VM AVD, puis lancez le script suivant en prenant le soin de renseigner votre Tenant ID dans la variable $TenantGUID :
La commande effectuée va permettre de laisser fonctionner OneDrive en tâche de fond lorsque l’application en RemoteApp est démarrée :
La configuration de OneDrive sur notre machine virtuelle AVD est terminée.
Pour que tout fonctionne correctement, la version de Windows de la VM AVD doit être supérieure ou égale à la 25905.
Pour cela, nous avons besoin de rejoindre programme Windows Insider de Windows 11.
Etape III – Installation du Programme Windows Insider :
Sur la session administrateur de votre VM AVD, retournez dans les paramétrages Windows :
Cliquez-ici pour rejoindre le programme Windows Insider :
Avant de pouvoir rejoindre le programme Windows Insider, cliquez sur l’alerte afin d’activer la remontée de données de diagnostic :
Activez l’option, puis retournez sur la page principale des paramètres Windows :
Cliquez sur Commencer afin d’activer le programme Windows Insider :
Utilisez le compte de votre utilisateur AVD pour rejoindre le programme :
Renseignez ses identifiants :
Choisissez le canal Canary, puis cliquez sur Continuer :
Considérez si besoin les particularités du canal Canary, puis cliquez sur Continuer :
Cliquez sur Continuer pour accepter les conditions du programme liées à votre poste :
Redémarrez la VM de test AVD :
Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour, dont celles-ci :
Une fois l’installation terminée, lancez une redémarrage de la VM AVD :
Quelques minutes plus tard, vérifiez via la session ouverte sur Azure Bastion que votre VM AVD est dans la bonne version de Windows 11 :
Notre environnement est enfin prêt et fonctionnel pour tester OneDrive en version RemoteApp.
Il ne nous reste plus qu’à effectuer des tests RemoteApp grâce à notre utilisateur AVD.
Etape IV – Test de OneDrive en RemoteApp :
Retournez sur la session ouverte sur la VM de test local ouverte via Azure Bastion, puis réouvrez l’application configurée en RemoteApp :
Constatez la présence du compte OneDrive depuis l’application WordPad :
Constatez l’apparition d’un second OneDrive ouvert localement, avec la mention Remote, puis cliquez-dessus:
Constatez l’ouverture de la fenêtre OneDrive comme une seconde application RemoteApp ouverte depuis le poste local :
Fermez l’application WordPad :
Quelques secondes plus tard, l’application OneDrive ouverte automatiquement en RemoteApp se ferme également :
Conclusion
Grâce à cette évolution, OneDrive fonctionne parfaitement avec RemoteApp créée dans un environnement Azure Virtual Desktop. Cela permet à vos aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp de 2 manières, localement ou au travers de l’application RemoteApp.
Azure Lighthouse existe déjà depuis longtemps. Mais je souhaitais malgré tout en faire un article car il est très utile dans bien des cas car il facilite grandement la gestion de ressources réparties sur plusieurs tenants Microsoft. Cela s’adapte donc parfaitement aux prestataires ou fournisseurs de services Cloud.
Qu’est-ce qu’Azure Lighthouse ?
Azure Lighthouse permet une gestion multi-locataire avec de la scalabilité, une automatisation plus poussée et une gouvernance renforcée des ressources.
En d’autres termes, Azure Lighthouse vous permet d’accéder à plusieurs tenants en simultané. Cela permet de visualiser un ensemble de ressources Azure réparties sur plusieurs tenants dans une seule et unique vue.
Grâce à Azure Lighthouse, vous allez pouvoir :
Créer une relation sécurisée entre vous et vos clients gérés.
Fournir une transparence et à la demande sur l’accès et les actions.
Permettre une gestion granulaire de l’accès à l’ensemble du parc Azure.
Vous pouvez gérer plusieurs clients dans un seul Azure Lighthouse. Vous devez simplement définir comment vos équipes accéderont aux ressources des clients :
Pourquoi utiliser Azure Lighthouse pour un client ?
Gardez le contrôle : Ajoutez, modifiez ou retirez les droits des intervenants externes à tout moment grâce à la relation fournisseur de services / client établie via Azure Lighthouse.
Conservez la sécurité : Fournissez un accès granulaires aux fournisseurs de services, à des niveaux spécifiques (souscription ou groupe de ressources), et à des groupes d’utilisateurs définis, pour un accès permanent ou temporaire.
Restez informé : Veillez à ce que vos données soient toujours sécurisées et ne quittent pas votre environnement, tout en ayant une visibilité sur les actions et les changements effectués par vos fournisseurs de services.
Comment Azure Lighthouse fonctionne ?
Pour qu’Azure Lighthouse puisse fonctionner, il est nécessaire de disposer de :
Utilisateurs, groupes ou principaux de service provenant du tenant du fournisseur.
Rôles RBAC à appliquer sur les ressources du client.
Ces 2 éléments (Rôles + identités) sont alors combinés dans un template généré au format JSON depuis le tenant du fournisseur, puis exécuté sur le tenant du client.
Pour réaliser cet exercice sur Azure Lighthouse, il vous faudra disposer de :
Deux tenants Microsoft (fournisseur / client)
Tenant fournisseur :
Un utilisateur avec des droits d’administrateur
Tenant client :
Une souscription Azure valide
Un utilisateur avec rôle de Propriétaire sur la souscription Azure
Afin d’identifier plus facilement les deux tenants Azure, je vous propose de configurer les couleurs du portail Azure comme ceci :
Portail Azure clair : tenant fournisseur
Portail Azure sombre : tenant client
Commençons par la configuration du tenant du fournisseur.
Etape I – Configuration du tenant fournisseur :
Connectez-vous au tenant du fournisseur afin de créer un nouveau groupe Entra ID dédié à Azure Lighthouse :
Ajoutez dans ce nouveau groupe les membres nécessaires pour tester par la suite le bon fonctionnement de l’accès aux ressources Azure situées sur le tenant du client :
Toujours sur le tenant du fournisseur, utilisez la barre de recherche comme ceci :
Cliquez sur Créer un modèle ARM (Azure Resource Manager) :
Nommez le nom de votre template ARM, puis cliquez-ici pour ajouter des autorisations RBAC :
Recherchez le groupe créé précédemment , ajoutez une autorisation que vous accorderez à vos utilisateurs d’Azure Lighthouse, puis définissez si les droits sont permanents ou éligibles :
Pour les droits éligibles, vous devrez configurer Lighthouse avec Azure AD PIM, qui est disponible dans la licence Entra ID Premium P2.
Cliquez sur le bouton Voir le modèle :
Cliquez sur le bouton Télécharger :
La configuration du tenant fournisseur est maintenant terminée
Ce template au format JSON est utilisable autant de fois que nécessaire, tant que les accès aux ressources Azure des clients sont identiques.
La suite se passe maintenant sur le tenant du client.
Etape II – Configuration du tenant client :
Connectez-vous au tenant du client où se trouve la souscription ou le groupe de ressources que vous souhaitez gérer.
Avant de mettre en place Azure Lighthouse, prenez le temps de vérifier sur la souscription Azure le bon enregistrement du fournisseur de ressources suivant :
Utilisez la barre de recherche comme ceci :
Cliquez ici pour voir les offres des prestataires de services :
Dans le menu Offres des prestataires de services, cliquez sur Ajouter une offre, puis sélectionnez Ajouter par le biais d’un modèle :
Téléchargez le modèle que vous avez créé précédemment :
Sélectionnez la souscription Azure, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du lien Azure Lighthouse :
Attendez environ deux minutes :
La configuration est maintenant en place. Avant de créer une nouvelle ressource Azure, nous allons contrôler le lien établi.
Etape III – Contrôle de la configuration :
Toujours sur le tenant du client, rendez-vous dans le menu suivant afin de constater l’apparition de la délégation créée précédemment :
Retournez sur le tenant du fournisseur afin de constater l’apparition du client dans le menu suivant :
Cliquez sur le bouton de paramétrage du portail Azure afin de voir dans la liste des tenants et des souscriptions provenant du tenant du client :
Toujours sur le tenant fournisseur, vérifiez la présence de la souscription client dans la liste des souscriptions Azure, puis cliquez dessus :
Contrôlez la désactivation des fonctions d’assignation car le rôle de propriétaire n’est pas disponible via Azure Lighthouse :
L’environnement client est maintenant correctement configuré.
Afin de vérifier le bon fonctionnement, je vous propose créer une nouvelle machine virtuelle sur la souscription Azure du client, depuis le tenant du fournisseur.
Etape IV – Création d’une machine virtuelle Azure :
Encore sur le tenant fournisseur, cliquez-ici pour créer une machine virtuelle Azure :
Renseignez les informations de base relatives à votre VM en choisissant bien la souscription Azure du tenant du client, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 2 minutes que le déploiement se termine :
Retournez sur le portail Azure du tenant du client afin de vérifier la bonne apparition de la machine virtuelle créée depuis le tenant du fournisseur :
Contrôlez les droits RBAC présents sur cette machine virtuelle :
Notez l’absence de droits RBAC, directs ou hérités, des utilisateurs d’Azure Lighthouse.
La création des ressources est bien possible grâce à la mise en place d’un rôle RBAC de contributeur au travers d’Azure Lighthouse.
La suppression des ressources Azure depuis le tenant du fournisseur fonctionne elle aussi sans souci :
Etape V – Modification des ressources gérées par Azure Lighthouse :
La modification ou l’ajout des ressources gérées par Azure Lighthouse est possible depuis le tenant client, sans besoin de réutiliser le template JSON du fournisseur :
Là encore, la suppression de droits sur une souscription Azure est possible à tout moment depuis le tenant du client :
Conclusion :
En quelques clics, nous avons mis en place une délégation de ressources Azure en place. Bravo ! Bien évidemment, cette liaison d’Azure Lighthouse est aussi compatible avec Microsoft Entra Privileged Identity Management.
Enfin, voici comme toujours une vidéo de John Savill qui en parle très bien :
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). 😥😥
0
Years
:
0
Months
:
0
J
:
0
H
:
0
M
:
0
S
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.
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.
Microsoft nous prévient déjà depuis assez longtemps : la fin du support de Windows Server 2012 R2 et SQL 2012 sont prévues pour le 10 octobre 2023 😖. Après cette date, ces produits ne recevront plus de mise à jour, sécurités incluses ! Trois s’options s’offrent alors à vous :
Migrer vers une nouvelle version Windows ou SQL plus récente.
Acheter les Mises à jour de sécurité étendue (ESU).
Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.
Pas de panique !
Microsoft vous aide à planifier la fin de support Windows Server 2012/2012 R2 et SQL Server 2012. Plusieurs ressources sont mises à disposition :
En plus de la documentation Microsoft, Dean Cefola de l’Azure Academy nous propose un petit exercice d’upgrade d’un Active Directory, actuellement hébergé sur un serveur Windows 2012R2 vers un Azure en version 2022 :
La vidéo est vraiment bien faite et très explicative, je souhatais donc vous proposer en détail l’explicatif étape par étape en français afin que vous puissiez le tester par vous-même :
Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Un environnement Active Directory on-premise (point de départ)
De mon côté, j’ai simulé mon environnement Active Directory on-premise sur Azure. Voici donc les ressources Azure déjà en place :
Machine virtuelle en Windows Server 2012R2
Azure Bastion
Azure VPN Site à Site
En me connectant à mon serveur AD (nous l’appellerons DC2012R2), nous y retrouvons mon domaine on-premise, ainsi que la version de l’OS : Windows Server 2012R2.
Actuellement, mon environnement de test ne comporte qu’un seul serveur en tant que contrôleur de domaine AD :
Nous allons donc maintenant déployer un nouvel environnement sur Azure afin de simuler la transition AD vers le Cloud de Microsoft.
Etape I – Déploiement des ressources Azure :
Pour cela, commencez par déployer une machine virtuelle sur Azure. 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, bloquer les ports entrants (question de sécurité pour un DC), puis cliquez sur Suivant :
Comme le Microsoft le recommande, il est nécessaire de stocker les informations AD (base de données, les journaux et le dossier sysvol) séparées du disque OS.
Pour cela, rajoutez un second disque en cliquant ici :
Cliquez sur OK :
Définissez le paramètre Host Cache sur le disque de données sur None, puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Créez un réseau virtuel (différent de celui utilisé pour simuler le réseau on-premise), 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 :
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 :
Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice.
Modifiez l’adresse IP locale de votre machine virtuelle Azure pour la rendre statique :
Avant d’aller plus loin, il est nécessaire d’établir une liaison réseau entre les deux environnements Azure <> on-premise (Normalement, notre environnement on-premise ne se trouve pas dans Azure).
Une des options est donc pour nous de construire une liaison VPN en connectant 2 passerelles VPN Azure entre elles.
Etape II – Déploiement de la passerelle VPN Azure :
Pour cela, il est nécessaire de commencer par la création d’une nouvelle passerelle VPN dans notre réseau virtuel Azure.
Pour cela, utilisez la barre de recherche :
Cliquez sur le réseau virtuel créé lors de la création de la VM DC2022 d’Azure :
Ajoutez un sous-réseau dédié à la passerelle VPN comme ceci :
Pour créer une passerelle VPN, utilisez à nouveau la barre de recherche :
Cliquez ici pour créer la seconde passerelle que nous connecterons par la suite à la première (on-premise) :
Renseignez les informations de base relatives à votre Passerelle VPN, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 15-45 minutes :
Afin de connecter les deux Passerelles VPNs Azure entre eux, nous avons besoin d’avoir :
deux passerelles de réseau local
deux connexions VPNs
Dans mon cas, la ressources VPNs côté on-premise sont déjà présentes :
Il ne me reste donc qu’à déployer les 2 ressources VPNs suivantes sur mon réseau Azure :
Passerelle de réseau local
Connexion VPN
Pour créer cela, utilisez encore une fois la barre de recherche Azure :
Configurer la passerelle de réseau local dans l’environnement Azure, mais indiquez l’adresse IP publique du VPN on-premise, puis lancez la validation :
Une fois la validation Azure réussie, lancez la création de la ressource :
Continuez en créant la connection entre le VPN Azure et la passerelle de réseau local on-premise, puis cliquez sur Suivant :
Définissez une clef partagée, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la ressource :
Attendez environ 5 minutes afin de constater un changement dans le statut de la connexion VPN.
Le statut de la connexion change bien sur le passerelle VPN Azure :
Le statut de la connexion change également sur le passerelle VPN on-premise :
Afin que la nouvelle machine virtuelle DC2012 d’Azure se connecte à l’Active Directory on-premise DC2012R2, configurez le DNS de votre réseau Azure pour qu’il pointe sur l’adresse IP de votre AD on-premise, puis cliquer sur Sauvegarder :
Notre environnement Azure est maintenant prêt pour configurer l’Active Directory. Pour cela, nous devons d’abord joindre votre machine virtuelle DC2022 au domaine on-premise, puis la promouvoir en tant que contrôleur de domaine.
Etape III – Ajout du second contrôleur de domaine Azure :
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 DC2022 :
Saisissez la commande suivante afin renouveler les informations DNS de votre VM DC2022 d’Azure afin qu’elle puisse rejoindre votre domaine on-premise :
ipconfig/renew
Sur la console Server Manager, utilisez le menu suivant pour créer une nouvelle partition liées aux données AD DS :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur OK:
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Créer :
Attendez que le traitement se termine :
Cliquez sur Fermer :
Toujours sur Server Manager, cliquez sur WORKGROUP afin de joindre votre domaine on-premise :
Cliquez sur le bouton ci-dessous :
Renseignez le nom de votre domaine on-premise, puis cliquez sur OK :
Renseignez les identifiants d’un compte présent sur le domaine on-premise, puis cliquez sur OK :
Attendez quelques secondes pour voir apparaître le message suivant, puis cliquez sur OK :
Cliquez sur OK :
Cliquez sur Fermer :
Cliquez-ici pour lancer un redémarrage immédiat de la VM DC2022 d’Azure :
Azure Bastion vous informe que la connexion RDP a été perdue. Cliquez sur Fermer :
Retournez sur votre DC2012R2 afin de constater la bonne apparition de notre VM DC2022 d’Azure dans la liste des ordinateurs du domaine Active Directory.
Rouvrez à nouveau une session à distance via le service Azure Bastion en utilisant un compte de domaine sur votre DC2022 :
Cliquez-ici pour installer les rôles AD DS et DNS sur votre VM DC2022 d’Azure :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Attendez quelques minutes, puis cliquez ici pour promouvoir votre VM DC2022 comme un second serveur AD DS de votre domaine on-premise :
Conservez le premier choix ainsi que le domaine précédemment joint, puis cliquez sur Suivant :
Choisissez si besoin un site différent du premier, renseignez le mot de passe DSRM, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Modifiez les chemins AD DS pour utiliser le nouveau disque, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 5 minutes que l’installation se termine :
Comme la VM doit redémarrer au niveau OS, Azure Bastion vous informe que la connexion RDP a été perdue. Cliquez sur Fermer :
Retournez sur votre DC2012R2 afin de constater la bonne apparition de notre VM DC2022 d’Azure dans la liste des contrôleurs de domaine.
Afin que la nouvelle machine virtuelle DC2022 Azure puisse résoudre des requêtes DNS du domaine on-premise, configurez le DNS de votre réseau Azure pour qu’il pointe sur l’adresse IP de votre VM DC2022, puis cliquer sur Sauvegarder :
Effectuez la même opération sur le DNS du réseau on-premise :
Notre machine virtuelle est maintenant contrôleur de domaine, nous allons pouvoir préparer le décommissionnement du DC2012R2 sur le réseau on-premise.
Avant cela, nous devons nous occuper des rôles FSMO.
Pour cela, ouvrez une session à distance sur votre VM 2012R2 via le service Azure Bastion en utilisant un compte admin de domaine :
Lancez la commande suivante afin de vérifier sur quel contrôleur de domaine se trouve actuellement les 5 rôles FSMO :
netdom /query fsmo
Comme attendu, les 5 rôles sont actuellement gérés par le contrôleur de domaine DC2012R2 :
Depuis la console Server Manager du serveur DC2012R2, ouvrez Windows PowerShell avec le module AD :
Saisissez la commande suivante pour transférer d’un coup les 5 rôles depuis DC2012R2 vers DC2022, en prenant le soin de modifier le nom en gras par le nom de votre VM :
Etape V – Décommissionnement l’Active Directory DC2012R2 :
Pour faire les choses dans l’ordre, cliquez sur la fonction de désinstallation présente dans la console Server Manager se trouvant sur votre serveur DC2012R2 :
Cliquez sur Suivant :
Cliquez sur Suivant :
Décochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :
Cliquez-ici pour confirmer votre choix :
Le message d’erreur suivi est attendu, la d’installation de rôles en activité ne peut que se faire qu’après un premier décommissionnement au niveau du domaine.
Cliquez-ici pour commencer l’opération :
Cliquez sur Suivant :
Cochez la case suivante pour également procéder pour la partie DNS, puis cliquez sur Suivant :
Définissez un nouveau mot de passe pour le compte d’administrateur local Windows :
Cliquez sur Rétrograder :
Attendez quelques minutes que le traitement se termine :
Le serveur DC2012R2 a besoin d’effectuer un redémarrage OS pour terminer la rétrogradation :
Azure Bastion vous informe alors que la connexion RDP a été perdue. Cliquez sur Fermer :
Retournez sur Server Manager de votre DC2022 d’Azure pour ouvrir Active Directory Utilisateurs et Ordinateurs :
Comme attendu, il ne reste que le DC2022 hébergé sous Azure :
Configurez le DNS de votre réseau Azure pour qu’il pointe plus que sur l’adresse IP de votre DC2022, puis cliquez sur Sauvegarder :
Effectuez la même opération sur le DNS du réseau on-premise, puis cliquez sur Sauvegarder :
Nous environnement Active Directory est maintenant 100% Cloud. Nous allons pouvoir mettre à jour le niveau domaine fonctionnel vers une version plus récente.
Etape VI – Mise à niveau du domaine Active Directory :
Pour cela, retournez sur la console Server Manager de votre DC2022 d’Azure, puis ouvrez Active Directory Domains and Trusts :
Commencez par élever le niveau fonctionnel du domaine sur chaque domaine de votre forêt :
Choisissez la version la plus récente possible, puis cliquez sur Elever :
Cliquez sur OK :
Cliquez sur OK :
Une fois tous les domaines modifiés, effectuez la même opération au niveau de la forêt AD :
Là encore, choisissez la version la plus récente possible, puis cliquez sur Elever :
Cliquez sur OK :
Cliquez sur OK :
Toutes les opérations de transfert ou de mise à jour sont maintenant terminées. Il ne nous reste plus qu’à tester le bon fonctionnement de notre Active Directory dans Azure.
Etape VII – Test de connexion depuis le réseau on-premise :
Pour tester notre AD dans Azure, nous utiliserons une machine virtuelle Windows 11 connectée au réseau on-premise (donc transitant par le lien VPN).
Sur la page de machines virtuelles Azure, éteignez le DC2012R2 afin de ne pas fausser le test de bon fonctionnement :
Confirmez votre choix en cliquant sur Oui :
Attendez l’apparition de la notification Azure suivante :
Ouvrez une session à distance sur votre machine Windows 11 de test via le service Azure Bastion en utilisant un compte de domaine :
Attendez que la session Windows s’ouvre :
Saisissez la commande suivante afin de bien vérifier l’ouverture de session sur un compte du domaine AD :
whoami
Conclusion :
Grâce à cet exercice, nous avons pu parcourir ensemble les principales étapes présentes dans une migration vers Azure d’un Active Directory, et via une version plus récente. Nul doute que le nombre et la répartition des DCs des infrastructures on-premise peut rajouter des tâches et de la complexité.
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.
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.
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 :
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.
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.
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.
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 :
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 :
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.
Azure Virtual Desktop est souvent associé aux environnements mutualisés. Mais on oublie souvent qu’AVD propose également à des environnements individuels, comme peut aussi le faire Windows 365. Comme toujours, les produits estampillés Azure apportent de la flexibilité dans la configuration et des optimisations possibles. Par exemple, des machines virtuelles équipées de puissantes cartes graphiques.
Aujourd’hui, Azure Virtual Desktop continue d’évoluer et propose maintenant l’arrêt automatique des VMs pour les environnements individuels.
En effet, il est déjà possible depuis un certains de temps faire automatiquement démarrer la machine virtuelle AVD d’utilisateur quand celui-ci s’y connecte. Cela s’appelle le Start on connect et j’en avait déjà parlé juste ici. Bien pratique et facile à configurer, cette fonction avait pour défaut de ne jamais arrêter la VM quand l’utilisateur n’en avait plus besoin.
Rappelons-le : une machine virtuelle éteinte au niveau OS continue de coûter de l’argent car des ressources Azure lui sont toujours allouées.
Des parades existent déjà depuis quelques temps déjà, mais elles nécessitent bien souvent une configuration annexe :
J’avais d’ailleurs écrit un article sur ce sujet. Mais depuis, les choses se compliquent car certaines fonctionnalités des comptes Azure Automation vont bientôt être dépréciées…
Bref, je suis bien content que Microsoft ait rajouté cette fonctionnalité d’arrêt automatique des VMs dans Azure Virtual Desktop.
Qu’est-ce que la mise à l’échelle automatique ?
La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.
La mise à l’échelle automatique, ou autoscaling, est déjà disponible pour les environnements AVD mutualisés. Un autre article en parle juste ici.
Comme indiqué dans le titre, la grande nouveauté concerne les environnements AVD individuels. La documentation Microsoft en parle déjà : la mise à l’échelle automatique pour les pools d’hôtes individuels est actuellement en préversion.
Voici donc un petit exercice pour tester cette fonctionnalité :
Pour réaliser cet exercice sur Azure Virtual Desktop, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Déploiement de l’environnement AVD :
Pour déployer un environnement AVD, commencez par déployer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :
Renseignez tous les champs, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création de votre réseau virtuel :
Attendez environ une minute que le déploiement se termine :
Utilisez encore une fois la barre de recherche Azure pour créer votre environnement AVD :
Cliquez-ici pour créer un nouvel environnement AVD :
Renseignez tous les champs en prenant soin de choisir un type d’environnement individuel :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Renseignez les champs liés aux machines virtuelles AVD de votre environnement :
Choisissez la taille et le nombre de VMs AVD, ainsi que le réseau virtuel créé précédemment :
Dans notre environnement, une jointure des VMs à Azure Active Directory suffira. N’oubliez pas de joindre également vos VMs à Intune pour terminer cet exercice, puis cliquez sur Suivant :
Renseignez les champs pour créer 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 terminé, cliquez-ici pour terminer la configuration de votre AVD :
Cochez l’option pour activer le SSO sur Azure Virtual Desktop. Cela évite de devoir s’authentifier deux fois pour arriver sur le bureau de la VM AVD :
Afin de pouvoir tester notre environnement AVD, il est nécessaire de rajouter des rôles à nos utilisateurs de test :
Desktop Virtualization User
Virtual Machine User Login
Enfin, mon environnement AVD de test nécessite d’assigner des utilisateurs aux VMs AVD. Pour cela, rendez-vous sur cet écran pour les assigner manuellement :
Comme je dispose de 2 VMs dans mon environnement AVD, j’ai assigné à chacune d’entre-elles un utilisateur de test :
Vérifiez que les machines virtuelles sont bien présentes et disponibles :
Ouvrez le client Remote Desktop, ou installez-le depuis ce lien si cela n’est pas encore le cas :
Utilisez la fonction suivante pour faire apparaître les machines AVD :
Vous pouvez répéter cette opération avec votre second utilisateur de test :
Cliquez sur l’icône de bureau à distance :
Authentifiez-vous une seconde fois pour activer la fonction SSO :
Autorisez-les connections de bureau à distance à partir de l’identité Azure AD de votre utilisateur de test :
Attendez que le bureau à distance Windows 11 s’ouvre :
Une fois la session AVD ouverte, fermez cette dernière en utilisant la déconnexion habituelle de Windows :
Votre environnement AVD est prêt et fonctionnel. Notre objectif est maintenant d’ajouter la fonction d’allumage et d’extinction automatique des VMs.
Etape II – Configuration de l’allumage et de l’extinction automatique :
Pour cela, nous devons rajouter un nouveau rôle Azure RBAC pour permettre à Azure Virtual Desktop (ou anciennement Windows Virtual Desktop) de pouvoir allumer et éteindre les VMs AVD :
Ajoutez le rôle RBAC suivant au niveau du groupe de ressources Azure contenant votre environnement AVD :
Retournez dans le menu Azure Virtual Desktop afin d’ajouter le scaling plan qui pilotera les VMs individuelles selon les besoins de connexion, puis cliquez sur Créer :
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 :
Heure de début : heure correspondant au début de la phase.
Démarrage de la VM : permet à l’utilisateur de pouvoir démarrer une VM éteinte pendant la phase. Cette option prend le pas sur la configuration renseignée dans le pool d’hôtes.
VMs à démarrer : propose de démarrer automatiquement des VMs si nécessaire dès le début de la phase, ou pas.
Paramètres de déconnexion : permet d’effectuer ou non une action après un temps donné.
Paramètres de fermeture de session : permet d’effectuer ou non une action après un temps donné.
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 :
Cliquez sur Suivant pour continuer :
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 :
Attendez quelques minutes que la configuration soit déployée :
Votre environnement individuel AVD est enfin géré par un planning de démarrage et d’arrêt automatique.
Nous allons maintenant effectuer différents tests pour voir le comportement d’Azure Virtual Desktop d’un point de vue utilisateur.
Etape III – Test de l’allumage et de l’extinction automatique :
Dans mon environnement de démonstration AVD, les machines virtuelles individuelles sont bien arrêtées.
Test A – Fermeture de la session utilisateur en Phase 1 :
A 9h22, j’ouvre un navigateur web afin de me rendre sur la page de connexion AVD. Une fois authentifié avec un utilisateur de test, j’ouvre une session de bureau à distance :
Comme la machine virtuelle affectée à cet utilisateur est arrêtée, Azure Virtual Desktop la démarre et ce message s’affiche :
Le statut de la machine virtuelle change bien dans Azure :
Une fois la machine démarrée, le message d’attente change également :
Peu après, le bureau virtuel Windows apparaît bien. Je décide donc d’effectuer une fermeture de session Windows par le menu Démarrer :
Environ 15 minutes plus tard, la machine virtuelle retrouve bien son précédent état :
Le premier test est concluant. Effectuons maintenant un second test en ne fermant pas la session AVD, mais en utilisant la croix pour simuler une déconnexion :
Test B – Déconnexion utilisateur en Phase 2 :
J’ouvre à nouveau une session de bureau à distance :
Comme la machine virtuelle affectée s’était précédemment arrêtée, Azure Virtual Desktop est obligé de la redémarrer à nouveau :
Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :
Peu après, le bureau virtuel Windows apparaît bien. Je décide donc déconnexion de la session par la croix, en haut de la fenêtre AVD :
La session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :
A 10h56, la VM est déjà éteinte depuis quelques temps :
Cette information est confirmée par le journal d’audit de la machine virtuelle :
Les fonctions de déconnexion de l’utilisateur et de fermeture de session sont bien prises en compte dans le processus d’arrêt des machines virtuelles par Azure Virtual Desktop.
Prenons maintenant le temps de vérifier le respect des paramétrages renseignés dans la configuration.
Test C – Fermeture de la session utilisateur en Phase 3 :
A 11h01, j’ouvre à nouvelle fois une session Windows :
Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :
Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :
Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :
A 11h25, soit exactement 20 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre :
Cela confirme bien le paramétrage de temps renseigné dans cette phase :
Je décide de continuer mon test en vérifiant mon raisonnement en phase 4, dans laquelle j’ai configuré un arrêt de la VM seulement 5 minutes après la fermeture ou déconnexion de la session.
Test D – Fermeture de la session utilisateur en Phase 4 :
A 12h01, j’ouvre à nouvelle fois une session Windows :
Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :
Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :
Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :
A 12h08, soit exactement 5 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre à nouveau :
Cela confirme bien le respect du paramétrage selon la phase dans laquelle l’utilisateur se trouve :
Le paramétrage de démarrage et d’arrêt des machines virtuelles individuelles AVD fonctionne bien.
Afin d’aller plus loin dans le test, je décide d’y intégrer une session de déconnexion des sessions inactives, passé un certain temps.
Pour cela, je vais utiliser Intune pour déployer une police de configuration Windows sur les sessions de bureau à distances inactives.
Etape IV – Configuration log off Windows via Intune :
Afin de déployer une configuration Intune, démarrez les machines virtuelles AVD via la fonction suivante :
Sur la page d’Azure AD, créez un nouveau groupe et ajoutez-y les machines virtuelles AVD :
Rendez-vous dans la console Intune afin de créer un nouveau profil de configuration Windows comme ceci :
Choisissez le type de profil suivant, puis cliquez sur Créer :
Nommez votre profil de configuration, puis cliquez sur Suivant :
A droite, recherchez l’option suivante afin de l’ajouter et de la configurer sur la partie gauche de l’écran, puis cliquez sur Suivant :
Les Tags ne sont pas utilisés dans notre test, cliquez sur Suivant :
Ajoutez le groupe précédemment créé et contenant les machines virtuelles AVD, puis cliquez sur Suivant :
Vérifiez une dernière fois les options de votre profil de configuration, puis cliquez sur Créer :
Attendez environ 15-30 minutes que le profil de configuration soit bien déployée sur vos VMs AVD :
Ma configuration Intune et maintenant en place. Maintenant, nous allons pouvoir tester la combinaison des deux configurations.
Test E – Combinaison AVD + Intune :
Rouvrez une nouvelle fois une session AVD :
Comme la machine virtuelle AVD est déjà démarrée, la session s’ouvre bien plus rapidement :
Environ 15 minutes plus tard et sans avoir rien fait, un premier message d’avertissement apparaît sur la session AVD m’indiquant que la session sera déconnecté dans environ 2 minutes :
Environ 2 minutes plus tard et n’ayant toujours rien touché, le message suivant apparaît :
Là encore, la session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :
Environ 5 minutes après la déconnexion de la session, la machine virtuelle AVD change encore de statut pour s’éteindre une nouvelle fois :
Cette dernière démonstration montre bien la combinaison habille entre la nouvelle fonctionnalité AVD et la configuration Windows installée via une police de configuration Intune.
Conclusion :
Comme toujours, les nouveautés sur Azure Virtual Desktop font plaisir. Elles sont pratiques et vous ferons gagner du temps dans la configuration et dans la mise en place.
Voici d’ailleurs quelques une des dernières nouveautés AVD que j’ai pu tester récemment :
