Reprise du message précédent :

compare le contenu du fichier (sous XP) "C:\WINDOWS\system32\drivers\etc\lmhosts" des machines qui ne posent aucun soucis avec celles qui ont un problème

C'est exactement le même...
D'ailleurs le problème est réapparu de temps en temps sans raison apparente, notamment sur une machine neuve dont on venait d'installer l'OS... Le simple fait de se relogger sur le domaine à corriger le problème pour un certain temps mais il réapparaitra sans doute un jour comme sur les autres machines...

il doit y avoir une merde sur le fichier de conf de la GPO du domaine...

par contre maintenant à savoir quoi...

il faudrait faire un test de toutes les GPOs et voir celles qui gagnent par rapport aux autres .

En fafouillant partout sur le net, il semblerait que le soucis reviennent à chaque fois que le SP2 de 2k3 server est installé...

j'utilise des machines hors domaine et je n'ai jamais eu de probleme!!!

J'ai eu un soucis un poil semblable il y a peu de temps. J'avais des Users bloqués de la même façon. Je ne suis pas au taf donc je n'ai pas le détail de la solution de suite, je regarderai demain, mais dans l'AD, il y a un calendrier avec des plages d'accès (mois, jours, heures, etc..) au domaine. Je ne sais pas comment cela était arrivé mais dans ce calendrier, étaient apparu des tas de créneaux horaires interdisants l'accès au domaine pendant certaines périodes. Du coup, pas exemple, entre 22h et minuit, certaines UC d'une OU se voyaient refuser l'accès au domaine. A voir dans ton cas...

jm

Ce n'est pas le cas ici, vu que parfois certains peuvent se connecter et d'autres non. Puis après vérification, il n'y a aucune plage de restriction définie.

Par contre il semblerait que j'ai la solution. Il semblerait que ce soit un problème de déchargement du profil lors de la fermeture de la session. Vu que le profil ne se décharge pas complètement, il est endommagé sur la machine et ne peut pas être rouvert sauf si on est connecté au domaine où le profil est reconstruit...

edit : http://support.microsoft.com/kb/837115/fr

C'est ce qu'on a trouvé sur certaines machines dans l'observateur d'évènement mais au début on y a pas fait attention parce qu'on ne pensait pas que c'était lié.

tu as des profils itinérants ???

pas eu le tps de tout lire, le dns est le bon ?

Le DNS est le bon et non je n'ai pas de profil itinérant mais le problème s'applique aussi dans le cas de profil locaux qui ne se déchargent pas correctement...

tu utilises des scripts de connexion ???

oui

ahhhhhhhhh!!!!

script de connexion de type bidule.bat ....

il me semble que sur les net use je mettais des >nul à la fin de la ligne

euh les ">" servent à copier le resultat vers un fichier, mettre un ">nul" revient au même que pas en mettre du tout... non ?

t'as les logs de l'application des GPO ?

t'as touché aux stratégie locales des postes ?
les users sont admin local de leur postes ou pas?

Alors, les users sont admin local de leurs poste en effet.
les stratégies locales n'ont pas été touché hormis celle indiqué dans ce topic (nombre de sessions mise en cache).

Pour les logs des GPO, je ne l'ai pas et je ne pourrais pas les avoirs car je viens de terminer ma mission la bas, je rattaque donc une période de chomage

et pour le >nul : Il permet de rediriger les sorties sur la sortie nulle donc n'affiche rien à l'écran ni ne le met dans un fichier...

ah mais tu cherches quand même la réponse à titre d'info ?

oui pour le >nul mais je vois justement pas trop le rapport avec les soucis de connexion au domaine... ?

Je cherche en effet une réponse à titre informatif. Ca pourrais éventuellement me servir dans un futur boulot.

Pour le >nul, en effet je ne pense pas que ça puisse influencer les connexions, sachant que de toute façon quand ça déconne il n'arrive pas jusque là...

sans pouvoir tester ça risque d'être dur...

ouaip je sais bien