Fix ERROR_DS_NONEXISTENT_MAY_HAVE (0X000020C3) in AD Schema

What's happening here?

You're trying to modify a class in your Active Directory schema — maybe you're adding a new attribute to a user or computer class. But Windows throws back error 0X000020C3 (ERROR_DS_NONEXISTENT_MAY_HAVE).

The message is simple: the attribute you listed in the class's mayHave or mayContain section doesn't exist in the schema. Either you typed the wrong name, the attribute was deleted, or someone never created it in the first place.

You'll see this most often when applying a schema extension from a third-party app (like Exchange, Skype for Business, or a line-of-business tool) that didn't fully install the required attributes. Or you're editing the schema manually and mistyped an attribute name.

Let's sort this out. I'll start with the quickest check, then move to the deeper fixes.

Quick check (30 seconds): Look for obvious typos

1. Open ADSI Edit on a Domain Controller (or a machine with RSAT installed). Go to Start > Run > adsiedit.msc.
2. Right-click ADSI Edit in the left pane and choose Connect to.
3. In the Connection Settings window, set Select a well known Naming Context to Configuration. Click OK.
4. In the tree, expand CN=Configuration, DC=yourdomain, DC=com > CN=Schema, CN=Configuration.
5. Find the class that's failing (e.g., CN=User). Double-click it.
6. Look at the Attribute Editor tab. Scroll to mayContain. Double-click it.
7. You'll see a list of attribute LDAP display names. Check for any typo — a misspelled attribute name like msExchUid instead of msExchUID.
8. If you find a typo, correct it. Click OK and Apply. Then try your schema update again.

That's the easy one. Nine times out of ten, it's a simple spelling mistake. If the name looks fine, move on.

Moderate fix (5 minutes): Verify the attribute actually exists

The attribute name might be correct, but the attribute object itself is missing. Here's how to confirm.

1. In ADSI Edit, still in the Schema container, press Ctrl+F to open the Find dialog.
2. Set Find to Attribute (not Class).
3. Type the exact attribute name you saw in the mayContain list. Click Find Now.
4. If no results appear, the attribute doesn't exist. That's the cause of your error.
5. Now you have two choices:
   • Option A: Remove the missing attribute from the mayContain list (if you don't need it). Go back to the class's mayContain, select the bad entry, click Remove. Apply. Done.
   • Option B: Create the missing attribute yourself (covered in the next section).

Warning: If this is part of a schema extension from a vendor (Exchange, SharePoint, etc.), removing the attribute from the class will break the application. You need to create the attribute properly. Don't skip that step.

Advanced fix (15+ minutes): Create the missing attribute

If you need the attribute, you'll create it manually. You'll need Schema Management Console or you can do it with a PowerShell script. I'll show you both.

Using the Schema Management Console (GUI)

1. Register the Schema Management DLL. Open a command prompt as Administrator and run:

   regsvr32 schmmgmt.dll

2. Open MMC (Start > Run > mmc).
3. Go to File > Add/Remove Snap-in. Add Active Directory Schema.
4. In the left pane, right-click Active Directory Schema and choose Create Attribute.
5. Fill in the details:
   • Common Name: The friendly name (e.g., MS-Exch-UID).
   • LDAP Display Name: The exact name that appeared in the mayContain list (e.g., msExchUID).
   • Unique X.500 OID: You must provide a valid OID. If you don't have one, use a temporary OID from your organization's root. Do not reuse Microsoft OIDs — that will cause conflicts. If you're recreating a vendor attribute, look up their OID from their documentation.
   • Syntax: Choose the correct syntax (e.g., Unicode String for text).
   • Minimum/Maximum: Leave blank unless you know a specific range.
6. Click OK to create the attribute.
7. Now go back to the class's mayContain in ADSI Edit and Add the new attribute by its LDAP display name.
8. Click OK, then Apply. The schema update should complete now.

Using PowerShell (faster if you're comfortable)

If you have the AD PowerShell module installed, you can do this in three lines:

# Connect to the schema master
$schema = Get-ADRootDSE | Select-Object -ExpandProperty schemaNamingContext

# Create the attribute (change names and OID as needed)
New-ADObject -Name "msExchUID" -Type "attributeSchema" -Path $schema -OtherAttributes @{
  attributeID = "1.2.840.113556.1.4.7000.100.100"
  attributeSyntax = "2.5.5.12"
  isSingleValued = $true
  lDAPDisplayName = "msExchUID"
  adminDescription = "Exchange UID attribute"
}

# Add it to the User class
Add-ADObject -Identity "CN=User,$schema" -Add @{mayContain = "msExchUID"}

After running that, test your schema update again. It should pass.

What if none of this works?

There's a rare case where the attribute exists but is disabled. In ADSI Edit, find the attribute object, check the isDefunct attribute. If it's TRUE, set it to FALSE, then add it to the class. This happens when someone retired an attribute but the class still references it.

Also verify you're making these changes on the Schema Master DC. Schema updates only work on the server holding that FSMO role. To find it, run netdom query fsmo in a command prompt.

Once you've fixed the missing attribute, the 0X000020C3 error should be gone. You'll be able to complete your schema update without issue.