Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.
Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.
Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.
Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.
Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :
Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.
Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :
Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.
Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :
Qu’est-ce qu’une identité cloud-only ?
Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.
Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?
Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».
Que change concrètement pour un architecte cloud ou un administrateur ?
Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.
Plusieurs vidéos sont également disponible pour vous aider à la tâche :
Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :
- Activer l’authentification Microsoft Entra Kerberos pour les identités cloud
- Stockez les conteneurs de profils FSLogix sur Azure Files à l’aide de Microsoft Entra ID
Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.
L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :
- Etape 0 – Rappel des prérequis
- Etape I – Préparation de l’environnement
- Etape II – Test de connexion AVD
- Etape III – Configurations des permissions NTFS Access Control Lists
- Etape IV – Tests de performances
Etape 0 – Rappel des prérequis :
Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :
- Un abonnement Azure valide
- Un tenant Microsoft
Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.
Etape I – Préparation de l’environnement :
Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :
Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :
Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :
Activation de l’identité Microsoft Entra directement sur le compte de stockage :
Activation du support Microsoft Entra Kerberos pour gérer l’authentification :
Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :
Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :
Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :
Attribution du consentement administrateur global pour autoriser l’application
Validation de l’autorisation accordée à l’application d’entreprise :
Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :
Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :
Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :
Activation du Single Sign-On directement dans les propriétés RDP :
Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f
Confirmation que la clé de registre est bien apparue :
Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :
reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1
Vérification de la création de la clé de registre attendue dans Windows :
Application de la configuration complète FSLogix via les différentes clés de registre :
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f
Vérification de la création des clés de registre attendues pour FSLogix :
Alternative via Intune pour gérer ces mêmes paramètres sans script :
Redémarrage des machines virtuelles du host pool pour appliquer la configuration :
Etape II – Test de connexion AVD :
Attente du retour en ligne des machines dans l’environnement AVD :
Activation du mode de drainage sur la seconde machine pour préparer les tests :
Connexion avec l’utilisateur de test pour valider le fonctionnement :
Observation du démarrage du service FSLogix App Services à l’ouverture de session :
Création du dossier de profil FSLogix directement dans le file share :
Présence du fichier VHDx correspondant au profil utilisateur :
Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :
Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :
Inversion du mode de drainage sur les deux machines AVD :
Reconnexion avec l’utilisateur de test pour valider la bascule du profil :
Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :
Vérification que la permission générée pour l’utilisateur de test est bien présente :
Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.
Etape III – Configurations des permissions NTFS Access Control Lists :
Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :
Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :
Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :
Travis Roberts rencontre d’ailleurs le même souci que moi :
Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :
Le bouton Manage access est alors visible juste ici :
Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :
L’affichage des permissions NTFS Access Control Lists configurées par défaut :
Les permissions pour FSLogix doivent alors être reconfigurées comme telles :
Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.
Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.
Etape IV – Tests de performances :
J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :
- Partage de fichiers sur un compte de stockage Premium joint à Entra ID
- Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
- Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput
Pour réaliser les mesures, nous utiliserons l’outil Diskspd :
DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.
Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.
Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :
Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :
L’exécutable se trouve dans le sous-dossier amd64 :
Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :
- Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
- IOPS
- Débit
- Le changement entre ces deux séries se fera au niveau de la taille des blocs.
Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :
Partage de fichiers sur un compte de stockage Premium joint à Entra ID :
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :
Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :
Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :
C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt
C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt
C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt
C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt
C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt
C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt 
Les arguments utilisés pour diskspd.exe sont les suivants :
- -d900 : durée du test en secondes
- -r : opérations de lecture/écriture aléatoires
- -w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
- -F4 : nombre de threads max
- -o128 : longueur de la file d’attente
- -b8K : taille du bloc
- -Sh : ne pas utiliser le cache
- -L : mesure de la latence
- -c50G : taille du fichier 50 GB
- E:\diskpsdtmp.dat : chemin du fichier généré pour le test
- > IOPS-AvecEntra.txt : fichier de sortie des résultats
Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :
| Scenario | IOPS | Bandwidth MB/s |
|---|---|---|
| Avec Entra ID | 12,446.88 | 299.95 |
| Sans Entra ID | 15,032.54 | 341.17 |
| Premium SSD v2 | 20,378.31 | 1,167.25 |
Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.
La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.
Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.
Conclusion
Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.
Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.
Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.
