DCDiag: how to diagnose and fix Active Directory problems

When Active Directory starts behaving unexpectedly — users cannot log in, Group Policy stops applying, replication falls behind, or DNS resolution breaks for domain names — the first diagnostic tool every AD administrator reaches for is dcdiag. It runs a structured battery of tests against a domain controller and reports exactly which components are healthy, which are degraded, and which have failed outright.

This guide covers how dcdiag works, what each major test means, how to read and interpret its output, and how to use it as the foundation of a systematic AD troubleshooting workflow.

Running dcdiag

dcdiag is available on any machine with the Remote Server Administration Tools (RSAT) installed, and natively on every Domain Controller. Run it from an elevated command prompt or PowerShell.

Reading dcdiag output

dcdiag output follows a consistent pattern. Each test produces one of three results:

A typical failed test block looks like this:

Starting test: Replications
   [Replications Check, DC01] A recent replication attempt failed:
   From DC02 to DC01
   Naming Context: DC=corp,DC=local
   The replication generated an error (1722):
   The RPC server is unavailable.
   The failure occurred at 2026-04-14 09:32:11.
   ......................... DC01 failed test Replications

The important fields are: which DC pair is affected, which Naming Context (partition) failed, the error code, and the timestamp. The error code — 1722 in this example — is the most actionable piece of information and maps directly to a known cause.

What each test checks

Scenario 1: Replication failure — RPC server unavailable (error 1722)

Error 1722 is the most common replication failure in AD environments. It means DC01 cannot establish an RPC connection to DC02 to pull or push directory changes. Left unresolved, replication lag leads to stale passwords, missing objects, and Group Policy inconsistencies across sites.

rem Start with a targeted replication test
dcdiag /test:Replications /v

rem Check replication status across all partners
repadmin /showrepl

rem Show only replication failures
repadmin /showrepl * /errorsonly

rem Check replication queue
repadmin /queue

If dcdiag confirms error 1722, work through these checks in order:

rem 1. Basic connectivity — can DC01 reach DC02 at all?
ping DC02
ping DC02.corp.local

rem 2. Check if RPC Endpoint Mapper is responding (port 135)
portqry -n DC02 -e 135

rem 3. Test RPC dynamic ports are not blocked by firewall
portqry -n DC02 -e 49152

rem 4. Verify the Netlogon and RPC services are running on DC02
sc \\DC02 query netlogon
sc \\DC02 query rpcss

rem 5. Check DNS — DC01 must resolve DC02 by FQDN
nslookup DC02.corp.local
nslookup -type=SRV _ldap._tcp.corp.local

rem 6. Force replication after resolving the connectivity issue
repadmin /syncall /AdeP

Scenario 2: DNS test failures

DNS is the foundation of Active Directory. Almost every AD problem — login failures, replication errors, GPO not applying — can be traced back to a DNS issue. The dcdiag /test:DNS command runs a comprehensive DNS health check that goes far beyond a simple nslookup.

rem Full DNS test suite against local DC
dcdiag /test:DNS /v

rem DNS test against all DCs in the domain
dcdiag /test:DNS /e /v

rem Save full DNS report to file
dcdiag /test:DNS /v /f:C:\logs\dns-check.txt

The DNS test suite checks six sub-tests:

When dcdiag reports DNS record failures, verify the records manually and re-register if missing:

rem Check if critical SRV records exist
nslookup -type=SRV _ldap._tcp.corp.local
nslookup -type=SRV _kerberos._tcp.corp.local
nslookup -type=SRV _gc._tcp.corp.local

rem Force Netlogon to re-register all DNS records
nltest /dsregdns
net stop netlogon && net start netlogon

rem Alternatively, use ipconfig to re-register the A record
ipconfig /registerdns

rem Verify the DC's own A record resolves correctly
nslookup DC01.corp.local

Scenario 3: DC not advertising — Netlogon and SYSVOL not ready

The Advertising test checks whether a DC is registering itself as a functioning domain controller. A DC that fails this test cannot be located by clients or other DCs — it is effectively invisible to the domain even though it is running.

rem Check advertising status
dcdiag /test:Advertising /v

rem Typical failure message:
rem WARNING: DC01 is not advertising as a time server.
rem WARNING: DC01 is not advertising as a KDC.
rem DC01 failed test Advertising

Advertising failures almost always come from Netlogon not starting, SYSVOL not replicating, or a time synchronisation problem. Check them in this order:

rem 1. Is Netlogon running?
sc query netlogon

rem 2. Is SYSVOL shared and accessible?
net share | findstr SYSVOL
dir \\DC01\SYSVOL

rem 3. Check SYSVOL replication state (DFSR)
dfsrmig /getmigrationstate
dcdiag /test:SysVolCheck
dcdiag /test:DFSREvent

rem 4. Check time sync — Kerberos requires clocks within 5 minutes
w32tm /query /status
w32tm /query /source

rem 5. If time is wrong, resync
w32tm /resync /force

rem 6. Restart Netlogon to trigger re-advertising
net stop netlogon && net start netlogon

rem 7. Verify DC now advertises correctly
nltest /dsgetdc:corp.local

Scenario 4: FSMO role holder unreachable

The KnowsOfRoleHolders test verifies that the DC can contact all five FSMO role holders: Schema Master, Domain Naming Master, PDC Emulator, RID Master, and Infrastructure Master. If any role holder is offline or unreachable, specific AD operations will fail — new user creation stops when the RID Master is unreachable, domain joins fail without the PDC Emulator, and schema changes are impossible without the Schema Master.

rem Check FSMO role holder connectivity
dcdiag /test:KnowsOfRoleHolders /v
dcdiag /test:RidManager /v

rem Find which DC holds each FSMO role
netdom query fsmo

rem Test connectivity to the PDC Emulator specifically
nltest /sc_verify:corp.local

rem If a role holder is permanently offline, seize the role
rem (only after confirming the original holder will never come back)
ntdsutil
  roles
  connections
    connect to server DC02
    quit
  seize pdc
  quit
quit

Scenario 5: Investigating a recently promoted DC

After promoting a new DC, running dcdiag is the standard post-promotion health check before pointing any clients at it. A newly promoted DC may pass dcpromo but still have replication, DNS, or service issues that only surface under dcdiag scrutiny.

rem Full check on the new DC immediately after promotion
dcdiag /v /f:C:\logs\post-promotion.txt

rem Check replication specifically — did initial sync complete?
dcdiag /test:Replications /v
repadmin /showrepl DC-NEW

rem Verify all partitions replicated (Domain, Config, Schema)
repadmin /showrepl DC-NEW /errorsonly

rem Check that the new DC is visible from other DCs
nltest /dsgetdc:corp.local /force

rem Verify SYSVOL replication completed (DFSR)
dcdiag /test:SysVolCheck
dcdiag /test:DFSREvent

rem Check the new DC is advertising correctly
dcdiag /test:Advertising

Scenario 6: Secure channel broken between member server and domain

The OutboundSecureChannels test checks whether a DC has a healthy secure channel to each of its replication partners. A broken secure channel between a member server and its DC produces the classic error: “The trust relationship between this workstation and the primary domain failed.” This can be investigated and fixed from the command line without rejoining the domain.

rem Test secure channel on a member server or DC
dcdiag /test:OutboundSecureChannels /v

rem Verify the secure channel from a member server
nltest /sc_verify:corp.local

rem Test the channel without breaking it
nltest /sc_query:corp.local

rem Reset the secure channel (run on the affected machine as Domain Admin)
nltest /sc_reset:corp.local

rem PowerShell alternative — reset without rejoining domain
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Combining dcdiag with repadmin

dcdiag tells you which component failed. repadmin tells you the replication topology and gives you per-object replication state. Used together, they cover the full picture of AD health.

rem Show full replication status for all DCs
repadmin /showrepl * /csv > C:\logs\repl.csv

rem Show only replication errors across the entire domain
repadmin /showrepl * /errorsonly

rem Show replication summary (good overview for multi-DC environments)
repadmin /replsummary

rem Force replication of a specific partition from all partners
repadmin /syncall DC01 dc=corp,dc=local /AdeP

rem Check for lingering objects (common after USN rollback or long DC isolation)
repadmin /removelingeringobjects DC01 DC02-GUID "dc=corp,dc=local"

rem Show USN (Update Sequence Number) state — useful for detecting USN rollback
repadmin /showutdvec DC01 dc=corp,dc=local

AD health check — standard runbook

This is a reproducible sequence that covers all major AD health dimensions. Run it on every DC in the domain for a full environment assessment, or against a single DC when investigating a specific problem.

rem === STEP 1: Full dcdiag run, save to file ===
dcdiag /v /f:C:\logs\dcdiag-%COMPUTERNAME%.txt

rem === STEP 2: DNS health ===
dcdiag /test:DNS /v /f:C:\logs\dns-%COMPUTERNAME%.txt

rem === STEP 3: Replication status ===
repadmin /replsummary
repadmin /showrepl * /errorsonly

rem === STEP 4: FSMO role holders reachable ===
netdom query fsmo
dcdiag /test:KnowsOfRoleHolders

rem === STEP 5: SYSVOL replication ===
dcdiag /test:SysVolCheck
dcdiag /test:DFSREvent

rem === STEP 6: Services running ===
dcdiag /test:Services

rem === STEP 7: Time sync ===
w32tm /query /status
w32tm /stripchart /computer:DC01 /samples:5

rem === STEP 8: Netlogon and advertising ===
dcdiag /test:Advertising
nltest /dsgetdc:corp.local

Best practices and common mistakes

• Always run dcdiag /v and save to a file. The default non-verbose output hides detail that matters. When a test fails in production, you want the full context in a file you can review without re-running the tool.
• Run against every DC, not just the one you suspect. AD problems are often systemic — a replication failure on DC01 usually means DC02 has a corresponding failure from the other direction. Use dcdiag /e to test the entire forest, or loop through DCs explicitly.
• Never point a DC’s primary DNS at an external resolver. This is the single most common misconfiguration that causes cascading AD failures. DCs must resolve AD DNS zones, which only AD-integrated DNS servers can answer.
• Check time before anything else. A 5-minute clock skew breaks Kerberos completely and produces error messages that look like network or permissions issues. w32tm /query /status takes five seconds and rules out the most disruptive root cause.
• Do not demote and repromote a DC to fix replication. In most cases, the underlying cause (firewall, DNS, time, secure channel) can be fixed without a demotion. A forced demotion of a replication-failed DC can leave metadata in AD that requires manual cleanup with ntdsutil.
• Run dcdiag after every major change. Promoting a new DC, decommissioning an old one, changing site topology, updating DNS — each of these can introduce new failures. Running dcdiag immediately after the change catches problems before they propagate.
• Use repadmin /replsummary as a daily check. It gives a compact view of replication health across all DCs in one screen and takes seconds to read. A clean replsummary with 0 failures is a strong signal that the AD environment is healthy.

Related tools

• nltest Command Builder — interactive builder for nltest commands used alongside dcdiag for secure channel and domain controller testing
• nltest command reference — full guide to nltest flags and when to use them
• Fix trust relationship between workstation and domain — what to do when the secure channel breaks and users cannot log in
• PowerShell Commands Cheat Sheet — PowerShell equivalents for AD diagnostic tasks

Official documentation

• dcdiag — Microsoft Learn — official command reference including all test names, switches, and parameters