After the restore: why a Windows server can lose its trust with the domain

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A familiar recovery story goes like this. A physical server fails, or a bad change has to be undone. The team restores an image from a few months ago. Windows starts, the sign-in screen appears, and every domain account is refused with a message about the trust relationship between the workstation and the primary domain.

That message alone does not establish whether the backup is sound. The server has come back with an old copy of its own password, and the domain has moved on.

This article explains how a domain member's computer password works, which kinds of restore put it at risk, and what Microsoft documents for checking and repairing the trust. It ends with the preparation that makes the repair possible, because the repair usually has to happen at a moment when domain sign-in does not work.

The commands named here come from Microsoft's documentation. They were not run for this article.

Every domain computer has a password

When a Windows computer joins an Active Directory domain, it gets a computer account, and that account has a password like any other. Microsoft's security policy reference puts it simply: in Active Directory–based domains, each device has an account and password.

The computer uses that password to build what Microsoft calls the secure channel with domain controllers. Microsoft explains that machine account passwords are used to establish secure channel communications between members and domain controllers, and that once established, the secure channel carries information needed for authentication and authorisation decisions. When the secure channel cannot be built, domain sign-in on that computer fails.

The password changes itself, about every 30 days

Nobody types this password. The computer changes it automatically. Microsoft states that by default, the domain members submit a password change every 30 days. The interval is set by the policy Domain member: Maximum machine account password age, and Microsoft recommends keeping it at about 30 days.

Three details from Microsoft's Directory Services team explain the behaviour after a restore. They come from an archived post on the machine account password process:

• The computer drives the change, not Active Directory. The post says machine account passwords do not expire in Active Directory and are exempt from the domain's password policy. A computer turned off for three months simply changes its password when it next starts and finds a domain controller.
• The computer and directory must retain compatible password information. The archived post contradicts itself about the update order, so that order is not used as a recovery assumption here.
• Both sides keep two passwords: current and previous. The post explains that each Windows-based computer maintains a machine account password history containing the current and previous passwords. If the current password has not been received, Windows falls back on the previous one. It continues: if the sequence of password changes exceeds two changes, the computers involved may be unable to communicate.

That last point is the heart of the restore problem.

Why an older image breaks the trust

A disk image or bare metal backup includes the computer's local copy of its password. Restoring the image puts that old password back.

Meanwhile, Active Directory still holds whatever the computer last changed its password to before it failed. In our reading of Microsoft's description:

• If the computer has changed its password once since the backup, the restored password matches the domain's "previous" password. The secure channel can usually still be built, and the computer will change its password again in due course.
• If the computer has changed its password twice or more since the backup, the restored password matches neither of the two the domain holds. The restored value can then fall outside the accepted history. Treat this as a possible cause, not a diagnosis established from the change count alone.

A default interval describes normal password changes, not a guarantee about backup age. Actual changes, administrative resets, replication and offline periods determine whether the restored secret can still be accepted. Check the secure channel and diagnose failures rather than classifying an image as safe merely because it is only weeks old.

Other ways to land in the same place

The same mismatch can come from:

• Rolling back a virtual machine to an old checkpoint or snapshot. The principle is the same as a disk image.
• System Restore. Microsoft's post notes that if you use System Restore after a password change and restore the computer to a point before the password changes, the next password change may not occur when it is due, because Windows treats the restore as if the password were changed.
• Non-persistent images. Microsoft describes non-persistent virtual desktops and embedded devices that start from a read-only image, where a password change that was made during normal operations would be lost as soon as the session ends.

When the domain controller is the one restored

There is a mirror case. If a domain controller is restored to an older point, it comes back holding older copies of every computer's password. In a domain with other healthy domain controllers, our understanding is that a normal (non-authoritative) restore picks up newer changes by replication from its partners. A domain with a single domain controller has no partner to learn from. A member one password change ahead may still match through its previous password; the existence of any post-backup change does not by itself prove broken trust. Restoring domain controllers requires its own Microsoft recovery guidance. Here it is enough to know that the symptom on member computers looks the same.

What the failure looks like

The best-known symptom is a sign-in message along the lines of "The trust relationship between this workstation and the primary domain failed". Microsoft's troubleshooting article for Windows virtual machines in Azure gives the cause plainly: the machine can't establish a secure communication with a domain controller in its domain, because the secret password isn't set to the same value in the domain controller. That article is written for Azure virtual machines, but the cause it describes is the same Active Directory mechanism on any domain member.

Other symptoms follow, in our reading, from the same cause rather than from Microsoft's text. They include services that run as domain accounts failing to start, file shares on the server refusing domain users, and scheduled tasks failing. All of these depend on the server being able to talk to a domain controller on behalf of a domain account.

Checking the secure channel

Microsoft documents a PowerShell cmdlet for this exact job. Test-ComputerSecureChannel is described as testing and repairing the secure channel between the local computer and its domain, by checking the status of its trust relationships.

Some points from its reference page:

• It returns True when the channel works and False when it does not. With -Verbose, it prints a plain message about whether the secure channel is alive.
• -Server lets you test against a specific domain controller, which helps when you suspect one domain controller holds different information from the others.
• It only works on domain member computers. Microsoft warns that on domain controllers it returns false positive errors, and points to netdom.exe or nltest.exe for domain controllers instead.

A sensible post-restore check, in our recommendation, is to run this test on every restored member server before handing it back to users. It takes seconds and turns a surprise into a known item on the recovery checklist.

Choosing a repair after diagnosis

Microsoft documents secure-channel repair and computer-password reset as distinct operations. Domain rejoin is another intervention with effects on the machine’s identity and dependent services. These are not an automatic sequence to run whenever a check fails.

The domain owner should establish connectivity, identity and replication state, then select the version-appropriate member-computer procedure with the required local and domain permissions. Preserve a working local sign-in path and identify application dependencies before changing the account. This article deliberately provides no executable repair recipe and does not apply these member-server operations to domain controllers.

What to prepare before you need it

These are our recommendations, drawn from the mechanism above rather than from a single Microsoft procedure.

Keep a working local administrator path for every server. When the trust fails, you need to sign in without the domain. Know how you will do that for each server, for example with a managed local administrator password solution, and test that the local account works. A recovery plan that depends on a domain sign-in to repair the domain trust has a gap.

Know who holds the right to reset computer passwords. The repair cmdlets ask for credentials with permission to reset a computer account. Confirm which accounts or groups have it, and make sure someone on the recovery team can use one.

Record the age of each restore point. If a restore point is older than about two password changes, allow for trust diagnosis and a possible approved repair in the recovery time. Check the actual password-change policy and history; elapsed time is not a reliable pass or fail test.

Test after every restore, not only the ones that look old. Test-ComputerSecureChannel is quick. Make it part of the checklist alongside services, shares and applications.

Do not "fix" restores by turning off password changes. Microsoft's guidance on Domain member: Disable machine account password changes is blunt: don't enable this policy setting. Microsoft warns that devices that can no longer change their machine password are at risk of a malicious user determining it. The policy reference also says that significantly increasing the interval gives an attacker more time to undertake a brute-force password-guessing attack. Microsoft describes narrow cases, such as non-persistent virtual desktops, where the policy may be considered, and even then recommends planning password changes for maintenance windows.

Treat domain controllers separately. Do not run the member-server cmdlets against a domain controller and read the result as true. Use the tools Microsoft names for domain controllers and follow Microsoft's domain controller restore guidance.

A short recovery checklist

For a restored member server, our suggested order is:

1. Before the restore, note the age of the restore point and have local administrator access ready.
2. After the restore, start the server with network access to a domain controller.
3. Sign in with the local administrator account.
4. Run Test-ComputerSecureChannel and read the result.
5. If it fails, establish the cause and have the domain owner choose the applicable documented repair; do not automatically progress through resets and domain rejoin.
6. Once the trust is healthy, check services that run under domain accounts, file shares and scheduled tasks.
7. Record what happened, including the restore point's age, for the next recovery plan.

Risks and limits

• The "two changes" behaviour and the 30-day default come from Microsoft's policy pages and an archived Directory Services post. There is no universal two-month restore limit.
• The PowerShell cmdlets are documented for Windows PowerShell 5.1. Check their availability on your Windows version.
• The Azure troubleshooting article is written for Azure virtual machines. We cite it for the Active Directory cause and repair order, which are not specific to Azure.
• Repair and rejoin steps change the computer's domain relationship. Test them in a lab first.
• None of the commands was run for this article.

Sources

Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.

• Microsoft Learn, archived Windows 10 IT pro policy reference: Domain member: Maximum machine account password age
• Microsoft Learn, archived Windows 10 IT pro policy reference: Domain member: Disable machine account password changes
• Microsoft Learn (archived Ask the Directory Services Team blog): Machine Account Password Process
• Microsoft Learn: Test-ComputerSecureChannel (PowerShell 5.1)
• Microsoft Learn: Reset-ComputerMachinePassword (PowerShell 5.1)
• Microsoft Learn: Troubleshoot a failed trust relationship in an Azure Windows VM

This article was originally published on 13 November 2026.