VM – Traquez les changements

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

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

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

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

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

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

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

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

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

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

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

Niveau agent : AMA ou MMA, lequel choisir ?

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

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

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

Agent, Extension, Kesako ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

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

Etape I – Préparation de l’environnement :

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

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

Renseignez les informations de base relatives à votre VM :

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

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

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

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

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

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

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

Les notifications suivantes devraient apparaitre :

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

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

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

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

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

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

Etape II – Activation du Suivi des modifications et inventaire :

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

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

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

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

Etape III – Sauvegarde des évènements Azure :

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

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

Puis cliquez-ici :

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

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

Effectuez ensuite un changement de taille de votre machine virtuelle :

Attendez que le redimensionnement soit terminé :

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

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

Etape IV – Sauvegarde du suivi de fichiers Windows :

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

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

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

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

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

Etape V – Sauvegarde du suivi du registre Windows :

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

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

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

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

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

Etape VI – Sauvegarde du suivi de services Windows :

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

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

Install-WindowsFeature -name Web-Server -IncludeManagementTools

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

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

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

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

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

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

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

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

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

Choisissez votre compte de stockage, puis cliquez sur Sauvegarder :

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

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

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

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

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

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

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

Etape VIII – Inventaire des logiciels :

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

Lancez son installation :

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

Conclusion

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

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

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

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

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

Connectez votre réseau local à Global Secure Access

Restons encore un peu dans la lignée des articles dédiés au Global Secure Access de Microsoft. Abordons cette fois-ci une fonction appelée Remote Network : la connexion d’un réseau local (distant) tout entier à un point Edge du réseau Microsoft. Cette approche est complémentaire aux Clients Global Secure Access installés sur les postes en situation de mobilité.

Si le sujet Global Secure Access vous passionne tout comme moi, je vous invite à lire mes précédents articles sur le sujet :

J’y détaille l’intérêt du service Global Secure Access et la démarche sécuritaire mise en avant par Microsoft.

Qu’est-ce qu’un réseau distant ?

A l’inverse de postes en mobilité, il faut voir ces réseaux comme des réseaux fixes d’une entreprise dont le nombre et la répartition est possiblement mondiale :

Les réseaux distants sont des emplacements distants 🤣 ou des réseaux qui nécessitent une connectivité Internet. Par exemple, de nombreuses organisations ont un siège social central et des filiales dans différentes zones géographiques. Ces filiales ont besoin d’accéder aux données et services d’entreprise. Elles ont besoin d’un moyen sécurisé de communiquer avec le centre de données, le siège social et les travailleurs à distance. La sécurité des réseaux distants est cruciale pour de nombreux types d’organisations.

Les réseaux distants, tels qu’un emplacement de branche, sont généralement connectés au réseau d’entreprise via un réseau étendu dédié (WAN) ou une connexion de réseau privé virtuel (VPN). Les employés de l’emplacement de branche se connectent au réseau à l’aide de l’équipement local du client (CPE).
Microsoft Learn

Comment fonctionne la connectivité réseau à distance Global Secure Access ?

Comme pour une connexion VPN classique, une connexion sécurisée via le service Global Secure Access s’appuie sur un tunnel IP Sec :

Pour connecter un réseau distant à Global Secure Access, configurez un tunnel IPSec (Internet Protocol Security) entre votre équipement local et le point de terminaison Global Secure Access. Le trafic que vous spécifiez est acheminé via le tunnel IPSec vers le point de terminaison Global Secure Access le plus proche.
Microsoft Learn

Pourquoi utiliser Global Secure Access pour nos réseaux ?

Global Secure Access propose une approche plus adaptée que les méthodes traditionnelle (WAN / MPLS) en faisant transiter la donnée via le backbone de Microsoft avec une tarification bien plus abordable que ces concurrents :

Il est de plus en plus difficile de maintenir la sécurité d’un réseau d’entreprise dans un monde de travail à distance et d’équipes distribuées. Security Service Edge (SSE) promet un monde de sécurité où les clients peuvent accéder à leurs ressources d’entreprise n’importe où dans le monde sans avoir à renvoyer leur trafic au siège social.
Microsoft Learn

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.
Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un nouvel exercice. Voici quelques liens vers la documentation Microsoft :

J’ai été assez surpris de voir que Microsoft a même écrit un mode opératoire en simulant comme moi le réseau distant sous Azure 😎

Comme Microsoft, mon but est donc de mesurer l’impact dans l’accès aux services 365 en simulant un réseau distant sous Azure et directement connecté Global Secure Access. Les tâches que nous allons réaliser seront donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

Un tenant Microsoft
Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle pour simuler un accès aux services 365 depuis notre réseau distant.

Etape I – Préparation de la VM de test :

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 une image sous Windows Server 2022 :

Choisissez la taille de votre VM, puis définissez un compte administrateur local :

Bloquez les ports entrants, puis cliquez sur Suivant :

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

Retirez l’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 2 minutes :

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

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

Attendez environ 3 minutes que la notification Azure suivante apparaisse :

Notre machine virtuelle est maintenant opérationnelle. La prochaine étape consiste à préparer la connexion VPN côté Azure.

Etape II – Création de la passerelle VPN Azure :

Pour cela, nous allons avoir besoin d’une passerelle VPN Azure. Un ancien article parlait déjà de ce service Azure juste ici.

Recherchez le réseau virtuel créé avec la VM, puis notez sa plage d’adresses réseaux pour la suite :

Profitez-en pour lui ajouter un sous-réseau dédié à la future passerelle VPN :

Cliquez sur Sauvegarder :

Attendez environ 15 secondes que la notification suivante apparaisse :

Recherchez dans le menu Azure le service suivant pour créer la passerelle VPN :

Cliquez-ici pour créer votre passerelle VPN Azure :

Renseignez les informations de base, choisissez le SPU VpnGw1, puis le même réseau virtuel que précédemment :

Désactivez mode actif-actif, activez la fonction BGP, renseignez un numéro ASN valide, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle VPN, puis attendez environ 30 minutes :

Une fois le déploiement terminé, cliquez-ici afin de récupérer quelques informations sur la passerelle VPN :

Allez dans l’onglet Configuration afin de copier ces informations :

Notre passerelle VPN côté Azure est maintenant en place. Nous devons maintenant configurer Global Secure Access d’Entra ID pour reconnaître les demandes de connexion depuis cette passerelle VPN.

Etape III – Configuration du réseau distant sur GSA :

Rendez-vous sur la page suivante du portail Entra, puis cliquez-ici pour mettre en place la connexion réseau côté Microsoft Entra :

Nommez votre connexion, choisissez la région Azure la plus proche de votre réseau distant, puis cliquez sur Suivant :

Ajoutez un lien réseau à votre connexion :

Renseignez les informations de base en reprenant les informations récupérées de la passerelle VPN, puis cliquez sur Suivant :

Conservez les options suivantes, puis cliquez sur Suivant :

Définissez une clef PSK et conservez-là, puis cliquez sur Suivant :

Cliquez sur suivant :

Cochez la seule case possible à ce jour : seul le traffic vers les services Microsoft 365 sera actuellement routé via cette connexion, puis lancez la validation Entra ID :

Une fois la validation Entra ID réussie, lancez la connexion réseau, puis attendez environ 1 minute :

Une notification Entra ID apparaît alors :

Consultez le menu suivant afin de constater la présence d’un réseau distant uniquement sur le profil Microsoft 365 :

Retournez sur le menu des connexions réseaux afin de récupérer des informations :

Récupérez les 3 informations suivantes pour continuer la configuration de la connexion à la passerelle VPN côté Azure :

La configuration réseau côté Global Secure Access est maintenant terminée. Avançons maintenant côté Azure afin que ce dernier reconnaisse également le réseau GSA.

Etape IV – Configuration du réseau GSA sur Azure :

Retournez sur le portail Azure afin de créer passerelle de réseau local correspondant à la connexion configurée sur Global Secure Access.

Pour cela, recherchez le service suivant sur le portail Azure :

Cliquez-ici pour commencer la création :

Renseignez les informations de base, reprenez l’IP publique récupérée sur Global Secure Access, puis cliquez sur Suivant :

Renseignez les autres informations suivantes provenant de Global Secure Access, puis lancez la validation Azure :

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

Attendez que le déploiement de la passerelle de réseau local soit terminé :

Avant de finaliser la configuration VPN, il serait intéressant de tester une connexion vers les services 365 en y incluant une police d’accès conditionnel potentiellement bloquante.

Etape V – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.
Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites via Global Secure Access :

Bloquez l’accès pour toutes les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis retournez sur votre VM de test via une session Azure Bastion :

Lancez un ping sur le site outlook.office.com afin de constater l’IP actuelle du service de messagerie de Microsoft :

Ouvrez Edge sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Constatez le blocage de l’accès conditionnel mis en place précédemment :

Ce test nous confirme que la connexion GSA via un réseau distant ou le client est maintenant obligatoire pour accéder aux services 365.

Finalisons maintenant la connexion entre notre environnement Azure de test et GSA.

Etape VI – Connexion entre le réseau distant et GSA :

De retour sur le portail Azure, cliquez-ici pour mettre en place la connexion entre la passerelle VPN et Global Secure Access :

Définissez la connexion en IP Sec, puis cliquez sur Suivant :

Renseignez les informations de base dont la clef PSK, cochez la case BGP, puis lancez la validation Azure :

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

Attendez que le déploiement de la connexion soit terminé, puis cliquez-ici :

Constatez le statut inconnu de celle-ci :

Retournez sur la page suivante de la passerelle VPN, puis rafraichissez périodiquement afin de constater une changement de status de la connexion :

Le statut devrait changer sous environ 3 minutes :

Consultez la page suivante pour voir les impacts de routage via les communications BGP :

L’environnement est maintenant opérationnel. Il ne reste plus qu’à refaire des tests sur notre machine virtuelle.

Etape VII – Global Secure Access + Accès Conditionnel v2 :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie Microsoft :

Ouvrez Edge en navigation privée sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Cliquez sur Non :

Constatez la bonne connexion au service de Microsoft 365 :

Afin de confirmer nos tests, retirez la connexion entre Azure et GSA pour retrouver le blocage initialement constaté à cause de la police d’accès conditionnelle.

Etape VIII – Retrait de la connexion VPN :

De retour sur le portail Azure, supprimez la connexion VPN Azure précédemment établie :

Confirmez votre choix en cliquant sur Oui :

Attendez que la notification Azure suivante apparaisse :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie de Microsoft :

Constatez le retour du blocage de l’accès conditionnel mis en place précédemment :

Consultez l’évolution du status de la connexion Global Secure Access via le menu suivant :

Constatez le log de connexion vers les services Microsoft 365 ayant transité par le Global Secure Access via le menu suivant :

Conclusion

Ce nouveau test montre encore une fois la grande simplicité de la connexion entre l’on-premise et les services 365 de Microsoft. Aucun doute que ce service devrait connaître un grand succès une fois sorti de sa préversion et quand sa grille tarifaire sera dévoilée 🤣🙏

Le prochain article devrait parler de l’Accès Privé de Global Secure Access. John a déjà pris de l’avance sur moi 🤣

Microsoft 365 via Global Secure Access

2024 est à peine là, mais certaines choses ne changent pas. La sécurité IT reste encore au cœur des préoccupations pour cette nouvelle année. Les façons de consommer la donnée au travers des outils informatiques ont été bouleversées depuis l’arrivée des Cloud publics. Mais ces usages doivent s’accompagner de mesures de sécurité toujours plus performantes.

Microsoft veut changer la partie avec son Global Secure Access. Parcourons ensemble quelques notions sur ce sujet.

Pourquoi Microsoft s’intéresse aux réseaux ?

L’émergence des outils 365, les nombreuses applications disponibles sous format SaaS, les ressources hébergées sur Azure, ou encore les effets du COVID ont fait voler en éclat les approches réseaux traditionnelles.

Partant de ce constat, la sécurité des réseaux, pensée de manière centralisée, a dû elle aussi s’adapter face à au nouveaux usages et fait face à de nouvelles menaces potentielles.

Microsoft est un acteur majeur du Cloud public, et la nouvelle approche sécuritaire des réseaux au-delà de leurs centre de données est donc une évidence pour eux.

Secure Access Service Edge (SASE) vs Security Service Edge (SSE) ?

Il s’agit avant tout de structurer les produits et les services de manière plus cohérentes selon les besoins :

Le SSE définit un cadre limité de la sécurité réseau convergente, qui allie des fonctions SWG, CASB/DLP et ZTNA dans un service cloud natif. Il permet un accès sécurisé aux applications Web, SaaS et métier internes, sans prise en charge directe des ressources WAN. Ce dernier aspect relève toujours d’une solution technologique distincte, englobant des fonctions comme le SD-WAN, les pare-feux nouvelle génération et les backbones réseau globaux.
Cato Networks

Voici d’ailleurs une vidéo pour vous en faire une meilleure idée :

On dit merci qui ? Merci Gartner🤣 !

On peut donc voir le SSE comme un pan clé du pilier sécurité du SASE :

Qu’est-ce que le Zéro Trust (ZT) ?

Le concept Zéro Trust vous dit peut-être déjà quelque chose (ou pas encore) ? Une règle simple et appliquée tout le temps : Ne jamais faire confiance, toujours vérifier.

Considérez simplement chaque demande d’accès comme suspecte :

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.
Zscaler

Qu’est-ce que le Global Secure Access proposé par Microsoft ?

Voyant l’évolution des besoins de sécurité réseaux et la demande grandissante du Cloud, Microsoft a souhaité apporter sa propre solution SSE basée sur ZTNA :

Global Secure Access est l’emplacement unifié du centre d’administration Microsoft Entra et repose sur les principes fondamentaux de confiance zéro, d’utiliser le moindre privilège, de vérifier explicitement et de supposer une violation.
Microsoft Learn

Comme le montre le schéma ci-dessous, Global Secure Access regroupe 2 principaux services :

Accès Internet Microsoft Entra : apporte un accès à Internet via Microsoft Entra et sécurise l’accès aux services Microsoft 365.
Accès privé Microsoft Entra : apporte via Microsoft un accès sécurisé à vos ressources locales et privées.

Voici d’ailleurs un excellent webinar animé par Seyfallah Tagrerout sur le Global Secure Access :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un petit exercice. Mon premier but étant de mesurer son impact dans l’accès aux services 365 en simulant des postes utilisateurs ayant le client Windows Global Secure Access d’installé.

Les tâches que nous allons réaliser sont donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

Un tenant Microsoft
Une souscription Azure valide
Une licence Microsoft Entra ID P1 licence (obligatoire)
Une licence Microsoft 365 E3 (recommandée)

Etape I – Configuration du tenant :

Global Service Access est un service intégré à Microsoft Entra. Vous le trouverez donc uniquement dans ce portail.

Rendez-vous sur la page du portail d’Entra, puis cliquez-ici :

Certains prérequis sont vérifiés automatiquement. Une fois tous ces derniers en vert, cliquez sur le bouton Activer :

Attendez quelques secondes l’apparition de cette notification :

Cliquez-ici afin de continuer :

Cette page vous remontre les 2 principaux services de Global Secure Access :

Cliquez sur le service de votre choix pour en savoir un peu plus :

La documentation Microsoft correspondante s’ouvre alors dans un nouvel onglet :

De retour sur le portail d’Entra, continuer la configuration du Global Secure Access en cliquant sur Journalisation. Cette page nous informe que la Journalisation n’est pas encore activée sur Entra ID :

Activez la sauvegarde en passant par le menu suivant :

Configurez les Paramètres de diagnostic selon vos souhaits en cochant bien les logs nommées EnrichedOffice365AuditLogs :

Retournez sur la page de Journalisation de Global Secure Access afin de contrôler le bon changement :

La configuration de base de Global Secure Access est maintenant terminée.

Avant d’activer le service de Profil d’accès à Microsoft 365, nous allons créer 2 VMs dans Azure pour simuler des postes utilisateurs.

Etape II – Préparation de postes utilisateurs :

Depuis le portail Azure, créez 2 machines virtuelles sous Windows 11 sous un même réseau virtuel :

Sur ce réseau virtuel, déployer le service Azure Bastion afin de vous connecter à ces 2 VMs dépourvues d’IP publiques :

Joignez les deux machines virtuelles créées précédemment à Entra ID selon cet article, puis vérifiez leur présence sur cette page d’Entra ID :

Vérifiez également la présence de ces 2 VMs sur cette page de la console Intune :

Nos machines virtuelles de test sont prêtes.

Créez une premier groupe Entra ID contenant vos 2 utilisateurs de test :

Créez une second groupe Entra ID contenant vos 2 machines Azure de test :

L’environnement Azure est maintenant opérationnel. Retournons sur la configuration de Global Secure Access pour activer le profil dédié aux services Microsoft 365.

Etape III – Configuration du Profil d’accès à Microsoft 365 :

Retournez sur cette page d’Entra ID, puis cochez la case suivante pour activer ce profil sur votre tenant :

Confirmez votre action en cliquant sur OK :

Attendez quelques secondes l’apparition de cette notification :

Vérifiez le changement de statut pour le Profil d’accès à Microsoft 365 :

Pour gérer les détails de la politique de transfert de trafic Microsoft 365, sélectionnez le lien suivant :

Continuons maintenant par l’installation du client Global Secure Access.

Etape IV – Déploiement du client Global Secure Access :

Ce client est nécessaire pour acheminer le trafic réseau vers le service Global Secure Access quand on souhaite s’y connecter en dehors d’un réseau d’entreprise.

Les différents clients de Global Secure Access sont disponibles sur cette page. Cliquez-ici pour télécharger la version Windows 10/11 :

Attendez que le téléchargement se termine :

Si vous le souhaitez, utilisez comme moi l’application Intunewin (Microsoft Win32 Content Prep Tool) afin de packager votre client Global Secure Access et de le déployer via Intune.

Créez votre application sur la console Intune comme Microsoft le préconise :

Attendez environ 30 minutes que l’application se déploie automatiquement sur les 2 machines virtuelles précédemment créées :

L’environnement est enfin prêt pour tester la connexion aux services 365 via Global Secure Access.

Etape V – Test de Global Secure Access :

Ouvrez 2 sessions RDP via Azure Bastion sur les 2 VMs en utilisant respectivement vos 2 utilisateurs Entra ID de test :

Constatez l’ouverture d’une page d’authentification de Global Secure Access, puis connectez-vous-y en utilisant l’identité Entra ID proposée par Windows :

Vérifiez la bonne connexion grâce à l’icône présent dans la barre de tâches :

Afin de comparer les 2 environnements, activez le mode Pause sur l’une des 2 VMs de test :

Cliquez sur le menu suivant du client Global Secure Access afin d’obtenir plus d’informations sur le statut de la connexion :

Comparez les deux checklist et leurs différences :

Vérifiez la présence de la règle concernant le profil Microsoft 365 sur les 2 VMs :

Sur les 2 machines virtuelles de test :

Ouvrez la page d’Outlook sur Edge afin de constater la connexion au service
Lancez une requête PING afin de constater les variations d’adresses IP

Retournez sur la page de log suivante du service Global Secure Access d’Entra ID afin de constater l’apparition de plusieurs lignes de log :

En quelques clics, nous avons mis en place un client Global Secure Access. Continuons un autre test en combinant le Global Secure Access avec l’Accès Conditionnel d’Entra ID.

Etape VI – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.
Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, rendez-vous sur la page suivante d’Entra afin de constater la situation avant activation :

Activez l’option nommée Accès adaptatif sur cette page, puis sauvegardez :

Attendez quelques secondes l’apparition de cette notification :

Retournez sur page suivante d’Entra afin de constater la situation après activation :

Créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites depuis Global Secure Access :

Bloquez l’accès pour les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis ouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Continuons avec un dernier test de restriction de tenant pour Global Secure Access.

Etape VII – Global Secure Access + Restriction au tenant :

Les restrictions imposées aux locataires permettent aux administrateurs de contrôler si leurs utilisateurs peuvent accéder aux ressources d’une organisation externe avec des comptes émis par cette dernière, tout en utilisant le réseau ou l’appareil de votre organisation.
Microsoft Entra

En d’autres termes, une fois connecté au Global Secure Access, plus moyen de s’authentifier sur un tenant tiers si cette option est activée et sans y ajouter le second tenant comme exception.

Pour cela, rendez-vous sur cette même page d’Entra ID, activez l’option suivante puis sauvegardez :

Attendez quelques minutes, puis réouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Conclusion

Par la mise à disposition du Global Secure Access, Microsoft apporte une brique manquante et attendue depuis longtemps dans son approche Zéro Trust. D’autres fonctionnalités comme Remote network vont s’avérer très utile pour sécuriser les connexions depuis et vers le Cloud sans obligatoirement investir dans des solutions de type MPLS.

Enfin, d’autres articles vont bientôt suivre sur la gestion de trafic des autres profils (Private access profile, Internet access profile) 😎

Déplacez votre VM dans une Zone Azure

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

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

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

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

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

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

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

Pourquoi migrer dans une Zone de disponibilité Azure ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Choisissez la zone cible pour la migration :

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

Une notification Azure apparaît également :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Etape IV – Nettoyage des ressources non zonées :

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

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

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

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

Confirmez l’ordre de suppression :

Conclusion

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

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

Copilot for Azure 💙

Comme pour Microsoft 365, Azure a lui aussi droit à son propre Copilot, appelé Copilot for Azure. Par contre, aucune GA n’a pour l’instant encore été annoncée pour ce dernier, seule la préversion est actuellement disponible sur demande et sur approbation de Microsoft. Copilot for Azure est bien une IA fonctionnant sous forme d’assistant, tout en ayant un accès direct aux ressources Azure selon vos droits RBAC.

Un premier article sur ce blog parlant déjà de plusieurs Copilot est disponible juste ici, tandis qu’un autre consacré à l’IA de façon généraliste est accessible juste là.

L’annonce de l’ouverture de la préversion de Copilot for Azure s’est faite durant l’Ignite, la procédure pour la rejoindre avait été détaillée sur le blog Azure :

Microsoft Copilot for Azure est déjà utilisé en interne par les employés de Microsoft et par un petit groupe de clients.

Aujourd’hui, nous sommes ravis de passer à l’étape suivante en annonçant et en lançant l’avant-première pour vous ! Cliquez ici pour vous inscrire.

Nous intégrerons les clients à l’avant-première sur une base hebdomadaire. Dans les semaines à venir, nous ajouterons continuellement de nouvelles fonctionnalités et apporterons des améliorations en fonction de vos commentaires.
Azure Blog

Comme l’indique encore le blog Azure, Copilot for Azure va vous aider principalement à :

Conception : créer et configurer les services nécessaires tout en s’alignant sur les politiques de l’organisation
Exploitation : répondre aux questions, créer des commandes complexes et gérer les ressources
Dépannage : orchestrer les services Azure pour obtenir des informations permettant de résumer les problèmes, d’identifier les causes et de suggérer des solutions
Optimisation : améliorer les coûts, l’évolutivité et la fiabilité par le biais de recommandations pour votre environnement

Que peut-on rêver de mieux? Voici d’ailleurs ce que son grand frère en dit de lui quand on lui pose la question 🤣 :

Voici également une vidéo sur Copilot for Azure déjà réalisée par John Savill :

Tout comme John, je souhaitais partager avec vous mes premières expériences de Copilot for Azure, depuis la demande d’accès jusqu’aux premiers tests sur le portail Azure. Voici quelques prompts réalisés sur mon environnement Azure autorisé :

Avant de pouvoir jouer à Copilot for Azure, il est nécessaire de le mettre en place sur Copilot for Azure sur votre environnment.

Etape 0 – Mise en place de Copilot for Azure :

Comme pour tout produit en préversion chez Microsoft, des contraintes sont présentes :

L’autorisation pour Copilot for Azure portera sur toutes les souscriptions Azure.
Uniquement disponible certains partenaires agréés par Microsoft.
Uniquement disponible sur le Cloud publique d’Azure (Pas de Gov ou China).
Seulement l’anglais est disponible durant la préversion publique.
La préversion publique est gratuite.

Tout commence par le formulaire officiel à accessible par ce lien :

Des informations personnelles et professionnelles sont nécessaires, et il vous faudra également donner votre Tenant ID :

Après avoir rempli votre formulaire, il ne vous reste qu’à l’envoyer :

Voici le message email que vous devriez immédiatement recevoir après l’envoi du formulaire :

Exactement 15 jours plus tard, j’ai reçu avec un immense plaisir le second email suivant :

J’ai donc immédiatement vérifié un éventuel changement sur le portail Azure, rien à ce moment-là :

Par contre, le lendemain, les choses ont bougé et le bouton Copilot y a fait son apparition :

En cliquant dessus, on remarque que Copilot est toujours en préversion, c’est important de le rappeler :

Quelques explications apparaissent, cliquez sur Suivant :

On y apprend les 3 principales limitations à la préversion :

5 ressources impactées max par une action Copilot
10 requêtes max par session de chat avec Copilot
5 chats max par tranche de 24 heures avec Copilot

Enfin l’avertissement sur le besoin actuel et indispensable de vérifier toutes les réponses d’une IA :

Le prompt est maintenant à nous, nous allons pouvoir effectuer quelques tests :

Commençons par une chose simple sur des ressources Azure déjà en place.

Test I – Prompt Analyse (nombre de VMs) :

Demandons à Copilot le calculer nombre de VMs Azure présentes sur mon environnement Azure :

Copilot for Azure nous montre qu’il tient compte des souscriptions filtrées dans ma console et la requête qu’il compte faire sous forme de requête :

La réponse affichée dans le prompt par Copilot for Azure est bien correct :

Je n’ai bien qu’une seule machine virtuelle actuellement visible sur mon tenant de test :

Continuons maintenant avec un prompt de type action sur une ressource Azure.

Test II – Prompt Action (démarrage VM) :

Demandons à Copilot de nous démarrer cette machine virtuelle précédemment listée :

Copilot for Azure comprend la demande et nous demande juste de confirmer l’ordre d’allumage :

Copilot démarre la machine virtuelle et nous invite à suivre l’évolution via la notification Azure :

Une notification Azure apparaît bien suite à la confirmation à Copilot de l’ordre de démarrage :

Environ 1 minute plus tard, la notification Azure confirme bien le démarrage de la VM :

Le statut de la machine virtuelle a bien changé dans la liste des VMs Azure :

Continuons avec un second ordre sur une ressource Azure.

Test III – Prompt Contre-Action (arrêt VM) :

Admettons que la commande précédente ne soit pas celle finalement voulue. Voici ce qui passe avec Copilot si l’on souhaite faire modifier cette action par une autre.

Ma machine virtuelle ci-dessous supporte le mode hibernation décrit sur ce blog ici et là :

Je souhaite que Copilot change son statut, actuellement démarrée, en mode hibernation :

Visiblement, la fonction d’hibernation, encore en préversion, n’est pas encore reconnue par Copilot for Azure :

Copilot me propose malgré tout une autre action proche de celle demandée :

Je confirme mon choix en cliquant sur Oui :

Une nouvelle notification Azure apparait alors :

Le message suivant de Copilot apparaît dans le prompt au même moment :

Environ 30 secondes plus tard, la notification Azure de succès de l’action apparaît :

Le statut de la machine virtuelle a bien changé comme attendu :

Continuons nos tests avec des questions financières relative au Cost Management d’Azure.

Test IV – Prompt Analyse (Coûts Azure) :

Cette machine virtuelle est opérationnelle depuis déjà plusieurs semaines. Posons la question suivante à Copilot afin d’obtenir les coûts depuis le 1er novembre 2023 :

Le résultat n’est selon moi pas correct comme le montre les coûts présents :

Posons la même question afin d’obtenir les coûts depuis le 1er décembre 2023 :

Posons la question en ciblant la VM afin d’obtenir ses coûts depuis le 1er décembre 2023 :

Là encore, et malgré que cette VM est bien souvent en état d’hibernation, des coûts sont constamment présents sur la partie stockage, comme le montre le Cost Management suivant :

Afin d’approcher différemment cette requête financière, j’ajoute un tag sur toutes les ressources Azure concernées :

Et je repose la question à Copilot en ciblant uniquement le tag :

La requête est bien comprise par Copilot for Azure puisque seules des ressources taggées me sont affichées en réponse dans le prompt :

Mais la même réponse d’absence de coûts m’est retournée quand je cherche à savoir combien me coûte les ressources Azure ayant ce même tag :

Continuons nos tests avec d’autres exemples de prompt.

Test V – Prompt Analyse (Infos VM) :

Posons une question simple à Copilot concernant le statut de votre VM :

Les informations retournées sont précises et informatives :

Continuons nos tests avec d’autres exemples de prompt.

Test VI – Prompt Action (création VM) :

Une autre demande à Copilot sur la création de ressource Azure vous donnera toutes les étapes nécessaires, sous forme de commandes CLI, sans pour autant les réaliser pour vous pour l’instannt :

En ouvrant soi-même une fenêtre Azure Cloud Shell et en y copiant les 2 commandes proposées par Copilot, la création de la VM démarre bien :

Voici un second test de création de VM avec plus de paramètres :

Continuons nos tests dans le cas où l’on souhaiterait modifier une ressource Azure déjà en place.

Test VII – Prompt Action (Modification VM) :

Demandons à Copilot de changer la taille de la VM récemment créée :

Malheureseument, Copilot n’effectue pas directement l’action mais repropose une commande CLI.

Une fois la commande manuellement lancée dans Azure Cloud Shell, la taille de la VM est bien modifiée :

Continuons nos tests avec d’autres exemples de prompt.

Test VIII – Prompt Optimisation (Protection VM) :

Demandons à Copilot de l’aide dans la protection d’une machine virtuelle déjà en place :

L’ordre suivant apparaît alors :

Je sélectionne le premier compte de stockage de la liste :

Je confirme mon choix en cliquant sur Oui :

Le traitement d’analyse suivant ce lance alors :

Copilot for Azure m’affiche des conseils de sécurité concernant le compte de stockage sélectionné :

C’est une bonne chose, mais je voulais obtenir des conseils pour ma machine virtuelle😎

Continuons nos tests avec d’autres exemples de prompt.

Test IX – Prompt Analyse (Suppression VM) :

Continuons les tests Copilot par une demande de suppression d’une machine virtuelle Azure :

Copilot for Azure comprend bien la requête et me confirmer l’action de suppression :

La fenêtre habituelle de suppression de ressources apparaît alors :

Je confirme mon choix :

La notification Azure de suppression apparaît alors :

Celle-ci se confirme environ 1 minute plus tard :

La machine virtuelle est bien supprimée :

Continuons nos tests avec un dernier exemple de prompt.

Test X – Prompt Documentation (Azure Virtual Desktop) :

Terminons par une question documentaire sur le déploiement d’un environnement Azure Virtual Desktop :

Plusieurs documentations Microsoft me sont retournées. Peut-être qu’un jour ce blog y sera également en tant que réponse Copilot 🤣

Conclusion

Cette première préversion de Copilot for Azure montre déjà un certain potentiel dans la gestion, la création et l’optimisation des ressources du Cloud. J’ai eu aussi quelques petites erreurs de prompt ou de perte connexion avec les serveurs Copilot.

Nul doute que Copilot va très rapidement gagner en stabilité, apprendre plus de commandes et proposer d’interactions afin de faciliter la vie dans certaines actions basiques ou avancées sur le Cloud Azure.

Azure Site Recovery pour des serveurs sur site

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

Cliquez ensuite sur Suivant :

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

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

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

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

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

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

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

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

Etape II – Configuration Hyper-V :

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

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

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

Rôle DHCP
Rôle Hyper-V

Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

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

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

Shutdown -R

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

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

Pensez à bien choisir Génération 2 :

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

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

Cliquez sur Suivant :

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

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

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

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

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

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

Lancez l’installation de Windows Server 2019 :

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

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

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

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

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

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

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

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

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

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

Depuis Internet Explorer, recherchez puis installez Edge :

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

Etape IV – Configuration Azure Site Recovery :

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

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

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

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

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

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

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

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

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

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

Lancez l’extraction dans le dossier de votre choix :

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

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

Lancez la commande PowerShell suivante :

.\DRInstaller.ps1

Confirmez la réponse avec Y :

Attendez environ 2 minutes que le traitement PowerShell se termine :

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

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

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

Confirmez les utilisateurs voulus, puis cliquez sur Partager :

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

Lancez les 2 actions suivantes respectivement sur les deux VMs :

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

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

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

Cliquez sur Sauvegarder :

Cliquez sur Continuer :

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

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

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

Renseignez vos identifiants Azure :

Réussissez le challenge MFA si nécessaire :

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

Vérifiez la confirmation Azure :

Attendez que l’enregistrement sur Azure se termine :

Cliquez sur Continuer :

Cochez la case suivante puis cliquez sur Continuer :

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

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

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

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

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

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

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

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

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

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

Cliquez sur terminer une fois tous les voyants au vert :

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

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

Etape V – Activation de la réplication :

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

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

Cliquez sur Suivant :

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

Activez la réplication Azure :

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

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

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

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

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

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

Etape VI – Test de la réplication :

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

Consultez les informations dont le RPO :

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

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

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

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

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

Cochez la case suivante, plus cliquez-ici :

Confirmez votre action en cliquant ici :

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

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

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

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

Vérifiez la configuration CPU / Mémoire :

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

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

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

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

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

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

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

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

Conclusion :

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

Hibernez votre AVD ⛄❄️

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.

Etape 0 – Rappel des prérequis :

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 😎

❄️Faites hiberner vos VMs ⛄

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

Qu’est-ce que l’hibernation ?

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

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

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

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

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

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

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

Combien coûte une machine virtuelle éteinte ?

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

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

Combien coûte une machine virtuelle en hibernation ?

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

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

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

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

Quelles sont les VMs compatibles avec le mode Hibernation ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Etape III – Test de l’hibernation :

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

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

Cliquez sur Suivant :

Cliquez sur Accepter :

Ouvrez plusieurs applications sans enregistrer les travails effectués :

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

Confirmez votre choix en cliquant sur Oui :

Attendez environ 1 minute :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Confirmez votre choix en cliquant sur Oui :

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

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

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

Redémarrer la troisième machine virtuelle Azure :

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

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

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

Etape V – Test de l’hibernation :

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

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

Cliquez sur Suivant :

Cliquez sur Accepter :

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

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

Confirmez votre choix en cliquant sur Oui :

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

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

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

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

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

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

Conclusion

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

Attendons de voir la suite 😎💪

Azure Virtual Desktop + GPU = 🏎️

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

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

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

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

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

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

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

Quels sont les GPUs disponibles sur Azure ?

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

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

Un tenant Microsoft
Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

Cliquez sur Accepter :

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

Etape III – Post-configuration GPU 1/2 :

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

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

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

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

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

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

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

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

Lancez la validation Azure :

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

Attendez environ 1 minute :

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

Constatez le bon provisionnement de votre extension GPU NVIDIA :

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

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

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

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

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

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

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

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

Confirmez le dossier de décompression au niveau local :

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

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

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

Cliquez sur Suivant :

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

Attendez environ 2 minutes que l’installation se termine :

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

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

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

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

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

Etape IV – Installation d’applications de test :

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

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

Installation d’AutoCAD :

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

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

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

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

L’installation d’AutoCAD s’ouvre alors :

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

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

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

Installation de FurMark :

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

Cliquez-ici pour lancer l’installation de FurMark :

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

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

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

Pour cela, lancez la commande Sysprep :

Ouvrez le programme Sysprep :

Configurez-le comme ceci, puis cliquez sur OK :

Attendez que Sysprep commence le travail de nettoyage :

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

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

Confirmez votre action en cliquant sur Oui :

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

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

Configurez les options de capture comme ceci :

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

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

Attendez environ 10 minutes que le traitement se termine :

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

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

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

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

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

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

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

Joignez votre VM GPU AVD à Entra ID et à Intune, puis cliquez sur Suivant :

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

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

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer sa configuration :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Etape VII – Post-configuration GPU 2/2 :

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

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

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

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

Continuez comme ceci :

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

Cliquez sur Ajouter un paramètre :

Rechercher les 2 paramètres GPU suivants :

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

Activez ces 3 paramètres comme ceci :

Cliquez sur Suivant :

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

Terminez la création de votre police de configuration.

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

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

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

Etape VIII – Vérification de la configuration GPU :

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

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

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

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

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

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

Recherchez le journal suivant :

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

Constatez la bonne présence des 2 ID suivants :

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

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

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

AutoCAD
FurMark
Clipchamp

Etape IX – Test AutoCAD :

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

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

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

Continuons les tests avec FurMark.

Etape X – Test FurMark :

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

Finissons les tests applicatifs avec Clipchamp.

Etape XI – Test Clipchamp :

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

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

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

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

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

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

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

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

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

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

Conclusion :

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

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

OneDrive & RemoteApp AVD

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.
Microsoft Learn

Cette fonctionnalité ajoutée il y a quelques jours est disponible en préversion publique, comme le dit l’annonce faite par Microsoft sur son Tech Community.

La documentation Microsoft spécifie les quelques ressources indispensables pour utiliser la fonctionnalité, à l’heure où ces lignes sont écrites :

L’environnement AVD doit être configuré comme environnement de validation
La version Windows 11 des VMs AVD doit être en version 22H2, Build 25905 ou ultérieure
Configuration OneDrive :
- OneDrive doit être installé en mode ALLUSER
- OneDrive doit être configuré en mode silencieux

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 :

Etape 0 – Rappel des prérequis :

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 :

Sur la machine AVD, téléchargez OneDrive via la page officielle Microsoft :

Ouvrez une fenêtre PowerShell, en mode administrateur, puis exécutez-y la commande suivante dans le dossier de téléchargement de votre utilisateur :

.\OneDriveSetup.exe /allusers

Attendez que l’installation de OneDrive se termine :

Contrôler que l’installation de OneDrive est bien en mode ALLUSER par la présence de la clef de registre suivante :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OneDrive

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 :

$HKLMregistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\OneDrive'##Path to HKLM keys
$DiskSizeregistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\OneDrive\DiskSpaceCheckThresholdMB'##Path to max disk size key
$TenantGUID = 'XXXXXXXXXXXXX'

if(!(Test-Path $HKLMregistryPath)){New-Item -Path $HKLMregistryPath -Force}
if(!(Test-Path $DiskSizeregistryPath)){New-Item -Path $DiskSizeregistryPath -Force}

New-ItemProperty -Path $HKLMregistryPath -Name 'SilentAccountConfig' -Value '1' -PropertyType DWORD -Force | Out-Null ##Enable silent account configuration
New-ItemProperty -Path $DiskSizeregistryPath -Name $TenantGUID -Value '102400' -PropertyType DWORD -Force | Out-Null ##Set max OneDrive threshold before prompting

Vérifiez la bonne exécution de celui-ci :

Sur la machine de test local, ouvrez une session de bureau à distance depuis l’application Remote Desktop AVD :

Acceptez la finalisation de la configuration SSO entre Entra ID et la VM AVD :

Vérifiez que l’authentification automatique de OneDrive fonctionne et que la synchronisation des fichiers OneDrive démarre bien :

Contrôlez également la présence des fichiers OneDrive depuis l’explorateur de fichiers Windows :

De retour sur la session administrateur de la VM AVD ouverte via Azure Bastion, lancez le script PowerShell suivant :

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name OneDrive -PropertyType String -Value '"C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background' -Force

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.