Fix ERROR_DS_DUP_LINK_ID (0x00002114) in AD Schema

Quick Answer

Find the attribute that already uses the linkID you're trying to assign, then either change its linkID to an unused value or use a different linkID for your new attribute.

Why This Happens

Active Directory uses linkIDs to pair up linked attributes—think of them as two ends of a rope. One attribute is the forward link, the other is the back link, and they share the same linkID number. When you try to add a new attribute and give it a linkID that's already taken, you get ERROR_DS_DUP_LINK_ID (0x00002114). This usually happens after someone manually edited the schema without checking existing linkIDs, or when a poorly written import script tries to reuse a number that's already in use. I've seen it happen when a third-party app tried to extend the schema and used a linkID that collided with an existing one from Exchange or Skype for Business.

What You'll Need

• Access to the Schema Master (the domain controller that holds the schema operations master role).
• Domain admin credentials, and ideally Schema Admins membership.
• The ADSI Edit console (installed by default on domain controllers with the AD LDS Snap-In).
• Remember to back up the schema before making changes. You can do this with ntdsutil or by taking a system state backup.

Step-by-Step Fix

Step 1: Identify the conflicting attribute

1. Open ADSI Edit on the Schema Master. You'll find it under Administrative Tools.
2. Right-click ADSI Edit and choose Connect to.
3. In the dialog, under Select a well-known naming context, pick Schema and click OK.
4. Once connected, expand CN=Schema,CN=Configuration,DC=... and click on the CN=Schema node.
5. In the right pane, find the attribute that's causing the conflict. You'll see a column called linkID. Scroll through until you find one that matches the linkID you're trying to use. If you don't know the exact linkID, look at the error details from the schema update—it usually says which linkID is in conflict.

After you find it, write down the distinguished name (the full path) of that attribute. You'll need it later.

Step 2: Free up the linkID (or change yours)

You have two ways to resolve this. Either change the existing attribute's linkID, or change the linkID you're using for your new attribute. I prefer reassigning the new attribute because it's less risky—you don't touch something that might be in use by another app. But if you absolutely must use that specific linkID (like for a custom app that expects it), then you'll change the existing one.

Option A: Change the new attribute's linkID

1. Edit your schema import file (usually a .ldf file) and replace the linkID value with an unused one. To find an unused linkID, look at the highest existing linkID in ADSI Edit, then pick a number higher than that. For example, if the highest is 1000, use 1001. But don't go crazy high—stay within the valid range for linkIDs (1 to 32767).
2. Reapply the schema update with the corrected file.

Option B: Change the existing attribute's linkID

1. If you've decided to move the existing attribute, right-click the conflicting attribute in ADSI Edit and select Properties.
2. Find the linkID attribute in the list and double-click it.
3. Change the value to an unused linkID. Again, pick a high number that's free.
4. Click OK and then Apply in the properties dialog.
5. Now try your schema update again. It should go through without the duplicate error.

Step 3: Verify the change

After you've resolved the conflict, run your schema update again. You should see it complete without the 0x00002114 error. To be safe, open ADSI Edit and confirm that no two attributes share the same linkID. You can sort by the linkID column to make it easier.

If the Main Fix Fails

Sometimes the duplicate is hidden because the attribute is in the Deleted Objects container. Schema objects that were deleted but not yet garbage-collected might still hold a linkID. Here's how to check:

1. In ADSI Edit, connect to the Configuration naming context.
2. Expand CN=Configuration,DC=... and then CN=Deleted Objects.
3. Look for any attribute with a matching linkID. If you find one, you might need to force garbage collection or manually remove the tombstone—but that's advanced and risky. In most cases, waiting 180 days (the default tombstone lifetime) will clear it. If you can't wait, you can temporarily lower the tombstone lifetime, but I'd avoid that unless you're in a test environment.

Another possibility: the schema update tool itself is trying to create two attributes that both use the same linkID. If you're importing a large schema file, check the file for duplicates in the linkID fields before you run it.

Prevention Tips

• Before any schema import, run a script that lists all linkIDs currently in use and compare it to the ones you're about to add. You can get the list with PowerShell:

Get-ADObject -SearchBase "CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Filter { linkID -like "*" } -Properties linkID | Sort-Object linkID | Format-Table name, linkID

• Always test schema changes in a lab that mirrors your production environment. The schema is global, so a mistake affects every domain controller.
• Keep a record of which linkIDs you've assigned to custom attributes. A simple spreadsheet works fine.
• If you're using third-party applications that extend the schema, check their documentation for known linkID ranges. Some apps have their own ranges, and collisions are more likely if they don't.

The real fix here is understanding that linkIDs are a finite resource, and you've got to play nice with what's already there. Once you find the duplicate, the solution is straightforward—just reassign one of them.