Fout 1988 wordt weergegeven in het gebeurtenislogboek van de directoryservice van een Active Directory-domeincontroller

Fout 1988 wordt weergegeven in het gebeurtenislogboek van de Directory Service van een domeincontroller (DC):
 
Verdere tekst in de gebeurtenisbeschrijving geeft de bron-DC aan, het achtergebleven object dat wordt gedetecteerd en een aanbevolen actie. De volledige beschrijving van het evenement is lang.

Andere waarschuwingen en fouten kunnen worden weergegeven in het gebeurtenislogboek van de Directory Service van een getroffen DC.

Achtergebleven objecten worden verwijderd en garbage verzameld uit de AD-database op een DC, maar bestaan nog steeds op ten minste één andere DC. Dit gebeurt als gevolg van een permanente replicatiefout tussen DC's, zoals wordt weergegeven in het volgende voorbeeld.

Stel dat er drie DC's in een domein zijn; DC1, DC2 en DC3. Strikte replicatieconsistentie is ingeschakeld op alle drie DEC's, maar alle drie mogen worden gerepliceerd met Partners van Replicatie. (Zie hieronder voor meer informatie over deze concepten.) Hun AD-databases worden gesynchroniseerd. De volgende gebeurtenissen treden vervolgens op in chronologische volgorde:

1. DC1 wordt offline gehaald, opzettelijk of door een storing.
2. Een bestaande object met de naam User1 wordt verwijderd op DC2. DC3 repliceert de verwijdering van DC2 als een tombstone-object. DC1 blijft offline en ontvangt het tombstone-object niet.
3. De tombstone lifetime (TSL) slaagt en DC1 blijft offline. Het User1 tombstone-object wordt permanent verwijderd ("garbage collected") van DC2 en DC3. Gebruiker 1 bestaat niet meer op deze twee DC's.
4. DC1 wordt online gebracht. Het bevat een achtergebleven object (Gebruiker1), hoewel dit voorlopig geen effect heeft.
5. Een bewerking wordt uitgevoerd naar een kenmerk van Gebruiker 1 op DC1.
6. DC2 en DC3 worden op de hoogte gebracht van een wijziging (de bewerking naar Gebruiker1).
7. Wanneer DC2 en DC3 proberen de wijziging te repliceren vanuit DC1, ontdekken ze allemaal dat Gebruiker1 niet bestaat in hun lokale databases.
8. De replicatiepoging van DC1 wordt voorkomen op DC2 en DC3 en fout 1988 wordt vastgelegd in de gebeurtenislogboeken van de Directory Service.

De DC met fout 1988 is niet de DC die achtergebleven objecten bevat. De fout geeft aan dat achtergebleven objecten worden gedetecteerd op een van de replicatiepartners. Een DC met deze fout repliceert geen AD-data van de partner-DC die in de fout is aangegeven, maar kan nog steeds worden gerepliceerd van andere partners.

Deze fout houdt in dat strikte replicatieconsistentie is ingeschakeld op de lokale DC, omdat de poging tot replicatie niet plaatsvindt. Strikte replicatieconsistentie is standaard ingeschakeld. Het is bedoeld om achtergebleven objecten te detecteren en te voorkomen dat ze opnieuw in het domein worden geïntroduceerd na verwijdering.

De fout betekent ook dat replicatie van replicaties is ingeschakeld. Wanneer dit is ingeschakeld, kan een DC worden gerepliceerd van een partner die langer onbereikbaar is dan de TSL van het forest. Replicatie van replicatie met replicatie van replicatie is nietstandaard ingeschakeld, maar kan handmatig worden ingeschakeld door een administrator.

Het wordt niet aanbevolen om het probleem op te lossen door strikte replicatieconsistentie uit te schakelen. Hierdoor kunnen achtergebleven objecten worden gerepliceerd, waardoor permanent verwijderde objecten in het domein kunnen worden gerepliceerd.

In plaats daarvan moeten achtergebleven objecten worden verwijderd uit de DC's waarop ze bestaan. De gebeurtenisbeschrijving van fout 1988 bevat instructies voor het verwijderen ervan met behulp van repadmin-opdrachten . Deze opdrachten kunnen echter omslachtige zijn, omdat de wereldwijd unieke ID (GUID) van ten minste één DC bekend moet zijn. Bovendien kan slechts één naamgevingscontext tegelijk worden gescand. Microsoft heeft een tool gepubliceerd, de Lingering Object Liquidator (LOL), die dit proces aanzienlijk vereenvoudigt. Het biedt een grafische interface voor het vinden en verwijderen van achtergebleven objecten in een AD-forest.

De bovenstaande koppeling biedt een overzicht van de tool, de vereisten en een koppeling naar de downloadpagina. In de volgende stappen wordt ervan uitgegaan dat de LOL en de vereisten al op een DC zijn geïnstalleerd.

1. Zorg ervoor dat de firewallregel voor Remote Event Log Management (RPC) is ingeschakeld op alle gescande DC's.
2. Start de LOL.
3. Klik op Detect AD Topology (AD-topologie detecteren). De tool verzamelt informatie over de DC's in het AD-forest.
4. Selecteer in de vervolgkeuzelijst Naming Context de naamgevingscontext waarin een of meer achtergebleven objecten bestaan. Dit is te vinden in de beschrijving van fout 1988. U kunt ook [Scan All NCs] selecteren om alle naamgevingscontexten voor achtergebleven objecten te scannen.
5. Selecteer in de vervolgkeuzelijst Reference DC de DC met fout 1988 in het Directory Service-logboek.
6. Selecteer in de vervolgkeuzelijst Doel-DC een DC die achtergebleven objecten bevat. Dit wordt bepaald uit de beschrijving van fout 1988, maar het vermeldt de bron-DC door de hexadecimale GUID in plaats van de naam. U kunt elke replicatiepartner van de referentie-DC op zijn beurt selecteren.
7. Zodra een referentie-DC en doel-DC zijn gekozen, klikt u op Detect Lingering Objects. Alle gedetecteerde achtergebleven objecten worden weergegeven en automatisch geselecteerd in het bovenste deelvenster. Een logboek van de scan wordt geproduceerd in het onderste deelvenster en naar een bestand geschreven. Als er geen achtergebleven objecten worden gedetecteerd, controleert u de firewallregel in stap 1.
8. Als achtergebleven objecten niet worden verwijderd, wist u ze.
9. Klik op Geselecteerde achtergebleven objecten verwijderen. Alle geselecteerde achtergebleven objecten worden verwijderd.
10. Voer indien nodig verdere scans uit.