Active Directory Troubleshooting: DNS, Replication and Logons

When a user cannot sign in, restarting a domain controller is rarely a useful first test. Determine whether the failure affects one account, one workstation, one site or the whole domain. That scope helps separate a local credential problem from a directory-service problem.

Check how the client finds the domain

Domain members need DNS resolution for the domain's service records. Replacing an internal DNS server with a public resolver can break discovery even when ordinary websites still open. From an affected client, inspect its configured DNS servers and query the domain's LDAP service record. Replace the example domain with your own:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.com
w32tm /query /status

The first command tests a DNS lookup, not successful authentication. The second reports local time-service status; compare it with the domain's intended time hierarchy. Investigate an unexpected source or time offset instead of manually changing clocks across the domain.

Read replication failures before forcing replication

On an authorized administration machine with the AD tools installed, collect:

repadmin /replsummary
repadmin /showrepl

Look for the failing source and destination, the last successful replication and the exact error. A DNS failure, blocked connection and authentication error require different corrections. Microsoft's replication troubleshooting guide provides a starting point for interpreting the evidence. Repeatedly forcing synchronization does not repair a broken dependency.

Separate account problems from policy problems

For a lockout, identify the account and the device or service submitting old credentials. Unlocking the account without fixing a saved password can simply restart the cycle. For a Group Policy complaint, inspect the applied policies on the affected user and computer, including scope, security filtering and relevant event logs.

Write down one reproducible test: which user, on which machine, performing which action. “AD is broken” is difficult to verify; “this workstation cannot locate a domain controller using its configured DNS server” is something you can test again after a change.

Know when this stops being routine troubleshooting

Database repair, authoritative restore and domain-controller recovery are separate operations requiring a recovery plan, suitable backups and an understanding of the other controllers. Do not run them as general fixes for slow logons. Escalate with the diagnostic outputs, topology and recent changes, keeping passwords and sensitive directory exports out of public tickets.