I have a domain with one primary domain controller and two secondary domain controllers. The primary and one secondary still replicate normally, but the other secondary stopped replicating after a networking problem. It appears that the affected DC changed its machine-account password, so its local password no longer matches the version stored in Active Directory.
Attempts to repair the secure channel with Test-ComputerSecureChannel -Repair and Reset-ComputerMachinePassword -Server PDC01 both fail with "Cannot reset the secure channel password for the computer account in the domain" and "A local error has occurred."
What is the current, safest way to recover DFSR and domain-controller replication on Windows Server 2019? Is it still reasonable to use the KDC service workaround or Netdom to reset the DC password, or is demoting, unjoining, rejoining, and repromoting the affected controller the recommended approach? I would prefer not to rebuild it unnecessarily, but I also do not want to risk damaging the domain by trying an outdated repair procedure.
3 Answers
I would avoid blindly following older DFSR or FRS repair videos. First determine whether the failure is only the secure channel or whether SYSVOL and AD replication are also unhealthy. Netdom can still be useful when the prerequisites are correct, but it will not overcome broken DNS, connectivity, time, or Kerberos conditions. If the KDC workaround and a targeted machine-password reset do not restore replication cleanly, rebuilding the DC is usually the more supportable choice.
A common recovery sequence for this specific machine-password and Kerberos situation is to work on the affected domain controller, first capture a baseline with dcdiag /replsummary, then stop and disable the Kerberos Key Distribution Center service. Reboot the DC, reset its machine password while explicitly targeting the PDC emulator, and reboot again. Once connectivity and replication begin working, monitor dcdiag /replsummary for a while before setting the KDC service back to Automatic and rebooting once more. Make sure DNS, time synchronization, and network connectivity are healthy before doing this, and verify replication rather than assuming the password reset fixed everything.
In practice, replacing the damaged DC is often the safer and faster option. Try a normal demotion first, but if that fails, remove the server and perform the required metadata and DNS cleanup before building a replacement with a new name and promoting it again. Domain controllers are generally best treated as rebuildable infrastructure; spending hours on an uncertain repair can create more risk than starting over.
That is my concern with a failed demotion: cleanup can be just as involved as the repair, and I want to avoid leaving stale metadata or DNS records behind. I will verify the replication and Kerberos prerequisites before deciding.