Recently, we had a problem when performing Exchange organization (forest preparation - PrepareSchema, PrepareAD) before installing Exchange 2007 and Exchange 2010. It failed when extending Active Directory schema with some of its link and backlink attributes.
In our case, it was due to linID number collisions on attributes ms-Exch-ELC-Folder-Link, ms-Exch-ELC-Folder-BL, ms-Exch-ailbox-Template-Link and ms-Exch-Mailbox-Template-BL. It manifestated itself as the following error messages:
There was an error while running 'ldifde.exe' to import the schema file
The server side error is: 0x2114 Schema update failed: An attribute with the same link identifier already exists.
00002114: SvcErr: DSID-032603BC, problem 5003 (WILL_NOT_PERFORM), data 8468
An error has occurred in the program
Organization Preparation Failed
Error: The following error was generated when
"$error.Clear();
install-ExchangeSchema -LdapFileName ($roleInstallPath + "Setup\Data\"+$RoleSchemaPrefix + "schema5.ldf") "
install-ExchangeSchema -LdapFileName ($roleInstallPath + "Setup\Data\"+$RoleSchemaPrefix + "schema2.ldf") "
was run:
"There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2000_schema5.ldf'. The error code is: 8245. More details can be found in the error file: 'C:\Users\domain-admin\AppData\Local\Temp\2\ldif.err'".
"There was an error while running 'ldifde.exe' to import the schema file 'C:\Windows\Temp\ExchangeSetup\Setup\Data\PostExchange2003_schema2.ldf'. The error code is: 8245. More details can be found in the error file: 'C:\Users\domain-admin\AppData\Local\Temp\2\ldif.err'".
"Add error on entry: Unwilling To Perform"
CN=ms-Exch-ELC-Folder-Link, linkID: 2054
CN=ms-Exch-ELC-Folder-BL, linkID: 2055
CN=ms-Exch-Mailbox-Template-Link, linkID: 2056
CN=ms-Exch-Mailbox-Template-BL, linkID: 2057
What are link and backlink attributes and why they require a linkID?
Some AD objects need to reference other objects. In order to reference an object DN (distinguishedName), the referencing object must have a link attribute. An example of a link attribute is the member attribute of groups. Groups point to their members through this attribute called member. Another example would be serverReference attribute of the server objects in Sites and Services (configuration partition actually) which point to DC computer object in domain partition.
If some object points to others, the referenced objects may display back reference to simplify navigation. This means that the referenced objects may have a backlink attribute. In case of members of a group, the attribute is called memberOf. While DC computer objects have backlink attribute called serverReferenceBL which points back to the server object in configuration.
While LDAP interface accepts write requests into link attributes, their backlinks are read/only. From this, it may look like backlinks are just computed dynamically when queried for their value, while the links store the actuall reference. In fact, since forest functional level (FFL) of Windows 2003, the links/backlinks are stored in a common table (foreign key table) inside the AD database called linktable. But the read/only logic of backlinks remain.
If you define new link and backlink attributes into the AD schema, you must specify their unique linkID values. The linkID values are used to identify what is the link and what link the backlink is referencing. Logically, their values must be unique or there would be mishmatch of who points where.
Link attribute must be assigned linkID with an even integer, while its backlink must be assigned odd integer exactly one higher than its link. Both linkIDs must be unique in the forest you are modifying.
What Exchange was trying to import looked like this:
dn: CN=ms-Exch-ELC-Folder-Link,
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,
objectClass: attributeSchema
linkID:2054
schemaIdGuid:: E+URcZKecUGRdE+GbC1zaQ==
searchFlags: 0
dn: CN=ms-Exch-ELC-Folder-BL,
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,
objectClass: attributeSchema
linkID:2055
schemaIdGuid:: K6eLJBaO+06RJ+MH5uh1rA==
searchFlags: 0
dn: CN=ms-Exch-Mailbox-Template-Link,
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,
objectClass: attributeSchema
linkID:2056
schemaIdGuid:: NZNi518rk0WGVoUjmpxG9g==
searchFlags: 0
dn: CN=ms-Exch-Mailbox-Template-BL,
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,
objectClass: attributeSchema
linkID:2057
schemaIdGuid:: bejPk9DHCEGxF5zHKQjubg==
searchFlags: 0
Our problem came from previous Aladdin eToken installation which brought its own attributes with the same linkIDs. You can find the attributes with the following simple LDAP query (just replace your root domain naming context and the linkID you are searching for):
dsquery * cn=schema,cn=configuration,dc=gopas,dc=virtual -filter "(&(objectClass=attributeSchema)(linkID=2054))"
In our case, it produced the following Aladdin eToken attributes:
CN=aks-tms-tokens
lDAPDisplayName: AksTmsTokens
linkID: 2054
CN=aks-tms-users
lDAPDisplayName: AksTmsUsers
linkID: 2055
CN=aks-tms-creator
lDAPDisplayName: AksTmsCreator
linkID: 2056
CN=aks-tms-paramsets
linkID: 2057
lDAPDisplayName: AksTmsParamSets
So that the later Exchange schema update was not able to import the two link/backlink pairs because their linkIDs would be duplicating those of Aladdin eToken.
It actually was problem of the previous Aladdin installation, not of Exchange. The policy behind using static linkIDs for an application requires that the developers ask Microsoft directly to provide them with some non-colliding linkIDs, which apparently Aladdin guys didn't do.
But how to repair it now? You cannot change most of the schema parameters after they are defined. And you, logically, should not change the Exchange linkIDs to something else manually. You might run in the same problem later again.
Dynamic linkID generation with Windows 2003 schema FSMO and newer
If your schema master FSMO is running operating system Windows 2003 or newer, you can do with dynamically generated linkIDs. The newer DCs can generate linkIDs for you automatically. You do not specify the linkID explicitly, but rather put there a standard OID with value of 1.2.840.113556.1.2.50 as described in the Obtaining a Link ID and the Auto-Generated linkID articles.
This OID goes into the link type attribute's linkID. When you later define the backlink type attribute, you just reference its associated link with the link attribute's lDAPDisplayName or attributeID value.
The magic here is schema update between the two. Once you define the fist link attribute (the one with the 1.2.840.113556.1.2.50 OID), and before you proceed with the backlink definition, you must invoke schema cache cleanup and subsequent schema update. Why? DCs cache schema definitions in memory and update them only 5 minutes after they receive a schema modification.
Invoking schema update from an LDF file goes like the following. You just write the schemaUpdateNow attribute into rootDSE object of the DC:
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
How to repair the Exchange schema update files
To make the Exchange schema update working, we just modified the LDF file in question using the dynamic linkID OID and the schemaUpdateNow attribute. You must modify the particular LDF file, that your organization preparation is trying to import actually. There are more such files that contain the problematic link and backlink attributes. It may be one of the following:
POSTEXCHANGE2000_SCHEMA5.LDF
POSTEXCHANGE2000_SCHEMA5.LDF
POSTEXCHANGE2003_SCHEMA2.LDF
POSTEXCHANGE2003_SCHEMA2.LDF
POSTWINDOWS2003_SCHEMA34.LDF
SCHEMA46.LDF
The following are the modifications we did into one of the LDF files:
dn: CN=ms-Exch-ELC-Folder-Link,
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,
objectClass: attributeSchema
# ============================================================
# The link's linkID automatic OID goes here
linkID: 1.2.840.113556.1.2.50
# ============================================================
schemaIdGuid:: E+URcZKecUGRdE+GbC1zaQ==
searchFlags: 0
dn: CN=ms-Exch-ELC-Folder-BL,
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,
objectClass: attributeSchema
# ============================================================
# The backlink's linkID automatic reference goes here
linkID: msExchELCFolderLink
# ============================================================
schemaIdGuid:: K6eLJBaO+06RJ+MH5uh1rA==
searchFlags: 0
dn: CN=ms-Exch-Mailbox-Template-Link,
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,
objectClass: attributeSchema
# ============================================================
# The link's linkID automatic OID goes here
linkID: 1.2.840.113556.1.2.50
# ============================================================
schemaIdGuid:: NZNi518rk0WGVoUjmpxG9g==
searchFlags: 0
dn: CN=ms-Exch-Mailbox-Template-BL,
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,
objectClass: attributeSchema
# ============================================================
# The backlink's linkID automatic reference goes here
linkID: msExchMailboxTemplateLink
# ============================================================
schemaIdGuid:: bejPk9DHCEGxF5zHKQjubg==
searchFlags: 0