Using Perfmon to Monitor Active Directory

Today we are going to explain about active directory performance counter. How we can monitor the LDAP connections LADP bind time and more about active directory database performance including domain controller’s performance.

Why I am writing this article? I am writing this because of one incident occurred in my organization that was related to LDAP utilization as number of ldap connections were coming to our domain controllers. I also saw around 18 thousands unknown connections that were not part of any subnets which are registered in active directory. There were two big tasks for my team to get these ip addresses details as well troubleshoot the ldap utilization issue.i will explain in next article how we have found these unknown ip addresses ldap connections.

This issue occurred for one of critical trading site. For this trading site there are 27 domain controllers are being used. Two domain controllers were generating the high utilization out of 27 domain controllers as per network team graph. This was also surprising for us how domain controller could generate the high utilization.

Domain controllers do not generate any utilization, DCs acknowledge and respond each and every LDAP request that comes to domain controllers. This is happening as per active directory mechanism.

Due to high utilization, card related transaction was impacted and business chased active directory team to check these domain controllers.

I had attended the MI call and shared the domain controller’s health check reports as well currents user’s details with client technical team But I forgot to share the performance report with client.

But client technical team was not happy with this report and asked to analyses the issue deeply and also others team checking the issue.

In my organization, We are following the Microsoft baseline guideline. It has already configured and scheduled on all domain controllers that monitor the LDAP connections LADP bind time as well others things monitoring. We did not see any issue on domain controllers end and also saw the normal LDAP utilization.

We had generated the 3-4 day’s LDAP dump and shared with client technical team that clearing showing LDAP connection and bind time as per below snapshot.

This issue was also checked by Microsoft and Microsoft did not find anything that cause high utilization at domain controllers end. Microsoft active directory team also impressed from us when they saw these performance counter.

As per MS, few companies are following these active directory performance counter for domain controllers.

Come to this article

So today I will share the active directory performance counter details which is very important for active directory to capture each and every LDAP related activity as well DS Directory Reads/writes and also Active directory related counters. In troubleshooting server performance, there’s a standard set of objects, including processor, Logical Disk, Server, Memory, System and so on. However, there’s an NTDS object that provides us with relevant AD counters such as DRA, Kerberos, LDAP and even NTLM-related counters. In addition, we can collect valuable AD data by monitoring the LSASS process. I recommend enabling the following:

\NTDS\ATQ Threads LDAP
\NTDS\ATQ Threads Total
\NTDS\DS Directory Reads/sec
\NTDS\DS Directory Searches/sec
\NTDS\DS Directory Writes/sec
\NTDS\DS Threads in Use
\NTDS\DS Directory Reads/sec
\NTDS\DS Directory Searches/sec
\NTDS\DS Directory Writes/sec
\NTDS\DS Threads in Use
\DirectoryServices(NTDS)\LDAP Client Sessions
\Process(lsass)\% Processor Time
\DirectoryServices(NTDS)\LDAP Active Threads
\DirectoryServices(NTDS)\SAM Enumerations/sec
\DirectoryServices(NTDS)\SAM GC Evaluations/sec

In this article, I will explain about LDAP client session and LDAP bind time only because both are very important for active directory. We can monitor LDAP queries through these performance counters.

LDAP Client Sessions: This is the number of sessions opened by LDAP clients at the time the data is taken. This is helpful in determining LDAP client activity and if the DC is able to handle the load. Of course, spikes during normal periods of authentication — such as first thing in the morning — are not necessarily a problem, but long sustained periods of high values indicate an overworked DC.

LDAP Bind Time: This is the time in milliseconds needed to complete the last successful LDAP binding. Documentation says that this should be “as low as possible,” but if you run the perfmon output through the Performance Analyzer of Logs (PAL) tool, it will flag 15 milliseconds as a warning threshold and 30 milliseconds as an error threshold. The fix is more resources: processor, memory and so on. (Note: PAL is an excellent performance-analysis tool, and is available online.)

 In diagnosing the LSASS process, as in any performance analysis, a baseline must be established. A note on Microsoft’s DS blog indicates that if a baseline is not available, use 80 percent. That is, the LSASS counters shouldn’t indicate more than 80 percent consumption. Above 80 percent consumption indicates an overload condition, which could be a high LDAP query demand or general lack of server resources. The resolution is to increase resources or reduce demand, but be advised this has the potential to cause a performance hit in the domain.

If you really want to solve your LSASS resource issues, put your DCs on x64 platforms with several processors and 32GB of RAM. You might be surprised at how much memory LSASS really can use.

So, that’s all in this blog. I will meet you soon with some other stuff. Have a nice day !!!

Recommended content

RODC Installation Guide- Step by step guide to install read only domain controller

RODC Filtered Attribute Set

Installing and configuring a RODC in Windows Server-2012

How to find the GUID of Domain Controller

Understanding Group Policy Preferences

Group Policy Verification Tool GPOTool Exe

Group Policy Health Check on Specific Domain Controller

Netlogon Folder in Active Directory

Custom Attributes in Active Directory

Tombstone Lifetime of My Active Directory Forest

Computers AD Site From the Command Line

Active Directory Database Integrity

Disabling and Enabling the Outbound Replication

DFS Replication Service Stopped Replication

Strict Replication Consistency

The replication operation failed because of a schema mismatch between the servers involved

Troubleshooting ad replication error 8418 the replication operation failed because of a schema mismatch between the servers

Replication information in txt file

Repadmin Replsummary

Enabling the outbound replication

Guys please don’t forget to like and share the post.Also join our WindowsTechno Community and where you can post your queries/doubts and our experts will address them .

You can also share the feedback on below windows techno email id.

If you have any questions feel free to contact us on admin@windowstechno.com also follow us on facebook@windowstechno to get updates about new blog posts.