Profil regeneré sur Workstations

Répondre
Partager Rechercher
Yop,
(J'aurais jamais cru poster ça sur JOL, mais on sait jamais ;-))

je bosse dans une grosse structure au sein du Support Infrastructure et depuis Mi 2006, sur l'ensemble de notre parc - composé de 35 000 Machines - nous observons le problème suivant :
(Cela correspond à l'arrivée de 2003 SP1 sur la majorité de nos serveurs.)

Les profils des utilisateurs sont stockés dans Document And Settings
Sous la forme : Prenom.Nom

(Qui correspond exactement à leur compte utilisateur leur permettant de se logger sur le domaine.)

Sur à peu près 5% des postes, de manière aléatoire, un nouveau profil va être régénéré et de la forme:
Prenom.Nom.NomdeDomaine

Ce profil étant bien sûr vierge, l'ancien profil restant toujours à sa place, et ne souffrant d'aucune modification.

2 choix s'ouvrent à nous dans ces cas la :

1: Nous demandons à notre Service Desk d'aller dans le registre du poste, et de repointer sur le profil adéquat.
Après un reboot, la personne se relogge et repointe sur le bon profil.
Inconvénient : Le problème "peut" se reproduire et dans ce cas la un nouveau profil sera généré et de la forme:
Prenom.Nom.NomdeDomaine000 (Puis 001/002/etc)

2: Log en Local Admin, nous effaçons le "NomdeDomaine" du profil prenom.nom.NomdeDomaine.
Nous replaçons le "NomdeDomaine" sur l'ancien profil utilisé.
Après un reboot, sans modification sur le registre, le profil pointe bien et l'utilisateur retrouve son environnement.
Dans ce cas la, l'incident ne se retrouve jamais.

Cela fait donc plusieurs mois que le Service Desk procède de la sorte.
Ce n'est malheureusement qu'un Workaround.

Nous voudrions trouver le déclencheur de ce bug, mais à l'heure d'aujourd'hui nous ne l'avons toujours pas trouvé.

Les Workstations sont en 2000SP4/XPSP2.

Depuis des mois nous sommes en rapport avec HP (Avec qui nous avons un contrat de support pour les problèmes Microsoft)
Ils n'ont pour l'instant rien trouvé de probant, après que nous leur ayons envoyés de nombreux logs et installé pas mal d'outils pour essayer de tracer le problème. Cela ne serait pas un problème de droits car aucun ne saute après le bug.

Si quelqu'un dans sa boite est déjà tombé sur cette problématique, ça serait chouette qu'il m'en fasse part ;-)

Merci d'avance!
As tu constaté en parallèle avec la création du nouveau profil un message d'erreur dans l'event log sur la station, normalement provenant du process Userenv ou une erreur sur l'auto-enrollment ?
Il y a plusieurs cas, il serait aussi interessant de savoir :

Si l'Antivirus est le même sur toutes les stations

(Bon là ça va être plus dur à avoir comme info) si le nouveau profil a été recréé suite à un reboot, ou suite à une ouverture de session alors que la machine était deja up and running

Si il y a des GPO (simples ou complexes)

Etc etc...

Enfin toutes les infos dont tu disposes et qui te semblent utiles, si ça te gêne de les donner publiquement, tu peux me MP, et si ça te genes de me le donner tout court, je comprendrais....
Non ça me gêne pas.
Du moment que je n'indique pas ou je travaille

Antivirus : Symantec Corporate Edition / 10.1.5(ou6)
Je suis actuellement en rapport avec eux pour savoir si cela ne viendrait pas de ça.

GPO: Aucune

Toutes les workstations sont installées via une image identique.

Le problème se génère toujours après un reboot quelconque. Quand les users arrivent le matin par exemple.

Il y a un post qui traite de ce sujet, et personne ne semble avoir trouvé d'ou vient le problème.

http://www.mcse.ms/message2352633.html
Bon deja tu peux essayer en passant sur 1 ou 2 machines identifiées qui connaissent le problème le UPHClean (qui permet d'éviter les problèmes à la fermeture du profil, ce qui peut-être la cause pour en regenerer un nouveau) :

http://www.microsoft.com/downloads/d...displaylang=en

Gaffe je t'ai mis le lien d'origine en Anglais, donc a voir en fonction de la version de tes clients.

Sinon tu as monitoré si l'ID utilisateur avait changé ?

Une autre piste pourrait être le changement de password du compte de machin, tu pourrais essayer sur 2 ou 3 de changer les valeurs du registre (ça se fait sur les machines, pas sur les DC) :

Clé= HLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Valeur= DisablePasswordChange REG_DWORD 1
Valeur = 0
"id event 1517, avec comme source UserEnv"
Tu avais raison Paice.

Ca témoigne d'une application qui ne libère pas correctement la mémoire à la fin de la session.
Reste maintenant à la localiser ;-)

Merci pour UPHClean, c en effet ce que nous utilisons pour éviter le problème.
Mais nous ne voulons pas le déployer sur les 35 000 machines...

Le SID reste le même...

Merci encore pour toutes tes pistes, on voit que tu gère ton truc ;-)
Comme ça a vu de nez, je dirais Antivirus, ou alors un service qui se lance avec comme compte celui de l'utilisateur, mais ça sent bien l'Antivirus quand même....
Citation :
Publié par Irannia Amarthalion
Chez nous (on est aussi sous sce 10), c'est principalement sur des profils blindés de fichiers temporaires que ça arrive.
Vous avez essayé avec UPHClean ?
Citation :
Publié par Paice
Vous avez essayé avec UPHClean ?
Non, je ne connaissais pas.
C'est relativement rare (on a du avoir une 30aine de cas en 6 mois, pour 8000 utilisateurs, et le dernier il y a 2 mois), le seul point commun qu'on a pu trouver c'était les fichiers temporaires anormalement nombreux (et supprimer ces fichiers rend le profil utilisable).
Si je retrouve un incident résolu ainsi, je regarderai les journaux pour voir si quelque chose me marque après la lecture des liens donnés plus haut.
Merci à tous pour votre aide ;-)
C'est un Svchost qui pose problème, j'essaie de le localiser via le PID, mais c'est plutôt galère d'arriver à reproduire le bug ^^
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés