Diagnose a slow domain controller

Start with the delayed operation

Start with what’s slow: a new interactive sign-in, an LDAP search, a password change, a policy-file read or inbound replication. Those paths share resources but do different work. Record the selected DC, client/site, protocol, elapsed time and error. A successful request from the same application gives you something useful to compare with the failing one.

Separate discovery, connection, authentication and directory/application processing. A long DNS lookup before the connection is different from an established LDAP request spending time on the server. A fast test from the DC console does not measure the branch client’s network or the application’s referrals and follow-up requests. Begin with DC health and service-path diagnosis.

Capture while the symptom occurs

Where available, Performance Monitor’s Data Collector Sets → System → Active Directory Diagnostics captures counters and tracing on the DC. Its default collection lasts five minutes, then takes some time to generate the report. Start it during the problem. The active clients and possible causes in the report are leads to follow, rather than a diagnosis on their own. Microsoft’s high-LSASS-CPU procedure.

For a bounded counter recording, first discover the installed/localized counter paths:

Get-Counter -ListSet NTDS | Select-Object -ExpandProperty Paths
Get-Counter -ListSet '*Database*' |
    Select-Object CounterSetName,PathsWithInstances

The following example collects data and writes a BLG file locally. Run on the affected English-language DC in an elevated session, choose an existing protected output directory and a new filename, and adjust paths for the actual installed counters:

$counters = @(
    '\Processor(_Total)\% Processor Time'
    '\Process(lsass)\% Processor Time'
    '\Process(lsass)\Private Bytes'
    '\Process(lsass)\Working Set'
    '\Memory\Available MBytes'
    '\Memory\Committed Bytes'
    '\Memory\Pages Input/sec'
    '\LogicalDisk(*)\Avg. Disk sec/Read'
    '\LogicalDisk(*)\Avg. Disk sec/Write'
    '\LogicalDisk(*)\Disk Reads/sec'
    '\LogicalDisk(*)\Disk Writes/sec'
    '\NTDS\LDAP Searches/sec'
    '\NTDS\LDAP Bind Time'
    '\NTDS\LDAP Client Sessions'
    '\NTDS\DRA Pending Replication Synchronizations'
)
Get-Counter -Counter $counters -SampleInterval 5 -MaxSamples 120 |
    Export-Counter -Path 'C:\PerfLogs\AD-Incident.blg' -FileFormat BLG

This is about ten minutes of observation, not a universal sampling prescription. Brief stalls can require finer sampling; capacity trends need a longer representative period. Confirm the file actually contains the incident, valid samples and the intended instances. Localized paths and ACLs can prevent collection. Get-Counter’s discovery and sampling semantics.

Normalize CPU before comparing it

The classic Processor(_Total)\% Processor Time counter averages across logical processors. Process(lsass)\% Processor Time adds its threads’ processor use and can exceed 100. On an eight-processor system, an LSASS value of 240 means about 2.4 processors’ worth of execution, approximately 30% of that machine’s aggregate capacity. Subtracting 240 from a machine-wide value of 45 is meaningless. Windows counter definitions.

Check individual processors, user/kernel time and other processes when aggregate numbers hide the pattern. A saturated thread or interrupt path can coexist with moderate total CPU. Correlate host scheduling evidence for a VM; guest counters alone do not describe every resource contention on the host.

If LSASS is doing the work, find which component and caller are responsible. Search count alone can be misleading: a few scans, recursive membership lookups or repeated searches can dominate the workload. Use LDAP query performance to compare filters, entries visited, returned entries, execution time and frequency. If another process is consuming the resource, look at its scheduled work and configuration before tuning LDAP limits.

Follow memory pressure into storage

LSASS contains more than the database cache: version store, code, stacks and other structures also use memory. A large process is not automatically a leak. ESE caches pages as they are used and adjusts to memory pressure; other agents, WMI queries and file-cache activity can compete for RAM. A smaller cache can require more database reads even if the directory workload has not increased. Microsoft’s AD DS memory explanation.

Look for the sequence over time: another consumer grows, available memory falls, LSASS/cache changes, database reads rise and the application slows down. One working-set screenshot can’t show that. Private bytes and working set answer different questions; neither directly measures the useful directory working set. Pages Input/sec includes hard faults for mapped data as well as paging activity, so it doesn’t establish a page-file leak by itself. Microsoft’s page-file counter interpretation separates those faults from page-file utilization.

A newly started DC also has a cold cache. Compare its read I/O and latency as normal traffic warms it with steady-state behavior. Do not reboot all replicas to “clear memory” during an incident: that can discard several useful caches together. Capacity planning covers the restart and failover state separately.

Separate database reads from log writes

Map the OS, DIT, transaction-log and SYSVOL paths to their volumes and underlying storage. Record read/write latency and operation rates for each. A latency value of 0.020 seconds is 20 milliseconds. A quiet volume’s occasional slow I/O is different from a sustained high-latency workload affecting requests.

Read-heavy requests benefit from cached database pages. Directory writes require durable logging before normal successful completion; having a warm read cache does not remove that dependency. The log volume can therefore delay writes, password-related operations or replication while CPU remains low. Two drive letters backed by the same constrained virtual disk or storage tier do not create independent I/O capacity. AD hardware and write-durability considerations.

Compare guest latency with host, datastore/controller and other tenant activity, including backup, antivirus and storage maintenance. Free space doesn’t tell you whether storage is fast enough. An old queue-length rule written for a different number of spindles may be just as misleading.

Low CPU does not exclude a queue

Authentication can wait for an outbound dependency rather than consume CPU. With NTLM pass-through, inspect Netlogon semaphore waiters, hold time and timeouts along the actual server/DC/trust path. Increasing a queue limit before finding a slow downstream hop can move or amplify the bottleneck. Use NTLM queue diagnosis for those counters and their interpretation.

Likewise, DRA Pending Replication Synchronizations counts queued synchronization work, not the number of unreplicated objects or proof that every partner is failing. Combine it with partition/source errors and last-success times. LDAP Bind Time is the last successful bind measurement, not the application’s end-to-end latency distribution. Check counter definitions before making those numbers an SLA.

Change one cause and replay the workload

Write down what you think is happening and what would disprove it. An application fix might reduce query frequency, returned attributes or search scope; a capacity fix might reserve memory or remove storage contention. Increasing LDAP limits, disabling protection or repeatedly restarting LSASS won’t tell you which cause you had.

Repeat the original operation and compare before/after counters under similar workloads. Check that client latency improved without moving the problem to another DC, replication or backup window. If the application failed over, a quieter server may just mean its workload went elsewhere.