Fix ERROR_DS_LOCAL_MEMBER_OF_LOCAL_ONLY (0x2164)

What Causes This Error

The error ERROR_DS_LOCAL_MEMBER_OF_LOCAL_ONLY (0x00002164) shows up when you try to add a domain local group to a group that lives in a different domain. Domain local groups are a special breed — they can only be members of other domain local groups in the same domain. This is by design in Active Directory. You can't nest them across domains.

I've seen this happen most often when IT folks are building cross-domain trust setups and try to add a universal group or global group from another domain to a domain local group. Or when someone scripts a group membership change and doesn't check the group scope first.

The Most Common Fix: Check Group Scopes

Why It Happens

The culprit here is almost always a scope mismatch. You're trying to add a domain local group to a group in a different domain. Active Directory doesn't allow it.

How to Fix It

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the group you're trying to add to. Right-click and go to Properties.
3. Check the Group scope tab. If it says Domain local, you can only add members from the same domain.
4. Change the target group to Universal or Global if you need cross-domain nesting. Or just create a new group in the other domain.

Important: Changing a domain local group to universal or global might break existing permissions. Test in a lab first. I've had to roll back changes more than once because someone didn't check what permissions relied on that group.

Second Common Cause: Wrong Group Type in Scripts

Why It Happens

Automated scripts often hardcode group DN paths. If you move a group between OUs or domains, the script can still try to add a domain local group from Domain A to a group in Domain B. The error code is the same — 0x00002164.

How to Fix It

1. Check any PowerShell or VBScript that modifies group membership. Look for lines like Add-ADGroupMember or dsmod group.
2. Verify the -Identity parameter points to a group that's in the same domain as the group you're modifying.
3. If you need cross-domain membership, use universal groups instead. Those can contain members from any domain in the forest.

Example fix in PowerShell:

# Wrong: adding domain local across domains
Add-ADGroupMember -Identity 'CN=MyLocalGroup,OU=Groups,DC=DomainA,DC=com' -Members 'CN=OtherGroup,OU=Groups,DC=DomainB,DC=com'

# Right: use universal group
# Create universal group first
New-ADGroup -Name 'MyUniversalGroup' -GroupScope Universal -GroupCategory Security -Path 'OU=Groups,DC=DomainA,DC=com'

Then add members from any domain.

Third Common Cause: Replication Latency or Stale Data

Why It Happens

Sometimes the error isn't really about scope — it's about stale group data. If you recently changed a group's scope from domain local to universal, but the domain controller you're querying hasn't replicated yet, AD still sees it as domain local. This gave me a headache on a Windows Server 2008 R2 domain controller that was offline for two days.

How to Fix It

1. Force replication between domain controllers: repadmin /syncall /AdeP
2. Check replication status: repadmin /showrepl
3. Wait 15–30 minutes after replication, then try the group membership change again.
4. If you're in a hurry, use a domain controller that's in the same site as the target group.

Don't bother with restarting the NTDS service unless replication is completely broken. That rarely helps here.

Quick-Reference Summary

That's it. This error is annoying but straightforward once you know the rules. Domain local groups are meant for resource access within a single domain. Don't try to bend AD's design — work with it.