Fix STATUS_DS_INVALID_GROUP_TYPE 0XC00002D4 in AD

This error means you tried to create or modify a security group in Active Directory with an invalid type. The fix is almost always a mismatched group scope.

Yeah, getting STATUS_DS_INVALID_GROUP_TYPE (0XC00002D4) is annoying, especially when you're in the middle of setting up AD groups. But I've fixed this dozens of times — it's almost always a simple scope mismatch. Let's get you sorted.

The Quick Fix: Check Your Group Scope

The error means Active Directory won't accept the group type you're trying to use. The most common cause is trying to nest a global security group inside another global group, or adding a universal group to a domain local group in a way that breaks the rules.

Open Active Directory Users and Computers (ADUC) — run dsa.msc from the Run dialog or Server Manager.
Find the group you're modifying or creating. Right-click it and pick Properties.
Go to the Member Of tab — if you're adding this group to another group, check the target group's scope.
Check the scope on the General tab. It'll say Domain Local, Global, or Universal.

Here's the rule you broke:

Domain local groups can contain: global groups, universal groups, and other domain local groups (but only from the same domain).
Global groups can contain: other global groups — but only from the same domain.
Universal groups can contain: global groups and other universal groups from any domain.

If you're trying to add a global group from domain A into a global group in domain B — that's your problem. Switch the target group to universal or domain local, or create a new group with the right scope.

Quick PowerShell Alternative

If you prefer the command line, run this to check a group's scope:

Get-ADGroup -Identity "YourGroupName" -Properties GroupScope, GroupCategory

To create a new group with the correct scope:

New-ADGroup -Name "NewGroup" -GroupScope Global -GroupCategory Security

Swap Global for Universal or DomainLocal as needed.

Why This Error Happens

Active Directory's group nesting rules are strict for a reason. They prevent loops and keep the Global Catalog efficient. When you try to nest a global group from another domain into a local global group, AD says "nope" — that's a cross-domain violation. The error code 0XC00002D4 is a direct translation of DS_INVALID_GROUP_TYPE.

Another common trigger: you're trying to change a group's scope after it already has members. AD doesn't let you convert a global group to universal if it's already a member of another global group. You'll get the same error.

Less Common Variations

These show up less often, but I've seen each one at least a couple of times:

1. Distribution Group vs Security Group Mismatch

If you're using ADUC and the group type is set to Distribution instead of Security, some operations (like adding to a security group or applying a GPO) will fail with this error. Check the Group type radio button on the General tab — switch it to Security if that's what you need.

2. Universal Group in a Mixed or Windows 2000 Domain

Universal groups only work in Windows 2000 Native or higher domain functional levels. If your domain functional level is still set to Windows 2000 Mixed or Windows Server 2003 Interim, universal groups are blocked. Check this in Active Directory Domains and Trusts — right-click the domain, pick Raise Domain Functional Level. If it's not at least 2003, you can't use universal groups. Raise it (but test first — this is permanent).

3. RODC or Read-Only Domain Controller Issues

If you're trying to create a group on a Read-Only Domain Controller (RODC), the operation might fail with this error if the group type isn't replicated properly. Always create groups on a writable DC. Check which DC you're connected to in ADUC — look at the domain root's properties for the DC name.

4. Custom Script or Application Bug

Sometimes a third-party app or a custom PowerShell script passes the wrong groupType attribute value. The groupType attribute is a bitmask — common values:

-2147483646 = Global Security
-2147483640 = Domain Local Security
-2147483644 = Universal Security
2 = Global Distribution
4 = Domain Local Distribution
8 = Universal Distribution

If the script writes a value that doesn't match these, you get the error. Use ADSI Edit to check the actual groupType value if you're troubleshooting.

Prevention: Set Up Group Naming Standards

This error rarely bites you twice if you follow a few rules:

Use a naming convention that includes scope — like GG-Marketing-Global or DL-Servers-DomainLocal. Makes it obvious what you're working with.
Know your domain functional level before creating universal groups. Check it yearly or when upgrading DCs.
Always create groups on a writable DC — point ADUC to one with Change Domain Controller from the domain root's right-click menu.
Test nesting in a lab OU first. Spend 10 minutes in a test environment instead of an hour debugging the error in production.

That's it. Check the scope, fix the nesting, and you'll be back to normal in under five minutes. If you're still stuck after this, run repadmin /syncall to force replication — sometimes a stale DC is holding onto an old group object that's causing the conflict.