ERROR_DS_DUP_MSDS_INTID (0X00002195): Fix Duplicate msDS-IntId Schema Error

You ran an ldifde -i import or used the Schema Management MMC, and Windows threw ERROR_DS_DUP_MSDS_INTID (0X00002195): Schema update failed: Duplicate msDS-IntId. That's AD telling you the attribute you're trying to add already uses an internal ID that's taken. The fix isn't to guess — it's to find the exact attribute holding that msDS-IntId and change one of them.

Cause 1: The msDS-IntId You're Importing Already Exists on Another Attribute

This is the one you'll hit 9 times out of 10. You (or whoever wrote the LDIF) hardcoded an msDS-IntId value like 0x80000001 because you copied it from another forest. That value is already assigned to a different attribute in this schema. AD won't let two attributes share the same internal ID — it's designed to break replication if it did.

Real-world trigger: you're deploying a third-party app (say, an identity management tool) that ships an LDIF with sample msDS-IntId values. The vendor tested it in a lab forest, not yours.

Here's how to find the conflict. Open PowerShell as Enterprise Admin on the schema master:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter 'msDS-IntId -eq 0x80000001' -Properties msDS-IntId, lDAPDisplayName | Select-Object lDAPDisplayName, msDS-IntId

After running that, you should see one attribute returned — the existing owner of that ID. Note the lDAPDisplayName. Now decide:

1. If you don't need the existing attribute, skip ahead — don't delete core schema objects. Bad idea.
2. The real fix: pick a new msDS-IntId that isn't taken. Use a value in the 0x80000100–0x8000FFFF range, which AD reserves for third-party extensions.
3. Edit your LDIF, change the msDS-IntId:: line to your new value, and re-import.

Confirm the new ID is free before importing:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter 'msDS-IntId -eq 0x80000100' -Properties msDS-IntId

If nothing comes back, that ID is yours to use. After re-running ldifde -i -f yourfile.ldf -k, you should see "The command has completed successfully" and no error 0x2195.

Cause 2: Stale Schema Object Left Over From a Failed Import

You tried the import before and it half-failed. AD rolled back the replication but left a partially-created attribute object behind. Now when you retry, the leftover object already claims the msDS-IntId, and the new attempt can't grab it.

Trigger scenario: someone ran the LDIF, it errored with a different code (usually a naming violation or constraint issue), and then they re-ran it without checking the schema. Now you get 0x2195 on top of the original mess.

Find orphaned attributes — objects with systemFlags that include the "not replicated" or "dynamically created" bits, or attributes with a whenCreated timestamp matching your failed attempt:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter {whenCreated -gt '2024-01-01'} -Properties whenCreated, lDAPDisplayName, msDS-IntId | Sort-Object whenCreated

That lists every schema object added after January 1, 2024. If you see an attribute name you don't recognize and a creation date matching your broken import, that's your orphan. Delete it with ldifde -d:

ldifde -d "CN=yourAttributeName,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -f delete.ldf -m
ldifde -i -f delete.ldf

After deletion, wait for replication. Check with repadmin /showrepl . Once the schema container shows consistent, retry your original import.

Don't touch attributes with isCriticalSystemObject=TRUE. Deleting those breaks AD permanently. If the orphan has that flag set, restore the schema from a system state backup instead.

Cause 3: You Imported Into the Wrong Partition or Forest

This one's sneaky. You wrote the LDIF against forest A, exported it, and imported into forest B. The msDS-IntId values were unique over there — not over here. Different forests have different schema histories. IDs that look empty in one are taken in the other.

Trigger scenario: M&A activity. You're merging two companies and copying schema extensions from the acquired forest. The acquiring forest already has the same vendor's schema extension installed with overlapping IDs.

Check before importing:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter 'msDS-IntId -ge 0x80000000' -Properties msDS-IntId, lDAPDisplayName | Sort-Object msDS-IntId

That dumps every msDS-IntId above 0x80000000 in the current forest — the range reserved for extensions. Scan the output for the ID in your LDIF. If it's there, pick a fresh value 0x80000100 or higher and retry. If it's not there, the ID is safe and something else is causing your error — jump back to Cause 1.

There's one more thing worth knowing: msDS-IntId doesn't exist on every attribute. It's only stamped on attributes that the schema engine needs to refer to by integer. Core attributes use MAPI IDs instead. If your LDIF tries to set msDS-IntId on something that shouldn't have it, you'll get other errors first. Don't add it "just in case."

Verify the Schema Update Actually Applied

After your fix, don't trust the LDIF exit code alone. Confirm the attribute exists with the right ID:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter "lDAPDisplayName -eq 'yourAttributeName'" -Properties msDS-IntId, objectClass

You should see the attribute, its objectClass, and your msDS-IntId value. If Get-ADObject returns nothing, the import didn't commit. Check dcdiag /test:advertising /v on the schema master and look at the Directory Service event log for LDAP errors.

Quick Reference

Whatever you do, don't just keep re-running the import hoping it works. 0x2195 is deterministic — same LDIF, same result, every time. Fix the ID, fix the orphan, or fix the forest source, then run it once.