L’erreur 1988 s’affiche dans le journal des événements du service d’annuaire d’un contrôleur de domaine Active Directory

L’erreur 1988 s’affiche dans le journal des événements du service d’annuaire d’un contrôleur de domaine (DC) :
 
Un texte supplémentaire dans la description de l’événement indique le contrôleur de domaine source, l’objet persistant détecté et une procédure d’action recommandée. La description complète de l’événement est longue.

D’autres avertissements et erreurs peuvent apparaître dans le journal des événements du service d’annuaire d’un contrôleur de domaine concerné.

Les objets persistants sont supprimés et le garbage collecté à partir de la base de données AD sur un contrôleur de domaine, mais existe toujours sur au moins un autre contrôleur de domaine. Cela se produit en raison d’un échec persistant de la réplication entre les contrôleurs de domaine, comme illustré dans l’exemple suivant.

Supposons qu’il existe trois contrôleurs de domaine dans un domaine ; DC1, DC2 et DC3. La cohérence stricte de la réplication est activée sur les trois contrôleurs de domaine, mais les trois sont autorisées à être répliquées avec des partenaires divergents. (Voir ci-dessous pour plus d’informations sur ces concepts.) Leurs bases de données AD sont synchronisées. Les événements suivants se produisent ensuite dans l’ordre chronologique :

1. DC1 est mis hors ligne, volontairement ou par un dysfonctionnement.
2. Un objet préexistant portant le nom User1 est supprimé sur DC2. DC3 réplique la suppression de DC2 en tant qu’objet tombstone. DC1 reste hors ligne et ne reçoit pas l’objet tombstone.
3. La durée de vie tombstone (TSL) réussit et DC1 reste hors ligne. L’objet de désactivation User1 est définitivement supprimé (« garbage collected ») de DC2 et DC3. User1 n’existe plus sur ces deux contrôleurs de domaine.
4. DC1 est mis en ligne. Il contient un objet persistant (User1), bien que cela n’ait aucun effet pour le moment.
5. Une modification est apportée à un attribut User1 sur DC1.
6. DC2 et DC3 sont informés d’une modification (modification apportée à User1).
7. Lorsque DC2 et DC3 tentent de répliquer la modification à partir de DC1, ils découvrent chacun que User1 n’existe pas dans leurs bases de données locales.
8. La tentative de réplication à partir de DC1 est empêchée sur DC2 et DC3, et l’erreur 1988 est consignée dans les journaux d’événements du service d’annuaire.

Le contrôleur de domaine avec l’erreur 1988 n’est pas le contrôleur de domaine qui contient des objets persistants. L’erreur indique que les objets persistants sont détectés sur l’un de ses partenaires de réplication. Un contrôleur de domaine avec cette erreur ne réplique pas les données AD du contrôleur de domaine partenaire indiqué dans l’erreur, mais peut toujours être répliqué à partir d’autres partenaires.

Cette erreur implique que la cohérence stricte de la réplication est activée sur le contrôleur de domaine local, car la tentative de réplication ne se produit pas. La cohérence stricte de la réplication est activée par défaut. Il est conçu pour détecter les objets persistants et les empêcher d’être incorporés dans le domaine après la suppression.

L’erreur implique également que la réplication divergente est activée. Lorsque cette option est activée, un contrôleur de domaine peut répliquer à partir d’un partenaire qui est inaccessible pendant plus longtemps que le TSL de la forêt. La réplication divergente n’est pasactivée par défaut, mais peut être activée manuellement par un administrateur.

Il n’est pas recommandé de tenter de résoudre le problème en désactivant la cohérence stricte de la réplication. Cela permet aux objets persistants de répliquer, ce qui pourrait entraîner la suppression définitive d’objets dans le domaine.

Au lieu de cela, les objets persistants doivent être supprimés des contrôleurs de domaine sur lesquels ils existent. La description de l’événement de l’erreur 1988 contient des instructions pour les supprimer à l’aide des commandes repadmin . Toutefois, ces commandes peuvent être fastidieuses, car l’identifiant global unique (GUID) d’au moins un contrôleur de domaine doit être connu. En outre, un seul contexte de dénomination peut être analysé à la fois. Microsoft a publié un outil, le liquidateur d’objets persistant (Lingering Object Liquidator, Lingering Object Liquidator), qui simplifie considérablement ce processus. Il fournit une interface graphique permettant de localiser et de supprimer des objets persistants dans une forêt Active Directory.

Le lien ci-dessus fournit une vue d’ensemble de l’outil, ses exigences et un lien vers sa page de téléchargement. La procédure suivante suppose que le PROGRAMME d’installation sans fil et ses conditions préalables sont déjà installés sur un contrôleur de domaine.

1. Assurez-vous que la règle de pare-feu RPC (Remote Event Log Management) est activée sur tous les contrôleurs de domaine qui sont analysés.
2. Lancez LE PROGRAMME D’INSTALLATION.
3. Cliquez sur Detect AD Topology. L’outil collecte des informations sur les contrôleurs de domaine dans la forêt AD.
4. Dans la liste déroulante Contexte de dénomination , sélectionnez le contexte de dénomination dans lequel un ou plusieurs objets persistants existent. Cela est obtenu à partir de la description de l’erreur 1988. Vous pouvez également sélectionner [Scan All NCs] pour analyser tous les contextes de dénomination des objets persistants.
5. Dans la liste déroulante Reference DC , sélectionnez le contrôleur de domaine qui a l’erreur 1988 dans son journal de service d’annuaire.
6. Dans la liste déroulante Target DC , sélectionnez un contrôleur de domaine qui contient des objets persistants. Cela est déterminé à partir de la description de l’erreur 1988, mais il mentionne le contrôleur de domaine source par son GUID hexadécimal plutôt que par son nom. Vous pouvez sélectionner à son tour chaque partenaire de réplication du contrôleur de domaine de référence.
7. Une fois qu’un contrôleur de domaine de référence et un contrôleur de domaine cible sont choisis, cliquez sur Détecter les objets persistants. Tous les objets persistants détectés sont répertoriés et automatiquement sélectionnés dans le volet supérieur. Un journal de l’analyse est généré dans le volet inférieur et écrit dans un fichier. Si aucun objet persistant n’est détecté, vérifiez la règle de pare-feu à l’étape 1.
8. Si aucun objet persistant n’est supprimé, effacez-les.
9. Cliquez sur Supprimer les objets persistants sélectionnés. Tous les objets persistants sélectionnés sont supprimés.
10. Effectuez d’autres analyses en fonction des besoins.