Restauration d'un contrôleur de domaine peut entraîner des incohérences entre les contrôleurs de domaine

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 316829
Symptômes
Restauration d'un contrôleur de domaine peut entraîner un ID d'événement : 1587, indiquant les incohérences entre les contrôleurs de domaine. Si cela se produit, certains des objets en attente peuvent être présents sur le contrôleur de domaine restauré. En outre, les nouveaux objets sur le contrôleur de domaine restauré ne sont pas répliquées.
Cause
Ce problème se produit car le contrôleur de domaine attribue un nouvel ID d'invocation, mais utilise la borne de note d'origine.
Résolution
Pour résoudre ce problème, procurez-vous le dernier service pack pour Windows 2000. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
260910 Comment faire pour obtenir le dernier Service Pack Windows 2000
Pour résoudre ce problème, procurez-vous le correctif qui est décrit dans l'article suivant de la Base de connaissances Microsoft :
299687 MS01-036 : Une fonction exposée en utilisant le protocole LDAP sur SSL pourrait permettre de modifier les mots de passe
Contournement
Pour contourner ce problème, rétrograder, puis promouvoir le contrôleur de domaine restauré. Avant de rétrograder le serveur concerné, forcez une réplication complète du serveur affecté à un autre contrôleur de domaine. (La synchronisation complète peut être beaucoup de domaines plus étendus de ressources.) Effectuer la synchronisation complète sur la partition de domaine et sur la partition de configuration. La ligne suivante illustre la syntaxe de la commande Repadmin que vous utilisez pour effectuer la synchronisation :
repadmin /sync <Naming context=""> <Dest dc=""> <Source dc="" guid="">[/ force] [/ Full]</Source> </Dest> </Naming>
La ligne suivante est un exemple de cette commande :
repadmin /sync DC = domaine, DC = racine good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force/complète
Dans l'exemple de commande,
  • « DC = domaine, DC = root » est le contexte de nommage de domaine.
  • « good_DC » est le contrôleur de domaine de destination. C'est le partenaire bonne qui va recevoir les mises à jour.
  • Le DSA GUID est le GUID de la réplication pour le contrôleur de domaine restauré. Vous pouvez obtenir cela en exécutant Repadmin /showreps sur le serveur restauré. Le GUID est répertorié en haut sous « Guid d'objet contrôleur de domaine ».
Si la synchronisation est réussie, le message d'erreur suivant s'affiche :
Synchronisation entre 122a5239-36b3-488a-b24c-971ed0ca8a46 et Good_DC s'est terminée correctement.


Répétez le processus pour le contexte de nommage de configuration en utilisant une commande semblable à la suivante :
repadmin /sync cn = configuration, DC = domaine, DC = racine good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force/complète
Le problème n'est pas susceptible d'être résolue après cela. Après cela, installez le correctif ou rétrograder et puis promouvoir le contrôleur de domaine pour résoudre le problème.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés au début de cet article. Ce problème a été corrigé dans Windows 2000 Service Pack 3.
Plus d'informations
Lorsque vous restaurez un contrôleur de domaine, l'USN le plus élevé validé est restaurée jusqu'au point où la sauvegarde a été créée. ID d'invocation du contrôleur de domaine est annulée et un nouveau est affecté. Lorsqu'un partenaire essaie de répliquer la première fois après la restauration, le message suivant est enregistré :

Type d'événement : informations
Source de l'événement : La réplication NTDS
Catégorie d'événement: (5)
L'ID d'événement : 1587
Date : 16/3/2001
Heure : 10:52:35: 00
Utilisateur : CONTOSO\CO-NA-DC-01$
Ordinateur: CO-DC-02
Description :
Le Service Agent DSA (Directory) correspondant au GUID d'objet d0a6a575-9702-4f4e-bf68-bb2a9f875188 a demandé commençant à un signet précédant la restauration de la plus récente de la DSA local à partir de la sauvegarde à l'USN 94727614 de modifications. Le signet est en cours d'ajustement comme suit: ID d'Invocation précédente : bc546028-fae7-4978-abe0-d294694da32b
Mise à jour objet USN précédente : 95853579
Mise à jour des propriétés précédentes USN: 95853579
Nouvel ID d'Invocation : ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Mise à jour de nouvel objet USN: 94727614
Nouvelle propriété mise à jour USN: 94727614


Cet événement est généralement utilisé pour un contrôleur de domaine restauré. En soi, cela n'indique pas un problème. Il s'agit d'un problème si vous ne répliquent pas d'objets qui sont créés sur le contrôleur de domaine restauré « en silence ».

Dans le scénario à problème, l'USN le plus élevé est restaurée. Toutefois, pendant le signet (ou réinitialisation de vecteur de « mise à jour »), le contrôleur de domaine source fournit la plus grande valeur d'USN qui était présente avant la restauration. Les objets qui ont des valeurs USNchanged entre la valeur d'attribut supérieure et inférieure highestCommittedUSN ne sont jamais considérés comme pour la réplication.

Par exemple : supposons que ce contrôleur de domaine 1 a un USN le plus élevé de 100. Son partenaire de réplication, le contrôleur de domaine 2, a un « vecteur » 100 pour le contrôleur de domaine 1.

Vous restaurez le contrôleur de domaine 1 à partir d'une sauvegarde dont l'USN le plus élevé est de 50. Après la prochaine réplication avec le contrôleur de domaine 2, contrôleur de domaine 1 réinitialise le signet à 100 (il doit être de 50). contrôleur de domaine 1 provient des modifications 51, 52 et 53. Lorsque le contrôleur de domaine 2 négocie la réplication, il considère jamais les modifications car il pense qu'il a des modifications à 100. le contrôleur de domaine 1 continue à apporter des modifications et atteint finalement 101. Modification 101 est répliquée, mais les modifications 51 à 100 ne sont pas.

Dans certains cas, vous pouvez détecter cet état. Utilisez Ldp ou ADSI Edit pour lire l'attribut highestCommittedUSN actuelle sur l'objet rootDSE du contrôleur de domaine restauré. Puis, comparez ces informations à la sortie de la repadmin /showreps /verbose commande sur l'un de ses partenaires. Dans la sortie de Repadmin, recherchez la valeur de « / ou d'USN ### » pour le contrôleur de domaine restauré pour chaque contexte d'attribution de noms. Si la valeur de Repadmin est supérieure à l'attribut highestCommittedUSN , le contrôleur de domaine restauré est l'origine du problème.

Notez que si le contrôleur de domaine restauré provenant de vecteurs suffisamment mises à jour que son attribut highestCommittedUSN ayant atteint ou dépassé la "mise à jour » qui est enregistrée sur les autres contrôleurs de domaine (comme dans l'exemple de cet article), certaines modifications ne seront jamais prises en compte pour la réplication. Toutefois, les nouvelles modifications sont répliquées. Les modifications non répliquées sont appelées « objets en attente ».
Références
Pour plus d'informations sur les objets en attente, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

317097 Objets en attente empêchent la réplication Active Directory

3125191 L'ID d'événement 1587 est généré sur un contrôleur de domaine lorsqu'il y a plus de deux contrôleurs de domaine dans le même site que de Lync server
kbDirServices

Propriétés

ID d'article : 316829 - Dernière mise à jour : 01/25/2016 22:02:00 - Révision : 1.0

  • kbbug kbdirservices kbfix kbwin2000presp3fix kbwin2000sp3fix kbmt KB316829 KbMtfr
Commentaires