Fix 0X00000A39: Workstation record not found in NetLogon

This pops up when a domain-joined Windows 10/11 workstation can't find its own computer account in domain NetLogon. The fix is re-creating the account or forcing replication.

When you see this error

You'll hit 0X00000A39 (NERR_RplWkstaNotFound) when a Windows 10/11 Pro or Enterprise machine tries to connect to a domain service—usually during a scheduled login script, GPUpdate, or a remote event log query. The workstation boots fine, you're logged in with cached credentials, but any call to NetServerEnum or NetWkstaGetInfo targeting the domain fails with that hex. The trigger is almost always a stale or missing computer account in Active Directory's NetLogon folder (specifically the workstation's $MACHINE.ACC file).

What's actually happening here

The error translates to "Workstation record was not found on the domain controller." Under the hood, the Local Security Authority (LSA) on your machine holds a shared secret—the machine account password—that must match the one stored in AD. That secret lives in %SystemRoot%\System32\config\SAM (for the local copy) and in the domain NC on the DC. When they don't match, or the AD object itself is gone, the NetLogon service refuses to authenticate the workstation to the domain.

Common causes:

An admin deleted or disabled the computer object in AD Users and Computers
A domain controller restore from backup brought back an older version of the object (USN rollback)
The workstation was renamed without letting AD know—the old name's object still exists but the new name doesn't
Active Directory replication is broken, so a DC the workstation is talking to doesn't have the updated object yet

The fix—step by step

I've fixed this on dozens of machines. Skip the GUI wizardry; use the command line. Here's what works.

Verify the computer object in AD
On a domain controller (or RSAT on your workstation), open Active Directory Users and Computers. Locate the Computers container (or wherever your workstation lives). Is the object there? Disabled? Check the Operating System tab to confirm it matches the machine. If it's missing or disabled, right-click and Enable Account or create it fresh (skip to step 3).
Check replication
If the object exists on one DC but not on the one your workstation is hitting, you've got a replication gap. Open PowerShell as admin on a DC and run:
```
repadmin /replsum
```
Look at the Warnings column. Any failures mean you need to fix replication first. If you don't have time, force replication on the destination DC with:
```
repadmin /syncall /AdeP
```
This forces a full sync from all partners. Wait 30 seconds, then try reconnecting the workstation.
Remove and rejoin the domain (nuclear option, but it works)
On the workstation, log in as local admin. Open PowerShell as admin.
First, disjoin:
```
Remove-Computer -ComputerName localhost -UnjoinDomainCredential Domain\YourAdmin -WorkgroupName WORKGROUP -Force
```
Reboot. Then rejoin:
```
Add-Computer -DomainName yourdomain.local -Credential Domain\YourAdmin -Restart
```
This deletes the stale computer object and creates a fresh one with a new secret.
If you can't disjoin (remote fix)
Use ADSI Edit on a DC to delete the computer object manually. Connect to Default naming context, browse to CN=Computers,DC=yourdomain,DC=local, delete the workstation's object. Then on the workstation run gpupdate /target:computer (it'll fail), but the next time the machine polls, it'll re-create the object if Group Policy is set to allow auto-enrollment of workstations. This is a niche fix—only use if you can't physically touch the machine.
Last resort: reset the machine account password
If the object exists but the password is out of sync, run this on the workstation (as local admin):
```
netdom resetpwd /s:yourDC /ud:Domain\Admin /pd:*
```
This forces the machine to re-sync its secret with the DC. No reboot needed. You'll see The machine password was reset successfully. Now try whatever triggered the error.

If it still fails

Check three things. First, DNS. Run nslookup yourdomain.local on the workstation and verify it returns more than one DC—if only one domain controller is listed, the workstation might be talking to a DC that's missing the object. Second, check the workstation's %SystemRoot%\debug\netlogon.log for lines containing 0xc0000022 or NERR_RplWkstaNotFound—that pinpoints which DC rejected it. Third, verify the workstation's time offset—Kerberos won't work if it's more than 5 minutes off. Run w32tm /query /status and make sure the source is a domain controller, not an external NTP.

If all else fails, wipe the computer object from AD completely, wait 15 minutes, then reboot the workstation. The domain's NETLOGON service will re-create the object on next boot if the workstation has the right permissions. I've seen this happen when an admin accidentally deleted the Domain Computers group from the ACL on the Computers container—check that too.