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 :

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

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 ????

Privatisez l’accès de votre AVD

Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.

Pourquoi restreindre un service Cloud ?

Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.

Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.

Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :

Qu’est-ce qu’Azure Private Link ?

En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :

Voici une vidéo qui aborde le sujet dans son entièreté :

Comment va fonctionner Azure Virtual Desktop avec Private Link ?

Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.

En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.

A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?

Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.

C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :

La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.

Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?

Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.

Etape 0 – Rappel des prérequis

Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :

Poste Windows 10 avec Azure VPN
Environnement AVD avec jointure Azure AD

On retrouve ainsi mon premier réseau virtuel comprenant :

La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
Le service Azure Bastion pour m’y connecter plus facilement

J’ai également déployé un second réseau virtuel. Celui-ci comprend

Mon environnement Azure Virtual Desktop
Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD

La connexion VPN Point à Site est bien fonctionnelle :

*L’accès direct à une des machines virtuelles AVD répond bien*.

Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :

Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.

Etape I – Activation de la fonction de préversion d’Azure Private Link

Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :

N’oubliez pas de sélectionner la bonne souscription Azure.

Une fois enregistrée, attendez environ 15 minutes.

Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :

Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :

Entre le client et le service Azure Virtual Desktop
Entre le service Azure Virtual Desktop et les machines virtuelles AVD

Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :

Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuel Azure

La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :

Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :

*Comme dit plus haut, l’utilisateur n’en est pas responsable : Le service Azure Virtual Desktop est incapable de communique avec la machine virtuelle AVD.*

Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :

*Pour réactiver les connexions, vous devrez créer un private endpoint* pour chaque *pool d’hôtes AVD que vous souhaitez autoriser.*

Donnez-lui un nom, puis passez à l’onglet suivant :

Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.

Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :

Type de resource	Type de sous-resource	Quantité
Microsoft.DesktopVirtualization/workspaces	global	Un pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspaces	feed	Un par workspace
Microsoft.DesktopVirtualization/hostpools	connection	Un par pool d’hôtes

Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :

Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :

Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :

Lancez la création puis attendez :

Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :

Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.

Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :

Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.

Pour bien comprendre ce qui s’est passé, un test intéressant est de

Créer un groupe de sécurité réseau (NSG)
Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
L’associer au sous-réseau contenant les machines virtuelles AVD

Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.

J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :

Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.

Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :

Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :

Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :

Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.

Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :

Comme précédemment, commencez par créer un private endpoint comme ceci :

Nommez-le différemment du premier private endpoint créé durant l’étape précédente :

Choisissez cette fois-ci la sous-resource cible de type Feed :

Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :

Là encore, des adresses IP privées seront allouées pour les services suivants :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :

Lancez la création puis attendez :

Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.

Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.

Pour cela, créez un nouvel espace de travail AVD :

Nommez-le et lancez sa création :

Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.

Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :

Choisissez le type de sous-resource cible Global :

Choisissez un réseau en relation directe avec votre environnement AVD :

Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :

Lancez la création puis attendez :

Etape IV : Configuration du réseau on-premise

Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.

Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :

*Reprenez tous les enregistrements présents dans la zone DNS créée par les private endpoints*.

Si comme moi votre réseau on-premise est dans Azure, associez cette zone DNS privée à celui-ci.

Etape V : Test de la connexion via Azure VPN Point à Site

Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :

aka.ms/wvdarmweb

Constatez avant tout que la page n’est dorénavant plus joignable :

Démarrez votre connexion VPN grâce au client Azure VPN :

Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :

Cliquez sur l’icône de bureau à distance :

Renseignez une seconde fois son mot de passe :

Et vus voilà dans votre session AVD !

Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :

Réactiver la connexion VPN pour retrouver la session AVD.

Etape VI : Résumé des ressources Azure créées

Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :

3 private endpoints :

3 cartes réseaux :

2 zones DNS privées :

1 second espace de travail AVD :

Etape VI : Aide à la résolution

Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :

*Absence du premier private endpoint sur le pool d’hôtes AVD.*

*Authentification correcte, mais absence d’enregistrements DNS www,* rdweb et client sur le réseau on-premise.

*Authentification correcte, mais absence d’enregistrements DNS .*rdweb sur le réseau on-premise.

*Authentification correcte, mais absence d’enregistrements DNS gateway sur le réseau on-premise.*

Conclusion

Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.

Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route ????

Augmentez la résilience de votre AVD

De manière générale, la grande majorité des services proposés par les principaux hébergeurs Cloud s’accompagnent d’un niveau de service (SLA). Ce Service-level agreement est un point d’accord concernant la disponibilité d’un service entre les utilisateurs et l’hébergeur Cloud. Une architecture entière dispose elle aussi de sa propre SLA. La SLA de ce produit final combine alors toutes les SLAs de ses sous-produits dont elle dépend.

Dans cet article, nous allons parcourir ensemble quelques mécanismes de résilience disponibles sur Azure. Nous testerons aussi ces méthodes dans le cadre de déploiement d’environnement AVD via le portail Azure.

Qu’est-ce que la SLA selon Microsoft ?

Les Contrats de Niveau de Service (« Service-level agreements », SLA) décrivent les engagements de Microsoft en termes de temps de disponibilité et de connectivité. Les SLA pour les différents services Azure sont énumérés ci-dessous.
SLA selon Microsoft

Azure élabore différentes SLAs pour chaque service qu’ils proposent. Certains services encore en préversion, destinés à du développement ou même gratuits peuvent être dépourvus de SLA. Tout naturellement, une SLA plus élevée apporte une meilleure disponibilité au service attendu.

Prenons en exemple la SLA des machines virtuelles créées sur Azure. Cette SLA dépend par exemple des performances des disques rattachés à la machine virtuelle :

Le choix de disques plus performant est une chose facile à comprendre et à mettre en place. Elle est donc la une première démarche à effectuer pour renforcer la résilience.

Quelle SLA dans le cadre d’un Azure Virtual Desktop ?

Azure Virtual Desktop s’appuie lui aussi sur des machines virtuelles Azure. Microsoft propose le un tableau comparant les cinq types de disques disponibles pour vous aider à choisir celui que vous allez utiliser selon votre scénario d’utilisation :

	Disque Ultra	SSD Premium v2	SSD Premium	SSD Standard	HDD Standard
Type de disque	SSD	SSD	SSD	SSD	HDD
Scénario	Charges de travail gourmandes en E/S, telles que le système SAP HANA, les bases de données de niveau supérieur (par exemple, SQL et Oracle), et autres charges de travail très lourdes en transactions.	Charges de travail de production et sensibles aux performances qui nécessitent systématiquement une latence faible, des IOPS et un débit élevé	Charges de travail de production et sensibles aux performances	Serveurs web, applications d’entreprise peu utilisées et Dev/Test	Sauvegarde, non critique, accès peu fréquent

Microsoft vous recommande donc de créer vos machines virtuelles AVD avec des disques Premium SSD, et cela pour trois raisons :

SLA de haut niveau, 99.9 %, indispensable pour environnement de production.
Performances élevées, bande passante et IOPS satisfaisantes.
Rapport qualité / prix en intégrant les coûts transactionnels dans son prix mensuel fixe.

Dans le cadre d’un pool de machines virtuelles AVD avec des disques Premium SSD, la SLA est alors à 99.9 % pour chacune d’elle.

Un autre paramètre rentre en ligne de compte pour renforcer la SLA de machines virtuelles : Nombre de machines virtuelles jouant un rôle identique :

Qu’est-ce qu’un Groupe à haute disponibilité ?

Un Groupe à haute disponibilité est un regroupement logique d’au moins deux machines virtuelles, de manière à fournir une application hautement disponible et à répondre aux exigences du niveau de 99,95 % inscrit dans les contrats de niveau de service Azure. Le groupe à haute disponibilité proprement dit ne vous coûte rien ; vous payez uniquement pour chaque instance de machine virtuelle que vous créez.
Microsoft Learn

Deux notions importantes sont alors configurables grâce à cette fonctionnalité d’Azure :

Domaine de mise à jour : regroupe des machines virtuelles pouvant être mises à jour et donc potentiellement redémarrées en même temps. Le redémarrage des domaines de mise à jour effectue un redémarrage que sur un seul un seul domaine à la fois. (Max 20 domaines de mise à jour par Groupe à haute disponibilité)
Domaine d’erreur : regroupe des machines virtuelles partageant une source d’alimentation et réseau en commune. Cela a pour effet de limiter l’effet des défaillances des équipements physiques, des pannes du serveur et des coupures d’électricité. (Max 3 domaines d’erreur par Groupe à haute disponibilité)

Autrement dit, Azure vous permet de positionner gratuitement vos machines virtuelles dans un Groupe à haute disponibilité, de telle sorte que si l’une d’entre-elles rencontre des difficultés ou une mise à jour Azure, une continuité de service de votre application est assurée via la disponibilité garantie des autres machines virtuelles.

Dans le cas d’un environnement Azure Virtual Desktop, certains services critiques peuvent alors être répartis sur plusieurs Groupes de disponibilité. Par exemple :

Groupe de disponibilité 1 : Les machines virtuelles dédiées au pool d’hôtes AVD
Groupe de disponibilité 2 : Les machines virtuelles dédiées au domaine AD

Qu’est-ce que les Zones de disponibilité ?

Un schéma est souvent plus clair que de longues explications. Voici un empilement hiérarchique du Cloud Microsoft. Chaque service Azure est défini par toutes ces strates ici présentes.

Les géographies d’Azure n’ont pas d’impact direct sur les architectures déployées dans le Cloud. Il faut juste garder en tête qu’une géographie Azure regroupe plusieurs régions Azure.

Le niveau le plus important à retenir est bien la Région Azure. Le Cloud de Microsoft est réparti sur environ une soixantaine de régions Azure. La plupart de ces régions Azure forment une paire de 2 régions. Cette liaison forte apporte des services spécifiques, comme le but d’accroitre les capacités de de reprise après sinistre.

Enfin, de plus en plus de régions Azure disposent de plusieurs Zones de disponibilité :

Les Zones de disponibilité Azure sont des emplacements physiquement séparés au sein de région Azure, qui sont tolérants aux défaillances de centre de données en raison de l’infrastructure redondante et de l’isolation logique des services Azure.
Microsoft Learn

L’intérêt de disposer de lieux géographiques séparés de plusieurs kilomètres, voir dizaines de kilomètres, est d’apporter une meilleure résilience que celle générée via les Groupes à haute disponibilité, toujours présent dans un seul site physique, pour faire face à des sinistres de grande envergure.

A titre d’information, les zones de disponibilité sont disponibles dans la région Azure Suisse Nord depuis mai 2022.

Afin de garantir un haut niveau de performance, Microsoft signale que l’impact sur la latence d’une architecture Azure répartie sur plusieurs Zones de disponibilité est minime voire nul, et cela grâce à une latence inférieure à deux millisecondes entre ces zones.

Il est possible de combiner les Zones de de disponibilité avec les **Groupes à haute** *disponibilit*é.

Microsoft met également à disposition un outil graphique intéressant sur les composantes de l’infrastructure Azure afin d’en savoir un peu plus :

Comme pour presque tous les articles dédiés Azure Virtual Desktop, voici différents tests pour en évaluer l’impact dans le déploiement de vos ressources.

Etape 0 : Rappel des prérequis

Des prérequis sont nécessaires pour réaliser ces démonstrations AVD :

Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure

La mise en place d’une notion de disponibilité doit se faire lors de la création des machines virtuelles. Il n’est plus possible d’agir dessus une fois les machines virtuelles déployées. Cela est donc paramétrable uniquement :

Lors de la création du pool d’hôtes AVD
Lors de l’ajout de nouvelles machines virtuelles à un environnement AVD existant.

Test A : AVD + Groupe à haute disponibilité

Commencez par déployer un pool d’hôtes AVD grâce à la barre de recherche du portail Azure :

*Tapez « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.*

Remplissez le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

L’option ci-dessous nous invite à préciser la notion de disponibilité voulue. Choisissez ici Groupe à haute disponibilité :

Cliquez comme ceci pour en créer un nouveau Groupe à haute disponibilité :

Spécifiez le nom et les nombres de domaines de mise à jour et d’erreurs voulus :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez également un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez le Groupe à haute disponibilité dont elles dépendent :

Consultez l’ensemble des informations de votre Groupe à haute disponibilité en recherchant directement cette ressource Azure depuis votre groupe de ressources :

Ses paramétrages de base ne sont malheureusement plus modifiables :

L’ajout de nouvelle machines virtuelles à votre pool d’hôtes AVD avec ce même Groupe à haute disponibilité est toujours accessible.

La répartition des machines virtuelles est toujours faite en round-robin (équitable)

Finalement, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend bien en charge la répartition des machines virtuelles du pool d’hôtes dans un Groupe à haute disponibilité.

Continuons maintenant avec un second test dédié aux Zones de disponibilité.

Test B : AVD + Zones de disponibilité

Là encore, nous allons commencer par déployer un second pool d’hôtes AVD. Repartez depuis la barre de recherche du portail Azure pour accéder au service AVD :

Remplissez là encore le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

Choisissez dans le même menu déroulant Zones de disponibilité, puis sélectionnez les 3 Zones disponibles dans la région Suisse Nord :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez là encore un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre second déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez la Zone de disponibilité dont elles dépendent :

A l’inverse du Groupe à haute disponibilité, il n’existe pas de ressource Azure symbolisant la Zones de disponibilité. Là encore, plus aucun paramétrage n’est modifiable après création.

Ici aussi, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend lui aussi en charge la répartition des machines virtuelles du pool d’hôtes dans plusieurs Zones de disponibilité.

Remarque importante

Une différence subtile existe les Groupes à haute disponibilité et les Zones de disponibilité. Le premier est bien un groupe dont sont associées plusieurs machines virtuelles, tandis que le second est une affectation d’une machine virtuelle à un datacenter (zone) spécifique.

Au final, pour que ces deux services Azure fassent sens dans votre architecture :

Je n’ai besoin que d’un seul groupe à haute disponibilité pour plusieurs VMs
J’ai besoin de plusieurs zones de disponibilité pour plusieurs VMs

Pourquoi cette précision ?

Car il arrive souvent qu’un doute s’installe sur lesquelles et combien de ces ressources (Groupe à haute disponibilité / Zones de disponibilité) sont nécessaires.

Conclusion

Azure Virtual Desktop continue de progresser en automatisation et en simplicité de déploiement. Le fait que de plus en plus de régions Azure disposent de Zones de disponibilité est une très bonne nouvelle pour la résilience des services Cloud. Enfin Dean de l’Azure Academy nous en reparle en détail dans cette vidéo ????????

Conditionnez l’accès de votre AVD

Je souhaitais faire cet article depuis quelques temps déjà. Comme pour les autres services disponibles sur le Cloud Microsoft, Azure Virtual Desktop nécessite une sécurité renforcée. Hors de question de laisser un accès ouvert aux applications de l’entreprise avec un simple identifiant / mot de passe.

Dans cet article, nous allons commencer par reprendre quelques bases sur l’accès conditionnel disponible sur Azure AD. Puis nous allons le mettre en oeuvre dans un environnement Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel proposé par Azure AD ?

Tous les environnements informatiques sont quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers d’un hébergeur Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations à gérer pour la sécurité IT.

Le périmètre de sécurité moderne s’étend désormais au-delà du réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations peuvent utiliser des signaux d’identité dans le cadre de leurs décisions de contrôle d’accès.
Microsoft Doc

Pour cela, Microsoft propose d’intégrer dans le processus d’authentification à Azure AD de nouvelles étapes, sous forme de police :

*Le schéma ci-dessus est une vue simplifiée des 3 étapes du processus d’accès conditionnel.*

Signal : pour Azure AD, l’accès conditionnel repose sur un certain nombre de signaux ou paramètres. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :

Emplacement (adresse IP)
Appareil (OS, version, conformité, …)
Utilisateur Azure AD
Application interrogée
IA (Détection des risques en temps réel par Azure AD Identity Protection)

Décision : la décision sera alors le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est question ici de bloquer l’accès à l’utilisateur, ou de l’autoriser selon les conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :

Exiger une authentification multifacteur (cas plus utilisé)
Exiger que l’appareil soit marqué comme conforme
Exiger un appareil joint en hybride à Azure AD
Exiger une stratégie de protection des applications

Application : apporte une supervision des sessions et des accès utilisateur aux applications en fonction des stratégies d’accès et de session, telles que :

Empêcher l’exfiltration des données
Protéger lors du téléchargement
Empêcher le chargement de fichiers sans label
Bloquer les programmes malveillants potentiels
Surveiller les sessions utilisateur pour la conformité
Bloquer l’accès

Quelles sont les licences nécessaires pour l’accès conditionnel d’Azure AD ?

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Azure AD Premium P1. Cela est donc bien différent des offres disponibles pour disposer de l’authentification multifacteur (Challenge MFA).

Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

Azure AD Premium P1
Azure AD Premium P2
Enterprise Mobility + Security E3
Enterprise Mobility + Security E5
Microsoft 365 Business Premium
Microsoft 365 A3
Microsoft 365 A5
Microsoft 365 F1
Microsoft 365 F3
Microsoft 365 F5 Security
Microsoft 365 F5 Security + Compliance

Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?

Cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :

Certains services clients ne sont actuellement pas capables de limiter les avantages à des utilisateurs spécifiques. Des efforts doivent être déployés pour limiter les avantages du service aux utilisateurs sous licence.
Doc Microsoft

Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.

*Voici un autre tenant Azure ne disposant d’aucune licence.*

Comment l’accès conditionnel est vécu par un utilisateur ?

Une fois l’accès conditionnel mis en place via une police, la sécurité est immédiatement renforcée par l’application de celle-ci. L’image ci-dessous montre en exemple une authentification multifacteur déployée par ce mécanisme pour protéger le portail Azure :

*L’accès au portail Azure est conditionné à une authentification multifacteur pour cet utilisateur* : challenge MFA.

L’absence de réponse entraîne alors un blocage dans le processus d’authentification et donc de l’accès au portail Azure pour l’utilisateur :

En alternative, si l’utilisateur ne peut pas utiliser cette méthode, Il lui est malgré tout possible de continuer le processus d’authentification par une autre mesure disponible dans la double authentification :

Les réussites ou les échecs des connexions d’utilisateurs sont directement visibles dans le journal des connexions de l’utilisateur sur Azure AD :

Un clic sur une authentification affiche alors les détails et l’application de la police utilisée :

Essai I : Absence de règle d’accès conditionnel

Le premier essai que nous allons faire repose sur aucune configuration particulière.

L’accès au service Azure Virtual Desktop se fait en HTML 5 via l’URL officielle. L’accès conditionnel marcherait également avec les applications installées sur le poste en local, comme le client Remote Desktop, disponible ici au téléchargement.

Aucun blocage ni contrainte pour l’utilisateur n’est constaté :

La sécurité y est donc minimale et l’obtention du login et du mot de passe par un tier permet de se connecter à son environnement et d’accéder aux données.

Essai II : Mise en place d’une règle de blocage total

Le second essai nécessite la création d’une police d’accès conditionnel. Connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu de la Sécurité :

Rentrez dans la section d’Accès conditionnel :

Créez votre nouvelle Police :

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

Cherchez l’application Azure Virtual Desktop dans la section suivante :

Définissez la décision sur Bloquer l’accès :

Activez votre police et validez sa création :

Attendez quelques minutes et retester l’accès à Azure Virtual Desktop sur votre utilisateur. Pour information, l’accès conditionnel d’Azure AD dispose d’une fonction Et Si pour tester vos règles avant de les appliquer :

Quelques minutes plus tard, le test de connexion nous montre que blocage est bien effectif pour cet utilisateur :

*Les conditions d’authentification sont bien réunies, mais ici l’utilisateur n’a tout simplement par le droit de se connecter à AVD.*

Essai III : Mise en place d’une règle pour exiger la MFA

Retournez sur votre accès conditionnel et cliquez sur votre police pour la modifier :

Modifiez la décision pour autoriser l’accès à Azure Virtual Desktop, sous réserve d’un succès au challenge MFA par votre utilisateur de test :

Retentez la connexion à Azure Virtual Desktop avec votre utilisateur de test. La modification MFA de la police est bien prise en compte ici :

Dans mon cas, l’utilisateur est alors invité à enregistrer une ou des méthodes pour le challenge MFA pour poursuivre cette nouvelle opération d’authentification. L’application Microsoft Authenticator est proposée en tant que première méthode du challenge à configurer :

*Il est possible de choisir une autre méthode*.

La méthode MFA choisie est immédiatement vérifiée pour éviter un blocage ultérieur :

Essai IV : Mise en place d’une règle pour bloquer la connexion autre qu’au bureau

La restriction ou le blocage d’un service comme Azure Virtual Desktop est possible selon la localisation de l’utilisateur par son adresse IP. Retournez sur votre police pour la modifier comme ceci :

Pensez à créer votre location de confiance, en reprenant votre propre IP publique :

Retentez la connexion de votre utilisateur à AVD et constatez l’absence de blocage ou de challenge MFA :

Un contrôle dans le journal des connexions nous montre bien le processus d’exclusion de la police d’accès conditionnel grâce à mon adresse IP publique, exclue :

Essai V : Mise en place d’une règle pour exiger le challenge MFA toutes les heures

La mémorisation constante du challenge MFA sur une poste peut être considérée comme un risque sécuritaire, spécialement si le poste est en accès libre pour différents utilisateurs.

Retournez sur votre police pour la modifier comme ceci :

Effectuez l’authentification de votre utilisateur et réussissez le challenge MFA :

Validez la présence des icônes et attendez une heure. Une heure plus tard, rafraîchissez votre AVD :

Une MFA est bien redemandée après le délai défini dans la police d’accès conditionnel.

Conclusion :

Grâce à l’accès conditionnel d’Azure AD, il est assez facile de renforcer la sécurité d’Azure Virtual Desktop. Comme toujours, Microsoft rappelle les risques encourus à seulement utiliser un login et mot de passe pour seule sécurité. L’excellente vidéo de Dean nous montre cela en détail :

En espérant que cela a pu vous aider à mieux sécuriser votre environnement Cloud ????

Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on

Après ces quelques chaudes semaines d’été, il est pour nous l’occasion de nous replonger dans Azure Virtual Desktop et ses dernières nouveautés. Comme vous le savez peut-être, AVD repose sur une authentification d’Azure AD, potentiellement combinée avec un Active Directory classique. Cette méthode apporte une couche de sécurité dans l’accès au service grâce aux mesures de protections disponibles sur Azure AD.

Dans cet article, nous allons nous intéresser au Single Sign-on, ou Authentification Unique, dans Azure Virtual Desktop à travers une première méthode de gestion des identités Cloud : Azure AD. Enfin, nous finirons ce billet par un rapide troubleshooting concernant cette évolution, encore en préversion à l’heure où les lignes de cet article sont écrites.

Avant de commencer, voici un rappel de la définition du Single S ign-on par Wikipédia :

L’authentification unique, souvent désignée par le sigle anglais SSO est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.
Wikipédia

Rappel de l’existant

Afin de bien comprendre l’évolution du SSO dans Azure Virtual Desktop, l’authentification utilisateur s’effectue en deux étapes. Voici un rappel du processus depuis le client Windows Remote Desktop utilisé pour AVD, disponible ici :

Première authentification Azure AD (ou serveur AD FS si besoin) :

Seconde authentification pour l’ouverture de la session Windows :

La mémorisation du mot de passe de session Windows est bien disponible via la case à cocher ci-dessous, mais elle pose un souci de sécurité. Il ne s’agit pas ici de SSO mais d’un classique stockage de mot de passe en local. En effet, le mot de passe sera alors sauvegardé sur le Credential Manager de Windows :

*Sur un ordinateur partagé, cela rendrait simplement l’accès à Azure Virtual Desktop ouvert à tous !*

Microsoft travaille depuis déjà pas mal de temps sur du SSO pour Azure Virtual Desktop. L’excellente vidéo ci-dessous faite il y a quelques mois par Dean Cefola de l’Azure Academy nous montre son processus de mise en place, mais uniquement si l’infrastructure dispose d’un Active Directory avec un serveur AD FS :

Comment faire du SSO sans serveur AD FS ?

C’est dans ce cas précis que la nouveauté de Microsoft intervient ! Une nouvelle option RDP vient de se faire son apparition sur Azure Virtual Desktop. Cette option apporte le SSO de manière 100% native. Petit rappel toujours utile, voici la liste des propriétés RDP acceptées par AVD.

Comme pour presque tous les articles de ce blog, nous allons détailler le processus de mise en place de cette nouvelle fonctionnalité d’AVD :

Etape 0 : Rappel des prérequis

Cette fonctionnalité d’AVD est encore en préversion. Nous allons donc partir d’un environnement Azure vierge et y installer un environnement AVD joint à Azure AD. Voici la courte liste des composants déjà présents sur mon environnement de test :

Tenant Azure
Souscription Azure valide

Etape I : Création du réseau virtuel

Dans un environnement vide, il faut donc commencer par la création d’un réseau virtuel :

Dans mon exemple de test, je ne modifie pas l’adressage réseau :

Attendez que la création se termine pour continuer :

Etape II : Déploiement d’Azure Virtual Desktop

Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :

*Taper « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.*

La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI :

*Il n’est toujours pas possible de stocker les métadatas d’AVD sur un centre de données en Suisse.*

Le choix de l’image Windows utilisée pour Azure Virtual Desktop a son importance ! Actuellement, la fonctionnalité de préversion du SSO repose sur une modification de l’OS Windows, et n’est pour l’instant déployée que sur la version 22H2 de Windows 11 :

La suite des options concernant les machines virtuelles AVD ne changent pas :

Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.

La création de l’espace de travail ne change pas :

Lancez la création et attendez plusieurs minutes :

Une fois le déploiement terminé, constatez la présence des ressources suivantes dans le groupe de ressources :

Etape III : Affectation des utilisateurs AVD

Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou groupes pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par le groupe d’application AVD :

Il est aussi possible de passer par l’attribution d’un rôle RBAC pour cette même opération :

Etape IV : Ajout des rôles RBAC

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles AVD jointes à Azure AD, l’attribution d’un rôle RBAC spécifique est nécessaire. Affectez les deux rôles RBAC suivants sur le groupe de ressources :

Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Etape V : Implémentation de la fonctionnalité SSO

Retournez sur votre pool d’hôtes afin de profiter très facilement de cette nouvelle fonctionnalité :

La sauvegarde de cette option impacte les arguments RDP affichés dans l’onglet Avancé :

Un clic sur la session RDP vous affiche toujours la demande d’authentification de la session Windows :

Lancez un rafraîchissement pour mettre à jour les options RDP :

Retentez l’opération de connexion RDP pour voir cette nouvelle fenêtre apparaître :

Confirmez votre identité :

Acceptez la demande d’autorisation pour autoriser les connexion RDP :

*Il semble que cette demande soit valable pour une machine du pool uniquement.*

La session Windows 11 devrait alors s’ouvrir :

Retentez l’opération une seconde fois pour vérifier le bon fonctionnement du SSO ????

Conclusion

On peut dire que Microsoft a fait le maximum pour simplifier les choses concernant le déploiement de cette nouvelle fonctionnalité AVD ! D’autres articles suivront pour tester les autres cas de gestions des identités via Active Directory.

Encore merci à Dean pour cette annonce et sa vidéo sur le sujet.

Troubleshoot

Depuis l’apparition de cette nouvelle fonctionnalité, je me suis retrouvé embêté dans le déploiement d’environnements AVD joint à Azure AD et sous Windows 10/11 sans utiliser cette nouvelle option.

En effet, mes utilisateurs de test n’étaient plus en mesure de passer l’authentification de la session Windows :

La faute revient à l’impossibilité de remettre l’ancien argument RDP suivant dans ma configuration RDP, comme indiqué dans mon premier article sur le sujet.

targetisaadjoined:i:1

Voici le message d’erreur en question sur mon AVD depuis le portail Azure :

La solution

Pour contourner ce blocage, il est nécessaire de passer cet argument RDP targetisaadjoined:i:1 via une commande PowerShell :

$properties = "drivestoredirect:s:*;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:*;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;use multimon:i:1;targetisaadjoined:i:1"

Update-AzWvdHostPool -ResourceGroupName toto-rg -Name toto-hp -CustomRdpProperty $properties

Retournez sur votre client Remote Destop et lancez un rafraîchissement :

Et sa refonctionne !

En espérant que cela a pu vous aider ????

Programmez la mise à jour de l’agent AVD

La maintenance informatique est une fenêtre nécessaire dans laquelle un service est volontairement indisponible et annoncé en amont. Les architectures basées sur des services Azure n’échappent pas à cette règle car il est toujours nécessaire d’effectuer des maintenances régulières pour des sauvegardes, des mises à jour, des refontes, des réplications, …

Dans cet article, nous allons nous intéresser une nouvelle fonctionnalité disponible sous Azure Virtual Desktop. Encore en préversion à l’heure où ces lignes sont écrites, elle permet de gérer les périodes de mise à jour des agents AVD sur les machines virtuelles qui composent votre pool d’hôtes.

Qu’est qu’un agent AVD ?

Un environnement Azure Virtual Desktop est composée d’une ou plusieurs machines virtuelles. Pour que la communication entre le contrôleur de structure Azure et ces dernières soit assurée, un agent est présent sur chaque machine virtuelle. Un tour dans les programmes installés nous montre tout cela :

L’installation de ces agents est entièrement transparente si la création de la machine virtuelle est réalisée depuis le portail Azure. Si vous créez la machine virtuelle via un script PowerShell, vous devrez alors télécharger et installer manuellement les fichiers MSI.

Quand est-ce que l’agent AVD est mis à jour ?

Avant l’apparition de cette nouvelle fonctionnalité, l’agent AVD se mettait à jour à son rythme sans logique particulière. A ce ceci près qu’il existait une option ayant un impact sur le rythme de mise à jour : environnement de validation.

Qu’est-ce que l’environnement de validation ?

Nous (Microsoft) vous recommandons vivement de créer un pool d’hôtes de validation dans lequel les mises à jour de service seront appliquées en premier. Les pools d’hôtes de validation vous permettent de superviser les mises à jour de service avant que celui-ci ne les applique à votre environnement standard ou de non-validation. Sans pool d’hôtes de validation, vous risquez de ne pas détecter les modifications qui génèrent des erreurs, ce qui peut entraîner des temps d’arrêt pour les utilisateurs de votre environnement standard.
Microsoft Doc

Autrement dit, la mise à jour est orientée en premier lieu vers les pools d’hôtes marqués comme environnement de validation. Une fois la mise à jour déployée avec succès en grand nombre sur des environnements de validation, elle est aussi installée sur les machines virtuelles d’environnements AVD de production.

De manière générale, un environnement de validation a tout son sens dans une solution de bureau à distance car il apporte une couche supplémentaire de tests via des utilisateurs spécifiques et évite ainsi un déploiement pouvant provoquer un blocage massif.

Mises à jour planifiées de l’agent

Toujours dans la volonté d’apporter une meilleure maîtrise de l’environnement Azure Virtual Desktop, Microsoft introduit la fonctionnalité de planification. Celle-ci ne concerne que la mise à jour de l’agent AVD présent sur les machines virtuelles du pool d’hôtes.

Comme vous allez le voir dans les écrans ci-dessous, cette option se configure au niveau du pool d’hôtes et impacte alors toutes les machines virtuelles rattachées de la même manière.

Via le portail Azure, rendez-vous sur votre pool d’hôtes et cliquez sur Mises à jour programmées des agents :

Cliquez sur la case ci-dessous pour activer la gestion manuelle des mises à jour :

Il vous est alors possible de définir une ou deux fenêtres de maintenance. Comme indiqué sur la page, 4 tentatives de mise à jour seront effectuées avant que celle-ci soit reportée la prochaine fois que les hôtes de session seront allumés.

Commencez par définir le fuseau horaire. Vous avez le choix entre celui employé par la machine virtuelle ou un parmi la liste déroulante :

Définissez le jour et l’heure de la première fenêtre de mise à jour :

Ajoutez au besoin une seconde fenêtre de mise à jour :

Enfin cliquez pour appliquer la configuration :

Et c’est tout ! ????

Conclusion

Azure Virtual Desktop continue son chemin et évolue en permanence ????. Pour rester sur ce sujet, retrouvez la vidéo très bien expliquée faite par Dean de l’Azure Academy. Dean y aborde également la possibilité de consulter l’historique des mises à jour installées via l’utilisation du Log Analytics Workspace d’Azure :

Testez MSIX App Attach dans votre AVD

La conteneurisation applicative est accessible sur Azure Virtual Desktop depuis plusieurs mois. L’attachement via MSIX permet de fournir des applications à des machines virtuelles sans aucune installation locale. Cependant, Il est ici différent du format MSIX normal, car celui-ci est spécialement conçu pour AVD. Pour en savoir plus sur MSIX, consultez la page web Présentation de MSIX.

Pourquoi faire de la conteneurisation applicative pour Azure Virtual Desktop ?

Azure Virtual Desktop est principalement conçu pour délivrer une expérience utilisateur commune et partagée. Il arrive fréquemment que certains utilisateurs travaillent sur des applications spécifiques. Dans ce cas, il est possible de leur délivrer cet attendu de plusieurs manières :

Gestion de applications requises dans une image OS spécifiquement dédiée
Utilisation de solution de type Intune pour un déploiement distribué
Approvisionnement d’applications via des solutions tierces (Liquidware Flexapp, Citrix AppLayering)
Utilisation d’applications conteneurisées

Dans cet article, nous allons démontrer ensemble la dernière possibilité.

Etape 0 : Rappel des prérequis

Comme pour chaque déploiement réalisé sur ce blog, des prérequis sont nécessaires avant de pouvoir se concentrer sur MSIX AppAttach :

Un tenant Microsoft (AAD)
Une souscription Azure active
Un domaine Active Directory Domain Services (AD DS)
Un espace de stockage Azure joint au domaine AD DS
Un agent Azure AD Connect installé et synchronisé avec votre Azure AD
Un environnement Azure Virtual Desktop (Pool d’hôtes – Groupe d’application – Espace de travail – VMs)
Facultatif : un Azure Bastion pour faciliter les connexions RDP

Une fois votre environnement Azure en place, plusieurs étapes sont nécessaires pour arriver à la mise à disposition des applications conteneurisées.

Etape I : Déployer une nouvelle VM Azure Windows 10

Cette nouvelle machine virtuelle vous nous être utile pour créer différents composants nécessaires :

Création d’un certificat pour signature des packages MSIX
Création du package MSIX
Configuration des VMS AVD pour supporter la couche conteneur
Création de l’image VHD
Dépose de l’image VHD sur le partage de fichier

*J’ai ici repris la même image Windows 10 que celle utilisée pour AVD.*

*Pas besoin d’adresse IP publique dans mon cas grâce à Azure Bastion.*

Patientez quelques minutes une fois la création lancée :

Une fois cette VM créée, utilisez Azure Bastion pour vous connecter en RDP sur votre machine virtuelle :

Joignez cette machine virtuelle au domaine AD DS, puis redémarrez-là :

Etape II : Préparation du certificat

Reconnectez à votre VM MSIX via Azure Bastion, puis lancez Windows PowerShell ISE, en mode administrateur :

Exécutez les commandes PowerShell suivantes :

Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Scheduled Start" /Disable
reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload /t REG_DWORD /d 0 /f
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager /v PreInstalledAppsEnabled /t REG_DWORD /d 0 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Debug /v ContentDeliveryAllowedOverride /t REG_DWORD /d 0x2 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
reg add HKLM\Software\Microsoft\RDInfraAgent\MSIXAppAttach /v PackageListCheckIntervalMinutes /t REG_DWORD /d 1 /f

Exécutez la commande PowerShell suivante pour générer un certificat auto-signé sur votre domaine (JLOUDEV), et stockez le dans le dossier Personal des certificats locaux :

New-SelfSignedCertificate -Type Custom -Subject "CN=Jloudev" -KeyUsage DigitalSignature -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "cert:\LocalMachine\My

Exécutez certlm.msc pour ouvrir la console des certificats locaux :

Lancez la commande d’Export sur ce nouveau certificat :

Cliquez sur Suivant :

Sélectionnez l’option Oui, exporter la clé privée, puis cliquez sur Suivant :

Cochez la case Exporter toutes les propriétés étendues, décochez la case Activer la confidentialité des certificats, puis cliquez sur Suivant :

Cochez la case Mot de passe, renseignez les deux champs dessous, puis cliquez sur Suivant :

Créez un nouveau dossier, par exemple celui-ci :

C:\MSIX

Renseignez le chemin de destination, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser le processus :

Etape III : Déploiement du certificat sur les machines virtuelles AVD

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour déployer le certificat nouvellement généré dans Trusted People des machines virtuelles AVD :

$avdhosts = 'avd-vm-0','avd-vm-1'
$cleartextPassword = 'Demo!pass123'
$securePassword = ConvertTo-SecureString $cleartextPassword -AsPlainText -Force
$localPath = 'C:\MSIX'
ForEach ($avdhost in $avdhosts){
  $remotePath = "\\$avdhost\C$\MSIX\"
  New-Item -ItemType Directory -Path $remotePath -Force
  Copy-Item -Path "$localPath\jloudev.tk.pfx" -Destination $remotePath -Force
  Invoke-Command -ComputerName $avdhost -ScriptBlock {
     Import-PFXCertificate -CertStoreLocation Cert:\LocalMachine\TrustedPeople -FilePath 'C:\MSIX\jloudev.tk.pfx' -Password $using:securePassword
  } 
}

Un tour rapide grâce à Azure Bastion sur une des machines virtuelles AVD nous confirme la bonne présence du certificat :

Etape IV : Téléchargements de l’application Mozilla Firefox

Dans notre démonstration, nous allons télécharger la dernière version de Mozilla Firefox. Nous prendrons l’installation au format MSI, disponible ici.

Lancez le téléchargement depuis la machine virtuelle MSIX comme ceci :

Copiez le fichier téléchargé dans le dossier C:\MSIX :

Etape V : Préparation avant création

Avant de lancer la création, exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour désactiver le service de recherche de Windows :

$serviceName = 'wsearch'
Set-Service -Name $serviceName -StartupType Disabled
Stop-Service -Name $serviceName

Profitez-en également pour créer cette nouvelle arborescence :

New-Item -ItemType Directory -Path 'C:\MSIX\Firefox' -Force

Exécutez la commande PowerShell suivante pour supprimer le Zone.Identifier des fichiers d’installation téléchargés depuis Internet :

Get-ChildItem -Path 'C:\MSIX' -Recurse -File | Unblock-File

Etape VI : Création du package applicatif

Pour continuer, vous aurez besoin de MSIX Packaging Tool, que vous trouverez dans le Microsoft Store. Lancez le téléchargement de ce dernier, toujours depuis la machine virtuelle MSIX :

Une fois le téléchargement terminé, lancez l’application.

Sur la page d’accueil, sélectionnez Application package afin de lancer la création d’un nouveau paquet :

*Vous aurez peut-être besoin de redémarrer la machine pour continuer.*

Sur la page suivante, cochez la case Créer le paquet sur cet ordinateur, puis cliquez sur Suivant :

Attendez l’installation du pilote de l’outil de conditionnement MSIX, puis cliquez sur Suivant :

Sélectionnez Parcourir pour accéder au fichier d’installation de Firefox au format MSI :

C:\MSIX\Firefox Setup 95.0.msi

Dans la liste déroulante Préférence de signature, sélectionnez Signer avec un certificat (.pfx).

Recherchez le certificat C:\MSIX\jloudev.tk.pfx, saisissez le mot de passe Demo!pass123, puis cliquez sur Suivant :

Examinez et modifiez si besoin le nom du paquet, vérifiez que le nom de l’éditeur est défini sur CN=JLOUDEV, puis cliquez sur Suivant :

Cela déclenche alors l’installation de Mozilla Firefox de manière encapsulée :

Une fois l’installation terminée, vous retrouvez le message ci-dessous, cliquez sur Suivant :

Cliquez alors sur Suivant.

Lorsque le système vous demande Avez-vous terminé ?, sélectionnez Oui :

Vérifiez dans l’écran ci-dessous qu’aucun service n’est nécessaire, puis cliquez sur Suivant :

Changez le fichier et le dossier de destination :

C:\MSIX\Firefox\Firefox

Une fois la création terminée, cliquez sur Fermer :

Retrouvez les fichiers MSIX et XML suivants dans votre dossier C:\MSIX\Firefox :

Copiez seulement le fichier MSIX dans le dossier racine C:\MSIX :

Etape VII : Installation des fonctionnalités d’Hyperviseur

Maintenant, vous allez activer la fonctionnalité d’Hyperviseur sur l’ensemble des machines virtuelles Azure Virtual Desktop, mais également sur la machine MSIX :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour commencer l’activation sur les VMs AVD :

$avdhosts = 'avd-vm-0','avd-vm-1'
ForEach ($avdhost in $avdhosts){
  Invoke-Command -ComputerName $avdhost -ScriptBlock {
     Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Scheduled Start" /Disable
     reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload /t REG_DWORD /d 0 /f
     reg add HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager /v PreInstalledAppsEnabled /t REG_DWORD /d 0 /f
     reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Debug /v ContentDeliveryAllowedOverride /t REG_DWORD /d 0x2 /f
     reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
     reg add HKLM\Software\Microsoft\RDInfraAgent\MSIXAppAttach /v PackageListCheckIntervalMinutes /t REG_DWORD /d 1 /f
     Set-Service -Name wuauserv -StartupType Disabled
  }
}

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour installer Hyper-V et ses outils de gestion sur les VMs AVD :

$avdhosts = 'avd-vm-0','avd-vm-1'
ForEach ($avdhost in $avdhosts){
  Invoke-Command -ComputerName $avdhost -ScriptBlock {
     Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
  }
}

Chaque hôte AVD doit redémarrer pour prendre en compte les modifications : cliquez sur Oui :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour installer Hyper-V et ses outils de gestion sur la machine virtuelle MSIX :

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

La machine virtuelle MSIX doit elle aussi redémarrer :

Reconnectez-vous sur machine virtuelle MSIX, avec le même compte utilisateur qu’utilisé précédement :

Etape VIII : Créer une image jointe à une application MSIX

Ouvrez Microsoft Edge et rendez-vous sur la page suivante pour télécharger msixmgr.zip.

Dans l’Explorateur de fichiers, accédez au dossier Téléchargements, ouvrez le fichier compressé et copiez le dossier x64 dans le dossier C:\MSIX :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer le fichier VHD qui servira d’image jointe de l’application MSIX :

New-Item -ItemType Directory -Path 'C:\MSIX\MSIXVhds' -Force
New-VHD -SizeBytes 256MB -Path 'C:\MSIX\MSIXVhds\Firefox.vhd' -Dynamic -Confirm:$false

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell IS, en mode administrateur , pour monter le fichier VHD nouvellement créé :

$vhdObject = Mount-VHD -Path 'C:\MSIX\MSIXVhds\Firefox.vhd' -Passthru

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer une nouvelle partition, la formater, et lui attribuer la première lettre de lecteur disponible :

$disk = Initialize-Disk -Passthru -Number $vhdObject.Number
$partition = New-Partition -AssignDriveLetter -UseMaximumSize -DiskNumber $disk.Number
Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force

Cliquez sur Annuler pour ne pas formater à nouveau ce disque :

Le nouveau disque image est déjà présent dans l’explorateur de fichiers :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer une structure de dossier qui hébergera les fichiers MSIX :

$appName = 'Firefox'
New-Item -ItemType Directory -Path "$($partition.DriveLetter):\Apps" -Force
Set-Location -Path 'C:\MSIX'
.\x64\msixmgr.exe -Unpack -packagePath .\$appName.msix -destination "$($partition.DriveLetter):\Apps" -applyacls

Constatez la présences des fichiers dans le nouveau disque :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour démonter le fichier VHD qui servira d’image MSIX :

Dismount-VHD -Path "C:\MSIX\MSIXVhds\$appName.vhd" -Confirm:$false

Etape IX : Configurer le groupe Active Directory contenant les hôtes AVD

Retournez sur votre contrôleur de domaine via Azure Bastion :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer un groupe AD DS qui sera synchronisé avec Azure AD :

$ouPath = "OU=AVD-Devices,DC=jloudev,DC=tk"
New-ADGroup -Name 'avd-hosts' -GroupScope 'Global' -GroupCategory Security -Path $ouPath

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour ajouter les machines virtuelles AVD en tant que membres du groupe que vous avez créé à l’étape précédente :

Get-ADGroup -Identity 'avd-hosts' | Add-AdGroupMember -Members 'avd-vm-0$','avd-vm-1$'

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour redémarrer les VMs AVD :

$hosts = (Get-ADGroup -Identity 'avd-hosts' | Get-ADGroupMember | Select-Object Name).Name
$hosts | Restart-Computer

Ce nouveau groupe doit faire partie des synchronisations vers Azure AD. Pour cela, vérifiez dans votre configuration Azure AD Connect que cette OU est bien synchronisée :

Contrôlez après 30 minutes que le nouveau groupe remonte bien dans Azure AD :

Pour que les machines virtuelles Azure Virtual Desktop remontent bien dans ce groupe, il est nécessaire de reconfigurer également Azure AD Connect.

Retournez dans ce dernier pour activer la fonctionnalité Hybrid Azure AD Join :

Une fois les identifiants d’administrateur global renseignés, choisissez l’option ci-dessous :

Cochez la case pour remonter les machines Windows 10 et ultérieures :

Renseignez un compte Enterprise Administrator :

Une fois la configuration d’Azure AD Connect terminée :

Redémarrez les machines virtuelles AVD
Utilisez Azure Bastion pour vous connecter sur chaque VM AVD avec le compte avdadmin1@jloudev.tk
Retournez sur votre contrôleur de domaine via Azure Bastion (ou sur la machine virtuelle sur laquelle est installé Azure AD Connect), puis saisissez la commande PowerShell suivante en mode administrateur :

Start-ADSyncSyncCycle -PolicyType Initial

Attendez quelques minutes et contrôler la présence des machines virtuelles AVD dans le groupe AD sur Azure AD :

Etape X : Ajout des droits pour les VMs AVD sur le compte de stockage

Afin de mettre à disposition l’application packagée, nous allons créer un nouveau partage de fichier sur le compte de stockage existant.

Retournez sur votre portail Azure et rendez-vous sur le compte de stockage utilisé pour FSLogix :

Cliquez sur ce nouveau partage de fichier pour rajouter les 3 droits d’accès suivants :

Option	Valeur
Rôle	Storage File Data SMB Share Elevated Contributor
Assign access to	Group
Select	avd-admins

Option	Valeur
Rôle	Storage File Data SMB Share Elevated Contributor
Assign access to	Group
Select	avd-hosts

Option	Valeur
Rôle	Storage File Data SMB Share Reader
Assign access to	Group
Select	avd-group

Une fois les droits en place, retournez sur votre machine virtuelle MSIX avec le compte avdadmin1 via Azure Bastion, pour connecter ce nouveau partage de fichier grâce à la commande suivante :

$connectTestResult = Test-NetConnection -ComputerName jlosto.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Mount the drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\jlosto.file.core.windows.net\msixvhds" -Persist
} else {
    Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}

Exécutez les commandes suivantes via le programme CMD pour accorder les permissions NTFS requises :

icacls Z:\ /grant JLOUDEV\avd-hosts:(OI)(CI)(RX) /T
icacls Z:\ /grant JLOUDEV\avd-group:(OI)(CI)(RX) /T
icacls Z:\ /grant JLOUDEV\avd-admins:(OI)(CI)(F) /T

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour recopier le fichier VHD vers le partage de fichiers Azure :

New-Item -ItemType Directory -Path 'Z:\packages' 
Copy-Item -Path 'C:\MSIX\MSIXVhds\Firefox.vhd' -Destination 'Z:\packages' -Force

Un contrôle dans l’explorateur de fichier nous permet de vérifier la bonne présence de ce dernier :

Etape XI : Ajout de l’application MSIX sur l’environnement Azure Virtual Desktop

On arrive presque au bout ! Il ne nous reste maintenant qu’à rajouter notre application MSIX sur notre pool d’hôtes Azure Virtual Desktop. Pour cela, retournez sur votre portail Azure et cherchez votre pool d’hôtes, cliquez sur MSIX packages, puis sur Ajouter :

Saisissez le chemin suivant pour chercher le package nouvellement généré :

\\jlosto.file.core.windows.net\msixvhds\packages\Firefox.vhd

Renseignez les champs ci-dessous de la façon suivante, puis cliquez sur Ajoutez :

Vérifiez la bonne présence de votre application dans l’écran des applications :

Rendez-vous maintenant dans la section groupe d’applications, puis cliquez sur Ajouter :

Renseignez un nom à votre groupe d’applications, puis cliquez sur Suivant :

Sur le second onglet, cliquez sur Ajouter des applications :

Renseignez les champs ci-dessous, puis cliquez sur Sauvegarder et passez à l’onglet suivant :

Ajoutez votre groupe d’utilisateurs AVD puis passez sur l’onglet suivant :

Reprenez votre espace de travail existant puis validez les derniers onglets pour lancer la création :

Quelques minutes plus tard, la création se termine :

Etape XII : Test du package MSIX

Pour cela rien de plus simple, ouvrez l’application Remote Desktop. Voici le lien vers la page Microsoft si vous avez besoin de la télécharger :

Une fois installée, cliquez sur Souscrire :

Renseignez les identifiants d’un utilisateur présent dans votre groupe d’utilisateurs AVD :

Décochez la case et cliquez sur Non :

Constatez la présence de l’icône de bureau à distance et du nouvel icône pour Firefox :

Cliquez sur Firefox et renseignez le mot de passe de l’utilisateur AVD :

Firefox s’ouvre bien comme une application publiée sur votre poste local !!!

Le petit icône spécial dans la barre des tâches vous montre bien qu’il s’agit d’une application publiée et non locale :

Conclusion

Félicitations ! Vous avez réussi votre premier package applicatif via MSIX sur votre environnement Azure Virtual Desktop. On ne va pas se mentir, les premières opérations de mise en place demandent de la vigilance. Mais à force de pratiquer, les choses deviennent plus simples. Nul doute que tout cela peut vous faire gagner un temp considérable dans la mise à jour des applications dans de larges environnements Azure Virtual Desktop.

Comme toujours, faites part de vos remarques dans les commentaires ????

Associez FSLogix avec Azure AD

Microsoft vient tout juste de l’annoncer en préview : vous pouvez maintenant gérer les identités d’un partage de fichiers Azure PaaS directement avec Azure AD !

C’est une excellente nouvelle, attendue depuis plusieurs mois par de nombreux utilisateurs d’Azure Virtual Desktop, notamment pour mettre en place des solutions comme FSLogix, déjà utilisée pour la gestion des profils utilisateurs, sans serveur AD DS. Par contre, il y a encore une petite mauvaise nouvelle :

Cette fonctionnalité nécessite actuellement que les utilisateurs aient des identités hybrides, gérées dans Active Directory.
Documentation Microsoft

Quel est donc l’intérêt ?

Cette contrainte d’avoir un environnement hybride, qui sous-entend donc la présence d’un domaine AD, n’est pas forcément une mauvaise chose. Il s’agit ici d’une avancée technique intermédiaire. Nul doute que ce prérequis ne sera plus nécessaire à moyen terme.

Dans cet article, nous allons donc tester cette nouvelle fonctionnalité. Le but de tester cette préview de gestion des tickets Kerberos par Azure AD est de mesurer les avancées Microsoft. Vous pouvez suivre la documentation leur officielle ici.

Etape 0 : Rappel des prérequis

Comme vous allez travailler avec des tickets Kerberos spécifiques à Azure AD, il est obligatoire que les postes ayant accès au partage de fichiers PaaS disposent de l’un des OS suivants :

Windows 11 Enterprise mono ou multisession
Windows 10 Enterprise mono ou multisession, en version 2004 ou ultérieure avec la mise à jour KB5007253
Windows Server, version 2022 avec la dernière mise à jour KB5007254

Dans mon cas, j’ai utilisé l’environnement suivant :

une VM Windows Server 2022 pour jouer le contrôleur de domaine
Une environnement AVD composé de VMs en Windows 11 Enterprise multisession

Comme annoncé avant, les postes en accès au partage de fichier doivent donc être joints à Azure AD ou en mode hybride (Active Directory + Azure AD). Néanmoins, les utilisateurs doivent être « hybrides », il est donc nécessaire de passer par Azure AD Connect pour y arriver. Le choix du domaine managé Azure AD DS n’est donc pas possible ici :

Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS fournit des services de domaine managé avec un sous-ensemble de fonctionnalités AD DS traditionnelles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM.
Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets, la stratégie de groupe et les approbations.

Au final, les prérequis sont donc les suivants :

Un tenant Microsoft (Azure AD)
Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
Une souscription Azure active avec le rôle de propriétaire :

Un domaine Active Directory Domain Services (AD DS) :

Un agent Azure AD Connect installé et configuré pour l’hybridation (lire jusqu’à l’étape III)

Des utilisateurs AVD présents dans AD DS et synchronisés avec Azure AD :

Un environnement Azure Virtual Desktop déployé et lié à votre domaine AD DS :

Des machines virtuelles AVD jointes é la fois à votre AD DS et enrôlées dans votre Azure AD :

Une fois cela en place, déroulez les prochaines étapes d’installation depuis votre contrôleur de domaine.

Etape I : Création d’un nouveau compte de stockage

Sur votre portail Azure, commencez par créer votre nouveau compte de stockage :

Une fois créé, stockez l’ID de la souscription Azure, le nom du groupe de ressources et le nom du compte de stockage dans les variables suivantes :

$resourceGroupName = "<MyResourceGroup>"
$storageAccountName = "<MyStorageAccount>"
$Subscription = "<MySubscriptionID>"

Etape II : Configuration de l’authentification Azure AD

Vous allez utiliser plusieurs nouvelles fonctionnalités, il est donc préférable de réinstaller des modules PowerShell sur votre poste. Ouvrez PowerShell ISE en mode administrateur et lancez la commande suivante :

Install-Module -Name Az.Storage -AllowClobber
Install-Module -Name AzureAD -AllowClobber

Validez les messages d’avertissement si besoin :

L’activation de l’authentification via Azure AD passe elle aussi par une commande PowerShell :

Connect-AzAccount
$ApiVersion = '2021-04-01'

$Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

$json = 
   @{properties=@{azureFilesIdentityBasedAuthentication=@{directoryServiceOptions="AADKERB"}}};
$json = $json | ConvertTo-Json -Depth 99

$token = $(Get-AzAccessToken).Token
$headers = @{ Authorization="Bearer $token" }

try {
    Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json;
} catch {
    Write-Host $_.Exception.ToString()
    Write-Error -Message "Caught exception setting Storage Account directoryServiceOptions=AADKERB: $_" -ErrorAction Stop
}

Le lancement du script PowerShell vous demandera de vous authentifier en utilisant un compte propriétaire de la souscription Azure :

Le lancement réussi du script devrait vous donner le résultat suivant :

Constatez l’activation de la fonctionnalité en préview, directement sur le compte de stockage :

Il ne reste en plus qu’à générer une nouvelle clef pour le protocole Kerberos :

Set-azcontext -Subscription $Subscription
New-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -KeyName kerb1 -ErrorAction Stop

Cette clef n’est pas contre pas visible sur le portail Azure.

Etape III : Création d’une identité principal de service

L’activation des droits d’Azure AD sur le compte de stockage n’est pas encore possible via le portail Azure. Commencez par générer un mot de passe, basé sur la nouvelle clef Kerberos de votre compte stockage, et stocker le dans une variable grâce à la commande PowerShell suivante :

$kerbKey1 = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -ListKerbKey | Where-Object { $_.KeyName -like "kerb1" }
$aadPasswordBuffer = [System.Linq.Enumerable]::Take([System.Convert]::FromBase64String($kerbKey1.Value), 32);
$password = "kk:" + [System.Convert]::ToBase64String($aadPasswordBuffer);

Lors d’une étape précédente, vous vous êtes déjà connecté à Azure. Connectez-vous maintenant à Azure AD :

Connect-AzureAD
$azureAdTenantDetail = Get-AzureADTenantDetail;
$azureAdTenantId = $azureAdTenantDetail.ObjectId
$azureAdPrimaryDomain = ($azureAdTenantDetail.VerifiedDomains | Where-Object {$_._Default -eq $true}).Name

Utilisez ici un compte administrateur global du tenant :

Préparer la génération du principal de sécurité :

$servicePrincipalNames = New-Object string[] 3
$servicePrincipalNames[0] = 'HTTP/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[1] = 'CIFS/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[2] = 'HOST/{0}.file.core.windows.net' -f $storageAccountName

Créez et chargez dans une variable les éléments nécessaires à la future Enregistrement d’applications :

$application = New-AzureADApplication -DisplayName $storageAccountName -IdentifierUris $servicePrincipalNames -GroupMembershipClaims "All";

Générez alors le principal de sécurité :

$servicePrincipal = New-AzureADServicePrincipal -AccountEnabled $true -AppId $application.AppId -ServicePrincipalType "Application";

Configurez le mot de passe stocké précédement pour celui-ci :

$Token = ([Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens['AccessToken']).AccessToken
$apiVersion = '1.6'
$Uri = ('https://graph.windows.net/{0}/{1}/{2}?api-version={3}' -f $azureAdPrimaryDomain, 'servicePrincipals', $servicePrincipal.ObjectId, $apiVersion)
$json = @'
{
  "passwordCredentials": [
  {
    "customKeyIdentifier": null,
    "endDate": "<STORAGEACCOUNTENDDATE>",
    "value": "<STORAGEACCOUNTPASSWORD>",
    "startDate": "<STORAGEACCOUNTSTARTDATE>"
  }]
}
'@
$now = [DateTime]::UtcNow
$json = $json -replace "<STORAGEACCOUNTSTARTDATE>", $now.AddDays(-1).ToString("s")
  $json = $json -replace "<STORAGEACCOUNTENDDATE>", $now.AddMonths(12).ToString("s")
$json = $json -replace "<STORAGEACCOUNTPASSWORD>", $password
$Headers = @{'authorization' = "Bearer $($Token)"}
try {
  Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method Patch -Headers $Headers -Body $json 
  Write-Host "Success: Password is set for $storageAccountName"
} catch {
  Write-Host $_.Exception.ToString()
  Write-Host "StatusCode: " $_.Exception.Response.StatusCode.value
  Write-Host "StatusDescription: " $_.Exception.Response.StatusDescription
}

Etape IV : Définir les autorisations API sur l’application nouvellement créée

Comme indiqué dans la documentation Microsoft, la suite du processus peut se faire dans le portail Azure. Ouvrez votre portail Azure Active Directory :

Dans vos Enregistrement d’applications, cliquez sur Toutes les applications, puis enfin sélectionnez l’application dont le nom correspond à votre compte de stockage :

Dans les autorisations API dans le volet de gauche, ajoutez une autorisation comme ceci :

Sélectionnez Microsoft Graph, puis choisissez délégation des permissions :

Dans la section OpenID, sélectionnez Profile :

Descendez plus bas dans la liste pour retrouver la section User. Cochez alors User.Read et cliquez sur Ajouter :

Une fois sur retourné sur l’écran des permissions, cliquez ci-dessous pour ajouter le consentement global à tout votre tenant :

Constatez la bonne application de celui-ci grâce au statut à droite :

Etape V : Création du partage de fichier

Retournez sur votre compte de stockage pour créer un nouveau partage de fichier comme ceci :

Etape VI : Jointure du partage de fichier Azure au domaine Active Directory

Pour l’instant, le partage de fichier Azure nécessite encore l’attribution de droits RBAC aux utilisateurs Azure Virtual desktop. Dans votre cas cette fonctionnalité nécessite d’activer l’authentification AD DS sur le compte de stockage.

Commencez par télécharger sur GitHub la version la plus récente du module PowerShell AzFilesHybrid.zip :

Décompressez les fichiers sur le disque C sur une VM, jointe à votre domaine :

Démarrez Windows PowerShell ISE en tant qu’administrateur et exécutez ce qui suit pour supprimer le flux de données alternatif Zone.Identifier, qui a une valeur de 3, indiquant qu’il a été téléchargé à partir d’Internet :

Get-ChildItem -Path C:\AzFilesHybrid -File -Recurse | Unblock-File

Toujours en PowerShell, connectez-vous à Azure :

Connect-AzAccount

Lancez alors le script suivant en modifiant les paramètres, selon votre configuration :

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid
Join-AzStorageAccountForAuth `
  -ResourceGroupName 'aadjoin-rg' `
  -StorageAccountName 'jloaadjoin2' `
  -DomainAccountType 'ComputerAccount' `
  -OrganizationalUnitDistinguishedName 'OU=AVDJOIN-Devices,DC=jloudev,DC=ml'

Constatez le retour de commande suivant :

Vous pouvez aussi contrôler la bonne activation sur le compte de stockage :

Restez sur votre compte de stockage pour assigner le rôle Storage File Data SMB Share Contributor à votre utilisateurs Azure Virtual Desktop :

*Dans notre démonstration, nous allons seulement autoriser le groupe d’utilisateurs Azure Virtual Desktop.*

Etape VII : Attribution des autorisations

Pour empêcher les utilisateurs d’accéder aux profils utilisateurs d’autres utilisateurs, vous devez également attribuer des autorisations au niveau du répertoire.

Le système que vous utilisez pour configurer les permissions doit répondre aux exigences suivantes :

La poste a une version de Windows répond aux exigences des systèmes d’exploitation des prérequis
Le poste doit être joint à Azure AD ou à Hybrid Azure AD à Azure AD
Le poste est relié au contrôleur de domaine

Installez ou importez si besoin sur le poste le module PowerShell ActiveDirectory. Dans mon cas, je n’ai pas eu à faire cette opération car j’ai tout exécuté depuis mon contrôleur de domaine :

Import-module ActiveDirectory

Azure AD ne prenant pas actuellement en charge la configuration des listes de contrôle d’accès dans Shell, il doit s’appuyer sur Active Directory. Pour configurer Shell sur votre compte de stockage, exécutez la commande suivante dans PowerShell ISE en tant qu’administrateur :

function Set-StorageAccountAadKerberosADProperties {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true, Position=0)]
        [string]$ResourceGroupName,

        [Parameter(Mandatory=$true, Position=1)]
        [string]$StorageAccountName,

        [Parameter(Mandatory=$false, Position=2)]
        [string]$Domain
    )  

    $AzContext = Get-AzContext;
    if ($null -eq $AzContext) {
        Write-Error "No Azure context found.  Please run Connect-AzAccount and then retry." -ErrorAction Stop;
    }

    $AdModule = Get-Module ActiveDirectory;
     if ($null -eq $AdModule) {
        Write-Error "Please install and/or import the ActiveDirectory PowerShell module." -ErrorAction Stop;
    }	

    if ([System.String]::IsNullOrEmpty($Domain)) {
        $domainInformation = Get-ADDomain
        $Domain = $domainInformation.DnsRoot
    } else {
        $domainInformation = Get-ADDomain -Server $Domain
    }

    $domainGuid = $domainInformation.ObjectGUID.ToString()
    $domainName = $domainInformation.DnsRoot
    $domainSid = $domainInformation.DomainSID.Value
    $forestName = $domainInformation.Forest
    $netBiosDomainName = $domainInformation.DnsRoot
    $azureStorageSid = $domainSid + "-123454321";

    Write-Verbose "Setting AD properties on $StorageAccountName in $ResourceGroupName : `
        EnableActiveDirectoryDomainServicesForFile=$true, ActiveDirectoryDomainName=$domainName, `
        ActiveDirectoryNetBiosDomainName=$netBiosDomainName, ActiveDirectoryForestName=$($domainInformation.Forest) `
        ActiveDirectoryDomainGuid=$domainGuid, ActiveDirectoryDomainSid=$domainSid, `
        ActiveDirectoryAzureStorageSid=$azureStorageSid"

    $Subscription =  $AzContext.Subscription.Id;
    $ApiVersion = '2021-04-01'

    $Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' `
        -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

    $json=
        @{
            properties=
                @{azureFilesIdentityBasedAuthentication=
                    @{directoryServiceOptions="AADKERB";
                        activeDirectoryProperties=@{domainName="$($domainName)";
                                                    netBiosDomainName="$($netBiosDomainName)";
                                                    forestName="$($forestName)";
                                                    domainGuid="$($domainGuid)";
                                                    domainSid="$($domainSid)";
                                                    azureStorageSid="$($azureStorageSid)"}
                                                    }
                    }
        };  

    $json = $json | ConvertTo-Json -Depth 99

    $token = $(Get-AzAccessToken).Token
    $headers = @{ Authorization="Bearer $token" }

    try {
        Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json
    } catch {
        Write-Host $_.Exception.ToString()
        Write-Host "Error setting Storage Account AD properties.  StatusCode:" $_.Exception.Response.StatusCode.value__ 
        Write-Host "Error setting Storage Account AD properties.  StatusDescription:" $_.Exception.Response.StatusDescription
        Write-Error -Message "Caught exception setting Storage Account AD properties: $_" -ErrorAction Stop
    }
}

Lancez alors la fonction précédente grâce à cette commande :

Connect-AzAccount
Set-StorageAccountAadKerberosADProperties -ResourceGroupName $resourceGroupName -StorageAccountName $storageAccountName

Cette commande fait alors rebasculer le statut Active Directory sur compte de stockage comme ceci :

Etape VIII : Création de la GPO

Toujours sur votre contrôleur de domaine, ouvrez le gestionnaire des polices :

Sous votre OU des postes AVD, créez une nouvelle police et éditez là :

Activer la police suivante :

Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

Ajoutez également une règle de registre sur cette même police :

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

Redémarrez les VMs Azure Virtual Desktop pour la bonne prise en compte de la GPO :

Connectez-vous à une session Azure Virtual Desktop grâce à Windows Remote Desktop :

Une fois la session AVD ouverte, ouvrez une ligne de commande et tapez le code suivant :

dsregcmd /RefreshPrt

Verrouillez votre session AVD, puis déverrouillez-là :

Saisissez les deux lignes de commande suivantes :

klist purge
klist get krbtgt

Constatez la présence de :

krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM

Lancez enfin la commande net use pour monter le lecteur réseau et vérifiez le bon fonctionnement :

net use Z: \\jloaadjoin2.file.core.windows.net\avdfileshare

*Il arrive par moment que la commande échoue la première fois.*

On retrouve bien le disque réseau dans l’explorateur Windows :

En retournant sur les tickets Kerberos, un nouveau CIFS a fait son apparition :

Etape IX : Configuration de FSLogix

Une fois l’architecture en place, on peut combiner cette dernière pour la gestion des profils utilisateurs via FSLogix. Pour cela, il nous faut rajouter la configuration FSLogix et une règle de registre en plus pour Azure AD.

#Variables
$storageAccountName = "jloaadjoin2"
$filesharename = "avdfileshare"

#Create Directories
$LabFilesDirectory = "C:\LabFiles"

if(!(Test-path -Path "$LabFilesDirectory")){
New-Item -Path $LabFilesDirectory -ItemType Directory |Out-Null
}
if(!(Test-path -Path "$LabFilesDirectory\FSLogix")){
New-Item -Path "$LabFilesDirectory\FSLogix" -ItemType Directory |Out-Null
}

 #Download FSLogix Installation bundle
  if(!(Test-path -Path "$LabFilesDirectory\FSLogix_Apps_Installation.zip")){
       Invoke-WebRequest -Uri "https://experienceazure.blob.core.windows.net/templates/wvd/FSLogix_Apps_Installation.zip" -OutFile     "$LabFilesDirectory\FSLogix_Apps_Installation.zip"

 #Extract the downloaded FSLogix bundle
 function Expand-ZIPFile($file, $destination){
     $shell = new-object -com shell.application
     $zip = $shell.NameSpace($file)
     foreach($item in $zip.items()){
     $shell.Namespace($destination).copyhere($item)
     }
 }

 Expand-ZIPFile -File "$LabFilesDirectory\FSLogix_Apps_Installation.zip" -Destination "$LabFilesDirectory\FSLogix"

}
   #Install FSLogix
   if(!(Get-WmiObject -Class Win32_Product | where vendor -eq "FSLogix, Inc." | select Name, Version)){
       $pathvargs = {C:\LabFiles\FSLogix\x64\Release\FSLogixAppsSetup.exe /quiet /install }
       Invoke-Command -ScriptBlock $pathvargs
   }
   #Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

   #Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
   New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$filesharename" -PropertyType String -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null
    
    reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

   #Display script completion in console
Write-Host "Script Executed successfully"

L’ouverture d’une nouvelle session utilisateurs d’AVD vous affiche bien la mention FSLogix :

Un tour dans le partage de fichier du compte de stockage montre bien la présence du dossier du profil utilisateur géré par FSLogix :

Conclusion

La gestion des tickets Kerberos par Azure AD est une belle avancée. Bien évidemment, le processus de prise en charge complète d’un compte de stockage de manière native n’est pas encore là, mais nous y sommes en bonne voie ???? Comme à chaque fois, n’hésitez pas à utiliser les commentaires pour exprimer de vos retours ????

Faites de l’autoscale sur Azure Virtual Desktop

Microsoft continue d’apporter des fonctionnalités directement intégrées à Azure Virtual Desktop. Après le démarrage machines des virtuelles à la demande ou encore leur intégration directe avec Azure AD sans domaine AD, Microsoft permet encore une fois d’optimiser l’architecture AVD en l’adaptant à la demande.

Cela est toujours bienvenu pour l’optimisation des coûts.

Encore en préversion, vous pouvez déjà tester cette fonctionnalité depuis plusieurs jours en suivant la documentation Microsoft. Dans cet article, je vais mettre en place cette fonctionnalité étape par étape. Nous allons voir ensemble son impact sur un environnement AVD.

La fonction de mise à l’échelle automatique (ou plan d’autoscaling) vous permet de mettre en route des machines virtuelles (VM) Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre.

Cela permet d’optimiser les coûts de déploiement en fonction de vos besoins. Vous pouvez établir un plan d’autoscaling basé sur :

Créneaux horaires
Jours de la semaine
Plafond du nombre de sessions utilisateurs

Etape 0 : Rappel des prérequis

Cette fonctionnalité AVD nécessite de disposer d’un environnement Azure Virtual Desktop déjà en place. Voici donc la liste des composants déjà présents sur mon tenant Azure :

Domaine Active Directory Domain Services (AD DS)
Pool d’hôtes Azure Virtual Desktop
Espace de travail AVD
Groupe d’applications AVD
5 machines virtuelles D4s_v4, déjà jointes à AVD

Point important : Il est nécessaire de définir un nombre maximal de sessions utilisateurs par VM dans la configuration de votre pool d’hôtes :

*L’algorithme du pool d’hôtes n’a pas d’importance car le plan d’autoscaling dispose de sa propre option.*

Etape I : Création d’un nouveau rôle RBAC

Comme l’indique la documentation Microsoft, il est nécessaire de créer un nouveau rôle RBAC pour assurer la gestion automatique des VMs.

Besoin d’en savoir un peu plus sur les rôles Azure ? Voici une vidéo en français qui devrait vous aider :

Merci à Seyfallah pour cette explication très claire ????.

Vous pouvez suivre la création du rôle personnalisé via cette aide Microsoft, ou en répétant les étapes suivantes :Copiez le code JSON suivant et enregistrez le dans un fichier (ex. AVD-custom-role.json) sur votre PC :

{
 "properties": {
 "roleName": "Autoscale",
 "description": "Friendly description.",
 "assignableScopes": [
 "/subscriptions/<SubscriptionID>"
 ],
  "permissions": [
   {
   "actions": [
"Microsoft.Insights/eventtypes/values/read",
"Microsoft.Compute/virtualMachines/deallocate/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",                   "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read"
],
  "notActions": [],
  "dataActions": [],
  "notDataActions": []
  }
 ]
}
}

Positionnez-vous au niveau de votre souscription Azure et cliquez sur le bouton d’Ajout d’un rôle personnalisé :

Selectionnez la fonction JSON et cherchez votre fichier précédement créé, puis cliquez sur Suivant :

Contrôlez la bonne présence des permissions suivantes, puis cliquez sur Suivant :

"Microsoft.Compute/virtualMachines/deallocate/action", 
"Microsoft.Compute/virtualMachines/restart/action", 
"Microsoft.Compute/virtualMachines/powerOff/action", 
"Microsoft.Compute/virtualMachines/start/action", 
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",

Supprimez le permiètre par défaut :

Cliquez ici pour ajouter un nouveau périmètre :

Selectionnez le type Souscription puis choisissez celle voulue, puis cliquez sur Suivant :

Contrôlez cet onglet et cliquez sur Suivant :

Lancez la création de votre rôle personnalisé :

Etape II : Création d’un nouveau rôle RBAC

Une fois le nouveau rôle créé, il ne nous reste qu’à assigner le service Azure Virtual Desktop à celui-ci. Cela s’effectue directement sur le périmètre, qu’on souhaite lui assigner.

Cherchez donc ici la Souscription Azure de votre AVD puis cliquez ici :

Utilisez la barre de recherche pour retrouver plus facilement votre rôle personnalisé :

Cliquez ici pour ajouter le service Azure Virtual Desktop :

Utilisez encore une fois la barre de recherche pour retrouver le service AVD sous son ancien nom et Sélectionnez-le :

Cliquez sur Suivant :

Lancez l’Assignation du rôle :

Vérifiez la présence de l’assignation d’AVD sur la souscription, puis cliquez sur le rôle :

Vous retrouvez ici toutes les permissions nécessaire à la fonctionnalité d’Autoscale :

Microsoft.Compute/virtualMachines/deallocate/action
Microsoft.Compute/virtualMachines/restart/action
Microsoft.Compute/virtualMachines/powerOff/action
Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/read
Microsoft.DesktopVirtualization/hostpools/read
Microsoft.DesktopVirtualization/hostpools/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read

Etape III : Création du plan d’autoscaling

La création d’un plan d’autoscaling AVD apporte les avantages / restrictions suivants :

Le plan d’autoscaling est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
Ne pas associer le plan d’autoscaling avec d’autres solutions tierces de gestion des ressources Azure
Il n’est pas possible d’associer plusieurs plans d’autoscaling sur un seul environnement AVD
Le plan d’autoscaling est dépendant d’un seul fuseau horaire
Le plan d’autoscaling est configurable sur plusieurs périodes distinctes
Le plan d’autoscaling est opérationnel dès sa configuration terminée
Le plan d’autoscaling ne tient pas compte du « Drain mode » activé sur les VMs si aucun TAG n’est pas renseigné
Le plan d’autoscaling n’est pas en interaction avec la méthode de répartition des utilisateurs configuré sur votre pool d’hôtes

La création du plan d’autoscaling se fait directement sur la page d’Azure Virtual Desktop :

Cliquez ici pour démarrer sa création :

Remplissez le premier onglet avec vos informations de base puis cliquez sur Suivant :

*Le champ dédié au TAG exclu permet de « sortir » des VMs du plan d’autoscaling.*

L’onglet suivant vous permet de définir quand le plan d’autoscaling s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.

Dans chaque phase de la planification, autoscale n’éteint les machines virtuelles que lorsqu’un hôte de session n’a plus de sessions actives.

Les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins.

Cliquez comme ceci pour ajouter votre première période :

Choisissez un Nom, sélectionnez les Jours adéquats puis cliquez sur Suivant :

L’onglet de charge reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs et de cliquer sur Suivant :

Heure de début : Sélectionnez une heure dans le menu déroulant pour commencer à préparer les VM pour les heures de charge
Algorithme d’équilibrage de charge : Microsoft recommande de choisir l’algorithme Breadth-first. Cela répartira les utilisateurs sur les VM existantes afin de maintenir des temps d’accès rapides
Pourcentage minimum de VM hôtes : Entrez ici le pourcentage d’hôtes de session que vous souhaitez conserver au minimum pendant les heures de montée et de pointe. Par exemple, si vous choisissez 10 % et que votre pool d’hôtes compte 10 hôtes de session, plan d’autoscaling gardera une hôte de session disponible pour les prochaines connexions utilisateur
Seuil de capacité : Saisissez ici le pourcentage d’utilisation du pool d’hôtes qui déclenchera le début des phases de charge et de pic. Par exemple, si vous choisissez 60 % pour un pool d’hôtes pouvant gérer 10 sessions à l’instant T, le plan d’autoscaling n’activera des hôtes supplémentaires que lorsque le pool d’hôtes dépassera 6 sessions

L’onglet de pic de charge reprend aussi le fuseau horaire du premier onglet et vous demande de renseigner les champs puis de cliquer sur Suivant :

Heure de début : Entrez une heure correspondante au moment où votre taux d’utilisation est le plus élevé pendant la journée. Cette heure sera également l’heure de fin de votre phase de charge
Equilibrage de charge : Sélectionnez Breadth-first ou Depth-first. Le premier distribue les nouvelles sessions utilisateur sur toutes les sessions disponibles dans le pool d’hôtes. Le second distribue les nouvelles sessions à l’ôte de session disponible ayant le plus grand nombre de connexions et n’ayant pas encore atteint sa limite de session.
Seuil de capacité : Valeur non modifiable

L’onglet de décharge vous demande de renseigner les mêmes champs que pour ceux des périodes de charge et de pic :

Heure de début
Equilibrage de charge
Pourcentage minimum d’hôtes (%)
Seuil de capacité (%)
Forcer la déconnexion des utilisateurs

Pour finir, l’onglet heures creuses vous demande de renseigner les mêmes champs suivants :

Heure de début
Equilibrage de charge
Seuil de capacité

Cliquez sur Ajouter une fois ce premier planning terminé :

Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants :

Sélectionnez-le ou les pools d’hôtes concernés et cliquez sur Suivant :

Renseignez les TAGs et lancez la Création :

Consultez la ressource Azure créée et dédiée au plan d’autoscaling d’Azure Virtual Desktop :

Etape IV : Test de la solution

Avant que mon script soit validé et en place, j’ai pris le soin d’éteindre l’ensemble des VMs (5) de mon pool d’hôtes AVD. Voici donc mon environnement de test :

Limite d’utilisateurs AVD par VM : 2 utilisateurs
Nombre de VMs AVD : 5 VMs
Nombre total de sessions AVD disponibles : 20 sessions, soit 4 par VM

Période A : Hors période du plan d’autoscaling
Période B : Charge : Algorithme : Breadth-first / Min : 25 % / Max : 60 %
Période C : Pic : Algorithme : Depth-first / Max : 60 %
Période D : Décharge : Algorithme : Depth-first / Min : 10 % / Max : 90 %
Période E : Creux : Algorithme : Depth-first / Max : 90 %

Période A – Hors période :

Seule une machine virtuelle s’allume après la validation du script car celui-ci est directement opérationnel :

Période B – Période de charge :

Nous entrons dans la période de charge de mon environnement Azure Virtual Desktop. Ayant paramétré le Pourcentage minimum de VM hôtes à 25% et disposant de 5 VMs AVD , une seconde VM s’allume automatiquement allumée à l’entrée dans cette phase :

25% x 5 (max nbr VMs) = 1 VM

Sans attendre la période de pic, je décide alors de connecter un premier utilisateur AVD, sachant que mon Seuil de capacité est de 60% et que le nombre d’utilisateurs AVD par VM est de 4.

De façon assez logique, aucune machine nouvelle virtuelle ne s’allume. Cela fait sens car deux VMs sont déjà opérationnelles. Je décide donc de connecter un second utilisateur. Même constat au niveau de VMs, toujours à cause de la règle des 60 % :

*La répartition des utilisateurs se fait bien selon l’algorithme Breadth-first*.

Je connecte donc un 3ème utilisateur AVD et ne constate toujours aucun allumage d’une nouvelle machine virtuelle. En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :

60% x 4 (max nbr users) x 2 (VMs allumées) = 4.8 sessions utilisateurs

Je décide donc de continuer mon test et de rajouter un quatrième utilisateur. Toujours le même constat :

On finit avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :

Curieusement, la connexion du 6ème utilisateur se ne retrouve pas sur cette nouvelle machine virtuelle sans utilisateur, mais bien sur la seconde, en contradiction avec l’algorithme de la période de charge :

Afin de tester toutes les caractéristiques de la période de charge, je décide de déconnecter l’ensemble des utilisateurs AVD. Aucune VM ne s’éteindra malgré 0 utilisateur connecté sur AVD :

Période C – Période de pic :

Nous quittons la période de charge pour entrer dans la période de pic d’AVD. Le but ici est de constater le changement d’algorithme Depth-first agissant sur la répartition des utilisateurs.

Aucune session utilisateur AVD n’est ouverte, 2 VMs restent allumées, même sans utilisateur :

Je connecte alors 4 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait bien en Depth-first :

On continue avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :

En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :

60% x 4 (max nbr users) x 2 (VM allumée) = 4.8 sessions utilisateurs

Je décide de finir en connectant un 6ème utilisateur. L’algorithme Depth-first continue de bien s’appliquer bien comme précédement :

Au final, la période de pic se distingue de la période de charge par la présence systématique d’une machine virtuelle « d’avance », vide d’utilisateurs pour encaisser leur arrivée massive.

D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à deux machines virtuelles allumées :

Période D : Période de décharge :

Nous continuons l’analyse du plan d’autoscaling avec la période de décharge de mon environnement AVD. Aucune session AVD n’est active à ce moment précis. Comme la période de charge, seule une seule VM reste allumée :

Comme à chaque période, je connecte alors 3 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait toujours en Depth-first :

Quand je connecte le 4ème utilisateur, je constate bien le démarrage d’une seconde machine virtuelle :

En effet la règle des 90 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :

90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs

Dès que je connecte les utilisateurs 5, 6 et 7, aucune nouvelle machine virtuelle ne s’allume :

Dès que j’arrive à l’utilisateur 8, les choses changent :

Cela s’explique encore par la règle des 90% ci-dessous :

90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs

A noter que l’inactivité des utilisateurs AVD provoque le message d’alerte suivant :

*Ce chrono et le message indiqué ici est paramétré dans* le plan d’autoscaling.

D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à une machine virtuelle allumée :

Période E : Période de creux :

Nous sommes maintenant dans la dernière période, appelée aussi période creuse. Le but de celle-ci est de fonctionner en économie maximale. Notre point de départ est donc une seule session AVD d’ouverte et donc une seule machine virtuelle reste active :

On recommence donc par connecter 3 utilisateurs Azure Virtual Desktop. Aucune autre machine virtuelle ne s’allume :

90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs

De ce fait, la connexion du 4ème utilisateur ajoute une seconde machine virtuelle :

On continue par connecter les utilisateurs 5, 6 et 7. Aucun changement au niveau du nombre de VMs :

En effet et comme pour le cas du 4ème utilisateur, la règle des 90% qui s’applique ici n’est réalisée que si le nombre d’utilisateurs connectés dépasse l’entier supérieur :

90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs

La connexion du 8ème utilisateur vérifie et valide cette théorie :

Pour finir la déconnexion de tous les utilisateurs entraîne l’arrêt des machines virtuelles AVD allumées, sauf une :

Fonctionnalités et annexes

Modification

Le plan d’autoscaling est pleinement modifiable après sa création en cliquant ici :

Désactivation

Si votre pool d’hôtes a besoin de repasser en fonctionnement manuel, rien de plus simple par la désactivation temporaire du plan d’autoscaling :

Sauvegarde des logs

Comme un grand nombre de ressources Azure, vous pouvez sauvegarder les logs pour une analyse plus fine :

Dans mon cas, je fais le choix d’utiliser Log Analytics Workspace :

Erreur rencontrées

Au fil de mes différents tests, j’ai reçu une ou deux fois des messages d’erreur lors de la connexion d’un nouvel utilisateur sur une machine virtuelle fraîchement démarrée.

Un nouvel essai de connexion a résolu le souci à chaque fois.

Conclusion

Disons-le tout de suite, cette fonctionnalité était déjà disponible depuis plusieurs mois via une la solution script proposée par Microsoft et basée sur Azure Logic Apps.

La nouvelle solution choisie par Microsoft d’intégrer une fonctionnalité d’autoscaling dans Azure Virtual Desktop est riche de sens et est plus que bienvenue. Pour ma part je trouve qu’elle remplace la fonctionnalité Démarrage des VMs à la demande, déjà existante mais qui ne permettait pas de tenir des plannings de charges et de décharges.

Malgré tout, le plan d’autoscaling manque encore de clarté sur son fonctionnement dans le besoin de démarrage de machines virtuelles. Je me suis en effet retrouvé à plusieurs reprises avec plusieurs VMs allumées malgré qu’elles soient vides d’utilisateurs.

Pour finir, un aperçu graphique du mode et des indices de charges actuels aurait été apprécié.

Nerdio s’occupe de votre AVD

Azure Virtual Desktop est en évolution constante, de part Microsoft (Azure AD, Intune, Teams, FSLogix,…) mais aussi par des solutions tierces comme celle proposée par Nerdio.

C’est ici que Nerdio intervient. Nerdio Manager est une solution disponible sur la marketplace d’Azure, qui va vous simplifier la gestion de votre environnement AVD. Voici une vidéo sur le sujet part le CEO de Nerdio, Vadim Vladimirskiy :

La nombre de vidéos disponibles concernant AVD sur leur chaîne Youtube est impressionnant !

Le portail Azure apporte en effet une grande facilité de déploiement d’un environnement Azure Virtual Desktop. Mais tout cela devient assez lourd quand on doit manager la solution durant toute sa période d’exploitation.

Alors imaginez avec plusieurs centaines d’utilisateurs sur plusieurs pools d’hôtes …

Comme vous allez le voir une fois en place, Nerdio propose de simplifier et d’automatiser les opérations courantes sur l’environnement AVD. On pourra gérer les images OS, les cycles de mise à jour, optimiser les ressources Azure selon les besoins et les pics de charge, et bien d’autres encore…

Dans ce premier article sur Nerdio, nous allons nous occuper ici de l’installation de la solution sur votre environnement Azure.

Etape 0 : Rappel des prérequis

Comme pour tout déploiement dans Azure, des prérequis sont nécessaires :

Un tenant Microsoft (AAD)
Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
Une souscription Azure active
Un domaine Active Directory Domain Services (AD DS)
Un espace de stockage sur Azure pour les profils utilisateurs via FSLogix, provenant d’un serveur de fichiers ou d’un compte de stockage Azure + partage de fichier

Si un des points listés est absent de votre environnement, pas de panique, Vadim vous explique tout ici :

Au final, Nerdio se focalise avant tout sur les composants Azure Virtual Desktop, afin de pouvoir l’intégrer sans difficulté dans un grand nombre d’environnements existants.

Etape I : Déploiement de la solution

Tout commence donc depuis la marketplace. Avant de pouvoir jouer avec Nerdio, il faut en effet commencer à déployer les premières ressources Azure.

Cliquez ci-dessous pour créer votre Nerdio :

Tapez Nerdio dans la barre de recherche et sélectionnez Nerdio Manager for Enterprise :

Créez un nouveau groupe de ressources et choisissez la localisation qui vous convient :

Une fois la validation passée, lancez la création :

Une fois le déploiement terminé, cliquez sur Outputs pour récupérer l’URL de votre application web Nerdio :

En effet, le groupe de ressources créé par Nerdio a généré plusieurs ressources dont une application web :

Ouvrez cette URL dans un nouvel onglet de votre navigateur Internet :

Comme indiqué sur cette page web, vous avez déjà déployé les composants nécessaires à Nerdio. Maintenant, Nerdio va avoir besoin de s’installer.

Pour cela, suivez les indications en ouvrant Azure Cloud Shell avec un compte disposant du rôle d’administrateur global de votre tenant, mais aussi d’un rôle de propriétaire sur la souscription Azure :

Qu’est-ce qu’Azure Cloud Shell ?

Azure Cloud Shell est un interpréteur de commandes interactif, authentifié et accessible par navigateur qui permet de gérer les ressources Azure. Il vous donne la possibilité de choisir l’expérience d’interpréteur de commandes la plus adaptée à votre façon de travailler, qu’il s’agisse de Bash ou de PowerShell.
Source : Microsoft

Lors de l’ouverture de ce nouvel onglet, Azure Cloud Shell vous demandera éventuellement de créer ou de rattacher à un compte de stockage + partage de fichier pour stocker les logs :

Azure Cloud Shell - Storage - Chapter 2 | RidiCurious.com

Azure Cloud Shell va vous permettre d’exécuter des commandes en PowerShell ou en Azure CLI. Restez en PowerShell et coller le script donné sur la page web Nerdio :

*Script correctement terminé après plusieurs minutes.*

Une fois le script terminé, vous pouvez retourner sur la page web Nerdio et rafraîchir. Si vous n’avez pas conservé cette page, pas de panique ! Vous pouvez la retrouver comme ceci :

Retournez sur le groupe de ressources créé par l’application Nerdio, puis cliquez sur le service d’application :

Copiez l’URL de l’application :

Collez l’URL dans un nouvel onglet de votre navigateur :

Pour que Nerdio puisse fonctionner, vous allez devoir le configurer sur votre environnement actuel. Voici, étape par étape, les points à paramétrer :

Les informations du tenant et de la souscription Azure sont déjà renseignés et donc non modifiable :

Ensuite, enregistrez votre application auprès des serveurs Nerdio :

Un environnement Azure Virtual Desktop nécessite aussi un contrôleur de domaine dans la majorité des scénarios. Une gestion via Nerdio n’échappe pas à cette règle et demande alors le réseau virtuel où se trouve l’AD et FSLogix :

Le menu déroulant propose automatiquement les ressources Azure se trouvant dans la même souscription que Nerdio. Cliquez sur OK pour continuer la configuration :

Nerdio vous demande de spécifier un groupe de ressources pour Azure Virtual Desktop. Il propose par défaut le même que celui utilisé pour son installation, mais reste modifiable :

Un conseil, créez un groupe de ressources dissocié pour les ressources AVD afin de gagner en clarté. Retournez alors sur votre premier onglet (Portail Azure) pour créer le groupe de ressources AVD.

Une fois créé, revenez sur la page de configuration.

Cliquez sur le groupe de ressources et changez-le par votre nouveau groupe, puis cliquez sur OK :

Le paramètre suivant concerne Active Directory. Nerdio a besoin de connaître plusieurs paramètres pour connecter les machines virtuelles AVD au domaine :

Directory : Choisissez selon votre annuaire entre Active Directory ou Azure AD DS
AD Domain : Spécifiez le domaine Active Directory au format FQDN pour les machines virtuelles hôtes de session à rejoindre
AD Username : Spécifiez un utilisateur admin au format FQDN avec l’autorisation de créer des objets « ordinateurs«
AD Password : Mot de passe du compte admin
Organisation Unit : Spécifiez l’unité d’organisation (OU) au format DN où toutes les machines virtuelles hôtes de session seront créées par défaut

Une fois les champs renseignés, cliquez sur OK :

Le compte de stockage est utilisé pour stocker les profils via FSLogix. Ce dernier doit exister au préalable, comme pour le partage de fichier, qui doit être joint au domaine AD renseigné plus haut :

Plusieurs options possibles sur cet écran :

Vous pouvez passer la configuration du compte de stockage pour y revenir plus tard si nécessaire
Vous pouvez activer la fonction Cloud Cache de FSLogix. Cela permet de conserver sur le profil utilisateur sur plusieurs compte de stockage Azure, hébergés dans différentes régions pour augmenter sa résiliance.

Cliquez sur OK une fois les champs renseignés :

Le portail de gestion Nerdio offre aussi la possibilité de gérer des machines Windows 365. Cela s’avère pratique pour centraliser la gestion des bureaux à distance dans une seule console.

Pour cela, vous devez autoriser l’application Nerdio sur votre environnement. Cliquez sur OK si vous êtes d’accord :

Enfin, choisissez le modèle de gestion AVD au sein de Nerdio. Prenez ici Spring 2020 Update -ARM (GA) et cliquez sur Done :

Avant de pouvoir laisser Nerdio procéder, il faut lui donner un consentement de l’administrateur global. Cliquez sur le lien donné dans le nom du domaine :

Saisissez les identifiants appropriés pour vous identifier :

La liste d’autorisations est assez longue. Prenez le temps de la regarder et acceptez si vous êtes d’accord :

Un message d’information apparaît alors pour vous confirmer le succès de l’opération :

Fermez l’onglet et retournez sur l’onglet de configuration Nerdio pour cocher la case et cliquez sur OK :

Le processus vous emmène alors directement sur le portail de management Nerdio :

Vous allez maintenant pouvoir créer votre premier environnement Azure Virtual Desktop. Nerdio dispose d’un grand nombre de personnalisations. Nous ne ferons que les opérations de base dans ce premier article. D’autres articles suivront pour des sujets précis.

Etape II : Création d’un environnement Azure Virtual Desktop

Vous voilà sur votre portail de gestion Nerdio. Indispensable dans toute structure AVD, l’espace de travail est un composant créé par Nerdio. Cliquez sur Workspaces, puis Add Workspace :

Renseignez les options de votre espace de travail et cliquez sur OK :

Chaque tâche Nerdio est visible dans l’historique, très précis avec ses statuts actualisés automatiquement :

Faites un tour dans votre portail Azure pour constater la création de la première ressource :

Cliquez votre espace de travail Nerdio pour le configurer :

Cliquez sur Static host pools dans le sous-menu à gauche, puis sur Add static host pool :

Renseignez les champs de votre pool d’hôtes AVD et cliquez sur OK. Voici mes options :

Desktop Experience : vous permet de choisir entre un environnement mono-utilisateur ou multi-utilisateurs
Répertoire : reprend par défaut l’AD DS ou l’Azure AD DS renseigné pendant la configuration Nerdio
FSLogix : reprend par défaut le compte de stockage utilisé pour FSLogix renseigné
Initial host count : nombre initial de machine virtuelles AVD créées avec le pool d’hôtes
Name Préfix : préfixe du nom utilisé pour la création des machines virtuelles AVD
Desktop image : propose une liste d’images Windows 10/11 disponibles sur Azure, mais aussi des images personnalisées et créées dans le menu Desktop image de Nerdio
VM size : offre plusieurs choix de puissance pour les VMs AVD
OS Disk : Taille et puissance du disque OS installé sur chaque VM AVD
Resource group : groupe de ressources Azure pour la création des VMs AVD et du pool d’hôtes
Quick assign : Annuaire des groupes et des utilisateurs d’Azure AD

Une fois la création du pool d’hôtes lancée, vous pouvez suivre toutes les étapes grâce au système de tâches Nerdio :

Après que toutes les tâches sont terminées, ouvrez un portail Azure pour constater les créations dans le groupe de ressources AVD :

Cliquez sur le pool d’hôtes créé par Nerdio et constatez la présence de VMs disponibles aux utilisateurs AVD :

Pour tester la solution, ouvrez un navigateur en mode privé pour vous rendre sur la page d’accueil AVD :

aka.ms/wvdarmweb

Utilisez les identifiants d’un utilisateur faisant parti du groupe AVD assigné lors de la création sur Nerdio et cliquez sur OK :

Recherchez le bon espace de travail créé par Nerdio et cliquez sur l’icône RDP :

Saisissez une nouvelle fois le mot de passe de l’utilisateur AVD et cliquez sur Submit :

Vous voilà enfin sur votre bureau Windows 11 !

Faites un tour sur votre compte de stockage FSLogix via votre portail Azure :

Cliquez sur le partage de fichiers correspond à celui renseigné dans la configuration Nerdio :

Constatez la présence d’un dossier créé par FSLogix pour le stockage du profil utilisateur au format VHDX :

Etape III : Suppression de l’environnement de test AVD

Dans le cadre d’un environnement de test, vous pouvez également supprimer très facilement les composants Azure créés par Nerdio.

Commencez par les machines virtuelles AVD :

Continuez par le pool d’hôtes :

Et finissez par supprimer l’espace de travail :

Conclusion

Au final la mise en place d’un environnement de test pour Azure Virtual Desktop via Nerdio a été très simple et très facile. Plusieurs remarques à ce sujet :

Nerdio ne vous dispense pas de mettre en place les prérequis propres à un environnement AVD
Le présent article ne montre pas toutes les fonctionnalités très utiles et présentes dans la console Nerdio. Plusieurs articles suivront par la suite

Quel est le coût de Nerdio ?

La société propose plusieurs modèles de licence après le premier mois d’essai gratuit :

Nerdio for Managed Service Providers (MSPs)

Nerdio manager for Enterprise :

A cela s’ajoute aussi le coût des ressources Azure déployées par Nerdio, dont voici les estimations au bout de quelques jours :

En conclusion, la solution s’avère assez prometteuse sur la gestion des environnements d’Azure Virtual Desktop par un grand nombre d’automatismes ou de customisations, à travers un seul et unique portail.

Comme à chaque fois Dean Ceola, de la Cloud Academy, a également fait une très bonne vidéo juste ici :

Enfin et comme toujours, pensez à partager votre propre expérience dans les commentaires ????

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/