SolutionBase: Discover Active Directory performance problems with Performance Monitor

If you suspect performance problems with Active Directory, an easy way to check it is with the Performance Monitor. In this article, Brien Posey shows you the counters you need to track and what to look for.

There are many factors that can impact Active Directory's performance. The key is just finding out what's causing things to go so slowly. In this article, I'll explain how you can use the Performance Monitor to gain a better understanding of the factors that are affecting the Active Directory's performance.

Before I begin

In this article, I will be making extensive use of the Windows Performance Monitor. Before I jump right in and start talking about which counters you should be monitoring, I want to go over a few performance monitoring best practices. The best practices that I am going to go over don't always apply to every performance monitoring session, but they do apply to this article.

The Uncertainty Principle in physics states that it is impossible to measure something without affecting it to some degree. Nowhere is this more true than with Performance Monitoring. When following the techniques in this article, you will be monitoring systems that are already having performance problems. The monitoring process is only going to make those performance problems worse because resources such as memory, CPU time, disk space, and disk time are used by the Performance Monitor.

That being the case, you should start out by taking some steps to lighten the existing load on the servers that you will be monitoring. The easiest way to reduce the system's workload is to disable the screen saver and any services that are not absolutely necessary. Be sure to make note of what you have disabled though. It's possible that the Performance monitor may not reveal any performance problems. If that happens, then one possible cause is that something that you disabled was causing the performance problem.

Another step that I recommend taking in preparation for the monitoring process is to increase the amount of virtual memory that is available to the servers that you will be monitoring. The minimum amount of virtual memory that any of the servers should have is one and a half times the amount of physical memory in the machine. Therefore, if the server has a gigabyte of RAM, then you will want to make sure that the machine's virtual memory is set to a minimum size of 1.5 GB.

The last thing that I want to talk about in regards to the monitoring process is that you need to conduct the performance monitoring session in a way that minimizes the amount of monitoring related overhead placed on the server that's being monitored. Unless your network is short on bandwidth, or there is a WAN link between you and the server that you are monitoring, I recommend monitoring the machine remotely. This means that you actually run Performance Monitor on a workstation, but tell it to monitor one of your servers. The advantage of doing this is that it will conserve both memory and processing power on the server that you are monitoring because you are not running the Performance Monitor user interface directly on that machine.

I was hesitant the first time that someone gave me this advice, so I decided to do some benchmark testing of my own, and there really is a noticeable difference when Performance Monitor is run remotely. You should not however run Performance Monitor remotely if you have issues with low bandwidth, or if you are trying to measure network traffic or network throughput.

If you find that you need to run Performance Monitor locally, then one way that you can minimize its impact is to log data to a hard disk that is not going to be affected by the monitoring process. For example, if the server that you are monitoring acts as both a domain controller and a file server, then you know that which ever drive contains the Active Directory database (C:\NTDS by default) is going to be heavily used. Therefore, if D: is only storing user files, then that might be a good place to log the collected data.

Regardless of whether you are monitoring the server remotely or locally, I recommend adjusting the update interval so that you are sampling the counter data at no more than once every three seconds. Performance Monitor usually samples counters once a second by default, but decreasing the sampling rate will greatly decrease Performance Monitor's impact on the system and give you a more realistic reading.

One last tip that I have for you is that you should refrain from monitoring more than three or four counters at a time. The fewer counters you are monitoring simultaneously, the more accurate the results are going to be.

The Directory Service

Now that I have given you some best practices that you can use to get greater accuracy on your measurements, it's time to get down to business by talking about some Performance Monitor counters that are associated with the Directory Service. Directory Service related counters are located within the NTDS performance object. There are dozens of Directory Service related counters available, but there are only about ten counters that you really need to pay attention to.

  • DRA Inbound Bytes Total / Sec - This counter shows the number of bytes received through inbound Active Directory related replication. If this number is consistently equal to zero, it means that replication is not occurring. Low numbers may indicate that there is a network bottleneck or that the server's NIC is too busy with other traffic to receive the requests in a timely manner.
  • DRA Inbound Object Updates Remaining in Packet - This counter displays the number of Active Directory objects that have been received through replication, but that have not yet been applied. This number may start high, but should diminish very quickly. If this value takes a while to diminish, it is a clue that the server's hardware might not be fast enough to keep up with the demand.
  • DRA Outbound Bytes Total / Sec - This counter displays the total number of bytes (compressed and uncompressed) that are being transmitted each second as a result of the replication process. A lack of activity often indicates insufficient hardware.
  • DRA Pending Replication Synchronization - This number indicates the number of objects which must be synchronized. Like the DRA Inbound Object Updated Remaining in Packet counter, this value may start high, but should quickly dissipate. If this counter's value remains high, it usually means that the hardware is having trouble keeping pace with the demands being made of it.
  • DS Threads in Use - This counter indicates the number of threads that are currently servicing client API calls. You can use this value to determine whether or not the domain controller could benefit from additional processors.
  • Kerberos Authentications - The value from this counter indicates the number of times each second that clients use a ticket to authenticate to the domain controller. A lack of activity sometimes indicates that network problems are preventing requests from reaching the domain controller.
  • LDAP Bind Time - This counter indicates the number of milliseconds that the last successful LDAP bind took to complete. This value should remain consistently low. Longer bind times can be an indication of network problems or of hardware that needs to be upgraded.
  • LDAP Client Sessions - This number indicates the number of LDAP sessions that are connected to the domain controller at the moment. The appropriate value depends on your network, but if this value remains at zero, it means that you probably have some network problems that are preventing client sessions from connecting with the server.
  • LDAP Searches / Sec - The LDAP Searches / Sec counter indicates the number of LDAP queries made by clients each second. I recommend viewing this counter along with the LDAP Successful Binds / Sec counter, which shows the number of successful LDAP binds each second. The biggest thing that you are looking for in these two counters is activity. A lack of activity would almost always indicate that network problems are disrupting the client's ability to interact with the domain controller.

The database

As I'm sure you know, the Active Directory is a database that physically resides on your domain controllers. As such, it makes sense to examine some database related Active Directory counters when trying to troubleshoot Active Directory performance problems. The counters that I will be discussing in this section are accessible through the Database performance object.

General performance monitoring

Now that I have gone over some of the more important Performance Monitor counters that are directly related to troubleshooting Active Directory performance, I want to take a few moments and discuss some counters that you can use for general performance troubleshooting. If you find out that your DNS server is not performing adequately, then you might want to upgrade it. First you should use the Performance Monitor to figure out where the real problems are. The techniques that I am about to show you can help you to find performance related problems on your DNS servers, domain controllers, or on any other type of server.


When you are performing general performance monitoring, in search of system bottlenecks, you should always start by checking the Performance Monitor counters related to memory. The reason for this is that if the system is low on memory, it can produce symptoms that make the system appear that the CPU or the hard disk is actually casing the problem. If you were to test the CPU or hard disk first, and encountered such symptoms, then you might assume that you had found the problem and never realize that memory was the real culprit.

When testing the system's memory, you will want to use the counters found within the Memory performance object to look for signs that the system has insufficient RAM. There are a number of counters available, but the ones that I am about to discuss are the most important:

  • PAGES/SEC - The PAGES/SEC counter indicates the number of times each second when the system must access virtual memory. Anything over 20 is considered to be a problem. If you experience high values, then it means that the system is either short on RAM or that the system's virtual memory is configured incorrectly.
  • Committed Bytes and Available Bytes - The committed bytes and available bytes counters work in opposition to each other. The Available bytes counter indicates how much memory is available, while the committed bytes counter indicates how much of the virtual memory is being used. As the available bytes counter decreases, the committed bytes counter increases. If the available bytes counter seems to be low, your system may be short on memory. Before investing in memory though, try opening and closing any applications that are running on the server. If the available bytes don't increase as applications are closed, then it may indicate that the application has a memory leak.
  • Cache Bytes - The Cache Bytes counter indicates the amount of memory that is being used by the file system cache. If the value is over 4 MB, then it almost always means that the server needs additional RAM.

CPU-related counters

If you are testing a server for bottlenecks, then you should check to make sure that the CPU isn't the cause of the problem. To do so, check out the %Processor Time counter in the Processor performance object. The average value should remain below 80%. If the average value (not the peak value) is above 80% and you have made sure that the system has sufficient memory, then it's time for either a faster processor or an additional processor.

Disk-related counters

One more important resource to test for bottlenecks is the server's hard drive. You must verify that the disk is fast enough to keep pace with the server's I/O demands. To do so, there are two counters that I recommend watching. Both of these counters are located in the Physical Disk performance object.

The first counter is the Current Disk Queue Length. This counter tells you how many I/O operations need to be performed, but are waiting on the hard disk to become available. There is a lot of contradictory information regarding what this value should be, but generally speaking, if the average value is 2, then you need to keep an eye on your hard disk. If the average value is 3 or more, then the disk is too slow.

The other counter that I recommend watching is the % Disk Time counter. This counter shows you what percentage of time the hard disk is in use. If the % Disk Time counter has an average value of 90% or higher, and the system has adequate RAM, then the hard disk is too slow for the system.