Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.
Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.
Microsoft préconise cette approche pour AVD :
À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.
Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.
La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.
En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.
Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.
Voici donc les quelques chapitres dans mon article :
Pour réaliser mon test, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons par créer une machine virtuelle sous Windows 11.
Etape I – Création d’une machine virtuelle :
Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :
Comme attendu, l’écran de démarrage est par défaut en anglais :
L’interface utilisateur l’est également :
Allons voir dans Language et région :
Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :
Seul le pack Anglais (USA) semble installé :
Cela se confirme par la commande suivante :
Get-InstalledLanguage
Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :
Le pays est là encore défini sur USA, peu importe le région Azure utilisée :
De façon logique, le formatage Anglais (USA)y est également appliqué :
Continuons avec l’administration des paramètres de la langue :
Un clic pour consulter les 3 types de paramétrage :
Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA):
Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.
Etape II – Modification de la langue via script :
Commençons par ouvrir une fenêtre PowerShell ISE :
Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :
Get-InstalledLanguage
Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :
$regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
$RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
$Language : modifier au besoin le language (liste)
En cette fin juin 2024, Microsoft nous partage un peu plus d’informations sur la future MFA obligatoire à venir pour Azure à partir de juillet 2024. Plusieurs grandes étapes sont maintenant mentionnées et intégrées dans un planning qui démarre dès cet été et se terminera début 2025. De plus, Microsoft nous propose également donc quelques outils pour nous y préparer.
Un second post sur le Tech Community est apparu hier sur ce même sujet, et nous donne quelques informations sur les 2 phases de cette obligation liée à Azure :
Phase 1 – À partir de juillet 2024 : La notification puis l’obligation de la MFA pour le portail Azure sera progressivement étendue à tous les tenants.
Phase 2 – À partir de début 2025 : La notification puis l’obligation de la MFA aux outils de commande liés à Azure : CLI, Azure PowerShell et les outils Infrastructure as Code (IaaC) sera progressivement étendue à tous les tenants.
Partant de ces informations, nous pouvons en déduire les points suivants :
Portail Azure : Le portail Azure est utilisé par les humains, il faudra alors former les utilisateurs et configurer pour chacun d’entre eux une méthode MFA.
Autres outils : D’autres outils (CLI, Cloud Shell, …) sont utilisés par les humains et certains applications. Ces dernières pourront elles faire l’objet d’une bascule vers des identités managés ou des comptes de service.
Impact progressif : Les entreprises utilisant Azure doivent se préparer à une transition progressive des tenants. Elles auront le temps d’ajuster leurs configurations et de résoudre les problèmes potentiels avant que l’implémentation complète ne soit réalisée.
Microsoft a t-il prévu de notifier les administrateurs Azure ?
Microsoft a privilégié la notification des administrateurs globaux 60 jours avant la mise en application des phases 1 et 2. Cela sans doute pour laisser les entreprises organiser les messages et notifications en interne aux personnels Azure impactés par cette mesure.
Le compte à rebours de la mise en application pour votre/vos tenant(s) ne commence pas tant que vous n’avez pas reçu cette première notification de notre part. En outre, nous enverrons des rappels périodiques aux administrateurs globaux à intervalles réguliers entre la première notification et le début de la mise en application pour votre/vos tenant(s).
Pourrons-nous déroger temporairement à cette règle pour un tenant ?
Les mails de notification envoyés par Microsoft devraient comporter un lien pour activer une période de grâce, afin de pouvoir gérer les imprévus :
La première notification de notre part indiquant la date de mise en application pour votre/vos tenant(s) inclura également un lien pour demander la période de grâce. Des détails supplémentaires sur les types de clients, les cas d’utilisation et les scénarios éligibles à la période de grâce seront inclus dans la notification.
MFA pour tout Azure, mais vraiment pour tout le monde ?
Microsoft avait déjà été clair sur ce point, j’en avais également parlé dans mon précédent article :
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement.
Malgré cette information, une confusion a déjà pu s’installer, et c’est pour cela que ce second post de Microsoft reprécise que les utilisateurs finaux non gestionnaires d’Azure ne seront pas impactés :
Les utilisateurs finaux qui accèdent à des applications, des sites web ou des services hébergés sur Azure, mais qui ne se connectent pas au portail Azure, à la CLI ou à PowerShell, ne sont pas soumis à cette exigence de Microsoft. Les exigences d’authentification pour les utilisateurs finaux seront toujours contrôlées par les propriétaires de l’application, du site web ou du service.
Quid des accès conditionnels d’Entra ID ou de la sécurité par défaut ?
Microsoft a décidé d’implémenter ce contrôle MFA en amont des mesures de sécurité actuelles :
Sécurité par défaut activée : aucun changement car la MFA est déjà requise pour accéder aux outils Azure.
Accès conditionnel Azure : une police d’accès conditionnel plus restrictive et nécessitant une authentification plus forte que cette nouvelle règle sera appliquée en priorité.
Quid des comptes « brise-glace » ?
En mai dernier, Microsoft ne donnait pas encore de méthodes spécifiques pour ces comptes d’urgence. C’est maintenant chose faite :
Nous avons pris connaissance de vos questions concernant les comptes « verre cassé » ou « accès d’urgence ». Nous recommandons de mettre à jour ces comptes pour qu’ils utilisent FIDO2 ou l’authentification basée sur un certificat (lorsqu’elle est configurée en tant qu’AMF) au lieu de s’appuyer uniquement sur un mot de passe long. Ces deux méthodes satisferont aux exigences de l’AMF.
Pour éviter les soucis de connexion le jour J, Microsoft propose un outil de type tableau de bord, et une commande PowerShell d’extraction sous format EXCEL. Ces deux outils donne plus de visibilité sur les utilisateurs Azure concernés et mal préparés. Voici les deux liens directs mis à disposition par Microsoft :
Authentifiez-vous avec un compte disposants des autorisations nécessaires :
Acceptez les permissions demandées :
Une fois l’authentification terminée, fermez la fenêtre du navigateur :
Attendez que l’export Excel se termine :
Ouvrez le fichier Excel généré :
Constatez sur le premier onglet un tableau récapitulatif des utilisateurs qui se sont connectés au portail Azure, à Azure CLI ou à Azure PowerShell au cours des 30 derniers jours en interrogeant les journaux de connexion et de leur méthodes MFA enregistrées :
✅ MFA Capable + Signed in with MFA : L’utilisateur a enregistré des méthodes d’authentification MFA et s’est connecté avec succès au moins une fois à Azure en utilisant MFA.
✅ MFA Capable : L’utilisateur a enregistré des méthodes d’authentification MFA mais s’est toujours connecté à Azure en utilisant l’authentification à facteur unique.
❌ Not MFA Capable : L’utilisateur n‘a pas encore enregistré de méthode d’authentification multifacteur et ne s’est pas connecté à Azure à l’aide de MFA.
Constatez sur le second onglet un graphique et des totaux des utilisateurs prêts ou non :
Conclusion – Comment se préparer avant le jour J ?
Commencez dès à présent à créer une nouvelle règle d’accès conditionnel équivalente à la future implémentation prévue par Microsoft. Il existe un template de police d’accès conditionnel très proche du résultat attendu :
Cette police cible la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement est un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Vous pourrez par la suite changer son statut sur ON :
Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.
Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :
Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.
You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.
This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.
Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.
Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45
If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.
Required action
We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.
Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.
If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.
If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.
————————————————————-
Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :
Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.
La date limite de transition est prévue pour le 26 juin 2024 :
Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.
Les actions requises :
Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
Contactez votre administrateur global Azure pour planifier ces mises à jour.
Mettre à jour votre documentation interne et informer votre service d’assistance.
Le support :
Pour des questions, consultez la communauté Microsoft Q&A ou ouvrez un cas de support dans le portail Azure.
En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :
Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.
Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :
Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.
Tâche I – Premier test AVD sans SSO :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de l’utilisateur AVD :
Confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Renseignez à nouveau votre identifiant et mot de passe utilisateur :
Confirmez à nouveau votre choix en cliquant sur Continuer :
Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :
Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :
Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.
L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :
Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.
Tâche IV – Configuration AVD pour activer l’authentification unique:
Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :
Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :
Tâche V – Second test AVD avec SSO :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de cet utilisateur :
Confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :
La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.
Tâche VI – Accès conditionnel actuel AVD (Portail) :
Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :
Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)
Voici l’impact sur l’utilisateur AVD quand cette première police est activée :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de ce premier utilisateur AVD :
L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :
Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
Tâche VII – Accès conditionnel actuel AVD (VM) :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de ce second utilisateur AVD :
Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :
L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.
Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de cet utilisateur :
L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Conclusion
Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.
En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘
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.
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 :
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 1minute :
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 :
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 😎🙏.
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 😎🤘
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 :
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 I – Utilisation 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.
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 II – Utilisation 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 optimisations
Front Door Standard
Front Door Premium
Livraison et accélération
Remise de fichiers statiques
Oui
Oui
Livraison de site dynamique
Oui
Oui
Domaines et certificats
Domaines personnalisés
Oui – Validation de domaine basée sur un enregistrement TXT DNS
Oui – Validation de domaine basée sur un enregistrement TXT DNS
Prise en charge de HTTPS
Oui
Oui
HTTPS sur un domaine personnalisé
Oui
Oui
Apportez votre propre certificat
Oui
Oui
Versions prises en charge de TLS
TLS1.2, TLS1.0
TLS1.2, TLS1.0
Mise en cache
Mise en cache des chaînes de requête
Oui
Oui
Gestion du cache (vidage, règles et compression)
Oui
Oui
Purge rapide
No
Non
Préchargement de ressources
No
Non
Paramètres de comportement du curseur
Oui à l’aide du moteur de règles standard
Oui à l’aide du moteur de règles standard
Routage
Équilibrage de charge d’origine
Oui
Oui
Routage basé sur le chemin
Oui
Oui
Moteur de règles
Oui
Oui
Variable de serveur
Oui
Oui
Expression régulière dans le moteur de règles
Oui
Oui
Redirection/Réécriture d’URL
Oui
Oui
Double pile IPv4/IPv6
Oui
Oui
Assistance HTTP/2
Oui
Oui
Préférence de routage non mesurée
Non 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’origine
Tous les ports TCP
Tous les ports TCP
Moteur de distribution de contenu personnalisable et basé sur des règles
Oui
Oui
Règles pour appareils mobiles
Oui
Oui
Sécurité
Règles personnalisées du pare-feu d’applications web
Oui
Oui
Ensemble de règles managées Microsoft
Non
Oui
Protection des bots
Non
Oui
Connexion de liaison privée à l’origine
Non
Oui
Géofiltrage
Oui
Oui
Jeton d’authentification
No
Non
Protection DDOS
Oui
Oui
Analytique et création de rapports
Surveillance Métriques
Oui (plus de métriques que Classic)
Oui (plus de métriques que Classic)
Analyses avancées/rapports intégrés
Oui
Oui – comprend le rapport WAF
Journaux bruts – journaux d’accès et journaux WAF
Oui
Oui
Journal des sondes d’intégrité
Oui
Oui
Simplicité d’utilisation
Intégration facile avec les services Azure, tels que le stockage et les applications Web
Oui
Oui
Gestion via REST API, .NET, Node.js ou PowerShell
Oui
Oui
Types MIME de compression
Configurable
Configurable
Encodages de compression
gzip, brotli
gzip, brotli
Intégration d’Azure Policy
No
Non
Intégration des conseils Azure
Oui
Oui
Identités managées avec Azure Key Vault
Oui
Oui
Tarification
Tarification simplifiée
Oui
Oui
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 🥳
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.
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.
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 :
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 :
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 :
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œudsconnecté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 file
Description
C:\HCIBox\Logs\Bootstrap.log
Output from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.log
Output 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.log
Log output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.log
Log output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.log
Log 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) :
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.
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
Subnet
192.168.200.0/24
Gateway
192.168.200.1
VLAN Id
200
DNS Server
192.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 :
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 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 :
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 :
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
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.
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.
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 :
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 :
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 :
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 🙏
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.
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 😎
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.
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 :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur 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 :
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 😎🥳