You're running an LDIFDE schema update—maybe for Exchange, maybe for some LOB app—and halfway through you get slapped with ERROR_DS_RESERVED_LINK_ID (0X00002180). The exact message says something like "The link identifier is reserved." Last month I had a client trying to prep their domain for Exchange 2019, and this error killed the whole schema import. The update fails, the schema stays half-baked, and you're stuck.
The trigger is almost always a line in the LDIF file trying to assign a linkID value that falls in a range Microsoft already reserved for internal use. When you're importing a custom schema extension—like one from a vendor or a third-party app—they might pick a linkID that overlaps with these reserved blocks. AD says "nope, that's mine" and bails.
Root Cause: Reserved Link ID Ranges
Every linked attribute in Active Directory has a unique linkID. Microsoft reserved certain ranges:
- 1.2.840.113556.1.2.49 through 1.2.840.113556.1.2.70 – reserved for system-linked attributes.
- Any
linkIDvalue that starts with1.2.840.113556is part of Microsoft's OID space. If your LDIF file'slinkIDfalls in that path, you'll get this error.
In plain English: you're trying to use a number AD has already promised to itself. The fix is to assign a different linkID that isn't reserved.
The Fix: Edit the LDIF File
- Open the LDIF file in Notepad++ or any text editor. Don't use plain Notepad—it mangles line endings. I've seen that cause more problems than the original error.
- Search for
linkID:The error message should point you to the exact attribute. Look for the line likelinkID: 1.2.840.113556.1.2.XX. That number is the problem. - Change the linkID to a safe range. Microsoft's official guidance: use
linkID: 1.2.840.113556.1.2.1200and above, or1.2.840.113556.1.2.1300through1.2.840.113556.1.2.1999. Avoid anything under 1200. I usually pick1.2.840.113556.1.2.1500for forward attributes and1.2.840.113556.1.2.1501for back links. Just make sure the forward and back link IDs are sequential (e.g., forward = 1500, back = 1501). - Save the LDIF file and re-run the import with
ldifde -i -f yourfile.ldf -v.
If It Still Fails
If the error persists, check these:
- Duplicate linkID. Another attribute might already own that number. Run
ldifde -f export.ldf -d "CN=Schema,CN=Configuration,DC=YOURDOMAIN,DC=com" -r "linkID=*"and grep for your proposed linkID. If it's taken, pick a different one. - OID collision. Make sure the attribute's OID itself isn't a Microsoft-reserved OID. Use an OID generator (like OIDInfo) to get a unique one.
- Schema master FSMO role holder. The import must run on a DC that holds the schema master role. If you're running it on a different DC, the error can show up as a timeout or replication issue. Check with
netdom query fsmo.
I've seen people waste hours trying to re-run the import hoping it'll magically work. It won't. The LDIF file has a bad linkID—fix the number, rerun, and you're done.