Fix 0X00000910: Computer Not Active in This Domain

Yeah, this error sucks. You try to access a network share or run a domain-specific tool, and Windows throws 0X00000910 — "The computer is not active in this domain." The domain trust is broken. Here's the fix I've used at least 200 times in the last decade.

The Direct Fix: Rejoin the Domain

Don't bother with gpupdate /force or DNS flushes. The trust relationship between your computer and the domain controller is dead. You need to break it and re-establish it.

1. Log in with the local Administrator account. If you don't know the password, you'll need to reset it via a bootable tool or another admin account.
2. Open PowerShell as Administrator.
3. Run this command to leave the domain cleanly:

Remove-Computer -UnjoinDomainCredential (Get-Credential) -Force -Restart

Enter domain admin credentials when prompted. The machine will restart into a workgroup (usually WORKGROUP).

4. After reboot, rejoin the domain:

Add-Computer -DomainName "yourdomain.com" -Credential (Get-Credential) -Restart

Use a domain admin account again. Reboot once more. Done.

Why This Works

Error 0X00000910 means the domain controller no longer recognizes your machine's computer account in Active Directory. Usually happens when:

• A sysadmin deleted the computer object from AD by accident.
• The machine was restored from a backup that's older than the domain password change (every 30 days by default).
• You cloned a VM without running Sysprep.

Rejoining forces a new computer account to be created with a fresh machine password. That's the only way to fix the trust.

Variations of This Issue

Sometimes the error shows up as "The trust relationship between this workstation and the primary domain failed" in a dialog box. Same root cause. Same fix.

On Server 2016 or 2019, you might see "The computer is not active in this domain" when trying to add a server to a cluster. Do the same rejoin procedure — but back up any cluster configuration first.

Another variation: on Windows 10 1809 and older, the error occasionally triggers after a failed netdom password reset. In that case, skip netdom entirely and use the PowerShell method above. It's more reliable.

Prevention: Don't Let It Happen Again

• Never delete a computer object in AD without decommissioning the machine properly. If you need to retire a PC, unjoin it from the domain first.
• Set a reminder to reset machine passwords. By default, Windows changes the computer account password every 30 days. If your backup restore goes back further than that, you're asking for trouble.
• Use Sysprep before cloning VMs. Running sysprep /generalize /oobe resets the machine SID and domain state. Without it, every clone will eventually get this error.
• Enable the "Domain member: Maximum machine account password age" GPO. Set it to something sane like 30 days. But don't set it to 0 (never expires) — that's a security risk. Rotating passwords is good.

Pro tip: If you have dozens of machines hitting this error after a domain controller crash, don't manually rejoin each one. Use a startup script with Test-ComputerSecureChannel -Repair. It'll fix the trust for any machine that can still authenticate. Saves hours.

That's it. You're back in the domain. Took ten minutes. Next time you see 0X00000910, you'll know exactly what to do.