I have two Windows Server 2019 domain controllers, both using static IP addresses. After changing a DNS forwarder setting on one server and later reverting it, neither domain controller can open Active Directory Users and Computers or locate the domain. The error says: "Naming information cannot be located because the specified domain does not exist or could not be contacted." Both servers can ping each other by IP, and each currently points to the other for DNS. DNS Manager appears normal, but I'm unsure whether the forwarder configuration is correct. I have rebooted one DC without improvement and am avoiding rebooting client machines.
The remaining domain controllers are also global catalogs. One of the two previously removed domain controllers, DC-old, was demoted and metadata-cleaned after confirming it held no FSMO roles. The current event logs include DFS Replication error 5012 reporting that DC-old does not recognize the replication connection, KCC error 2921 for missing attributes, Group Policy error 1054, global catalog connection error 1126, and LSA/SAM policy notification error 1003. One current DC holds the FSMO roles but cannot see the domain. What should I check first, and what is the safest way to recover DNS, AD replication, and SYSVOL without making the situation worse?
5 Answers
Start with DNS rather than assuming the domain itself is gone. A domain controller should use another healthy DC as its preferred DNS server while services start, with the local DC as an alternate if appropriate. Verify that the AD-integrated zone exists, that the DC host records and _ldap._tcp and other SRV records resolve correctly, and that both servers can resolve the domain and each other by name. Use nslookup and dcdiag /test:dns, then run repadmin /replsummary and repadmin /showrepl to identify the actual replication failure. DNS forwarders are only for resolving external names; they do not replace the internal AD DNS zone.
The DFSR 5012 message is important. If DC-old was removed while the remaining controllers still had stale replication topology or references to it, AD replication and SYSVOL may be unhealthy. Check that no DNS records, connection objects, or replication references still point to DC-old, and confirm that the current controllers have the SYSVOL and NETLOGON shares. Do not immediately perform an authoritative SYSVOL restore just because replication is failing; first determine which DC has the most current and trustworthy copy of SYSVOL and whether the AD database itself is consistent.
An authoritative SYSVOL restore is a recovery procedure, not a routine fix. It should be based on verified backups or a known-good SYSVOL copy, with the other DCs made non-authoritative afterward. Using an old or incomplete copy can overwrite current Group Policy data.
Do not remove and rejoin the domain controllers like ordinary member computers. A DC cannot simply be rejoined using the normal workstation process, and cached credentials or disabling networking will not repair AD. If the servers cannot authenticate, check whether a usable local Administrator account exists for console recovery, but preserve the current state and take backups before attempting demotion, metadata cleanup, or database/SYSVOL recovery.
Before making more changes, record which server holds the FSMO roles and which DCs are global catalogs. Run dcdiag /v, dcdiag /test:dns, netdom query fsmo, repadmin /replsummary, and repadmin /showrepl from an elevated command prompt. Also check the Directory Service, DNS Server, DFS Replication, and System event logs around the first failure. Confirm that the network profile and firewall still allow the domain-controller rules; a profile switching to Public can block the required AD ports even when basic ping works.
The removal of DC-old may have exposed an existing replication problem rather than caused a simple DNS-forwarder issue. Once DNS and connectivity are corrected, make sure the remaining DCs advertise properly and that the domain and forest naming contexts replicate. If neither DC has a healthy SYSVOL/NETLOGON state, stop and use a documented disaster-recovery plan or a verified system-state backup instead of repeatedly rebooting or forcing replication.
Pointing each DC only at the other one can create a startup dependency, especially if both were changed or restarted around the same time. Correct the client/DNS adapter settings first, but don’t assume that alone will repair a broken SYSVOL replication state.