Freigeben über

Verwenden von Event1644Reader.ps1 zum Analysieren der LDAP-Abfrageleistung in Windows Server

  • Artikel

In diesem Artikel wird ein Skript beschrieben, das bei der Analyse der Active Directory-Ereignis-ID 1644 in Windows Server hilft. Überprüfen Sie die Schritte zum Verwenden des Skripts , und analysieren Sie dann Ihre Probleme.

Ursprüngliche KB-Nummer: 3060643

Informationen zum Skript "Event1644Reader.ps1"

Die Active Directory-Ereignis-ID 1644 wird im Verzeichnisdienst-Ereignisprotokoll protokolliert. Dieses Ereignis identifiziert teure, ineffiziente oder langsame LDAP-Suchvorgänge (Lightweight Directory Access Protocol), die von Active Directory-Domänencontrollern gewartet werden. NTDS General event ID 1644 can be filtered to record LDAP searches in the Directory Services event log based on the number of objects in the Active Directory database that were visited, the number of objects that were returned, or the LDAP search execution time on the domain controller. Weitere Informationen zur Ereignis-ID 1644 finden Sie unter Hotfix 2800945 fügt Leistungsdaten zum Active Directory-Ereignisprotokoll hinzu.

Event1644Reader.ps1 ist ein Windows PowerShell-Skript, das Daten aus 1644-Ereignissen extrahiert, die in gespeicherten Verzeichnisdienst-Ereignisprotokollen gehostet werden. Anschließend importiert sie diese Daten in eine Reihe von PivotTables in einer Microsoft Excel-Kalkulationstabelle, damit Administratoren Einblicke in die LDAP-Workloads erhalten, die von den Domänencontrollern und Clients gewartet werden, die diese Abfragen generieren.

Abrufen des Skripts

Sie können das Skript aus dem Blogbeitrag "Core Infrastructure and Security" abrufen, wie Sie teure, ineffiziente und lange ausgeführte LDAP-Abfragen in Active Directory finden.

Notiz

Das Skript ist im Blogbeitrag mit dem Dateinamen Event1644Reader.zip

Skriptcenter-Haftungsausschluss
Die Beispielskripts werden unter keinem Microsoft-Standardsupportprogramm oder -dienst unterstützt. Die Beispielskripts werden AS IS ohne Jegliche Garantie bereitgestellt. Microsoft lehnt weiterhin alle konkludenten Garantien ab, einschließlich, ohne Einschränkung, jegliche konkludente Gewährleistung der Handelsmöglichkeit oder der Eignung für einen bestimmten Zweck. Das gesamte Risiko, das sich aus der Verwendung oder Leistung der Beispielskripts und dokumentation ergibt, bleibt bei Ihnen. In keinem Fall haftet Microsoft, seine Autoren oder sonstigen Personen, die an der Erstellung, Produktion oder Lieferung der Skripts beteiligt sind, für jegliche Schäden (einschließlich, ohne Einschränkung, Schäden für Verlust von Geschäftsgewinnen, Geschäftsunterbrechungen, Verlust von Geschäftsinformationen oder anderen unbestimmten Verlusten), die sich aus der Verwendung oder Unfähigkeit ergeben, die Beispielskripts oder Dokumentation zu verwenden, auch wenn Microsoft über die Möglichkeit solcher Schäden informiert wurde.

Online-Peerunterstützung
Für Online-Peer-Support, treten Sie dem offiziellen Scripting Guys Forum bei ! Um Feedback zu geben oder Fehler in Beispielskripts zu melden, beginnen Sie eine neue Diskussion auf der Registerkarte "Diskussionen " für dieses Skript.

Verwendung des Skripts

Führen Sie die folgenden Schritte aus, um die LDAP-Abfragen besser zu analysieren, die in der Ereignis-ID 1644 erfasst werden:

  1. Stellen Sie sicher, dass die Domänencontroller, für die Sie die Problembehandlung durchführen, erweiterte ** 1644-Ereignismetadaten erfassen.

    Notiz

    Windows Server 2012 R2 hat die Erweiterte 1644-Ereignisprotokollierung hinzugefügt, indem die Dauer von LDAP-Abfragen und anderen Metadaten aufgezeichnet wird. Die erweiterte Ereignisprotokollierung 1644 wurde durch Hotfix 2800945 zu Windows Server 2012, Windows Server 2008 R2 und Windows Server 2008 zurückportiert.

  2. Legen Sie den Wert des folgenden Field Engineering-Registrierungseintrags auf 5 fest: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering

    Notiz

    Das Festlegen der Ausführlichkeit des Feld engineering-Protokolls auf 5 führt dazu, dass andere Ereignisse im Verzeichnisdienstereignisprotokoll protokolliert werden. Setzen Sie Feldtechnik wieder auf den Standardwert 0 zurück, wenn Sie nicht aktiv 1644 Ereignisse sammeln. (Für diese Aktion ist kein Neustart erforderlich.)

  3. Wenn die folgenden Registrierungseinträge vorhanden sind, ändern Sie die Werte in Millisekunden in den gewünschten Schwellenwert. Wenn kein bestimmter Registrierungseintrag vorhanden ist, erstellen Sie einen neuen Eintrag mit diesem Namen, und legen Sie dann seinen Wert in Millisekunden auf den gewünschten Schwellenwert fest.

    Registrierungspfad Datentyp Standardwert
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search Time Threshold (msecs) DWORD 30.000
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Teuren Schwellenwert für Suchergebnisse DWORD 10.000
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Ineffizienter Schwellenwert für Suchergebnisse DWORD 1.000

    Notiz

    • Wenn die Feldtechnikprotokollierungsebene aktiviert ist und der Registrierungseintrag für den Suchzeitschwellenwert (msecs) nicht verwendet oder auf 0 festgelegt ist, beträgt der Standardwert des Zeitschwellenwerts 30.000 Millisekunden. (Für diese Aktion ist kein Neustart erforderlich.)
    • Eine Strategie wäre das Festlegen des Registrierungswerts sowohl für die Registrierungseinstellungen für ineffiziente Suchergebnisse als auch für teure Registrierungseinstellungen für Suchergebnisse, und konzentrieren Sie sich dann auf Ereignisse, die durch den Suchzeit-Haltepunkt (msecs) identifiziert werden. Beginnen Sie mit einem größeren Wert wie 100 Millisekunden, und verringern Sie dann den Wert inkrementell, während Sie die Abfragen optimieren, die in Ihrer Umgebung auftreten.
    • Event1644Reader.ps1 kann Ereignisse von mehreren Domänencontrollern analysieren. Konfigurieren Sie die Feldtechnik, suchzeit, teuer und ineffiziente Registrierungsschlüsseleinstellungen für alle Domänencontroller, auf denen Sie LDAP-Suchen überprüfen möchten.

  4. Laden Sie die Datei Event1644Reader.ps1 von Sie können das Skript aus dem Blogbeitrag Core Infrastructure and Security Abrufen, wie Sie teure, ineffiziente und lange ausgeführte LDAP-Abfragen in Active Directory auf den Computer finden, der gespeicherte Active Directory-Dienst EVTX-Dateien analysiert, die 1644 Ereignisse enthalten.

    Auf diesem Computer sollte Microsoft Excel 2010 oder eine höhere Version installiert sein und über ausreichend Speicherplatz verfügen, um die Verzeichnisdienstereignisprotokolle zu hosten, die das Skript analysiert.

  5. Kopieren Sie gespeicherte Verzeichnisdienst-Ereignisprotokolle, die 1644 Ereignisse von den Domänencontrollern enthalten, auf denen Sie die Ereignisprotokollierung von 1644 auf dem 1644-Analysecomputer aktiviert haben.

  6. Klicken Sie im Windows-Explorer mit der rechten Maustaste auf die Datei "Event1644Reader.ps1", und wählen Sie dann "Mit PowerShell ausführen" aus.

    Im Folgenden sehen Sie den Screenshot für diesen Schritt:

    Klicken Sie mit der rechten Maustaste auf die Datei

  7. Drücken Sie Y, um die PowerShell-Ausführungsrichtlinie nach Bedarf zu umgehen.

  8. Geben Sie den Pfad der zu analysierenden EVTX-Dateien an.

  9. Wenn die Eingabeaufforderung als folgenden Screenshot angezeigt wird, führen Sie die folgenden Aktionen aus:

    PowerShell-Befehl zum Ausführen der Datei

    • Drücken Sie die EINGABETASTE, um alle EVTX-Dateien zu analysieren, die sich im selben Verzeichnis befinden wie die Datei "Enent1644Reader.ps1".
    • Geben Sie den drive:\path Pfad ein, der die zu analysierenden EVTX-Dateien enthält.

    Notiz

    Event1644Reader.ps1 analysiert 1644-Ereignisse in allen Verzeichnisdienstereignisprotokollen auf oberster Ebene, die sich jedes Mal, wenn das Skript ausgeführt wird, im Zielpfad befinden.

  10. Öffnen Sie das Arbeitsblatt, um Daten zu überprüfen und die Reihe von Registerkarten zu durchlaufen, und speichern Sie dann die Excel-Tabelle nach Bedarf. Weitere Informationen zu den Registerkarten im Arbeitsblatt finden Sie im Abschnitt "Walkthrough of the Excel spreadsheet created by 1644Reder.ps1 ".

    Notiz

    *.csv Dateien, die vom Tool erstellt werden, werden nicht automatisch entfernt. Erwägen Sie, *.csv Dateien nach Abschluss der Untersuchung zu löschen.

Weitere Informationen

Walkthrough of the Excel spreadsheet that is created by Event1644Reader.ps1

Event1644Reader.ps1 extrahiert Metadaten aus 1644 Ereignissen in gespeicherten Verzeichnisdienst-Ereignisprotokollen und importiert diese Daten in eine Reihe von Tabellenarbeitsblättern in einer Microsoft Excel-Kalkulationstabelle.

In der folgenden Tabelle sind die Daten zusammengefasst, die auf den einzelnen Registerkarten enthalten sind:

Tab Beschreibung
RawData Jedes Datenfeld, das von der Ereignis-ID 1644 erfasst wird, wird in separate Spalten importiert. Die Datenfilterung ist automatisch aktiviert, sodass Sie nach spaltenüberschriften sortieren oder filtern können. Wenn sich 1644 Ereignisprotokolle von mehreren Domänencontrollern im selben Verzeichnis wie das PowerShell-Skript oder das vom Administrator angegebene Verzeichnis befinden, verwenden Sie Filter, um LDAP-Abfragen anzuzeigen, die auf bestimmte Domänencontroller abzielen.
Top_StartingNode Stellt eine sortierte Liste der Verzeichnispartitionen bereit, die auf LDAP-Abfragen in einem bestimmten Beispiel ausgerichtet sind. Wenn die meisten Abfragen in einer einzelnen Partition (Schema, Konfiguration oder Domäne) auftreten, sollten Sie diese Partition als Filter in den verbleibenden PivotTables hinzufügen. Drillthrough-Detail macht die wichtigsten Filter (z. B. die LDAP-Abfrage), die Client-IPs, die diese Abfragen ausgestellt haben, sowie die Datums- und Zeitstempel für diese Abfragen verfügbar.
Top_Callers Listet Client-IP-Adressen auf, die LDAP-Abfragen in absteigender Suchanzahlreihenfolge mit prozentualer Gesamtsumme ausgegeben haben. Der Prozentsatz der laufenden Summe hilft Ihnen bei der Identifizierung der wichtigsten Anrufer. (Das heißt, die 10 oder 20 wichtigsten Aufrufer generieren möglicherweise 80 Prozent des Abfragevolumens, vorausgesetzt, dass zu viele Anrufe Ihr Problem sind). Drillthrough-Detail macht Filter und Datums- und Uhrzeitschritte verfügbar, die von den einzelnen Client ausgestellten LDAP-Abfragen in einem bestimmten Beispiel ausgeführt werden.
Top_Filters Listet die am häufigsten ausgestellten LDAP-Abfragen in absteigender Volumenreihenfolge auf. Dies schließt die durchschnittliche Suchzeit ein. Drillthrough-Detail macht die IP-Adresse des LDAP-Clients und das Datum und die Uhrzeit der Übermittlung jeder Abfrage verfügbar.
TotalSearchTime nach Anrufern Listet Client-IP-Adressen in absteigender Reihenfolge der Gesamtsuchzeit für alle LDAP-Abfragen im Beispiel auf. Drillthrough-Detail identifiziert die LDAP-Abfragen und das Datum und die Uhrzeit, zu der jede Abfrage ausgestellt wurde.
TotalSearchTime nach Filtern Listet LDAP-Abfragen in absteigender Reihenfolge der Gesamtsuchzeit auf. Drillthrough-Detail macht die IP-Adresse des LDAP-Clients sowie das Datum und die Uhrzeit der Übermittlung jeder übereinstimmenden Abfrage verfügbar.
Suchzeitbewertungen Zeigt die Anzahl der LDAP-Abfragen an, die in zeitbasierten Quartilen aufgetreten sind. Langsamere Abfragen sind schlecht. Schnellere Abfragen sind gut, wenn sie nicht zu oft ausgegeben werden. Microsoft Exchange möchte LDAP-Abfragen, die von Exchange-Servern ausgegeben werden, in 50 Millisekunden oder weniger aufgelöst werden. Daher konzentriert sich die erste Quartilgruppe auf diese Zeit "Bucket".
Leeres Pivot Dies ist eine leere Pivottable, die Sie nach Bedarf ändern können, um die spezifischen Daten für Ihr Szenario anzuzeigen.

Szenarioanalyse

Wenn LDAP-Abfragen langsam sind oder die CPU-Auslastung auf Domänencontrollern hoch ist, kann dies durch übermäßig ausgestellte Abfragen, ineffiziente Abfragen, eine Kombination dieser Abfragen, die Ausschöpfung des Asynchronen Threadwarteschlangenpools (ATQ) oder viele Änderungsbenachrichtigungen verursacht werden.

Wenn Clients teure, ineffiziente oder viele LDAP-Abfragen ausgeben, verwenden Sie Event1644Reader.ps1, um Daten auf den Domänencontrollern zu sammeln, um die IP-Adressen der Clients zu identifizieren. Ordnen Sie diese Abfragen dann der Prozess-ID, dem Prozessnamen oder der aufrufenden Anwendung auf den Clientcomputern zu.

In der folgenden Tabelle sind die möglichen Optimierungen für dieses Problem aufgeführt.

Optimierung/Entschärfung Übersicht
Beenden Sie die übermäßige Arbeitsauslastung. Wenn viele oder LDAP-Abfragen zu Dienststopps führen, konzentrieren Sie sich auf die wichtigsten Anrufclients, und arbeiten Sie daran, die Quelle der übermäßigen Arbeitsauslastung zu identifizieren und zu beseitigen.

Mögliche Optionen zum Identifizieren von Anwendungen sind die Verwendung von PROCMON, ETL/ETW-Ablaufverfolgung und Debuganalyse, um die Anwendung zu identifizieren, die LDAP-Abfragen auf dem Client generiert. Eine weitere Strategie besteht darin, einen Divid-by-Two-Ansatz zu verwenden, um Dienste aufzuteilen oder Anwendungen zu entfernen, die LDAP-Abfragen generieren. Die ausgestellten Abfragen können die aufrufende Anwendung oder den aufruften Prozess inplizieren.
Installieren Sie einen aktualisierten LDAP-Abfrageoptimierer. Windows Server 2012 R2 enthält einen aktualisierten LDAP-Abfrageoptimierer, der die Leistung für die meisten Abfragen verbessert. Teilmengen der Windows Server 2012 R2 werden in Hotfix-2862304 zu Windows Server 2008 R2 und Windows Server 2012 zurückportiert.
Stellen Sie sicher, dass Clients Abfragen an standortoptimale Domänencontroller übermitteln. Das Senden von LDAP-Abfragen über das WAN führt zur Netzwerklatenz bei der Übermittlung der LDAP-Abfrage an den Domänencontroller und seine Antwort auf den Client. Stellen Sie sicher, dass Active Directory-Standorte und Subnetzdefinitionen für Client- und Servercomputer in Active Directory vorhanden sind.

Stellen Sie sicher, dass Anwendungen keine hartcodierten Verweise auf Remote-Site-Domänencontroller oder schreibgeschützte Domänencontroller haben, wenn standortoptimale Domänencontroller vorhanden sind.
Arbeiten Sie mit Softwareentwicklern zusammen, um die Häufigkeit zu verringern, mit der Abfragen ausgegeben werden. Dazu gehört auch die Verwendung der Zwischenspeicherung. Selbst effizient ausgestellte Abfragen können einen entsprechend großen und konfigurierten Domänencontroller schlagen, wenn Abfragen zu häufig ausgegeben werden.
Anwendungen müssen möglicherweise ihr Abfragevolume oder Abfrageergebnisse zwischenspeichern, um die Netzwerk-, LDAP- und CPU-Auslastung zu reduzieren.
Optimieren Sie die LDAP-Abfrage, um sie schneller auszuführen. Die Abfragesyntax muss möglicherweise umstrukturiert werden, damit sie schneller ausgeführt werden kann.
Das Verschieben von Abfrageelementen nach links oder rechts innerhalb des Filters kann die Leistung verbessern.
Durch das Hinzufügen eines doppelten "Nicht" kann die Abfrageleistung verbessert werden.
Erwägen Sie, die Anzahl der Objekte zu verringern, die besucht werden, indem Sie Abfragen in der Struktur beginnen.
Verringern Sie die Anzahl der Attribute, die von Abfragen zurückgegeben werden.
Fügen Sie Indizes nach Bedarf zu Active Directory-Attributen hinzu. Das Hinzufügen von Indizes kann die Abfrageleistung verbessern. Dies hat den Nebeneffekt, die Datenbankgröße zu erhöhen, und kann die Active Directory-Replikation während des Indexbuilds vorübergehend verzögern.
Ermitteln Sie, ob ein Codefehler im Abfrageoptimierer und anderen Komponenten vorhanden ist. Fehler im LDAP-Abfrageoptimierer und andere Komponenten können den Durchsatz reduzieren.

Bekanntes Problem

Die Werte in der Excel-Kalkulationstabelle werden nicht auf Computern angezeigt oder ordnungsgemäß gerendert, auf denen nicht englische Sprachen verwendet werden.

Dies tritt beispielsweise auf einem Computer auf, wenn das Windows PowerShell-Cmdlet "Get-Culture" die regionale Einstellung wie folgt angibt:

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)

In dieser Situation werden Zahlen in der Excel-Tabelle wie im folgenden Screenshot gerendert:

Zahlen im Excel-Tabellenkalkulationsproblem.

Um dieses Problem zu beheben, ändern Sie das Dezimalsymbol in ein Punkt (.) im Regionseinstellungselement in Systemsteuerung.

Weitere Informationen zu LDAP-Abfragen finden Sie im folgenden Blog: So finden Sie teure, ineffiziente und lange ausgeführte LDAP-Abfragen in Active Directory