ERROR_DS_NO_NEST_GLOBALGROUP_IN_MIXEDDOMAIN (0X00002142) Fix

Yeah, this error stops you cold mid-migration or group policy setup. Let's skip the hand-wringing and get it fixed.

The fix: raise the domain functional level

Open Active Directory Domains and Trusts, right-click your domain, select Raise Domain Functional Level. Choose Windows Server 2003 or higher. Click OK. Wait for replication across all domain controllers (usually a few minutes). That's it—the error disappears.

# Or via PowerShell, run this on a domain controller:
Set-ADDomainMode -Identity "yourdomain.local" -DomainMode Windows2003Domain

The reason this works: the mixed domain functional level (Windows 2000) explicitly blocks nesting global security groups inside other global groups. Microsoft designed it that way to maintain backward compatibility with pre-2003 domain controllers that couldn't handle it. Once you bump to 2003 or later, that restriction lifts.

Why this happens

Active Directory has three group scopes: domain local, global, and universal. Nesting rules differ by functional level. In a mixed domain (Windows 2000 functional level), global security groups can't be nested—period. The error code 0X00002142 tells you exactly that. What's actually happening here is your domain still runs at that legacy level, probably because an old domain controller isn't ready or you inherited a migration project.

The trigger is often adding a global group as a member of another global group via ADUC or a script. You'll see the error message and a red exclamation. The domain controller refuses the operation, and the event log logs it under NTDS event ID 1981.

Alternative fix: use universal groups

If you can't raise the functional level (say, you still have Windows 2000 domain controllers you can't decommission yet), don't nest global groups. Instead, create a universal security group and nest your global groups inside that. Universal groups can contain global groups even in mixed mode. But there's a catch: universal groups require global catalog access, so you need at least one GC per site.

# Create a universal group via ADUC or PowerShell:
New-ADGroup -Name "NestedUniversal" -GroupScope Universal -GroupCategory Security

Then add your global group as a member. This bypasses the restriction without touching the functional level.

Less common variations

1. Distribution groups don't have this problem. Yes, you can nest global distribution groups in mixed mode. The restriction only applies to security-enabled groups. If your use case allows it, convert the group to distribution mode (though you lose security token membership).

2. The error appears in a cross-forest trust scenario. If you're nesting a global group from one forest into a global group in another forest, the same error pops up. The fix is the same—raise the domain functional level in the target forest or use universal groups there.

3. Windows Server 2008 R2 still supports mixed mode. If you're on 2008 R2 or older, you might still see this error. Even if all your DCs are 2012+, a domain functional level does not auto-upgrade. You have to do it manually.

Prevention

First, never leave a domain at Windows 2000 functional level unless you absolutely have to. Any domain controller running 2003 or later can handle 2003 functional level. The only reason to stay mixed is backward compatibility with legacy apps that need Windows 2000 DCs—and those should be long gone.

Second, use universal groups for cross-domain or cross-forest nesting. They're more flexible and don't require raising the domain level. But beware: universal groups replicate to the global catalog, so don't create thousands of them without planning.

Third, before you start any group restructuring, check your functional level with a simple PowerShell command:

Get-ADDomain | fl Name,DomainMode

If it's Windows2000Domain or Windows2003InterimDomain, you're going to hit this error. Fix it before you script yourself into a corner.

That's it. No fluff. Raise the level or switch scopes. Both work.