Windows Server 2008 ships with the Reliability and Performance Monitor (RPM) snap-in. On DCs, RPM incorporates an Active Directory Diagnostics feature that includes the abilility to track LDAP searches against a DC. The amount of information captured can be very useful when troubleshooting LDAP issues.
This article provides a step by step guide on how to use RPM to track LDAP searches.
Tracking LDAP activity on a specific DC is not trivial to achieve with the native toolset. A few years back, I posted an article on ActiveDir.org that showed how to log all LDAP activity by enabling diagnostic logging and tweaking the inefficient and expensive LDAP search thresholds. The article is available here:
The problem with the approach shown in that article is its inability to help with LDAP failures. For example, the information logged will not show LDAP failures due to protocol errors.
When troubleshooting an application that is exhibiting LDAP problems another alternative is to trace the activity at the network level using tools such as Ethereal or Microsoft's NetMon. The information available with tracing is certainly detailed, but troubleshooting problems can be a little like finding a needle in a haystack, especially if the data is encrypted over an SSL connection. You could also look at command line tools such as LogMan and TraceRpt.
Windows Server 2008 ships with the Reliability and Performance Monitor, a tool that allows to you easily troubleshoot problematic LDAP searches. This article provides a step-by-step guide on how to leverage this useful feature of the latest version of Windows Server.
Tracking LDAP searches with RPM
Log onto the DC and select Start -> Run and type perfmon in the box.
When the snap-in opens, expand Data Collector Sets and System and then click on Active Directory Diagnostics. Click the green start button on the action bar. This initiates the collection of AD related information on your DC.
While RPM is collecting data, run your LDAP search against the DC. When you have finished click the stop button on the action menu, as shown below.
To view the report of the information you have collected, click the green report button on the action menu.
The report will take some time to generate. On my DC running on a fairly sluggish virtual machine it can take up to a minute. During the wait, you will be presented with the screen shown below.
Once the report has generated, you can dive straight into the Search option by moving down to the Active Directory section and clicking the summary button (highlighted in red below). From the summary window, select Unique Searches.
At this point you should be able to identify the search that you are interested in. Note that the report only shows the “highest 25” searches. Quite what criteria RPM uses to identify the highest 25 searches is not clear, but I assume that it is CPU usage. The report shows a fair amount of detail about each search, as explained in the table below.
Label | Example | Explanation |
Client | 192.168.83.1814 | Client IP address and source port number |
Instance | NTDS | Always NTDS for AD DS. May be different for AD LDS. |
Scope | Deep | LDAP search scope. Will be one of base, one-level or deep (subtree). |
Object Name | DC=ad,DC=fisheagle,DC=net | Search base, i.e. the Distinguished Name of the object from which the base will start. |
Filter Name | (&(objectClass=user)(sn=n*)) | The LDAP search filter used. |
Index | idx_sn:6:N; | The internal index used for the search. In this example, the index for surname (sn) was used. |
Status | 0 | The result of the search. A value indicates that the search completed successfully. |
Visited | 6 | The number of objects visited by the search. |
Found | 6 | The number of objects found by the search. |
Requests/Sec | 0 | The number of requests made per second. Typically, this is 0. |
Response Time (ms) | 1 | The number of milliseconds the search took to complete. |
CPU % | 0 | The percentage of CPU the search used. |
While the HTML report is useful, you also have the option of looking at the raw XML data. To do this, highlight the report in the left hand pane and select View -> Folder.
The right hand pane will then display the files all the files used for the data capture and for the report. The file named report.xml contains the XML content.
Within the XML report file, a search will appear as shown below.
192.168.83.110:1814
NTDS
deep
DC=ad,DC=fisheagle,DC=net
( & (objectClass=user) (sn=n*) )
idx_sn:6:N;
0
6
6
0.020444
1.395700
0.000000
While the example shown above is simple, hopefully you can see the potential for the tool when troubleshooting LDAP issues on a DC. If nothing else, it provides a useful addition to your armoury of troubleshooting and diagnostic tools.
Some background on Reliability and Performance Monitor (RPM)
RPM is a Microsoft Management Console (MMC) snap-in that can be launched either from within Administrative Tools for by running perfmon.msc directly from Start Run. The tool brings together the features of previous stand-alone tools including Performance Logs and Alerts, Server Performance Advisor, and System Monitor. It also provides new functionality in the form of Reliability Monitor, a feature that tracks changes to the system and provides you with a graphical view and a report showing system stability over time.
The SPA heritage
The ability to report the details of LDAP searches made against a DC was provided in a downloadable add-on for Windows Server 2003 called the Server Performance Advisor (SPA). The latest version (2.0) is still available for download at the following URL.
I blogged about how to troubleshot LDAP issues with SPA a few years back. You can find the blog entry here:
Much of the functionality in the Windows Server 2008 Reliability and Performance Monitor appears to be derived from the SPA, although there are some fundamental differences in the look and feel and with some of the features.
0 comments:
Post a Comment