DCDIAG Explained: How to Read and Interpret Domain Controller Diagnostics (Windows Server 2025)

dcdiag ships on every Windows Server and gets run at the start of every serious AD troubleshooting session. Most operators know the command. Fewer know what each test actually checks, why a specific test fails, and — critically — when a FAILED result is a real problem versus background noise.

This article covers the full dcdiag test reference, common error codes mapped to their causes, the DNS sub-test breakdown, and what dcdiag doesn’t test — which is as important as what it does.

Quick Command Reference

Pick the command that matches what you’re trying to do. The full switch reference and scenario-specific guidance follow below.

Goal	Command
Fast health scan — failures only	dcdiag /q /skip:systemlog
Full enterprise scan — all DCs, logged	dcdiag /e /c /q /f:dcdiag.txt
DNS validation	dcdiag /test:DNS /v
Replication check only	dcdiag /test:Replications /v
New DC post-promotion	dcdiag /test:Advertising /test:Replications /test:SysVolCheck /test:DNS /v
Target a specific DC	dcdiag /s:dc01.yourdomain.com /v
RPC / security error deep dive	dcdiag /test:CheckSecurityError /s:failing-dc

What dcdiag Actually Does

dcdiag runs a series of diagnostic tests against a domain controller and reports PASSED, FAILED, or WARNING for each. It tests whether AD components are configured correctly and operational — services running, objects intact, replication connections valid, DNS records registered, FSMO roles known.

What it does not do: measure replication latency in depth, force replication, check disk space, validate GPO content, or assess security hardening posture. Those require other tools. The full list of what dcdiag misses is covered in the What dcdiag Does NOT Test section below.

Run it elevated. Many tests require domain admin permissions, and running dcdiag without elevation produces misleading access-denied failures across tests that should otherwise pass. The full switch reference is available in the Microsoft Learn dcdiag documentation.

When to Run dcdiag

After every DC promotion or demotion, run the post-promotion check immediately — Advertising, Replications, SysVolCheck, and DNS confirm the new DC is functional before clients start hitting it.

After structural changes — site link modifications, schema updates, trust changes, functional level raises — run a full enterprise scan to confirm convergence. These changes can leave the environment in a transient state that looks clean locally but isn’t.

During troubleshooting, dcdiag gives you the map. When authentication fails, Group Policy stops applying, or replication errors appear, it won’t always name the exact cause — but it points to the right area fast.

On a weekly schedule, dcdiag /e /c /q /f:dcdiag.txt catches slow-developing failures: a DC that quietly stopped replicating, a service that didn’t restart after a patch, an FSMO role holder that became unreachable. These don’t generate alerts. They accumulate until something breaks.

How to Run dcdiag — Switches Reference

Switch	What it does
/q	Quiet — show only failures and warnings
/v	Verbose — show full detail per test
/c	Comprehensive — run all tests including non-default
/e	Enterprise — run against all DCs in the forest
/s:DCname	Target a specific DC by name
/f:file.txt	Write output to file
/skip:testname	Skip a specific test
/fix	Attempt automatic repair — MachineAccount SPN fix only

Most Useful dcdiag Tests

Not all tests carry equal operational weight. These five surface the failures that matter most in production and homelab environments — run them first when you need a faster read than a full scan.

Advertising — confirms the DC is announcing itself as a DC, KDC, and time server. If this fails, the DC is functionally invisible to clients even if it’s online.

Replications — checks all replication connection objects for errors. This is where error codes 1722 and 8453 surface. A FAILED Replications test is always worth investigating.

SysVolCheck — reads the SysVolReady registry flag. A failed SysVolCheck means Group Policy isn’t replicating from this DC, even if the DC otherwise looks healthy.

DFSREvent — scans the DFSR event log for the last 24 hours. Events 2213 and 4012 require specific restore procedures and won’t appear in any other dcdiag test output.

DNS — runs seven sub-tests covering record registration, zone configuration, dynamic updates, and forwarder health. Most replication errors (1722 in particular) trace back to DNS. This test is not run by default — always request it explicitly with dcdiag /test:DNS /v.

dcdiag Test Reference — Every Default Test

Tests run in order. The Connectivity test cannot be skipped.

Connectivity (cannot be skipped)

Tests DNS name resolution for the DC, ICMP ping response, LDAP bind, and RPC bind via DsBindWithCred. Every other test depends on Connectivity — if this fails, the rest of the output is unreliable.

FAILED means the DC is not reachable or not registered in DNS. Check DNS records with nslookup dc01.yourdomain.com, confirm ICMP isn’t blocked between the machine running dcdiag and the target (Microsoft explicitly notes that blocking ICMP breaks dcdiag), verify the DC is online and NTDS is running.

Advertising

Tests whether the DC is advertising its roles via DsGetDcName — registered as a DC, a KDC, a time server, and (if applicable) a GC.

FAILED most often means Netlogon is stopped, or the KDC service is stopped (which drops the KDC advertising flag). Occasionally fires on a newly promoted DC before SYSVOL has fully replicated. Fix: start Netlogon and KDC, confirm with nltest /dsgetdc:yourdomain.com /force.

FrsEvent

Scans the FRS event log for errors in the last 24 hours. FRS was removed in Windows Server 2025 — if this test fires in a WS2025 environment, the SYSVOL migration state is wrong. In environments still running FRS on older functional levels, treat FRS errors as a migration priority, not a maintenance item.

DFSREvent

Scans the DFS Replication event log for errors in the last 24 hours. FAILED means DFSR encountered errors — dirty shutdown (Event 2213), content-freshness lockout (Event 4012), or staging quota exhaustion (Event 2104) are the most common causes.

Check the DFS Replication event log directly. Events 2213 and 4012 require specific restore procedures covered in SYSVOL Replication Issues in Active Directory: DFSR Troubleshooting.

SysVolCheck

Reads the SysVolReady registry flag (HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SysvolReady). Works regardless of whether SYSVOL uses DFSR or FRS.

FAILED means SYSVOL hasn’t completed initialization or replication. Netlogon won’t share SYSVOL until this flag is 1. On a newly promoted DC, wait for initial SYSVOL sync. If it’s stuck, check the DFSR event log before attempting any restore procedure.

KccEvent

Scans the Directory Service event log for KCC (Knowledge Consistency Checker) errors or warnings in the last 15 minutes. FAILED means the KCC can’t build a valid replication topology. Event 1311 in the Directory Service log is the most common KCC failure — the KCC couldn’t find a spanning tree, usually because a DC is unreachable.

KnowsOfRoleHolders

Tests this DC’s knowledge of which servers hold the five FSMO roles. Run with /e to compare knowledge across all DCs — if DCs disagree on role holders, replication is broken between them. A FAILED result here means this DC doesn’t know where an FSMO role is held, which is a replication symptom, not a role holder failure. Use LocatorCheck to test whether role holders are actually reachable.

For background on FSMO roles and what breaks when each role holder goes offline, see FSMO Roles Active Directory: What They Do and How to Manage Them.

MachineAccount

Tests that the DC’s computer object exists in the Domain Controllers OU, has correct UserAccountControl flags, and has valid SPNs registered. Missing SPNs break Kerberos.

FAILED: run dcdiag /test:MachineAccount /fix — dcdiag can attempt automatic SPN repair. For deeper issues, inspect SPNs with setspn -L dc01 and reset the computer account with netdom if needed.

NCSecDesc

Tests that security descriptors on naming contexts have the permissions required for replication. Can produce false positives in mixed-version environments and with RODCs. If this fails in an otherwise healthy environment, read the verbose output before acting — a false alarm here is more common than an actual permissions problem.

NetLogons

Tests that the DC can read the SYSVOL and NETLOGON shares and that the “Access this computer from the network” privilege is correctly configured. FAILED means Netlogon can’t access SYSVOL, the shares aren’t present, or the security policy is misconfigured.

ObjectsReplicated

Tests that the NTDS Settings object and the DC’s computer object have replicated to at least one replication partner. FAILED means the DC is newly promoted and replication hasn’t completed, or replication is broken.

Replications

Checks all configured replication connection objects for: last-attempt errors, disabled replication connections, or latency over 12 hours. FAILED means one or more replication connections have errors. The error code matters — 1722 is RPC unavailable, 8453 is access denied. See the error reference section below.

RidManager

Tests that the RID master is reachable and this DC has a valid RID pool to allocate new object SIDs from. FAILED means the RID master is down or unreachable. New security principal creation — users, groups, computers — will fail when the current RID pool is exhausted.

Services

Tests that AD-dependent services are running: DFSR, DNS, DNSCACHE, EVENTSYSTEM, ISMSERV, KDC, NETLOGON, NTDS, RPCSS, SAMSS, SERVER, W32TIME, WORKSTATION. FAILED output names the specific service that’s stopped.

SystemLog

Scans the System event log for errors in the last 60 minutes. This test fails constantly in production environments — Windows Update, driver messages, hardware events, anything that generated a System log error in the last hour will trigger it. In a clean lab, it’s a useful signal. In any real environment, it generates noise that buries actual AD failures.

Use dcdiag /q /skip:systemlog for routine health scans. Review the System log separately when investigating specific incidents.

VerifyReferences

Tests that FRS or DFSR computer-reference attributes on the DC object are intact.

Enterprise Tests (run with /e)

LocatorCheck — tests that global FSMO role holders (PDC emulator, KDC, GC, time server) can be located and respond. Error 1717 from this test means a specific role holder is unreachable.

FsmoCheck — verifies this DC can contact a KDC, time server, preferred time server, PDC emulator, and GC. Important distinction: FsmoCheck tests locator connectivity, not whether the operations master role holders are performing their functions correctly. A passing FsmoCheck doesn’t mean all FSMO roles are healthy.

Non-Default Tests

Test	How to run	What it does
DNS	/test:DNS /v	Seven DNS sub-tests — see below
CheckSecurityError	/test:CheckSecurityError	Deeper RPC and security failure analysis for errors 1722 and 5
OutboundSecureChannels	/test:OutboundSecureChannels	Validates secure channels to all DCs in the domain
Topology	/test:Topology	Analyzes replication topology — does not verify partner reachability
VerifyEnterpriseReferences	/test:VerifyEnterpriseReferences	Cross-domain object references
RegisterInDNS	/test:RegisterInDNS	Re-registers DC DNS records
DcPromo	/test:DcPromo	Pre-promotion environment readiness check
CutoffServers	/test:CutoffServers	DCs that can’t be reached by any replication path

dcdiag /test:DNS — Sub-Test Breakdown

The DNS test runs up to seven sub-tests and produces a summary table at the end of its output. Read the summary table — not the verbose test output. The columns are labeled Auth / Basc / Forw / Del / Dyn / RReg / Ext and each DC gets a row.

Column	Sub-test	What it checks
Basc	DnsBasic	DNS client config, service availability, zone existence
Auth	DnsAuthoritativeZones	Whether this DC is authoritative for the domain zone
Forw	DnsForwarders	Forwarder configuration and reachability
Del	DnsDelegation	Delegation records for child zones
Dyn	DnsDynamicUpdate	Dynamic updates enabled on the AD-integrated zone
RReg	DnsRecordRegistration	A, CNAME, and SRV records registered for this DC
Ext	DnsResolveExtName	External name resolution — not included in /DnsAll

A WARN means dcdiag couldn’t fully validate the configuration — it’s a “look here,” not always a defect. Run with /v to get the detail behind any flagged column.

Most common real failures in the DNS test:

RReg FAIL — SRV records aren’t registered. This breaks DC locator for clients and other DCs. Force re-registration: nltest /dsregdns, then restart Netlogon. For SRV record troubleshooting and DNS zone issues, see Active Directory DNS Problems: SRV Records, Zones, and Resolution Failures.

Forw FAIL — the forwarder is misconfigured or unreachable. Forwarder failures don’t break internal AD name resolution but break internet access from the DC and external name resolution for clients using the DC as their DNS resolver.

Dyn FAIL — dynamic updates disabled on the zone. Client and DC records won’t self-register, which leads to stale and missing records over time.

Auth FAIL — this DC isn’t authoritative for its own domain zone. Usually means DNS is pointing at an external resolver instead of an AD-integrated zone.

Common dcdiag Errors — What They Mean

Error 1722 — “The RPC server is unavailable”

Surfaces in: Replications, Connectivity, LocatorCheck.

RPC failure almost always traces to one of three causes: firewall blocking the RPC endpoint mapper (TCP 135) or dynamic RPC ports (49152–65535), DNS failure preventing the partner DC from being resolved, or SMB signing mismatch — documented by Microsoft as a cause of 1722 in replication scenarios.

For the full 1722 diagnostic sequence including error code variants and repadmin correlation, see Active Directory Replication Not Working: How to Diagnose and Fix.

Error 8453 — “Replication access was denied”

Surfaces in: Replications.

The DC attempting replication doesn’t have permission, or the secure channel is broken. The most common causes: missing “Replicating Directory Changes” permission on the naming context, broken computer account secure channel, or — simplest — dcdiag wasn’t run elevated.

Run dcdiag elevated first. Many 8453 errors disappear when run as Domain Admin. If elevated and still failing, check permissions with dsacls "DC=yourdomain,DC=com" | findstr /i "replicating", verify the secure channel with nltest /sc_verify:yourdomain.com.

Error 5 — “Access is denied”

Surfaces in: multiple tests. RPC session established but the operation was rejected. Usually means excessive time skew — Kerberos rejects the ticket when the clock offset exceeds five minutes — or a broken secure channel.

Check time first: w32tm /query /status on the failing DC. If clock offset exceeds five minutes from the domain, fix time before investigating anything else. For time synchronization recovery, see Active Directory Time Synchronization: Fix PDC Emulator, W32Time, and Kerberos Clock Skew.

Error 1717 — From LocatorCheck

An FSMO role holder (PDC emulator, KDC, GC, or time server) is unreachable — the test couldn’t locate the role holder in DNS or couldn’t get a response. Run netdom query fsmo to identify which DC holds each role, then verify that DC is online and reachable. See FSMO Roles Active Directory: What They Do and How to Manage Them for role transfer and seize procedures if the holder is unrecoverable.

Error 8606 and Error 8614

Both surface in Replications and both indicate the DC has been out of contact for an extended period.

8606 — “Insufficient attributes were given to create an object.” The replicating DC encountered a lingering object — an object deleted on other DCs that still exists here because this DC missed the tombstone notification.

8614 — The DC hasn’t replicated past the tombstone lifetime and AD has blocked it to prevent data corruption. Recovery requires lingering object removal for 8606, or metadata cleanup and DC rebuild for severe 8614 cases. Full procedures are in Active Directory Replication Not Working: How to Diagnose and Fix.

Troubleshooting Flow — What to Do When a Test Fails

Use this as a starting point, not a complete decision tree. The error code in the test output usually tells you more than the test name alone.

dcdiag vs repadmin — When to Use Which

These tools answer different questions. Using repadmin when you need dcdiag, or vice versa, wastes diagnostic time.

Question	Tool
Is this DC healthy overall?	dcdiag
Which tests are failing on this DC?	dcdiag
Are there replication errors anywhere?	dcdiag /test:Replications first, then repadmin
What exactly failed, when, with which partner?	repadmin /showrepl
How long ago did replication last succeed?	repadmin /replsummary
Is replication stuck or just delayed?	repadmin /queue
Force replication now	repadmin /syncall /AdeP
Export replication state for all DCs	repadmin /showrepl * /csv

The practical sequence: start with dcdiag /q /skip:systemlog. If Replications fails, switch to repadmin /showrepl * /errorsonly for the specific partner, naming context, and error code. Then use repadmin /syncall or investigate the error code. The full repadmin command reference is on Microsoft Learn.

dcdiag tells you what is broken. repadmin tells you where replication failed and gives you the tools to act on it.

Recommended dcdiag Workflow

This is the sequence that wastes the least time — from initial scan to confirmed fix.

What dcdiag Does NOT Test

This is the part that catches operators who treat a clean dcdiag as a clean bill of health.

dcdiag does not check disk space on the NTDS volume, NTDS.dit file size or integrity, backup recency, GPO content correctness, or SYSVOL file consistency beyond confirming shares exist and DFSR logs are clean. It doesn’t assess absolute time accuracy — only Kerberos-relevant skew against a partner. It doesn’t evaluate security hardening posture: NTLM usage, TLS versions, unsigned LDAP binds, or SMB signing state are outside its scope. AD Recycle Bin status, object count trends, schema health, and trust health beyond basic locator connectivity are also not covered.

The Topology test analyzes replication topology but does not verify that partners are actually reachable or that the replication schedule allows current replication. FsmoCheck confirms locator connectivity but does not test whether role holders are performing their functions correctly.

A clean dcdiag is a necessary check, not a sufficient one. The Active Directory Health Check Checklist covers the areas dcdiag misses — AD database, backup recency, security posture, and the cadence-based checks that keep a production environment stable.

dcdiag Cheat Sheet

Scenario	Command	Notes
Quick health scan	dcdiag /q /skip:systemlog	Routine use — skips SystemLog noise
Full enterprise scan	dcdiag /e /c /q /f:dcdiag.txt	Weekly; run from a DC with forest-wide connectivity
DNS validation	dcdiag /test:DNS /v	Read summary table columns, not just pass/fail
Replication only	dcdiag /test:Replications /v	Note error code — drives next step
New DC validation	dcdiag /test:Advertising /test:Replications /test:SysVolCheck /test:DNS /v	Run immediately after promotion
RPC / 1722 deep dive	dcdiag /test:CheckSecurityError /s:failing-dc	More detail than Replications alone
All DCs, specific test	dcdiag /test:Advertising /e /v	Replace Advertising with any test name
FSMO role knowledge check	dcdiag /test:KnowsOfRoleHolders /e /v	Compare across all DCs for consistency

Windows Server 2025 — dcdiag Behavior

dcdiag is unchanged and fully supported on Windows Server 2025, available natively on DCs and through RSAT on management workstations.

One point operators raise frequently: because wmic is disabled by default in WS2025, does dcdiag /test:DNS break? No. The DNS test uses the WMI service — not the wmic CLI — so the WMIC deprecation doesn’t affect dcdiag DNS testing. The concern is valid but the impact is limited to legacy scripts and monitoring agents that call wmic directly, not to dcdiag itself.

Verify patch level on every WS2025 DC before running health checks. Microsoft’s Windows Server 2025 resolved issues page documents the KB5060842 firewall profile bug and its resolution.

If it’s not installed, apply it before drawing conclusions from local diagnostic output.

Final Thoughts

dcdiag is the first tool most operators reach for when an AD environment starts behaving strangely — and correctly so. It maps the failure surface faster than manually checking services, events, and replication state individually. The gap isn’t in using it. It’s in knowing that a FAILED SystemLog test is usually irrelevant, that FsmoCheck doesn’t actually test role holder function, and that a clean result doesn’t mean the directory is healthy.

Use dcdiag to find where to look. Use repadmin when replication is the problem. Use the Active Directory Health Check Checklist to cover the areas dcdiag doesn’t reach — backup recency, database health, security posture, and the full service dependency chain.

FAQ

What does dcdiag check?

dcdiag validates domain controller health across approximately 20 default tests covering DNS registration, service state, SYSVOL sharing, DFSR event logs, replication connections, FSMO role knowledge, machine account integrity, naming context security descriptors, and Netlogon share access. Additional tests — DNS sub-suite, CheckSecurityError, Topology — run only when explicitly requested.

Why does dcdiag say “access denied” on every test?

Almost always because dcdiag was run without elevation. Open an elevated command prompt or PowerShell session and run again. If the error persists when elevated, the issue is a broken secure channel or excessive time skew — check w32tm /query /status and nltest /sc_verify:yourdomain.com.

What is the difference between dcdiag and repadmin?

dcdiag tests configuration and state across many functional areas. repadmin specializes in replication — per-partner, per-naming-context status, error history, queue depth, and the ability to force sync. Use dcdiag to find what is broken; switch to repadmin when replication specifically is the problem and you need to act on it.

Should I be worried if the SystemLog test fails?

Usually no. The SystemLog test fails whenever there are error-level events in the System log in the last 60 minutes — Windows Update, driver messages, hardware events. In a production environment it almost always fires. Run dcdiag /q /skip:systemlog for routine scans and review the System log separately when investigating specific incidents.

How do I run dcdiag on all domain controllers at once?

Add /e: dcdiag /e /c /q /f:dcdiag-enterprise.txt. Run from a DC that has network connectivity to all sites. Results for all DCs are written to the output file.

What does error 1722 mean in dcdiag?

Error 1722 (“The RPC server is unavailable”) means dcdiag couldn’t establish an RPC connection to a DC. Most common causes: firewall blocking TCP 135 or dynamic RPC ports (49152–65535), DNS failure preventing DC name resolution, or SMB signing mismatch. Run dcdiag /test:CheckSecurityError for a deeper analysis.

Does dcdiag work correctly on Windows Server 2025?

Yes — dcdiag is fully supported on WS2025. WMIC deprecation does not affect dcdiag, including the DNS test suite. However, on WS2025 DCs without KB5060842, a locally clean dcdiag result does not confirm the DC is reachable from the rest of the domain after a restart.