Learn Active Directory - Active Directory Performance Tuning

#Introduction

In episode 23 we built a security monitoring system: catching anomalies, alerting when accounts get mass-locked-out, and detecting attacks through event logs and SIEM. Monitoring is the radar — it tells you there's a problem even before the damage spreads. Episode 24 answers the next question: how do we make sure the radar doesn't fire all the time because the underlying infrastructure is actually unhealthy?

Performance tuning in Active Directory is preventive work, not reactive. The goal is simple: DCs that serve logons, LDAP queries, and replication stay fast under both normal load and spikes. AD performance is rarely caused by a single root cause — it's almost always a combination of underpowered hardware, wasteful queries, and a database growing without maintenance. Let's dissect each one.

#Baseline: Measure Before You Tune

The first rule of tuning: don't change anything without a baseline. A baseline is a snapshot of your infrastructure's "healthy" state — the numbers captured while everything runs normally. Without a baseline, you have nothing to compare against to judge whether a change helps or hurts.

Windows provides a set of AD-specific counters under the NTDS object. See the available counters, then record samples periodically into a baseline file:

Get-Counter -ListSet "NTDS*" -ComputerName dc01.corp.local |
    Select-Object -ExpandProperty PathsWithInstances

Get-Counter -SampleInterval 15 -MaxSamples 60 -Counter "\\DC01\NTDS\*" |
    Export-Csv -Path "C:\Data\baseline-ntds.csv" -NoTypeInformation

The most informative counters to monitor daily:

Compare today's numbers against the baseline: a sharp spike in LDAP Searches not accompanied by a spike in users is a sign of wasteful queries — the topic we'll dissect shortly.

#DC Sizing: CPU, RAM, and Disk

The baseline tells you actual load; from there you tune the hardware. There's no magic formula, but the direction is clear:

• CPU. A DC isn't a heavy compute server; its load is authentication, Kerberos encryption, and LDAP query processing. Start at 2 vCPUs for a small DC, then scale up if the baseline shows % Processor Time consistently above 70-80%.
• RAM. AD stores database pages in memory — a DC's RAM is the cache for ntds.dit. The bigger the database, the more RAM is useful. A rough rule of thumb: 2-4 GB per 10,000 objects, plus room for Windows and other processes. 4 GB is enough in the lab; 16 GB and up isn't wasteful in production.
• Disk. Use SSDs, especially for the database and log volumes. ntds.dit is read when queries miss the cache — a slow disk is felt directly as query latency. Put the database and logs on volumes separate from the OS, and separate from SYSVOL if traffic is heavy.
• Network. Keep latency to clients and between DCs low. High inter-site latency slows replication and cross-site GC lookups — a deciding point in episode 27.

RAM is the easiest investment: no configuration, just more cache capacity. If the baseline shows slow LDAP queries but low CPU, it's almost always RAM that's lacking — not CPU.

#Capacity Planning as a Mindset, Not a Project

The baseline isn't a one-time activity. When doing capacity planning, consider four growth curves:

1. Object count — every added user, computer, and group enlarges the database and the cache required.
2. Replication traffic — adding DCs and sites increases the replication queue bridgeheads must carry.
3. Authentication load — working hours, employee growth, and SSO adoption change the Kerberos peak per second.
4. Global Catalog queries — applications that search across domains load the GC, not a regular DC.

Review the baseline every quarter and compare trends. Good tuning makes load spikes feel ordinary.

#LDAP Query Optimization

LDAP is AD's query language: applications, Group Policy, and PowerShell commands all speak it. Lazily written queries can swallow DC resources without anyone noticing.

#Use Indexed Attributes

AD maintains indexes for certain attributes. Queries filtering on indexed attributes are resolved via the index; those that don't force a full database scan. Attributes like samAccountName, objectSid, userPrincipalName, and memberOf are already indexed. For custom attributes that are frequently filtered, mark them as indexed via the schema:

Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -Filter "Name -eq 'extensionAttribute5'" |
    Set-ADObject -Replace @{ searchFlags = 1 }

#Avoid Wildcards at the Start of Patterns

Filters like (cn=*santoso*) force AD to examine every entry — the index can't help because the pattern doesn't begin with a fixed character. When possible, use a firm prefix: (cn=santoso*) can still take advantage of the index.

#Monitor Event 1644

Windows records expensive and inefficient queries via event 1644 in the Directory Service log. Enable it by setting the 15 Field Engineering diagnostic value to 5 in the registry under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics, then set the Search Time Limit Exceeded threshold on the same key. After that, event 1644 tells you exactly: who sent the query, what filter, and how long it ran. This is the best feed for finding wasteful queries in the field.

#Set LDAP Policies

The built-in LDAP thresholds are conservative by design: MaxPageSize of 1000 objects per page and MaxQueryDuration of 120 seconds. Applications pulling large datasets can choke on the default MaxPageSize. Set them via ntdsutil:

ntdsutil
ldap policies
set MaxPageSize to 2000
set MaxQueryDuration to 60
show values
quit
quit

Changes take effect immediately. Be careful raising MaxQueryDuration: a ravenous query that used to be killed at the two-minute mark may now consume resources longer — always balance with event 1644 monitoring. Also note MaxConnections and MaxDatagramRecv, which limit concurrent connections and UDP packets per second; their defaults are safe for most environments.

#Database Defragmentation

ntds.dit grows throughout a DC's life. Deleted objects leave empty space in database pages. There are two kinds of defragmentation:

• Online defragmentation runs automatically in the background (roughly every 12 hours) and performs garbage collection. It tidies empty space so it can be reused, but does not shrink the file size on disk.
• Offline defragmentation rewrites the database into a new file at an empty location, producing a smaller new ntds.dit. It's mandatory while the DC isn't serving (e.g. in DSRM mode) and requires ntdsutil.

The offline defrag procedure:

ntdsutil
activate instance ntds
files
compact to C:\compact
quit
quit

The compressed result is written to C:\compact\ntds.dit. Before overwriting the original file: shut down the DC (not just restart), move the old database aside as a backup, copy the new file to the original location, then run dcdiag to confirm the database is valid. Measure the result by comparing file sizes before and after:

ntdsutil
activate instance ntds
files
info
quit
quit

#Global Catalog Placement and Memory

A Global Catalog (GC) is a DC holding a partial copy of every domain's attributes in the forest. When a client or application queries cross-domain objects (including during logon), the GC answers. Two common mistakes:

1. No GC in a site. All cross-site queries loop through the WAN — slow and prone to timeouts.
2. Too many GCs for a small size. A GC stores cross-forest data; every extra GC adds global replication traffic. In large sites, balance it: one GC per site as the standard, two or more only for redundancy.

When planning RAM, remember: a DC that's also a GC must hold cache for the forest dataset, not just its own domain. Consequently, the 2-4 GB per 10,000 objects rule applies to the total forest object count for a GC.

#Conclusion

In episode 24 you learned that AD performance is a discipline of measurement: baselines as a comparison point, hardware sizing based on data rather than guesses, query optimization through indexes, filter patterns, event 1644, and LDAP policies, database defragmentation online and offline with ntdsutil, and GC placement plus RAM cache tying it all together.

Key points:

• Tuning without a baseline is guessing — measure first, then change.
• RAM is AD's cache; SSDs speed up queries that miss the cache.
• Queries should filter on indexed attributes; beware of leading wildcards.
• Event 1644 is the detective for finding wasteful queries.
• Offline compact shrinks the database file; always back up first.

Once the infrastructure runs fast, the logical next question is: how do we move everything to a new structure without stopping production? In episode 25 we dissect Active Directory Migration: inventory and planning, ADMT, SID History, profile migration, up to cutover and rollback. See you there!