STATUS_DS_GLOBAL_CANT_HAVE_LOCAL_MEMBER: Fix 0xC00002D7

You clicked Add on a global group, picked a local group, and AD threw 0xC00002D7 in your face. Annoying, but the error is doing exactly what it should.

Short version: you picked the wrong group scope on one of the two sides. Fix the scope, re-add the member, done. Here's how.

The Fix

Ask yourself one question: is the group you're adding as a member a local group, a domain local group, or another global group? That determines the fix.

Case 1 — You tried to make a Domain Local group a member of a Global group

This is the one that triggers the error 90% of the time. Global groups in a domain can only contain:

• User accounts from the same domain
• Computer accounts from the same domain
• Other global groups from the same domain

They cannot contain Domain Local groups or Universal groups from anywhere. If that's what you're doing, flip the nesting. Make the Global group a member of the Domain Local group instead.

# Wrong direction — this throws 0xC00002D7
dsmod group "CN=G-Sales,CN=Groups,DC=corp,DC=local" -addmbr "CN=DL-ShareAccess,CN=Groups,DC=corp,DC=local"

# Right direction
dsmod group "CN=DL-ShareAccess,CN=Groups,DC=corp,DC=local" -addmbr "CN=G-Sales,CN=Groups,DC=corp,DC=local"

Alternatively, if you genuinely need to nest in the original direction, change the outer group's scope from Global to Domain Local or Universal. That's rarely the right call though — it breaks the AGDLP pattern most shops run on.

Case 2 — Local groups on a member server or workstation

If you're on a machine not running AD DS and you try to add a local group (like Power Users) as a member of a domain-based global group, that also fails. Local SAM groups can't be members of AD groups at all. No scope change fixes this. You have to flatten the membership — add the users individually.

# This will fail against a global group
net group "G-Helpdesk" /domain /add "BUILTIN\Power Users"

# Do this instead — enumerate and add users one by one
net localgroup "Power Users"

Case 3 — You're using the GUI and the picker let you select the wrong object

ADUC's object picker is dumb about this. It'll happily let you select a Domain Local group when you're editing a Global group's membership, then only tell you at write time. Stop using the GUI picker for bulk group edits — use PowerShell:

Add-ADGroupMember -Identity "G-Sales" -Members "CN=JSmith,OU=Users,DC=corp,DC=local"

PowerShell at least fails fast and gives you a readable error instead of the raw NTSTATUS code.

Why This Happens

AD group scopes aren't aesthetic choices. They map to which security principals can be replicated across domain boundaries and which can grant access to resources.

Global groups are designed to hold accounts from their own domain so they replicate to the Global Catalog. If you nested a Domain Local group inside a global group, that membership would have to replicate to every GC in the forest — and domain local memberships aren't stored in the GC. So the design says no.

Universal groups can contain users, global groups, and other universal groups from any domain in the forest — but still not domain local groups, because those don't replicate. Domain local groups can contain anything from anywhere, which is why they're the ones that get assigned permissions to resources.

Rule of thumb: A-G-DL-P. Accounts go in Global groups. Global groups go in Domain Local groups. Domain Local groups get Permissions. You can't shortcut this and AD will smack you every time you try.

Quick reference

Less Common Variations

0xC00002D7 when importing a group via CSV or LDIF

Bulk imports love to hit this. Someone exports members from one group and pipes them into another without checking scopes. The import tool processes 500 entries, fails on entry 42, and if it's not transactional you end up with a half-populated group. Check the source and target scopes before you run the import, not after.

Trust-crossing memberships

If you're adding a group from a trusted domain into a local domain's group, the same rules apply but the error gets murkier. A Domain Local group in your domain can hold a Global group from the trusted domain — that's fine. Trying to do it the other way around is what breaks. Confirm the direction with:

Get-ADGroup -Identity "GroupName" -Properties GroupScope,Members |
  Select-Object Name,GroupScope,Members

Migrated groups from ADMT

ADMT sometimes drops scope information during a cross-forest migration and the resulting group is global when it needs to be domain local. If you're post-migration and suddenly a group that worked for years won't accept members, check its scope first.

Set-ADGroup -Identity "G-Sales" -GroupScope DomainLocal

You can only widen scope (Global → Universal → Domain Local is not actually a valid chain — Global to Universal works, but Global to Domain Local does not, you'd have to recreate the group). Check before you commit.

Prevention

Do these three things and you'll never see 0xC00002D7 again in your environment:

1. Enforce AGDLP in your naming convention. Name global groups G-Something and domain local groups DL-Something. When a junior admin tries to nest a DL under a G, the name mismatch is a red flag before AD even complains.
2. Audit group scopes quarterly. Run Get-ADGroup -Filter * -Properties GroupScope | Group-Object GroupScope and look for Global groups with suspiciously high member counts — those are usually scopes-that-should-have-been-universal waiting to break.
3. Script your group changes. GUI pickers hide scope. PowerShell and dsmod don't. If a group change is a one-liner in a ticket, it should be a one-liner in a script, not five minutes of clicking through ADUC.

The error looks intimidating because of the NTSTATUS hex. It isn't. It's AD telling you the scope you picked doesn't support the member you picked. Change one of them and move on.