Problem solve Get help with specific problems with your technologies, process and projects.

Resolving Adprep duplicate Link ID errors for Windows Server 2008

Admins need to run the Adprep utility to avoid failure when adding a Windows 2008 DC to a down-level domain. But what if Adrpep itself fails?

As with older versions, Windows Server 2008 and R2 require the Adprep.exe utility to update the Active Directory...

schema prior to introducing any Windows 2008 or R2 DCs into a down-level domain. There is a Forestprep and Domainprep option; both must be run, and the Domain Prep must be run for each domain.

Adprep is found on the DVD for all versions of Windows Server. If you have a Windows Server 2003 forest with Windows 2003 domains, you must run Adprep from the Windows Server 2008 DVD prior to promoting a 2008 domain controller in any domain in the forest. Failure to do so will result in an error message telling you to run Adprep first.

But what if Adprep itself fails? This article will address a known Adprep failure issue and the challenge of finding a solution.

The Adprep link identifier error

The error that may appear when running Adprep actually shows up in the log located in %windir%\debug\adprep\logs. Before Adprep fails, the error states:

An attribute with the same link identifier already exists.

More Active Directory troubleshooting tips

Troubleshooting KDC 7 event errors when no one else can

Disaster prevention strategies for Active Directory forests

How to find and remove lingering objects in Active Directory

In order to resolve the problem, we need to understand what a link identifier, or Link ID, is. In the Active Directory schema, the values of some object attributes are linked either forward or backward. Stored in the Link ID property, they are essentially two attributes that point to each other.

The easiest example involves the Member and MemberOf attributes. The Member attribute of a group is the forward link, and it points to objects that are members of the group. This link can be edited by admins and is replicated to other domain controllers. The MemberOf attribute is a backlink that is automatically calculated when the forward link is set. The forward link will end in an even, positive, non-zero integer and the back link will be the forward link plus one (+1). It doesn't really matter what these values are, but they must be unique in the directory. This is the problem seen in the Adprep error above. Any directory-enabled application can issue Link ID values to its objects, but they must be unique. Microsoft used to have a process for assigning unique values -- similar to object identifiers (OID) --. but now they are automatically generated and guaranteed to be unique. (Another option is for developers to use Link ID values of 13800 or above.)

The error clearly states the problem during Adprep. Since we are installing a new version of Windows that will have some new objects with Link IDs, the IDs must be unique.

Case study

In one case I worked on, an application called Cognos had two attributes with Link ID values. These values were fine for Windows Server 2003, but Windows Server 2008 had new attributes that used those same values. Therefore, when Adprep ran we got the error. The documentation for the application clearly stated that the Link ID values were in the 13800 range, but it wasn't implemented that way.

The trick to resolving this is to find the objects in Windows Server 2008 that conflict with the Cognos attributes and generate a new link for them. Microsoft Knowledge Base article 969307 describes this exact issue, even using Cognos as an example. But the article -- at least to me -- is unclear and misleading, so I'll correct it here. Here is the troubleshooting process for fixing this Adprep error:

1. Diagnosing the error. An error occurs when Adprep runs: "Adprep unable to update forest information." In the Adprep log, we see the following:

Adprep was unable to upgrade the schema on the schema master. [Status/Consequence] The schema will not be restored to its original state. [User Action] Check the Ldif.err log file in the C:\WINDOWS\debug\adprep\logs\20100301111718 directory for detailed information.

Looking in the LDIF.err (or LDIF.err.34) file, we see this:

Entry DN:CN=ms-PKI-DPAPIMasterKeys,CN=Schema,CN=Configuration,DC=Corp, DC=com Add error on line 123: 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

An identical error exists in the LDIF.err file.

2. Locate the new attribute that has the duplicate Link ID. Adprep uses files named SCHxx.ldf (where xx is a sequential integer) to modify the schema. The problem attribute is listed in one of these files, located on the Windows Server 2008 DVD in \Sources\ADPrep. From the error noted previously, we know the attribute is CN=ms-PKI-DPAPIMasterKeys.

A simple search of the .ldf files on the DVD will find the attribute and the associated Link ID of 2046. In this case it was in SCH34.ldf. So we know the attribute that tried to be added with Link ID 2046, but now we need to find which attribute already in the directory has that Link ID.

3. Locate the existing attribute with the conflicting Link ID (in this case, 2046). Using a simple LDIFDE search we can find the Cognos attribute that is conflicting:

ldifde -f linkID.ldf -d "CN=Schema,CN=Configuration,DC= ,DC=com" -r "(&(objectclass=*)(linkid=2046))"

The output file in this example is linkID.ldf, so by opening it in notepad I found the following:

DN: CN=camDBSignonRef,CN=Schema,CN=Configuration,DC=corp,DC=com
          2> objectClass: top; attributeSchema
          1> cn: camDBSignonRef
          1> linkID: 2046

If we were to dump the ms-PKI-DPAPIMasterKey attribute in a Windows 2008 domain without Cognos installed, it would have a Link ID of 2046. The temptation then is to change the Cognos attribute because we shouldn't mess with a Windows attribute, but as noted before, the value of any Link ID is irrelevant as long as they are unique, positive, non-zero integers. Once again, the keyword here is unique.

In this case, we also found that another Cognos attribute conflicted with ms-DS-Bridgehead-Servers-Used in Windows, so note that you may have to track down more than one.

4. The solution. The new attributes (in this case, the Windows 2008 attributes) must be assigned a new Link ID. Just follow the instructions in the Resolution section of KB 969307 noted above, which is essentially:

  1. Copy the contents of the Adprep directory from the Windows Server 2008 DVD to the server's hard disk. I recommend making a new directory called C:\ADPrep to put it in.
  2. Open the LDIF.err.xx file (the file that contains the Attribute in conflict) and replace the Link ID (2046 in our example) with 1.2.840.113556.1.2.50 -- this will trigger automatic Link ID generation.
  3. Run Adprep from the folder you copied the .ldf files to and made the Link ID changes (C:\ADPrep in step 1 here).
  4. Note that if your attribute has any back links, you need to modify those as well. The KB article explains this process.

The important thing to note here is that these errors can easily happen if developers aren't paying attention, but they can also be easily rectified. Again, just remember that the Link IDs must be unique. It doesn't matter whether you change them in the Windows attributes or applications, but opting for the attributes is easier and it will work just as well.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.

Dig Deeper on Windows administration tools