Repair a computer’s corrupted domain trust relationship with PowerShell, no restart required.
What causes a domain computer to lose its trust relationship?
If you’ve been working in an Active Directory environment long enough, you are bound to encounter a domain-joined computer whose membership becomes invalid. Around our office, we call this “falling off the domain” (which seems to be a common term, though I haven’t found its origin).
The two scenarios I have encountered most often when this happens are:
- A VM or system restore has been performed from a backup prior to a computer’s AD password being changed.
- Someone accidentally adds a computer of the same name to the domain, thereby invalidating the current computer.
Windows events related to a computer falling off the domain
When one of these two scenarios occurs, you will see a logon error of “The trust relationship between this workstation and the primary domain has failed.” You will also see the following events in the Windows System log of the computer with the broken trust relationship:
Event 3210 – Error – NETLOGON
This computer could not authenticate with \\<DC NAME>, a Windows domain controller for domain <DOMAIN>, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.
Event 8019 – Warning – DNS Client Events
The system failed to register host (A or AAAA) resource records (RRs) for network adapter
with settings:
<HOST SETTINGS>
The reason the system could not register these RRs was because of a security related problem. The cause of this could be (a) your computer does not have permissions to register and update the specific DNS domain name set for this adapter, or (b) there might have been a problem negotiating valid credentials with the DNS server during the processing of the update request.
Event 130 – Warning – Time-Service
NtpClient was unable to set a domain peer to use as a time source because of failure in establishing a trust relationship between this computer and the ‘<DOMAIN>’ domain in order to securely synchronize time. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The trust relationship between this workstation and the primary domain failed. (0x800706FD)
Repair computer’s trust relationship with domain
In the past, your option for fixing a computer’s trust relationship with the domain was to remove it from the domain, reboot, re-add it to the domain, and reboot. Not exactly a seamless operation, especially if the system is remote.
In PowerShell 3.0, Microsoft introducted the cmdlet Test-ComputerSecureChannel. It is not telling from the name, but this cmdlet can not only check whether a computer’s domain trust is still valid, but it can repair it if it is not!
Using Test-ComputerSecureChannel to check and repair domain trust relationship
Here is how it works. On my afflicted computer, I am going to open an elevated admin PowerShell session. First thing I am going to do is check the current status of the computer’s domain trust relationship. I can do this by issuing the naked cmdlet.
PS C:\Windows\system32> Test-ComputerSecureChannel False
OK. We confirmed our suspicions based on the Windows events we saw in the log. Now let’s work the magic of repairing the trust. I am going to run Test-ComputerSecureChannel with the -Repair parameter.
PS C:\Windows\system32> Test-ComputerSecureChannel -Repair Test-ComputerSecureChannel : Cannot reset the secure channel password for the computer account in the domain. Operation failed with the following exception: The user name or password is incorrect. . At line:1 char:1 + Test-ComputerSecureChannel -Repair + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (Win10A:String) [Test-ComputerSecureChannel], InvalidOperationExceptio n + FullyQualifiedErrorId : FailToResetPasswordOnDomain,Microsoft.PowerShell.Commands.TestComputerSecureChannelComma nd
Why did it fail? Because if you recall earlier, when I attempt to login using a domain user, I was getting the error message “The trust relationship between this workstation and the primary domain has failed.” I am currently signed into the computer using a local Administrator account. I need to use the -Credential parameter and pass in credentials for a domain user that has the rights to add a computer to the domain. To do this, I will use Get-Credential and store it in a variable called $cred. I will then pass that variable into the Test-ComputerSecureChannel cmdlet.
Here is a demo video, as well as the commands and output below.
PS C:\Windows\system32> $cred = Get-Credential cmdlet Get-Credential at command pipeline position 1 Supply values for the following parameters: Credential PS C:\Windows\system32> Test-ComputerSecureChannel -Credential $cred -Repair True PS C:\Windows\system32> Test-ComputerSecureChannel True
You can see the last cmdlet runs returned True to confirm the domain trust relationship is now valid. I was then able to log out of the computer and log back in with a domain user successfully. No restart required!
Reference
- Test-ComputerSecureChannel | docs.microsoft.com
PS C:\Users\aaron> Get-Help Test-ComputerSecureChannel NAME Test-ComputerSecureChannel SYNOPSIS Tests and repairs the secure channel between the local computer and its domain. SYNTAX Test-ComputerSecureChannel [-Confirm] [-Credential <PSCredential>] [-Repair] [-Server <String>] [-WhatIf] [<CommonParameters>] DESCRIPTION The Test-ComputerSecureChannel cmdlet verifies that the channel between the local computer and its domain is working correctly by checking the status of its trust relationships. If a connection fails, you can use the Repair parameter to try to restore it. Test-ComputerSecureChannel returns $True if the channel is working correctly and $False if it is not. This result lets you use the cmdlet in conditional statements in functions and scripts. To get more detailed test results, use the Verbose parameter. This cmdlet works much like NetDom.exe. Both NetDom and Test-ComputerSecureChannel use the NetLogon service to perform the actions. RELATED LINKS Online Version: http://go.microsoft.com/fwlink/?LinkId=821645 Checkpoint-Computer Reset-ComputerMachinePassword Restart-Computer Stop-Computer REMARKS To see the examples, type: "get-help Test-ComputerSecureChannel -examples". For more information, type: "get-help Test-ComputerSecureChannel -detailed". For technical information, type: "get-help Test-ComputerSecureChannel -full". For online help, type: "get-help Test-ComputerSecureChannel -online"
Sem says
hello!
Very good! Very useful!
Thanx!
Chamois says
Noob here.
So quick ?. How did you access powershell on the afflicted computer? Logging in as Admin or another way?
What if you weren’t able to log in as Admin?
Aaron Rothstein says
In this test scenario, I had console access to the VM, so you do need some sort of access at the workstation. I was logged in as local admin, but you could also elevate a PowerShell prompt with admin rights from a non-admin session. Then, you need domain credentials for a user that has rights to add computers to the domain.
Tristian says
I’m getting a server is not operational error message?
Aaron Rothstein says
I haven’t personally encountered that, but here is a Microsoft KB article referencing that error regarding the Domain ‘guest’ account. See if that applies to your situation.
https://support.microsoft.com/en-us/help/837328/you-may-receive-a-the-server-is-not-operational-error-message-when-you
Aaron Rothstein says
Hi Tristian,
I encountered this recently. Issue was the workstation had invalid DNS servers set that could not resolve the domain name / domain controllers.
chad says
thank you so much!!!!! you saved my bacon!!!!
Aaron Rothstein says
Glad to hear it Chad.
Brian says
I hope it will help me, thanks.
Chris M says
I has having this issue on a couple of VMs that were restored from an image. This saved a rebuild. I had to log on as the local admin account through vSphere. Ran the command with -Credential and it came back “true”. Logged off and then logged back in as my domain account. I did a reboot of the server and once it came back online, I was able to RDP into it again as well.
Aaron Rothstein says
Glad to hear it helped!
Naresh says
This is very good for single machine but the big question is why is this happening. In my case this is happening for lot of machines. I am unable to find as what went wrong with my DC or GPO. Anything you found in your case or anything you can suggest.
Matt D Wilson says
Hi,
How would you run this command against several machines at once?
Thanks
Aaron Rothstein says
Hey Matt,
I don’t know if there is a good way to run it against multiple systems at once. Theoretically, you could package this up into an SCCM script which would allow the script to run as SYSTEM on the local computer, but you would need to include domain credentials for repairing the trust, which you probably don’t want to do.
pao says
graciassssssssssssssssssss
BFos says
This just helped me. Thanks! I didn’t know you could specify a credential for Test-ComputerSecureChannel. I have the trust relationship breaking a lot on me in my testing environment where I have VMs hoping back and forth between checkpoints all the time.
Aaron Rothstein says
Glad you found it useful!
Space says
and when Test-ComputerSecureChannel -credential $cred -repair
still returns False as result ?
Aaron Rothstein says
Other factors may be at play. One I encountered recently was the workstation had invalid DNS servers configured, so it couldn’t resolve the domain name / domain controllers.
Ed says
Wow!!! This saved me blowing away my print server and rebuilding it! Thank you so much!
Aaron Rothstein says
Glad to hear it was helpful!
Krishna says
Hi Thank you so much. I restored few VMs after recovering from backups, passwords were changed, and had same issue. This is so simple fix
Steve says
Very useful, I too have saved an awkward situation using your fix. In my instance the local administrator account was disabled too, however, as it was a VM, I disabled the network card so it wasn’t talking to the domain and it allowed me to login using the domain credentials and then run powershell as administrator and use your script.