The environment has 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. Its machine account password apparently changed independently, so it no longer matches the password stored in Active Directory.
Both Test-ComputerSecureChannel -Repair and Reset-ComputerMachinePassword, including attempts targeted at the PDC, fail with "Cannot reset the secure channel password for the computer account in the domain" and "A local error has occurred."
Is there a current, reliable procedure for repairing the secure channel and restoring DFSR/SYSVOL replication on Server 2019? Would the older Netdom-based reset procedure still be appropriate, or is demoting, removing, rejoining, and promoting the domain controller again the recommended approach?
3 Answers
This can happen when the affected domain controller changed its machine password while it was isolated. A possible recovery sequence is to first capture the current state with dcdiag /replsummary, then stop and disable the Key Distribution Center service on the affected DC and reboot it. With KDC stopped, reset the machine account password while explicitly targeting the PDC, then reboot again and verify connectivity and replication. If replication starts working, monitor dcdiag /replsummary for a while before setting KDC back to Automatic and rebooting once more so the server resumes issuing Kerberos tickets. Make sure the underlying DNS and network problems are fixed first.
In practice, replacing the affected domain controller is often the lowest-risk option. Try a normal demotion first; if that fails, rebuild the server and perform the required metadata cleanup before promoting a replacement. Domain controllers are generally safest to treat as disposable rather than spending a long time repairing a badly damaged replication state.
The Netdom procedure may still be useful, but it should be performed only after confirming that DNS, time synchronization, connectivity to the PDC, and the computer account state are correct. If the secure-channel reset continues to return a local error, repeatedly forcing password changes or manually repairing DFSR can create a larger problem. With two healthy domain controllers available, a clean demotion and re-promotion is usually more predictable than an extensive repair attempt.
A failed demotion can leave metadata behind, so cleanup is still required afterward. The older manual repair procedures were especially unpleasant in the FRS era, which is why rebuilding is commonly preferred when there are other healthy DCs available.