Active Directory Operations and recovery
DC capacity, cache and failure headroom
Work out what happens to DC load at peak times, after a restart and when a host or site fails.
Size the service that clients actually use
User count alone won’t size a DC. Two sites with the same number of users can generate very different authentication, application-query, group-expansion, write and replication workloads. Measure the existing service during representative periods, then allow for changes in applications and operational agents as well as directory growth.
Capacity planning chooses acceptable sustained use and time to add resources. Incident alerting detects immediate service impact. A planning target and an emergency alarm need not have the same number or averaging interval. Microsoft’s AD DS capacity guide makes this distinction and uses busy-period measurements rather than a fixed users-per-DC rule.
Define the states the design must survive
| State | Capacity question |
|---|---|
| Ordinary business peak | Can the actual serving DCs meet client latency targets? |
| One DC unavailable | Where will its clients go, and can those replicas absorb them? |
| Host or storage failure | Does one failure remove several nominally redundant DCs? |
| Reboot/rebuild | Can storage and surviving replicas support cold caches and initial synchronization? |
| Backup/maintenance | Does scheduled work overlap another site’s business peak? |
| WAN outage | Which users, credentials, DNS zones and applications still have a usable local path? |
List the domain, site, GC/DNS role and explicit application dependencies for each DC. Five forest DCs are not five interchangeable replicas of every domain or application partition. A branch RODC also has credential and write dependencies that spare CPU cannot remove.
Aggregate work, then model its redistribution
Collect enough data to cover normal busy periods and use shorter samples to catch bursts. Include month-end jobs, password/credential events, backup cycles, failovers and new applications. Averaging a heavily loaded DC with an idle one can hide the very problem you’re looking for.
For an illustrative equal-capacity site with four DCs each consuming 40% of its available processor capacity, losing one would require roughly 4 × 40 / 3 = 53.3% on each survivor if load redistributes evenly and the workload remains comparable. This is an estimate, not a locator guarantee. Hard-coded targets, persistent connections, PDC-specific work and mismatched host capacity can produce a very different result.
Express the forecast in work as well as percentages. For example, a classic process counter total of 600% means six logical processors’ worth of execution. At an illustrative 50% planning target, that work needs about twelve comparable logical processors before other headroom and failure-domain requirements. Different processor generations, VM scheduling and workload serialization can invalidate a simple linear extrapolation. Check counter normalization before summing measurements.
Treat the PDC’s extra work separately
Some work legitimately prefers the PDC emulator. Applications and administrative scripts can also pin ordinary work there when they don’t need to. Compare its authentication, password failures, LDAP searches, monitoring and application connections with its peers. Moving the role without finding the caller can move the overload with it.
A PDC-specific capacity reserve does not imply removing its GC role, disabling site registration or changing locator weights in every environment. Those are design changes with different effects. First distinguish required PDC operations from avoidable targeting, then test redistribution under failure. Microsoft’s FSMO placement guidance.
Memory is a working-set and competition question
Caching most or all active directory data can greatly reduce read I/O. Budget for the OS, ESE buffer cache, version store, security packages, other LSASS structures and required agents. The DIT file’s length is not a complete RAM formula: internal unused space, hosted naming contexts and the workload all matter.
Watch the ESE cache/reads and available memory as demand changes. A small branch may repeatedly touch a limited subset of the directory; an application DC may touch a different subset. Even with enough installed RAM, another consumer can displace the cache or the host may not supply the expected resources. Microsoft’s memory guidance also explains why LSASS can legitimately exceed the DIT’s size.
Version-store pressure is distinct from the read-cache size. Long transactions and concurrent changes can retain versions; adding a read cache does not necessarily fix the retaining transaction. Use database diagnosis when the error concerns transaction resources rather than ordinary read misses.
Size page files for peak commit and the required crash-dump support, not a universal RAM multiplier. A high page-file utilization percentage is not enough to diagnose slow paging, and a large page file is not a replacement for RAM used repeatedly by the workload. Compare committed bytes/limit, hard-fault I/O and the relevant disk latency. Microsoft’s page-file sizing guidance describes both commit and dump requirements.
Storage must handle more than the warm steady state
A large warm cache can make a storage design look excellent until the next reboot. Plan the restart interval, rebuilding a replica and the I/O generated by initial replication, backup and recovery. Client requests warm useful cache pages over time. Artificially scanning the entire directory competes with real clients and can populate the cache with irrelevant data; Microsoft’s cache-warming guidance advises against that shortcut.
The read path and durable-write path need separate assessment. Transaction-log writes remain important even when the DIT fits in RAM. Budget volume capacity for growth, transaction/checkpoint behavior, temporary maintenance space and recovery operations. A large deletion can first create retained deleted objects rather than immediately free the file.
Separate volumes can make storage easier to manage. They only separate I/O if the underlying layout does too. Two virtual disks may still share a saturated datastore, controller, link or physical pool. Check the host and storage counters, and test controller/path failure as well as disk failure. Microsoft’s AD hardware considerations.
Count failure domains beneath the VMs
DC VMs with different names can still share one host, storage dependency or recovery credential. Inspect reservations/limits, host memory pressure, CPU scheduling and uplink capacity alongside guest measurements. Include the host’s other workloads in the peak calculation.
Also test how the team starts the platform after an outage. A management plane that requires the DCs it is meant to start has an operational dependency even when enough hardware exists. Virtual DC deployment considerations and virtualization diagnosis cover this alongside rollback safeguards.
Validate the plan with a controlled removal
Before retiring or consolidating DCs, test representative client selection and workloads while the intended member is unavailable. Preserve capacity, replication and application-latency evidence before, during and after. Confirm clients leave the unavailable target, find an appropriate replacement and recover normally when it returns.
Before the exercise, decide what you’ll accept for client latency, survivor resource use, replication progress and cold-cache recovery time, and when you’ll stop. An average-CPU calculation can’t answer all of those questions. Revisit the model when applications, sites, host placements or the directory’s data change.