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 approach. A few Windows 11 25H2 clients intermittently fail to sign in after waiting one or two minutes with the message: "The trust relationship between this workstation and the primary domain failed."
Disconnecting the client from the corporate network allows users to sign in with cached credentials. Rejoining the domain and running `Test-ComputerSecureChannel -Repair` fixes the affected machines temporarily, but one computer lost its trust again after only two days. The issue affects only three or four machines, and it began roughly one or two months after the domain controllers were upgraded. Time synchronization appears correct, and the domain or forest functional levels were not raised. What should we check to find the underlying cause?
5 Answers
Check the basics that can cause the secure channel to break repeatedly: AD replication health between both domain controllers, DNS configuration on the clients, and the computer account’s location and status. Also verify that no other device is using the same hostname. A duplicate computer name or stale computer object can make the machine authenticate against the wrong account.
Because the failures started after the domain controller migration, compare event logs from the affected clients and both DCs around the failure time. Look for Netlogon, Kerberos, DNS, and replication errors. Confirm that the new DCs are advertising the correct SRV records and that clients can consistently reach the same domain controllers. A secure-channel repair will not solve an underlying replication or name-resolution problem.
A full domain leave and rejoin is reasonable for an isolated machine, but remember that deleting or recreating its AD computer object can affect management systems and certificates tied to that object. For only a few clients, document the affected computer accounts, check their Netlogon events, and compare their DNS, network path, and applied policies with a healthy workstation.
For a quick recovery, sign in with a local administrator account and run `Test-ComputerSecureChannel -Repair -Verbose` in PowerShell. If that does not hold, remove the computer account from Active Directory, reset or delete the corresponding local relationship, and join the machine to the domain again. Since the trust is breaking again after a few days, treat that as a symptom rather than the permanent fix.
Some administrators have reported instability with newer domain-controller builds, but it is better to confirm the cause through logs before downgrading. Verify that every Server 2025 update is installed, review the migration and promotion logs, and validate the domain with tools such as `dcdiag` and `repadmin /replsummary`. If the problem began only after the migration, testing with a freshly installed, fully patched domain controller may help distinguish an operating-system issue from a configuration or replication issue.
The client SIDs are unique, and the issue is limited to a few computers. I’ll check for duplicate hostnames and investigate replication and DNS more closely.