Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. "An attribute with the same link identifier already exists" error when you run ADPREP/FORESTPREP or install a new OS version domain controller

"An attribute with the same link identifier already exists" error when you run ADPREP/FORESTPREP or install a new OS version domain controller

View products that this article applies to.

Symptoms

When you run the ADPREP /FORESTPREP command to extend the forest schema on a Windows Server 2003-based computer, the command fails, and you receive the following error message:

Connecting to "<host name of schema master>"

Logging in as current user using SSPI

Importing directory from file "C:\WINDOWS\system32\sch44.ldf"

Loading entries........

Add error on line 43: Unwilling To Perform

The server side error is "Schema update failed: An attribute with the same link identifier already exists."

7 entries modified successfully.

An error has occurred in the program

ERROR: Import from file C:\WINDOWS\system32\sch44.ldf failed. Error file is saved in ldif.err.44.

Additionally, if you open the Ldif.err.44 error file, you see an error message that resembles the following: 

Entry DN: CN=ms-DS-BridgeHead-Servers-Used, CN=Schema,CN=Configuration,DC=<forest root domain> Add error on line 43: Unwilling To Perform The server side error is "Schema update failed: An attribute with the same link identifier already exists." An error has occurred in the program

Note This error also occurs on other attributes. For example, the error occurs when a schema change assigns a linkID 2046 to the camDBSignonRef object. The Microsoft attribute ms-PKI-DPAPIMasterKeys has this linkID in the Windows Server 2008 schema update.

↑ Back to the top

Cause

This error occurs when the ADPREP /FORESTPREP command tries to add a new object to the schema partition by using a linkID that was already assigned to an existing object in the schema partition.

Important Although this is a severe problem, at the point where the schema extension failed, the forest is not in a broken state and does not have to be reset to the previous state. Nevertheless, we do recommend that you follow up on the problem quickly. Then, if you have to run a forest recovery, you will not lose many changes as you rewind the forest.

↑ Back to the top

Resolution

The repair procedure that is described in this section requires at least Windows Server 2003 on the Schema Master. The procedure can also be applied to other attributes.

Do not change the link IDs for existing objects in the schema partition, because the behavior can cause Active Directory replication to fail with a schema mismatch. 

Important We strongly recommend that you contact Microsoft Customer Support Services to help resolve this problem. Although the forest is likely not in an irreparable state at this point, if you continue with the repair on your own, you may unwittingly making another mistake and damage the forest so much that you have to perform a forest recovery. Therefore, you should make sure that you have valid system state backups from two or more domain controllers in every domain in the forest before you proceed.

To resolve this issue, follow these steps:
  1. Identify the conflicting linkID that is being added. To do this, review the schema definition file in the Ldif.err.<Number> file. In this case, you will find that the attribute CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=<forest name> in sch44.ldf is being assigned a linkID of 2160.   
  2. Identify the object in the target schema partition that currently owns the conflicting linkID. You can search the schema on the target schema master to see which existing object was assigned the linkID that conflicts with the object in the Sch<xx>.ldf file. To do this, use REPADMIN, LDIFDE, LDP.EXE, or an equivalent tool. Some examples follow.

    For a REPADMIN search: 
    repadmin /showattr fsmo_schema: ncobj:schema: /filter:"(linkid=2160)" /subtree


    For an LDIFDE search: 
    LDIFDE /f <filename> /d "CN=Schema,CN=Configuration,DC=<forest root domain>" /r (linkid=2160)


    For an LDP search: 
    BaseDN: CN=Schema,CN=Configuration,DC=<forest name>
    Scope : Subtree
    Filter: (linkid=2160)
  3. Look up the schema file that is included with the affected attribute such as ms-DS-BridgeHead-Servers-Used or ms-PKI-DPAPIMasterKeys. The schema files are located at \support\adprep. Search the files for the attribute that is in conflict. For example, use the following command:
    Findstr ms-DS-BridgeHead-Servers-Used d:\support\adprep\sch*.ldf
  4. In a text editor, open the file that you find.
  5. Assign new link IDs to forward-link objects in the Sch<xx>.ldf files that conflict with linkIDs of existing objects in the schema partition. This can be achieved by assigning the assign the well-known object identifier (also known as OID) "1.2.840.113556.1.2.50" to the linkID field for all forward-link attributes in the SCH<xx>.ldf whose linkIDs conflict with existing objects in the target forest. The "1.2.840.113556.1.2.50" object identifier will assign unique auto-generated link IDs in the target schema. 

    To resolve the issue for the example of linkID 2160 that is defined in Sch44.ldf for CN=ms-DS-BridgeHead-Servers-Used, follow these steps: 
    1. Open the Sch44.ldf file. You see the following text for CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=<forest name>: 
      dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaAdd adminDescription: List of bridge head servers used by KCC in the previous run. adminDisplayName: ms-DS-BridgeHead-Servers-Used attributeID: 1.2.840.113556.1.4.2049 attributeSyntax: 2.5.5.7 cn: ms-DS-BridgeHead-Servers-Used instanceType: 4 isSingleValued: FALSE lDAPDisplayName: msDS-BridgeHeadServersUsed linkID: 2160 objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X objectClass: attributeSchema oMObjectClass:: KoZIhvcUAQEBCw== oMSyntax: 127 schemaFlagsEx: 1 schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg== searchFlags: 0 showInAdvancedViewOnly: TRUE systemFlags: 25
    2. Copy this text to a new txt file, and then save the file by using a new name. For example, save the file as "New-BridgeHeadServersUsed.ldf." 

      Note Do not change the existing schema file.
    3. Change the linkID field from "2160" to "1.2.840.113556.1.2.50" to trigger auto-generation of unique linkIDs on Windows Server schema operations masters. You see the following text in the Sch44.ldf file for CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=<DC>:
      dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaAdd adminDescription: List of bridge head servers used by KCC in the previous run. adminDisplayName: ms-DS-BridgeHead-Servers-Used attributeID: 1.2.840.113556.1.4.2049 attributeSyntax: 2.5.5.7 cn: ms-DS-BridgeHead-Servers-Used instanceType: 4 isSingleValued: FALSE lDAPDisplayName: msDS-BridgeHeadServersUsed linkID: 1.2.840.113556.1.2.50 objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X objectClass: attributeSchema oMObjectClass:: KoZIhvcUAQEBCw== oMSyntax: 127 schemaFlagsEx: 1 schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg== searchFlags: 0 showInAdvancedViewOnly: TRUE systemFlags: 25
    4. Before the definition of the corrected attribute, add the following section:
      dn:  changetype: modify add: schemaupgradeinprogress schemaupgradeinprogress: 1 -

      The line that contains only the hyphen (-) and the empty line that follows are important.
  6. Update linkIDs for the back-link attributes when linkIDs for forward link attributes are changed. Some objects in Active Directory have back-link attributes, and other objects do not. The ms-DS-BridgeHead-Servers-Used object that is used in this example does not have a back-link attribute. You have to determine whether the object that is changed has a back-link attribute that uses another object. If the affected object does have a back-link object, the back-link object must be changed in the same way. 

    You can find the back-link attribute by looking for the next odd-numbered linkID in the schema definition files. Usually, the back-link attribute is the next attribute that is listed in the schema file. But sometimes it is in a different file. For example, if you identified the problem linkID / attribute as being 2050 / CN=ms-DFSR-ComputerReference,CN=Schema,CN=Configuration,DC=<forest name>, the back link would have linkID 2051. To search for link ID 2051, run the following command:

    Findstr /c:"linkid: 2051" d:\support\adprep\sch*.ldf
    If a back link is found, copy the attribute definition from the schema import file to the new import file in the same way that you copied the forward-link attribute.

    Note The linkID definition of the back-link object uses a hard-coded (numeric) ID. The definition should be changed enable the object identifier of the back-link object to be generated automatically. 

    In this scenario, a back link for this forward link is created by setting the linkID for the back-link object to the ldapDisplayName of the forward-link object. If msDS-BridgeHeadServersUsed had a backlink attribute, the linkID line would resemble the following:

    linkID: msDS-BridgeHeadServersUsed
  7. In summary, the schema import file New-BridgeHeadServersUsed.ldf now has up to four commands. The commands appear in the following order:
    1. Turn on Schema import mode (schemaupgradeinprogress)
    2. Corrected definition of the forward link attribute 
    3. Instruction to reload the schema cache
    4. Optional: Corrected definition of the backward link attribute
  8. Save and close the schema update file for the custom attributes that you created. 
  9. Import the new custom change to the schema. For example, use the following command:
    LDIFDE /i /f New-BridgeHeadServersUsed.ldf /j . 

    Inspect the Ldif.err and Ldif.log files for any errors. If there are errors, contact Microsoft Customer Support Services at this point.
  10. Rerun the schema update process. If you can run the schema extension tool ADPREP, rerun the tool by using the /forestprep parameter.If you were using Server Manager to drive the installationof the first uplevel domain controller, you should repeat the installation process from Server Manager.
  11. The LDIF import logs such as Ldif.err.44 may contain warnings about the fact that the attributes through New-BridgeHeadServersUsed.ldf already exist. However, the expectation is that the schema update is successfully completed now.

    If there are errors, you should contact Microsoft Customer Support Services at this point.

↑ Back to the top

More Information

For more information about how to obtain a linkID, go to the following Microsoft Developer Network (MSDN) website:
Obtaining a Link ID
For more information about the auto-generated linkID, go to the following MSDN website:
Auto-Generated linkID
For more information about the linkID attribute, go to the following MSDN website:
Attribute linkID

↑ Back to the top

Keywords: kbexpertiseadvanced, kbsurveynew, kbtshoot, kb

↑ Back to the top

Article Info
Article ID : 969307
Revision : 1
Created on : 1/7/2017
Published on : 5/6/2015
Exists online : False
Views : 714