Subtitle: Fun with linkID and Schema LDF files
On site getting a project rolling. One of our first steps was to test the schema extending in lab. Perfect execution. So we submit for change control and get going the next morning. Having just succeeded doing this task the day before in lab, we were not expecting any issues. Not so fast Bucko!
Setup /prepareschema (setup /ps) got about 20 seconds in and dumped out with this little gem:
[02/09/2012 19:08:14.0737]  [ERROR] There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema18.ldf'. The error code is: 8245. More details can be found in the error file: 'C:\Users\me.adm\AppData\Local\Temp\5\ldif.err'
Oh wonderful. But, no problem – let’s get to the bottom of this and get moving forward. A closer read revealed that the ldf count was up to at least the 18th file, and probably higher. (If you look at that directory, there is over 400 LDF files there….) So, my conclusion is that something is not the same in the production AD as in the lab. Looking at the ldif.err file shows this: (sorry about the crappy wrapping…)
Entry DN: CN=ms-Exch-Mobile-Mailbox-Policy-Link, CN=Schema, CN=Configuration,DC=domain,DC=local
Add error on entry starting on line 358: Unwilling To Perform
The server side error is: 0x2114 Schema update failed: An attribute with the same link identifier already exists.
The extended server error is:
00002114: SvcErr: DSID-032603BC, problem 5003 (WILL_NOT_PERFORM), data 8468
An error has occurred in the program
Personally, I really liked the idea of changing the error code in the file I was told to go look at… the server error said 8245, here in the ldif.err file we are given a value of 8468. This is important though… it enabled me to find an EXACT fix.
What was Wrong
Long story short – at some point in the past, the client had done an application or something that grabbed the same linkID that the Exchange 2010 schema extension wanted to use. So it pitches the error and quits out. Here is the pertinent section of the ldif.log:
[02/09/2012 19:08:14.0284]  Beginning processing install-ExchangeSchema - LdapFileName: 'Setup\Data\PostExchange2003_schema18.ldf'
[02/09/2012 19:08:14.0284]  Running <C:\Windows\system32\ldifde.exe> with arguments <-i -s "XXX-W2K8-DC02.domain.local" -f "C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema18.ldf" -j "C:\Users\me.adm\AppData\Local\Temp\5" -c "<SchemaContainerDN>" "CN=Schema,CN=Configuration,DC=domain,DC=local">.
[02/09/2012 19:08:14.0705]  Process C:\Windows\system32\ldifde.exe finished with exit code 8245.
[02/09/2012 19:08:14.0721]  [ERROR] Unexpected Error
[02/09/2012 19:08:14.0721]  [ERROR] There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema18.ldf'. The error code is: 8245. More details can be found in the error file: 'C:\Users\me.adm\AppData\Local\Temp\5\ldif.err'
What is happening here?
0x2114 schema update failed: searching that phrase or “an attribute with the same link identifier already exists” gave some interesting results – including this one: http://support.microsoft.com/kb/917682 which is for Exchange 2003 and the advice is to modify the ldf file with an arbitrary number and, of course, in the future hope that no one created an install that wants to use that number for a LinkID. After reading that article and several others like it, I concluded that the error was the same, but I did not like the solution.
Searching with the second value in the ldif.err log (8468) gave me a technet forum article that was so close to being my error that I was almost moved to genuflect in the direction of Redmond. Here is the article. Down towards the bottom is the interesting part, where is mentions “…German article which exactly described my problem…” BINGO!! Anyone read German? My search engine does….
The LinkID exists that the PostExchange2003_schema18.ldf file wants to use for ITS object is already in use. OK. Let’s look at the actual file, or at the very least a section of the file (it is several K of text).
In my case, the exchange install log pointed at this attribute inside the PostExchange2003_schema18.ldf as failing:
A quick search of the PostExchange2003_schema18.ldf file give us this section:
(The DN: line, btw, is line 358 which is what the ldif.err log pointed to also.)
But, look at the “linkID: 1058” line… and then go back and read the German translation again. And there is our fix. We need to get a number into that value that no longer conflicts… but we want that number to be good from here on out also. What is important about that German article is that it gives us the input for the value – but in AD terms without having to dream up a number and hope it never gets used, or contact Microsoft for an official linkID to use (something maybe the Exchange team did?)! Apparently, using this number (1.2.840.1135126.96.36.199) causes the object to get created with a linkID that does not exist. Sweet!
For a quick close to this issue, we copied the entire DVD down local, cranked up a quick notepad session, changed the linkID in question to the 1.2.840.1135188.8.131.52 value, and re-ran setup /ps. Success.
Keep in mind that you need to be very careful about editing the LDF files, much like AdsiEdit, what you do is quick and fairly permanent.