Connexion au domaine très lente 10+ minutes

16

Nous nous creusons la tête en essayant de comprendre ce problème et nous sommes actuellement coincés!

Fondamentalement, nous avons des problèmes avec certains utilisateurs qui prennent des heures pour se connecter le matin, parfois jusqu'à 20 minutes, nous avons essayé de corriger ce problème en examinant une variété de méthodes, nous avons vérifié le DNS (semble bien, bien que ce ne soit pas mon point le plus fort, j'accepterai des suggestions), la vitesse du réseau vérifiée (semble bien), les utilisateurs en question n'utilisent pas de profils itinérants et il n'y a pas de politiques pointant vers des lecteurs réseau mappés non disponibles.

C'est maintenant un problème majeur car de nombreux utilisateurs se plaignent de pouvoir faire une tasse de café avant que l'ordinateur ne se connecte.

— Daryl Liney
source

3

Avez-vous un serveur ntp et synchronisez-vous toutes vos horloges avec ce serveur ntp? J'ai presque perdu la tête parce que nous n'avions pas de serveur ntp et que toutes nos masques AD étaient légèrement désynchronisées, ce qui entraîne un trafic réseau insensé et des temps d'authentification très longs.

— Harrys Kavan

1

bien que vous ayez mentionné DNS, veuillez vérifier que vos clients pointent vers les services DNS et WINS de votre serveur Windows. Vous pouvez également essayer de configurer les entrées DNS sur un système local. voir le lien pour plus de détails.

— Striker_84

6

Mark Russinovich a d'excellents liens pour résoudre les ouvertures de session lentes . Vous pouvez envisager de commencer par là pour recueillir plus d'informations sur votre problème spécifique.

— jscott

J'ai deux questions sur le problème: êtes-vous sûr de ne pas télécharger l'intégralité du répertoire utilisateur lors de la connexion (fichiers, documents, musique, etc.) à partir du contrôleur de domaine, et pas seulement les fichiers de configuration? La déconnexion est-elle aussi lente?

— Str82DHeaD

Cochez Trafic réseau. Porifle itinérant + gigaoctets de données = ouverture de session lente.

— TomTom

3

Nous avons eu un problème similaire où les postes de travail prenaient environ 10 minutes pour se connecter. Cependant, si le câble réseau était débranché et le PC redémarré, ils se connectaient immédiatement.

Nous avons constaté que les ouvertures de session lentes étaient causées par un pilote d'imprimante qui était en cours d'installation mais qui nécessitait une entrée utilisateur, ce qui ne pouvait évidemment pas être fourni car l'utilisateur n'était pas encore connecté.

Essayez d'activer l'écran de bienvenue détaillé dans GPO. Cela pourrait vous montrer où le PC est bloqué.

— user239341
source

En légère variation de cette solution, j'ai résolu le même problème que l'OP avait en supprimant un élément GP Preference qui tentait d'installer une imprimante qui n'existait plus (plutôt que de nécessiter une entrée utilisateur).

— Je dis Reinstate Monica

2

Vous souhaiterez peut-être tester le paramètre de Registre "BufferPolicyReads". Ce paramètre est activé par défaut dans Windows 7, mais doit être spécifié pour Windows XP.

http://support.microsoft.com/kb/319440

Clé: HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon

Valeur: BufferPolicyReads
Type: DWORD
Valeur: 1

— Greg Askew
source

1

Pour ajouter à ce que d'autres ont publié, je l'ai vu parfois lorsque le DNS des machines clientes est défini sur autre chose qu'un serveur AD (ou un serveur DNS interne), cela est particulièrement vrai si votre domaine local utilise un .com ou. net ou quelque chose qui est dans le domaine DNS public.

— OrganizedChaos
source

5

"this is especially true if your local domain is using a .com or .net or something that is in the Public DNS domain."- Non, c'est faux. Vous devriez être en utilisant le sous - domaine sur un domaine enregistré que vous possédez pour votre AD. Donc, si votre site est, example.comvous devez utiliser quelque chose comme ad.example.compour votre Active Directory. Tant que les clients sont configurés pour utiliser les contrôleurs de domaine pour DNS, il n'y a aucune raison de décourager quiconque d'utiliser un .net, .com, .edu ou tout autre TLD enregistré. En aucun cas vous ne devez jamais utiliser un TLD faux comme .local, .lan ou .corp.

— MDMarra

2

@MDMarra so .... Je suis allé chercher votre réponse pour vous prouver le contraire, car dans le passé, cela était largement considéré comme la meilleure pratique. Je vois que maintenant, il est recommandé d'utiliser un nom DNS public et d'utiliser le sous-domaine comme vous l'avez mentionné, car il est unique. Si votre entreprise devait fusionner, vous n'aurez aucun problème à fusionner deux AD avec le même nom, etc ...

— OrganizedChaos

-3

Essayez netsh int ipv4 reset & netsh winsock reset & ipconfig / flushdns, cela l'a fait dans mon cas

— gonzo
source

1

Cela aiderait si vous fournissiez une raison pour laquelle il devrait exécuter votre script.

— John aka hot2use