How to use Event1644Reader.ps1 to analyze LDAP query performance in Windows Server
About the Event1644Reader.ps1 script
Event1644Reader.ps1 is a Windows PowerShell script that extracts data from 1644 events that are hosted in saved Directory Service event logs. Then, it imports that data into a series of pivot tables in a Microsoft Excel spreadsheet to help administrators gain insights about the LDAP workloads that are being serviced by the domain controllers and clients that are generating those queries.
How to obtain the script
Script Center disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Online peer support
For online peer support, join The Official Scripting Guys Forum! To provide feedback or report bugs in sample scripts, please start a new discussion on the Discussions tab for this script.
How to use the script
- Make sure that the domain controllers that you are troubleshooting capture enhanced1644 event metadata.
Note Windows Server 2012 R2 added enhanced 1644 event logging by recording the duration of LDAP queries and other metadata. The enhanced 1644 event logging was backported to Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008 by hotfix 2800945.
- Set the value of the following Field Engineering registry entry to 5:Note Setting field engineering log verbosity to 5 will cause other events to be logged in the directory service event log. Reset field engineering back to its default value of 0 when you are not actively collecting 1644 events. (This action does not require a restart.)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering
- If the following registry entries exist, change the values to the desired threshold in milliseconds. If a particular registry entry does not exist, create a new entry with that name, and then set its value to the desired threshold in milliseconds.Notes
Registry path Data type Default value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search Time Threshold (msecs) 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
- When the Field Engineering logging level is enabled and the Search Time Threshold (msecs) registry entry is not used or is set to 0, the default value of the time threshold is 30,000 milliseconds. (This action does not require a restart.)
- One strategy would be to set the registry value for both the Inefficient Search Results Threshold and Expensive Search Results Threshold registry settings, and then focus on events that are identified by Search Time hold (msecs). Start with a larger value like 100 milliseconds and then incrementally decrease the value as you optimize the queries that are occurring in your environment.
- Event1644Reader.ps1 can parse events from multiple domain controllers. Configure the field engineering, search time, expensive, and inefficient registry key settings on all domain controllers on which you want to review LDAP searches.
- Download the Event1644Reader.ps1 file from Microsoft Script Center to the computer that will analyze saved Active Directory Service EVTX files that contain 1644 events.
This computer should have Microsoft Excel 2010 or a later version installed and should have sufficient disk space to host the directory service event logs that the script will parse.
- Copy saved Directory Service event logs that contain 1644 events from the domain controllers where you enabled 1644 event logging to the 1644 analysis computer.
- In Windows Explorer, right-click the Event1644Reader.ps1 file,and then select Run with PowerShell.
The following is the screen shot for this step:
- Press Y to bypass PowerShell Execution Policy as required.
- Specify the path of the EVTX files to be parsed.
- When you see the prompt as the following screen shot, take the following actions:
- Press Enter to parse all EVTX files that are located in the same directory as the Enent1644Reader.ps1 file.
- Type the drive:\path path that contains the EVTX files to be parsed.
Note Event1644Reader.ps1 parses 1644 events in all up-level directory service event logs that are located in the targeted path every time that the script runs.
- Open the worksheet to review data and walk through the series of tabs, and then save the Excel spreadsheet as required. For more information about the tabs in the worksheet, see the "Walkthrough of the Excel spreadsheet created by 1644Reder.ps1" section.
Walkthrough of the Excel spreadsheet that is created by Event1644Reader.ps1
The following table summarizes the data that is contained in each tab:
|RawData||Each data field that is captured by event ID 1644 is imported into discrete columns. Data Filtering is auto-enabled so that you can sort or filter on any column header. If 1644 event logs from multiple domain controllers resided in the same directory as the PowerShell script or the admin-specified directory, use filters to view LDAP queries that are targeting specific domain controllers.|
|Top_StartingNode||Provides a sorted list of the directory partitions that are targeted by LDAP queries in a given sample. If most of the queries are occurring in a single partition (schema, configuration, or domain), consider adding that partition as a filter in the remaining pivot tables. Drillthrough detail exposes the top filters (such as the LDAP query), the client IPs that issued those queries, and the date and time stamps for those queries.|
|Top_Callers||Lists client IP addresses that issued LDAP queries in descending search count order with percentage of grand total. Percentage of running total helps you identify top callers. (That is, the top 10 or 20 callers may be generating 80 percent of the query volume, assuming that too many calls are your problem). Drillthrough detail exposes filters and date and time steps that each client-issued LDAP queries in a given sample.|
|Top_Filters||Lists most frequently issued LDAP queries in descending volume order. This includes average search time. Drillthrough detail exposes the LDAP client's IP address and the date and time when each query was submitted.|
|TotalSearchTime by Callers||Lists client IP addresses in descending order of total search time across all LDAP queries in the sample. Drillthrough detail identifies the LDAP queries and the date and time when each query was issued.|
|TotalSearchTime by Filters||Lists LDAP queries in descending order of total search time. Drillthrough detail exposes the LDAP client's IP address and the date and time when each matching query was submitted.|
|Search time ranks||Displays the number of LDAP queries that occurred in time-based quartiles. Slower queries are bad. Faster queries are good if they aren't issued too often. Microsoft Exchange wants LDAP queries that are issued by Exchange servers to be resolved in 50 milliseconds or less. So, the first quartile group focuses on that time "bucket."|
|Blank Pivot||This is a blank pivot table that you can change as required to show the specific data for your scenario.|
If clients issue expensive, inefficient, or lots of LDAP queries, use Event1644Reader.ps1 to collect data on the domain controllers to identify the IP addresses of the clients. Then, map such queries to the process ID, the process name, or the calling application on the client computers.
The following table lists the possible optimizations for this issue.
|Stop the excessive workload.||If lots or LDAP queries cause service stops, focus on top calling clients, and work to identify and eliminate the source of the excessive workload. |
Possible options to identify applications include using PROCMON, ETL/ETW tracing, and debug analysis to identify the application that generates LDAP queries on the client. Another strategy is to use a divide-by-two approach of either topping services or removing applications that are generating LDAP queries. The issued queries may implicate the calling application or process.
|Install an updated LDAP query optimizer.||Windows Server 2012 R2 contains an updated LDAP query optimizer that improves performance for most queries. Subsets of the Windows Server 2012 R2 are backported to Windows Server 2008 R2 and Windows Server 2012 in hotfix 2862304.|
|Make sure that clients are submitting queries to site-optimal domain controllers.||Sending LDAP queries across the WAN introduces network latency into the delivery of the LDAP query to the domain controller and its reply to the client. Make sure that Active Directory sites and subnet definitions exist for client and server computers in Active Directory.|
Make sure that applications do not have hard-coded references to remote-site domain controllers or to read-writable domain controllers only when site-optimal domain controllers exist.
|Work with software developers to reduce the frequency at which queries are issued. This includes the use of caching.||Even efficiently issued queries can beat down an appropriately sized and configured domain controller if queries are issued too often. |
Applications may have to throttle their query volume or cache query results to reduce network, LDAP, and CPU load.
|Optimize the LDAP query to execute more quickly.||Query syntax may have to be restructured to execute more quickly. |
Moving query elements to the left or right within the filter can improve performance.
Adding a double "not" may improve query performance.
Consider reducing the number of objects that are visited by starting queries lower in the tree.
Reduce the number of attributes that are being returned by queries.
|Add indexes to Active Directory attributes as required.||Adding indexes can improve query performance. This has the side effect of increasing database size and may temporarily delay Active Directory replication during index build.|
|Determine whether a code defect exists in the query optimizer and other components.||Defects in the LDAP query optimizer and other components can reduce throughput.|
For example, this occurs on a computer when the Get-Culture Windows PowerShell cmdlet indicates the regional setting as follows:
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-UICultureLCID Name DisplayName ---- ---- -----------1033 en-US English (United States)In this situation, numbers in the Excel spreadsheet are rendered as in the following screen shot:
To resolve this issue, change the Decimal symbol to a period (.) in the Region settings item in Control Panel.
For more information about LDAP queries, see the following blog:
Article ID: 3060643 - Last Review: 09/24/2015 18:06:00 - Revision: 7.0
- kbprb kbtshoot kbexpertiseadvanced kbsurveynew KB3060643