Erreur « un attribut avec le même identificateur de lien existe déjà » lorsque vous exécutez ADPREP/FORESTPREP ou installez un nouveau contrôleur de domaine de version du système d’exploitation

Symptômes

Lorsque vous exécutez la commande ADPREP /FORESTPREP pour étendre le schéma de la forêt sur un ordinateur Windows Server 2003, la commande échoue et vous recevez le message d’erreur suivant :

Connexion à « < nom d’hôte du contrôleur de schéma > »

Connexion en tant qu’utilisateur actuel en utilisant SSPI

Importation de l’annuaire à partir du fichier « C:\WINDOWS\system32\sch44.ldf »

Chargement des entrées...

Erreur d’ajout sur la ligne 43 : refuse à exécuter.

L’erreur du côté serveur est « Échec de la mise à jour de schéma : un attribut avec le même identificateur de lien existe déjà. »

7 entrées modifiées.

Une erreur s’est produite dans le programme

Erreur : Importation à partir du fichier C:\WINDOWS\system32\sch44.ldf a échoué. Erreur de fichier est enregistré dans ldif.err.44.

En outre, si vous ouvrez le fichier d’erreur Ldif.err.44, vous voyez un message d’erreur semblable au suivant :

Entrée DN : CN =Ms-DS-pont-serveurs-utilisée, CN = Schema, CN = Configuration, DC = erreur d’ajout de < domaine > à la ligne 43 : refuse d’effectuer l’erreur du côté serveur est « mise à jour du schéma a échoué : un attribut avec le même identificateur de lien existe déjà. » Une erreur s’est produite dans le programme

Notez que cette erreur se produit également sur d’autres attributs. Par exemple, l’erreur se produit lorsqu’une modification de schéma affecte un ID de lien 2046 à l’objet camDBSignonRef . L' attribut de Microsoft ms-PKI-DPAPIMasterKeys a cette linkID dans le schéma de Windows Server 2008 mise à jour.

Cause

Cette erreur se produit lorsque la commande ADPREP /FORESTPREP tente d’ajouter un nouvel objet à la partition de schéma à l’aide d’un ID de lien qui a été déjà attribué à un objet existant dans la partition de schéma.

Important Bien qu’il s’agit d’un problème grave, au point où l’extension du schéma a échoué, la forêt n’est pas dans un état défectueux et ne pas devoir être réinitialisée à l’état précédent. Toutefois, nous recommandons d’effectuer un suivi sur le problème rapidement. Puis, si vous devez exécuter une récupération de forêt, vous ne perdrez pas beaucoup de modifications comme le rembobinage de la forêt.

Résolution

La procédure de réparation décrite dans cette section nécessite au moins Windows Server 2003 sur le contrôleur de schéma. La procédure peut également être appliquée à d’autres attributs.

Ne modifiez pas l’ID de lien pour les objets existants dans la partition de schéma, car le comportement peut provoquer la réplication Active Directory échoue avec une incompatibilité de schéma.

Important Nous recommandons vivement que vous contactez les Services de Support technique Microsoft pour vous aider à résoudre ce problème. Bien que la forêt est probablement que pas dans un état irréparable à ce stade, si vous souhaitez continuer la réparation à votre rythme, vous pouvez involontairement une autre erreur et endommager la forêt bien que vous devez effectuer une récupération de forêt. Par conséquent, il se peut que vous devez vous assurer ont des sauvegardes d’état du système valide à partir de deux ou plusieurs contrôleurs de domaine dans chaque domaine de la forêt avant de poursuivre.

Pour résoudre ce problème, procédez comme suit :
  1. Identifier le conflit linkID qui est ajouté. Pour ce faire, passez en revue le fichier de définition de schéma dans le Ldif.err. fichier de < nombre > . Dans ce cas, vous constaterez que l’attribut CN = ms-DS-pont-serveurs-utilisée, CN = Schema, CN = Configuration, DC =< nom de la forêt > dans sch44.ldf est assignée une linkID de 2160.
  2. Identifier l’objet dans la partition de schéma cible qui possède actuellement le linkID en conflit. Vous pouvez rechercher le schéma sur le maître de schéma cible pour voir quel objet existant a été affecté le linkID qui est en conflit avec l’objet dans le fichier .ldf Sch < xx >. Pour ce faire, utilisez REPADMIN, LDIFDE, LDP. EXE, ou un outil équivalent. Quelques exemples.

    Pour une recherche REPADMIN :
    repadmin /showattr fsmo_schema: ncobj:schema: /filter:"(linkid=2160)" /subtree 


    Pour une recherche LDIFDE :
    LDIFDE /f <filename> /d "CN=Schema,CN=Configuration,DC=<forest root domain>" /r (linkid=2160)  


    Pour une recherche de LDP :
    BaseDN: CN=Schema,CN=Configuration,DC=<forest name>Scope : Subtree
    Filter: (linkid=2160)

  3. Recherchez le fichier de schéma qui est inclus avec l’attribut affecté par exemple Ms-DS-pont-serveurs-utilisée ou Ms-DPAPIMasterKeys-infrastructure à clé publique. Les fichiers de schéma se trouvent dans \support\adprep. Rechercher les fichiers pour l’attribut qui est en conflit. Par exemple, utilisez la commande suivante :
    Findstr ms-DS-pont-serveurs-utilisée d:\support\adprep\sch*.ldf
  4. Dans un éditeur de texte, ouvrez le fichier que vous recherchez.
  5. Affecter des nouveau lien ID aux objets de liaison directe dans le Sch < xx > fichiers .ldf qui entrent en conflit avec linkIDs des objets existants dans la partition de schéma. Ceci peut être réalisé en assignant l’attribuer à l’identificateur d’objet connu (également appelé OID) « 1.2.840.113556.1.2.50 » à la linkID champ pour tous les attributs de liaison directe dans le SCH < xx > .ldf dont conflit linkIDs avec des objets existants dans la forêt cible. Le « 1.2.840.113556.1.2.50 » identificateur d’objet assignera un ID unique de lien généré automatiquement dans le schéma cible.

    Pour résoudre le problème de l’exemple de 2160 linkID qui est défini dans Sch44.ldf pour CN = ms-DS-pont-serveurs-utilisée, procédez comme suit :
    1. Ouvrez le fichier Sch44.ldf. Vous voyez le texte suivant pour CN = ms-DS-pont-serveurs-utilisée, CN = Schema, CN = Configuration, DC = < nom de la forêt >:
      dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaAdd adminDescription: List of bridge head servers used by KCC in the previous run. adminDisplayName: ms-DS-BridgeHead-Servers-Used attributeID: 1.2.840.113556.1.4.2049 attributeSyntax: 2.5.5.7 cn: ms-DS-BridgeHead-Servers-Used instanceType: 4 isSingleValued: FALSE lDAPDisplayName: msDS-BridgeHeadServersUsed linkID: 2160 objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X objectClass: attributeSchema oMObjectClass:: KoZIhvcUAQEBCw== oMSyntax: 127 schemaFlagsEx: 1 schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg== searchFlags: 0 showInAdvancedViewOnly: TRUE systemFlags: 25 
    2. Copier ce texte dans un nouveau fichier txt et puis enregistrez le fichier à l’aide d’un nouveau nom. Par exemple, enregistrez le fichier sous « New-BridgeHeadServersUsed.ldf. »

      Remarque Effectuez pas modifier le fichier de schéma existant.
    3. Modifier le champ linkID à partir de « 2160 » à « 1.2.840.113556.1.2.50 » pour déclencher la génération automatique de linkIDs unique sur maîtres d’opérations de schéma de Windows Server. Vous voyez le texte suivant dans le fichier Sch44.ldf pour CN = ms-DS-pont-serveurs-utilisée, CN = Schema, CN = Configuration, DC = < DC >:
      dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=X changetype: ntdsSchemaAdd adminDescription: List of bridge head servers used by KCC in the previous run. adminDisplayName: ms-DS-BridgeHead-Servers-Used attributeID: 1.2.840.113556.1.4.2049 attributeSyntax: 2.5.5.7 cn: ms-DS-BridgeHead-Servers-Used instanceType: 4 isSingleValued: FALSE lDAPDisplayName: msDS-BridgeHeadServersUsed linkID: 1.2.840.113556.1.2.50 objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X objectClass: attributeSchema oMObjectClass:: KoZIhvcUAQEBCw== oMSyntax: 127 schemaFlagsEx: 1 schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg== searchFlags: 0 showInAdvancedViewOnly: TRUE systemFlags: 25 
    4. Avant la définition de l’attribut corrigée, ajoutez la section suivante :
      dn:  changetype: modify add: schemaupgradeinprogress schemaupgradeinprogress: 1 - 

      La ligne qui contient seulement le trait d’union (-) et la ligne vide qui suit sont importants.
  6. Mise à jour linkIDs pour les attributs de lien inverse lorsque les linkIDs pour les attributs de lien de transfert sont modifiées. Certains objets dans Active Directory ont les attributs de lien inverse, et autres objets ne le font pas. L’objet Ms-DS-pont-serveurs-utilisée qui est utilisé dans cet exemple n’a pas un attribut de lien inverse. Vous devez déterminer si l’objet est modifié a un attribut de lien inverse qui utilise un autre objet. Si l’objet affecté a un objet de lien inverse, l’objet lien précédent doit être modifié de la même manière.

    Vous pouvez trouver l’attribut de lien inverse pour la prochaine linkID portant un numéro impair dans les fichiers de définition de schéma. En règle générale, l’attribut de lien inverse est l’attribut suivant qui figure dans le fichier de schéma. Mais parfois il est dans un autre fichier. Par exemple, si vous avez identifié le problème linkID / d’attribut comme étant 2050 / CN = ms-DFSR-ComputerReference, CN = Schema, CN = Configuration, DC = < nom de la forêt >, le lien précédent aurait linkID 2051. Pour rechercher le lien ID 2051, exécutez la commande suivante :

    Findstr /c:"linkid: 2051" d:\support\adprep\sch*.ldf 
    Si un lien inverse est trouvé, copier la définition de l’attribut à partir du fichier d’importation de schéma dans le nouveau fichier d’importation de la même façon que vous avez copié l’attribut link de l’avant.

    Remarque La définition de linkID de l’objet lien précédent utilise un code codée en dur (numérique). La définition doit être modifiée activer l’identificateur d’objet de l’objet lien précédent pour être généré automatiquement.

    Dans ce scénario, un lien inverse pour ce lien de transfert est créé en affectant à l’ID de lien pour l’objet de lien inverse le ldapDisplayName de l’objet lien vers l’avant. Si l’attribut msDS-BridgeHeadServersUsed possédait un attribut de lien ascendant, la ligne linkID aurait l’aspect suivant :

    linkID: msDS-BridgeHeadServersUsed 
  7. En résumé, le fichier d’importation de schéma-nouveau BridgeHeadServersUsed.ldf a maintenant jusqu'à quatre commandes. Les commandes s’affichent dans l’ordre suivant :
    1. Activer le mode d’importation de schéma (schemaupgradeinprogress)
    2. Définition corrigée de l’attribut du lien suivant
    3. Instruction pour recharger le cache de schéma
    4. Facultatif : Corriger la définition de l’attribut de liaison descendante
  8. Enregistrez et fermez le fichier de mise à jour de schéma pour les attributs personnalisés que vous avez créé.
  9. Importer les nouvelles modifications personnalisées dans le schéma. Par exemple, utilisez la commande suivante :
    LDIFDE /i /f New-BridgeHeadServersUsed.ldf /j . 

    Vérifiez que les fichiers Ldif.err et Ldif.log pour toutes les erreurs. S’il existe des erreurs, contactez le Support technique de Microsoft à ce stade.
  10. Exécutez de nouveau le processus de mise à jour de schéma. Si vous pouvez exécuter l’outil d’extension de schéma ADPREP, réexécutez l’outil en utilisant le paramètre /forestprep . Si vous utilisiez le Gestionnaire de serveur pour l’installation du lecteurdu premier contrôleur de domaine de niveau supérieur, vous devez répéter le processus d’installation à partir du Gestionnaire de serveur.
  11. L’importation LDIF journaux tels que Ldif.err.44 peut contenir des avertissements sur le fait que les attributs à nouveau-BridgeHeadServersUsed.ldf existent déjà. Toutefois, l’objectif est que la mise à jour de schéma effectuée maintenant.

    S’il existe des erreurs, vous devez contacter les Services de Support technique de Microsoft à ce stade.

Plus d'informations

Pour plus d’informations sur la façon d’obtenir un ID de lien, accédez au site Web de Microsoft Developer Network (MSDN) suivant :Pour plus d’informations sur le linkID généré automatiquement, consultez le site Web MSDN suivant :Pour plus d’informations sur l’attribut linkID, accédez au site Web MSDN suivant :
Propriétés

ID d'article : 969307 - Dernière mise à jour : 14 janv. 2017 - Révision : 1

Windows Server 2012 R2 Standard, Windows Server 2012 Standard, Windows Server 2012 Standard, Windows Server 2012 Standard, Windows Server 2012 Standard, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter, Windows Server 2008 R2 Service Pack 1, Windows Server 2008 Service Pack 2, Microsoft Windows Server 2003 Service Pack 2

Commentaires