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

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

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

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

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

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

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

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

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

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

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

Microsoft Learn

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

Choisissez une image OS sous Windows 11 :

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

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

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

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

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

Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :

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

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

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

Vérifiez les caractéristiques du disque :

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

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

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

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

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

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

Choisissez une machine virtuelle de type D8ds_v3 :

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

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

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

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

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

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

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

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

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

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

Cochez la case, puis cliquez sur Suivant :

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

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

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

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

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

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

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

Lancez la validation Azure :

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

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

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

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

dsregcmd /status

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

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

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

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

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

Choisissez une machine virtuelle de type D8ds_v5 :

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

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

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

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

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

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

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

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

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

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

Cochez la case, puis cliquez sur Suivant :

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

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

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

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

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

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

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

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

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

Lancez la validation Azure :

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

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

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

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

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

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

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

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

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

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

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

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

Sur chacune des 3 sessions AVD :

  • Ouvrez le gestionnaire des disques afin de constater les différentes tailles des partitions.
  • Téléchargez l’exécutable DiskSpd via ce lien Microsoft, puis décompressez l’archive ZIP à la racine du disque C.
  • Lancez le moniteur de ressources Windows.
  • Ouvrez une fenêtre PowerShell en mode administrateur, puis exécutez les 2 scripts de tests suivants :
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L C:\diskpsdtmp.dat > IOPS.txt
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L C:\diskpsdtmp.dat > Throughput.txt

Machine virtuelle AVD avec disque OS Premium SSD :

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

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

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

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

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

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

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

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

Etape V – Synthèse des résultats :

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

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

Conclusion

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

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

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

  • Un redimensionnement de la machine virtuelle avec un disque éphémère fera perdre toute la donnée modifiée :
  • Il n’est pas possible de désallouer les ressources machines quand un disque éphémère est utilisé :
  • Il n’est pas possible de sauvegarder une machine virtuelle quand un disque OS éphémère est utilisé :

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

Changez l’URL de votre AVD

Vous la souhaitez plus longue ou plus courte votre URL d’accès à Azure Virtual Desktop ? C’est à vous de choisir ! Mettez en place une URL raccourcie pour accéder à la page d’authentification AVD, vos utilisateurs vous remercieront ! Sinon, il y aussi l’URL AKA.MS d’Azure Virtual Desktop 😎🤘

En parcourant le blog de George Markou, je suis tombé sur le billet suivant : Utiliser un nom de domaine mémorable avec Azure Virtual Desktop.

Aucun doute que cette fonctionnalité pourra être très utile car plusieurs longues URLs Microsoft sont actuellement disponibles pour accéder aux services HTML5 d’Azure Virtual Desktop ou Windows 365:

Mais comment faire pour ajouter une URL de redirection depuis un nom de domaine personnalisé ?

On peut utiliser des sites comme Long URL Maker 🤣, ou faire comme moi en suivant le conseil de George Markou disponible juste ici. Cela donnera alors des URLs courtes pour AVD comme par exemple :

J’ai donc décidé de tester 2 méthodes différentes dans cet article :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests sur la personnalisation de l’URL d’Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un nom de domaine

Commençons par la première méthode basée sur une Static Web App.

Méthode IUtilisation d’une Static Web App :

Avec ce service, vous pouvez rapidement et facilement déployer un site web statique qui redirige vers un autre site web, dans notre cas il s’agirait du client HTML5 Azure Virtual Desktop. En général, Azure Static Web Apps est un service qui construit et déploie automatiquement des applications web complètes sur Azure à partir d’un dépôt de code.

George Markou

Un rapide tour dans le calculateur Azure nous montre l’avantage principal d’une Static Web App : son prix :

Disponible en version gratuite, cette Static Web App devrait correspondre à la majorité des scénarios de redirection Azure Virtual Desktop.

Le schéma ci-dessous nous montre le fonctionnement de redirection de notre Static Web App :

Vous l’aurez probablement compris, nous allons utiliser un peu de code pour effectuer cette direction.

Pour cela, commencez par créer votre compte GitHub si cela n’est pas déjà fait :

Une fois votre compte GitHub créé, rendez-vous sur le répertoire de George via ce lien afin de cloner son répertoire template vers votre compte GitHub :

Nommez ce nouveau répertoire selon vos souhaits, puis cliquer sur Créer :

Attendez quelques secondes que le traitement de copie se termine :

Retournez sur la page du portail Azure afin de recherche le service Static Web App :

Créez votre Static Web App en cliquant ici :

Renseignez les informations de base, dont le nom de votre Static Web App :

Choisissez la source GitHub, authentifiez-vous avec votre compte, choisissez le répertoire nouvellement importé, puis lancez la validation Azure :

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

Environ 1 minute plus tard, cliquez-ici pour consulter votre Static Web App :

Un dossier workflow est maintenant présent sur votre GitHub :

Cliquez sur l’URL suivante pour éditer le workflow :

Cliquez sur le bouton suivant pour éditer le fichier yaml présent sur votre GitHub :

Modifiez la ligne 31 comme ceci :

Avant :

app_location: "/" # App source code path

Après :

app_location: "/src" # App source code path

Cliquez sur Commit changes :

Indiquez si besoin une description, puis cliquez sur Commit changes :

Après quelques secondes, une action GitHub sera déclenchée, poussant le code vers la Static Web App nouvellement créée.

Retournez sur votre Static Web App afin de lui ajouter votre nom de domaine personnalisé :

Saisissez le nom de votre domaine ou sous-domaine, puis cliquez sur Suivant :

Sélectionnez le type CNAME, puis copiez la valeur de celle-ci dans votre presse-papier :

Sur la page de gestion de votre nom de domaine personnalisé, créez un nouvel enregistrement de type CNAME avec comme valeur celle copiée :

Confirmez votre création d’enregistrement DNS :

Attendez quelques secondes l’actualisation de vos enregistrements DNS :

Retournez sur le portail Azure afin de cliquer sur Ajouter :

Attendez quelques secondes qu’Azure confirme la présence de votre enregistrement DNS pointant vers le CNAME indiqué :

Une fois le domaine validé, cliquez sur Fermer :

Dans la liste des domaines personnalisés, vérifiez la présence de votre nouvel ajout :

Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :

Constatez apparition rapide du message de transfert suivant :

Constatez le changement d’URL :

Une fois les services AVD accessibles, cliquez sur l’un d’eux :

Attendez quelques secondes l’établissement de la connexion :

Attendez quelques secondes l’ouverture de la session :

L’URL personnalisée pour Azure Virtual Desktop fonctionne sans souci avec une Static Web App.

Il ne nous reste qu’à tester la même chose avec Azure Front Door.

Méthode IIUtilisation d’Azure Front Door :

Un second tour dans le calculateur Azure nous montre le coût Azure Front Door :

Bien évidemment cela s’explique par la multitude de fonctionnalités disponibles sur Azure Front Door :

Le tableau suivant fournit une comparaison entre 2 SKUs Azure Front Door :

Fonctionnalités et optimisationsFront Door StandardFront Door Premium
Livraison et accélération
Remise de fichiers statiquesOuiOui
Livraison de site dynamiqueOuiOui
Domaines et certificats
Domaines personnalisésOui – Validation de domaine basée sur un enregistrement TXT DNSOui – Validation de domaine basée sur un enregistrement TXT DNS
Prise en charge de HTTPSOuiOui
HTTPS sur un domaine personnaliséOuiOui
Apportez votre propre certificatOuiOui
Versions prises en charge de TLSTLS1.2, TLS1.0TLS1.2, TLS1.0
Mise en cache
Mise en cache des chaînes de requêteOuiOui
Gestion du cache (vidage, règles et compression)OuiOui
Purge rapideNoNon
Préchargement de ressourcesNoNon
Paramètres de comportement du curseurOui à l’aide du moteur de règles standardOui à l’aide du moteur de règles standard
Routage
Équilibrage de charge d’origineOuiOui
Routage basé sur le cheminOuiOui
Moteur de règlesOuiOui
Variable de serveurOuiOui
Expression régulière dans le moteur de règlesOuiOui
Redirection/Réécriture d’URLOuiOui
Double pile IPv4/IPv6OuiOui
Assistance HTTP/2OuiOui
Préférence de routage non mesuréeNon requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connectéNon requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connecté
Port de l’origineTous les ports TCPTous les ports TCP
Moteur de distribution de contenu personnalisable et basé sur des règlesOuiOui
Règles pour appareils mobilesOuiOui
Sécurité
Règles personnalisées du pare-feu d’applications webOuiOui
Ensemble de règles managées MicrosoftNonOui
Protection des botsNonOui
Connexion de liaison privée à l’origineNonOui
GéofiltrageOuiOui
Jeton d’authentificationNoNon
Protection DDOSOuiOui
Analytique et création de rapports
Surveillance MétriquesOui (plus de métriques que Classic)Oui (plus de métriques que Classic)
Analyses avancées/rapports intégrésOuiOui – comprend le rapport WAF
Journaux bruts – journaux d’accès et journaux WAFOuiOui
Journal des sondes d’intégritéOuiOui
Simplicité d’utilisation
Intégration facile avec les services Azure, tels que le stockage et les applications WebOuiOui
Gestion via REST API, .NET, Node.js ou PowerShellOuiOui
Types MIME de compressionConfigurableConfigurable
Encodages de compressiongzip, brotligzip, brotli
Intégration d’Azure PolicyNoNon
Intégration des conseils AzureOuiOui
Identités managées avec Azure Key VaultOuiOui
Tarification
Tarification simplifiéeOuiOui

Dans mon cas, j’utilise déjà un service Azure Front pour mon blog, lui-même hébergé sur une Wep app Azure.

Une fois Azure Front Door en place, rendez-vous dans le menu suivant :

Ajoutez la règle de configuration suivante :

Attendez environ une minute la fin de la création, puis associez à votre règle la route via le menu suivant :

Choisissez une route, puis cliquez sur Suivant :

Modifiez au besoin l’ordre d’exécution des règles, puis cliquez sur Associer :

Attendez environ une minute la fin de l’association :

Retournez dans le menu suivant afin d’ajouter le domaine ou sous-domaine dédié à votre URL Azure Virtual Desktop :

Auprès de votre fournisseur de nom de domaine, ajoutez les 3 enregistrements DNS suivants :

  • A
  • AAAA
  • TXT

Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :

Constatez le changement d’URL :

Une fois les services AVD accessibles, cliquez sur l’un d’eux :

Attendez quelques secondes l’ouverture de la session :

L’URL personnalisée pour Azure Virtual Desktop fonctionne là aussi sans souci avec Azure Front Door.

Conclusion

Quelle que soit la méthode choisie pour la personnalisation de votre URL Azure Virtual Desktop, celles-ci sont simple et facile à mettre en oeuvre et facilitera la vie de vos utilisateurs 🥳

Azure Virtual Desktop sur Azure Stack HCI

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

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

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

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

Qu’est-ce qu’Azure Arc Jumpstart ?

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

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

Azure Arc Jumpstart

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

Mais qu’est-ce qu’HCIBox ?

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

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

Azure Arc Jumpstart

Combien coûte le service HCIBox ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

az --version

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

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

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

az account set

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

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

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

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

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

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

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

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

Le statut du fournisseur de ressources change durant cette phase :

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

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

az bicep upgrade

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

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

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

Etape II – Déploiement des ressources Azure :

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

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

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

Déplacez le fichier template dans le dossier Bicep :

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

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

cd ./azure_arc/azure_jumpstart_hcibox/bicep/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Configuration de la virtualisation :

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

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

Démarrage des 3 machines virtuelles :

Configurations réseaux et stockages :

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

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

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

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

C:\HCIBox\Logs\

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

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

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

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

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

  • TelemetryAndDiagnostics
  • AzureEdgeLifecycleManager
  • AzureEdgeDeviceManagement

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

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

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

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

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

  • Administrateur Key Vault
  • Contributeur au compte de stockage

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

Cliquez-ici pour continuer :

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

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

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

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

Cliquez sur Editer les paramètres :

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

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

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

Attendez que ce dernier soit terminé :

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

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

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

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

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

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

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

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

Lancez la mise à jour 2402 comme ceci :

Cliquez sur Suivant :

Cliquez sur Suivant :

Lancez l’installation de la mise à jour :

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

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

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

  • les images OS
  • les réseaux logiques

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

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

Azure Arc Jumpstart

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

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

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

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

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

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

Network details
Subnet192.168.200.0/24
Gateway192.168.200.1
VLAN Id200
DNS Server192.168.1.254

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

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

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

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

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

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

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

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

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

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

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

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

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

Cliquez-ici pour ajouter une carte réseau :

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

Cliquez sur Suivant :

Ajoutez au besoin des tags, puis cliquez sur Suivant :

Cliquez sur Créer :

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

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

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

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

Utilisez le compte suivant :

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

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

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

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

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

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

Utilisez le compte de domaine suivant :

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

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

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

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

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

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

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

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

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

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

Attendez environ 1 heure :

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

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

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

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

Copiez le script suivant pour sa mise en place :

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

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

Collez le script sur la VM AVD :

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

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

Rafraichissez la page plusieurs fois si nécessaire :

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

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

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

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

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

Renseignez à nouveau le mot de passe de votre utilisateur :

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

Conclusion

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

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

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

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

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

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

Coûts licences utilisateurs :

Coûts licences infra :

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

FSLogix sont nos amis 🙏!

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

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

La solution FSLogix en quelques mots & vidéos :

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

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

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

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

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

Mais aussi d’autres sources non-Microsoft :

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

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

Etape 0 – Contexte :

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

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

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

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

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

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

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

Voici une vue de l’environnement Azure Virtual Desktop :

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

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

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

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

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

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

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

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

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

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

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

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

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

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

Je renseigne les identifiants :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Je lance toutes les mises à jour Windows 11 disponibles :

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

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

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

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

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

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

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

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

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

Et la suite se passe de commentaire 🤣.

Etape III – Identification de la cause :

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

Et je tombe sur celui-ci 😎 :

Microsoft propose également une résolution juste ici :

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

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

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

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

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

Sysprep /generalize /oobe /mode:vm /shutdown

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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 :

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énarioAssistance techniqueDétails
Machine virtuelle à instance uniquePrise en chargeLe 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 uniformeNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexibleNon pris en charge
Régions prises en chargePrise en chargeSeules 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 chargeLe 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 virtuelleNon pris en chargeLe 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 fiablePrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentiellesPrise en chargeRé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 chargeLe 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ésPrise en chargeL’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activéePrise 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éesPrise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)Prise en charge
Stratégies RBAC de machine virtuelleNon pris en chargeLe 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éseauPrise 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 :

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

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

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

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

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

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

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

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

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

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

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

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

Choisissez la zone cible pour la migration :

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

Une notification Azure apparaît également :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Etape IV – Nettoyage des ressources non zonées :

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

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

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

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

Confirmez l’ordre de suppression :

Conclusion

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

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

Azure Site Recovery pour des serveurs sur site

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

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

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

Microsoft Learn

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

Cliquez ensuite sur Suivant :

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

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

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

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

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