8 hours ago8 hr A lot of the AD calls we get start the same way. Someone at the front desk says a user "only sometimes" can't get into an app, or a new hire's drive mappings never show up. When we dig in, it's rarely anything exotic. It's replication that quietly stopped weeks ago, a DC nobody noticed was heading for tombstone, or SYSVOL that never finished moving to DFSR. I run this same check on every domain we take on, and again any time something is flaky. You'll want a DC or a management box with RSAT (AD DS tools), an account in Domain Admins (or delegated rights to read replication metadata), and an elevated prompt or PowerShell window. Start with dcdiag across the whole enterprise dcdiag runs a battery of tests against a DC: connectivity, replication, advertising, FSMO reachability, SYSVOL and more. I always run it verbose and save it to a file, because the lines that matter scroll past way too fast on screen. dcdiag /v /c /e > C:\Temp\dcdiag-all.txt dcdiag /test:dns /v /e > C:\Temp\dcdiag-dns.txt /e tests every DC in the enterprise and /c runs the comprehensive set. Don't skip /e. Without it you're only testing the box you're logged into. We had one domain where the local DC was spotless and a branch office DC hadn't replicated in 40 days. Search the file for failed test. Some failures are noise. SystemLog, for example, fails if there's been any error in the System log in the last hour. Anything in Replications, Advertising, NetLogons, KccEvent or DFSREvent deserves a proper look. Then the replication summary repadmin /replsummary You get one table showing, per DC, the largest replication delta and how many of its partners are failing. You want zero in the fails column and deltas in minutes, not days. If any delta is getting close to your tombstone lifetime (180 days on modern forests), stop and fix that first. A DC that's been out of replication longer than that must not just be reconnected. Per-partner detail when something looks off repadmin /showrepl repadmin /showrepl * /csv > C:\Temp\showrepl.csv repadmin /queue /showrepl lists each naming context (Domain, Configuration, Schema, DomainDnsZones, ForestDnsZones) and each inbound partner with the result of its last attempt. Once you have more than a handful of DCs, the CSV is much easier to filter. /queue shows pending inbound requests. If the queue never drains, that DC is overloaded or can't reach its partner. The errors I see most here are 1722 (RPC server unavailable, usually firewall or DNS), 8453 (access denied on replication) and 8524 (DSA operation unable to proceed because of a DNS lookup failure). I check DNS first every time. Most replication errors turn out to be DNS errors in disguise. Forcing replication repadmin /syncall /APed The flags are A for all partitions, P to push changes outward from this DC, e to include partners in other sites, and d to identify servers by distinguished name in the output. Run it on the DC where the change was made. Every partition should report "SyncAll terminated with no errors". Then rerun repadmin /replsummary to confirm. The help desk ticket that was really replication This comes up more than you'd think. The help desk added a user to an access group on DC01 and could see it in ADUC, but the line-of-business app kept denying them. The app did its own LDAP lookups against DC02, which hadn't received the change yet. Within a site, changes normally replicate within seconds. Between sites the default interval is 180 minutes, and in this case someone had stretched the site link schedule further. A repadmin /syncall /APed on DC01 fixed it on the spot. So before you start troubleshooting the app, find out which DC it's actually talking to. nltest /dsgetdc:contoso.local on a Windows client works, or look at the app's LDAP server setting. Also remember that a user's own Windows session won't see a new group until they log off and back on, because group SIDs are baked into the logon token. That's a different problem from replication, so rule it out separately. FSMO roles netdom query fsmo You should get five roles, all held by DCs that actually exist and are online. If one points at a DC that was removed without being demoted, you'll need to seize that role to a healthy DC with ntdsutil and clean up the dead DC's metadata. While you're here, note which DC is the PDC emulator. It matters for time sync and password changes. Speaking of dead DCs, leftover DNS records and connection objects from DCs that were simply switched off throw replication errors that look alarming but are really a metadata cleanup job. Remove the dead DC in AD Sites and Services and clean up its DNS records instead of chasing each error. SYSVOL and DFSR dfsrmig /getglobalstate net share Get-CimInstance -Namespace root\microsoftdfs -ClassName DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName, State dfsrmig /getglobalstate should say Eliminated, which means the migration from FRS to DFSR is complete. Anything else means you're still on FRS, or halfway off it, and newer Windows Server versions won't accept that as a DC. net share has to show both SYSVOL and NETLOGON. A DC missing those won't process Group Policy for clients, and that's usually how users find out for you. In the CIM query, a State of 4 means Normal, 2 is initial sync and 5 is in error. Also check the DFS Replication event log on each DC for event 2213, which means replication paused after a dirty shutdown. It needs a manual resume, and it's the one I'm most likely to forget. What a healthy domain looks like dcdiag /e shows no failures in the replication, advertising or DFSR tests repadmin /replsummary shows zero fails and small deltas for every DC netdom query fsmo lists only live DCs Every DC shares SYSVOL and NETLOGON, and DFSR state is 4 I run this monthly and keep the output files. Comparing this month's against last month's is how you catch the slow drift before it turns into a Monday morning outage.
Create an account or sign in to comment