A broken trust relationship exists because the computer account password Server1 has stored locally no longer matches the password value AD DS holds for the Server1$ computer account, and repairing the secure channel requires both sides of that shared secret to be resynchronized to the same value. Set-ADAccountPassword -Identity " Server1$ " -Reset changes only the AD DS side of that shared secret: it sets a new password value on the computer account object as stored in the directory, but it has no mechanism to also update the local secret Server1 itself has cached, since Set-ADAccountPassword is an Active Directory module cmdlet that operates purely against the directory over LDAP/Kerberos and never touches a computer ' s local machine-account secret store. After running this cmdlet, the two sides of the secure channel are now mismatched in the opposite direction from before (AD DS has the new password, Server1 still has the old one), which does not restore the trust relationship at all and can, in practice, leave the account in exactly the same broken state or worse. Restoring the secure channel properly requires a cmdlet or tool that updates both sides together, such as Test-ComputerSecureChannel -Repair or Reset-ComputerMachinePassword run from Server1 itself, neither of which this solution uses, so this solution does not meet the goal.