Fix 0x00000710 Workstation Trust Account Error

Cause #1: Stale Computer Account Password in Active Directory

Most of the time, this error happens because the computer account password stored on the workstation doesn't match what Active Directory has. Every domain-joined machine rotates its account password every 30 days by default. If that rotation fails even once, you get a trust break. The exact error 0x00000710 pops up when a service tries to log on using a computer account as if it were a user account — like running a scheduled task with the SYSTEM account or using an old service that references the machine account.

Fix: Reset the machine account password

You'll need an account that has permission to reset computer accounts. Domain Admins work, but Account Operators also have rights. Here's the cleanest way:

1. Log on to the affected workstation with a local admin account. If you can't log on at all, use a domain account that has local admin rights on that box.
2. Open Command Prompt as Administrator. Click Start, type cmd, right-click it, choose Run as administrator.
3. Run this command to check the current trust status:

   nltest /sc_verify:yourdomain.com

   Replace yourdomain.com with your actual domain name. You'll see something like I_NetLogonControl failed: Status = 5 0x5 ERROR_ACCESS_DENIED — that's a dead giveaway.
4. Run this to force a password reset and re-establish trust:

   netdom resetpwd /s:yourdomaincontroller /ud:yourdomain\adminaccount /pd:*

   Replace yourdomaincontroller with the DC's FQDN, yourdomain\adminaccount with a domain admin account, and yourdomain.com with your domain. You'll be prompted for the password. After it runs, you should see The machine account password has been reset successfully.
5. Reboot the machine. Then try to access a network share or run gpupdate /force to confirm the trust is working.

That fixes it for most people. But if netdom gives you an access denied or you still see the error after the reboot, read on.

Cause #2: Computer Account Is Disabled or Deleted in AD

Sometimes the problem isn't a password mismatch — the computer object in Active Directory is missing or disabled. This happens when someone cleans up stale accounts, or when the machine was reinstalled without removing the old AD object. The error shows up when the System account or a service tries to authenticate, and the DC can't find a valid computer account to match.

Fix: Verify and re-enable or recreate the computer object

1. On a domain controller or a machine with RSAT tools installed, open Active Directory Users and Computers.
2. Find the computer object under the correct OU. Right-click it, select Properties. Check the Account tab — if the account is disabled, uncheck Disable account and click OK.
3. If the object isn't there, you need to rejoin the domain. Log on as local admin, join a workgroup, reboot, then rejoin the domain. This creates a fresh computer object.
4. If the object exists but is orphaned (old SID, different GUID), the cleanest fix is to delete the object and rejoin. Right-click the computer, select Delete, confirm.
5. On the workstation, open System Properties (Win + Pause/Break), go to Computer Name tab, click Change. Set Workgroup to WORKGROUP, reboot.
6. After reboot, go back to System Properties, join the domain again. Enter domain credentials when prompted. You should get a Welcome message.

Expect a reboot after removing and rejoining. Don't skip that — you'll get weird access issues if you don't.

Cause #3: Misconfigured Service or Scheduled Task Using the Computer Account

Here's the sneaky one. This error often appears when a service or scheduled task is set to run as Local System or Network Service, but the task or service is trying to access a remote resource that expects a user account. The remote server sees the computer account and rejects it with 0x00000710. I've seen this most often with SQL Server Agent jobs, custom backup scripts, and scheduled PowerShell scripts that try to map network drives.

Fix: Change the service or task to use a real user account

1. Press Win + R, type services.msc, press Enter.
2. Find the service that's throwing the error. Right-click it, select Properties.
3. On the Log On tab, instead of Local System Account, select This account. Enter a domain user account that has the necessary permissions, and fill in the password twice.
4. Click OK, then restart the service.
5. If it's a scheduled task, open Task Scheduler. Find the task, right-click, Properties. Go to the General tab. Change the user account to a domain user (not SYSTEM). Make sure Run whether user is logged on or not is selected, and store the password.

After you change that, the error should stop. Watch the event log for a while to confirm.

One more thing — if the error appears during an interactive logon (like when you try to log on to the console), it's almost always cause #1 or #2. Services trying to use the computer account cause the error in the background, and you'll see it in the System or Application event logs.

Quick Reference Table

Start with the netdom resetpwd fix — that resolves about 80% of these. If it doesn't work, check AD. And if that doesn't do it, look at the services. In my experience, the trust account issue is rarely the hardware's fault. It's almost always a broken relationship between the workstation and the DC.