We have an Active Directory environment with two domain controllers, both recently migrated from Windows Server 2019 to fully patched Windows Server 2025 using a side-by-side setup. A few Windows 11 25H2 clients intermittently show "The trust relationship between this workstation and the primary domain failed" during sign-in, usually after waiting one or two minutes. Disconnecting the computer from the corporate network allows the user to sign in with cached credentials. Rejoining the affected computers to the domain and running Test-ComputerSecureChannel -Repair has not provided a lasting fix; one machine broke again after only two days. The issue affects roughly three or four computers, while other clients work normally. Domain controller time synchronization appears correct, and the clients have unique SIDs. What should we check to identify the underlying cause?
4 Answers
The timing suggests the controller migration is worth investigating rather than repeatedly repairing individual clients. Verify AD replication, DNS configuration, controller event logs, and the health of the migrated domain-controller roles. If the environment is still unstable, testing with a freshly installed supported server version may help determine whether the issue is specific to the current Server 2025 deployment.
Make sure there is no duplicate computer name in the domain or on the network. A second device using the same hostname, or a stale computer object being reused incorrectly, can cause the machine password and secure-channel state to become inconsistent.
Since the issue began a month or two after the domain controllers were migrated, check replication health between the two controllers. Confirm that both controllers agree on the computer account password and that DNS is returning the correct domain-controller records. A replication delay or lingering DNS problem can make a repaired secure channel fail again.
For an isolated machine, signing in with a local administrator account and running Test-ComputerSecureChannel -Repair is usually the quickest repair and avoids completely removing and rejoining the computer. If that does not hold, remove the computer account from Active Directory, then join the machine again. Be careful to check integrations that depend on the computer object, such as device-management or deployment systems.
I tried the secure-channel repair and also removed and recreated the computer account before joining the machine again, but the problem returned on one client after two days.
The affected machines do not have duplicate SIDs, and I will also verify that their computer names are unique and that no stale objects are conflicting with them.