Diagnostic des connexions Active Directory lentes

J'ai du mal à diagnostiquer des connexions lentes intermittentes sur les PC du domaine.

Un peu d'informations sur le réseau qui a ce problème:

• Mon domaine s'étend sur 5 sites, tous avec des connexions VPN.
• Les contrôleurs de domaine sont un mélange de 2003, 2008 et 2012. Le niveau fonctionnel du domaine est 2003.
• Les clients sont principalement Windows 7 x64.
• Nous utilisons des stratégies de groupe, y compris celles qui utilisent WMI, le ciblage au niveau de l'élément de préférence de groupe et le déploiement d'imprimante GPP.
• Nous n'utilisons pas de profils itinérants.

Pour la plupart, les connexions fonctionnent correctement et rapidement pour les personnes qui ont déjà utilisé la machine. La première connexion à un nouvel ordinateur est toujours lente, mais c'est normal.

Le problème semble être principalement lié aux ordinateurs portables. S'ils sont utilisés à la maison avec une connexion réseau non-domaine, ou déplacés vers un emplacement différent (toujours sur un réseau de domaine, mais un site AD différent, et ne semblent pas avoir d'importance câblé ou sans fil), les connexions peuvent prendre jusqu'à 3 minutes à partir du moment où l'utilisateur entre son mot de passe, jusqu'au moment où il commence réellement à afficher le bureau. Notre serveur de terminaux connaît également par intermittence des connexions lentes.

Malheureusement, c'est un problème intermittent, et je n'ai trouvé aucun moyen fiable de le reproduire. Je soupçonne que cela a à voir avec les préférences de stratégie de groupe, mais je n'ai pas vraiment de preuve de cela. J'ai vu un article de Microsoft KB blâmer certains types de ciblage au niveau de l'élément pour les connexions lentes, mais il ne donne aucune indication pour déterminer si c'est réellement la cause.

Quels journaux et outils puis-je utiliser pour déterminer la cause des connexions lentes?

Quels paramètres de stratégie de groupe dois-je utiliser ou éviter si possible pour accélérer les connexions?

Fondamentalement, je vais dans la même direction que joeqwerty

J'ai connu les symptômes que vous décrivez dans quelques entreprises. D'après mon expérience, cela se produit généralement lorsqu'il y a plusieurs sites. Une façon de résoudre un problème potentiel avec les sites et les services est la suivante. Sur un ordinateur qui vient de connaître une ouverture de session lente, allez à l'invite de commande, tapez echo% logonserver% Si la réponse n'est pas un serveur sur le même site que l'ordinateur portable ou la station de travail, mon expérience a été que les sous-réseaux ne sont pas configurés et attribués le bon site dans les sites et services Active Directory.

Une autre façon de résoudre les problèmes consiste à consulter ce fichier journal sur vos contrôleurs de domaine% SystemRoot% \ debug \ netlogon.log

Si vous voyez des entrées comme celle-ci, le sous-réseau spécifique doit être entré dans les sites et services et assigné un site.
16/05 22:57:31 [4068] AD: NO_CLIENT_SITE: specificserverhostname 172.16.10.104

Les postes de travail et contrôleurs de domaine Microsoft ont la possibilité de s'assurer qu'ils se rendent sur les bons contrôleurs de domaine pour l'authentification et les stratégies en raison des sites et des services.

Si tel est le cas et que cela entraîne un ajustement des sites et des services, sachez que la réplication des modifications vers / depuis les contrôleurs de domaine peut prendre un certain temps. De plus, il faudra encore plus de temps aux postes de travail pour voir les nouveaux changements. Le temps de réplication par défaut est défini dans les sites et services pendant 1 heure entre les contrôleurs de domaine. En fonction de la distance géographique et de la taille de votre forêt AD, je la règle généralement sur 15 minutes environ.

Une réponse qui pourrait correspondre à la question ou simplement une note pour moi pour plus tard:

Nous avons connu des retards extrêmes sur les connexions pour quelques-uns de nos sous-réseaux. Il s'est avéré que ces sous-réseaux manquaient de zones DNS inversées dans le serveur AD. Nous avons ajouté les zones inversées, AD a ajouté automatiquement les entrées PTR et nous n'avons pas connu de retard depuis. Peut-être aussi une coïncidence.