0XC00002D6

Fix STATUS_DS_NO_NEST_LOCALGROUP_IN_MIXEDDOMAIN (0xC00002D6) Error

Cybersecurity & Malware Intermediate 👁 0 views 📅 May 27, 2026

This shows up when you try to add a global group from a trusted domain into a local group during a group policy or security operation. The root cause is a domain function level mismatch.

When This Error Hits

You're configuring a Group Policy Object (GPO) security filter or setting up a domain local group on a server. You go to add a global group from another domain in the same forest, click OK, and boom — STATUS_DS_NO_NEST_LOCALGROUP_IN_MIXEDDOMAIN (0xC00002D6). The operation fails, and the group doesn't get added. I've seen this most often when someone tries to nest a global security group from a child domain into a domain local group on a parent domain controller, especially in an environment that still has Windows Server 2003 domain controllers lying around.

Root Cause — It's the Domain Functional Level

This error is Microsoft's way of saying "you can't nest global groups from a trusted domain into a domain local group when the domain is still running at Windows 2000 mixed or Windows Server 2003 interim functional level." Those old functional levels explicitly block this kind of cross-domain group nesting. Why? Because the older security model didn't support universal group caching properly. The real fix is to raise the domain functional level to at least Windows Server 2003 native (or higher, which you should already be on).

If you're still on a mixed domain with a 2003 DC, you're also blocking yourself from using universal groups properly. This isn't just a GPO issue — it breaks any cross-domain group membership you try to set up.

Had a client last month whose entire print queue server lost access because a domain local group couldn't get members from the trusted domain. They had a 2003 DC they forgot about. Raising the functional level fixed it in 10 minutes.

The Fix — Step by Step

  1. Identify all domain controllers. Run Get-ADDomainController -Filter * | Select Name, OperatingSystem in PowerShell. If you see any Windows Server 2003 or 2003 R2, that's your problem. If you see no 2003 DCs, skip to step 4.
  2. Remove or upgrade the 2003 DC. You can't raise the functional level with a 2003 DC still alive. Either upgrade it to a supported OS (2008 R2 or later) or demote and decommission it. Use dcpromo /forceremoval as a last resort if the DC's broken.
  3. Clean up metadata if you removed the DC forcefully. Use ADSI Edit or ntdsutil to remove stale references. Skip this and you'll get replication issues later.
  4. Raise the domain functional level. Open Active Directory Domains and Trusts, right-click your domain, choose "Raise Domain Functional Level," and pick at least Windows Server 2003 native. 2008 or 2012 is better — gives you more features and tighter security. Apply and wait for replication across all DCs.
  5. Test the operation again. Now try adding that global group from the trusted domain into your domain local group. It should work cleanly.
  6. Reboot the machine if the GPO still doesn't apply. Group policy caches group memberships, and a reboot forces a fresh evaluation.

What to Check If It Still Fails

  • Forest functional level. If your forest functional level is also stuck at 2003 interim, raise that too. Same process in Active Directory Domains and Trusts, but right-click the forest root.
  • SID filtering on trusts. If the trust between domains has SID history filtering enabled (which is default for external trusts), you can't use SID history. This won't cause 0xC00002D6 directly, but it can cause access denied errors that look similar. Check trust properties in Active Directory Domains and Trusts.
  • Universal group caching. If you're using universal group caching on your DCs, make sure it's enabled. Without it, cross-domain membership lookups can fail in larger environments. Run Set-ADDomainController -Identity -EnableUniversalGroupCaching $true.
  • DNS resolution. Verify that the domain you're pulling the group from resolves properly. Use nslookup or Resolve-DnsName. If the DC can't find the trusted domain, group lookups fail.
  • Event logs. Check the System and Directory Service logs on the DC for clues. Look for event IDs 1202 (group policy processing) or 1126 (security descriptor errors). They'll point you to the specific group that's causing the issue.

If after all that you still see the error, you've likely got a replication problem — specific groups not syncing between DCs. Use repadmin /replsum to check. But 9 times out of 10, raising the functional level kills this error cold.

Was this solution helpful?