Fix ERROR_LAST_ADMIN 0x52A — Last admin account can't be removed

What's actually happening here

You're seeing ERROR_LAST_ADMIN (0X0000052A) because Windows detected you're trying to disable or delete the only account with administrator privileges on the machine. The system blocks this to prevent you from locking yourself out. This isn't a bug — it's a safety catch, and it's been around since Windows NT.

Most people hit this when cleaning up old user accounts after a migration, or when they've been running with a single admin account and decide to remove it (usually the built-in Administrator or a renamed personal account). The fix isn't complicated, but you have to work with Windows' rules, not against them.

Most common cause: You have one admin account and tried to delete or disable it

The most common trigger is simple: you're logged into the only admin account, open Local Users and Groups (lusrmgr.msc) or Settings > Accounts, and try to remove or disable that account. Windows immediately returns 0x52A.

What Windows doesn't tell you right away: you need at least two admin accounts before you can remove one. The built-in Administrator account (SID ending in -500) counts, but if it's disabled (default on most Windows 10/11 systems), it doesn't count as a valid active admin for this check.

Fix: Create a second admin account first

Press Win + R, type cmd, right-click and run as Administrator.

Run this to create a new local admin account:

net user TempAdmin StrongPassword123! /add
net localgroup Administrators TempAdmin /add

Log out of your current account, log into TempAdmin.
Now you can delete or disable the original admin account using:

net user OldAdminName /active:no
REM or
net user OldAdminName /delete

Why this works: Windows checks the number of active admin accounts at the moment of the operation. With TempAdmin active, your original admin is no longer the last one. Note: if you disable the account instead of deleting it, Windows still counts it as an admin account — so you may need to delete it if the error persists.

Second cause: The built-in Administrator account (SID-500) is disabled but you're trying to disable another admin

Windows 10/11 disable the built-in Administrator by default. But when you check admin count, Windows ignores disabled accounts for the purpose of this error. So if your only enabled admin account happens to be a renamed one, and you try to disable it, you get 0x52A — even though there's a disabled built-in Administrator sitting there.

Fix: Enable the built-in Administrator, then proceed

Open Command Prompt as Admin.
Enable the built-in account:
```
net user administrator /active:yes
```
Set a password on it (required for security — never leave it blank):
```
net user administrator SomeStrongPassword123!
```
Now you can disable or delete your other admin account. The built-in one takes the role of "last admin."
If you want, disable the built-in Administrator again after you're done (but only if you have another enabled admin).

The gotcha: The built-in Administrator has special behavior — even when disabled, some group policy checks treat it differently. But for the ERROR_LAST_ADMIN check specifically, a disabled account doesn't count. You have to enable it.

Third cause: Domain-joined machines where the last local admin is being removed

If your machine is domain-joined, you might have domain admins that can log in. But the error 0x52A only cares about local admin accounts on the machine, not domain groups. So even if you're a domain admin, removing the last local admin account will still trigger this error.

Fix: Use the domain to create a local admin via Group Policy or PowerShell

From an elevated PowerShell on the machine (run as a domain admin):

net user TempAdmin StrongPwd789! /add
net localgroup Administrators TempAdmin /add
net localgroup "Administrators" "DOMAIN\YourDomainAdmin" /add

Wait — that last line adds a domain admin to the local Administrators group. Now you have two admin accounts: the domain admin (via group membership) and the new local TempAdmin. Now you can safely remove the old local admin.

Why this matters: Some IT admins rely on "Domain Admins" group being added to local Administrators via Group Policy. But if that policy hasn't applied yet, or if the machine is offline, the domain admin isn't actually a local admin at that moment. Always verify with:

net localgroup Administrators

If you see DOMAIN\Domain Admins (or your own account) listed there, you're good. If not, you're still the last admin.

Quick-reference summary table

Scenario	Symptom	Fix
Single admin account, trying to delete/disable it	Error 0x52A immediately	Create a second admin account via `net user` + `net localgroup`
Built-in Administrator is disabled, you're disabling your personal admin	Error 0x52A even though built-in exists	Enable built-in Administrator with `net user administrator /active:yes`
Domain-joined, removing last local admin	Error 0x52A despite being domain admin	Add domain admin to local Administrators group, then remove local admin

If none of these work, check for Group Policy that restricts who can be a local administrator — look in secpol.msc under Local Policies > User Rights Assignment for "Deny log on locally" or "Deny access to this computer from the network." But that's rare — 95% of the time it's one of the three scenarios above.