Both domain controllers can’t access Active Directory after removing an old DC

Before making more changes, document the current DNS settings, FSMO ownership, global catalog status, and the output from dcdiag and repadmin. Check that the deleted DC no longer appears in DNS, Active Directory Sites and Services, and the replication configuration. Stale host records or SRV records pointing at the removed server can cause exactly this kind of failure.

Also verify that the remaining DCs can locate a global catalog and that their clocks are synchronized. Avoid demoting or rejoining a domain controller as though it were a workstation; that can cause additional AD and replication damage. If both copies of SYSVOL are unavailable or the FSMO holder is not functioning correctly, restore from a known-good system-state backup or involve an AD recovery specialist before attempting an authoritative operation.

The timing strongly suggests that replication or SYSVOL was already unhealthy, and removing the old DC exposed the problem. Event 5012 mentioning the removed server is expected after metadata cleanup, but the important question is whether either remaining DC still has a healthy, shared SYSVOL and NETLOGON folder. Check dcdiag, repadmin /replsummary, repadmin /showrepl, and the DFS Replication event log on both servers.

Do not immediately perform an authoritative SYSVOL restore or copy SYSVOL manually. First identify which DC has the newest valid SYSVOL and whether the AD database and replication topology are otherwise healthy. A mistaken authoritative restore can overwrite the working copy and make recovery harder. Use Microsoft’s documented DFSR SYSVOL recovery procedure only after confirming the state of both DCs and preserving backups.

You can often sign in locally to a domain controller with its local Administrator account, even when domain authentication is unavailable. If normal sign-in is difficult, disconnecting the network temporarily may allow cached credentials to work, but that only provides access to troubleshoot the server—it will not repair AD. The primary path should still be validating DNS and replication, not changing workstation membership or rebooting every machine.

Start with DNS rather than trying to repair the domain trust. Domain controllers should use only internal AD DNS servers, not public resolvers. Verify that each DC can resolve the domain name, its own hostname, the other DC, and the required _ldap, _kerberos, and _msdcs SRV records. Use nslookup and dcdiag /test:dns to check this. Also confirm that the network profile and firewall are still using the domain configuration and that the required AD ports are open between the servers.

Pointing one DC to the other as its preferred DNS server is generally safer during startup than having both depend on themselves, but the final DNS design should include reliable internal DNS on both DCs. DNS forwarders are only for external name resolution; they do not make AD locate a domain controller.