You tried to add a domain group to a local group and Windows told you to take a hike with STATUS_DS_LOCAL_MEMBER_OF_LOCAL_ONLY (0xC00002E5). Annoying, but the fix is straightforward once you know the rule that's biting you.
The quick fix
Find the domain group that's currently a member of the local group, and remove it. Then add the user or computer accounts you actually wanted.
Open an elevated Command Prompt or PowerShell on the machine and run:
net localgroup "Administrators"
Look at the output. If you see something like CONTOSO\Helpdesk-Admins in there, that's your culprit. It's a domain group sitting inside a local group.
Remove it:
net localgroup "Administrators" "CONTOSO\Helpdesk-Admins" /delete
If you're doing this via PowerShell instead:
Remove-LocalGroupMember -Group "Administrators" -Member "CONTOSO\Helpdesk-Admins"
Once the domain group is out, add whichever account you actually needed:
net localgroup "Administrators" "CONTOSO\jsmith" /add
That's it. Error gone. If you were trying to nest a domain group inside a local group on purpose, you need a different approach — more on that below.
Why this happens
Windows has hard rules about group nesting, and they're not suggestions. The rule that's biting you here: a local group can only contain other local groups from the same machine. It cannot contain domain groups. Period.
The technical reason is scope. A local group lives on one machine, in that machine's SAM database. A domain group lives in Active Directory on a domain controller. When you add a domain group as a member of a local group, Windows gets confused about how to resolve membership across the two security databases, so it refuses.
There's a related rule too, and it trips people up constantly: a domain local group can only contain members from its own domain (plus accounts from trusted domains in some configurations). If you try to slap a global group from another forest into a domain local group, you get a close cousin of this error.
What you can do:
- Local group → local group (same machine): allowed
- Local group → user account (local or domain): allowed
- Local group → computer account: allowed
- Local group → domain group: blocked (0xC00002E5)
The typical real-world trigger: you're setting up a server, you want the Helpdesk team to have admin rights, and a colleague's old script or a blog post told you to add DOMAIN\Helpdesk to the local Administrators group. Windows now blocks that path directly, which is why you're staring at this error instead of getting on with your day.
What to do if you really need domain group nesting
If your goal is to get a whole team of domain users into a local group, you've got two sane options.
Option 1: Use Group Policy (Preferred)
This is the right answer on any domain-joined machine you care about. Set it up once via GPO and let it apply across your fleet.
- Open Group Policy Management on a DC or admin workstation.
- Edit the GPO that targets your servers or workstations.
- Navigate to
Computer Configuration → Policies → Windows Settings → Security Settings → Restricted Groups. - Right-click, choose Add Group, and enter
Administrators. - Under "Members of this group", add the domain group you want.
GPO handles the plumbing. It's the only scalable way to do this, and it survives rebuilds.
Option 2: Add individual domain users
If it's just one or two people, skip the group altogether and add them directly:
net localgroup "Administrators" "CONTOSO\jsmith" /add
net localgroup "Administrators" "CONTOSO\agarcia" /add
Manual, ugly, doesn't scale. But it works and it's fast.
Option 3: Nest inside Active Directory instead
If you control AD, the clean pattern is:
- Create a global group with your users (e.g.,
GG-Helpdesk). - Create a domain local group on the target resource's domain (e.g.,
DL-ServerAdmins). - Add
GG-HelpdesktoDL-ServerAdmins— this works, global-in-domain-local is fine. - Add
DL-ServerAdminsto the local Administrators group on each server.
That last step still hits the same wall if DL-ServerAdmins is a domain group. So even this needs GPO or manual addition. Yes, it's annoying. Microsoft knows.
Less common variations
Error when adding through the GUI
Same error, same cause. The "Add" dialog in lusrmgr.msc or Computer Management doesn't always show the underlying NTSTATUS code — it just says "The operation is not allowed" or similar. Run the net localgroup command to see the real error.
0xC00002E5 during domain controller promotion
If you hit this while running dcpromo or Install-ADDSDomainController, it usually means a leftover local group on the box still has a domain group as a member, and the promotion process is trying to migrate membership. Pre-clean the local groups before promotion:
net localgroup "Administrators"
net localgroup "Remote Desktop Users"
net localgroup "Backup Operators"
Remove any domain group members from those lists, then retry the promotion. This one bit me on a 2016 server upgrade a while back — a stale entry in Backup Operators blocked the whole thing.
Error on workgroup machines
On a workgroup box, this error shouldn't really appear because there are no domain groups. If it does, someone's been editing the SAM database with tools like ntrights or a third-party utility and left a phantom SID behind. Wipe the local group and rebuild it:
net localgroup "Administrators" /delete
net localgroup "Administrators" /add
Then re-add the local accounts you need. Do this on a test box first if the machine is production.
Nested local groups breaking unexpectedly
Local groups can nest into other local groups on the same machine, but not across machines. If you're trying to make a local group on ServerA a member of a local group on ServerB, that's the error you'll see. There's no workaround — use AD groups and GPO.
Prevention
A few habits will keep you out of this mess:
- Stop adding domain groups to local groups manually. Use Group Policy Restricted Groups or Group Policy Preferences → Local Users and Groups. It's the supported path and it's auditable.
- Audit local group membership on your servers regularly. A quick PowerShell sweep across your fleet will surface stale entries before they break something like a DC promotion.
- Document your AD group structure. Global → Domain Local → local group on the resource. That's the pattern Microsoft's been pushing since Windows 2000 and it still works.
- Test on a non-production machine first. Any change to local group membership on a DC or a critical server deserves a dry run.
Handy one-liner to audit local Administrators groups across a list of servers:
$servers = Get-Content C:\scripts\servers.txt
foreach ($s in $servers) {
Invoke-Command -ComputerName $s -ScriptBlock {
Get-LocalGroupMember -Group "Administrators"
} | Select-Object @{n='Server';e={$s}}, Name, ObjectClass
}
Run that once a quarter. You'll catch a lot of small problems before they get big.