Endormez vos VMs AVD inutilisées 🛏

Azure Virtual Desktop propose deux types d’environnement virtualisé en fonction des usages attendus. Voici une méthode simple de les différencier :

Environnement partagé : plusieurs utilisateurs sur une machine virtuelle
Environnement individuel : un utilisateur par machine virtuelle

Seulement ces types d’environnement ne conviennent pas à tous les usages. Par exemple, des besoins variés entre les utilisateurs, des droits d’administrateurs ou encore une fréquence d’utilisation ponctuelle d’Azure Virtual Desktop correspondent plus à un environnement AVD individuel.

Dans cet article, nous allons justement nous intéresser aux environnements AVD individuels. La configuration de ces machines mono-utilisateur permet de diminuer les coûts quand ces dernières sont uniquement démarrées si leur utilisateur a en réellement besoin.

Justement, que propose Azure pour allumer et éteindre les machines AVD ?

Pour les environnements AVD partagés, le démarrage et l’arrêt des machines virtuelles est configurable dynamiquement grâce à la nouvelle fonction d’autoscalling : un article est déjà disponible sur ce blog juste ici.

En quelques mots, la fonction de mise à l’échelle automatique (autoscalling) vous permet de démarrer des machines virtuelles Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre selon les besoins à l’instant T.

Est-ce aussi compatible pour les environnements AVD individuels ?

Oui pour le démarrage des machines virtuelle. Appelé démarrage à la demande, sa mise en place est très simple. Un autre article de ce blog en parle juste ici.

En quelques mots, l’utilisateur se connecte et attend quelques minutes, si la machine est éteinte, le temps qu’Azure démarre sa machine virtuelle AVD. Voici également une vidéo de Dean qui en parle très bien :

Quand s’éteindra alors sa machine individuelle AVD ?

Concernant l’arrêt de sa machine virtuelle individuelle AVD, il n’existe pas encore d’option native qui agit dynamiquement. Par défaut, l’arrêt d’une machine virtuelle Azure est :

Manuel : réalisé par script ou depuis le portail Azure.
Programmé : via la fonction auto-shutdown, configurable individuellement sur chaque VM.

Cette seconde option pose un souci dans un environnement AVD : l’absence de corrélation entre un auto-shutdown à heure fixe durant l’utilisation d’AVD risque de déconnecter à tort des utilisateurs.

Est-il envisageable de laisser l’utilisateur éteindre sa propre machine virtuelle ?

Cela vous oblige à lui donner des droits sur une ressource Azure : sa machine virtuelle 🤷‍♀️

Que peut-on faire pour gérer dynamiquement l’arrêt des machines virtuelles individuelles AVD ?

Azure est une chose flexible 😋 Une combinaison de services est possible pour arriver à cet objectif. Soyons clair, je n’ai rien trouvé n’y inventé, mais je me suis appuyé sur cette excellente documentation Microsoft.

Comme le montre le schéma ci-dessous, différentes étapes sont présents pour arriver à l’arrêt complet du service Azure :

Premier déclencheur = déconnecte l’utilisateur inactif
Second déclencheur = éteint l’OS de la machine virtuelle
Troisième déclencheur = désalloue la ressource Azure

*Un mécanisme anticipe le retour de l’utilisateur avant l’arrêt de l’OS.*

Différents composants sont nécessaires pour réaliser toutes ces étapes :

Ressources Azure :
- Automation Account / Runbook / Identité managé
- Alertes journalisées / Groupe d’action
Ressources Windows :
- GPOs ou Polices locales
- Tâches planifiées
- Scripts

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ce test sur un environnement individuel AVD :

Un tenant Microsoft
Une souscription Azure valide

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

Pour déployer rapidement un environnement AVD joint à Azure AD, déployez un réseau virtuel Azure :

Continuez en déployant un environnement individuel AVD :

Ajoutez une ou plusieurs machines virtuelles pour les tests :

Renseignez les informations de réseau et un identifiant / mot de passe pour l’administrateur local :

Créez votre espace de travail AVD :

Une fois validation terminée, lancez la création des ressources Azure Virtual Desktop :

Attendez que le déploiement de votre AVD se termine :

Etape III – Finalisation de la configuration initiale :

Quelques opérations sont nécessaires pour finaliser l’installation de l’environnement AVD.

Ajoutez les 3 rôles Azure RBAC suivants sur votre groupe de ressources AVD :

Contributeur à la mise en route de la virtualisation des postes de travail : permet à l’application AVD de démarrer une machine virtuelle éteinte.
Utilisateur de la virtualisation du poste de travail : assigne l’utilisateur au groupe d’applications AVD.
Connexion de l’administrateur de la machine virtuelle : autorise l’utilisateur à se connecter à distance sur sa machine virtuelle avec les droits d’administrateur local.

Activez cette option pour mettre en route la fonction d’authentification SSO entre Azure AD la machine virtuelle AVD (expliquée juste ici) :

Activez la fonction de démarrage à la demande (expliquée juste ici et documentée officiellement là) :

Assignez votre utilisateur AVD de test à une des machines virtuelles :

Etape IV – Test de l’environnement AVD :

Avant de déployer la solution de configuration d’arrêt dynamique, testez le bon fonctionnement de l’accès à votre environnement AVD avec votre utilisateur de test.

Depuis votre poste local, connectez-vous à l’URL suivante, puis renseignez vos identifiants :

Ouvrez la session de bureau à distance AVD :

Acceptez la fin de la configuration SSO :

Attendez que la session Windows s’ouvre :

Une fois connecté, fermez la session utilisateur :

Depuis votre portail Azure, éteignez la machine virtuelle AVD :

Relancez la même connexion AVD depuis la page web de votre utilisateur de test :

Constatez la présence du message du démarrage de la machine virtuelle, vous invitant à patienter :

Attendez quelques minutes et constatez l’ouverture de la session Windows AVD :

Si tout fonctionne correctement pour vous, continuez la suite de cet article pour configurer l’arrêt dynamique AVD.

Etape V – Configuration des composants Azure

Pour cela, créez un compte Azure Automation :

Une fois la validation terminée, lancez sa création :

Une fois la ressource créée, allez dans le service appelé Azure Monitor :

Ajoutez une Règle d’alerte d’état de santé comme ceci :

Cochez uniquement les 4 conditions suivantes de cette façon :

Créez un nouveau Groupe d’action :

Rattachez le Groupe d’action à votre compte Azure Automation précédemment créé :

Lancez la création de votre Groupe d’action :

Nommez votre Règle d’alerte :

Lancez la création de votre Règle d’alerte :

L’étape suivante concerne maintenant la configuration Windows des machines virtuelles AVD. Il est possible de l’établir cela par :

des Polices locales sur chaque VM AVD
des GPOs créées sur un Active Directory

N’ayant pas d’Active Directory dans mon environnement de test, nous allons créer des polices locales sur la machine AVD de test. C’est aussi votre cas si les machines virtuelles AVD sont jointes à Azure AD.

Etape VI – Configuration des composants Windows

Comme votre utilisateur de test est considéré comme un administrateur local, ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :

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

Nommez la Tâche planifiée, puis cochez les cases suivantes :

Ajoutez un déclencheur sur le second onglet :

Choisissez le motif de déconnexion avec un délai de 30 minutes :

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

/f /s /t 0

Validez la création de la Tâche planifiée, puis lancez la création d’une seconde Tâche planifiée :

Choisissez le démarrage de la Tâche planifiée avec l’ouverture d’une session utilisateur :

Sur la VM AVD, créez un nouveau fichier texte avec les lignes ci-dessous :

@echo off
schtasks /change /tn  Disconnect /disable
schtasks /change /tn  Disconnect /enable
exit

Enregistrez-le sous le nom reset.cmd dans le dossier C:\Windows\System32 :

Appelez-le dans l’action de la Tâche planifiée :

Validez la création de la Tâche planifiée :

Ouvrez le Gestionnaire de police locale :

Naviguez dans l’arborescence suivante :

Configuration utilisateur
- Paramètres Windows
  - Scripts (Logon/Logoff)

Cliquez sur le script suivant :

Cliquez sur Ajouter :

Ajoutez le nom de script suivant :

C:\Windows\System32\tsdiscon.exe

Validez ce script en cliquant sur OK :

Toujours dans le Gestionnaire de police locale, naviguez dans la seconde arborescence suivante :

Configuration utilisateur
- Modèle administratif
  - Composants Windows
    - Services de bureau à distance
      - Hôte de session de bureau à distance
        
        Limite de temp de session

Cliquez sur la configuration suivante :

Configurez comme ceci, puis validez vos modifications :

Etape VII – Test de la configuration

Il ne reste qu’à tester tout ça 🤣🤣 Voici un rappel des temps de phase configurés :

Avant la première authentification de mon utilisateur AVD, la VM qui lui est attitrée est désallouée, comme le montre le portail Azure ci-dessous :

Je connecte mon utilisateur de test au bureau AVD. Comme sa machine virtuelle est en statut désalloué, je dois attendre quelques minutes pour accéder à son bureau Windows :

Quelques minutes plus tard, la session Windows s’ouvre sans autre action de sa part ni de la mienne :

Le statut de la machine virtuelle AVD a lui aussi changé dans Azure :

Son horloge Windows indique 19:31, j’attends donc les 30 minutes nécessaires, sans effectuer aucune activité sur la session AVD. Environ 30 minutes plus tard, le message suivant apparaît sur sa session AVD :

Si rien n’est fait pendant ces deux minutes, la suite logique est la déconnexion de cet utilisateur :

A ce moment-là, Le portail Azure nous affiche que la machine virtuelle est toujours bien fonctionnelle :

Par contre, AVD reconnait bien que sa session AVD est bien en statut déconnecté :

Environ 30 minutes après la déconnexion de l’utilisateur de test, sa machine virtuelle AVD passe en statut arrêté :

La machine virtuelle devient alors indisponible pour le service AVD :

Environ 5 minutes plus tard , la machine virtuelle passe en statut désalloué :

Une nouvelle tentative d’ouverture AVD depuis le portail utilisateur relancera le démarrage de sa machine virtuelle :

Conclusion

La mise en place de la configuration de déconnexion des sessions inactives fonctionne très bien dans les environnements individuels d’Azure Virtual Desktop. Cette approche va sans nul doute diminuer les coûts liés au Cloud pour des besoins spécifiques et/ou périodiques, sans avoir à se soucier du démarrage et de l’arrêt des machines virtuelles individuelles.

Il sera même intéressant de combiner cette approche avec des instances réservées. Le nombre d’instances réservées approprié dépendra du plancher constant d’utilisateurs AVD connectés.

Peut-on booster les FPS de votre Azure Virtual Desktop ?

L’amélioration de l’expérience utilisateur est une tâche constante. Azure Virtual Desktop simplifie et sécurise grandement l’accès aux ressources de l’entreprise. Mais AVD reste un environnement de bureau à distance. A caractéristiques égales, une ressource IT distante a un désavantage en comparaison avec une ressource locale de même grandeur : plusieurs paramètres rentrent en ligne de compte, comme le choix des réseaux (performances, types, …) ou encore le protocole de transmission utilisé.

Azure Virtual Desktop se doit donc de continuer d’évoluer. Plusieurs améliorations consacrées à l’expérience utilisateur ont déjà fait l’objet d’articles sur ce blog :

Concernant ce dernier point, je viens de faire remarque intéressante sur la généralisation du protocole UDP sur les réseaux publics pour un environnement AVD, dont je vous partage l’info juste ici.

Dernièrement, Microsoft propose quelques améliorations pour augmenter la fréquence du nombre d’images sur une session AVD. Cette donnée est importante pour la fluidité des animations ou des vidéos.

Je tiens à remercier Alexandre Moreaux pour son aide précieuse dans la réalisation des tests nécessaire à la rédaction de cet article !

Voici un site web montrant différents exemples de fréquence d’affichage sur un poste local :

M’appuyant sur cette vidéo de Dean, j’ai souhaité mettre en pratique ses conseils.

Pour avoir une meilleure idée sur le sujet, cet article va comparer différentes configurations pour en mesurer l’impact sur les FPS.

Plusieurs environnements Azure Virtual Desktop sont donc nécessaires. Les 4 premiers sont basés sur une machine virtuelle de type D8s v5 et vont servir à effectuer les tests suivants :

Environnement 0 : témoin de base, aucune modification
Environnement 1 : augmentation de la limite FPS pour les connexions RDS
Environnement 2 : augmentation FPS + priorité du décoding graphique
Environnement 3 : augmentation FPS + priorité + configuration du décoding graphique

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ces tests sur AVD :

Un tenant Microsoft
Une souscription Azure valide
4 réseaux virtuels Azure, un par environnement AVD
4 machines virtuelles AVD jointes à Azure AD

Vous pouvez créer rapidement et simplement les environnements AVD en suivant cet article. Voici quelques copies d’écran d’un des 4 environnements AVD créés pour mes tests :

N’oubliez pas de configurer les éléments suivants pour rendre accessible vos environnements AVD :

Rôle RBAC Connexion de l’utilisateur de la machine virtuelle à votre utilisateur de test
Rôle RBAC Connexion de l’administrateur de la machine virtuelle à votre utilisateur admin
Assignation du groupe d’application AVD à votre utilisateur de test + utilisateur admin

Etape I – Test sur votre poste local

Afin de se faire une meilleure idée de l’impact d’une session ouverte via RDP, rendez-vous sur la page suivante depuis votre poste physique. Vous devriez obtenir généralement les 3 fréquences FPS suivantes : 60 / 30 / 15.

Dans cet ordre de grandeur, l’œil humain distingue assez facilement l’impact du nombre d’images par seconde. Il est temps de comparer le poste physique avec la première machine AVD.

Etape II – Test de l’environnement témoin :

Connectez-vous à votre premier environnement AVD, appelé témoin :

Réouvrez cette même page de test FPS sur la session AVD via un navigateur internet. Le plafonnement devrait être aux alentours de 30 FPS :

Un clic sur l’icône d’information de connexion RDP vous indique également le nombre d’image traitées et le protocole utilisé :

Les sessions à distance par le protocole RDP sont en effet limité par défaut sur le nombre maximal d’images.

L’étape suivante va vous permettre de modifier cette limite et de recomparer le rendu sur les deux environnements AVD.

Etape III – Test de la modification de la limite FPS

Pour bien différencier ce premier changement, connectez-vous sur votre seconde machine AVD de test :

Cet article sur Microsoft Learn explique comment augmenter la limite de fréquence d’images dans une session à distance :

Depuis le menu Démarrer, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :

Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :

Ouvrez l’éditeur de registre Windows :

Saisissez l’arborescence suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations

Créez une nouvelle clef DWORD

Donnez-lui le nom suivant :

DWMFRAMEINTERVAL

Assignez-lui la valeur décimale suivante, puis cliquez sur OK :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL  /t REG_DWORD /d 15 /f

Fermez la session de votre utilisateur AVD.

Rouvrez la session sur la même machine AVD.

Ouvrez la même page de test FPS que sur la première machine AVD. Le plafonnement devrait être maintenant aux alentours de 60 FPS :

Avons-nous donc maintenant 60 FPS ?

Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique en revanche un nombre bien plus faible pour le nombre d’image traitées, malgré la grandeur du débit disponible par le protocole UDP.

Continuons les tests en suivant toujours les conseils de Microsoft.

Etape IV – Test de la modification de la limite FPS + Priorité au décoding

Ce nouveau test reprend la modification de registre apportée par l’étape III et rajoute en plus la priorité au décoding graphique. Vous pouvez donc reprendre la même machine AVD précédemment utilisée, ou repartir sur une nouvelle machine avec les deux modifications :

Modification de la limite FPS (Etape III)
Priorité au décoding

Pour ce second point, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :

Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :

Ouvrez l’Éditeur de stratégie de groupe locale :

Ouvrez l’arborescence suivante :

Computer Configuration
- Administrative Templates
  - Windows Components
    - Remote Desktop Services
      - Remonte Desktop Session Host
        
        Remote Session Environment

Ouvrez la police suivante :

Activez-là et cliquez sur OK pour sauvegarder :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVC444ModePreferred  /t REG_DWORD /d 1 /f

Fermez la session de votre utilisateur AVD :

Rouvrez la session sur la même machine AVD :

Ouvrez la même page de test FPS que précédemment. Le plafonnement devrait être toujours aux alentours de 60 FPS :

Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique toujours un nombre bien plus faible de FPS :

Continuions notre troisième test avec en ajout la configuration du décoding graphique.

Etape V – Test limite FPS + Priorité au décoding + Configuration du décoding

Ce troisième reprend les deux modifications apportées par les étape III et IV, et ajoute en plus la configuration du décoding graphique. Vous pouvez donc reprendre la même machine AVD précédemment utilisée, ou repartir sur une nouvelle machine avec les trois modifications suivantes :

Modification de la limite FPS (Etape III)
Priorité au décoding (Etape IV)
Configuration du décoding

Pour configurer ce troisième point, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :

Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :

Ouvrez l’Éditeur de stratégie de groupe locale :

Ouvrez l’arborescence suivante :

Computer Configuration
- Administrative Templates
  - Windows Components
    - Remote Desktop Services
      - Remonte Desktop Session Host
        
        Remote Session Environment

Ouvrez la police suivante :

Activez-là et cliquez sur OK pour sauvegarder :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVCHardwareEncodePreferred  /t REG_DWORD /d 1 /f

Fermez la session de votre utilisateur AVD :

Rouvrez la session sur la même machine AVD :

Ouvrez la même page de test FPS que précédemment. Le plafonnement devrait encore et toujours être aux alentours de 60 FPS :

Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique encore et toujours un nombre bien plus faible de FPS :

Que faire alors ? Sommes-nous bloqués quoi que nous fassions avec 30 FPS sur Azure Virtual Desktop ?

Etape VI – Test sur une machine virtuelle graphique

J’ai donc décidé d’aller un peu plus loin en testant AVD sur une machine virtuelle graphique disponible sur Azure. J’ai choisi de prendre la taille Standard_NV6 de la série des NV, elle dispose d’une puissance graphique bien plus conséquente que les machines de la famille D :

Comme ces machines graphiques ne supporte pas le GEN 2, j’ai choisi sur une image en Windows 10 en GEN 1:

Comme lors de la précédente salve de tests, j’ai utilisé deux environnements de même configuration pour mesurer l’impact ou non des modifications Microsoft sur les FPS :

Environnement 5 : Environnement graphique de base
Environnement 6 : Environnement graphique de base + modifications

Sur les deux environnements graphiques, j’ai commencé par mettre à jour les pilotes de la carte graphique à jour grâce au compte d’administrateur local :

J’ai continué par configurer l’outil de configuration GPU spécifique à Nvidia :

nvidia-smi.exe -fdm 0 -g 00000001:00:00.0

J’ai effectué par la suite un redémarrage nécessaire des deux VMs.

J’ai ensuite installé sur les deux environnements graphiques les applications suivantes :

Enfin, j’ai réalisé la configuration suivante uniquement sur l’environnement 6 :

Lancement des 3 modifications précédentes par des clefs de registre :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW  /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVC444ModePreferred  /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVCHardwareEncodePreferred  /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL  /t REG_DWORD /d 15 /f
gpupdate.exe /force

Un dernier redémarrage de la machine virtuelle de l’environnement 6 est encore nécessaire.

J’ai lancé Fraps suivi d’une nouvelle partie de jeu Age of Empires II. Sans plus attendre, voici les résultats FPS donnés par FRAPS et par la connexion RDP :

Environnement 5 : Graphique sans modification :

Environnement 6 : Graphique avec modifications :

Dans les deux environnements, Fraps indique un nombre très conséquent de 120 FPS. Cela s’explique par la faible exigence graphique Age of Empires II et de la performance graphique de ces machines virtuelles.

Concernant les FPS relevés par la connexion RDP, un écart se creuse d’environ 10 FPS entre les deux environnements tests. L’environnement 6 est meilleur, sans pour autant rapprocher le nombre de FPS généré par la carte graphique de machine virtuelle AVD.

Conclusion

Tous ces tests montrent l’importance relative de la configuration des FPS sur des machines classiques d’AVD et pour des tâches de bureautique. 30 FPS suffisent à beaucoup d’actions. On pourra néanmoins être gêné si le volume d’utilisateurs est important, et que des besoins graphiques (Teams ?) sont présents.

Les machines graphiques disponibles sur Azure montre de belles performances et peuvent convenir dans bien des scénarios graphiques quand elles sont combinées avec Azure Virtual Desktop.

Réduisez les coûts de votre AVD 🤑

Beaucoup d’articles sur ce blog parlent déjà d’Azure Virtual Desktop 🤣. Au fil des mois, nous avons constaté ses améliorations, la simplification du déploiement, l’augmentation de sa sécurité, de ses performances ou encore une meilleure compatibilité. Un point important n’a pas encore été abordé : l’optimisation des coûts sur AVD.

D’ailleurs, plusieurs articles parlant des coûts sur Azure sont déjà disponibles sur ce blog :

C’est un premier pas vers la compréhension de la facturation de Microsoft selon vos usages. Ce modèle de facturation, basé sur la consommation est la norme pour les principaux fournisseurs de Cloud.

Quels sont les principaux coûts d’Azure Virtual Desktop ?

Avant de parler d’optimisations sur les coûts, il est nécessaire de lister les principales charges d’une architecture Azure Virtual Desktop. Certains coûts sont systématiques, tandis que d’autres sont optionnels :

Gestion des identités : Azure Virtual Desktop repose sur une gestion des utilisateurs, de même que pour l’OS, les fichiers ou encore certaines applications. Plusieurs options sont disponibles : Azure AD, Active Directory ou le service managé Azure AD DS.
Machine virtuelle : Que l’environnement AVD soit composé pour des machines individuelles ou partagées, elles représentent toujours un coût important dans l’infrastructure AVD.
Stockage : Plusieurs types de stockage sont nécessaires dans une architecture AVD. Un premier stockage est déjà présent sur chaque machine virtuelle pour stocker l’OS, les applications, … Un second est créé pour stocker les données et les informations de session des utilisateurs AVD.
Licence : Que l’environnement AVD fonctionne sur Windows 10/11 ou Windows Server, des licences Microsoft sont nécessaires. Le choix de l’OS pour AVD repose sur les besoins applicatifs ou la méthode de gestion du parc souhaitée.
Réseau : Toute donnée sortante du Cloud Microsoft est facturée. Chaque utilisateur d’AVD génère un petit coût lorsqu’il ouvre et utilise sa session de bureau à distance. Cette somme varie selon le volume de Gio envoyés en dehors du Cloud, en sachant que le protocole RDP n’est pas réputé comme gourmand en traffic.
Gestion de la sécurité : Toute infrastructure IT a besoin de mesures de protection. Ces coûts ne sont pas obligatoirement liés à Microsoft, mais ils doivent être pris en compte dans l’enveloppe finale.
Sauvegarde : La sauvegarde de certaines données est indispensable pour se prémunir d’un accident ou d’une fraude. Le volume de donnée à sauvegarder, la fréquence ou la redondance de la sauvegarde influent sur son prix.
Plan de reprise d’activité : Le PRA n’est pas un système de sauvegarde au premier sens du terme. Il n’est pas non plus obligatoire. Mais il doit être perçu comme un point majeur dans la protection de services critiques, afin qu’ils continuent à fonctionner. Sur Azure, un doublement de certaines ressources AVD est envisageable dans une seconde région du Cloud.

Et le coût d’un AVD dans tout ça ?

Il n’existe pas de prix fixe pour Azure Virtual Desktop. La liste des éléments précédemment listés vous montre les principaux axes de coûts, mais le choix de chaque composant dépend du projet AVD.

Il existe un objet Azure Virtual Desktop dans le Calculateur de prix Azure, mais je trouve que celui-ci passe très vite sur certains points et oublie d’en mentionner d’autres.

Alors, comment procède-t-on pour estimer le prix d’un projet AVD ?

Aucune baguette magique n’existe ! Comme pour toute infrastructure IT, il est conseillé de récolter quelques métriques sur les besoins utilisateurs pour commencer à composer. Voici quelques exemples de questions qui me paraissent essentielles pour démarrer un projet AVD :

Nombre d’utilisateurs totaux
Nombre d’utilisateurs simultanés
Horaires de travail
Nature des besoins (Répartition des utilisateurs selon des types de population)
Exigences OS de l’équipe IT / des applications
Ont-ils déjà des licences 365 en place ?
Préférence géographique sur Azure ?
Volonté d’engagement dans la durée ?
Perspective de croissance des besoins AVD
Ressources IT locales à interconnecter

Ces données sont utiles pour estimer les principaux coûts listés précédemment.

Et si l’on ne souhaite pas réaliser tous ces calculs ?

Azure facture sur la consommation mensuellement. Le but sur Azure n’est pas de produire un coût fixe mensuel. Si cela n’est pas votre souhait, Microsoft a aussi pensé à vous et propose également une solution clef en main, appelé Windows 365 au tarif mensuel fixe.

Windows 365 est proche d’un système de licence comme pour Office 365, pour le provisionnement d’un PC Cloud. La puissance de ce PC dépend du prix de la licence Windows 365 choisie. Un premier article sous la solution est disponible juste ici

Bien que basé sur la même technologie, Windows 365 est un service hautement managé. Cela réduit donc la configuration possible sur certaines fonctionnalités, comme le montre ce tableau ci-dessous :

Êtes-vous êtes toujours là ? 😉

Je vous propose de reprendre les 6 principaux coûts Azure Virtual Desktop et d’envisager des économies possibles.

Coût I – Gestion des identités :

Azure Virtual Desktop fonctionne avec les 3 systèmes de gestion identitaire suivants :

Azure AD
Azure AD Domain Services
Active Directory classique

Il ne s’agit pas de solutions 100% équivalentes en termes de fonctionnalités, chacune apporte une plus-value selon le scénario AVD souhaité.

Quelles sont les économies possibles ?

L’économie consiste à prendre la bonne gestion identitaire à votre projet. Voici un classement croissant par ordre de prix et des usages les plus courants :

Azure AD : Azure AD de base est gratuit ! Évidemment, certaines fonctionnalités sont bridées, mais cela allège déjà un peu la facture. La gestion identitaire par Azure AD est conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
Azure AD DS : Solution intermédiaire en termes de coûts, de fonctionnalités et de management. Il s’agit d’un domaine géré par Microsoft et donc partiellement restreint. Azure AD DS est lui aussi conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
Active Directory : idéalement utilisé si l’on souhaite avoir la main complète sur les paramétrages du domaine AD, ou si un domaine AD existe déjà en on-premise. Il est alors possible d’étendre l’AD local à Azure via une liaison Azure VPN et une machine ayant le rôle d’AD dans Azure.

Coût II – Machine virtuelle :

Comme annoncé plus haut, les machines virtuelles représentent une part importante du coût total de l’architecture Azure Virtual Desktop. Bien souvent, il est difficile d’estimer au mieux le nombre et la puissance des machines virtuelles AVD. Les métriques de l’environnement actuel, un cahier des charges précis et des phases de POC sont de vrais facilitateurs.

*Classification AVD selon les charges de travail.*

De mon côté, j’essaie d’imaginer, selon mes expériences antérieures, les possibilités de machines virtuelles AVD adaptées aux besoins des utilisateurs. Je compile alors le tout dans un tableau Excel : le nombre d’utilisateurs par population et différents scénarios où les ressources allouées varient :

Quelles sont les économies possibles ?

Trois économies sont possibles sur les coûts des machines virtuelles AVD :

Adaptez la puissance de vos machines virtuelles : cela risque de ne pas plaire aux utilisateurs AVD, ou pas. Des machines correctement dimensionnées selon les usages diminuent fortement les coûts. Il est important d’analyser le nombre d’utilisateurs maximal que la machine supporte sans que l’expérience utilisateur ne soit dégradée.
Réservez vos machines virtuelles pendant 1 ou 3 ans : Deux méthodes de facturations sont disponibles sur Azure. Prendre un engagement sur une machine virtuelle est une méthode pratique pour diminuer les coûts quand l’utilisation de la ressource est en 24/7.
Privilégiez Windows 10/11 quand cela est possible : Une licence Windows Server + CAL RDS coûtent toujours plus cher que des licences ayant des droits d’accès utilisateur, comme Microsoft 365 Business Premium ou Microsoft E3/E5.

Coût III – Stockage :

Il existe deux principaux coûts au stockage sur Azure. La taille du stockage et les transactions influent sur le montant :

Taille du stockage : Un disque managé Azure est facturé toutes les heures au niveau supérieur le plus proche de sa taille. Autrement dit, un disque de 120 Go coûte autant qu’un disque de 128 Go, que la machine virtuelle soit allumée ou non.
Transactions : Sont appelées transaction, les lectures, les écritures, … effectuées par le disque, elles sont facturées par paquet de 10 000 transactions. Certains types de disque, comme les disques Premium ou Ultra, incluent le coût des transactions dans leur tarification les coûts sont alors plus prévisibles et mieux maîtrisés.

Voici une brève comparaison tarifaire pour un disque de 128 Go en Europe de l’Ouest, selon Azure Pricing Calculator :

Premium SSD : 20.13 CHF / mois
Premium SSD v2 : 11.49 CHF / mois
Standard SSD : 12.63 CHF / mois
Standard HDD : 6.39 CHF / mois
Ultra disk : 88.73 CHF / mois

Quelles sont les économies possibles ?

Le type de disque le moins cher n’est pas forcément le plus économe. Les transactions risquent de faire exploser le coût du stockage des machines virtuelles ou des partages de fichiers.
Surveillez les consommations d’espace : un espace réservé et inutilisé est facturé par Azure. Ajustez la taille et les performances selon les besoins.

Coût IV – Licence :

Azure Virtual Desktop nécessite des licences adéquates en fonction de l’environnement choisi, Windows 10/11 ou Windows Server :

Windows 10/11 : On licencie les utilisateurs et non les machines virtuelles.
Windows Server : On licencie les machines virtuelles (+ CAL RDS) et non les utilisateurs.

Quelles sont les économies possibles ?

Pour moi, la meilleure économie possible est de partir sur une licence Microsoft 365 Business Premium pour chaque utilisateur AVD. Cette dernière comprend entre autres :

Azure AD Premium P1
Les droits d’utilisation d’Azure Virtual Desktop sous environnement Windows 10/11
Les principaux outils de la suite bureautique d’Office 365
Et encore bien d’autres fonctionnalités de sécurité

Si le choix de partir sur un environnement AVD sous Windows Server est non négociable, privilégiez Azure Hybrid Benefit grâce à l’achat de licences Windows Server et CAL RDS en mode souscription CSP. La rentabilité est atteignable en 1 ou 2 mois seulement !

Coût V – Réseau :

*Pensez à consulter régulièrement l’excellent site m365maps pour vous aider à choisir la meilleure licence selon vos besoins.*

Les services hébergés dans le cloud sont accessibles depuis une architecture on-premise ou pour des utilisateurs simplement connectés à internet. Le schéma réseau ci-dessous montre les étapes de mise en place du bureau à distance AVD pour un utilisateur se connectant depuis internet :

Quelles sont les économies possibles ?

Vous l’avez compris, l’utilisation d’Azure AD et du protocole HTTPS inversé apportent une couche de sécurité dans le transfert de données entre l’infrastructure AVD et l’utilisateur.

Dans beaucoup de scénarios, il n’est pas systématiquement nécessaire d’exiger un accès VPN. Ce service est payant dans Azure, et son prix dépend principalement de son débit.

Enfin, les volumes de bande passante sortante ne sont pas élevés pour un environnement AVD. Il est donc inutile d’acheter un circuit ExpressRoute en formule illimité :

Coût VI – Gestion de la sécurité :

Une série d’articles dédiée à la sécurité est disponible juste ici. Pour éviter de vous endormir lors de longues lectures d’hiver et pour rester focalisé sur Azure Virtual Desktop, je vous conseille ces deux articles là :

Prenons en exemple la sécurité sur Azure AD :

Azure AD est gratuit ! 🤣 Azure Active Directory est bien proposé en quatre éditions : Gratuite, Applications Office 365, Premium P1 et Premium P2. Pour des questions de sécurité, je recommande de licencier vos utilisateurs AVD avec une licence Azure AD Premium P1.

Grâce à lui, l’accès conditionnel sur votre AVD apporte des mesures de restriction et bloque les connexions suspectes :

Fonctionnalité	Azure AD Free – Paramètres de sécurité par défaut	Azure AD Free – Administrateurs généraux uniquement	Office 365	Azure AD Premium P1	Azure AD Premium P2
Accès conditionnel				●	●
Accès conditionnel basé sur les risques					●

Quelles sont les économies possibles ?

Je pense qu’il n’est pas nécessaire de s’orienter vers une licence Azure AD Premium P2 pour vos utilisateurs AVD. Ses fonctionnalités sont certes très intéressantes, mais ce besoin n’est pas utile pour des « utilisateurs lambda ».

Conclusion :

Aucun doute qu’il existe plein d’autres optimisations possibles pour un environnement AVD. Un exercice que je conseille est de suivre régulièrement les évolutions de Microsoft sur les services Cloud. Le blog officiel et les vidéos disponibles sur YouTube vous donneront toujours des informations et des astuces auxquelles vous n’avez pas pensées.

Enfin n’oubliez pas de suivre et d’analyser la consommation Azure grâce au Cost Management 😉😉

Que valent les disques Azure ?

Microsoft vient d’annoncer il y quelques jours la disponibilité générale des disques Ultra dans plusieurs régions Azure, dont Suisse Nord. Depuis quelques mois déjà, un nouveau type de disque, appelé Premium SSD v2, a également fait son apparition sur Azure.

Au total, 5 types de disque managé sont disponibles pour les machines virtuelles Azure. SLA, IOPS, débit, taille, région ou encore sauvegarde sont quelques-uns des paramètres à prendre en compte lors de ce choix.

Dans cet article, nous allons aborder quelques points définissant les différents types de disque Azure, et nous ferons également quelques tests de performances IOPS et Débit. Durant mes tests, j’ai relevé des valeurs de latence très hautes. Je ne pense pas qu’elles représentent la réalité, et c’est pour cela qu’elles vous seront affichées mais pas commentées.

Compte-tenu de mes possibilités, à l’heure où ces lignes sont écrites, les tests ne porteront que sur les 4 types de disque suivants :

Premium SSD
Standard SSD
Standard HDD
Ultra disk

A quoi correspondent les IOPS d’un disque ?

IOPS (input/output operations per second en anglais, opérations d’entrée-sortie par seconde) est une unité de mesure commune en informatique. Elle est utilisée dans les tests de performance de supports de stockage tels les disques durs (HDD), solid-state drives (SSD) et réseaux de stockage SAN.
Wikip é dia

Une courte vidéo de John vaut mieux qu’un long discours 😎 :

A quoi correspond le débit d’un disque ?

Taux de transfert (ou débit) : quantité de données pouvant être lues ou écrites sur le disque par unité de temps. Il s’exprime en bits par seconde.
CommentCaMarche.net

Merci encore une fois à John pour ses vidéos :

Quelles sont les tailles disponibles pour un disque Azure ?

Azure vous propose de créer des disques très petits ou très grands. La plupart des types de disque peuvent aller jusqu’à 64 Tio :

Quels sont les coûts d’un disque Azure ?

Il existe deux principaux coûts aux disques managés d’Azure. La taille du disque et les transactions influent sur le montant mensuel :

Taille du disque : Un disque managé Azure est facturé toutes les heures au niveau supérieur le plus proche de sa taille. Autrement dit, un disque de 120 Go coûte autant qu’un disque de 128 Go, que la machine virtuelle soit allumée ou non.
Transaction : Sont appelées transaction, les lectures, les écritures, … effectuées par le disque, elles sont facturées par paquet de 10 000 transactions. Certains types de disque, comme les disques Premium ou Ultra, incluent le coût des transactions dans leur tarification les coûts sont alors plus prévisibles et mieux maîtrisés.

Voici une brève comparaison tarifaire pour un disque de 128 Go en Europe de l’Ouest, selon Azure Pricing Calculator :

Premium SSD : 20.13 CHF / mois
Premium SSD v2 : 11.49 CHF / mois
Standard SSD : 12.63 CHF / mois
Standard HDD : 6.39 CHF / mois
Ultra disk : 88.73 CHF / mois

Pourquoi le type de disque influe sur la SLA d’une machine virtuelle Azure ?

Azure est découpé en centaines de services. Chaque service dispose de sa propre SLA, elle-même calculée selon des paramètres précis.

Certains services proposent différents niveaux de performances et de fonctionnalités. Ces changement influent souvent sur l’architecture ou les composants physiques. Cela joue naturellement sur la SLA. Microsoft met à disposition une liste des SLA par service, régulièrement mise à jour.

Derrière chaque disque d’Azure se trouve une technologie de stockage. Microsoft se base donc sur cette SLA pour calculer la SLA de la machine virtuelle :

Quel scénario pour quel type de disque ?

Le coût du disque reste un facteur important pour une machine virtuelle. Néanmoins, Microsoft conseille un ou plusieurs types de disque, selon le rôle que celle-ci doit jouer :

Pourquoi les machines virtuelles Azure ont-elles un maximum d’IOPS ?

Quand vous sélectionnez une taille de machine virtuelle lors de sa création, une colonne concerne la performance des disques et doit attirer votre attention :

Les machines virtuelles d’Azure ont donc elles aussi un plafond IOPS :

Ce nombre maximal d’IOPS ne garantit en rien la performance de vos disques rattachés, mais agira en goulet d’étranglement si la puissance demandée par vos disques est supérieure à cette limite :

Etape 0 – Rappel des prérequis :

Peu de prérequis sont nécessaires pour réaliser les tests de performances des disques Azure :

Un tenant Microsoft
Une souscription Azure valide

Dans cet article, nous allons déployer une machine virtuelle Azure, avec différents types de disque. Cela nous permettra de comparer leurs performances.

Etape I : Enregistrement de la souscription Azure :

Tous les types de disque sont accessibles, à l’exception du nouveau type de disque Premium SSD v2. A l’heure où ces lignes sont écrites, un enrôlement de votre souscription Azure est encore nécessaire pour déployer ces derniers.

Cliquez-ici pour accéder au formulaire Microsoft :

Une fois le formulaire rempli, il ne vous restera qu’à attendre un retour de la part de Microsoft pour tester ce nouveau type de disque.

En attendant, rien ne vous empêche de continuer les étapes de cet article pour tester les autres types.

Etape II : Déploiement de la machine virtuelle Azure

Afin de tester différents types de disque, j’ai déployé une seule machine virtuelle sur Windows Server. J’ai choisi une machine virtuelle de type D8s v5 pour disposer de :

Une puissance de calcul CPU suffisante
Un nombre maximal d’IOPS élevé
Une limitation haute pour le nombre maximal de disques de données

Dans l’onglet des disques :

Pensez à cocher la case de comptabilité Ultra disque.
Pour les tests, tous les disques ont une taille proche pour comparer des performances de même tranche.
Quelques gigas seulement les séparent pour les identifier plus facilement par leur taille.
J’ai ajouté un second disque type Premium SSD, de plus grande capacité que les autres, pour mesurer l’impact sur les performances selon la taille.

*J’ai aussi retiré le cache d’hôte pour ne pas avoir de variation de résultats.*

Retirez l’adresse IP publique si vous utilisez comme moi le service Azure Bastion :

Quand la validation est réussie, lancez le déploiement de votre machine virtuelle de test :

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

Configurez au besoin les performances de votre Ultra disk :

J’ai configuré ces valeurs pour tester les limites liées à ma machine virtuelles. Attention à la consommation Azure qui peut s’envoler très vite 🤣🤣 :

Déployez également le service Azure Bastion pour vous y connecter plus facilement :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, puis connectez-vous à votre machine virtuelle de test avec le compte d’un administrateur local :

Etape III – Configurations des disques de données :

Une fois connecté à votre session à distance, ouvrez le gestionnaire de disque Windows :

Le gestionnaire de disque Windows vous propose automatiquement de lancer l’initialisation des disques de données ajoutés, cliquez sur OK :

Ajoutez un volume simple sur chacun des disques ajoutés :

Conservez toutes les options de bases pour chaque volume créé :

Contrôlez la présence des 5 partitions dans l’explorateur de fichier, renommez-les au besoin :

Etape IV – Installation de l’outil de mesure Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.
Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.
Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

Deux séries de tests sont conseillées pour exploiter le meilleur des deux caractéristiques :
- IOPS
- Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Etape V – Tests des IOPS des disques Azure :

Commencez une première salve de tests pour déterminer les IOPS maximums sur chacun des disques.

Ouvrez le programme de ligne de commande, puis positionnez-vous dans le dossier de l’exécutable Diskspd :

Lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L E:\diskpsdtmp.dat > IOPS-PremiumSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L F:\diskpsdtmp.dat > IOPS-StandardSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L G:\diskpsdtmp.dat > IOPS-StandardHDD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L H:\diskpsdtmp.dat > IOPS-PremiumSSD1024.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L I:\diskpsdtmp.dat > IOPS-UltraDisk.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

-c50G : taille du fichier 50 GB (il est préférable d’utiliser une taille de fichier importante pour qu’il ne parte pas dans le cache du contrôleur de stockage)
-d120 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-PremiumSSD.txt : fichier de sortie des résultats

En attendant la fin du traitement, ouvrez Resource Monitor et constatez la charge maximale du disque :

Une fois tous les tests terminés, retrouvez les fichiers des résultats dans le même dossier que l’exécutable :

Ouvrez chacun des fichiers de résultats, puis descendez au paragraphe suivant :

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

Etape VI – Tests débits des disques :

Continuez avec une seconde salve de tests pour mesurer les débits maximums des types de disque Azure.

Ouvrez le programme de ligne de commande si vous l’aviez fermé, puis repositionnez-vous dans le dossier de l’exécutable Diskspd :

Lancez les commandes de tests suivantes, une à une ou à la chaîne, en modifiant leurs paramètres si besoin :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L E:\diskpsdtmp.dat > Throughput-PremiumSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L F:\diskpsdtmp.dat > Throughput-StandardSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L G:\diskpsdtmp.dat > Throughput-StandardHDD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L H:\diskpsdtmp.dat > Throughput-PremiumSSD1024.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L I:\diskpsdtmp.dat > Throughput-UltraDisk.txt

Les deux paramètres ayant changés rapport aux commandes de test IOPS sont :

-b8K : taille du bloc
> Throughput-PremiumSSD.txt : fichier de sortie des résultats

Une fois les tests débits terminés, retrouvez les fichiers dans le même dossier que les IOPS :

Ouvrez chacun des fichiers de résultats de débits et compilez-les dans un tableau :

Etape VII – Analyse des résultats IOPS / Débits :

Après analyse des résultats de chaque type de disque, comparez-les à la documentation Microsoft : on retrouve bien des valeurs approchantes pour les IOPS et les débits. Voici quelques explications :

Premium SSD :

Premium SSD P10 : 3548 IOPS – 162 Mio/sec
Premium SSD P30 : 5099 IOPS – 194 Mio/sec

Le nombre d’IOPS et le débit garantit augmentent par parlier, en rapport avec la taille du disque.

A partir de 4 Gio et jusqu’à 512 Gio, le mode Burst est disponible et s’active automatiquement selon la charge, comme le montre le test réalisé.
A partir de 1024 Gio, les performances de base sont bien meilleures, mais le mode Burst s’active uniquement sur demande.

Voici d’ailleurs l’excellente vidéo de John sur le fonctionnement du mode Burst dans le temps :

Durant le premier test, le disque Premium SSD d’1 Tio n’a pas utilisé le mode Burst et est resté aux alentours de 5000 IOPS et 200 Mio/sec, soit les valeurs provisionnées sur un disque P30.

L’activation du burst à la demande doit se faire sur le disque, uniquement lorsque ce dernier est détaché ou quand la machine virtuelle est désallouée, donc éteinte.

Pour effectuer un test de burst sur le disque P30, éteignez votre machine virtuelle et cochez la case suivante sur le disque, puis rallumez-là :

Voici les résultats IOPS / débits du disque Premium SSD d’un 1 Tio avec le mode burst à la demande :

Premium SSD P30 + Burst : 19321 IOPS – 967 Mio/sec

Le test de débit est bon, mais la valeur IOPS aurait dû se rapprocher des 30 000 IOPS. L’écart s’explique à cause de la machine d8s_v5, qui vient limiter les performances du mode burst du disque.

Cela n’empêche pas d’avoir de performances très honorables. Passons maintenant au disques Standard SSD.

Standard SSD :

Je trouve le test de débit un peu faible comparé au tableau Microsoft :

Standard SSD E10 : 600 IOPS – 38 Mio/sec

Standard HDD :

Pour celui-ci, les résultats des tests sont cohérents avec la documentation Microsoft :

Standard HDD S10 : 543 IOPS – 35 Mio/sec

Rappel important : Pour les disques de type standard HDD, chaque opération a un impact sur la facturation.

Ultra disk :

Ce type de disque apporte le plus de flexibilité car ils sont disponibles à partir de 4 Gio et jusqu’à 64 Tio. De plus, la SLA qui les couvre est très élevée : 99.99 %.

Comme le montre l’écran de paramétrage de notre test, nous pouvons jouer avec les limites débit et IOPS selon des besoins très précis, et cela sans aucun redémarrage de la machine virtuelle.

Les limites maximales des IOPS et des débits sont très hautes, comme le montre le tableau ci-dessous :

Rappel important : Pour les disques Ultra, ces options ont un lourd impact sur la facturation.

Le test d’IOPS sur le disque ultra a plafonné à 20 000 IOPS car nous avons là encore été bridé par la limite d’IOPS de la machine virtuelle d8s_v5. Le tableau ci-dessous nous affiche cette limite et le mode burst possible :

Les machines virtuelles les plus puissantes acceptent jusqu’à 80 000 IOPS, ce qui reste en dessous de la limite maximale des IOPS des plus puissants disques ultra. C’est pour cela que ces derniers peuvent être utilisés en tant que disques partagés, pour prendre en charge plusieurs machines virtuelles.

Conclusion :

Je peux déjà commencer par vous dire que j’aurais bien aimé tester un disque Premium SSD v2 🤣. Cela devrait arriver sous peu, je vous ferai alors une mise à jour de cet article.

Cela dit, je pense que les performances et les usages de ces derniers sont proches des disques Ultra. A ce titre, je pense que la stratégie de Microsoft est bien de démocratiser la performance et la customisation des disques selon les besoins, avec un prix bien plus attractif ✌️😉

Edit :

Seulement quelques jours après la publication de mon article, j’ai reçu un avis favorable de la part d’un Product Manager de chez Microsoft pour tester les disques Premium SSD v2, sur une souscription Azure de mon tenant, en disponibilité générale depuis octobre 2022.

Je suis parti donc sur un disque Premium SSD v2 avec les caractéristiques suivantes :

Pour rappel, voici quelques caractéristiques maximales pour un disque Premium SDD v2 :

Taille maximale : 65 536 Gio
IOPS provisionnées : 80 000 IOPS
Débit provisionné : 1200 Mio / Sec

Afin d’atteindre les performances maximales de mon disque, j’ai créé une machine virtuelle D32s v5, qui dispose des limites suivantes :

Grâce à Diskspd et aux commandes suivantes :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L E:\diskpsdtmp.dat > IOPS-PremiumSSDv2.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L E:\diskpsdtmp.dat > Throughput-PremiumSSDv2.txt

Cela m’a permis de compléter mes tableaux de performances :

Il s’agit sans aucun doute d’un type de disque flexible aux performances incroyables. Voici un rappel du prix bien moins chère qu’un Ultra disk 😎

Attention aux limitations encore présentes sur le disques Premium SSD v2.

AVD : Protocole UDP pour tous !

Ce nouvel article est focalisé sur la partie réseau d’AVD, il reste dans la continuité de celui déjà consacré à RDP Shortpath, écrit il y a plusieurs mois déjà. Azure Virtual Desktop est capable d’établir des connexions de bureau à distance via deux protocoles : TCP et UDP. L’utilisation du second permet d’améliorer les performances grâce à un débit plus important et une gestion différente des paquets.

Pour vous remettre dans le bain, voici un rappel de l’excellente vidéo de Dean à ce sujet :

Pourquoi doit-on se préoccuper du protocole UDP ?

L’impact du protocole dans un environnement dédié au bureau à distance est majeur. Denis Gundarev nous explique avec simplicité l’inadéquation entre le protocole TCP dans le cadre d’une connexion RDP :

TCP est un excellent protocole pour la livraison garantie de petites quantités de données. Les applications telles que les navigateurs ou les clients de messagerie se contentent d’envoyer les données et de les oublier. Le protocole assure la cohérence et l’ordre des paquets et relance la transmission si la livraison échoue. Cependant, RDP utilise des connexions de longue durée et les connexions TCP de longue durée sont problématiques.

Le protocole TCP est idéal pour les réseaux locaux, mais pas pour l’Internet. Oui, si le paquet est perdu, il sera retransmis. La disponibilité de la bande passante est un facteur essentiel. Malheureusement, les algorithmes de contrôle de congestion TCP limitent la possibilité de saturer le réseau.

Pour vous donner une meilleure idée, voici une vidéo comparative montrant visuellement l’impact du protocole si une partie de paquets est perdue :

Pourquoi refaire un article sur ce sujet ?

En faisant différents tests sur des environnements Azure Virtual Desktop, je me suis rendu compte « par hasard » de l’activation quasi systématique du protocole UDP lors des ouvertures de session, sans aucune action ni configuration de ma part.

J’ai donc effectué différents tests sur 3 environnements AVD distincts :

VM : Standard D8s v3 (8 vCPU, 32 GiB memory) / OS : Windows 10 21H2
VM : Standard D2s v3 (2 vCPU, 8 GiB memory) / OS : Windows 11 22H2
VM : Standard D8s v3 (8 vCPU, 32 GiB memory) / OS : Windows 11 21H2

Dans les 3 environnements, j’ai constaté exactement le même mécanisme :

Première ouverture de session en TCP
Seconde ouverture de session en UDP

Aucune configuration via la règle de registre ICEControl, pour activer le RDP Shortpath, n’a été mise en place avant ces tests :

Comment cela est-ce possible ?

Tout simplement car la fonctionnalité UDP a été déployée sur l’ensemble des environnements AVD, de production et de validation : RDP Shortpath for public networks in Azure Virtual Desktop – Microsoft Community Hub.

Comme l’indique ce billet Microsoft , la disponibilité générale du routage via le protocole UDP pour les connexions transitant via un réseau public est disponible depuis la date du 6 septembre dernier. Ils recommandent même de retirer la précédente clef de registre.

A noter que certaines ouvertures de sessions se sont malgré faites tout en TCP. Bien souvent, la fermeture / réouverture de la session m’a permis de retrouver un protocole UDP. Je pense que certains éléments influent sur cela, sans vraies certitudes.

Peut-on désactiver le protocole UDP afin de rester systématiquement en TCP ?

Cela est parfaitement possible et nécessaire dans certains scénarios. Microsoft propose 3 méthodes pour retrouver l’état initial en TCP :

Désactivation au niveau de la machine virtuelle AVD
Désactivation au niveau du client AVD
Désactivation via Intune

Pour la première méthode, il est nécessaire d’intervenir au niveau de la machine AVD, ou de l’implémenter via une GPO.

Connectez-vous sur la machine virtuelle AVD avec un compte administrateur.

Ouvrez l‘Editeur de groupes polices locales :

Rendez-vous dans le menu suivant :

Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Host > Connections

Ouvrez le paramètre ci-dessous :

Cochez les options comme ceci, puis fermez la session et rouvrez là :

Constatez bien que votre connexion RDP utilise le protocole TCP :

La configuration et le résultat sont identiques pour les machines en Windows 10.

Annexe

Durant ces tests j’ai également remarqué que mes environnements Azure Virtual Desktop fonctionnaient très bien malgré l’absence de l’argument RDP targetisaadjoined dans les propriétés RDP du pool d’hôtes AVD :

Avant :

Maintenant :

C’est toujours appréciable d’avoir une chose de moins à penser dans la configuration 😎.

Conclusion

Microsoft continue d’améliorer son outil et facilite sa configuration. La simplification et l’automatisation du protocole UDP améliore les performances et donc l’expérience utilisateur. Nul doute que Microsoft va continuer à travailler dans ce domaine pour accroitre le nombre d’utilisateurs sur un de leurs produits phares.

Renouvelez vos certifications Microsoft

Vous avez passé et réussi une certification Microsoft il y a peu ? Bravo ! Dans quelques mois et selon celle-ci, attendez-vous à recevoir un mail, de la part de Microsoft, vous demandant de renouveler votre certification.

Non, ce n’est pas une blague, certaines certifications Microsoft ont toujours eu une durée de validité. La date d’expiration est basée sur la date de réussite de votre examen. Il vous est nécessaire de repasser une petite épreuve pour étendre la durée de votre certification.

Microsoft a changé les règles du renouvellement des certifications le 30 juin 2021. Les changements ne concernent que les certifications passées à partir de cette date :

Avant le 30 juin 2021, les certifications de niveau Associé, Expert ou même les spécialités avaient une durée de validité de 2 ans. Les personnes certifiées devaient alors payer pour repasser l’examen initial, comme toute personne souhaitant passer la même certification pour la première fois. Les certifications de niveau Fondamental n’ont jamais eu de date d’expiration.

A partir du 30 juin 2021, les certifications de niveau Associé, Expert ou même les spécialités présentes dans cette liste ont une durée de validité réduite à un an. Un renouvellement gratuit est maintenant accessible 180 jours avant la date d’expiration. Les certifications de niveau Fondamental n’ont toujours pas de date d’expiration.

Une FAQ est à disposition pour vous aider à comprendre les impacts.

Pourquoi ?

Pour les personnes certifiées, cette modification a un double avantage :

Ne plus repayer pour prolonger la durée de validation pour chaque certification
Ne plus subir les conditions strictes de l’examen initial

Bac à sable d’examen Microsoft

Le processus de renouvellement de certification annuel gratuit et pratique de Microsoft garantit que vous êtes à jour avec les dernières modifications technologiques.
Microsoft Learn

Bien évidemment, le point central dans ces deux modèles reste basé sur l’apprentissage continu des évolutions des produits. Ces produits rattachés au Cloud Microsoft sont en constante évolution dans leurs fonctionnalités et leur périmètre.

Quand passer son renouvellement ?

Inutile de vous précipiter, attendez de recevoir le premier mail de la part de Microsoft, 180 jours avant la date d’expiration de votre certification. Par la suite et si rien n’est fait, plusieurs rappels vous seront envoyés tant que votre certification n’est pas renouvelée :

90 jours avant la date d’expiration
30 jours avant la date d’expiration
7 jours avant la date d’expiration

Comment se déroule le renouvellement ?

La principale différence entre un renouvellement et un premier examen est avant tout l’absence d’outil de contrôle. Plus besoin de disposer d’un environnement vide et calme. La page d’examen du renouvellement est une page web de Microsoft Learn.

Concernant le contenu du renouvellement, l’examen est généralement composé d’une vingtaine de questions environ, parfois un peu plus. Les questions s’enchainent sans pouvoir revenir en arrière. Pas d’étude de cas à traiter non plus.

Je ne crois pas non plus avoir vu de chronomètre par question ou même pour l’ensemble de l’examen de renouvellement.

Quels sont les résultats possibles ?

Comme pour l’examen initial, deux issues sont possibles, réussite ou échec. Une différence réside sur le pourcentage à atteindre. 700 points sont nécessaires pour l’examen initial, tandis que le renouvellement se base sur un pourcentage, dont le son minimum varie entre chaque examen.

Si votre renouvellement est réussi, la date d’expiration de la certification est automatiquement repoussée d’une année. Un prochain renouvellement vous sera alors à requis à nouveau dans 365 jours, etc … Un nouveau mail arrivera quelques heures après pour vous féliciter :

Si vous échouez votre renouvellement, rien de grave, vous pourrez le repasser après 24 heures. En attendant, Microsoft vous affiche en dessous des indicateurs pour situer votre niveau sur chaque thème et pour vous inciter à vous concentrer vos efforts sur faiblesses :

Mon avis personnel

J’adhère complètement à ce nouveau processus simplifié de renouvellement, autant sur la forme que sur le fond : Il est plus juste de ne plus faire repayer une certification déjà acquise, et il est primordial de vérifier le maintien à jour des connaissances des personnes certifiées.

En revanche, je suis quelques fois dubitatif sur la présence de certaines questions, très à la marge du périmètre de la certification renouvelée. Cela donne un effet méli-mélo assez étrange sur le pool de questions rattachées derrière tout ça.

Conclusion

Après une première inquiétude émise à cause du raccourcissement de la durée de validité, ce changement dans le renouvellement des certifications Microsoft a été vivement apprécié, il simplifie le processus de validation des connaissances pour les personnes déjà certifiées.

Cette approche facilite également l’ajout de questions sur des contenus nouveaux, car la même démarche chez Microsoft est nécessairement plus longue pour l’appliquer et le valider dans un examen initial.

Comprenez les coûts d’une ressource Azure

Un des principes fondamentaux du Cloud est fonctionner, et de facturer, selon la consommation. Cela permet de payer un service uniquement quand celui-ci est utilisé. Associé à ce principe, une transparence des coûts est présente via une décomposition précise.

Néanmoins, la compréhension de la tarification et de la facturation d’Azure n’est pas chose aisée durant la mise en place des premières architectures, tant la granularité tarifaire peut s’avérer pleine de coûts combinés et de variantes possibles selon les scénarios.

Un premier article dédié à l’optimisation des coûts est déjà disponible sur ce blog juste ici. Ce second article est quant à lui dédié à la décomposition tarifaire d’une machine virtuelle, très utilisée sur Azure.

*Optimisez votre Azure : 1/4 – Les Coûts*

Comment fonctionne la politique tarifaire d’Azure ?

Azure propose deux méthodes de tarification, assez classiques chez tous les fournisseurs de Cloud :

Paiement à la demande : aussi appelé PAYG (Pay-As-You-Go), cette méthode de facturation est sans engagement. Le décompte tarifaire commence selon les cas quand la ressource est créée ou allumée, et se termine quand la ressource est supprimée ou arrêtée.
Engagement de durée : disponibles sur certaines ressources Azure, les engagements sur Azure sont généralement disponibles sur un ou trois ans avec un paiement unique en début d’engagement ou mensuellement. Durant cette durée, le coût de la ressource n’est plus facturé en PAYG, on profite alors d’un rabais très intéressant. L’annulation de l’engagement durant la période n’est pas toujours possible.

Il est possible de combiner les deux méthodes dans un seul environnement Azure sans difficulté.

Attention : un engagement ne couvre généralement pas l’ensemble des coûts d’une ressource Azure.

Quels sont les principaux types de coûts d’une ressource Azure ?

La liste des prix publics des ressources est accessible sur la Calculatrice de prix Azure.

Rien de telle qu’une vidéo pour comprendre comment celui-ci fonctionne :

Seyfallah Tagrerout

Le coût d’une ressource Azure se décompose généralement en plusieurs types de coût. Par exemple, le stockage de données sur Azure générera les coûts suivants :

Le volume de stockage : Mo, Go, To, …
Le volume de transactions : lectures, écritures, …
Le volume de données transitant par les réseaux : Mo, Go, To, …
Les services additionnels : réplication, sauvegarde, sécurité, …

*Ce lien ouvre une page détaillée des coûts.*

Dans cet article, nous allons nous intéresser aux machines virtuelles Azure et à quatre de ses principaux types de coûts :

Le Calcul : le traitement de l’information nécessite un service capable d’effectuer des calculs. Azure considère couple processeur / mémoire comme un couple de calcul. On retrouve cet ensemble dans les machines virtuelles, les serveurs de base de données ou les services Web. Assez simplement, le coût du service calcul va dépendre de sa taille, donc de sa technologie, de son nombre de coeurs et de sa taille de mémoire.
Le Stockage : Bien souvent, de l’information a besoin d’être stockée dans une architecture. Qu’elle soit utilisée par le service de calcul, mise à disposition pour des accès externes ou pour des besoins de sauvegarde, le stockage disposera généralement de 3 variables : taille (Go; To), débit (Mo/sec; Go/sec) et puissance transactionnelle (IOPS).
Le Réseau : Une ressource Azure a besoin de communiquer avec des utilisateurs ou d’autres ressources IT. Par exemple, le réseau virtuel Azure est un moyen simple de faire communiquer des ressources Azure entre elles, une passerelle VPN ou ExpressRoute Azure sera un moyen facile et sécurisé d’établir une communication vers un environnement local. Comme pour le stockage, la tarification réseau repose sur des variables : taille de la bande passante et le volume de données en transition.
La licence logicielle : Là encore, la ressource Azure sera souvent exploitée par un système d’exploitation et/ou logiciel, dont certains fonctionnent sous licence payante. Dans l’exemple des licences Microsoft, comme Windows Server ou SQL Server, la tarification Azure repose sur la taille du service de calcul, comme le nombre de coeurs des machines virtuelles. Il est aussi possible de réduire les coûts des licences en réutilisant, sous certaines conditions, des licences existantes.

La machine virtuelle Azure est le meilleur exemple car elle est présente dans de nombreux déploiements Cloud et comporte une variété de coûts Azure.

Tous les champs indiqués dans la Calculatrice de prix Azure ont un impact sur le prix, mais les trois champs entourés en rouge sont ajustables selon les besoins dans le temps :

Taille de l’instance de calcul :

Pas de mystère, plus une machine virtuelle dispose de coeurs et/ou de mémoire, plus son coût est élevé. Il est donc important de choisir une taille adaptée selon les besoins pour éviter des ralentissements ou une sous-utilisation.

Peut-on moduler la taille de la machine virtuelle selon les besoins ?

Il est envisageable de redimensionner la taille durant la nuit ou le week-end quand la période de calcul est plus faible, via le portail Azure ou même de l’automatiser grâce à un script.

Attention : un changement de taille engendre un repositionnement de la machine virtuelle par l’hyperviseur, donc un redémarrage systématique de l’OS.

Durée de fonctionnement :

Une fois créée, une machine virtuelle Azure oscille sur 3 différents statuts :

Démarrée : fonctionnement normal et tarification des 4 coûts : calcul, stockage, réseau et licence.
Arrêtée : machine virtuelle non accessible, tarification maintenue pour le calcul et le stockage.
Arrêtée (Désallouée) : machine virtuelle non accessible, tarification maintenue pour le stockage.

Dans certains cas, l’arrêt complet de la machine virtuelle est donc une approche intéressante pour réduire les coûts. Imaginez un scénario où la machine virtuelle ne démarre qu’au moment où l’utilisateur en a besoin, par exemple durant les heures des jours de la semaine.

Important : à noter que le démarrage d’une machine virtuelle dépend aussi des ressources disponibles dans le datacenter Azure où elle se situe. Ce point de détail a pu être épineux, par le passé, pour certaines tailles de machines exotiques.

Engagement, ou pas :

Comme indiqué plus haut, deux méthodes de facturations sont disponibles sur Azure. Prendre un engagement sur une machine virtuelle est une méthode pratique pour diminuer les coûts quand l’utilisation de la ressource est en 24/7.

Comment fonctionne une instance réservée ?

Il faut voir une instance réservée Azure comme une place de parking, louée pour une durée d’un ou trois ans auprès de Microsoft :

L’instance réservée est une méthode d’engagement historique, elle a depuis été complétée avec le Plan d’économies, disponible depuis quelques mois :

Disque de stockage :

Le stockage de données est un élément indispensable pour une machine virtuelle Azure. Il s’agit d’un coût que l’on paye en permanence, même si la machine virtuelle est éteinte. La taille, la SLA et les performances des disques sont des vecteurs de coûts et donc d’économies potentielles.

Quatre niveaux de disque sont actuellement disponibles sure Azure :

Standard HDD
Standard SDD
Premium SSD v1/v2
Ultra disk

L’économie va alors dépendre des besoins : une taille de disque adaptée, des performances suffisantes vous permettrons de répondre au mieux à ces derniers et donc de réduire les coûts :

*Les disques premium SSD v2 apportent plus de flexibilité sur le choix des performances voulues.*

Quelques remarques :

La taille du disque dépendra de la taille de l’image ou de la partition. Il n’est pas possible de choisir une taille plus petite que l’image.
Certains niveaux de disques n’incluent pas les coûts liés au volume de transaction dans le prix de base. Il faut donc en tenir compte dans le calcul de coût du stockage.
Le meilleur prix final, et donc la meilleure économie possible, peut reposer sur l’achat de disque plus cher pour ne pas payer un gros et coûteux volume de transactions.
Le changement de niveau de disque est possible au démarrage de la machine virtuelle via le portail Azure ou avec la mise en place d’un script.

Le réseau :

Inutile de se le cacher, la tarification du réseau d’Azure n’est pas simple. Azure considère un transfert de données et son prix change en fonction de sa destination :

Interne à la région Azure : transfert de données entre deux ressources d’une même région Azure. Dans ce scénario, le coût du traffic est nul, pour la plupart des cas :

A noter que le peering de réseaux virtuels, d’une même région Azure ou non, n’est pas gratuit.

Entre deux régions Azure : certains architectures Cloud sont réparties sur plusieurs régions Azure afin de disposer les ressources au plus près des utilisateurs. Tous les mois, les 5 premiers gigas de transfert de données inter-région sont gratuits :

Vers le réseau internet : tous les mois, les 100 premiers gigas de transfert de données vers internet sont gratuits :

Comme pour toute ressource Azure mise en réseau, une machine virtuelle communique via 2 types de flux :

Entrant : connexions entrantes, comme un accès RDP distant ou encore un service web accessible en local ou sur internet. Les flux réseaux entrants vers Azure ne génèrent pas de coûts.
Sortant : connexions sortantes, comme un accès RDP distant ou lors d’un téléversement de fichiers. Les flux réseaux sortant d’Azure génèrent des coûts si la destination est en dehors du réseau Microsoft ou sur une autre région Azure.

*Le routage du trafic via Microsoft Global Network sera plus résilient qu’un routage Internet, mais un peu plus cher.*

Licences logicielles :

La majorité des machines virtuelles vont fonctionner sur Windows ou Linux. Bien souvent, un système d’exploitation nécessite de disposer d’une licence. Microsoft propose donc de payer cette licence uniquement quand la machine est démarrée.

Vous retrouvez ce détail personnalisable dans le Calculateur de prix Azure :

Deux facteurs existent sur le prix de la licence en PAYG :

Le coût de licence va dépendre du nombre de coeurs.
Un nombre d’heures moins important fera baisser le montant du coût de licence.

Qu’est-ce qu’Azure Hybrid Benefit ?

Azure Hybrid Benefit est un avantage en matière de licences qui vous permet de réduire considérablement les coûts d’exécution de vos charges de travail dans le cloud. Son fonctionnement consiste à vous autoriser à utiliser vos licences Windows Server et SQL Server compatibles sur Azure.

L’activation de cette fonction est faisable pendant ou après la création de la machine virtuelle en quelques clics :

Vous pouvez acheter des licences en souscription annuelle ou pluriannuelle. Les économies réalisées représentent des sommes non négligeables.

Enfin, il ne faudra pas oublier d’autres coûts annexes comme la sauvegarde de données, la sauvegarde de logs ou de métriques, ou encore la mise en place d’un service de reprise après sinistre, qui seront rattachés à différents services Azure.

Conclusion

La tarification d’un hébergeur Cloud peut sembler complexe, mais une prédiction des coûts est possible grâce à l’utilisation du Calculateur de prix Azure. La documentation Azure est aussi là pour mieux comprendre les différences entre les SKU et leurs politiques tarifaires.

Enfin, je conseille également un suivi de la consommation post-déploiement via le Gestionnaire des coûts Azure afin de comparer votre prévision avec la réalité, et donc d’améliorer vos estimations futures.

Ne bougez pas, Azure Arc vient à vous !

Ayant eu l’occasion de participer à un évènement conjoint entre TD SYNNEX, Microsoft et DELL et dédié à Azure Stack HCI, j’ai pu m’intéresser au service qui oeuvre dans l’ombre : Azure Arc. L’ouverture d’Azure sur d’autres sites IT que leurs propres datacenters est indispensable, beaucoup d’architectures IT reposent en effet sur des serveurs locaux, ou sont déjà hébergées auprès d’autres fournisseurs Cloud.

Dans cet article, nous allons effectuer ensemble plusieurs méthodes d’intégration très facile de serveurs au service Azure Arc. Nous en profiterons pour faire tour dans les fonctionnalités disponibles gratuitement ou payantes sur les ressources Arc déployées.

Qu’est-ce qu’Azure Arc ?

Azure Arc est une passerelle qui étend la plateforme Azure pour vous aider à créer des applications et des services ayant la souplesse nécessaire pour fonctionner dans des centres de données, à la périphérie et dans des environnements multiclouds.
Microsoft

Combien coûte Azure Arc ?

A la base, Azure Arc ne coûte rien. Il vous permet d’effectuer les actions suivantes sans débourser un seul centime :

Inventaires des ressources Azure Arc
Accès et sécurisation via l’attribution de droits RBAC
Gestion via l’outil Windows Admin Center

Mais certains services annexes sont payants :

Serveur SQL avec Azure Arc
Defender for Cloud
Azure Policy Guest Configuration
Azure Insights
Logs
…

Puis-je tester moi-même Azure Arc avec une VM Azure ?

Non cela n’est pas possible aussi facilement : Azure n’autorise pas d’intégrer directement une machine virtuelle provenant dans la Marketplace Microsoft dans Azure Arc :

Seulement tout le monde ne dispose pas d’une infrastructure IT prête à servir de cobaye pour tester Azure Arc. C’est pourquoi Microsoft propose Azure Arc Jumpstart.

Le Jumpstart fournit des guides étape par étape pour des scénarios Azure Arc indépendants qui intègrent autant d’automatisation que possible, des captures d’écran et des échantillons de code détaillés, ainsi qu’une expérience riche et complète lors de la prise en main de la plateforme Azure Arc.
azurearcjumpstart.io

Pour en avoir testé quelques-uns, c’est très facile et très bien expliqué.

De mon côté, je vous propose une alternative via un exercice facile pour intégrer des serveurs sur Azure Arc via l’utilisation de ressources uniquement hébergées sur Azure.

Etape 0 – Rappel des prérequis :

Les prérequis suivants sont nécessaires pour réaliser cette démonstration d’Azure Arc :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Déploiement d’un template ressources :

Pour créer des ressources intégrables dans Azure Arc, j’utilise un template développé par Microsoft et disponible depuis GitHub : Line-of-business application migration : à la base, ce template est destiné à tester le service Azure Migrate.

Ce dernier vous propose de déployer un serveur Hyper-V, dans lequel se trouve un applicatif web réparti sur plusieurs machines virtuelles et une base de données SQL.

Seule la partie initiale, encadrée en rouge, nous intéresse pour Azure Arc :

Par ce template, nous allons donc déployer une machine virtuelle Standard D8s v3 (8 vCPU, 32 GB memory) avec un rôle Hyper-V. Cette dernière hébergera 4 machines virtuelles :

Windows Server 2016 + SQL Server 2016
Windows Server 2012 Frontend web
Windows Server 2012 Frontend web
Ubuntu WAF

Comme annoncé plus haut, nous allons uniquement nous intéresser à la première étape : déploiement de l’application web via la machine virtuelle Hyper-V

Pour cela, cliquez ici pour charger la configuration du template directement dans votre tenant :

Renseignez les champs suivants et continuez :

*Par défaut :*
Le nom d’utilisateur **demouser**
Le mot de passe **demo!pass123**

Lancez la création et attendez une heure environ :

*Prévoyez au moins une heure à partir du début du déploiement du template pour couvrir l’exécution des script*s.

Remarque : le déploiement du template prend environ 6 à 7 minutes. Une fois le déploiement du modèle terminé, plusieurs scripts supplémentaires sont exécutés pour amorcer l’environnement de laboratoire.

Récupérez l’adresse IP publique suivante :

Ouvrez un nouvel onglet depuis votre navigateur internet avec celle-ci. Vous devriez voir un site web affichant des réservations fictives d’hôtels :

*Un déploiement correctement terminé devrait vous afficher cette page.*

Supprimez le second groupe de ressources destiné aux tests d’Azure Migrate. Nous ne l’utiliserons pas dans le cadre de nos tests sur Azure Arc :

Ouvrez la machine virtuelle SmartHotelHost et cliquez sur Bastion :

Le service Bastion n’est pas créé, lancez son déploiement avec la configuration par défaut :

N’attendez pas la fin du déploiement de Bastion pour continuer.

Etape II – Configuration d’Azure Arc

La configuration d’Azure Arc est très rapide, utilisez la barre de recherche d’Azure pour retrouver le service Azure Arc :

Avant de commencer l’intégration de machines virtuelles à Azure Arc, nous allons créer un principal de service dédié à cette tâche. Ce principal de service va être utilisé pour l’authentification automatique pendant le processus d’intégration des ressources dans Azure Arc.

Cliquez dans le menu suivant :

Cliquez sur Créer :

Renseignez les champs, puis cliquez sur Créer :

Prenez soin de copier l’ID et le secret de principal de service dans un bloc-notes :

Revenez sur la page d’Azure Arc et constatez son apparition :

Une fois Azure Bastion entièrement déployé, retournez sur votre machine virtuelle SmartHotelHost, puis lancez une connexion RDP via Azure Bastion :

Renseignez les identifiants utilisés dans le template, puis cliquez sur Connecter :

La session RDP d’Azure Bastion s’ouvre alors dans un nouvel onglet de votre navigateur web :

Retournez sur le service Azure Arc depuis votre portail Azure, puis cliquez sur Ajouter dans la section Serveurs :

Plusieurs méthodes d’intégration à Azure Arc sont possibles. Le choix de la méthode va surtout dépendre du volume d’intégration à réaliser. Nous allons en tester plusieurs pour vous faire une meilleure idée.

Etape III – Test d’un ajout simple de serveur :

Cette méthode correspond à l’ajout d’un serveur unique sur Azure Arc. Ce premier script effectue les opérations suivantes :

Récupération de l’agent depuis le Centre de téléchargement Microsoft
Installation de l’agent sur le serveur
Création de la ressource serveur compatible avec Azure Arc

Pour utiliser ce script, cliquez comme ceci :

Azure commence par vous présenter les prérequis nécessaires pour assurer la communication entre le serveur et Azure Arc.

La communication repose sur le port 443 (HTTPS), cela nécessite une ouverture de pare-feu pour les flux sortant, et éventuellement la prise en charge d’un service proxy si besoin :

*Aucun blocage réseau n’est présent dans notre environnement de test.*

Cliquez sur Suivant et renseignez les champs :

Renseignez si besoin les étiquettes appropriées, puis cliquez sur Suivant :

Copiez le script suivant dans votre presse-papier :

Retournez sur la session RDP ouverte grâce à Azure Bastion, puis ouvrez la console Hyper-V :

Connectez-vous à la machine Windows smarthotelweb1 :

Renseignez le mot de passe de session Windows : demo!pass123

Dans cette nouvelle session, ouvrez la console PowerShell :

Collez le script donné par Azure Arc et appuyez sur Entrée pour lancer son exécution :

Comme attendu, le script procède au téléchargement et à l’installation de l’agent :

Identifiez-vous avec le compte Azure AD adéquat pour continuer le processus d’intégration :

Validez le processus d’authentification par un challenge MFA si besoin :

Fermez la fenêtre d’Internet Explorer :

Le script vous confirme la bonne création de l’objet serveur dans Azure Arc :

Retournez sur la page des serveurs Azure Arc, rafraîchissez la page si besoin :

Etape IV – Test d’un ajout de plusieurs serveurs :

Pour ajouter plusieurs serveurs à la fois sur Azure Arc, nous pouvons utiliser la seconde option.

Celle-ci génère un facilement script transportable puisqu’il gère l’authentification Azure via l’exploitation du principal de service créé précédemment. Ce script effectue les opérations suivantes :

Récupération de l’agent depuis le Centre de téléchargement Microsoft
Installation de l’agent sur le serveur
Création de la ressource serveur sur Azure Arc

Pour continuer, cliquez comme ceci :

Renseignez les champs et le principal de service, puis cliquez sur Suivant :

Renseignez si nécessaire les étiquettes appropriées, puis cliquez sur Suivant :

Copiez le script dans le presse-papier :

Retournez sur la session d’Azure Bastion. Sur la console Hyper-V, connectez-vous à la machine smarthotelweb2 :

Renseignez le même mot de passe : demo!pass123

Ouvrez la console PowerShell :

Collez votre script en prenant bien soin de remplacer le secret du principal de service par celui donné lors de sa création :

Attendez que le traitement d’intégration se termine :

Retournez sur la page des serveurs d’Azure Arc, rafraîchissez la page si besoin :

Nul besoin de fournir une authentification manuelle d’Azure, ce script est donc destiné à être utilisé pour importer massivement des serveurs sur Azure Arc.

Etape V – Test d’un ajout d’un serveur Linux

Azure Arc supporte également les serveurs fonctionnant sous distribution Linux ,via l’utilisation d’un autre script spécifique. Celui effectue les actions suivantes :

Récupération du script d’installation à partir du Centre de téléchargement Microsoft
Configuration du gestionnaire de packages pour approuver le référentiel
Téléchargement de l’agent à partir du référentiel de logiciels Linux de Microsoft
Installation l’agent sur le serveur
Création de la ressource de serveur sur Azure Arc

Pour continuer, cliquez encore une fois sur la seconde option :

Renseignez à nouveau les champs et le principal de service, puis cliquez sur Suivant :

Renseignez si besoin les étiquettes appropriées, puis cliquez sur Suivant :

Copiez le script dans le presse-papier :

Retournez sur la session d’Azure Bastion. Depuis le serveur Hyper-V, ouvrez directement une console PowerShell et connectez-vous à la machine UbuntuWAF via SSH:

Renseignez le mot de passe : demo!pass123

Collez le script donné par Azure Arc en prenant soin de modifier le secret, puis appuyez sur Entrée pour lancer son exécution :

Laissez la machine redémarrer au besoin :

Une fois le script correctement terminé, vérifiez sur le service Azure Arc l’apparition du serveur Linux :

Etape VI – Test d’un ajout d’un serveur SQL

Une machine virtuelle hébergeant un serveur SQL est également compatible avec Azure Arc et vous permet de le gérer dans votre inventaire. Le processus repose toujours sur le lancement d’un script. Ce dernier effectue les actions suivantes :

Vérification de la connectivité de votre environnement à Azure et à la machine spécifiée
Intégration de la machine hôte via l’agent Azure Connected Machine si absent
Initiation de la découverte d’instances SQL Server
Ajout des instances SQL Server de votre machine cible à Azure Arc

Cliquez comme ceci :

Renseignez les champs, puis cliquez sur Suivant :

Copiez le script dans le presse-papier :

Retournez sur la session d’Azure Bastion, sur la console Hyper-V, ouvrez une connexion vers le serveur smarthotelSQL1 :

Renseignez le mot de passe : demo!pass123 :

Désactivez la protection d’Internet Explorer :

Téléchargez Microsoft Edge par ce lien :

Validez les pop-ups d’Edge :

Ouvrez la console PowerShell :

Collez le script précédemment donné par Azure Arc et validez avec la touche Entrée :

Authentifiez-vous avec votre compte Azure. Si aucune fenêtre ne s’ouvre, saisissez l’URL dans votre navigateur web et authentifiez-vous avec votre compte Azure:

Cliquez sur Continuez :

Attendez que le script termine l’intégration du serveur SQL sur Azure Arc :

Une fois terminé, retrouvez le serveur SQL dans la liste des serveurs d’Azure Arc :

L’agent WindowsAgent.SqlServer est bien présent dans les extensions du serveur :

Retrouvez aussi le serveur SQL dans la liste ci-dessous d’Azure Arc :

Comme un serveur SQL Azure, cette intégration sur Azure Arc apporte une visibilité des bases de données ou apporte une intégration avec Microsoft Defender for SQL :

Etape VII – Test de fonctionnalités d’Azure Arc

Un grand nombre de fonctionnalités sont disponibles pour faciliter la gestion des serveurs intégrés sur Azure Arc. J’en ai sélectionné quelques-unes pour vous :

Windows Admin Center

Inauguré en 2018, Windows Admin Center est une interface web destinée à la configuration de serveurs, comme le ferait déjà Server Manager, mais à distance.

Voici un poster Microsoft récapitulant les fonctionnalités de Windows Admin Center :

Il est également possible de télécharger Windows Admin Center sur n’importe quelle machine Windows 10 (version 1709 ou ultérieure), ou Windows Server (version 2016 ou ultérieure) :

Dans notre exemple, l’installation de Windows Admin Center est nécessaire avant de pouvoir l’utiliser :

Lancez l’installation de Windows Admin Center :

Attendez plusieurs minutes :

Une fois terminée, la notification suivante apparaît alors :

Retournez sur le groupe des ressources Azure Arc pour y ajouter un rôle RBAC supplémentaire à votre identité Azure AD :

Ajoutez le rôle comme ceci :

Retournez sur Windows Admin Center et constatez la disparition de la notification, puis connectez-vous :

*Patientez si besoin plusieurs minutes.*

Retrouvez la console Windows Admin Center et toutes ses fonctionnalités, comme :

Accès au registre Windows
Configuration réseau et pare-feu
Accès aux journaux d’évènements Windows
Explorateur de fichiers

Il est même possible d’ouvrir une session RDP depuis Windows Admin Center 😎

Renseignez le mot de passe de session : demo!pass123

Defender for Cloud

Microsoft Defender pour les serveurs fournit la détection des menaces ainsi que des défenses avancées à vos machines Windows et Linux, qu’elles s’exécutent dans Azure, AWS, GCP ou localement. Microsoft Defender pour les serveurs est disponible dans deux plans :Microsoft Doc

Autrement dit, l’intégration d’une ressource dans Microsoft Defender active un grand nombre de mesures de sécurité (capteurs de faille, évaluation des vulnérabilités, threat intelligence, …), mais apporte également la possibilité de piloter ses alertes et ses incidents depuis le centre de sécurité Microsoft.

Deux plans sont disponibles selon le serveur concerné et les fonctionnalités recherchées. Le plan 2 correspond à l’ancien plan appelé Defender for Server :

La liste des avantages de Defender for Server se trouve ici.

L’activation de Defender for Server est facile, cliquez sur un des serveurs Azure Arc, puis rendez-vous dans la section Sécurité et enfin cliquez comme ceci :

Cliquez sur la souscription hébergeant vos ressources Azure Arc :

Activez le plan destiné à Defender for Servers :

Que le serveur soit sous Linux ou Windows, l’installation d’agent est réalisé de la même manière que pour des ressources Azure :

Azure Policy Guest configuration

Comme pour des ressources Azure, Azure Policy prend en charge l’audit de l’état de votre serveur compatible avec Azure Arc grâce aux politiques de configuration des invités. Les définitions de configuration d’invité d’Azure Policy peuvent auditer ou appliquer des paramètres à l’intérieur de la machine.

Il est à noter que ce service est payant pour des ressources non-Azure :

Contrairement à Defender for Cloud où l’activation est possible depuis une souscription Azure pour l’ensemble des ressources de même type, l’activation de cette fonctionnalité doit s’effectuer sur chacun des serveurs Azure Arc :

Cochez les cases voulues :

Les nouvelles polices sont bien visibles, mais en attente de lancement :

Retournez sur l’Hyper-V pour arrêter la machine virtuelle :

Une fois arrêté, redémarrer là :

Attendez un bon quart d’heure pour espérer voir des résultats sur les polices :

Surveillance

Comme pour les ressources Azure, la sauvegarde des logs est aussi disponible. L’activation de Defender for Server Plan 2 automatise sa mise en place et intègre dans le coût 500 Mo journalier pour les logs :

Insights

L’activation de capacités de surveillance supplémentaires permet d’obtenir des informations sur les performances et les dépendances de vos ressources de l’Arc.

Cliquez-ici pour configurer les paramétrages :

Activez le service :

Un Log Analytics Workspace est nécessaire. Choisissez-en un existant ou créez-en un nouveau :

En entendant le déploiement complet, consultez la liste des extensions pour voir apparaître AMA :

AzureMonitorWindowsAgent pour Windows
AzureMonitorLinuxAgent pour Linux

Il faut bien attendre un peu pour avoir de la donnée et en tirer des analyses intéressantes.

Il restera encore beaucoup à dire sur d’autres fonctionnalités, telles que Machine Configuration ou Centre de gestion des mises à jour, …

Conclusion

Microsoft démontre sous ouverture à d’autres environnements via Azure Arc. La centralisation des opérations sur le portail Azure sans tenir compte de la provenance de la ressource IT est une belle avancée car elle facilite la gestion d’infrastructure. Cela permet en plus de pouvoir toujours profiter des derniers services ajoutés par Microsoft.

Déployez des bases de sécurité Azure en 10 min

Configurer la sécurité sur Azure en seulement 10 minutes ? Et pourquoi pas en 9 minutes ? Cette course au temps ne veut rien dire ! La sécurité est une tâche constante, et passe presque toujours par différentes phases, comme la découverte, l’analyse et la configuration. Néanmoins, une approche directe est malgré tout possible sur certains éléments élémentaires de sécurité.

Microsoft le rappelle très régulièrement, le premier risque identifié provient d’identités mal sécurisées :

Chaque jour, plus de 300 millions de tentatives de connexion frauduleuses à nos services Cloud sont enregistrées. Les cyberattaques ne ralentissent pas, et il convient de noter que de nombreuses attaques ont réussi sans l’utilisation de technologies avancées. Il suffit d’une seule d’identité compromise … pour provoquer une violation de données. Cela montre à quel point il est essentiel de garantir la sécurité des mots de passe et une authentification forte.
Microsoft Blog

Par où commençons-nous ?

Déjà par lire mon article sur la sécurité, accessible juste ici 😁. Plus sérieusement, commencer par assimiler quelques notions, comme la défense en profondeur ou le Zéro Trust.

Principe de sécurité en couche

Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de toute entreprise :

Qu’est-ce que TD SYNNEX peut faire pour ma sécurité ?

Travaillant chez TD SYNNEX depuis plusieurs années, j’accompagne des partenaires IT dans la conception d’architecture sur Azure. La collaboration entre Microsoft et TD SYNNEX est très forte, nous distribuons tous les produits Cloud de Microsoft via une marketplace.

Disposant de compétences techniques en interne, nous développons aussi nos propres solutions pour faciliter et automatiser toujours plus la mise en place de solutions innovantes sur Azure.

Concernant la sécurité, TD SYNNEX n’est pas en reste et propose une nouvelle solution appelée SMB Fraud Défense. Il s’agit d’une solution, dite Click-to-Run, donc prête à l’emploi : quelques clics suffisent pour mettre en place la solution sur un tenant Azure.

Que fait exactement la solution SMB Fraud Defense ?

Voyez un tenant Microsoft comme une maison : les identités et les périphériques sont les portes et les fenêtres. Il est donc évident que ces points des entrées à la donnée :

Des mesures de sécurité sont nécessaires protéger la donnée. Voici une liste non exhaustive des fonctionnalités facilement activables depuis SMB Fraud Defense :

Protection des identités Azure AD :
- Création de scénarios d’accès conditionnel avec MFA
- Restriction géographique par pays
- Blocage d’anciens protocoles d’authentification
- Gestion de l’expiration des mots de passe
- Verrouillage des identités intelligent

Protection des ressources Azure :
- Mise en place de budgets et notifications
- Restrictions géographiques
- Restrictions de familles de machines virtuelles

Combien coûte SMB Fraud Defense ?

Rien du tout 😊, aucun frais à prévoir du côté de TD SYNNEX ou de Microsoft.

Comment procède-t-on pour déployer SMB Fraud Defense ?

Quelques étapes sont nécessaires et sont décrites dans les lignes de cet article, rien de plus.

Etape 0 – Rappel des prérequis :

Avant tout, le déploiement d’une solution Click-to-Run nécessite la mise en place d’un partenariat entre un vous et TD SYNNEX. En effet, ces solutions ne sont disponibles à l’achat qu’uniquement depuis notre Marketplace. Pour cela, cliquez ici.

Le second prérequis est de disposer d’un tenant Azure et d’une souscription Azure Plan acheté via la Marketplace de TD SYNNEX.

Etape I – Achat de la solution Click-to-Run SMB Fraud Defense :

Comme indiqué plus haut, SMB Fraud Defense est gratuit mais demande malgré tout par un provisionnement par depuis la Marketplace de TD SYNNEX.

Une fois votre Azure Plan en place, cliquez sur Modifier :

Parcourez la liste des solutions Click-to-Run disponibles à l’installation, et cliquez sur Acheter SMB Fraud Defense :

Note : La mise en place de la solution vous alerte sur l’incompatibilité avec des solutions MFA externe à Azure

Une fois que vous avez accepté ce message, la plate-forme vérifie la bonne configuration initiale du tenant :

Etape II – Déploiement de la solution Click-to-Run SMB Fraud Defense :

Juste avant de déployer SMB Fraud Defense, il est nécessaire de préparer 3 conditions sur le tenant cible, car la solution analyse les 3 points suivants :

Paramètre de sécurité par défaut d’Azure
Gestionnaire de coûts Azure
Souscription d’une licence Azure AD Premium (Plan 1 ou Plan 2)

Voici un détail point par point pour réussir la préparation et leur statut attendu :

Paramètre de sécurité par défaut d’Azure – désactivé :

La mise en place d’une sécurité personnalisée nécessite la désactivation de la sécurité par défaut d’Azure. Voici ce que cette dernière contient.

Sa désactivation est donc possible via ce menu :

Mais elle est aussi désactivable via le portail d’Azure AD :

Désactivez alors celle-ci en spécifiant un motif justifiant l’opération :

Gestionnaire de coûts Azure – Activé :

La mise en place de budget et d’alerte sur la consommation Azure nécessite l’activation du gestionnaire de coûts Azure.

En effet, la mise en place d’une souscription Azure Plan via un partenaire CSP ne l’active pas par défaut. Il est donc nécessaire de vous rapprocher de votre fournisseur CSP pour l’activation du Gestionnaire de coûts.

Souscription d’une licence Azure AD Premium Plan 1 ou Plan 2 – Souscrite :

La mise en place de l’accès conditionnel sur Azure AD nécessite de disposer d’une licence Azure AD Premium Plan 1 ou Plan 2 :

Pour un déploiement optimal, il est conseillé d’en disposer pour profiter de l’ensemble des avancées de SMB Fraud Defense, comme l’accès conditionnel avec prise en compte de l’évaluation du risque à la connexion.

Vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :

*Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.*

Une fois ces 3 points corrects sur votre environnement, vous pouvez commencer la configuration sur chacun des onglets :

Etape III – Configuration de la solution Click-to-Run SMB Fraud Defense :

Cette configuration est divisée en 5 onglets :

Localisation
Budget
Accès conditionnel
Méthodes d’authentification
Polices

Note : cliquez sur Déployer à la fin, une fois seulement tous les onglets configurés.

A / Localisation

Des informations sont nécessaires pour le bon déploiement des polices Azure. Pour cela, choisissez une région Azure dans le menu déroulant et spécifiez le nom d’un groupe de ressources :

B/ Budget

La mise en place d’un budget est une bonne approche pour suivre la consommation Azure en fonction de l’estimation faite au début du projet :

La mise en place d’alertes l’est tout autant pour éviter les dépassements et donc les factures salées :

Vous pouvez *indiquer plusieurs adresses emails pour les notifications.*

C/ Accès conditionnel

La gestion identitaire d’Azure passe par Azure Active Directory (Azure AD). La sécurisation d’environnement Azure passe donc avant tout par celui-ci.

Vous pouvez contrôler l’accès à vos applications cloud basées sur l’emplacement réseau d’un utilisateur. La condition d’emplacement est couramment utilisée pour bloquer l’accès à partir des pays/régions d’où votre organisation sait que le trafic ne doit pas provenir :

La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Azure AD impose de mettre en place les 3 méthodes d’authentification suivantes :

Un élément que vous connaissez (ex. mot de passe)
Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
Un élément qui vous définit : (ex. identifiant biométrique, tel qu’une empreinte digitale)

Les périphériques et les applications accédant à vos données se doivent d’être protégés.

Il est toujours utile de joindre les périphériques à Azure AD. Comme pour un Active Directory, la connaissance de ces derniers apporte une meilleure maitrise de la sécurité lors de la création de règles de sécurité :

N’ayant pas de poste joint à Azure AD sur cet environnement de démo, je n’active donc pas ces 2 options dans la configuration.

D/ Méthodes d’authentification

Toujours sur la protection des identités, certaines options supplémentaires sont encore configurables :

Le verrouillage intelligent empêche les attaquants de pénétrer dans le système, tout en permettant à vos utilisateurs d’accéder à leur compte et de travailler :

Le déploiement local de Protection de mots de passe d’Azure AD utilise les mêmes listes globales et personnalisées de mots de passe interdits qui sont stockées dans Azure AD, et effectue les mêmes vérifications des modifications de mot de passe localement :

Comme annoncé avant, la validation en deux étapes permet de renforcer la sécurité de votre compte Microsoft en exigeant une deuxième étape de validation lorsque vous vous connectez.

En plus de votre mot de passe, vous pouvez générer un code par l’application Microsoft Authenticator sur votre téléphone :

Autrement, le standard de sécurité FIDO2 répond à ce problème en s’appuyant là aussi sur une authentification à deux facteurs basés sur l’utilisation de clés de sécurité (clés FIDO2) et de tokens (jetons d’authentification) :

E/ Polices

Les polices d’Azure sont un moyen de contrôler les déploiements des ressources. La solution SMB Fraud Defense vous propose de restreindre les SKUs de familles de machines virtuelles. Cela bloque alors les SKUs les plus coûteux :

Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.

Ici, Il est vous possible de restreindre le déploiement sur certaines régions Azure, mais aussi d’activer d’autres fonctionnalités de sécurité :

Tous les onglets ont maintenant été passés en revue, il ne vous reste qu’à déployer la configuration.

Etape IV – Déploiement de la solution Click-to-Run SMB Fraud Defense :

Pour cela, cliquez ici pour lancer le déploiement et attendez quelques minutes :

Une fois le déploiement terminé, un email de notification est également envoyé, et le status de la solution C2R change :

Etape V – Contrôle du déploiement sur le tenant :

Le déploiement est maintenant terminé, une vérification sur le tenant permet de s’assurer la présence de toutes les options choisies durant la phase de la configuration.

A / Localisation

Consultez votre portail Azure et vérifiez la présence du groupe de ressources sur votre souscription Azure Plan :

B/ Budget

Toujours sur la souscription Azure, contrôler l’ajout du budget reprenant le montant configuré :

Cliquez dessus et éditez le pour vérifier la présence des 2 alertes :

C/ Accès conditionnel

La configuration de la restriction géographique s’effectue depuis le portail Azure AD. Consultez la sécurité pour voir l’apparition du pays sélectionné dans les zones de confiance :

Toujours dans Azure AD, chaque option activée a généré la création d’une ou plusieurs polices d’accès conditionnel, toujours en mode audit au moment du déploiement :

D/ Méthodes d’authentification

Le contrôle de la désactivation de l’expiration du mot de passe se fait via le portail Microsoft 365 :

Quant à lui, le contrôle du seuil de verrouillage du compte se fait via le portail Azure AD :

La configuration des deux méthodes MFA d’authentification se retrouve juste ici :

E/ Polices

Du côté d’Azure, contrôlez les polices déployées :

Un clic sur une police affiche le détail de la configuration, comme la région autorisée ou les SKUs interdits :

Conclusion

Alors, finalement nous ne sommes pas si loin des 10 minutes 🤣 ?

Plus sérieusement, je trouve que ce type de solution est une bonne approche quand on voit l’éparpillement des principales mesures de sécurité, qui sont maintenant indispensables pour sécuriser au minimum un tenant Microsoft.

SMB Fraud Defense de TD SYNNEX doit être perçue comme un point de départ à une configuration sécuritaire, et facile son automatisation lors de la création de tenants.

Enfin, il faut garder en tête que ce type de solution Click-to-Run évolue sans cesse chez TD SYNNEX, grâce aux feedbacks et aux évolutions du Cloud Microsoft 🙌

Azure Virtual Desktop ❤️ FIDO2

Rassurez-vous, Azure Virtual Desktop propose depuis longtemps une intégration avec l’accès conditionnel disponible sur Azure AD. Ce billet, datant déjà de 2019, écrit par Freek Berson, nous montre bien l’intégration entre AVD et FIDO2.

Je souhaitais malgré tout vous écrire un article en français pour détailler le processus de mise en place FIDO2 et les possibilités intéressantes avec AVD.

Qu’est-ce que FIDO2 (Fast IDentity Online 2) ?

La réponse de l’industrie au problème des mots de passe.
FIDO Alliance

Exit donc l’utilisation d’un simple du mot de passe pour valider un processus d’authentification. FIDO2 a été développé par la FIDO Alliance et est à ce jour leur dernière norme.

FIDO2 est bâti sur des spécifications Web Authentication, ou WebAuthn, du World Wide Web Consortium (W3C), donc universel mais disposant de capacités supplémentaires.

Cette vidéo en français explique plusieurs de ces avantages :

USB-A ou C ou encore NFC
Absence de donnée personnelle sur la clef
Code PIN de protection
Zone de contact pour valider une présence physique
Utilisation pour plusieurs comptes

Bon conseil : toujours avoir deux clefs 😊.

Puis-je utiliser une clef FIDO2 pour m’authentifier sur Azure AD ?

Oui, Azure AD supporte un grand nombre de méthodes renforcées pour sécuriser l’authentification des utilisateurs. Vous pouvez retrouver cette liste ici, ou dans le portail Azure, via la page des Méthodes d’authentification :

D’une manière générale, Microsoft déconseille l’utilisation unique de mot de passe pour authentifier un compte (Voir tableau ci-dessous). Azure AD propose à ce jour différentes méthodes dans le cadre d’un processus d’authentification multifacteur :

Windows Hello Entreprise
Microsoft Authenticator
Clés de sécurité FIDO2

Ai-je besoin d’une licence particulière pour utiliser FIDO2 ?

FIDO2 n’exige pas de licence particulière, mais l’accès conditionnel en demandera une. En effet, pour intégrer FIDO2 dans une ou plusieurs polices d’accès conditionnel, il vous faudra une licence Azure Premium P1 ou P2 pour tous les utilisateurs concernés.

Fonctionnalité	Azure AD Free – Paramètres de sécurité par défaut	Azure AD Free – Administrateurs généraux uniquement	Office 365	Azure AD Premium P1	Azure AD Premium P2
Accès conditionnel				●	●
Accès conditionnel basé sur les risques					●

Il ne faut pas confondre l’accès conditionnel qui vient en remplacement, car plus abouti et personnalisable que la MFA de base ou les paramètres de sécurité par défaut :

Stratégie	Paramètres de sécurité par défaut	Accès conditionnel	Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise	●
Activé/désactivé en un clic	●
Inclus dans la gestion des licences Office 365	●		●
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365	●	●
Flexibilité de la configuration		●
Fonctionnalité
Exempter les utilisateurs de la stratégie		●	●
Authentification par appel téléphonique ou SMS		●	●
S’authentifier par Microsoft Authenticator et jetons logiciels	●	●	●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels		●	●
Bloque les protocoles d’authentification hérités	●	●	●
Les nouveaux employés sont automatiquement protégés	●	●
Déclencheurs MFA dynamiques en fonction des événements à risque		●
Stratégies d’authentification et d’autorisation		●
Configurable en fonction de l’emplacement et de l’état de l’appareil		●
Prise en charge du mode « Rapport seul »		●

Où peut-on se procurer des clefs FIDO2 ?

Microsoft met à disposition cette liste de fournisseur proposant justement des clefs FIDO2 :

Pour effectuer mes tests sur mon environnement Azure, j’ai décidé d’acheter deux clefs USB-A sous forme de pack auprès de Token2 Switzerland, au prix de 23€, frais de port compris :

Comment procède-t-on pour intégrer FIDO2 à Azure Virtual Desktop ?

Le processus d’installation est très simple, il vous faudra néanmoins quelques prérequis pour arriver à une intégration complète. Dans ce tutoriel, nous allons mettre en place une clef FIDO2 pour un utilisateur et créer deux polices d’accès conditionnel dédiées à AVD :

Etape 0 – Rappel des prérequis :

Les prérequis suivants sont nécessaires pour réaliser cette démonstration avec AVD :

Un poste sous Windows 10 (1903) ou supérieur
Un tenant Microsoft
Une souscription Azure valide
Un environnement AVD déployé (je vous conseille de suivre ce tutoriel)
Une licence Azure AD Premium Plan 1 ou Plan 2

Si votre tenant ne dispose d’aucune licence Azure AD Premium, vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :

Etape I – Configuration du code PIN :

Azure AD exige que les clés de sécurité soient protégées par un code PIN. Insérer votre clef FIDO2 dans un port USB et allez dans les paramètres de votre poste pour le définir :

Cliquez ici pour configurer la clef :

Touchez la zone prévue à cet effet pour continuer :

Définissez un code PIN et confirmez-le :

Etape II – Activation de FIDO2 sur Azure AD :

Sur le portail d’Azure AD, consulter les paramètres de Sécurité via le menu suivant :

Cliquez sur Méthodes d’authentification :

Cliquez sur la ligne FIDO2 :

Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :

Sauvegardez-là avec les options de base :

Quelques minutes sont parfois nécessaire pour continuer sur la configuration FIDO2 au niveau de l’utilisateur. Ne vous inquiétez pas si les écrans suivants ne sont pas encore identiques au tutoriel.

Etape III – Enrôlement d’une clef FIDO2 sur un compte Azure AD :

Comme dit précédemment, la clef FIDO2 n’embarque aucune information personnelle sur les comptes associés à celle-ci. Vous pouvez donc sans souci utiliser la même clef pour plusieurs comptes Azure AD.

Dans mon cas, j’ai créé un nouvel utilisateur pour retester un enrôlement complet.

Rendez-vous sur la page myaccount de Microsoft avec votre utilisateur de test, puis cliquez les Informations de sécurité :

Cliquez ici pour ajouter la première clef FIDO2 :

Dans mon cas, Azure m’avertit que mon utilisateur de test ne dispose d’aucune autre méthode MFA, j’en profite donc pour mettre en place le SMS comme seconde méthode :

Une fois terminé, recommencez le processus pour arriver sur cet écran :

Azure AD entame une communication avec la clef FIDO2 :

Plusieurs messages d’information de Windows 10 vont se succéder :

Renseignez le PIN de votre clef FIDO2, puis continuez :

Touchez la zone prévue à cet effet pour terminer :

Il ne vous reste plus qu’à donner un nom à cette première clef FIDO2 :

Comme il est fortement conseillé, recommencer la même opération avec une seconde clef FIDO2, utilisable en cas de secours :

Etape IV – Test de FIDO2 :

Avant d’aller plus loin dans l’intégration avec Azure Virtual Desktop, je vous conseille de tester l’authentification utilisateur avec sa clef FIDO2. Pour cela ouvrez le navigateur de votre choix en mode privé et allez sur la page web office.com.

Cliquez-ici pour vous authentifier :

Au lieu de saisir le mot de passe du compte de test, cliquez comme ceci :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Cliquez enfin sur Non :

Et vous voilà correctement authentifié sur le portail Office365 😎

Etape V – Création d’une méthode d’authentification renforcée :

En faisant différents tests, je me suis rendu compte que l’on pouvait intégrer le mécanisme FIDO2 à plusieurs niveaux d’AVD.

Pour rappel, je suis partie d’un environnement Azure Virtual Desktop existant et équivalent à ce qui est détaillé dans cet article : Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on – Jean-Loup & Azure (jlou.eu).

Encore en préversion à ce jour, connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu Sécurité :

Cliquez sur Méthodes d’authentification :

Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :

Terminez la création de celle-ci :

Etape VI – Test de l’accès conditionnel au premier niveau :

Toujours dans votre portail Azure AD, retournez dans la section Sécurité puis cliquez sur Accès conditionnel :

Créez votre nouvelle Police :

Saisissez un nom à votre police et sélectionnez votre utilisateur de test :

Ajoutez l’application Azure Virtual Desktop :

Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :

Attendez quelques minutes et ouvrez votre client Windows d’Azure Virtual Desktop pour tester votre première police d’accès conditionnel :

Renseignez le compte Azure de votre utilisateur de test et constatez la présence de ce message :

Touchez la zone prévue à cet effet pour terminer l’authentification :

Félicitations ! Votre accès AVD est bien protégé par la clef FIDO2 😎.

Etape VII – Test de l’accès conditionnel au second niveau :

En parcourant les fonctionnalités de l’accès conditionnel d’Azure AD, j’ai remarqué une seconde application du Cloud Azure très intéressante :

J’ai donc créé une seconde règle d’accès conditionnel, avec les mêmes autres paramètres pour intégrer un mécanisme FIDO2 au moment de l’ouverture de session Windows d’AVD :

Sur votre application Azure Virtual Desktop, cliquez sur l’icône pour ouvrir une session AVD :

Attendez que le processus continue :

Choisissez le compte autorisé à AVD et disposant d’une clef FIDO2 :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Attendez que la session AVD s’ouvre :

Conclusion

Cette combinaison AVD + AD + FIDO2 fut très intéressante à tester, et assez simple à mettre en place. Cette flexibilité nous montre aussi l’infinité de scénarios possibles pour augmenter la sécurité des utilisateurs sans pour autant rendre le quotidien lourd ou invivable.

Enfin, profitez-en pour sécuriser un peu plus vos comptes à vous 🤣

Fournisseur	Biométrie	USB	NFC	BLE	Certifié FIPS	Contact
AuthenTrend						https://authentrend.com/about-us/#pg-35-3
Ciright						https://www.cyberonecard.com/
Ensurity						https://www.ensurity.com/contact
Excelsecu						https://www.excelsecu.com/productdetail/esecufido2secu.html
Feitian						https://shop.ftsafe.us/pages/microsoft
Fortinet						https://www.fortinet.com/
Giesecke + Devrient (G+D)						https://www.gi-de.com/en/identities/enterprise-security/hardware-based-authentication
GoTrustID Inc.						https://www.gotrustid.com/idem-key
HID						https://www.hidglobal.com/contact-us
Hypersecu						https://www.hypersecu.com/hyperfido
IDmelon Technologies Inc.						https://www.idmelon.com/#idmelon
Kensington						https://www.kensington.com/solutions/product-category/why-biometrics/
KONA I						https://konai.com/business/security/fido
NeoWave						https://neowave.fr/en/products/fido-range/
Nymi						https://www.nymi.com/nymi-band
Octatco						https://octatco.com/
OneSpan Inc.						https://www.onespan.com/products/fido
Swissbit						https://www.swissbit.com/en/products/ishield-fido2/
Thales Group						https://cpl.thalesgroup.com/access-management/authenticators/fido-devices
Thetis						https://thetis.io/collections/fido2
Token2 Switzerland						https://www.token2.swiss/shop/product/token2-t2f2-alu-fido2-u2f-and-totp-security-key
Solutions TrustKey						https://www.trustkeysolutions.com/security-keys/
VinCSS						https://passwordless.vincss.net
Yubico						https://www.yubico.com/solutions/passwordless/