In this episode we prepare the toolbox for troubleshooting Active Directory: dcdiag, repadmin, ntdsutil, dsquery, nltest, netdom, and klist, plus Event Viewer analysis with key event IDs and DNS diagnostics to find the root cause.

In episode 20 we connected AD to the cloud and learned to keep sync healthy. But no matter how tidy the design, production systems always face disruptions. In episode 21 we prepare the troubleshooting toolbox: the built-in Windows tools AD administrators use to find root causes — not just to guess.
The philosophy is the same as a doctor's: the right tool for the right symptom. Don't jump straight to restart server or rebuild DC — that's a recipe for prolonging the problem. Use tools that give data, then decide based on evidence.
Before diving into detail, learn which tool to use for which symptom:
| Symptom | First tool |
|---|---|
| DC health | dcdiag |
| Replication issues | repadmin |
| Broken secure channel | nltest |
| FSMO / trust issues | netdom |
| Missing or wrong objects | dsquery |
| Kerberos ticket issues | klist |
| Certificates / CA database | ntdsutil |
dcdiag is the comprehensive diagnostic tool for domain controllers. It runs a series of tests: connectivity, DNS, replication, trust, secure channel, and database integrity.
dcdiag /s:dc01.corp.local
dcdiag /v
dcdiag /cdcdiag /v — verbose mode, shows details of every test.dcdiag /c — runs all comprehensive tests (needs to run on a DC).dcdiag /test:dns — focuses on DNS, the most critical component for AD.dcdiag /test:replications — checks replication health.Each test reports a passed or failed status. Watch the summary of tests section at the end of the output — there you can see which tests failed and which services aren't running.
Replication is AD's heart; if it stops, changes don't spread. repadmin is your eyes into replication's pulse:
repadmin /showrepl — shows replication status from each DC's perspective, along with its partitions and replication partners.repadmin /replsummary — a summary of all DCs in the domain; the fails column shows which DCs failed and for how long.repadmin /syncall /AdeP — forces a full sync against all partners.Note
repadmin /replsummary is the first tool when you suspect replication — its output is concise and immediately points at the problematic DC.
ntdsutil is a low-level tool that performs operations no other tool can. The most commonly used:
ntdsutil: roles).ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server dc01.corp.local
server connections: quit
fsmo maintenance: seize schema masterWarning
seize (seizing) a role should only be done if the DC holding it is truly dead permanently. If the DC is still alive, use transfer, not seize — this difference concerns metadata integrity.
Three small tools that often tip the scales:
nltest /dsgetdc:corp.local — finds which DC serves the client and displays its address. Very useful for verifying the locator process.nltest /sc_query:corp.local — checks the secure channel status between a machine and its domain. A status: 0x0 means it's secure.netdom query fsmo — displays the holders of all five FSMO roles. Quick for confirming who should be running the role.klist — displays the Kerberos tickets stored in the user session. If tickets are corrupt or a TGT is missing, run klist purge then log in again.dsquery searches for objects in AD without opening a console:
dsquery user -name "joni*" — finds users whose name starts with joni.dsquery * "OU=Users,DC=corp,DC=local" -attr name whenCreated — displays object attributes within one OU.dsquery computer -inactive 90 — finds computer accounts inactive for 90 days (useful for cleanup).Query results can be piped to dsget to display details of specific attributes.
The event log is where AD writes its complaints. The most relevant logs: Directory Service for AD's internal operations, DNS Server for zones, and Security for authentication. Some event IDs you must know:
| Event ID | Meaning |
|---|---|
| 4662 | Operation on a directory object (basis for detecting DCSync) |
| 4740 | Account locked out due to wrong password attempts |
| 4769 | Kerberos service ticket request (could be Kerberoasting) |
| 1311 | Configuration replication changed — indicates a topology change |
| 1988 | A DC tried to replicate to a DC whose object was deleted |
Event IDs 1311 and 1988 appear in the Directory Service log; 4662, 4740, and 4769 live in the Security log — and are only recorded if audit policies are enabled (covered in depth in episode 23).
PowerShell offers cmdlets that combine several of the above tools into one session:
Test-ComputerSecureChannel -Repair
Get-ADDomainController -Filter * | Select-Object Name, Site, IPv4Address
Get-ADReplicationFailure -Scope Domain | Format-Table -AutoSizeTest-ComputerSecureChannel -Repair — checks and repairs a machine's secure channel.Get-ADDomainController — lists DCs along with their sites and addresses.Get-ADReplicationFailure — shows the last replication failures per DC.Tip
Get into the habit of a sequential diagnosis pattern: check DNS first, then the secure channel, then replication, then the rest. The majority of AD problems are rooted in these three layers — fixing them often makes other symptoms disappear too.
In this episode you have a troubleshooting toolbox:
dcdiag for overall DC health, repadmin for replication's pulse.ntdsutil for surgical operations like metadata cleanup and FSMO seizure.nltest, netdom, and klist for checking connections, roles, and tickets.dsquery for finding objects, and Event Viewer with key event IDs as the source of evidence.Tools are only half the battle — the other half is knowing which symptom means what. In episode 22, we practice directly on real cases: common Active Directory issues — DCs that don't replicate, failed logins, GPOs not applying, time skew, password lockouts, DNS registration failures, SYSVOL problems, and krbtgt. See you there!