About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2012/02/20

0x2114 schema update failed

Subtitle: Fun with linkID and Schema LDF files

Scenario

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] [1] [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] [2] Beginning processing install-ExchangeSchema - LdapFileName: 'Setup\Data\PostExchange2003_schema18.ldf'

[02/09/2012 19:08:14.0284] [2] 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] [2] Process C:\Windows\system32\ldifde.exe finished with exit code 8245.

[02/09/2012 19:08:14.0721] [2] [ERROR] Unexpected Error

[02/09/2012 19:08:14.0721] [2] [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?

The Fix

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….

For you bilinguals, here is the original and here is the translation.

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:

dn: CN=ms-Exch-Mobile-Mailbox-Policy-Link

A quick search of the PostExchange2003_schema18.ldf  file give us this section:

dn: CN=ms-Exch-Mobile-Mailbox-Policy-Link,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-Mobile-Mailbox-Policy-Link
adminDisplayName: ms-Exch-Mobile-Mailbox-Policy-Link
attributeID: 1.2.840.113556.1.4.7000.102.50668
attributeSecurityGuid:: iYopH5jeuEe1zVcq1T0mfg==
attributeSyntax: 2.5.5.1
isMemberOfPartialAttributeSet: TRUE
isSingleValued: TRUE
lDAPDisplayName: msExchMobileMailboxPolicyLink
name: ms-Exch-Mobile-Mailbox-Policy-Link
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
linkID: 1058
schemaIdGuid:: KqC15oH1QkyuYBCP58HttQ==
searchFlags: 0

(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.113556.1.2.50) 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.113556.1.2.50 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.

YMMV

2 comments:

Unknown said...

I ran into a very similar issue with the same symptoms and the resolution was to add the user account in use to the Schema Admins group in AD. Something worth checking.

tsoorad said...

I agree that that schema admin group membership is needed. In this case, the install account did have schema admin membership and the schema update was failing because another application had previously allocated the LinkID that the Exchange schema wanted to user.

test 02 Feb

this is a test it’s only a test this should be a picture