MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

AD Lingering Objects

Warum bricht die Replikation, wenn ein DC zu lange offline oder nicht erreichbar ist und wie löse ich den Knoten?

Hintergründe und Tombstone

Wenn ein Domain Controller zu lange nicht mehr mit anderen DCs kommunizieren kann, dann stoppt die Replikation. Ursache ist u.a., dass gelöschte Objekte nach Ablauf der Tombstone-Zeit real gelöscht werden. Wenn ein anderer DC länger als diese Zeitspanne die Änderungen nicht bekommt, dann hat übersieht er den "Delete"-Befehl. Die beiden Verzeichnisdienste nicht sind mehr synchron, weil ein DC Objekte hat, die es laut dem anderen DC gar nicht mehr gibt. Das würde nicht mal sofort auffallen, wenn es z.B. ein nicht mehr genutztes Benutzerkonto ist. Aber da die AD-Replikation sich anhand der aufsteigenden USNs durcharbeitet, können auch folgende Updates nicht repliziert werden.

Die Tombstone-Zeit war bei Windows 2000 noch bei 60 Tagen und erst mit Windows 2003SP1 wurde dieser Wert auf 180 angehoben

Achtung: Wer ein AD schon vorher installiert und danach immer nur aktualisiert hat, hat eventuell noch 60 Tage und sollte dies ändern. Schaue Sie einfach mit ADSIEDIT oder PowerShell hier nach:

CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domain>,DC=<TLD>


Auszug aus ADSIEDIT

Sollte hier noch eine 60 stehen, dann wäre eine Änderung angebracht. Eine Erhöhung ist unkritisch, da damit nur festgelegt wird, wann jeder DC für sich die gelöschten Objekte wegräumt. Das geht natürlich auch alles per PowerShell:

$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext

# Aktuelle Einstellung lesen
Get-ADObject `
   -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext" `
   -Partition $ADForestconfigurationNamingContext `
   -Properties tombstoneLifetime `
| select tombstoneLifetime

#Setzen geht ebenfalls mit 
Set-ADObject `
   -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext" `
   -Partition $ADForestconfigurationNamingContext `
   -Replace @{tombstonelifetime='180'}

Replikationsfehler

Bei mir ist es in einem Testfeld passiert, bei dem ein DC einer Subdomain über 180 Tage nicht eingeschaltet war. Als ich dann zum Artikel Get-USNChanges ein paar Details zur USN-Replikation über mehrere Domains im gleichen Forest nachstellen wollte, habe ich meine neuen Änderungen nicht in der andere Domain gesehen. Ein Versuch die Replikation zu forcieren ergab dann folgenden Fehler:

In einer produktiven Umgebung wäre das nun ein Schreckmoment, denn man hat hier 180 Tage lang nicht bemerkt, dass ein Active Directory ein Problem hat. Der normale Weg wäre hier, den defekten und veralteten DC möglichst schnell herunterzufahren, zu löschen und neu zu installieren. Das ist allerdings knifflig, wenn der DC ebenfalls schon 180 Tage der länger weitergelaufen ist und auch dort z.B. neue Benutzer angelegt wurden.

Die Fehler finden wir auch im Eventlog:


Beispiel Eventlog 2042

In weiteren Eventlog-Einträgen werden dann auch einzelne Objekte aufgeführt:


Beispiel EventlogID 1946

Dann wäre es schon wünschenswert, die Replikation wieder aktivieren zu können.

Lingering Objects erkennen

Das ist sogar möglich, denn Sie können dem Active Directory schon mitteilen, dass er diese Fehler "heilen" soll, indem er die Objekte wieder neu anlegt. Bei einzelnen Objekten funktioniert dies aber bei komplexeren Dingen, z.B. Mitgliedschaften in Gruppen etc. kann das zu Problemen führen. Daher ist es wichtig, dass wir zuerst einmal sehen, welchen Rückstand oder Grad der Unstimmigkeit in der Umgebung vorliegen.

Microsoft stellt dazu den "Lingering Object Liquidator (LoL)" bereit, der uns die Arbeit deutlich vereinfacht. Damit kann ich von einem System aus gleich ausgewählte oder sogar alle DCs und Namenkontexte des gesamten Forest abfragen und vergleichen lassen.

Der Lingering Object Liquidator (LoL) macht die Analyse einfach aber sie sollten wissen, was sie tun. Wenn Sie z.B. mehrere DCs haben und es nur einen DC betrifft, dann sind noch zum Rest übertragene Änderungen wichtig, während Sie überzählige Objekte vermutlich einfach löschen können, ehe Sie die Replikation erzwingen.

Lingering Object Liquidator (LoL)
https://www.microsoft.com/download/details.aspx?id=56051
http://aka.ms/msftlol

In meinem Testfeld habe ich jede Meng "DEL"-Objekte in meinem SubDC gefunden aber keine weiter relevanten Objekte 

Hier konnte ich die "DEL"-Objekte einfach entfernen. So habe ich auch verhindert, dass diese Objekte mit der nächsten Replikation wieder "reaktiviert" werden und irgendwo rumliegen. Die Aktivitäten werden ebenfalls im Eventlog protokolliert. Hier nur ein Auszug:

Im Idealfall haben sie keine "Lingering Objects" mehr auf ihren Domain Controllern. 

Strict Replication Consistency

Wenn Sie mit Replmon, AD-Replikation, Lingering Objects, Repadmin u.a. arbeiten, dann stoßen sie früher oder später auch auf die Einstellung "Strict Replication Consistency", die sie pro Domain Controller in der Registrierung ein- und ausschalten können. Die Funktion ist normalerweise "1", d.h. auf "Strict" gesetzt.

Strict Replication Consistency is a registry value that prevents destination domain controllers (DC) from replicating in lingering objects. Lingering objects are objects that have been deleted on one DC but replication failures prevent a partner DC learning of the deletion.
Quelle:  Strict Replication Consistency - Myth versus Reality
https://techcommunity.microsoft.com/blog/askds/strict-replication-consistency---myth-versus-reality/397453

Auf meinem DC im Testlabor finde ich folgenden Eintrag:

Sie sollten den Wert NICHT ändern, da ansonsten der DC auch die lingering Objects von anderen DCs eingehend repliziert und damit dieser wieder auftauchen. Sie sollten besser die Eventlogs überwachen, um das Erscheinen solcher Objekte frühzeitig zu erkennen und die Ursache zu lösen.

Sie können den Wert per REGEDIT oder REPADMIN setzen

REM Strikte Prüfung erzwingen
repadmin.exe /regkey  +strict

REM Strikte Prüfung abschalten (nicht ratsam)
repadmin.exe /regkey  -strict

Das ist wie ein Nagel im Reifen. Es ist besser den Verlust des Luftdrucks zu erkennen und zu reagieren als einen Reifen während der Autobahnfahrt zu verlieren. Verfügbarkeit und Stabilität durch Monitoring von Systemen ist wichtiger und billiger als Hochverfügbarkeit durch Clustern, die hier sowieso nicht hilft.

Sorgen Sie erst dafür, dass sie die "Lingering Objects" loswerden.

Replikation starten

Damit löst sich aber noch nicht das Problem, dass die DCs eine Replikation blockieren. Hierzu müssen wir temporär einen zweiten Weg wählen. Wir können den DC anweisen, auch mit korrupten Partnern zu sprechen. Dazu gibt es extra das Eventlog 2042 mit folgendem sehr ausführlichen Text:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          19.03.2025 15:09:20
Event ID:      2042
Task Category: Replication
Level:         Error
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      DC01.carius.de
Description:
It has been too long since this machine last replicated with the named source machine. 
The time between replications with this source has exceeded the tombstone lifetime. 
Replication has been stopped with this source.
The reason that replication is not allowed to continue is that the two DCs may contain 
lingering objects.  Objects that have been deleted and garbage collected from an Active 
Directory Domain Services partition but still exist in the writable partitions of other 
DCs in the same domain, or read-only partitions of global catalog servers in other 
domains in the forest are known as "lingering objects".  If the local destination DC 
was allowed to replicate with the source DC, these potential lingering object would be 
recreated in the local Active Directory Domain Services database.
 
Time of last successful replication: 2021-02-21 22:54:46 
Invocation ID of source directory server: b2cbf48d-59a9-40be-a439-87566a15711b 
Name of source directory server: 6b426733-9511-4735-b12e-ffb3070986ab._msdcs.carius.de 
Tombstone lifetime (days): 180 
 
The replication operation has failed.
 
User Action:
 The action plan to recover from this error can be found at http://support.microsoft.com/?id=314282.
 If both the source and destination DCs are Windows Server 2003 DCs, then install the support 
    tools included on the installation CD.  To see which objects would be deleted without 
    actually performing the deletion run "repadmin /removelingeringobjects <Source DC> 
    <Destination DC DSA GUID> <NC> /ADVISORY_MODE". The event logs on the source DC will 
    enumerate all lingering objects.  To remove lingering objects from a source domain 
    controller run "repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>".
 If either source or destination DC is a Windows 2000 Server DC, then more information on 
    how to remove lingering objects on the source DC can be found at 
    http://support.microsoft.com/?id=314282 or from your Microsoft support personnel.
 If you need Active Directory Domain Services replication to function immediately at all 
    costs and don't have time to remove lingering objects, enable replication by setting 
    the following registry key to a non-zero value:
 
    Registry Key:
    HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
 
Replication errors between DCs sharing a common partition can prevent user and computer 
accounts, trust relationships, their passwords, security groups, security group memberships 
and other Active Directory Domain Services configuration data to vary between DCs, affecting 
the ability to log on, find objects of interest and perform other critical operations. 
These inconsistencies are resolved once replication errors are resolved.  DCs that fail to 
inbound replicate deleted objects within tombstone lifetime number of days will remain 
inconsistent until lingering objects are manually removed by an administrator from each local DC.
Additionally, replication may continue to be blocked after this registry key is set, 
depending on whether lingering objects are located immediately.

Alternate User Action:
 
Force demote or reinstall the DC(s) that were disconnected. 

Voraussetzung ist natürlich, dass Sie die Korruption restlos beseitigt haben, ehe Sie den folgenden Schlüssel setzen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Allow Replication With Divergent and Corrupt Partner"=dword:00000001

Das geht auch per Kommandozeile:

repadmin.exe /regkey +allowDivergent

Ein Neustart des Server oder des NTDS-Service ist nicht erforderlich. Die Änderungen wirken sofort. Allerdings sollten Sie danach entweder mit AD Sites&Services, REPADMIN o.ä. die Replikation anstoßen und das Ergebnis kontrollieren. Vergessen Sie danach auch nicht, diese Änderungen wieder zurück zu stellen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Strict Replication Consistency"=dword:00000000
"Allow Replication With Divergent and Corrupt Partner"=dword:00000000
repadmin.exe /regkey -allowDivergent
repadmin.exe /regkey +strict

Danach würde ich noch einmal nacheinander auf jedem DC ein Objekt in jeder Partition ändern und den Erfolg überprüfen. Ich weiß, dass dies ziemliche Handarbeit sein kann. Vielleicht ist es nun an der Zeit, das Monitoring entsprechend einzuschalten, z.B. wie auf End2End AD beschrieben.

Weitere Links