Étiquette : Azure Virtual Desktop

AVD + SSO + Accès conditionnel v2

Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.

Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :

Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.

You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.

This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.

Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.

  • Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45

If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.

Required action

We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.

  • Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
  • Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.

To get started, review the documentation to secure user sign-in events with Microsoft Entra Multifactor authentication.

Help and support

If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.

If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.

————————————————————-

Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :

Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.

La date limite de transition est prévue pour le 26 juin 2024 :

  • Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
  • Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.

Les actions requises :

  1. Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
  2. Contactez votre administrateur global Azure pour planifier ces mises à jour.
  3. Mettre à jour votre documentation interne et informer votre service d’assistance.

Le support :

En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :

Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.

Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :

Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.

Tâche I – Premier test AVD sans SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de l’utilisateur AVD :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau votre identifiant et mot de passe utilisateur :

Confirmez à nouveau votre choix en cliquant sur Continuer :

Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :

Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :

Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.

Microsoft Learn

L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :

Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.

Microsoft Learn

Voici un rappel des étapes de configuration du SSO pour un environnement AVD :

  1. Activation de l’authentification Microsoft Entra pour le protocole RDP
  2. Création du groupe de machines AVD
  3. Configuration AVD pour activer l’authentification unique

Commençons donc par correctement configurer le SSO au niveau de l’application Entra ID.

Tâche II – Activation de l’authentification Microsoft Entra pour le protocole RDP :

Depuis votre portail Azure, ouvrez le service Azure Cloud Shell :

Importez les 2 modules Graph suivants, puis connectez-vous à ce dernier :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Validez l’authentification de votre compte grâce à un Device Code :

Obtenez l’ID d’objet de chaque principal de service, puis stockez-les dans des variables en exécutant les commandes PowerShell suivantes :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
$MSRDspId = (Get-MgServicePrincipal -Filter "AppId eq 'a4a365df-50f1-4397-bc59-1a1564b8bb9c'").Id
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Vérifiez la valeur actuelle de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Définissez la propriété isRemoteDesktopProtocolEnabled sur true en exécutant les commandes suivantes :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -IsRemoteDesktopProtocolEnabled
}

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Vérifiez le changement de valeur de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

$params = @{
	"@odata.type" = "#microsoft.graph.remoteDesktopSecurityConfiguration"
	isRemoteDesktopProtocolEnabled = $false
}

Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -BodyParameter $params
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -BodyParameter $params

La suite de la configuration SSO se passe au niveau d’un groupe Entra ID.

Tâche III – Création d’un groupe de machines AVD :

Créez un groupe Entra ID dans lequel vous y ajoutez les différentes machines hôtes d’Azure Virtual Desktop :

Copiez les valeurs suivantes de votre groupe de machines virtuelles AVD :

  • Nom du groupe
  • Object ID

Intégrez ces 2 valeurs dans la commande PowerShell suivante :

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

Ajoutez le groupe à l’objet targetDeviceGroup en exécutant les commandes PowerShell suivantes :

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -BodyParameter $tdg
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -TargetDeviceGroupId "<Group object ID>"
Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -TargetDeviceGroupId "<Group object ID>"

La suite se passe au niveau du pool d’hôtes AVD.

Tâche IV – Configuration AVD pour activer l’authentification unique :

Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :

Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :

Tâche V – Second test AVD avec SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :

La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.

Tâche VI – Accès conditionnel actuel AVD (Portail) :

Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :

Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)

Voici l’impact sur l’utilisateur AVD quand cette première police est activée :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce premier utilisateur AVD :

L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Tâche VII – Accès conditionnel actuel AVD (VM) :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce second utilisateur AVD :

Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :

L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.

Tâche VIII – Accès conditionnel AVD doublé (Portail + VM) :

J’ai paramétré un troisième utilisateur pour avoir une MFA renforcée sur les 3 applications AVD, via 2 polices distinctes d’accès conditionnel :

Police Portail

  • Police Portail :
    • Azure Virtual Desktop : 9cdead84-a844-4324-93f2-b2e6bb768d07
  • Police VM :
    • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
    • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Conclusion

Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.

En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘

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

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

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

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

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

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

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

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

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

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

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

Microsoft Learn

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

Choisissez une image OS sous Windows 11 :

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

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

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

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

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

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

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

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

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

Vérifiez les caractéristiques du disque :

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

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

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

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

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

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

Choisissez une machine virtuelle de type D8ds_v3 :

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

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

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

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

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

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

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

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

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

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

Cochez la case, puis cliquez sur Suivant :

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

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

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

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

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

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

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

Lancez la validation Azure :

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

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

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

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

dsregcmd /status

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

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

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

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

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

Choisissez une machine virtuelle de type D8ds_v5 :

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

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

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

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

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

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

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

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

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

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

Cochez la case, puis cliquez sur Suivant :

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

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

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

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

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

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

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

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

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

Lancez la validation Azure :

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

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

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

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

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

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

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

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

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

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

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

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

Sur chacune des 3 sessions AVD :

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

Machine virtuelle AVD avec disque OS Premium SSD :

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

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

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

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

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

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

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

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

Etape V – Synthèse des résultats :

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

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

Conclusion

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

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

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

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

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

Changez l’URL de votre AVD

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

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

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

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

Méthode I – Utilisation d’une Static Web App :

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

George Markou

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

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

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

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

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

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

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

Attendez quelques secondes que le traitement de copie se termine :

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

Créez votre Static Web App en cliquant ici :

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

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

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

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

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

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

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

Modifiez la ligne 31 comme ceci :

Avant :

app_location: "/" # App source code path

Après :

app_location: "/src" # App source code path

Cliquez sur Commit changes :

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

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

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

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

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

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

Confirmez votre création d’enregistrement DNS :

Attendez quelques secondes l’actualisation de vos enregistrements DNS :

Retournez sur le portail Azure afin de cliquer sur Ajouter :

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

Une fois le domaine validé, cliquez sur Fermer :

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

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

Constatez apparition rapide du message de transfert suivant :

Constatez le changement d’URL :

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

Attendez quelques secondes l’établissement de la connexion :

Attendez quelques secondes l’ouverture de la session :

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

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

Méthode II – Utilisation d’Azure Front Door :

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

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

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

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

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

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

Ajoutez la règle de configuration suivante :

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

Choisissez une route, puis cliquez sur Suivant :

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

Attendez environ une minute la fin de l’association :

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

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

  • A
  • AAAA
  • TXT

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

Constatez le changement d’URL :

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

Attendez quelques secondes l’ouverture de la session :

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

Conclusion

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

Azure Virtual Desktop sur Azure Stack HCI

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

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

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

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

Qu’est-ce qu’Azure Arc Jumpstart ?

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

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

Azure Arc Jumpstart

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

Mais qu’est-ce qu’HCIBox ?

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

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

Azure Arc Jumpstart

Combien coûte le service HCIBox ?

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

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

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

az --version

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

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

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

az account set

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

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

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

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

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

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

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

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

Le statut du fournisseur de ressources change durant cette phase :

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

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

az bicep upgrade

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

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

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

Etape II – Déploiement des ressources Azure :

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

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

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

Déplacez le fichier template dans le dossier Bicep :

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

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

cd ./azure_arc/azure_jumpstart_hcibox/bicep/

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

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

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

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

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

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

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

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

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

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

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

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

Note : Une fois terminé, la fenêtre PowerShell du script se fermera automatiquement :

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

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

Configuration de la virtualisation :

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

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

Démarrage des 3 machines virtuelles :

Configurations réseaux et stockages :

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

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

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

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

C:\HCIBox\Logs\

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

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

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

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

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

  • TelemetryAndDiagnostics
  • AzureEdgeLifecycleManager
  • AzureEdgeDeviceManagement

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

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

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

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

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

  • Administrateur Key Vault
  • Contributeur au compte de stockage

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

Cliquez-ici pour continuer :

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

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

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

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

Cliquez sur Editer les paramètres :

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

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

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

Attendez que ce dernier soit terminé :

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

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

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

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

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

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

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

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

Lancez la mise à jour 2402 comme ceci :

Cliquez sur Suivant :

Cliquez sur Suivant :

Lancez l’installation de la mise à jour :

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

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

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

  • les images OS
  • les réseaux logiques

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

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

Azure Arc Jumpstart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cliquez-ici pour ajouter une carte réseau :

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

Cliquez sur Suivant :

Ajoutez au besoin des tags, puis cliquez sur Suivant :

Cliquez sur Créer :

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

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

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

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

Utilisez le compte suivant :

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

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

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

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

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

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

Utilisez le compte de domaine suivant :

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

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

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

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

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

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

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

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

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

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

Attendez environ 1 heure :

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

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

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

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

Copiez le script suivant pour sa mise en place :

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

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

Collez le script sur la VM AVD :

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

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

Rafraichissez la page plusieurs fois si nécessaire :

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

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

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

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

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

Renseignez à nouveau le mot de passe de votre utilisateur :

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

Conclusion

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

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

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

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

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

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

Coûts licences utilisateurs :

Coûts licences infra :

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

FSLogix sont nos amis 🙏!

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

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

La solution FSLogix en quelques mots & vidéos :

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

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

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

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

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

Mais aussi d’autres sources non-Microsoft :

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

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

Etape 0 – Contexte :

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

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

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

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

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

Qu’est-ce qu’Entra Domain Services ?

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

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

Voici une vue de l’environnement Azure Virtual Desktop :

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

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

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

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

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

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

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

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

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

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

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

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

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

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

Je renseigne les identifiants :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Je lance toutes les mises à jour Windows 11 disponibles :

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

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

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

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

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

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

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

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

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

Et la suite se passe de commentaire 🤣.

Etape III – Identification de la cause :

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

Et je tombe sur celui-ci 😎 :

Microsoft propose également une résolution juste ici :

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

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

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

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

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

Sysprep /generalize /oobe /mode:vm /shutdown

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Hibernez votre AVD ⛄❄️

Non cet article n’est pas un doublon du précédent, appelé Faites hiberner vos VMs, et parlant d’une méthode astucieuse pour ne pas entièrement éteindre une VM lorsque l’on souhaite réduire les coûts. Vous l’aurez compris, Microsoft propose également l’hibernation de VM pour son produit VDI phare : Azure Virtual Desktop.

Ça y est, l’Ignite de Microsoft est juste terminé ! Beaucoup de news très intéressantes ont été annoncées concernant Azure. Je vous invite d’ailleurs à lire le Book of news de cette édition 2023.

Concernant l’hibernation d’Azure, voici quelques petits rappels :

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

Si l’envie vous prend d’en savoir un peu plus, je vous invite à lire l’article de la semaine dernière. Enfin, une toute nouvelle vidéo de Dean parle de l’hibernation dans un environnement AVD, le combo ultime :

Inutile de reparler en détail de l’hibernation, comme toujours je vous propose de réaliser un petit exercice, combinant AVD et l’hibernation.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice d’hibernation sur des VMs Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

La suite consiste maintenant à créer un environnement AVD et avec l’hibernation activée.

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

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

Nommez celui-ci, puis cliquez sur Vérifier:

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

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

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

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

Confirmez la sécurité de la VM comme ceci :

Choisissez dans la liste des images Microsoft l’image Windows 11 version 22H2, sélectionnez une VM de Séries Dsv5, puis cochez la case Hibernation :

Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :

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

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

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

Ajoutez-y les 3 rôles RBAC suivants à un utilisateurs de test AVD et à l’application Azure Virtual Desktop :

Nous devons rajouter un rôle Azure RBAC pour permettre à Azure Virtual Desktop (ou anciennement Windows Virtual Desktop) de pouvoir allumer et éteindre les VMs AVD :

De retour sur votre pool d’hôte AVD, activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Ajoutez le scaling plan qui pilotera la VM individuelle selon les besoins de connexion, puis cliquez sur Créer :

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

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

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

  • Heure de début : heure correspondant au début de la phase.
  • Démarrage de la VM : permet à l’utilisateur de pouvoir démarrer une VM éteinte pendant la phase. Cette option prend le pas sur la configuration renseignée dans le pool d’hôtes.
  • VMs à démarrer : propose de démarrer automatiquement des VMs si nécessaire dès le début de la phase, ou pas.
  • Paramètres de déconnexion : permet d’effectuer l’hibernation ou non.
  • Paramètres de fermeture de session : permet d’effectuer l’hibernation ou non

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

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

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

Cliquez sur Suivant pour continuer :

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

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

Attendez 1 minute que la configuration soit déployée :

Notre environnement AVD combiné à l’hibernation est enfin prêt, il ne nous reste plus qu’à utiliser un utilisateur pour tester les différentes phases de ce nouvel état.

Etape III – Test de l’hibernation :

Dans mon environnement de démonstration AVD, la machine virtuelle individuelle est déjà démarrée.

Depuis votre poste, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :

Lancez l’application de bureau à distance, puis authentifiez-vous encore une fois avec un compte AVD de test :

Validez la délégation en cliquant sur Oui :

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

Fermez la session AVD en utilisant la croix du bureau à distance :

Confirmez le choix de déconnexion en cliquant sur OK :

A ce moment précis, la machine virtuelle AVD est toujours en statut Disponible :

Environ 10 minutes plus tard, son statut commence à changer :

Environ 1 minute plus tard, son statut AVD bien changé :

De retour dans la listes des machines virtuelles Azure, le statut d’hibernation est bien confirmé :

Afin de confirmer le bon retour des programmes ouvert, recliquez à nouveau sur l’application de bureau à distance, puis attendez le démarrage effectif de la VM AVD :

Environ 2 minutes plus tard, la session Windows se réouvre alors avec les programmes précédemment ouverts et non sauvegardés :

Conclusion :

La fonction d’hibernation annoncée il y seulement quelques jours est un atout non négligeable dans la gestion offline de machine virtuelle. Aucun doute que ce statut est plus pratique que l’arrêt complet dans un environnement Azure Virtual Desktop. Les utilisateurs de machines AVD individuelles seront sans aucun doute ravi ne pas devoir fermer et ouvrir toutes leurs applications tous les jours 😎

Azure Virtual Desktop + GPU = 🏎️

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

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

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

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

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

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

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

Microsoft Learn

Quels sont les GPUs disponibles sur Azure ?

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

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

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

Produits disponibles par région.

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

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant :

Cliquez sur Accepter :

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

Etape III – Post-configuration GPU 1/2 :

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

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

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

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

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

Microsoft Learn

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

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

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

Lancez la validation Azure :

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

Attendez environ 1 minute :

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

Constatez le bon provisionnement de votre extension GPU NVIDIA :

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

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

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

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

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

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

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

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

Confirmez le dossier de décompression au niveau local :

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

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

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

Cliquez sur Suivant :

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

Attendez environ 2 minutes que l’installation se termine :

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

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

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

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

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

Etape IV – Installation d’applications de test :

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

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

Installation d’AutoCAD :

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

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

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

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

L’installation d’AutoCAD s’ouvre alors :

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

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

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

Installation de FurMark :

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

Cliquez-ici pour lancer l’installation de FurMark :

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

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

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

Pour cela, lancez la commande Sysprep :

Ouvrez le programme Sysprep :

Configurez-le comme ceci, puis cliquez sur OK :

Attendez que Sysprep commence le travail de nettoyage :

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

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

Confirmez votre action en cliquant sur Oui :

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

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

Configurez les options de capture comme ceci :

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

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

Attendez environ 10 minutes que le traitement se termine :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Etape VII – Post-configuration GPU 2/2 :

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

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

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

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

Continuez comme ceci :

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

Cliquez sur Ajouter un paramètre :

Rechercher les 2 paramètres GPU suivants :

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

Activez ces 3 paramètres comme ceci :

Cliquez sur Suivant :

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

Terminez la création de votre police de configuration.

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

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

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

Etape VIII – Vérification de la configuration GPU :

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

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

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

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

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

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

Recherchez le journal suivant :

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

Constatez la bonne présence des 2 ID suivants :

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

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

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

  • AutoCAD
  • FurMark
  • Clipchamp

Etape IX – Test AutoCAD :

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

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

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

Continuons les tests avec FurMark.

Etape X – Test FurMark :

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

Finissons les tests applicatifs avec Clipchamp.

Etape XI – Test Clipchamp :

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

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

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

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

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

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

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

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

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

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

Conclusion :

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

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

OneDrive & RemoteApp AVD

Azure Virtual Desktop intègre OneDrive depuis déjà quelques années, que ce soit via le bureau à distance ou les applications sous RemoteApp. Mais Microsoft améliore l’expérience utilisateur dans le cadre des applications lancées RemoteApp (publication d’applications sans bureau Windows).

En effet, il est possible de monter la ressource OneDrive liée au compte AVD automatiquement sur le poste local ! Concrètement, l’utilisateur ouvre son application RemoteApp et aura accès à OneDrive depuis son application ou son poste local.

Vous pouvez utiliser Microsoft OneDrive avec une RemoteApp dans Azure Virtual Desktop (preview), ce qui permet aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp. Lorsqu’un utilisateur se connecte à une RemoteApp, OneDrive peut être lancé automatiquement en tant que compagnon de la RemoteApp.

Microsoft Learn

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

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

Pour mes tests, je n’ai eu besoin d’installer FSLogix, mais nul doute que la dernière version de celui-ci doit être installée pour que la gestion des profils en itinérance se fasse correctement avec le nouveau comportement de OneDrive.

Afin d’en savoir un peu plus, je vous propose de réaliser un petit exercice ensemble :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur OneDrive au travers Azure Virtual Desktop en mode RemoteApp, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

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

Avant tout chose, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

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

Une fois le déploiement terminé, cliquez-ici pour y déployer le service Azure Bastion :

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

Sans attendre la fin du déploiement d’Azure Bastion, créez une machine virtuelle en Windows 11 sur le même réseau virtuel, sans y configurer d’options particulières :

Cette VM de test va nous servir à simuler notre poste local où nous lancerons l’application AVD en RemoteApp.

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

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

Activez l’option Validation de l’environnement AVD, puis cliquez sur Suivant :

Choisissez dans la liste des images Microsoft l’image Windows 11, version 22H2 :

Indiquez le nombre de VMs AVD, puis réutilisez le réseau virtuel Azure créé précédemment :

Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :

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

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

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

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

Créez un nouveau groupe d’applications AVD pour effectuer le test de l’application ouverte en RemoteApp :

Renseignez les informations de base, puis cliquez sur Suivant :

Ajoutez une application accessible depuis le menu Démarrer de votre VM AVD, puis cliquez sur Suivant :

Inutile de renseigner des utilisateurs à notre groupe d’applications, cliquez sur Suivant :

Associez votre nouveau groupe d’applications à votre espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du groupe d’applications AVD, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez sur le groupe de ressources commun à tous les déploiements antérieurs :

Ajoutez-y les 2 rôles RBAC suivants à un ou plusieurs utilisateurs de test AVD :

Retournez sur la machine virtuelle de test simulant le poste local, puis ouvrez une session de bureau à distance via Azure Bastion, en utilisant les identifiants administrateurs renseignés lors de la création de celle-ci :

Depuis cette VM, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :

Lancez l’application configurée en RemoteApp :

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

Constatez l‘absence de configuration OneDrive dans l’application RemoteApp, mais aussi au niveau de la VM de test simulant le poste local :

Fermez l’application en RemoteApp.

Nous environnement de départ est en place. Nous allons pouvoir effectuer la configuration cible en commençant par l’installation de OneDrive.

Etape II – Configuration de OneDrive :

Depuis votre portail Azure, ouvrez une seconde session Bastion sur la VM AVD, en utilisant les identifiants administrateurs renseignés lors de la création celle-ci :

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

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

.\OneDriveSetup.exe /allusers

Attendez que l’installation de OneDrive se termine :

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

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OneDrive

Retournez sur le portail Azure afin de récupérer le Tenant ID de votre tenant :

Retournez sur la fenêtre PowerShell de votre VM AVD, puis lancez le script suivant en prenant le soin de renseigner votre Tenant ID dans la variable $TenantGUID :

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

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

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

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

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

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

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

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

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

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

La commande effectuée va permettre de laisser fonctionner OneDrive en tâche de fond lorsque l’application en RemoteApp est démarrée :

La configuration de OneDrive sur notre machine virtuelle AVD est terminée.

Pour que tout fonctionne correctement, la version de Windows de la VM AVD doit être supérieure ou égale à la 25905.

Pour cela, nous avons besoin de rejoindre programme Windows Insider de Windows 11.

Etape III – Installation du Programme Windows Insider :

Sur la session administrateur de votre VM AVD, retournez dans les paramétrages Windows :

Cliquez-ici pour rejoindre le programme Windows Insider :

Avant de pouvoir rejoindre le programme Windows Insider, cliquez sur l’alerte afin d’activer la remontée de données de diagnostic :

Activez l’option, puis retournez sur la page principale des paramètres Windows :

Cliquez sur Commencer afin d’activer le programme Windows Insider :

Utilisez le compte de votre utilisateur AVD pour rejoindre le programme :

Renseignez ses identifiants :

Choisissez le canal Canary, puis cliquez sur Continuer :

Considérez si besoin les particularités du canal Canary, puis cliquez sur Continuer :

Cliquez sur Continuer pour accepter les conditions du programme liées à votre poste :

Redémarrez la VM de test AVD :

Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour, dont celles-ci :

Une fois l’installation terminée, lancez une redémarrage de la VM AVD :

Quelques minutes plus tard, vérifiez via la session ouverte sur Azure Bastion que votre VM AVD est dans la bonne version de Windows 11 :

Notre environnement est enfin prêt et fonctionnel pour tester OneDrive en version RemoteApp.

Il ne nous reste plus qu’à effectuer des tests RemoteApp grâce à notre utilisateur AVD.

Etape IV – Test de OneDrive en RemoteApp :

Retournez sur la session ouverte sur la VM de test local ouverte via Azure Bastion, puis réouvrez l’application configurée en RemoteApp :

Constatez la présence du compte OneDrive depuis l’application WordPad :

Constatez l’apparition d’un second OneDrive ouvert localement, avec la mention Remote, puis cliquez-dessus :

Constatez l’ouverture de la fenêtre OneDrive comme une seconde application RemoteApp ouverte depuis le poste local :

Fermez l’application WordPad :

Quelques secondes plus tard, l’application OneDrive ouverte automatiquement en RemoteApp se ferme également :

Conclusion

Grâce à cette évolution, OneDrive fonctionne parfaitement avec RemoteApp créée dans un environnement Azure Virtual Desktop. Cela permet à vos aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp de 2 manières, localement ou au travers de l’application RemoteApp.

AVD Solo : Start and Stop !

Azure Virtual Desktop est souvent associé aux environnements mutualisés. Mais on oublie souvent qu’AVD propose également à des environnements individuels, comme peut aussi le faire Windows 365. Comme toujours, les produits estampillés Azure apportent de la flexibilité dans la configuration et des optimisations possibles. Par exemple, des machines virtuelles équipées de puissantes cartes graphiques.

Aujourd’hui, Azure Virtual Desktop continue d’évoluer et propose maintenant l’arrêt automatique des VMs pour les environnements individuels.

En effet, il est déjà possible depuis un certains de temps faire automatiquement démarrer la machine virtuelle AVD d’utilisateur quand celui-ci s’y connecte. Cela s’appelle le Start on connect et j’en avait déjà parlé juste ici. Bien pratique et facile à configurer, cette fonction avait pour défaut de ne jamais arrêter la VM quand l’utilisateur n’en avait plus besoin.

Rappelons-le : une machine virtuelle éteinte au niveau OS continue de coûter de l’argent car des ressources Azure lui sont toujours allouées.

Des parades existent déjà depuis quelques temps déjà, mais elles nécessitent bien souvent une configuration annexe :

J’avais d’ailleurs écrit un article sur ce sujet. Mais depuis, les choses se compliquent car certaines fonctionnalités des comptes Azure Automation vont bientôt être dépréciées…

Bref, je suis bien content que Microsoft ait rajouté cette fonctionnalité d’arrêt automatique des VMs dans Azure Virtual Desktop.

Qu’est-ce que la mise à l’échelle automatique ?

La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.

Microsoft Learn

La mise à l’échelle automatique, ou autoscaling, est déjà disponible pour les environnements AVD mutualisés. Un autre article en parle juste ici.

Comme indiqué dans le titre, la grande nouveauté concerne les environnements AVD individuels. La documentation Microsoft en parle déjà : la mise à l’échelle automatique pour les pools d’hôtes individuels est actuellement en préversion.

Voici donc un petit exercice pour tester cette fonctionnalité :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

Pour déployer un environnement AVD, commencez par déployer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Renseignez tous les champs, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre réseau virtuel :

Attendez environ une minute que le déploiement se termine :

Utilisez encore une fois la barre de recherche Azure pour créer votre environnement AVD :

Cliquez-ici pour créer un nouvel environnement AVD :

Renseignez tous les champs en prenant soin de choisir un type d’environnement individuel :

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

Renseignez les champs liés aux machines virtuelles AVD de votre environnement :

Choisissez la taille et le nombre de VMs AVD, ainsi que le réseau virtuel créé précédemment :

Dans notre environnement, une jointure des VMs à Azure Active Directory suffira. N’oubliez pas de joindre également vos VMs à Intune pour terminer cet exercice, puis cliquez sur Suivant :

Renseignez les champs pour créer un espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour terminer la configuration de votre AVD :

Cochez l’option pour activer le SSO sur Azure Virtual Desktop. Cela évite de devoir s’authentifier deux fois pour arriver sur le bureau de la VM AVD :

Afin de pouvoir tester notre environnement AVD, il est nécessaire de rajouter des rôles à nos utilisateurs de test :

  • Desktop Virtualization User
  • Virtual Machine User Login

Enfin, mon environnement AVD de test nécessite d’assigner des utilisateurs aux VMs AVD. Pour cela, rendez-vous sur cet écran pour les assigner manuellement :

Comme je dispose de 2 VMs dans mon environnement AVD, j’ai assigné à chacune d’entre-elles un utilisateur de test :

Vérifiez que les machines virtuelles sont bien présentes et disponibles :

Ouvrez le client Remote Desktop, ou installez-le depuis ce lien si cela n’est pas encore le cas :

Utilisez la fonction suivante pour faire apparaître les machines AVD :

Vous pouvez répéter cette opération avec votre second utilisateur de test :

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

Authentifiez-vous une seconde fois pour activer la fonction SSO :

Autorisez-les connections de bureau à distance à partir de l’identité Azure AD de votre utilisateur de test :

Attendez que le bureau à distance Windows 11 s’ouvre :

Une fois la session AVD ouverte, fermez cette dernière en utilisant la déconnexion habituelle de Windows :

Votre environnement AVD est prêt et fonctionnel. Notre objectif est maintenant d’ajouter la fonction d’allumage et d’extinction automatique des VMs.

Etape II – Configuration de l’allumage et de l’extinction automatique :

Pour cela, nous devons rajouter un nouveau rôle Azure RBAC pour permettre à Azure Virtual Desktop (ou anciennement Windows Virtual Desktop) de pouvoir allumer et éteindre les VMs AVD :

Ajoutez le rôle RBAC suivant au niveau du groupe de ressources Azure contenant votre environnement AVD :

Retournez dans le menu Azure Virtual Desktop afin d’ajouter le scaling plan qui pilotera les VMs individuelles selon les besoins de connexion, puis cliquez sur Créer :

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

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

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

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

  • Heure de début : heure correspondant au début de la phase.
  • Démarrage de la VM : permet à l’utilisateur de pouvoir démarrer une VM éteinte pendant la phase. Cette option prend le pas sur la configuration renseignée dans le pool d’hôtes.
  • VMs à démarrer : propose de démarrer automatiquement des VMs si nécessaire dès le début de la phase, ou pas.
  • Paramètres de déconnexion : permet d’effectuer ou non une action après un temps donné.
  • Paramètres de fermeture de session : permet d’effectuer ou non une action après un temps donné.

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

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

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

Cliquez sur Suivant pour continuer :

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

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

Attendez quelques minutes que la configuration soit déployée :

Votre environnement individuel AVD est enfin géré par un planning de démarrage et d’arrêt automatique.

Nous allons maintenant effectuer différents tests pour voir le comportement d’Azure Virtual Desktop d’un point de vue utilisateur.

Etape III – Test de l’allumage et de l’extinction automatique :

Dans mon environnement de démonstration AVD, les machines virtuelles individuelles sont bien arrêtées.

Test A – Fermeture de la session utilisateur en Phase 1 :

A 9h22, j’ouvre un navigateur web afin de me rendre sur la page de connexion AVD. Une fois authentifié avec un utilisateur de test, j’ouvre une session de bureau à distance :

Comme la machine virtuelle affectée à cet utilisateur est arrêtée, Azure Virtual Desktop la démarre et ce message s’affiche :

Le statut de la machine virtuelle change bien dans Azure :

Une fois la machine démarrée, le message d’attente change également :

Peu après, le bureau virtuel Windows apparaît bien. Je décide donc d’effectuer une fermeture de session Windows par le menu Démarrer :

Environ 15 minutes plus tard, la machine virtuelle retrouve bien son précédent état :

Le premier test est concluant. Effectuons maintenant un second test en ne fermant pas la session AVD, mais en utilisant la croix pour simuler une déconnexion :

Test B – Déconnexion utilisateur en Phase 2 :

J’ouvre à nouveau une session de bureau à distance :

Comme la machine virtuelle affectée s’était précédemment arrêtée, Azure Virtual Desktop est obligé de la redémarrer à nouveau :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Peu après, le bureau virtuel Windows apparaît bien. Je décide donc déconnexion de la session par la croix, en haut de la fenêtre AVD :

La session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :

A 10h56, la VM est déjà éteinte depuis quelques temps :

Cette information est confirmée par le journal d’audit de la machine virtuelle :

Les fonctions de déconnexion de l’utilisateur et de fermeture de session sont bien prises en compte dans le processus d’arrêt des machines virtuelles par Azure Virtual Desktop.

Prenons maintenant le temps de vérifier le respect des paramétrages renseignés dans la configuration.

Test C – Fermeture de la session utilisateur en Phase 3 :

A 11h01, j’ouvre à nouvelle fois une session Windows :

Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :

A 11h25, soit exactement 20 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre :

Cela confirme bien le paramétrage de temps renseigné dans cette phase :

Je décide de continuer mon test en vérifiant mon raisonnement en phase 4, dans laquelle j’ai configuré un arrêt de la VM seulement 5 minutes après la fermeture ou déconnexion de la session.

Test D – Fermeture de la session utilisateur en Phase 4 :

A 12h01, j’ouvre à nouvelle fois une session Windows :

Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :

A 12h08, soit exactement 5 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre à nouveau :

Cela confirme bien le respect du paramétrage selon la phase dans laquelle l’utilisateur se trouve :

Le paramétrage de démarrage et d’arrêt des machines virtuelles individuelles AVD fonctionne bien.

Afin d’aller plus loin dans le test, je décide d’y intégrer une session de déconnexion des sessions inactives, passé un certain temps.

Pour cela, je vais utiliser Intune pour déployer une police de configuration Windows sur les sessions de bureau à distances inactives.

Etape IV – Configuration log off Windows via Intune :

Afin de déployer une configuration Intune, démarrez les machines virtuelles AVD via la fonction suivante :

Sur la page d’Azure AD, créez un nouveau groupe et ajoutez-y les machines virtuelles AVD :

Rendez-vous dans la console Intune afin de créer un nouveau profil de configuration Windows comme ceci :

Choisissez le type de profil suivant, puis cliquez sur Créer :

Nommez votre profil de configuration, puis cliquez sur Suivant :

A droite, recherchez l’option suivante afin de l’ajouter et de la configurer sur la partie gauche de l’écran, puis cliquez sur Suivant :

Les Tags ne sont pas utilisés dans notre test, cliquez sur Suivant :

Ajoutez le groupe précédemment créé et contenant les machines virtuelles AVD, puis cliquez sur Suivant :

Vérifiez une dernière fois les options de votre profil de configuration, puis cliquez sur Créer :

Attendez environ 15-30 minutes que le profil de configuration soit bien déployée sur vos VMs AVD :

Ma configuration Intune et maintenant en place. Maintenant, nous allons pouvoir tester la combinaison des deux configurations.

Test E – Combinaison AVD + Intune :

Rouvrez une nouvelle fois une session AVD :

Comme la machine virtuelle AVD est déjà démarrée, la session s’ouvre bien plus rapidement :

Environ 15 minutes plus tard et sans avoir rien fait, un premier message d’avertissement apparaît sur la session AVD m’indiquant que la session sera déconnecté dans environ 2 minutes :

Environ 2 minutes plus tard et n’ayant toujours rien touché, le message suivant apparaît :

Là encore, la session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :

Environ 5 minutes après la déconnexion de la session, la machine virtuelle AVD change encore de statut pour s’éteindre une nouvelle fois :

Cette dernière démonstration montre bien la combinaison habille entre la nouvelle fonctionnalité AVD et la configuration Windows installée via une police de configuration Intune.

Conclusion :

Comme toujours, les nouveautés sur Azure Virtual Desktop font plaisir. Elles sont pratiques et vous ferons gagner du temps dans la configuration et dans la mise en place.

Voici d’ailleurs quelques une des dernières nouveautés AVD que j’ai pu tester récemment :

Bonne lecture 😎

Bodybuildez votre AVD !

Azure Virtual Desktop n’en finit plus d’évoluer ! Aujourd’hui est une grande journée pour l’automatisation des environnements AVD. Jusqu’à présent, Azure proposait peu de solutions adéquates pour AVD pour faciliter le processus de gestion des images des VMs. Pour enfoncer le clou(d), d’autres solutions tierces faisaient déjà mieux et rendaient le travail IT beaucoup plus léger.

Microsoft vient donc de sortir une nouvelle fonctionnalité à son produit AVD, encore en préversion à ce jour, mais attendue depuis fort longtemps : Custom image templates, ou Modèles d’images personnalisés pour les francophones.

Aucun doute que les administrateurs d’AVD vont aimer !

Pourquoi doit-on gérer des images avec Azure Virtual Desktop ?

La gestion des applications et des mises à jour d’un environnement AVD reste très proche d’un environnement RDS traditionnel. De temps à autre, il vous faut penser à :

  • Les applications doivent être mises à jour
  • Les mises à jour correctives ou sécuritaires doivent être appliquées
  • Les besoins logiciels des utilisateurs évoluent
  • De nouvelles optimisations sont disponibles

Toutes ces raisons et encore d’autres font que les machines virtuelles d’un environnement Azure Virtual Desktop doivent être mises à jour régulièrement, et si possible, avec un mode opératoire le plus automatisé.

Que proposait Azure Virtual Desktop avant cette fonctionnalité ?

En cherchant un peu, on retrouvait déjà plusieurs méthodes qui avaient déjà fait leurs preuves :

  • Gestion 100% manuelle via Golden Image / Sysprep / Snapshot :
  • Gestion 50% manuelle via l’utilisation d’un Template d’Azure Image Builder :
  • Solutions tierces, comme par exemple la très connue Nerdio :

Sur quoi repose la fonction Custom image templates d’AVD ?

Disons-le tout de suite, Custom image templates fonctionne toujours avec Azure Image Builder.

Mais tout est maintenant intégré dans la console Azure Virtual Desktop. Et le meilleur dans tout ça :

l’intégration d’optimisations est gérée dans le template, qu’elles soient préconstruites par Microsoft ou créées par vos soins !

C’est tout le processus de préparation qui peut alors s’intégrer dans la seule étape de création du template. Fini les aller et retours !

Bref, ne perdons pas de temps, et testons ensemble cette fonctionnalité.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les templates d’Azure Virtual Desktop, encore en préversion, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de ne pas rendre cet article trop long, j’ai déjà préparé un environnement Azure. Je vous liste dans l’étape suivante tous les composants déjà mis en place sur mon environnement avant de démarrer le test.

Etape I – Préparation de votre environnement Azure Virtual Desktop :

J’ai créé un premier groupe de ressources Azure, dans lequel j’ai déployé 2 VMs :

  • Une première machine virtuelle Windows Server avec des rôles AD DS / DNS
  • Une seconde machine virtuelle Windows Server avec Azure AD Connect

J’ai également déployé dans un second groupe de ressources pour :

  • Un réseau virtuel pour l’ensemble de mon infrastructure AD DS / AVD :
  • Un service Azure Bastion pour me connecter aux différentes machines de mon domaine

Dans ce réseau virtuel Azure, nous retrouvons les sous-réseaux suivants :

  • Sous-réseau pour la partie domaine / Azure AD Connect
  • Sous-réseau pour les machines virtuelles AVD
  • Sous-réseau dédié au service Azure Bastion

Je n’ai pas oublié non plus de renseigner l’adresse IP locale de mon AD en tant que DNS de premier niveau sur mon réseau virtuel :

J’ai également déployé une Azure Compute Gallery, dans laquelle se trouvent une définition de base d’une image pour mon environnement AVD :

Grâce à la mise en place du domaine Active Directory et d’Azure AD Connect, j’ai pu synchroniser deux utilisateurs AD vers Azure AD :

J’ai également créé un compte de stockage Azure. Grâce à la tâche 6 de cet article, j’ai configuré ce compte de stockage pour être joint à mon Active Directory.

J’ai également créé un partage de fichier pour la gestion des profiles en itinérance via FSLogix :

Je n’ai pas oublié de rajouter les rôles Azure RBAC spécifiques au partage SMB FSLogix :

J’ai également transposé ces droits Azure RBAC en droits NTFS sur ce même partage FSLogix :

J’ai enfin vérifié, au niveau de ma souscription Azure, le bon enregistrement des fournisseurs de ressources suivants :

  • Microsoft.VirtualMachineImages
  • Microsoft.KeyVault

Si cela n’est pas fait, voici la procédure qui vous prendra à peine deux minutes :

Votre environnement de départ est enfin prêt pour commencer la mise en place de Modèles d’images personnalisés pour AVD.

L’étape suivante est donc consacré à la mise en place d’une identité managée pour Azure VM Image Builder.

Etape II – Azure VM Image Builder :

VM Image Builder est un service Azure complètement managé qui est accessible aux fournisseurs de ressources Azure. Les fournisseurs de ressources le configurent en spécifiant une image source, une personnalisation à effectuer et l’emplacement où la nouvelle image doit être distribuée.

Microsoft Learn

Pour que Azure VM Image Builder gère des images AVD, il est nécessaire de lui créer une identité managée Azure. Celle-ci disposera des autorisations nécessaires pour lire et écrire des images :

Microsoft.Compute/images/write
Microsoft.Compute/images/read
Microsoft.Compute/images/delete
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Compute/galleries/images/versions/write

Au niveau de votre souscription Azure, rendez-vous dans le menu suivant pour commencer la création d’un rôle personnalisé :

Donnez-lui un nom, puis cliquez sur Suivant :

Parcourez la liste des permissions disponibles afin d’ajouter celles ci-dessous :

Dean met aussi à disposition sur son GitHub un template JSON contenant ces permissions.

Définissez le périmètre de la souscription Azure pour ce nouveau rôle :

Lancez la création en cliquant sur Créer :

Sur votre portail, recherchez dans la barre du haut le services des Identités Managées :

Cliquez-ici pour créer votre Identité Managée dédiée à Azure VM Image Builder :

Nommez celle-ci, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Retournez au niveau de la souscription Azure pour assigner le rôle personnalisé à votre nouvelle identité managée :

Recherchez le rôle personnalisé en utilisant le filtre :

Cliquez ici pour rechercher dans Azure AD votre nouvelle identité managée :

Lancez la validation de votre affectation :

Une fois la validation passée, cliquez sur Assigner :

Toutes les étapes préparatoires à la création d’un modèle d’image personnalisé sont maintenant terminées. Nous allons pouvoir maintenant commencer la création de notre template AVD.

Comme le rappelle Dean durant sa vidéo, d’autres options seront prochainement rajoutées par la suite.

Etape III – Création d’un modèle d’image personnalisé :

Recherchez le service Azure Virtual Desktop en utilisant la barre du haut :

Dans le menu Modèle d’image personnalisés, cliquez-ici pour ajouter votre premier template :

Nommez votre template, choisissez sa localisation, reprenez l’identité managée créée et affectée précédemment, puis cliquez sur Suivant :

Comme il s’agit de votre premier template, cliquez sur Non à la question d’importation :

Sélectionnez votre image source, en utilisant par exemple la Marketplace Microsoft :

Attention à la génération rattachée à votre Image.
Celle-ci devra également utiliser des tailles de VM compatibles.

Concernant le stockage de votre template AVD, deux destinations sont possibles avec Azure VM Image Builder :

  • Image managée : utilisable pour AVD ou Windows 365
  • Azure Compute Gallery : utilisable pour AVD

Cochez la cible Azure Compute Gallery, renseignez les informations nécessaires, puis cliquez sur Suivant :

L’option Latest sera un choix intéressant pour positionner l’image en dernière version à déployer.

Azure VM Image Builder a besoin de quelques informations durant le processus de fabrication :

  • Timeout : à définir si besoin. Si vide, alors 240 minutes
  • Taille de la VM : taille sans rapport direct avec les futures VMs AVD
  • Taille du disque OS : taille avec rapport direct sur celui des futures VMs AVD
  • Groupe de ressources temporaire : Si laissé vide, le groupe sera créé par Azure
  • Réseau Virtuel : champs facultatifs

Puis cliquez sur Suivant :

Azure VM Image Builder vous propose d’exécuter à votre place des traitements post-déploiement. Vous pouvez lancer vos propres scripts, ou piochez dans la longue liste mise à disposition par Microsoft.

Cliquez-ici pour ajouter votre propre script, si besoin :

Cliquez-ici pour consulter la liste des scripts dédiés à AVD et construits par Microsoft :

Choix dans la liste les options voulues, puis sauvegardez :

Vérifier une dernière fois les options choisies, puis cliquez sur Suivant :

Ajoutez les étiquettes pour une meilleure classification de vos ressources Azure, puis cliquez sur Suivant :

Lancez la création de votre template en cliquant sur Créer :

Environ quelques secondes plus tard, le processus de création du template se lance, le statut passe alors en Création :

La création d’un template est assez rapide, le statut doit alors changer en Succès et le nom du groupe de ressources temporaire doit apparaître.

Cliquez dessus pour voir la première ressource créée :

Seul un compte de stockage est pour l’instant créé, cliquez dessus :

Un premier conteneur Blob est créé, dans lequel se trouvent les optimisations de votre template AVD :

Retournez sur les Modèles d’images personnalisés, puis cliquez sur le groupe de ressources de votre template :

Constatez la présence de votre template :

Le template, ou la recette de votre VM AVD, est maintenant prêt. Un second processus doit être lancé pour créer l’image AVD en elle-même. Azure VM Image Builder va réaliser les actions suivantes :

  • Créer une machine virtuelle à partir de la marketplace
  • Lui appliquer votre configuration personnalisée
  • La capturer et la stocker dans votre Azure Compute Gallery

Etape IV – Préparation de l’image AVD :

Ce processus peut prendre beaucoup de temp. Celui-ci dépendra également des personnalisations choisies à appliquer.

Cliquez-ici pour démarrer le processus de construction de votre image :

Le statut de construction change comme ceci :

Deux nouveaux conteneurs sont créés sur votre compte de stockage temporaire :

  • packerlogs : Journal d’évènements d’Azure VM Image Builder
  • vhds : fichier VHD de votre image créé par Azure VM Image Builder

Cliquez sur le premier conteneur afin de consulter, si besoin, le journal de log d’Azure VM Image Builder :

Rafraichissez cette page afin de voir le changement de statut :

Rafraichissez également cette seconde page afin de voir les changements de date de modification du journal d’évènements :

Environ 2 heures plus tard, le statut est enfin passé à Succès :

Vérifiez que la définition de votre image est bien stockée dans votre Azure Compute Gallery :

La version de l’image est également visible dans le groupe de ressources cible :

Notre image est enfin prête à intégrer un environnement Azure Virtual Desktop.

L’étape suivante consiste donc à créer un premier pool AVD en choisissant comme source cette nouvelle image personnalisée.

Etape V – Création de l’environnement AVD :

Sur la page Azure Virtual Desktop, commencez la création de votre environnement Azure Virtual Desktop comme ceci :

Définissez les options de base de votre pool d’hôtes :

Ajoutez une ou plusieurs machines virtuelles en prenant le soin de choisir l’image créée et stockée dans votre Azure Compute Gallery :

Renseignez les informations réseaux pour que votre VMs AVD se trouve sur le même réseau virtuel que votre AD :

Renseignez les informations liées à votre AD et les identifiants pour disposer d’un compte administrateur local, puis cliquez sur Suivant :

Créez un nouvel Espace de travail, puis lancez la validation :

Une fois la validation terminée, cliquez sur Créer :

Attendez environ 5 à 10 minutes, le temps que la création de votre environnement AVD se termine, puis cliquez ici :

Changez l’option d’authentification d’Azure AD, puis sauvegardez :

Cliquez sur le groupe d’applications AVD :

Ajoutez vos utilisateurs ou votre groupe d’utilisateurs de test :

C’est enfin fini ! Toutes les configurations sont faites ! Il ne vous reste plus qu’à tester votre nouvel environnement Azure Virtual Desktop.

Etape VI – Test de connexion à votre environnement AVD :

Pour cela, utilisez le client Remote Desktop disponible ici, ou l’URL suivante pour une connexion en HTLML5 via le navigateur internet.

Ouvrez votre application, souscrivez à un nouvel espace de travail, puis authentifiez-vous avec un compte utilisateur de test :

Réauthentifiez-vous une seconde fois, localement :

Attendez que la session de bureau à distance s’ouvre :

Vérifiez quelques paramétrages personnalisés, comme la langue ou les applications installées :

Les choses semblent pas mal pour moi sauf le pays et encore l’heure de la VM :

Vérifiez également sur votre compte de stockage dédié à FSLogix que l’ouverture de session AVD génère bien la création d’un profil itinérant :

On peut dire qu’on est pas mal, non ? 😎

Conclusion :

L’intégration Azure VM Image Builder dans la console Azure Virtual Desktop, mais aussi l’ajout direct de personnalisations, proposées par Microsoft, est un véritable pas en avant concernant la simplification !

Azure Virtual Desktop conserve malgré tout la caractéristique de pouvoir être personnalisé manuellement, mais apporte en parallèle une couche d’automatisme pour les petits environnements.

Nul doute que tout cela sera très fortement apprécié !