0xC00002D8: Global group can't have universal member

Cause #1 — Someone nested a universal group inside a global group

This error fires when Active Directory catches a cross-scope violation. Global groups can only contain other global groups or user accounts from the same domain. Universal groups can contain anything — users, global groups, other universal groups — but a global group cannot contain a universal group. The error code 0xC00002D8 is Windows' way of saying "that's not allowed."

I've seen this most often when someone fat-fingers a group membership change in ADUC, or when a script bulk-adds members without checking group scope. It also pops up during cross-forest migrations where an admin adds a universal group from another domain to a local global group. The error hits immediately — you won't get a delayed failure here.

Fix: Find the offending member and remove it

1. Open Active Directory Users and Computers (ADUC). Make sure you're viewing advanced features (View → Advanced Features).
2. Locate the global group that triggered the error. Right-click → Properties → Members tab.
3. Scan the list for any group with a scope of "Universal." That's your culprit. Remove it.
4. If you can't see the scope in ADUC, run this PowerShell command on a domain controller:

Get-ADGroupMember -Identity "YourGlobalGroup" | Where-Object {$_.objectClass -eq "group" -and (Get-ADGroup $_.DistinguishedName -Properties GroupScope).GroupScope -eq "Universal"} | Remove-ADGroupMember -Identity "YourGlobalGroup" -Members $_.DistinguishedName

That one-liner finds all universal groups nested inside your global group and removes them. Test it with -WhatIf first if you're skittish.

Cause #2 — A replication conflict or lingering object

Less common but still real: if you have multiple domain controllers and someone adds a member to a group right after the group's scope was changed from universal to global, the replication schedule can cause a temporary mismatch. One DC thinks the group is still universal, another thinks it's global — and when the membership change replicates, the check fails.

This also happens with lingering objects (orphaned group members from a DC that was offline too long and didn't tombstone properly).

Fix: Force replication and check for lingering objects

1. Run repadmin /syncall /AdeP from an elevated command prompt on your PDC emulator. This forces a full replication across all DCs.
2. After replication completes, retry the group membership change.
3. If the error persists, check for lingering objects using repadmin /removelingeringobjects against the domain partition. Be careful — this can break things if you don't know which DC is the authoritative source.

repadmin /removelingeringobject    /advisory_mode

Run it with /advisory_mode first to see what it would delete. Only remove if you're certain the source DC is correct.

Cause #3 — Schema or functional level mismatch

This one's rare but I've hit it twice in 14 years. If your domain functional level is Windows Server 2008 or lower, universal groups don't exist (or have restrictions). The domain functional level determines what group scopes are available. Universal groups require Windows Server 2008 or higher. If you're at 2003 functional level, you can't even create universal groups, let alone nest them.

But the error 0xC00002D8 can also appear if the schema was extended but the functional level wasn't raised — so the objects exist but the rules haven't caught up.

Fix: Raise the domain functional level

1. Open Active Directory Domains and Trusts.
2. Right-click your domain → Raise Domain Functional Level.
3. Select Windows Server 2016 or 2019 (depending on your environment). Windows Server 2022 also works fine.
4. Click Raise. This requires Enterprise Admin privileges and all DCs to be running the new minimum OS version.

You can't lower the functional level after this, so check your DCs first. Run Get-ADDomain | fl DomainMode in PowerShell to see the current level.

Quick-reference summary

In 90% of cases, it's cause #1. Don't overthink it. Find the bad membership, kill it, move on. If that doesn't work, check replication. The functional level thing is a last resort. I'd also recommend adding a change control step in your group management process — scripts that check group scope before adding members will stop this error from coming back.