New Domain Controller Checklist: 9 Checks After Promotion

A successful domain controller promotion does not mean the new DC is ready for production. The wizard can finish cleanly while DNS registration, SYSVOL, the time source, or backup coverage are still wrong. This new domain controller checklist covers nine checks to run immediately after promoting a domain controller, before clients, Group Policy, or additional DCs depend on it.

Each check follows the same pattern: command, pass condition, and where to go if it fails. Together they check domain controller health once, as an acceptance test after promotion, not as a recurring Active Directory health check. If the DC is not promoted yet, start with How to Install Active Directory.

New Domain Controller Post-Promotion Checklist

Run the new domain controller checklist in this order. It doubles as a quick domain controller health check command list: services, DCDiag, SYSVOL, DNS, FSMO, time, replication, Group Policy, and backup. Failures in the early service, DCDiag, SYSVOL, or DNS checks often explain problems that appear later.

Two pass conditions on the new domain controller checklist depend on what you promoted. The first DC in a new forest holds all five FSMO roles and has no replication partners. An additional DC in an existing domain holds no FSMO roles by default and must show healthy inbound replication.

1. Verify Domain Controller Services Are Running

Run this after the post-promotion reboot:

Pass condition: all six show Running. dfsr is the DFS Replication service that carries SYSVOL on current domains, so a stopped DFSR usually shows up again in step 3. Omit dns only if this DC deliberately does not host the DNS Server role.

If failed: check the System, Directory Service, DNS Server, and DFS Replication logs for the failing component and stop the rollout until the cause is understood. A stopped KDC is easy to misread later, because clients report Kerberos and access errors rather than a service failure.

2. Run DCDiag on the New Domain Controller

Pass condition: dcdiag /q returns no reported failures. Quiet mode suppresses successful test output, so a clean run is typically silent. This is one of the easiest steps to misread: the command can look like it did nothing, but a clean run is typically silent.

If failed: run dcdiag /v /c for the full picture, then work through the failing test with the DCDiag commands and tests guide. Microsoft’s DCDiag verification article covers test behavior. Don’t continue down this checklist with unresolved DCDiag failures.

3. Verify SYSVOL and NETLOGON Shares

Or in PowerShell:

Pass condition: both SYSVOL and NETLOGON are listed. SYSVOL and NETLOGON must be available before the new DC should be treated as ready for normal policy and logon use.

If failed: give initial SYSVOL replication a few minutes after the reboot, especially on an additional DC pulling content from a partner. If the shares still don’t appear, follow the SYSVOL replication troubleshooting guide rather than creating shares manually.

4. Validate DNS Registration for the New Domain Controller

Then confirm the new DC appears in the domain controller locator record:

Replace ad.example.com with your AD DNS domain name. _ldap._tcp.dc._msdcs is the record clients use to locate any domain controller in the domain, so it is the one the new DC needs to appear in.

Pass condition:

• the DCDiag DNS test passes;
• the new DC’s FQDN appears in the SRV results;
• the AD DNS zone uses the intended storage and replication model; in a standard AD-integrated deployment, it shows as Active Directory-Integrated in DNS Manager.

A DC with incomplete DNS registration can still look healthy locally. The problem often appears later as domain join or logon errors that do not mention DNS.

If failed: the Active Directory DNS problems guide covers SRV registration, zone type, and resolver configuration. This checklist only detects the problem.

5. Verify FSMO Role Ownership

Or in PowerShell:

Pass condition: all five roles are visible and held by the domain controllers you expect.

• First DC in a new forest: all five roles on the new DC.
• Additional DC: roles stay where they were. Promotion doesn’t move them.

Note which DC holds the PDC Emulator role, because the expected time source in step 6 depends on it.

If failed: an owner that resolves to a missing or demoted server needs attention before production. Transfer and seizure belong in the FSMO roles guide.

6. Verify Time Synchronization on the New DC

Pass condition depends on the DC’s role:

• PDC Emulator of the forest root domain: Source shows the approved external or organizational time source.
• Any other DC: Source shows another domain controller, following the domain hierarchy.

Verify that the reported source matches the intended AD time hierarchy. On the forest-root PDC Emulator, an unexpected local or virtualization source, such as Local CMOS Clock, deserves investigation. Microsoft’s W32Time tools and settings reference documents the query output.

If failed: fix the time hierarchy before production, because Kerberos rejects clock skew beyond five minutes by default. PDC configuration and virtualization time settings are covered in the Active Directory time synchronization guide.

7. Verify Active Directory Replication

For per-partner status:

Pass condition:

• Additional DC: 0 failures, with inbound partners present as expected.
• First and only DC: no replication partners is expected, so the summary has no partner rows to report. Run it anyway to confirm it returns no errors, and don’t treat the missing partners as a failure.

If failed: resolve replication before adding more DCs, because adding partners can spread or complicate an unresolved topology, DNS, or connectivity problem. The Active Directory replication troubleshooting guide covers RPC, access, and topology errors.

8. Validate Group Policy Processing on the Domain Controller

Pass condition: the report shows the expected domain-level and Domain Controllers OU policies applied under Computer Configuration. In most environments that includes the Default Domain Controllers Policy, since new DCs land in the Domain Controllers OU. Exact results depend on your GPO design, inheritance, and filtering.

Read both lines of gpupdate output. A successful user policy line doesn’t mean computer policy applied.

If failed: confirm steps 3 and 4 first, because SYSVOL and DNS are common causes of policy failures on a newly promoted DC. Then use the Group Policy troubleshooting guide.

9. Confirm System State Backup and Recovery Readiness

Backup is often deferred on a new DC, but the server is not production-ready without a recovery path. System State on a domain controller includes the AD DS database, SYSVOL, the registry, and boot files. A normal file-level backup is not a substitute for a supported System State or application-aware Active Directory backup.

Using Windows Server Backup, which is a separate feature and has to be installed first (Install-WindowsFeature Windows-Server-Backup) if wbadmin is not found:

Pass condition:

• at least one successful System State backup exists, where production readiness depends on local System State backup;
• the scheduled backup configuration is validated, not just created;
• the team knows where it is stored and who can restore it.

In a single-DC environment, losing the only DC without a usable backup can mean rebuilding the domain. In multi-DC environments, recovery options depend on the remaining DCs and the failure scenario. Setup and retention are covered in the Active Directory backup guide.

When the New Domain Controller Is Ready for Production

Consider the DC ready only when every applicable item on this new domain controller checklist passes. At that point the one-time domain controller health check is done:

• AD DS services, including DFSR, running
• dcdiag /q returns nothing
• SYSVOL and NETLOGON shared
• DNS test clean and the DC registered in SRV records
• FSMO roles where you expect them
• Time source matches the DC’s role in the hierarchy
• Replication at 0 failures, or no partners on a first DC
• Expected DC policies applied
• Successful System State backup confirmed and schedule validated

If one check fails, fix that subsystem before clients or additional infrastructure depend on the server. Fixing them now is easier than after users, policies, and other DCs begin relying on the new DC.

FAQ

What should I check after promoting a domain controller?

Run the nine checks on the new domain controller checklist: AD DS services, dcdiag /q, SYSVOL and NETLOGON shares, DNS registration, FSMO ownership, time source, replication, Group Policy processing, and System State backup.

What does dcdiag /q returning nothing mean?

It means DCDiag reported no failures in the tests it ran. Quiet mode suppresses successful test output. For confirmation that the tests ran, use dcdiag /v /c.

Why are SYSVOL and NETLOGON important after promotion?

SYSVOL holds Group Policy templates and scripts, and NETLOGON holds logon scripts. Until both are shared, the DC can’t serve policy correctly. If they’re missing, use the SYSVOL troubleshooting guide linked in step 3.

Do I need to check replication on a single-DC domain?

Run repadmin /replsummary once to confirm the promotion left no errors. No partners is expected. Run it again after every additional DC.

What time source should a new domain controller use?

It depends on the role. The forest root PDC Emulator uses an approved external or organizational source; every other DC follows the domain hierarchy. A production forest-root PDC Emulator should normally use an approved external or organizational time source rather than Local CMOS Clock.

Does this checklist apply to Windows Server 2022 and 2025?

Yes. The core tools and validation workflow in this new domain controller checklist apply across currently used Windows Server AD DS releases, including Windows Server 2022 and 2025. Exact behavior and event details can vary by release.

When is a newly promoted domain controller ready for production?

When all applicable checks pass, no DCDiag, DNS, replication, or SYSVOL failures remain unresolved, and recovery readiness is confirmed. Ongoing monitoring after that belongs to a regular health check, not to the new domain controller checklist.