0X00002165

Fix ERROR_DS_NO_FPO_IN_UNIVERSAL_GROUPS (0x00002165) on Domain Controllers

Cybersecurity & Malware Intermediate 👁 3 views 📅 Jun 1, 2026

This error pops up when you try to add a foreign security principal to a universal group in a mixed-mode domain. It means the group type or domain mode doesn't support it.

You're migrating users between forests with ADMT, or you're adding a foreign security principal (FSP) from a trusted domain into a universal security group. The operation fails with ERROR_DS_NO_FPO_IN_UNIVERSAL_GROUPS (0x00002165). The error message reads: "Foreign security principals cannot be members of universal groups." This almost always hits when the domain functional level is still at Windows 2000 mixed or Windows Server 2003 interim. The culprit here is almost always a domain that hasn't been raised to at least Windows Server 2003 native mode.

Root Cause

In Active Directory, a foreign security principal is an object that represents a security principal from another forest. Universal groups can contain FSPs only if the domain functional level is set to Windows Server 2003 native or higher. At lower functional levels (Windows 2000 mixed, Windows Server 2003 interim), universal groups don't support FSPs. Microsoft locked this down because the old group expansion logic couldn't handle cross-forest lookups correctly. So if you're still running a domain at a legacy functional level, this error is your roadblock.

The Fix

Don't try to hack the group type or force the membership with ADSI Edit — that'll break replication. The real fix is raising the domain functional level. Here's how to do it step by step.

Step 1: Check Your Current Domain Functional Level

  1. Open Active Directory Domains and Trusts on a domain controller.
  2. Right-click your domain and select Properties.
  3. Look at the Domain functional level field.

If it's Windows 2000 mixed or Windows Server 2003 interim, that's your problem. If it's already Windows Server 2003 native or higher, check Step 4 for other causes.

Step 2: Confirm All Domain Controllers Are Running Supported OS Versions

You can't raise the functional level if any DC is running an older OS. Fire up Active Directory Users and Computers, go to your domain, and check the Domain Controllers OU. Every DC must be running at least:

  • Windows Server 2003 (for 2003 native)
  • Windows Server 2008 (for 2008 level)
  • Windows Server 2008 R2 (for 2008 R2 level)
  • And so on up the chain.

If you have a Windows 2000 Server DC still hanging around, that's blocking you. You'll need to demote or upgrade it first. Don't bother checking the forest functional level unless you're also having forest-wide issues — the domain-level one is what matters here.

Step 3: Raise the Domain Functional Level

  1. In Active Directory Domains and Trusts, right-click the domain and choose Raise Domain Functional Level.
  2. Select the highest level your DCs support. I'd go straight to Windows Server 2016 if everything runs Server 2016 or later. Don't jump to 2019 unless all DCs are on Server 2019 or newer.
  3. Click Raise. Confirm the dialog box.
  4. Wait for replication to complete. You can force it with repadmin /syncall /AdeP on a DC if you're impatient.

Step 4: Retry the Operation

Now try adding the foreign security principal to the universal group again. Use Active Directory Users and Computers, the Add-ADGroupMember PowerShell cmdlet, or whatever tool you were using. Should work now.

Add-ADGroupMember -Identity "YourUniversalGroup" -Members "CN=ForeignPrincipal,CN=ForeignSecurityPrincipals,DC=domain,DC=com"

What If It Still Fails?

Two things can still trip you up even after raising the functional level.

1. The FSP Object Is Corrupted

Sometimes the foreign security principal object itself is messed up. Check it in ADSI Edit. Go to CN=ForeignSecurityPrincipals,DC=yourdomain,DC=com and verify the object's objectClass is foreignSecurityPrincipal and its cn matches the SID of the user from the trusted forest. If the object looks weird, delete it and let AD recreate it when you add the membership again.

2. Replication Delays

If you made changes on one DC but your client or tool is hitting another DC, the new functional level might not have replicated yet. Give it a few minutes or use repadmin /replicate to push the change. Then retry pointing to the specific DC.

One more thing: if you're running ADMT, make sure you're using the latest version (ADMT 3.2) and that the target domain functional level is at least Windows Server 2003 native. ADMT 3.2 won't even let you start a migration to a domain below 2003 native. It's a hard check.

That covers the fix. Raise the functional level, verify FSP objects, and check replication. You'll be done in 10 minutes. Don't overthink it.

Was this solution helpful?

ERROR_DS_NO_FPO_IN_UNIVERSAL_GROUPS 0x00002165 foreign security principal universal group Active Directory domain functional level Windows Server 2016 Windows Server 2019 ADMT cross-forest migration group membership error DS_NO_FPO universal group membership AD error code 0x00002165