Fix ERROR_DS_INVALID_SEARCH_FLAG_TUPLE (0x000021B3)

Error 0x000021B3: What it actually means

I know this error makes you want to throw your keyboard. I've seen it pop up when you're trying to modify an attribute in Active Directory Schema or promote a domain controller. The core issue: one or more attributes in your schema have a TUPLE search flag set and an msDS-IntId (internal ID) that's either missing, zero, or incorrectly assigned. The TUPLE flag (bit 0x00000004) requires a valid msDS-IntId to work properly. Without it, AD slaps you with 0x000021B3.

This typically happens after a schema import from another forest, a manual attribute edit, or a botched LDIFDE import. I once spent three hours chasing this because a junior admin copy-pasted a schema class without updating the internal IDs.

Preliminary check (30 seconds)

Before diving deep, make sure the attribute you're working on actually needs the TUPLE flag. TUPLE indexing is for substring searches on string attributes (like cn or sn). If you're setting it on an integer attribute or a DN, you'll get this error every time.

1. Open Active Directory Schema snap-in (register it with regsvr32 schmmgmt.dll if you haven't).
2. Locate the offending attribute. If you don't know which one, skip to the moderate fix below.
3. Right-click the attribute → Properties → Attribute tab.
4. Check Index this attribute and Tuple-index (if both are checked). If Tuple-index is checked but the attribute syntax isn't a string (Unicode, IA5, etc.), uncheck it immediately.

Skipping this step is why most people burn 20 minutes on nothing. I can't count the times someone checked Tuple-index on an Integer attribute and got nowhere.

Moderate fix: Find the bad attribute with ADSI Edit (5 minutes)

If you don't know which attribute triggered the error, or the schema snap-in doesn't show it, use ADSI Edit to scan for the culprit.

1. Open ADSI Edit (install via RSAT if needed).
2. Connect to Default naming context → expand CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
3. Right-click CN=Schema → Find.
4. In the Advanced tab, paste this LDAP filter:

   (&(searchFlags:1.2.840.113556.1.4.803:=4)(|(msDS-IntId=0)(!(msDS-IntId=*))))

5. Click Find. This returns attributes that have the TUPLE flag set (bit 4) but have a missing or zero msDS-IntId.
6. For each result, right-click → Properties.
7. Locate searchFlags and note its current value. Also check msDS-IntId — if it's empty or 0, that's your problem.

I've seen this filter save hours of manual hunting. Write down the attributes' cn (common name) and their searchFlags values — you'll need them in the advanced fix.

Advanced fix: Correct the schema attribute (15+ minutes)

Now we fix the actual attribute. You have two paths: remove the TUPLE flag or assign a valid msDS-IntId. I recommend the first because it's cleaner and avoids potential replication conflicts.

Option A: Remove the TUPLE flag

This is my go-to unless you explicitly need tuple indexing (e.g., for substring searches on names).

1. Open an elevated PowerShell prompt (Run as Administrator).
2. Import the Active Directory module: Import-Module ActiveDirectory.
3. For each bad attribute, run this (replace cn-of-attribute with the actual name):

   $attr = Get-ADObject "CN=cn-of-attribute,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Properties searchFlags
   $newFlags = $attr.searchFlags -band (-bnot 4)
   Set-ADObject $attr -Replace @{searchFlags=$newFlags}

4. Verify: Get-ADObject "CN=cn-of-attribute,CN=Schema,..." -Properties searchFlags — the value should no longer have bit 4 set (e.g., if it was 7, now it's 3).

Important: You must be a member of Schema Admins and the Schema Operations Master (FSMO) must be reachable. If the schema is read-only, transfer the role first from another DC.

Option B: Assign a valid msDS-IntId (if you need tuple indexing)

If you absolutely must keep the TUPLE flag (maybe for a business app that queries substrings), assign a non-zero, unique internal ID.

1. First, find the next available msDS-IntId. Open ADSI Edit, browse to the Schema container, and find an attribute with a high msDS-IntId (like >100000). You can use this filter:

   (&(objectClass=attributeSchema)(msDS-IntId=*))

2. Sort by msDS-IntId descending. Pick a value that's, say, 10 higher than the highest (e.g., if highest is 130205, use 130215).
3. In PowerShell, assign it:

   Set-ADObject "CN=bad-attribute,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Replace @{'msDS-IntId'=130215}

This is riskier — a duplicate msDS-IntId can break replication. I've seen whole forests stall because someone reused an internal ID. Test in a lab first.

Verification and next steps

After either fix, run repadmin /syncall /AdeP on the schema FSMO to force replication. Then try your original operation (schema update, DC promotion, etc.) again. If you still get the error, you missed an attribute — re-run the LDAP filter from the moderate fix.

One more thing: if you're dealing with a third-party schema extension (like Exchange or Lync), do not manually edit those attributes. Contact the vendor or restore schema from backup. I've seen people brick an Exchange organization by fiddling with its search flags.

Pro tip: Always export the Schema container before making changes: ldifde -f schema-backup.ldf -d "CN=Schema,CN=Configuration,DC=yourdomain,DC=com". You'll thank me later.

If this fixed your issue, great. If not, you might be dealing with a corrupted schema — that's a post for another day. Drop a comment below and I'll help narrow it down.