Guide de dépannage

des conditions inhabituelles. Par
exemple, que se passe-t-il si un utilisateur a un profil itinérant
spécifié mais qu’il n’ait pas de copie en cache locale et
que Windows ne puisse pas accéder à  la copie itinérante ?
Dans XP et Win2K, le système crée un profil temporaire à  partir du profil utilisateur par défaut sous \ % systemroot
%\documents and settings\temp pour permettre à  l’utilisateur
de continuer à  travailler. Toutefois, quand l’utilisateur
se déconnecte, le système ne s’intéresse plus au profil
temporaire. Et donc, les éventuels changements apportés au
profil sont perdus.
Voici un autre scénario courant. Que se passe-t-il si deux
utilisateurs avec le même nom d’utilisateur se connectent à 
une station de travail : les profils de l’un des utilisateurs vontils
écraser ceux de l’autre ? La réponse est non, mais la raison
n’est pas du tout évidente. Rappelez-vous que chaque copie
en cache locale d’un profil s’enregistre elle-même par le SID
de l’utilisateur dans le registre, pour éviter le problème que
je viens de mentionner. Deux noms d’utilisateurs identiques
ne poseront pas de problème parce que les SID seront différents.
Mais où le système va-t-il stocker le second profil ? La
réponse est que Windows ajoute le nom du domaine (ou du
groupe de travail) de l’utilisateur au chemin de dossier qui
est créé sous le dossier Documents and Settings. Supposons
que vous ayez un jsmith défini dans le domaine AD mycompany.
com (nom NetBIOS mycompany) et un autre compte jsmith
défini sur la station de travail locale nommée
workstationA. Le jsmith basé sur la station de travail locale se
connecte en premier sur workstationA et l’utilisateur local jsmith
obtient un profil créée sous \ % systemroot %\documents
and settings\jsmith. Ensuite, le jsmith basé sur le domaine
se connecte à  la même station de travail. Windows
crée un profil pour le second jsmith sous \ % systemroot
%\documents and settings\jsmithmycompany pour
identifier l’origine du compte. C’est compliqué mais efficace.
Presque tous les sites Windows que je
connais souffrent d’un gros problème avec
des profils utilisateur, sans qu’il y ait de
bonne réponse. Parfois, lorsqu’un utilisateur
se déconnecte d’un système, celui-ci
ne décharge pas complètement le profil de
l’utilisateur. Certains processus s’exécutant
sur la station de travail auront encore un
handle ouvert vers le profil – généralement
vers la ruche du registre ntuser.dat – qui
empêche le profil de se décharger complètement.
Cette situation peut causer toutes
sortes d’ennuis sur la station de travail, parce que les changements
d’un utilisateur dans ntuser.dat risquent de ne pas
être écrits correctement sur le profil itinérant de l’utilisateur,
ou parce que Windows pourrait être incapable de supprimer
la copie en cache locale du profil, si vous avez défini cette option.
En outre, si vous utilisez un outil tel que delprof.exe (à 
partir du kit des ressources) pour supprimer à  distance les
profils en cache locaux, cet utilitaire pourrait être incapable de supprimer le profil local. La seule solution raisonnable
que j’ai trouvée consiste à  réinitialiser la station de travail, ce
qui, en définitive, libère les handles qui pourraient exister
vers le profil. Bien entendu, cette action est infaisable dans
certaines circonstances. Microsoft offre au moins un outil
pour atténuer cette situation, sous la forme d’une stratégie
XP pour augmenter le nombre de fois que Windows essaie
de décharger le profil avant d’y renoncer. Cette stratégie,
que vous trouverez sous Computer Configuration
\Administrative Templates\System\User Profiles\Maximum
réessaie de décharger et de mettre à  jour le profil utilisateur,
peut s’avérer utile si ce problème est chronique dans votre
environnement.
Si vous avez des doutes sur ce qui se passe avec vos profils
utilisateur, je vous conseille d’activer le logging userenv
détaillé. Le fichier userenv.log se trouve dans le dossier \ %
systemroot %\debug\usermode sur toutes les machines
Windows 2003, XP et Win2K. Pour valider la journalisation
détaillée pour les profils utilisateur et les stratégies de
groupe, suivez les instructions de l’article Microsoft « How to
Enable User Environment Debug Logging in Retail Builds of
Windows » (http://support.microsoft.com/?kbid=221833).
Ce fichier log enregistre des informations détaillées sur ce
qui se passe pendant le chargement et le déchargement des
profils et peut être commode quand vous devez dépanner
des problèmes de profil.