Measuring AD performance
Published Sep 06 2006 04:20 PM 6,693 Views

On the heels of my previous post about Dedicated Active Directory Sites for Exchange, I wanted to go a bit more into measuring AD performance.

To decide if additional AD sites are required for your Exchange environment you should look at measuring the health of DC/GC's.  CPU and memory is not enough to look at, need to also look at network and disk activity.  The following is a list of counters you should monitor while measuring the health of your DC/GC's:

-      Database\Database Page Fault Stalls/sec
The number of page faults (per second) that cannot be serviced because there are no pages available for allocation from the database cache. If this counter is nonzero most of the time, the clean threshold might be too low. You can increase the size of the database cache by adding more RAM.

-      Database\Database Page Faults/sec

-      Database\Database Cache Size

-      Database\Log Record Stalls/sec
The number of instances (per second) that a log record cannot be added to the log buffers because the buffers are full. If this counter is not zero most of the time, the size of the log buffer might be a bottleneck

-      Database\Log Threads Waiting

-      Database\Log Writes/sec

-      NTDS\LDAP Client Sessions

-      NTDS\DSSearch sub-operations/sec

-      NTDS\LDAP Search/sec
The number of search operations per second performed by LDAP clients.

On the Exchange Servers we should include the following too (both of the following counters should be under 200ms always, indeally average under 50ms):

-      MSExchangeDSAccess Process\LDAP Search Time (all instances)

-      MSExchangeDSAccess Process\LDAP Read Time (all instances)
If an increase in these counters coincides with a drop in message delivery rate, the slowdown is occurring in Active Directory

For further information have a look at "Ruling Out Active Directory-Bound Problems" in the Troubleshooting Microsoft Exchange Server Performance Guide (


The Exchange Product Group recommends as a best practice that Microsoft Exchange 2003 servers are placed into a separate AD Site.

Microsoft and some of its customers have seen benefit of using separate AD Sites for Exchange.  One particular customer commented "Initially we didn't and it caused problems. We then built a dedicated AD site based loosely on the 4 to 1 rule, and haven't really had any problems since then."

Final thoughts:

-      Unless there is prior consideration in terms of network design, the change in the DSProxy algorithm that comes with Exchange 2003 Service Pack 2 may cause clients to be referred to incorrect global catalog servers from a network perspective (latency, bandwidth, usage, number of hops). You should consider these network implications before implementation.  This can be mitigated by hotfix and related registry key in 912584.

-      To ensure that Exchange Server continues to provide in-site global catalog referrals, you may need to add global catalog servers to the Exchange Active Directory site for those domains that contain mailboxes residing on the Exchange servers in that Active Directory site.

-      Run the System Centre Capacity Planner 2006 (This is available as part of the TechNet subscription).

-      Using the performance monitor counters above, check the health of your AD when under load from Exchange 2003 Servers.

-      Define OLA's for the Active Directory and SLA's for the Email Services and ensure they are actionable and measurable.

- Paul Flaherty

Version history
Last update:
‎Sep 06 2006 04:20 PM
Updated by: