Profil utilisateur itinérant

Disposition des dossiers d'un profil utilisateur Windows 2000/XP classique. Normalement, tous les éléments, à l'exception des « Paramètres locaux », sont stockés sur le serveur de fichiers dans le cadre d'un profil itinérant.

Un profil utilisateur itinérant est un concept de synchronisation de fichiers dans la famille de systèmes d'exploitation Windows NT qui permet aux utilisateurs d'un ordinateur joint à un domaine Windows de se connecter à n'importe quel ordinateur du même domaine et d'accéder à leurs documents et de bénéficier d'une expérience de bureau cohérente, comme les applications mémorisant les positions et les préférences de la barre d'outils, ou l'apparence du bureau restant la même, tout en conservant tous les fichiers associés stockés localement, pour ne pas dépendre en permanence d'une connexion réseau rapide et fiable à un serveur de fichiers .

Depuis Windows NT 3.1, tous les systèmes d'exploitation Windows sont conçus pour prendre en charge les profils itinérants. Normalement, un ordinateur autonome stocke les documents de l'utilisateur, les éléments du bureau, les préférences des applications et l'apparence du bureau sur l'ordinateur local dans deux sections séparées, constituées de la partie pouvant être itinérante et d'une partie temporaire supplémentaire contenant des éléments tels que le cache du navigateur Web. Le registre Windows est également divisé pour prendre en charge l'itinérance ; il existe des ruches Système et Machine locale qui restent sur l'ordinateur local, ainsi qu'une ruche Utilisateur distincte (HKEY_CURRENT_USER) conçue pour pouvoir se déplacer avec le profil utilisateur.

Lorsqu'un utilisateur itinérant est créé, les informations de son profil sont stockées sur un serveur de fichiers centralisé accessible depuis n'importe quel ordinateur de bureau connecté au réseau. L'invite de connexion sur l'ordinateur local vérifie si l'utilisateur existe dans le domaine plutôt que sur l'ordinateur local ; aucun compte préexistant n'est requis sur l'ordinateur local. Si la connexion au domaine réussit, le profil itinérant est copié du serveur de fichiers central vers l'ordinateur de bureau et un compte local est créé pour l'utilisateur.

Lorsque l'utilisateur se déconnecte de l'ordinateur de bureau, le profil itinérant de l'utilisateur est fusionné de l'ordinateur local vers le serveur de fichiers central, sans inclure les éléments de profil locaux temporaires. Comme il s'agit d'une fusion et non d'un déplacement/suppression, les informations de profil de l'utilisateur restent sur l'ordinateur local en plus d'être fusionnées avec le réseau.

Lorsque l'utilisateur se connecte sur un deuxième ordinateur de bureau, ce processus se répète, fusionnant le profil itinérant du serveur vers le deuxième ordinateur de bureau, puis fusionnant à nouveau du bureau vers le serveur lorsque l'utilisateur se déconnecte.

Lorsque l'utilisateur revient sur le premier ordinateur de bureau et se connecte, le profil itinérant est fusionné avec les informations du profil précédent, le remplaçant. Si la mise en cache des profils est activée, le serveur est capable de fusionner uniquement les fichiers les plus récents sur l'ordinateur local, de réutiliser les fichiers locaux existants qui n'ont pas changé depuis la dernière connexion, accélérant ainsi le processus de connexion.

En raison de la copie du profil lors de la connexion et de la déconnexion, un profil itinérant configuré à l'aide de la configuration par défaut peut être extrêmement lent et faire perdre beaucoup de temps aux utilisateurs disposant de grandes quantités de données dans leur compte.

Lorsque Microsoft a conçu Internet Explorer , les programmeurs ont pris la décision explicite de stocker les cookies et les favoris sous forme de petits fichiers individuels de moins d'un kilo-octet chacun, plutôt que de stocker ces données dans un seul gros fichier consolidé. Microsoft stocke également les fichiers de raccourci dans le dossier de profil Récent , qui renvoient vers les fichiers et dossiers récemment ouverts.

Les serveurs de fichiers ont tendance à transférer uniquement des fichiers volumineux de plusieurs mégaoctets à la vitesse réseau la plus rapide possible. Des centaines de très petits fichiers d'un kilo-octet par fichier seulement peuvent réduire les performances du réseau de 90 %. À mesure qu'un profil vieillit et accumule des centaines, voire des milliers de cookies, de favoris et d'éléments récents, les temps de connexion et de déconnexion deviennent progressivement plus lents, même si ces fichiers n'occupent que quelques mégaoctets de données de profil.

La mise en cache locale du profil utilisateur sur le disque dur d'un ordinateur de bureau peut réduire et améliorer les temps de connexion et de déconnexion, mais au risque d'encombrer le disque dur avec les données de profil de chaque utilisateur mis en cache qui se connecte. La mise en cache locale est plus adaptée lorsque les gens ont tendance à utiliser le même ordinateur tous les jours. La mise en cache locale des profils n'est pas utile lorsque des centaines, voire des milliers d'étudiants, doivent pouvoir utiliser n'importe quel ordinateur sur le campus d'une école ou d'une université : les données cumulées mises en cache provenant de tant de profils différents peuvent consommer tout l'espace disque disponible sur l'ordinateur du laboratoire.

Les utilisateurs avec un profil itinérant peuvent rencontrer des retards de connexion paralysants lorsqu'ils se connectent via un réseau étendu . S'ils sont connectés au domaine à partir d'un site distant, après l'authentification, Windows tente d'extraire le profil de l'utilisateur de l'emplacement spécifié dans Active Directory . Si l'emplacement se trouve sur une liaison WAN, cela peut potentiellement ralentir considérablement le WAN et provoquer l'échec de la connexion (après un délai très long).

Les utilisateurs avec un profil itinérant travaillant à partir d'un site distant doivent se connecter à la machine avant de se connecter au réseau (afin que la machine utilise sa copie locale en cache) et se connecter au réseau une fois la connexion terminée. Une autre option consiste à supprimer le chemin du profil itinérant d'Active Directory avant leur départ. Cela doit être fait suffisamment tôt pour que la modification soit répliquée sur le contrôleur de domaine concerné sur le site distant.

Travailler avec des fichiers volumineux, comme l'édition de vidéos brutes , peut entraîner des temps de connexion et de déconnexion excessifs, car Windows copie les fichiers du profil itinérant sur l'ordinateur lors de la connexion et les renvoie sur le serveur lors de la déconnexion.

Dans les environnements où les fichiers volumineux ne sont pas critiques pour la mission et n'ont pas absolument besoin d'être sauvegardés sur un serveur à chaque connexion, les applications nécessitant des quantités excessivement importantes de données utilisateur sont généralement exécutées sur un compte local autonome qui ne se déplace pas, pour contourner ces problèmes de stockage et de récupération réseau.

Dans un environnement scolaire, l'itinérance peut entraîner une congestion et une lenteur importantes du réseau lorsqu'une classe entière d'élèves se déconnecte de leurs ordinateurs en même temps, puis tente de se connecter ailleurs quelques minutes plus tard. Une incohérence dans les données de compte peut se produire si les élèves commencent à se connecter au deuxième emplacement avant que le téléchargement du profil et la déconnexion du premier emplacement ne soient terminés.

Certains programmes installés sur des ordinateurs de bureau ne libèrent pas correctement le contrôle du registre utilisateur lors de la déconnexion et peuvent entraîner la corruption des profils car la copie du registre utilisateur ne se termine jamais correctement. Pour résoudre ce problème, Microsoft a créé un utilitaire appelé User Profile Hive Cleanup Service qui va remapper de force les descripteurs de fichiers de ces programmes malveillants afin que la copie du profil puisse se terminer avec succès et que la déconnexion du compte soit réussie. Cependant, le programme bloqué peut rester sur l'ordinateur local en conservant toujours la copie en cache locale du registre utilisateur dans un état occupé, jusqu'au redémarrage de l'ordinateur.

La version la plus récente d'un fichier dans un profil itinérant sans redirection est stockée uniquement sur l'ordinateur local et y reste jusqu'à ce que l'utilisateur se déconnecte, après quoi elle est transférée vers le serveur. Si des sauvegardes nocturnes du serveur sont effectuées et qu'un utilisateur itinérant ne se déconnecte pas pendant plusieurs jours, ses documents de compte itinérant ne sont pas inclus dans la sauvegarde nocturne.

De plus, si un utilisateur itinérant utilise le mode veille ou hibernation pour éteindre son ordinateur la nuit, son profil n'est toujours pas copié sur le réseau. De cette manière, il est possible que les documents d'un compte itinérant ne soient pas sauvegardés pendant des jours ou des semaines, et il existe un risque de perte de données considérable si le disque dur local subit une panne catastrophique pendant ces longues périodes sans déconnexion du compte itinérant de l'ordinateur local.

En raison du mécanisme de copie de fichiers sous-jacent du serveur vers le bureau, l'itinérance suppose que le compte utilisateur est connecté à un seul ordinateur à la fois. Les documents d'un profil itinérant copiés sur la machine locale n'ont aucune connaissance réseau les uns des autres et il n'est pas possible d'utiliser le verrouillage de fichier pour avertir l'utilisateur que le fichier est déjà ouvert.

La connexion à plusieurs ordinateurs avec un seul compte et l'ouverture du même document plusieurs fois sur chaque ordinateur peuvent entraîner des incohérences et la perte des modifications enregistrées si le fichier est modifié sur deux ordinateurs différents en même temps :

• Lorsque le premier ordinateur avec le document modifié se déconnecte, les modifications sont écrites sur la copie réseau du profil.
• Lorsque le deuxième ordinateur se déconnecte, la version différente du document écrase les modifications précédemment enregistrées lors de la déconnexion du profil.

Différentes versions de Windows peuvent utiliser différentes dispositions de profil utilisateur incompatibles. Ainsi, un utilisateur qui se déplace entre des ordinateurs dotés de systèmes d'exploitation différents a besoin de profils itinérants distincts pour chaque système d'exploitation. Windows Vista et Windows 7 ajoutent le suffixe « .v2 » au dossier de profil utilisateur pour l'isoler des profils utilisateur de Windows XP et des versions antérieures. Malgré cela, Microsoft TechNet conseille aux utilisateurs de ne pas se déplacer entre des ordinateurs exécutant Windows Vista/ Windows Server 2008 et Windows 7/ Windows Server 2008 R2 . Les profils utilisateur dans Windows 8 / Windows Server 2012 et Windows 8.1 / Windows Server 2012 R2 ne sont pas non plus entièrement rétrocompatibles, bien qu'ils utilisaient initialement également le suffixe « .v2 ». Microsoft a ensuite publié des correctifs et des instructions pour permettre à ces systèmes d'exploitation d'ajouter respectivement les suffixes « .v3 » et « .v4 », les séparant ainsi de l'accès entre systèmes d'exploitation.

Pour résoudre ces problèmes de copie de profil, il est possible de contourner le fonctionnement par défaut de l'itinérance et de configurer des comptes d'utilisateur de manière à ce que certaines parties du profil soient accessibles directement par l'ordinateur local sur un serveur de fichiers central plutôt que d'être copiées d'abord sur l'ordinateur local. Si le serveur tombe en panne, les utilisateurs peuvent toujours accéder à certains fichiers grâce aux améliorations des fichiers hors ligne.

Pour l'utilisateur final, la redirection de dossiers ne semble généralement pas fonctionner différemment de l'utilisation d'un ordinateur autonome normal. La redirection des dossiers Mes documents et Bureau de l'utilisateur pour qu'ils soient accessibles directement sur un serveur de fichiers constitue les deux premières étapes importantes pour accélérer les profils itinérants. Cependant, comme les logiciels tiers ont commencé à stocker de plus en plus de données dans la partie Données d'application du profil itinérant, il est également devenu utile de rediriger ces données pour qu'elles soient également accessibles directement sur le serveur.

On peut se demander pourquoi l'intégralité du profil itinérant n'est pas accessible directement sur le serveur et pourquoi aucune copie n'est nécessaire. Il semble que cela soit dû au fait que certains programmes Microsoft exécutés en permanence sur l'ordinateur client ne peuvent pas tolérer la perte soudaine de leurs dossiers de données en cas de panne du serveur ou de déconnexion du réseau. Certaines parties doivent encore être copiées dans les deux sens avant que le bureau n'apparaisse, afin que ces dossiers soient disponibles en cas de panne des dossiers redirigés vers le réseau.

Certains programmes ne fonctionnent pas correctement avec les dossiers de profil redirigés qui font référence à un chemin de fichier UNC sur un partage de serveur : \\serveur\partage om d'utilisateur\Application Data

• À moins que l'entrée de registre [HKEY_CURRENT_USER\Software\Microsoft\Command Processor] « DisableUNCCheck »=dword:1 ne soit définie, le processeur de commandes de Windows ne peut pas avoir de répertoire de travail UNC, donc les fichiers batch échouent généralement.
• Il n'est pas possible d'installer des modules complémentaires Microsoft Office VSTO sur un chemin UNC. (AppData peut être un emplacement naturel pour que les utilisateurs installent des modules complémentaires sans privilèges d'administrateur.)
• Adobe Reader est incompatible avec les données d'application situées sur un chemin de fichier UNC depuis au moins la version 9.0, ce qui entraînerait un blocage avec une erreur d'exécution. Adobe Reader X (10.0) est partiellement compatible mais ne s'exécutera pas en mode de protection de document sur un chemin UNC.
• OpenOffice.org 3.3 est également incompatible avec Application Data sur un chemin UNC, et le logiciel plante au démarrage. Un correctif a été développé et sera disponible dans une prochaine version.
• Les profils itinérants et la redirection ne sont pas pris en charge par AutoCAD 2013.

Ces problèmes avec les chemins UNC peuvent généralement être résolus en redirigeant les dossiers vers un mappage de lecteur pour le partage UNC :

• Le lecteur N: (par exemple) est mappé sur \\server\share\userhomedir
• Redirection du dossier AppDir vers le répertoire personnel de l'utilisateur : N:\Application Data

Cependant, l’utilisation de mappages de lecteurs est généralement déconseillée par Microsoft, et les chemins de redirection UNC uniquement sont l’implémentation préférée.

• Les versions des logiciels d'application sur différentes machines utilisées avec le même profil peuvent devoir être synchronisées, avec les mêmes options installées, sinon les fichiers de configuration du logiciel peuvent faire référence à des bibliothèques dynamiques ou à des extensions ou à d'autres ressources qui ne sont pas disponibles sur une autre machine, provoquant un blocage du système ou des fonctionnalités limitées ou une corruption de la configuration.
• L'installation d'un logiciel sous un compte peut entraîner un fonctionnement partiel du logiciel pour d'autres comptes, car les ressources ne sont pas disponibles pour les autres utilisateurs en fonction de leurs droits d'accès aux dossiers personnels de l'installateur.

La redirection de dossiers peut être utilisée avec des profils obligatoires et est utile dans les situations où il est souhaitable de « verrouiller » l'apparence générale du bureau tout en permettant aux utilisateurs d'enregistrer des documents sur le réseau. Par exemple, cela peut être utilisé comme un compte générique que n'importe qui peut utiliser sans mot de passe pour une utilisation temporaire.

La redirection de Mes documents et du Bureau dans un profil obligatoire permettra d'enregistrer les documents, mais lors de la déconnexion, toutes les modifications apportées à l'apparence du bureau, telles que l'image du bureau, les cookies Internet Explorer, les favoris et la liste des documents récemment ouverts, seront rétablies à l'état d'origine.

La redirection de dossiers avec des profils obligatoires est réalisée en refusant l'accès en écriture à la copie centrale du profil. Lorsque les utilisateurs se déconnectent, ils peuvent s'attendre à recevoir régulièrement une erreur indiquant que le profil n'a pas pu être copié avec succès sur le serveur. Un utilisateur doit également savoir que le stockage de données à certains emplacements peut entraîner la perte de ses données. Par exemple, si le bureau est réinitialisé chaque fois qu'un utilisateur se connecte avec le bureau du profil obligatoire, alors même s'il semble correct d'enregistrer des fichiers sur le bureau, lorsque l'utilisateur se déconnecte, le profil n'est pas copié sur le serveur, et lorsque l'utilisateur se reconnecte, tout travail enregistré sur le bureau est définitivement perdu sans aucun préavis autre que l'erreur lors de la déconnexion indiquant que le profil n'a pas pu être copié.

Lorsque l'utilisateur U se connecte à un ordinateur Windows C joint à un domaine, C consulte les emplacements suivants pour déterminer si l'utilisateur a un chemin de profil itinérant configuré :

1. la stratégie de groupe « Définir le chemin d'accès pour le profil utilisateur itinérant des services Bureau à distance » pour C , si la connexion s'effectue sur un serveur de terminaux
2. l'attribut msTSProfilePath de l'objet LDAP de U , si la connexion est effectuée sur un serveur de terminaux
3. la stratégie de groupe « Définir le chemin du profil itinérant pour tous les utilisateurs se connectant à cet ordinateur » pour C
4. l'attribut profilePath de l'objet LDAP de U

Le premier de ces paramètres de configuration qui possède une valeur remplace tous les paramètres suivants. Les attributs LDAP peuvent être définis par un administrateur de domaine ou par toute autre personne disposant d'un accès en écriture à l'objet utilisateur LDAP correspondant en fonction de sa liste de contrôle d'accès . La valeur configurée comme chemin de profil est généralement donnée sous la forme d'un chemin UNC vers un dossier sur un serveur de fichiers SMB , et le chemin contient généralement la variable « %USERNAME% » pour le rendre spécifique à l'utilisateur. Le profil itinérant pour les utilisateurs du serveur Bureau à distance est spécifié sous l'onglet « Profil des services Bureau à distance ».

Dans Windows 2000 et les versions ultérieures, une interface graphique permettant de définir l'attribut profilePath est disponible dans le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory . Windows NT 4.0 et les versions antérieures utilisaient le programme Gestionnaire d'utilisateurs pour les domaines . À partir de nombreux autres systèmes d'exploitation, ces attributs LDAP sont accessibles, par exemple, avec les outils de ligne de commande OpenLDAP ldapsearch et ldapmodify (après authentification SASL / GSSAPI ).

Lorsqu'un utilisateur se connecte à un ordinateur rattaché à un domaine, le shell Windows vérifie les attributs LDAP et les fichiers de stratégie de groupe mentionnés ci-dessus pour déterminer le chemin d'accès au profil utilisateur itinérant. Il appelle ensuite la fonction LoadUserProfile. Microsoft n'a pas documenté l'algorithme précis de synchronisation de fichiers que cette fonction implémente, mais elle consiste à comparer les horodatages de chaque fichier trouvé dans le profil local et le profil itinérant, puis à remplacer tout fichier plus ancien trouvé sur l'ordinateur. Lorsque l'utilisateur se déconnecte, le shell Windows appelle UnloadUserProfile, qui applique un algorithme de synchronisation de fichiers similaire dans la direction opposée, pour permettre aux modifications apportées au profil itinérant de migrer vers l'emplacement où le profil itinérant de l'utilisateur est stocké. De plus, depuis Windows 7, il est possible de spécifier une stratégie de groupe « Téléchargement en arrière-plan du fichier de registre d'un profil utilisateur itinérant pendant que l'utilisateur est connecté » pour appliquer ce processus de synchronisation au fichier NTuser.dat à intervalles réguliers (la valeur par défaut est de 12 heures). La connexion à Windows via OpenSSH pour Windows ne charge pas de profil itinérant.

Les postes de travail exécutant Windows 95, 98 ou Me peuvent également avoir des profils itinérants. Toutefois, les fichiers de profils itinérants des utilisateurs sous Windows 9x sont stockés dans le répertoire de base des utilisateurs, même si un emplacement distinct pour l'itinérance est spécifié. Pour utiliser des profils itinérants sous Windows 9x, chaque poste de travail doit être configuré pour avoir des paramètres de profil distincts pour chaque utilisateur qui se connecte au poste de travail local. L'activation de paramètres de bureau distincts sous Windows 9x est activée sous Mots de passe dans le Panneau de configuration de Windows.

Les profils itinérants sous Windows 95, 98 et Me sont tous compatibles entre eux. Ainsi, si un réseau est composé de postes de travail fonctionnant sous Windows 95 et Windows 98, le même profil utilisateur peut être utilisé pour chaque poste de travail. C'est également le cas avec les profils itinérants entre Windows NT 4.0, Windows 2000 et Windows XP, mais il peut y avoir des problèmes de compatibilité en raison des différences entre les différentes versions de Windows. Les profils itinérants sous Windows Vista et Windows 7 sont compatibles entre eux, mais ces versions ne sont pas compatibles avec les versions antérieures de Windows. Un dossier de profil distinct avec l'extension .V2 sera créé lors de l'utilisation de profils itinérants avec Windows Vista ou 7. La solution la plus simple consiste à faire en sorte que tous les postes de travail exécutent la même version de Windows. (voir la section Compatibilité)

Pour que l'itinérance fonctionne avec les serveurs Novell , le produit Novell « ZENworks Desktop Management » doit être installé sur le serveur et son package de gestion de poste de travail associé doit être installé sur chacun des ordinateurs clients. Dans l'annuaire, un objet Package utilisateur est créé, qui active l'itinérance, spécifie où le profil d'itinérance est stocké et stocke également toutes les stratégies de groupe associées pour chaque version de Windows sur laquelle les utilisateurs se connecteront. Le package utilisateur active également l'utilisateur local dynamique , qui fonctionne de manière similaire à Active Directory, permettant à un compte créé dans eDirectory de se connecter sur n'importe quel ordinateur de bureau même si aucun compte local n'existe au préalable, et attribue des privilèges de compte local tels qu'Utilisateur, Utilisateur avec pouvoir ou Administrateur au compte d'utilisateur local nouvellement créé. Pour Windows NT, les fichiers de profil utilisateur sont stockés dans le répertoire de base des utilisateurs sous un sous-dossier pour chaque version de Windows, par exemple dans Windows NT 4.0, le dossier sera appelé « Profil de poste de travail Windows NT 4.0 » et dans Windows XP, le dossier sera appelé « Profil de poste de travail Windows NT 5.1 ».

Le package utilisateur peut être associé à un compte utilisateur spécifique dans l'annuaire ou à une unité organisationnelle qui s'applique ensuite à tous les comptes utilisateurs de cette unité organisationnelle. Le package utilisateur permet également d'activer des fonctions ZENworks Desktop Management supplémentaires, telles que l'affichage et le contrôle à distance de l'ordinateur de bureau, les imprimantes réseau qui suivent l'utilisateur d'un bureau à l'autre et la planification d'événements qui doivent être exécutés quel que soit le lieu de connexion de l'utilisateur.

Bien que Windows 3.x ne contienne pas de profils utilisateur, les utilisateurs pouvaient disposer de leur propre bureau personnalisé dans un environnement professionnel. Windows 3.x disposait d'une option de configuration administrative que les administrateurs réseau pouvaient utiliser en tapant setup.exe /a. Windows pouvait ensuite être installé sur un partage réseau. Le programme d'installation de Windows était ensuite exécuté à partir de chaque machine locale pour installer quelques fichiers locaux, ce qui permettait à Windows 3.1 d'être exécuté sur un réseau. Les fichiers locaux pouvaient être enregistrés dans le répertoire personnel d'un utilisateur sur un réseau de domaine Novell ou Windows NT, ce qui permettait à l'utilisateur de déplacer ses paramètres entre les machines. Dans ce scénario, la machine locale ne nécessitait pas de disque dur et pouvait être démarrée à partir d'une disquette ou d'une carte réseau.

Il peut arriver qu'un profil utilisateur doive être réinitialisé si le profil est corrompu ou pour résoudre un problème avec une application. Une réinitialisation est généralement effectuée par un administrateur système ou un membre du service d'assistance. Pour effectuer une réinitialisation, l'utilisateur concerné doit se déconnecter du système, puis le dossier dans lequel le profil itinérant de l'utilisateur est stocké sur le serveur est renommé. Le profil utilisateur doit également être supprimé du poste de travail local auquel l'utilisateur se connecte, sinon l'utilisateur prendra le profil stocké localement lors de sa prochaine connexion. Lorsque le profil a été effacé de la machine locale, lorsque l'utilisateur se connecte, un nouveau profil est généré à l'aide du profil par défaut stocké sur le poste de travail. Lorsque l'utilisateur se déconnecte, le profil est recopié à l'emplacement où le profil itinérant de l'utilisateur a été stocké.

• Application du contrôle administratif par l'utilisation de profils d'utilisateur obligatoires qui aident à protéger l'environnement de l'utilisateur contre tout dommage causé par l'utilisateur lui-même.
• Les utilisateurs peuvent accéder à leurs données n'importe où sur le réseau avec plus de fiabilité
• Sauvegarde plus facile car la plupart des données se trouvent au même endroit sur le serveur

Chaque fois qu'un utilisateur se connecte à un poste de travail, tous les fichiers et paramètres sont transférés sur le réseau. Le processus de connexion prend donc plus de temps que si l'utilisateur utilisait un profil local. C'est particulièrement le cas si le profil est volumineux. Le temps de connexion peut être réduit si le profil est mis en cache, car certains fichiers peuvent être chargés à partir du poste de travail local et en utilisant la redirection de dossiers pour rediriger les dossiers qui peuvent atteindre une taille importante, comme Mes documents , vers un partage réseau.

Toutefois, cette limitation a été résolue dans Windows Server 2008 Active Directory en autorisant la redirection de dossiers de presque tous les dossiers qui étaient précédemment stockés dans le profil d'un utilisateur (y compris Ma musique, Favoris et autres) vers un partage réseau centralisé et sécurisé. Cela signifie que le profil itinérant d'un utilisateur peut facilement être réduit à une taille inférieure à 20 Mo, éliminant ainsi les longs délais de connexion rencontrés avec les versions précédentes d'AD. Lorsque vous utilisez la redirection de dossiers et la mise en cache automatique des fichiers hors ligne , tous les fichiers et préférences d'un utilisateur sont disponibles hors ligne et synchronisés de manière beaucoup plus efficace qu'auparavant lorsque l'ordinateur est reconnecté au réseau à l'aide de la compression différentielle à distance (RDC).

Un autre problème est lié aux différents ensembles d'applications installées sur les machines. Les applications stockent des informations dans les paramètres locaux et certaines dans le registre, mais seul le registre est transféré. Cela peut corrompre les fonctionnalités de l'application sous un profil itinérant.

Les dossiers réseau redirigés peuvent ignorer la séparation entre 2000/XP et Vista/Win7. Par exemple, les deux types de profils peuvent être redirigés pour utiliser un seul dossier Documents et un seul dossier Bureau, de sorte que les documents du compte de l'utilisateur soient cohérents entre les deux profils, même si tous les autres paramètres du compte sont différents.

Le partage redirigé de dossiers tels que les données d'application peut entraîner une corruption des données, car Microsoft n'a pas prévu que ses données d'application soient partagées entre les différentes versions du système d'exploitation.

Les programmes de virtualisation utilisateur (tels que AppSense ) gèrent les profils utilisateur , les paramètres et les données, en les stockant dans un partage réseau ou dans le cloud .