Personal vDisk (PvD) et les User Profile Disks (UPD) de Microsoft sont en fin de vie depuis plusieurs années. Les deux technologies partagent un défaut structurel : elles lient le profil à un disque virtuel attaché à une VM spécifique, ce qui complique la portabilité entre hôtes et la montée en charge.
Le choix du successeur, FSLogix Profile Container ou une solution de couche utilisateur (UPL), dépend moins de la fonctionnalité que de l’architecture de stockage et d’identité déjà en place.
Authentification Kerberos et stockage SMB : le piège ignoré lors d’une migration FSLogix
FSLogix monte un VHD/VHDX depuis un partage SMB au moment de l’ouverture de session. Toute la chaîne d’authentification (poste, contrôleur de domaine, serveur de fichiers) doit être cohérente sur le plan du chiffrement Kerberos. Depuis le changement d’avril 2026 sur le chiffrement Kerberos pour les partages de profils, Microsoft signale que les échecs de montage FSLogix proviennent souvent d’incompatibilités d’authentification ou de chiffrement entre le client et le backend SMB, et non d’un problème de conteneur.
Concrètement, un environnement qui s’appuie sur Azure Files avec authentification Entra ID (ex-Azure AD) ne rencontre pas les mêmes contraintes qu’un partage hébergé sur un serveur de fichiers Windows Server joint au domaine AD DS classique. Si votre infrastructure impose NTLM sur certains segments réseau (sites distants, VPN legacy), FSLogix peut échouer silencieusement au montage du profil et basculer sur un profil temporaire.
Avant de migrer, nous recommandons de valider la politique de chiffrement Kerberos de bout en bout : type de ticket (AES-256 vs RC4), délégation contrainte, et compatibilité du backend de stockage cible. Une solution UPL qui ne repose pas sur un montage SMB à l’ouverture de session contourne ce problème, mais au prix d’une complexité de packaging différente.
FSLogix Profile Container : scénarios où il s’impose
FSLogix reste la recommandation officielle de Microsoft pour Azure Virtual Desktop et les environnements RDS multi-sessions. Son avantage principal est la simplicité opérationnelle : un seul VHD/VHDX par utilisateur, monté dynamiquement, compatible avec Office 365 (cache Outlook, OneDrive, Teams).
Le scénario typique où FSLogix domine :
- Infrastructure AVD ou RDS hébergée sur Azure avec Azure Files ou Azure NetApp Files comme backend de stockage, authentification Entra ID Kerberos configurée.
- Population d’utilisateurs standardisée, où la personnalisation se limite au profil Windows, aux favoris de navigateur et au cache applicatif. Pas de couche applicative spécifique par utilisateur.
- Besoin d’un clean start plutôt qu’une conversion de profils existants : dans la majorité des migrations PvD, conserver l’ancien profil bit à bit génère plus de problèmes qu’il n’en résout (clés de registre orphelines, chemins en dur vers l’ancien disque PvD).
Le module PowerShell FSLogixMigration permet de convertir des UPD ou des profils UPM Citrix vers des conteneurs FSLogix. Nous observons que cette conversion scriptée fonctionne correctement pour des profils légers, mais qu’elle échoue fréquemment sur des profils PvD volumineux qui embarquent des applications installées localement. Le PvD n’était pas un simple profil, c’était une couche système entière.
User Personalization Layer (UPL) Citrix : quand la couche applicative compte
La différence fondamentale entre FSLogix et une UPL tient à la granularité. FSLogix capture le profil utilisateur. Une UPL capture le profil et les applications installées par l’utilisateur, y compris les fichiers système modifiés, les pilotes d’impression ajoutés, les extensions applicatives.
Si vos utilisateurs PvD avaient la possibilité d’installer des logiciels dans leur couche personnelle (c’était précisément la promesse de Personal vDisk), FSLogix ne couvrira pas ce périmètre. Les applications installées hors de l’image de base ne seront pas portées. Deux options se présentent alors :
- Réintégrer ces applications dans l’image gold ou dans des couches App Layering Citrix, puis migrer uniquement le profil vers FSLogix.
- Adopter une solution de couche utilisateur (UPL Citrix, ou Liquidware ProfileUnity/FlexApp) qui capture à la fois le profil et la couche applicative.
Le choix dépend du nombre d’applications « hors image » effectivement utilisées. Si la population PvD n’exploitait qu’une ou deux applications spécifiques, les intégrer dans l’image gold est plus simple que de déployer une UPL complète. Si chaque utilisateur avait un environnement applicatif distinct, la UPL évite de multiplier les images.
Conversion VHD vers VHDX et redimensionnement des conteneurs FSLogix
Les PvD et UPD utilisent le format VHD. FSLogix supporte VHD et VHDX, mais le format VHDX offre une meilleure résilience aux corruptions et supporte des tailles supérieures. La conversion est possible via PowerShell (Convert-VHD) ou via Hyper-V Manager, mais elle nécessite le rôle Hyper-V installé sur la machine qui exécute le script.
Points de vigilance lors de la conversion
Le conteneur FSLogix est dynamique par défaut : le fichier VHDX grossit à mesure que l’utilisateur consomme de l’espace, jusqu’à la taille maximale définie (par défaut, plusieurs dizaines de gigaoctets). Microsoft précise que la taille du conteneur n’affecte pas les temps de connexion ni les performances de manière significative. Le facteur limitant est le débit IOPS du backend de stockage, pas la taille du fichier.
Lors d’une migration PvD, les fichiers VHD source sont souvent volumineux parce qu’ils contenaient le système d’exploitation différentiel. Il ne faut pas convertir ces VHD tels quels.
L’approche correcte consiste à extraire uniquement les données de profil (dossier Users, ruches de registre NTUSER.DAT et UsrClass.dat), puis aux injecter dans un conteneur FSLogix neuf. Le script Convert-UPDtoFSLogix disponible sur GitHub suit cette logique pour les UPD et peut servir de base, mais il devra être adapté pour le layout spécifique des PvD.
Stratégie de migration : clean start ou conversion scriptée
Nous recommandons le clean start pour la majorité des migrations PvD. Le PvD capturait des éléments système (pilotes, services, entrées COM) que ni FSLogix ni une UPL ne doivent hériter. Convertir un PvD complet vers un conteneur FSLogix revient à importer de la dette technique dans un environnement neuf.
Le clean start implique que les utilisateurs retrouvent un profil vierge et doivent reconfigurer certains paramètres (signature Outlook, favoris, préférences applicatives). Pour atténuer l’impact, déployez les GPO de redirection de dossiers (Documents, Bureau, Favoris) avant la migration, puis désactivez-les une fois les conteneurs FSLogix stabilisés.
La conversion scriptée reste pertinente si vous migrez depuis des UPD (pas des PvD) vers FSLogix, car les UPD ne contiennent que le profil utilisateur. Le script PowerShell copie les fichiers du VHD source, renomme le conteneur selon la convention SID attendue par FSLogix, et ajuste les permissions NTFS.
Le critère de décision final reste l’architecture d’identité. Si votre environnement cible utilise Entra ID avec Kerberos sur Azure Files, FSLogix s’intègre nativement. Si vous conservez une infrastructure on-premises avec des contraintes NTLM ou un stockage NAS tiers, évaluez le coût réel de mise en conformité Kerberos avant de vous engager sur FSLogix.
