Active Directory is a highly intricate IT ecosystem, even with primary domain controllers and a single Active Directory site. The capability to swiftly assess the health of Active Directory and resolve issues is crucial for a sysadmin.
This tutorial shows how to quickly check Active Directory health using built-in tools.
We will cover:
- Service health checks (critical Active Directory services)
- Domain controller diagnostics (DCDiag)
- DNS and replication tests
- Time synchronization
- SYSVOL and Netlogon availability
Check Services on the Domain Controller Servers
First, you must verify that all critical services are running on your DCs.
Critical AD Services to Check
- NTDS (Active Directory Domain Services) โ Active Directory database
- DNS (Domain Name System) โ name resolution (critical for Active Directory)
- KDC (Key Distribution Center) โ Kerberos authentication
- Netlogon โ authentication and secure channel
- W32Time (Windows Time Service) โ time sync
Additional Services Often Checked
- ADWS (Active Directory Web Services) โ remote AD management
- Dnscache (DNS Client) โ DNS client cache
Important. Keep in mind that in case any of these services are stopped, Active Directory may not function correctly.
Get the status of the services
To quickly check the status of these services use PowerShell. You can customize the command:
- `$services` โ list of services to check
- `$computer` โ domain controller names
$services = 'ntds', 'adws', 'dns', 'dnscache', 'kdc', 'w32time', 'netlogon'
Get-Service -Name $services -ErrorAction SilentlyContinue
The command returns the status of the services on the local machine.
To get the status of the services from multiple servers, you can run the below commands instead. Ensure to replace the $computer values with yours. This example queries two servers โ DC1 and DC2 (note that the Active Directory PowerShell module (RSAT-AD-PowerShell) must be installed).
$computer = Get-ADDomainController -Filter * |
Select-Object -ExpandProperty HostName
Invoke-Command -ComputerName $computer {
Get-Service ntds, adws, dns, dnscache, kdc, w32time, netlogon |
Select-Object MachineName, DisplayName, Status
} |
Sort-Object MachineName, DisplayName
This way, you get a birdโs eye view of the services and quickly identify which ones are not running.
Check Active Directory Health with DCDIAG
DCDiag is the main tool for checking domain controller health.
This tool helps detect issues with:
- Replication
- DNS
- Connectivity
- SYSVOL
This command has multiple flags and options, which you can find by running the below command.
dcdiag /h
When you run the DCDiag command on its own, it performs a series of tests on the domain controller and provides a detailed report of the results.
What checks DCDiag?
The tool checks various aspects of the domain controllerโs functionality, including:
- Connectivity โ communication between domain controllers
- DNS โ name resolution
- Replication โ data synchronization
- Directory Services โ AD database health
- Security โ permissions and configuration
- SYSVOL โ Group Policy replication
When to Use Each Command
Below you will find commands that you should use depending on your scenario.
In case you want to check the local domain controller, run the following command:
dcdiag
To check a specific domain controller, run the following command:
dcdiag /s:DC2
If you need to check all DCs in the current AD site, run the following command:
dcdiag /a
To check all DCs in the entire AD forest, run the following command:
dcdiag /e
Note that the /e switch can significantly increase execution time in large multi-domain forests because it contacts DCs across all domains in the forest.
Focus on Errors First (Recommended)
Full DCDiag output can be very verbose and hard to analyze. We recommend you to start by checking only failed tests instead:
dcdiag /a /q
The command above shows only errors that allow to quickly identify real issues without reviewing hundreds of lines of output. This is the best first diagnostic step.
After that, once issues are identified, you should run a full diagnostic to get the details:
dcdiag /a /v
Running Specific Tests
You can run specific tests with DCDiag, such as DNS and NetLogons. You can find all known tests by running dcdiag /h and referring to โThe list of known testsโ.
Checking AD Replication Health
To get a quick replication summary, run the command:
repadmin /replsummary
To show replication errors only, run the following command:
repadmin /showrepl * /errorsonly
In case you need to force replication between all DCs:
repadmin /syncall /AdeP
PowerShell Alternative
For automation and reporting cases, you can use the Active Directory PowerShell module instead of Repadmin.
In order to view replication failures, run the following command:
Get-ADReplicationFailure -Scope Forest
To display replication partner metadata, use the following:
Get-ADReplicationPartnerMetadata -Target * -Scope Forest
These cmdlets return PowerShell objects that can be filtered, exported, and integrated into monitoring/alerting solutions.
Here is a practical example:
Get-ADReplicationFailure -Scope Forest |
Select-Object Server, FirstFailureTime, FailureCount
Note. Keep in mind that persistent replication errors require investigation (because replication failures can lead to inconsistent AD data across DCs).
Checking FSMO Role Holders
Flexible Single Master Operations (FSMO) roles are critical components of AD. If a role holder becomes unavailable or roles are assigned incorrectly, certain directory operations may fail.
In order to quickly identify the current FSMO role owners, run the following command:
netdom query fsmo
Here is an example output:
| Schema master | DC1.contoso.com |
| Domain naming master | DC1.contoso.com |
| PDC | DC2.contoso.com |
| RID pool manager | DC2.contoso.com |
| Infrastructure master | DC2.contoso.com |
You need to check that:
- All FSMO role holders are online and accessible
- The role owners are valid DCs
- The PDC Emulator role holder is functioning correctly because it is responsible for time sync and password change propagation
You can retrieve the same information with PowerShell:
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Note that in enterprise environments, you should check if FSMO role holders are healthy, regularly backed up, and located on reliable DCs. Keep in mind that unexpected FSMO role placement may indicate previous recovery operations/incomplete migrations.
Check DNS Health (Important)
DNS is one of the most common sources of Active Directory issues.
To verify DNS configuration across all DCs, run this command:
dcdiag /test:DNS /e
If everything is working correctly, you should see PASS in the results.
In case there are errors:
- You need to check DNS zones config
- Also verify forwarders
- And make sure DCs can resolve each other
If DNS tests report errors, you should review the reported issues carefully before attempting remediation. Some DNS registration problems can be corrected by forcing the DC to re-register its DNS records:
ipconfig /registerdns
net stop netlogon
net start netlogon
However, most DNS config issues (such as incorrect forwarders, zone config problems, replication failures, or missing delegations) require manual investigation and correction.
Another example is the NetLogons test:
dcdiag /test:netlogons
Check Time Synchronization (Critical)
Important to mention that incorrect time is a common cause of AD authentication failures (Kerberos depends on time sync). Run the command:
w32tm /monitor
How to interpret the result?
- It’s OK if NTP offset close to 0 ms (e.g. < 100 ms)
- In case Offset is larger than 5 minutes, it means that Kerberos authentication will fail
- If you see large or inconsistent offset between DCs, it means you are facing with time sync problem
What to check if there is an issue?
- You should verify the PDC Emulator is configured as a reliable time source
- You need to check NTP configuration with the command:
w32tm /query /status
Make sure all DCs synchronize time from the correct source (usually the PDC Emulator).
If not, review NTP configuration and fix time sync issues.
Check SYSVOL and Netlogon Shares (Critical)
Keep in mind that SYSVOL and Netlogon shares are essential for AD functionality:
- SYSVOL โ stores Group Policy Objects (GPOs)
- NETLOGON โ used for authentication and logon scripts
If these shares are missing or not accessible:
- Group Policies will not apply
- Users may fail to log in
- DCs replication may be broken
Check if shares exist
To check if shares exist, run the following command on each DC:
net share
Expected result
After running the command, you should see at least SYSVOL and NETLOGON in the output.
What means when shares are missing? Usually, it indicates that you are facing serious issues like:
- Active Directory replication problems
- SYSVOL not initialized (DFSR issues)
- Netlogon service is not running
What to check
- To verify Netlogon service:
Get-Service netlogon
- Restart Netlogon if needed:
net stop netlogon && net start netlogon
- Check SYSVOL replication (DFSR)
- Review Event Viewer (Directory Services, DFS Replication, see the table below)
| Key Event Log | Location | What to Look For |
|---|---|---|
| Directory Services | Applications and Services Logs | Replication errors, database issues |
| DFS Replication | Applications and Services Logs | SYSVOL synchronization errors |
| System | Windows Logs | Time synchronization, service failures |
| DNS Server | Applications and Services Logs | DNS resolution errors |
Checking DFS Replication Backlog
In order to verify if SYSVOL data is actively replicating between DCs, you need to check the DFS Replication backlog. You can do that using DFSRDIAG:
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC1 /receivingmember:DC2
In case the backlog count is 0, SYSVOL replication is fully synced between the selected DCs. Note that large/continuously growing backlog values may indicate DFS Replication issues that require investigation.
Wrapping up
Regular Active Directory health checks help you detect and resolve issues before they impact users and business operations.
Why is Active Directory health monitoring important?
Active Directory is a complex system, and regular health checks help detect issues early with services, replication, DNS, and authentication before they affect users and business operations.
Which services should be checked on a Domain Controller?
Critical services include NTDS, DNS, KDC, Netlogon, W32Time, ADWS, and DNS Client (Dnscache). If any of them stop, Active Directory functionality may be disrupted.
What is the fastest way to check AD service health?
You can use PowerShell with Get-Service to check the status of critical services locally or across multiple domain controllers.
Why is SYSVOL and Netlogon important?
SYSVOL stores Group Policies, while Netlogon handles authentication scripts. If they are missing, users may fail to log in and Group Policy may not apply.
