0X00002166

Fix ERROR_DS_CANT_ADD_TO_GC (0X00002166) Attribute Replication Blocked

Cybersecurity & Malware Advanced 👁 9 views 📅 May 26, 2026

That error means you're trying to add a security-sensitive attribute to the Global Catalog, and AD won't let you. You'll need to edit the schema or work around it.

This one's a head-scratcher, but the fix is clean

I know seeing ERROR_DS_CANT_ADD_TO_GC (0X00002166) after you spent ages crafting a schema extension is maddening. You're not alone—this hit me hard on a Windows Server 2019 deployment when I tried adding a custom msExch* attribute to the Global Catalog. The error is clear: Active Directory says nope, that attribute can't live in the GC for security reasons. But you can override it if you have the right permissions and know the flag to flip.

The quick fix: change the attribute's attributeIsMemberOfPartialAttributeSet flag

Here's what you do. Open ADSI Edit (it's a standard tool on Domain Controllers) and connect to the Schema partition.

  • Go to CN=Schema,CN=Configuration,DC=yourdomain,DC=com
  • Find the attribute you're trying to add to the GC (e.g., CN=myCustomAttribute-OID)
  • Right-click it, choose Properties
  • Locate attributeIsMemberOfPartialAttributeSet and set it to TRUE

That's it. The error won't pop again because you're telling AD explicitly: yes, I know this attribute is sensitive—add it anyway.

Why this happens and how AD stops you

Microsoft hard-coded a list of protected attributes that can't be added to the Global Catalog by default. The GC replicates a subset of attributes to all domain controllers for fast searches. Some attributes—like unicodePwd, domainPassword, or anything containing credential material—are blocked to prevent security leaks. The error code 0X00002166 fires when you try to add an attribute that's flagged internally as security sensitive. The flag attributeIsMemberOfPartialAttributeSet is the master switch.

When that flag is FALSE (default for most attributes), AD checks the attribute's searchFlags for a bitmask value. If bit 3 is set (0x00000008), the attribute is automatically excluded from the GC—even if you mark it otherwise. So the real fix is flipping attributeIsMemberOfPartialAttributeSet to TRUE and also clearing that bit from searchFlags if it's there.

Checking and clearing the searchFlags

If setting the flag alone doesn't work, check searchFlags. In the attribute's properties, look at that value. If it's 0x00000008 or any value where bit 3 is on (like 0x0000000A), you need to clear it. Use ADSI Edit to change searchFlags to 0 (or the original value minus 8).

# PowerShell alternative—run as Schema Admin
Set-ADObject -Identity "CN=myAttribute,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Replace @{attributeIsMemberOfPartialAttributeSet=$true; searchFlags=0}

I've seen people forget to clear searchFlags and then wonder why the GC still rejects the attribute after 15 minutes. The replication cycle checks both flags.

Less common variations: what else triggers 0X00002166

This error can also fire when you're using ADSI Edit to add an attribute to the partialAttributeSet directly, not through the Schema snap-in. The schema snap-in has a checkbox for "Include in Global Catalog" that handles the flag automatically. But if you're script-happy like I sometimes am, you might try setting partialAttributeSet via LDAP—that's where you'll see the error. Also, if you're on a read-only domain controller (RODC), you can't modify schema at all. Make sure you're connecting to a writable DC.

Another gotcha: Some attributes are system-critical and Microsoft won't let them in the GC even if you flip both flags. Examples: objectGUID, objectSid, nTSecurityDescriptor. If yours is one of those, you're out of luck—create a separate attribute and map the data.

Preventing this from coming back

Start with a schema design review before any extension. If you're adding an attribute that might hold sensitive data (like a password hint, user ID for another system), don't try to GC-enable it. Plan for a smaller attribute set. Also, always test schema changes on a lab DC first—one wrong flag and you're looking at a forest recovery scenario. Use repadmin /syncall after the change to force replication to the entire domain.

And if you're managing a new forest, consider enabling Active Directory Recycle Bin before any schema modifications. That way if a flag goes sideways, you can roll back without restoring from backup. I learned that the hard way on a Windows Server 2022 upgrade—three hours of panic followed by a restore from tape.

Stick to the Schema snap-in for adding attributes to the GC. It validates the operation and prevents you from shooting yourself in the foot. The error 0X00002166 is AD's way of saying are you sure?—so be sure before you flip that bit.

Was this solution helpful?