PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteSome links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
If you mean the Windows error “The trust relationship between this workstation and the primary domain failed,” you usually want to repair the computer’s secure channel, not terminate it. Test and repair it from an elevated PowerShell window on the affected domain-member computer. If you mean permanently removing the computer from a domain—or changing a trust between two domains—use the separate procedures below.
First, identify which trust you mean
“Trust relationship” can refer to different things:
- Workstation or member server ↔ Active Directory domain: A secure Netlogon channel lets the computer and domain authenticate each other. A broken channel commonly involves a mismatch between the computer’s machine password and the password stored for its computer account in Active Directory. A deleted or corrupted account can also be involved.
- Domain ↔ domain or forest: This is an explicitly configured Active Directory trust. It is separate from a workstation’s secure channel.
- Computer being removed from a domain: This means changing its membership to a workgroup and restarting—not repairing a failed secure channel.
A Microsoft Entra ID device relationship is also distinct; it is not automatically the same as an on-premises Active Directory domain trust.
The steps in the first sections are for Windows 10/11 and Windows Server member computers, not domain controllers. For Microsoft’s command and repair guidance, see Join a computer to a domain.
#1 Best Overall
Repair the common workstation error first
Before changing domain membership, make sure you can sign in with a local administrator account, the computer is connected to the corporate network or VPN, and it can reach a domain controller. Use an account authorized to repair or reset the computer account. Check that the computer uses the organization’s correct DNS servers and that its date and time are reasonably synchronized.
Open PowerShell as administrator on the affected member computer and test the secure channel:
Test-ComputerSecureChannel -Verbose
A result of True means the test passed; it does not prove that DNS, Group Policy, profiles, or every application authentication path is healthy. If the result is False, try the repair:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteTest-ComputerSecureChannel -Repair -Credential (Get-Credential)
Enter credentials authorized to reset the computer’s domain relationship when prompted. If the command completes, restart and test again:
Rank #2
Restart-Computer -Force
Test-ComputerSecureChannel -Verbose
The expected test result after a successful repair is True. Microsoft documents this cmdlet for domain-member computers and its -Repair, -Credential, and -Server parameters in Test-ComputerSecureChannel. Do not use it as the primary repair method on a domain controller.
If you need to test against a particular domain controller, specify it explicitly:
Test-ComputerSecureChannel -Server "DC01.example.com" -Verbose
Replace the example server name with a domain controller that is reachable and appropriate for the computer’s domain.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →If the secure-channel repair does not work
First confirm that connectivity and DNS are working and that the intended computer account exists and is enabled in Active Directory. Avoid deleting the account as an initial troubleshooting step; doing so may add recovery work without fixing the cause.
Rank #3
Reset the machine password with PowerShell
On the member computer, run this in elevated PowerShell with an authorized domain account:
$credential = Get-Credential
Reset-ComputerMachinePassword -Credential $credential
Restart-Computer -Force
This resets the machine password used for the computer’s relationship with the domain. If it still fails, an administrator can test or reset the member computer’s connection from Command Prompt using Netdom:
netdom verify COMPUTERNAME /domain:example.com
netdom resetpwd /server:DC01.example.com /userd:EXAMPLEAdminUser /passwordd:*
netdom reset /domain:example.com /userd:EXAMPLEAdminUser /passwordd:*
Substitute the actual computer name, domain, domain controller, and authorized account. The * prompts for the password instead of placing it in the command line. Restart after resetting, then verify the channel again. Microsoft documents Netdom and domain-join troubleshooting at Netdom and Join a computer to a domain.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Another documented member-computer option is:
nltest /sc_reset:example.com
Restart afterward. These commands are alternatives for administrators; do not run every reset command indiscriminately. Choose a method appropriate to the computer and domain, and investigate server-side causes if resets do not hold.
Rank #4
- Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022, 3rd Edition
- ABIS BOOK
- Packt Publishing
If the test passes but sign-in still fails
A passing secure-channel test shifts attention to other dependencies. Check that DNS resolves the Active Directory domain and domain controllers as expected, the VPN or network route is available, and the client can contact the intended controller. Also investigate authentication, policy, or application-specific errors rather than repeatedly resetting the machine password. Microsoft’s domain-join troubleshooting guidance likewise points administrators toward DNS or network problems when the secure-channel test succeeds.
When to remove and rejoin the computer
Moving a computer to a workgroup and joining it to the domain again is a fallback if a repair fails and the account, DNS, network, and Active Directory health have been checked. It is not the first choice for an ordinary secure-channel failure.
- Sign in using a local administrator account and confirm you can continue to access the computer after a restart.
- Record the computer name, domain name, IP and DNS settings, and any needed local administrator credentials. Confirm you have BitLocker recovery information and back up important files.
- Before changing membership, check for EFS-encrypted files, certificate private keys, domain-account services or scheduled tasks, and profile or management-enrollment dependencies.
- Use System Properties or the Windows domain/workgroup settings available on that edition to change the computer from the domain to a temporary workgroup. Labels and menu paths vary across Windows client and Server releases and managed devices. Supply authorized domain credentials if prompted.
- Restart, then join the computer to the domain again using an account allowed to join computers. Restart once more.
- Test domain sign-in and check Group Policy, network resources, certificates, VPN, services, scheduled tasks, and device-management enrollment.
Rejoining does not guarantee that every profile, credential, certificate, private key, or encrypted file will work as before. Back up and confirm recovery access—especially for EFS data—before changing membership. Delete or disable the old computer account only after confirming the device is no longer needed or following your organization’s asset process.
Recommended Free Tools
If the trust is between two domains
For an actual Active Directory domain-to-domain trust, do not use the workstation repair cmdlets. Netdom can verify or reset a domain trust. For example:
netdom trust TrustingDomain /domain:TrustedDomain /verify
netdom trust TrustingDomain /domain:TrustedDomain /reset
The names, direction, and credentials must match the configured trust; a one-way trust is directional, and two one-way trusts can form a two-way relationship. /reset resets the trust secret; it does not delete the trust. For removal, use the appropriate trust-management process in Active Directory Domains and Trusts and verify the effects with the administrators of both domains. Netdom’s documented trust functions and its forest-trust limitation are described in Netdom trust. Netdom cannot create a forest trust; forest trusts are managed through Active Directory Domains and Trusts or an appropriate PowerShell process.
Special cases that need server-side investigation
- Domain controller: Do not use
Test-ComputerSecureChannelas the primary fix; Microsoft warns it can produce false-positive errors on domain controllers. An administrator can verify withnetdom verify DCNAME /domain:example.com. A DC machine-password reset can usenetdom resetpwd /server:HealthyDC.example.com /userd:EXAMPLEAdminUser /passwordd:*, but first assess replication and Active Directory health. See Netdom. - Replication inconsistency or a restored domain controller: Different controllers may hold inconsistent computer-password values. Repeatedly resetting the client may not help; investigate replication and recovery on the AD side. Microsoft describes relevant causes in Client device has a newer password value than Active Directory.
- VDI, snapshots, or cloned images: A restored snapshot or image workflow can repeatedly put stale machine-password data back on a device. Fix the image or provisioning/reset process rather than treating every clone as an unrelated workstation failure. See Microsoft’s guidance on Active Directory having a newer password value than a client device.
- Deleted, disabled, moved, or corrupted computer account: Have an AD administrator inspect the object and its organizational-unit placement before recreating or deleting it.
- No local administrator access: Use an approved recovery or IT support process. Do not bypass organizational controls.
- Azure Windows VM: Follow the relevant environment-specific steps in Microsoft’s broken secure-channel troubleshooting for Azure VMs.
Escalate promptly if multiple computers fail at once, domain controllers disagree, replication is unhealthy, a controller was restored from backup, or the affected computer is a domain controller or production server.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

