Partager via


Utiliser Event1644Reader.ps1 pour analyser les performances des requêtes LDAP dans Windows Server

Cet article décrit un script qui permet d’analyser l’ID d’événement Active Directory 1644 dans Windows Server. Passez en revue les étapes d’utilisation du script , puis analysez vos problèmes.

Numéro de la base de connaissances d’origine : 3060643

À propos du script Event1644Reader.ps1

L’ID d’événement Active Directory 1644 est enregistré dans le journal des événements du service d’annuaire. Cet événement identifie les recherches LDAP (Lightweight Directory Access Protocol) coûteuses, inefficaces ou lentes qui sont effectuées par des contrôleurs de domaine Active Directory. L’ID d’événement NTDS général 1644 peut être filtré pour enregistrer les recherches LDAP dans le journal des événements des services d’annuaire en fonction du nombre d’objets de la base de données Active Directory qui ont été visités, du nombre d’objets retournés ou du temps d’exécution de la recherche LDAP sur le contrôleur de domaine. Pour plus d’informations sur l’ID d’événement 1644, consultez Correctif logiciel 2800945 ajoute des données de performances au journal des événements Active Directory.

Event1644Reader.ps1 est un script Windows PowerShell qui extrait les données des événements 1644 hébergés dans les journaux des événements du service d’annuaire enregistrés. Ensuite, il importe ces données dans une série de tableaux croisés dynamiques dans une feuille de calcul Microsoft Excel pour aider les administrateurs à obtenir des insights sur les charges de travail LDAP qui sont utilisées par les contrôleurs de domaine et les clients qui génèrent ces requêtes.

Comment obtenir le script

Vous pouvez obtenir le script à partir du billet de blog Core Infrastructure and Security Comment trouver des requêtes LDAP coûteuses, inefficaces et longues dans Active Directory.

Remarque

Le script est joint au billet de blog avec le nom de fichier Event1644Reader.zip

Exclusion de responsabilité du Centre de scripts
Les exemples de scripts ne sont pris en charge dans aucun programme ou service de support standard Microsoft. Les exemples de scripts sont fournis tels quels, sans garantie d’aucune sorte. Microsoft Corporation décline aussi toute garantie implicite, y compris et sans limitation, les garanties implicites de qualité marchande ou d’adéquation à un usage particulier. La totalité des risques découlant de l’utilisation ou de la performance des exemples de scripts et de la documentation repose sur vous. En aucun cas Microsoft, ses auteurs ou quiconque impliqué dans la création, la production ou la livraison des scripts ne sera responsable de tous dommages quels qu’ils soient (y compris, sans limitation, les dommages pour perte de profits, interruption d’activité, perte d’informations commerciales ou toute autre perte pécuniaire) découlant de l’utilisation ou de l’impossibilité d’utiliser les exemples de scripts ou la documentation, même si Microsoft a été informé de la possibilité de tels dommages.

Support par les pairs en ligne
Pour le support par les pairs en ligne, rejoignez le Forum officiel des scripteurs ! Pour fournir des commentaires ou signaler des bogues dans des exemples de scripts, démarrez une nouvelle discussion sous l’onglet Discussions pour ce script.

Comment utiliser le script

Pour mieux analyser les requêtes LDAP capturées dans l’ID d’événement 1644, procédez comme suit :

  1. Assurez-vous que les contrôleurs de domaine que vous résolvez pour résoudre les problèmes capturent les métadonnées d’événement ** 1644 améliorées.

    Remarque

    Windows Server 2012 R2 a ajouté une journalisation des événements 1644 améliorée en enregistrant la durée des requêtes LDAP et d’autres métadonnées. La journalisation des événements 1644 améliorée a été rétroportée vers Windows Server 2012, Windows Server 2008 R2 et Windows Server 2008 par correctif logiciel 2800945.

  2. Définissez la valeur de l’entrée de Registre Field Engineering suivante sur 5 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering

    Remarque

    Si vous définissez le détail du journal d’ingénierie des champs sur 5, d’autres événements seront enregistrés dans le journal des événements du service d’annuaire. Réinitialisez l’ingénierie de champ à sa valeur par défaut 0 lorsque vous ne collectez pas activement les événements 1644. (Cette action ne nécessite pas de redémarrage.)

  3. Si les entrées de Registre suivantes existent, remplacez les valeurs par le seuil souhaité en millisecondes. Si aucune entrée de Registre particulière n’existe, créez une entrée portant ce nom, puis définissez sa valeur sur le seuil souhaité en millisecondes.

    Chemin d’accès du Registre Type de données Valeur par défaut
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search Time Threshold (mss) DWORD 30,000
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Expensive Search Results Threshold DWORD 10 000
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Inefficient Search Results Threshold DWORD 1 000

    Remarque

    • Lorsque le niveau de journalisation Field Engineering est activé et que l’entrée de Registre Seuil de temps de recherche (msecs) n’est pas utilisée ou est définie sur 0, la valeur par défaut du seuil de temps est 30 000 millisecondes. (Cette action ne nécessite pas de redémarrage.)
    • L’une des stratégies consiste à définir la valeur de Registre pour les paramètres de Registre Seuil des résultats de recherche inefficaces et Seuil des résultats de recherche coûteux, puis à se concentrer sur les événements identifiés par la conservation du temps de recherche (mss). Commencez par une valeur plus élevée comme 100 millisecondes, puis réduisez la valeur de manière incrémentielle à mesure que vous optimisez les requêtes qui se produisent dans votre environnement.
    • Event1644Reader.ps1 pouvez analyser des événements à partir de plusieurs contrôleurs de domaine. Configurez l’ingénierie de terrain, le temps de recherche, les paramètres de clé de Registre coûteux et inefficaces sur tous les contrôleurs de domaine sur lesquels vous souhaitez examiner les recherches LDAP.
  4. Téléchargez le fichier Event1644Reader.ps1 à partir de Vous pouvez obtenir le script à partir du billet de blog Core Infrastructure and Security Comment trouver des requêtes LDAP coûteuses, inefficaces et longues dans Active Directory sur l’ordinateur qui analysera les fichiers EVTX du service Active Directory enregistrés contenant 1644 événements.

    Microsoft Excel 2010 ou une version ultérieure doit être installé sur cet ordinateur et doit disposer d’un espace disque suffisant pour héberger les journaux des événements du service d’annuaire que le script analysera.

  5. Copiez les journaux des événements du service d’annuaire enregistrés qui contiennent 1644 événements des contrôleurs de domaine où vous avez activé la journalisation des événements 1644 sur l’ordinateur d’analyse 1644.

  6. Dans l’Explorateur Windows, cliquez avec le bouton droit sur le fichier Event1644Reader.ps1, puis sélectionnez Exécuter avec PowerShell.

    Voici la capture d’écran de cette étape :

    Cliquez avec le bouton droit sur le fichier Event1644Reader.ps1, puis sélectionnez Exécuter avec PowerShell.

  7. Appuyez sur Y pour ignorer la stratégie d’exécution PowerShell si nécessaire.

  8. Spécifiez le chemin des fichiers EVTX à analyser.

  9. Lorsque vous voyez l’invite comme la capture d’écran suivante, effectuez les actions suivantes :

    Commande PowerShell sur l’exécution du fichier Event1644Reader.ps1.

    • Appuyez sur Entrée pour analyser tous les fichiers EVTX qui se trouvent dans le même répertoire que le fichier Enent1644Reader.ps1.
    • Tapez le drive:\path chemin qui contient les fichiers EVTX à analyser.

    Remarque

    Event1644Reader.ps1 analyse les événements 1644 dans tous les journaux des événements du service d’annuaire de niveau supérieur qui se trouvent dans le chemin d’accès ciblé chaque fois que le script s’exécute.

  10. Ouvrez la feuille de calcul pour passer en revue les données et parcourir la série d’onglets, puis enregistrez la feuille de calcul Excel si nécessaire. Pour plus d’informations sur les onglets de la feuille de calcul, consultez la section Procédure pas à pas de la feuille de calcul Excel créée par 1644Reder.ps1 .

    Remarque

    *.csv fichiers générés par l’outil ne sont pas automatiquement supprimés. Envisagez de purger *.csv fichiers une fois votre enquête terminée.

Informations supplémentaires

Procédure pas à pas de la feuille de calcul Excel créée par Event1644Reader.ps1

Event1644Reader.ps1 extrait les métadonnées des événements 1644 dans les journaux des événements du service d’annuaire enregistrés et importe ces données dans une série de feuilles de calcul à onglets dans une feuille de calcul Microsoft Excel.

Le tableau suivant récapitule les données contenues dans chaque onglet :

Tab Description
RawData Chaque champ de données capturé par l’ID d’événement 1644 est importé dans des colonnes discrètes. Le filtrage des données est activé automatiquement afin que vous puissiez trier ou filtrer sur n’importe quel en-tête de colonne. Si les journaux des événements 1644 de plusieurs contrôleurs de domaine se trouvent dans le même répertoire que le script PowerShell ou le répertoire spécifié par l’administrateur, utilisez des filtres pour afficher les requêtes LDAP ciblant des contrôleurs de domaine spécifiques.
Top_StartingNode Fournit une liste triée des partitions d’annuaire ciblées par les requêtes LDAP dans un exemple donné. Si la plupart des requêtes se produisent dans une seule partition (schéma, configuration ou domaine), envisagez d’ajouter cette partition en tant que filtre dans les tableaux croisés dynamiques restants. Les détails de l’extraction exposent les principaux filtres (tels que la requête LDAP), les adresses IP clientes qui ont émis ces requêtes, ainsi que les horodatages de ces requêtes.
Top_Callers Répertorie les adresses IP clientes qui ont émis des requêtes LDAP dans l’ordre décroissant du nombre de recherches avec le pourcentage du total général. Le pourcentage du total en cours d’exécution vous aide à identifier les principaux appelants. (Autrement dit, les 10 ou 20 principaux appelants peuvent générer 80 % du volume de requêtes, en supposant que trop d’appels sont votre problème). Les détails de l’extraction exposent les filtres et les étapes de date et d’heure que chaque client a émis LDAP interroge dans un exemple donné.
Top_Filters Répertorie les requêtes LDAP les plus fréquemment émises dans l’ordre de volume décroissant. Cela inclut le temps de recherche moyen. Les détails d’extraction exposent l’adresse IP du client LDAP ainsi que la date et l’heure d’envoi de chaque requête.
TotalSearchTime par les appelants Répertorie les adresses IP des clients dans l’ordre décroissant du temps de recherche total pour toutes les requêtes LDAP de l’exemple. Les détails de l’extraction identifient les requêtes LDAP et la date et l’heure d’émission de chaque requête.
TotalSearchTime par filtres Répertorie les requêtes LDAP dans l’ordre décroissant du temps de recherche total. Les détails de l’extraction exposent l’adresse IP du client LDAP ainsi que la date et l’heure d’envoi de chaque requête correspondante.
Classements temporels de la recherche Affiche le nombre de requêtes LDAP qui se sont produites dans des quartiles basés sur le temps. Les requêtes plus lentes sont incorrectes. Les requêtes plus rapides sont bonnes si elles ne sont pas émises trop souvent. Microsoft Exchange souhaite que les requêtes LDAP émises par les serveurs Exchange soient résolues en 50 millisecondes ou moins. Ainsi, le premier groupe de quartiles se concentre sur ce « compartiment » de temps.
Tableau croisé dynamique vide Il s’agit d’un tableau croisé dynamique vide que vous pouvez modifier si nécessaire pour afficher les données spécifiques de votre scénario.

Analyse du scénario

Si les requêtes LDAP sont lentes ou si l’utilisation du processeur est élevée sur les contrôleurs de domaine, cela peut être dû à des requêtes émises excessivement, à des requêtes inefficaces, à une combinaison de ces requêtes, à l’épuisement du pool de files d’attente de threads asynchrones (ATQ) ou à de nombreuses notifications de modification.

Si les clients émettent des requêtes LDAP coûteuses, inefficaces ou nombreuses, utilisez Event1644Reader.ps1 pour collecter des données sur les contrôleurs de domaine afin d’identifier les adresses IP des clients. Ensuite, mappez ces requêtes à l’ID de processus, au nom du processus ou à l’application appelante sur les ordinateurs clients.

Le tableau suivant répertorie les optimisations possibles pour ce problème.

Optimisation/atténuation Synopsis
Arrêtez la charge de travail excessive. Si les requêtes par lots ou LDAP provoquent l’arrêt du service, concentrez-vous sur les principaux clients appelants et travaillez à identifier et éliminer la source de la charge de travail excessive.

Les options possibles pour identifier les applications incluent l’utilisation de PROCMON, le suivi ETL/ETW et l’analyse de débogage pour identifier l’application qui génère des requêtes LDAP sur le client. Une autre stratégie consiste à utiliser une approche divisée par deux qui consiste à arrêter les services ou à supprimer les applications qui génèrent des requêtes LDAP. Les requêtes émises peuvent impliquer l’application ou le processus appelant.
Installez un optimiseur de requête LDAP mis à jour. Windows Server 2012 R2 contient un optimiseur de requête LDAP mis à jour qui améliore les performances de la plupart des requêtes. Les sous-ensembles de Windows Server 2012 R2 sont rétroportés vers Windows Server 2008 R2 et Windows Server 2012 dans le correctif logiciel 2862304.
Assurez-vous que les clients envoient des requêtes aux contrôleurs de domaine optimaux du site. L’envoi de requêtes LDAP sur le wan introduit une latence réseau dans la remise de la requête LDAP au contrôleur de domaine et sa réponse au client. Vérifiez que les sites Active Directory et les définitions de sous-réseau existent pour les ordinateurs clients et serveurs dans Active Directory.

Assurez-vous que les applications n’ont pas de références codées en dur à des contrôleurs de domaine de site distants ou à des contrôleurs de domaine accessibles en lecture uniquement lorsqu’il existe des contrôleurs de domaine optimaux pour le site.
Collaborez avec les développeurs de logiciels pour réduire la fréquence d’émission des requêtes. Cela inclut l’utilisation de la mise en cache. Même les requêtes émises efficacement peuvent battre un contrôleur de domaine de taille appropriée et configuré si des requêtes sont émises trop souvent.
Les applications peuvent être amenés à limiter leur volume de requête ou à mettre en cache les résultats des requêtes pour réduire la charge du réseau, du LDAP et du processeur.
Optimisez la requête LDAP pour qu’elle s’exécute plus rapidement. La syntaxe de requête peut être restructurée pour s’exécuter plus rapidement.
Le déplacement d’éléments de requête vers la gauche ou la droite dans le filtre peut améliorer les performances.
L’ajout d’un double « not » peut améliorer les performances des requêtes.
Envisagez de réduire le nombre d’objets visités en démarrant des requêtes plus bas dans l’arborescence.
Réduisez le nombre d’attributs retournés par les requêtes.
Ajoutez des index aux attributs Active Directory en fonction des besoins. L’ajout d’index peut améliorer les performances des requêtes. Cela a pour effet secondaire d’augmenter la taille de la base de données et peut retarder temporairement la réplication Active Directory pendant la génération de l’index.
Déterminez si un défaut de code existe dans l’optimiseur de requête et d’autres composants. Les défauts de l’optimiseur de requête LDAP et d’autres composants peuvent réduire le débit.

Problème connu

Les valeurs de la feuille de calcul Excel ne sont pas affichées ou affichées de manière appropriée sur les ordinateurs qui utilisent des langues autres que l’anglais.

Par exemple, cela se produit sur un ordinateur lorsque l’applet de commande Windows PowerShell Get-Culture indique le paramètre régional comme suit :

PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-Culture  
LCID Name DisplayName  
---- ---- -----------
1031 de-DE German (Germany)

PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-UICulture

LCID Name DisplayName  
---- ---- -----------
1033 en-US English (United States)

Dans ce cas, les nombres de la feuille de calcul Excel sont affichés comme dans la capture d’écran suivante :

Nombres dans le problème de feuille de calcul Excel.

Pour résoudre ce problème, remplacez le symbole Décimal par un point (.) dans l’élément Paramètres de région du Panneau de configuration.

Pour plus d’informations sur les requêtes LDAP, consultez le blog suivant : Comment trouver des requêtes LDAP coûteuses, inefficaces et longues dans Active Directory