LinkID und Schema Erweiterungen

Da installiert man seinen ersten Exchange 2010 Server (natürlich als Cluster etc.) und die Vorbereitung des Forests beginnt mit dem Schemaupdate, welches diesmal gleich am Anfang mit folgender Fehlermeldung abbricht: (LDIF.ERR-Datei)

15: CN=ms-Exch-ELC-Folder-Link,CN=Schema,CN=Configuration,DC=kunde,DC=net
Entry DN: CN=ms-Exch-ELC-Folder-Link,CN=Schema,CN=Configuration,DC=kunde,DC=net
Add error on entry starting on line 268: 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

Entry DN: CN=ms-Exch-ELC-Folder-Link,CN=Schema,CN=Configuration,DC=kunde,DC=net
Add error on entry starting on line 268: 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

Was ist hier passiert ?. Anscheinend kann der Schemamaster die Änderungen nicht durchführen, weil bei bestehendes Attribut schon den verwendeten Link Identifier belegt.

Was sind LinkIDs ?

Nach kurzer Suche im Internet findet man dann auch ,was es sein kann. Das Active Directory kennt Verknüpfungen, z.B. beim Benutzer die Links auf die Gruppen, in denen er Mitglied ist und bei Gruppen die Liste der Mitglieder. Damit man diese "Rückwärts" auflösen kann, gibt es entsprechende Forwardlinks und Backlinks. Diese LinkIDs sind quasi die Definition, welche Felder zueinander passen und müssen eindeutig sein. Früher hat Microsoft diese IDs entsprechend an die Firmen verteilt. Das ist seit Windows 2003 nicht mehr zwingend der Fall, wie die MSDN beschreibt:

Starting with Windows Server 2003, it is no longer necessary to request a linkID from Microsoft; there is a process für automatically generating a linkID. The system will automatically generate a link ID für a new linked attribute when the attribute's linkID attribute is set to 1.2.840.113556.1.2.50. A back link für this forward link is created by setting the linkID to the attributeId or ldapDisplayName of the forward link.

Wenn Sie also das Schema durch eine Drittanwendung erweitern und diese ebenfalls LinkIDs verwendet und diesen automatischen Prozess einsetzt, dann ist der numerische Wert der LinkID nicht vorhersagbar. Muss er aber auch nicht, wenn alle Produkte das machen würden.

Welche LinkID ist betroffen ?

Das scheint sich aber noch nicht bis zu den Microsoft Exchange 2010 Schema-Entwicklern herumgesprochen zu haben. Denn die Fehlermeldung enthält auch die LDF-Datei, deren Import fehlgeschlagen ist. Sogar die Zeilennummer der LDF-Datei wird mit angegeben. So findet man dann in den Dateien postexchange2000_schema6.ldf, POSTWINDOWS2003_SCHEMA38.LDF und SCHEMA51.LDF den folgenden gleichen Teil (Gekürzt) 

dn: CN=ms-Exch-ELC-Folder-Link,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDisplayName: ms-Exch-ELC-Folder-Link
attributeID: 1.2.840.113556.1.4.7000.102.50349
lDAPDisplayName: msExchELCFolderLink
linkID: 2054

dn: CN=ms-Exch-ELC-Folder-BL,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDisplayName: ms-Exch-ELC-Folder-BL
lDAPDisplayName: msExchELCFolderBL
linkID: 2055

Also möchte Exchange gerne diese Einträge mit den LinkIDs 2054 und 2055 importieren

Wer belegt die LinkID ?

Per Kommandozeile lässt sich ganz schnell ermitteln, welches Objekt diese LinkID im aktuellen Schema verwendet: 

repadmin /showattr fsmo_schema: ncobj:schema: /filter:"(&(objectclass=*)(linkid=2054))" /subtree
DN: CN=aks-tms-tokens,CN=Schema,CN=Configuration,DC=customer,DC=net
    2> objectClass: top; attributeSchema
    1> cn: aks-tms-tokens
    1> distinguishedName: CN=aks-tms-tokens,CN=Schema,CN=Configuration,DC=kunde,DC=net
    1> instanceType: 0x4 = ( WRITE )
    1> whenCreated: 26.03.2007 10:02:05 W. Europe Standard Time
    1> whenChanged: 25.06.2009 08:56:13 W. Europe Standard Time
    1> USNCreated: 6587
    1> attributeID: 1.2.840.113556.1.4.7000.233.180672.443844.62.319964.247473.1
351439.197549.9
    1> attributeSyntax: 2.5.5.14 = ( DISTNAME_STRING )
    1> isSingleValued: FALSE
    1> linkID: 2054
    1> USNChanged: 6587
    1> showInAdvancedViewOnly: TRUE
    1> adminDisplayName: aks-tms-tokens
    1> oMObjectClass: \x2a864886f7140101010c
    1> oMSyntax: 127 = ( OBJECT )
    1> lDAPDisplayName: AksTmsTokens
    1> name: aks-tms-tokens
    1> objectGUID: a52db0de-79cc-4e4b-80b2-af74f114a349
    1> schemaIDGUID: 86b7a58e-95d8-4d93-8836-3e6a0d7496e8
    1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=kunde,DC=net
    1> dSCorePropagationData: 0x0 = (  )

Es ist also in dem Fall eine Schema Erweiterung von einer Aladdin Authentifizierungslösung gewesen, die unglücklicherweise diese LinkIDs aktuell belegt, da die Schemaerweiterung damit früher erfolgt ist. Leider hatte ich die LDF-Dateien dazu nicht vorliegen, so dass ich nicht bestimmen kann, ob damals "dynamische" LinkIDs verwendet wurden oder ob Aladdin von Microsoft vielleicht die 2054 zugewiesen bekommen kann. ändern kann man das aber im Nachhinein nicht mehr.

Lösung des Problems

Achtung: Änderungen an den LDF-Dateien sind sehr mit Vorsicht vorzunehmen. Vergewissern sie sich auf jeden Fall beim Hersteller der betroffenen Felder.

Die Lösung sieht so aus, dass die LDF-Dateien für Exchange 2010 derart geändert werden, dass beim Import andere LinkIDs verwendet werden. Auch hier weist "Obtaining a Link ID" (http://msdn.microsoft.com/en-us/library/bb891955(VS.85).aspx) den Weg. Ehe ich aber nun das eine Problem mit der einen LinkID angehe, habe ich mit einem FIND "linkid" *.* erst mal alle Vorkommen nach LinkID-Einträge in allen LDF-Dateien gesucht und mit REPADMIN geprüft, ob diese LinkIDs anderweitig belegt sind. Bei mir waren es dann nur 2054-2057, die schon belegt waren, auch wenn Exchange auch noch weitere LinkIDs reservieren möchte.

In den fraglichen LDF-Dateien musste ich dann die Einträge hinter LinkID entsprechend ändern:

2054 -> 1.2.840.113556.1.2.50
2055 -> msExchELCFolderLink
2056 -> 1.2.840.113556.1.2.50
2057 -> msExchMailboxTemplateLink

Wichtig ist, dass durch die Angabe von "1.2.840.113556.1.2.50" bei den geraden LinkIDs (Vorwärts) natürlich mir nicht bekannte LinkIDs erzeugt werden. In der Gegenrichtung (Backlink) sind die LinkID-Werte ungerade. Hier habe ich statt der mir unbekannten LinkID den LDAP-Displaynamen angegeben und den Rest dem Domaincontroller überlassen.

Aufpassen muss man hierbei, dass das Exchange 2010 Setup die Schema-Dateien leider zweimal in den Installationsquellen hat. Einmal unter "\setup\serverroles\common\setup\data" und in "\setup\data". Das Exchange Setup kopiert die LDF-Dateien aus dem Verzeichnis "\setup\serverroles\common\setup\data" nach Windows-TEMP. ändern Sie daher die LDF-Dateien dort. Das könnte dann wie folgt aussehen (gekürzt)

dn: CN=ms-Exch-ELC-Folder-Link,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-ELC-Folder-Link
adminDisplayName: ms-Exch-ELC-Folder-Link
attributeID: 1.2.840.113556.1.4.7000.102.50349
attributeSyntax: 2.5.5.1
isMemberOfPartialAttributeSet: FALSE
isSingleValued: FALSE
lDAPDisplayName: msExchELCFolderLink
name: ms-Exch-ELC-Folder-Link
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
linkID: 1.2.840.113556.1.2.50
schemaIdGuid:: E+URcZKecUGRdE+GbC1zaQ==
searchFlags: 0

dn: CN=ms-Exch-ELC-Folder-BL,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-ELC-Folder-BL
adminDisplayName: ms-Exch-ELC-Folder-BL
attributeID: 1.2.840.113556.1.4.7000.102.50350
attributeSyntax: 2.5.5.1
isMemberOfPartialAttributeSet: FALSE
isSingleValued: FALSE
lDAPDisplayName: msExchELCFolderBL
name: ms-Exch-ELC-Folder-BL
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
linkID: msExchELCFolderLink
schemaIdGuid:: K6eLJBaO+06RJ+MH5uh1rA==
searchFlags: 0

dn: CN=ms-Exch-Mailbox-Template-Link,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-Mailbox-Template-Link
adminDisplayName: ms-Exch-Mailbox-Template-Link
attributeID: 1.2.840.113556.1.4.7000.102.50351
attributeSecurityGuid:: iYopH5jeuEe1zVcq1T0mfg==
attributeSyntax: 2.5.5.1
isMemberOfPartialAttributeSet: TRUE
isSingleValued: TRUE
lDAPDisplayName: msExchMailboxTemplateLink
name: ms-Exch-Mailbox-Template-Link
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
linkID: 1.2.840.113556.1.2.50
schemaIdGuid:: NZNi518rk0WGVoUjmpxG9g==
searchFlags: 0

dn: CN=ms-Exch-Mailbox-Template-BL,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-Mailbox-Template-BL
adminDisplayName: ms-Exch-Mailbox-Template-BL
attributeID: 1.2.840.113556.1.4.7000.102.50352
attributeSyntax: 2.5.5.1
isMemberOfPartialAttributeSet: FALSE
isSingleValued: FALSE
lDAPDisplayName: msExchMailboxTemplateBL
name: ms-Exch-Mailbox-Template-BL
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
linkID: msExchMailboxTemplateLink
schemaIdGuid:: bejPk9DHCEGxF5zHKQjubg==
searchFlags: 0

Und endlich konnte auch das Exchange 2010 Schemaupdate den Weg auf die DCs finden und der Exchange Server installiert werden.

Schuld ?

Wenn Microsoft schon selbst in der MSDN schreibt, dass man keinen LinkID mehr von Microsoft beantragen muss und der dynamische Weg angeraten ist, dann frage ich mich, warum das Exchange Team noch immer mit statischen LinkID-Einträgen arbeitet, die anscheinend so niedrig sind, dass schon eine kleine zusätzliche Schemaerweiterung dem Admin das Leben so schwer macht.

Weitere Links