A Server 2012 R2 domain controller was moved to a different Hyper-V host and upgraded to Server 2025. It is currently the only domain controller, and the old and new systems were not running together. Since the change, some domain-joined PCs intermittently report, "The trust relationship between this workstation and the primary domain failed." Running Test-ComputerSecureChannel -Repair restores access, but I'm concerned this is masking an underlying problem. What could be causing the trust failures, and what would be a reliable permanent fix? An additional domain controller is planned, but the environment currently has only one.
3 Answers
Verify time synchronization too. Kerberos is sensitive to clock differences, and virtualized domain controllers can get unreliable time if they constantly inherit time from a Hyper-V host that is itself unsynchronized. Configure a proper time hierarchy: the forest-root PDC emulator should use a reliable external source, other domain controllers should follow it, and clients should follow the domain. Avoid having the DC continually switch between host time and domain time.
The most likely cause is that the domain controller was copied or restored while the original was still being used. A computer account has its own password, and if a workstation changed that password against the old DC after the copy was made, the replacement DC would not know about the newer value. The workstation and DC then disagree, producing the trust error. Repairing the secure channel updates the computer account on the current DC, so it can be a permanent fix for each affected machine—as long as the old DC is no longer coming back online. Also check for snapshots, duplicated DCs, or stale DNS records.
That makes sense if the upgraded server was created from an image of the old one. I’d make sure the original is permanently offline and then repair or rejoin any machines that still have mismatched computer-account passwords.
Treat the single-DC setup and the in-place upgrade as risks that need correcting, not just symptoms to work around. Confirm Active Directory and DNS health, check replication-related and system event logs, and make sure the DC has a stable IP and correct DNS configuration. Build at least two fresh, properly prepared Server 2025 domain controllers, transfer or establish the required roles, verify DNS and authentication, and then demote the questionable upgraded controller. Do not bring an old copy or snapshot of the same DC back onto the network.
Check the Hyper-V integration settings and the host’s NTP configuration. A few minutes of drift can cause authentication failures even when the secure channel itself is healthy.