Active Directory — Part 12 — Active Directory Health & Monitoring

Introduction

Everything in this series so far has described a system designed to hide small failures. Replication routes around a dead DC (Part 7). The DC locator finds another Domain Controller when one stops answering (Part 8). Clients retry, caches cover gaps, and users notice nothing.

That resilience is a blessing with a sharp edge: Active Directory can run in a quietly broken state for months. So how do you know your AD is actually healthy, rather than merely not-yet-visibly-broken?

You check. Regularly, briefly, and with the same short list every time. This part is that list — but first, we need to pay a debt from Part 7 and meet the five roles that are the exception to everything we said about multi-master.

FSMO: The Five Exceptions to Multi-Master

Part 7 established that every Domain Controller is writable and equal. That is true for almost everything — but a few operations would break if two DCs could perform them simultaneously. For those, AD quietly falls back to single-master: exactly one DC holds each of five Flexible Single Master Operations roles.

Think of it like a committee that shares nearly all the work, but has appointed one member each as treasurer, secretary, and chair — jobs where two people acting at once would cause chaos rather than help.

The pattern in the last column is worth noticing: most FSMO roles can be offline for days without anyone caring. The PDC Emulator is the exception — it does visible work constantly, which is why its placement and health matter most, and why so many earlier parts of this series kept mentioning it.

What to Check Regularly

A useful AD health routine is short enough that it actually happens. The daily set is five questions:

Weekly, add three more: SYSVOL replication — the DFS-R backlog check, since Part 7 showed GPO files travel separately from AD data; disk space on the volumes holding the AD database and logs; and a skim of the Directory Service event log for recurring warnings. Monthly, review privileged group membership (the Part 11 audit) and confirm the FSMO roles are where your documentation says they are.

Signs That AD Is Struggling

Because AD hides small failures, the early symptoms are behavioural, not alarms. The ones worth treating as smoke:

Logons that got slower for no stated reason — often DNS or site problems making clients authenticate across the WAN (Part 8). Group Policy applying inconsistently between offices — AD or SYSVOL replication lag (Parts 6 and 7). Authentication that fails intermittently and then works on retry — a struggling DC still in the DNS rotation. Account lockouts behaving strangely — replication or PDC Emulator trouble (Part 10). And recurring event-log entries that everyone has learned to ignore — the most reliable early-warning signal there is, precisely because it is the one most often silenced.

The Tools

Built into every DC: dcdiag runs the full test suite — connectivity, advertising, replication, services, and with /test:dns the DNS chain. repadmin owns replication diagnostics, as covered in depth in Part 7. The Active Directory module for PowerShell turns all of it into scriptable, schedulable checks. And the event logs — Directory Service, DNS Server, DFS Replication, and Security — are where the detail lives once a summary check turns red.

Beyond the built-ins, the sensible progression is automation first, products second: a scheduled script that runs the daily checks and emails a red/green summary catches most decay for free. Dedicated monitoring platforms add trending and alerting when the environment justifies them.

Scripts / Commands

Use the commands below as the working health check. All are read-only.

# Where are the five FSMO roles?
netdom query fsmo

# The same, via PowerShell
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

# Replication health across the forest (Part 7)
repadmin /replsummary

# Full DC health test - run per DC, or /e for every DC (verbose)
dcdiag
dcdiag /e /q

# DNS-specific tests (Part 8)
dcdiag /test:dns

# Time source check - should be a DC, or the external source on the PDC Emulator
w32tm /query /source
w32tm /query /status

# Last system state backup per partition
repadmin /showbackup

# SYSVOL replication backlog between two DCs
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" `
    /smem:DC1 /rmem:DC2

# Are all critical AD services running on every DC?
Get-ADDomainController -Filter * | ForEach-Object {
    Get-Service -ComputerName $_.HostName -Name NTDS, DNS, Netlogon, KDC, DFSR |
        Select-Object MachineName, Name, Status
}

# Recent errors and warnings from the Directory Service log
Get-WinEvent -FilterHashtable @{
    LogName = 'Directory Service'; Level = 2, 3
} -MaxEvents 25 | Select-Object TimeCreated, Id, Message

Warning Signs Cheat Sheet

Quick Reference Summary

Final Thoughts

Monitoring Active Directory is not a product decision; it is a habit decision. The failure pattern in real environments is nearly always the same: the information was sitting in repadmin output or an event log for weeks, and nobody was looking.

The counter-habit is deliberately small. Three commands daily, three checks weekly, two reviews monthly — none of it takes ten minutes, and together it converts AD failures from surprises into scheduled maintenance. Boring on purpose, like the best infrastructure.