Reading DCDIAG Output: What Each Failed Test Actually Means

Anatomy of a DCDIAG Diagnostic Run

Every Active Directory systems engineer has experienced the dread of a sudden directory anomaly. A member server reports that no logon servers are available, replication halts across a critical branch office, or Group Policy processing fails with access denied errors. The first tool administrators instinctively reach for is Directory Server Diagnosis (dcdiag.exe). Yet, when executed without structured parameters, DCDIAG produces a wall of text that can obscure the actual point of failure behind hundreds of passing checks.

Think of DCDIAG as an automated pre-flight inspection checklist for an aircraft. A Domain Controller is not an isolated server; it is an integrated cluster node that must advertise LDAP and Kerberos SRV records to DNS, hold valid secure channel machine credentials, maintain synchronized directory partitions with replication partners, and publish healthy SYSVOL shares. DCDIAG runs thirty individual modular tests against these subsystems. Understanding how the tool categorizes these checks is essential for rapid triage.

In an emergency triage scenario, running an unfiltered standard run floods the terminal buffer. Instead, run targeted switches depending on whether you are doing initial scoping, deep forensic analysis, or quiet error aggregation:

Run a targeted, quiet diagnostic scan that outputs only warnings and errors to the terminal:

# Run quiet DCDIAG test suppressing non-error pass output
dcdiag.exe /q

When investigating a specific failing subsystem (such as advertising or directory replication), isolate the test directly with verbose tracing:

# Run an isolated verbose check against the Advertising subsystem
dcdiag.exe /test:Advertising /v

When preparing for an Active Directory functional level upgrade or routine health audit, generate a comprehensive report capturing all optional and non-default tests across all enterprise domain controllers:

# Run comprehensive enterprise-wide diagnostic and output to log file
dcdiag.exe /v /c /e /f:C:\Logs\dcdiag-enterprise-audit.log

Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = DC01.corp.example.com
   * Identified AD Forest.
   Done gathering initial info.

Doing initial required tests
   
   Testing server: Default-First-Site-Name\DC01
      Starting test: Connectivity
         ......................... DC01 passed test Connectivity

Doing primary tests

   Testing server: Default-First-Site-Name\DC01
      Starting test: Advertising
         ......................... DC01 passed test Advertising
      Starting test: FrsEvent
         ......................... DC01 passed test FrsEvent
      Starting test: DFSREvent
         ......................... DC01 passed test DFSREvent
      Starting test: SysVolCheck
         ......................... DC01 passed test SysVolCheck
      Starting test: KccEvent
         ......................... DC01 passed test KccEvent
      Starting test: MachineAccount
         ......................... DC01 passed test MachineAccount
      Starting test: NCSecDesc
         ......................... DC01 passed test NCSecDesc
      Starting test: NetLogons
         ......................... DC01 passed test NetLogons
      Starting test: Replications
         ......................... DC01 passed test Replications
      Starting test: Services
         ......................... DC01 passed test Services

How to Diagnose: Execution & Network Reachability

When DCDIAG tests fail, administrators frequently assume Active Directory database corruption and begin contemplating drastic measures like metadata cleanups or authoritative restores. However, because DCDIAG executes its checks by initiating real RPC, LDAP, and SMB calls against local and remote endpoints, **network transport barriers and firewall drops account for the vast majority of reported test failures**.

Before attempting to fix directory objects, confirm that the necessary network ports between your diagnostic workstation and the target Domain Controller (and between replication partner DCs) are completely open.

Validate RPC and SMB reachability directly from a remote management workstation or partner domain controller:

# Test RPC Endpoint Mapper reachability on the target Domain Controller
Test-NetConnection -ComputerName DC01.corp.example.com -Port 135 -InformationLevel Detailed

ComputerName            : DC01.corp.example.com
RemoteAddress           : 10.10.10.11
RemotePort              : 135
InterfaceAlias          : Ethernet0
SourceAddress           : 10.10.10.50
TcpTestSucceeded        : True

# Test SMB transport reachability required for NetLogons and SysVolCheck
Test-NetConnection -ComputerName DC01.corp.example.com -Port 445 -InformationLevel Detailed

ComputerName            : DC01.corp.example.com
RemoteAddress           : 10.10.10.11
RemotePort              : 445
InterfaceAlias          : Ethernet0
SourceAddress           : 10.10.10.50
TcpTestSucceeded        : True

The Core DCDIAG Tests Decoded

When DCDIAG flags a test as failed test <TestName>, it provides a brief hexadecimal error code and an event log reference. Below is the operational anatomy of the most critical diagnostic tests:

1. The Advertising Test

The Advertising test interrogates the DsGetDcName API to determine whether the target server is advertising itself across the enterprise as a valid Domain Controller, Global Catalog, and Kerberos KDC.

What breaks it: If the Netlogon service is stopped, or if Netlogon has paused advertising because the DC has detected directory replication failure, this test will fail. Additionally, if the DC cannot register its CNAME and SRV records in DNS (specifically under the _msdcs.<ForestRoot> zone), client machines will be unable to locate it.

Starting test: Advertising
   Warning: DsGetDcName returned information for \\DC02.corp.example.com, when we were trying to reach DC01.
   SERVER IS NOT ADVERTISING as a Domain Controller.
   Check that Netlogon service is started and that DNS records are properly configured.
   ......................... DC01 failed test Advertising

2. The NetLogons Test

The NetLogons test verifies that standard network shares—specifically \\<ServerName>\SYSVOL and \\<ServerName>\NETLOGON—are accessible and that appropriate user rights assignments are configured.

What breaks it: This test fails if the local security policy has stripped the Access this computer from the network (SeNetworkLogonRight) permission from Authenticated Users, Everyone, or Administrators. It also fails if the server has not initialized SYSVOL, causing the Netlogon share to remain unshared.

3. The Replications Test

This test checks the inbound and outbound replication status of all directory partitions (Schema, Configuration, Domain, and DNS Application Partitions). It validates that replication links are active and that latency does not exceed tombstone lifetime thresholds.

What breaks it: Common root causes include RPC errors (Error 1722 / Error 1753) caused by network firewalls, DNS name resolution failures between replication partners, Kerberos authentication mismatches, or lingering objects (Event ID 1988).

Starting test: Replications
   [Replications Check,DC01] A recent replication attempt failed:
      From DC02 to DC01
      Naming Context: DC=corp,DC=example,DC=com
      The replication generated an error (1722):
      The RPC server is unavailable.
      The failure occurred at 2026-10-26 08:12:04.
   ......................... DC01 failed test Replications

4. The SysVolCheck & DFSREvent Tests

SysVolCheck verifies that the SYSVOL replica set has finished initial synchronization and is ready to service client requests. DFSREvent scans the DFS Replication event log over the preceding 24 hours for warnings and errors.

What breaks it: If a Domain Controller suffered an unexpected power outage or hypervisor snapshot rollback, DFSR halts replication to prevent database inconsistency (Event ID 4012: “The DFS Replication service stopped replication on the volume”). Until an administrator performs a manual recovery, SYSVOL remains unshared, failing both SysVolCheck and NetLogons.

5. The KccEvent Test

The Knowledge Consistency Checker (KCC) runs every 15 minutes to automatically construct and optimize the Active Directory replication topology. The KccEvent test inspects the Directory Service event log for failures logged by the KCC engine.

What breaks it: If two Active Directory sites lack an active Site Link in Active Directory Sites and Services, or if a designated bridgehead server is offline or network-isolated, KCC generates Event ID 1311 (“The Directory Service consistency checker has determined that either there is not enough physical connectivity… or replication cannot occur”) and Event ID 1925.

6. The MachineAccount Test

The MachineAccount test validates that the Domain Controller’s computer object in the OU=Domain Controllers container has the correct userAccountControl flags (such as SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION) and that its essential Service Principal Names (SPNs) are registered.

What breaks it: Missing SPNs (such as HOST/<DCName> or E3514235-4B06-11D1-AB04-00C04FC2DCD2/<NTDS-GUID>) or duplicate SPNs registered on another object will cause this test to fail. Conveniently, running dcdiag /fix can automatically repair missing SPNs on the machine account.

7. The NCSecDesc Test

The Naming Context Security Descriptors (NCSecDesc) test checks the security descriptors on the root containers of all directory naming contexts (Domain, Configuration, and Schema). It verifies that default administrative groups and the Enterprise Domain Controllers identity possess the mandatory rights required to synchronize directory data.

What breaks it: Heavy-handed security hardening scripts or misconfigured delegation scripts that strip Replicating Directory Changes permissions from partition heads.

Common Failure Scenarios: Root Cause & Fix

The table below provides an immediate diagnostic lookup mapping the most prevalent DCDIAG test failures to their underlying mechanism and tested resolution:

The Fix: Resolving Critical DC Failures

When troubleshooting a failing Domain Controller, resolve failures in the exact logical order of directory dependencies: Network Transport → DNS Resolution → Netlogon Service → Directory Replication → SYSVOL Health. Addressing downstream errors (like SYSVOL access) before fixing upstream errors (like DNS SRV records or RPC connectivity) is a common cause of wasted troubleshooting time.

Step 1: Verify Domain Controller Advertising and DNS Registration

If DCDIAG fails the Advertising test, verify which DC locator records are actively responding. Query the local locator subsystem using nltest:

# Query the domain controller locator for the local domain
nltest /dsgetdc:corp.example.com

           DC: \\DC01.corp.example.com
      Address: \\10.10.10.11
     Dom Guid: 3b2a7522-83b5-4f01-9238-6fbe8296a1a4
     Dom Name: corp.example.com
  Forest Name: corp.example.com
 Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS 0x371cf
The command completed successfully

If nltest fails to return flags like DS, LDAP, and KDC, force the Netlogon service to flush its local cache and immediately re-register all authoritative DNS SRV records:

# Force Netlogon to re-register all DC locator SRV records in DNS
nltest /dsregdns

Step 2: Diagnose and Force Replication Synchronization

If DCDIAG fails on the Replications test, use repadmin to obtain a granular status summary across all naming contexts:

# Check replication summary across all domain controllers in the forest
repadmin /replsummary

Replication Summary Start Time: 2026-10-26 08:30:15

Beginning data collection for replication summary, this may take a while:
   .....

Source DSA          largest delta    fails/total %%   error
 DC01                      12m:45s    0 /   5    0
 DC02                      14m:10s    0 /   5    0

Destination DSA     largest delta    fails/total %%   error
 DC01                      14m:10s    0 /   5    0
 DC02                      12m:45s    0 /   5    0

If partner replication reports failures (e.g., Error 1722 or Error 8453), force synchronous replication across all partition links with the enterprise synchronization switch once network reachability is verified:

# Synchronize all directory partitions across all partners with progress tracing
repadmin /syncall /AdeP

Syncing all NC's held by DC01.
Syncing partition: DC=ForestDnsZones,DC=corp,DC=example,DC=com
CALLBACK#1: Started linking message from DC02 to DC01.
CALLBACK#1: Finished linking message from DC02 to DC01.
Syncing partition: DC=corp,DC=example,DC=com
CALLBACK#1: Started linking message from DC02 to DC01.
CALLBACK#1: Finished linking message from DC02 to DC01.
SyncAll finished with no errors.

How to Prevent It: Proactive Health Audits

Domain Controller health should never be evaluated reactively during an authentication crisis. Incorporating automated health checks into regular operational schedules allows enterprise infrastructure teams to detect subtle replication latency, journal wraps, and DNS registration anomalies before client authentication is impacted.

Establish a recurring daily synthetic health inspection by executing a scripted quiet scan and redirecting warnings to your operational event collector:

# Verify domain controller health and pipe failures to a daily audit log
dcdiag.exe /s:DC01.corp.example.com /q /f:C:\Logs\dcdiag-daily-summary.log

Configure your SIEM or centralized monitoring system to trigger high-priority alerts on these critical Active Directory event log IDs:

Final Thoughts

The sheer volume of output generated by DCDIAG has historically led administrators to treat it as an intimidating black box. In reality, DCDIAG is an invaluable diagnostic tool that systematically interrogates the fundamental pillars of Windows Server directory architecture: DNS name resolution, RPC communication, local service availability, and cross-site replication topology.

When a test fails, do not rush to modify directory objects or demote the Domain Controller. Treat the output as a road map: verify your network firewall rules against port 135 and the dynamic RPC range, check that the Netlogon service is actively publishing locator records, and confirm that DFS Replication is maintaining healthy SYSVOL shares. Once the underlying transport and configuration issues are resolved, DCDIAG will reliably report clean passes across all thirty diagnostic tests.