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 à suivre pour utiliser le script , puis analysez vos problèmes.

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

À propos du script Event1644Reader.ps1

L’ID d’événement Active Directory 1644 est journalisé 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 mises en service par les contrôleurs de domaine Active Directory. L’ID d’événement général 1644 NTDS 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 de l’heure 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 de 1644 événements hébergés dans les journaux d’é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 en cours de service 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.

Note

Le script est attaché dans le billet de blog avec le nom de fichier Event1644Reader.zip

Exclusion de responsabilité du Centre de script
Les exemples de scripts ne sont pas pris en charge dans le cadre d’un programme ou d’un service de support Microsoft standard. Les exemples de scripts sont fournis AS IS sans garantie d’aucune sorte. Microsoft exclut en outre toutes les garanties implicites, y compris, sans limitation, toute garantie implicite de marchandabilité ou d’adéquation à un usage particulier. Tout le risque résultant de l’utilisation ou des performances des exemples de scripts et de la documentation reste avec vous. En aucun cas, Microsoft, ses auteurs ou toute autre personne impliquée dans la création, la production ou la livraison des scripts ne sont responsables de tout dommage que ce soit (y compris, sans limitation, dommages pour perte de bénéfices commerciaux, interruption d’activité, perte d’informations commerciales ou toute autre perte de fonds) résultant de l’utilisation ou de l’incapacité d’utiliser les exemples de scripts ou de documentation, même si Microsoft a été informé de la possibilité de tels dommages.

Prise en charge des pairs en ligne
Pour le support des pairs en ligne, rejoignez le Forum officiel des scripteurs ! Pour fournir des commentaires ou signaler des bogues dans des exemples de scripts, commencez une nouvelle discussion sous l’onglet Discussions pour ce script.

Utilisation du 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 les problèmes de capture améliorée ** 1644 métadonnées d’événement.

    Note

    Windows Server 2012 R2 a ajouté la 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 améliorée des événements 1644 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

    Note

    La définition du détail du journal d’ingénierie des champs sur 5 entraîne la journalisation d’autres événements dans le journal des événements du service d’annuaire. Réinitialisez l’ingénierie de champ sur sa valeur par défaut de 0 lorsque vous ne collectez pas activement 1644 événements. (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 une entrée de Registre particulière n’existe pas, créez une entrée portant ce nom, puis définissez sa valeur sur le seuil souhaité en millisecondes.

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

    Note

    • Lorsque le niveau de journalisation Field Engineering est activé et que l’entrée de Registre de seuil de recherche (msecs) n’est pas utilisée ou est définie sur 0, la valeur par défaut du seuil de temps est de 30 000 millisecondes. (Cette action ne nécessite pas de redémarrage.)
    • Une stratégie consisterait à définir la valeur du Registre pour les paramètres de seuil de résultats de recherche inefficaces et de seuil de résultats de recherche coûteux, puis à mettre l’accent sur les événements identifiés par la conservation du temps de recherche (msecs). Commencez par une valeur supérieure comme 100 millisecondes, puis diminuez la valeur de manière incrémentielle lorsque vous optimisez les requêtes qui se produisent dans votre environnement.
    • Event1644Reader.ps1 peut analyser des événements à partir de plusieurs contrôleurs de domaine. Configurez l’ingénierie de champ, 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 analyseront les fichiers EVTX du service Active Directory enregistrés qui contiennent 1644 événements.

    Cet ordinateur doit disposer de Microsoft Excel 2010 ou d’une version ultérieure et disposer d’un espace disque suffisant pour héberger les journaux des événements du service d’annuaire que le script analyse.

  5. Copiez les journaux des événements du service d’annuaire enregistrés qui contiennent 1644 événements provenant 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 contourner la stratégie d’exécution de PowerShell en fonction des besoins.

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

  9. Lorsque vous voyez l’invite comme 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 situés dans le même répertoire que le fichier Enent1644Reader.ps1.
    • Tapez le drive:\path chemin d’accès qui contient les fichiers EVTX à analyser.

    Note

    Event1644Reader.ps1 analyse les événements 1644 dans tous les journaux d’événements de service d’annuaire de niveau supérieur situés dans le chemin ciblé chaque fois que le script s’exécute.

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

    Note

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

Plus d’informations

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 :

Onglet 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 pour que vous puissiez trier ou filtrer sur n’importe quel en-tête de colonne. Si 1644 journaux d’événements provenant de plusieurs contrôleurs de domaine résident 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 tables croisés dynamiques restantes. Les détails de l’extraction exposent les filtres principaux (par exemple, la requête LDAP), les adresses IP clientes qui ont émis ces requêtes, ainsi que les horodatages de date et d’heure pour 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 un pourcentage de total général. Le pourcentage de total en cours d’exécution vous permet d’identifier les principaux appelants. (Autrement dit, les 10 premiers ou 20 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 des filtres et des étapes de date et d’heure que chaque requête LDAP émise par le client dans un exemple donné.
Top_Filters Répertorie les requêtes LDAP les plus fréquemment émises dans l’ordre décroissant du volume. Cela inclut le temps moyen de recherche. Les détails de l’extraction exposent l’adresse IP du client LDAP et la date et l’heure à laquelle chaque requête a été envoyée.
TotalSearchTime par callers Répertorie les adresses IP clientes dans l’ordre décroissant du temps de recherche total sur toutes les requêtes LDAP dans l’exemple. Les détails de l’extraction identifient les requêtes LDAP et la date et l’heure à laquelle chaque requête a été émise.
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 et la date et l’heure auxquelles chaque requête correspondante a été envoyée.
Classements du temps de 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 quartile se concentre sur ce « compartiment ».
Tableau croisé dynamique vide Il s’agit d’un tableau croisé dynamique vide que vous pouvez modifier en fonction des besoins pour afficher les données spécifiques de votre scénario.

Analyse des scénarios

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 excessivement émises, à des requêtes inefficaces, à une combinaison de ces requêtes, à l’épuisement du pool ATQ (Asynchrone Thread Queue) ou à un grand nombre de 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 pour 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 des requêtes de lots ou LDAP provoquent des arrêts de service, concentrez-vous sur les clients appelants principaux et travaillez pour identifier et éliminer la source de la charge de travail excessive.

Les options possibles pour identifier les applications incluent l’utilisation du suivi PROCMON, ETL/ETW et l’analyse du 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 de l’arrêt des services ou de la suppression d’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 à des contrôleurs de domaine optimaux de site. L’envoi de requêtes LDAP sur le wan introduit la 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 et les définitions de sous-réseau Active Directory 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 aux contrôleurs de domaine de site distant ou aux contrôleurs de domaine accessibles en lecture-écriture uniquement lorsque des contrôleurs de domaine optimaux de site existent.
Collaborez avec les développeurs de logiciels pour réduire la fréquence à laquelle les requêtes sont émises. Cela inclut l’utilisation de la mise en cache. Même efficacement, les requêtes émises peuvent battre un contrôleur de domaine correctement dimensionné et configuré si les requêtes sont émises trop souvent.
Les applications peuvent avoir à limiter leur volume de requête ou à mettre en cache les résultats de requête pour réduire la charge réseau, LDAP et 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 « non » peut améliorer les performances des requêtes.
Envisagez de réduire le nombre d’objets visités en démarrant les requêtes inférieures 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 l’effet secondaire de l’augmentation de la taille de la base de données et peut retarder temporairement la réplication Active Directory pendant la génération d’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 non anglaises.

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 dans 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