Der Garbage Collection-Prozess der Active Directory-Datenbank und die Berechnung der zulässigen Intervalle

In diesem Artikel werden der Prozess der Garbage Collection der Active Directory-Datenbank und die Berechnung der zulässigen Intervalle beschrieben.

Gilt für: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Ursprüngliche KB-Nummer: 198793

Zusammenfassung

Die Active Directory-Datenbank enthält einen Garbage Collection-Prozess, der unabhängig auf jedem Domänencontroller im Unternehmen ausgeführt wird.

Weitere Informationen

Die Garbage Collection ist ein Housekeeping-Prozess, der darauf ausgelegt ist, Speicherplatz in der Active Directory-Datenbank frei zu geben. Dieser Prozess wird auf jedem Domänencontroller im Unternehmen mit einem Standardlebensdauerintervall von 12 Stunden ausgeführt. Sie können dieses Intervall ändern, indem Sie das garbageCollPeriod-Attribut im unternehmensweiten DS-Konfigurationsobjekt (NTDS) ändern.

Der Pfad des Objekts in der Contoso.com Domäne sieht wie folgt aus:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=CONTOSO,DC=COM

Verwenden Sie ein Active Directory-Bearbeitungstool, um das garbageCollPeriod-Attribut festzulegen. Unterstützte Tools sind Adsiedit.msc, Ldp.exe und ADSI-Skripts (Active Directory Service Interfaces).

Wenn ein Objekt gelöscht wird, wird es nicht aus der Active Directory-Datenbank entfernt. Stattdessen wird das Objekt stattdessen zu einem späteren Zeitpunkt zum Löschen markiert. Diese Markierung wird dann auf andere Domänencontroller repliziert. Daher beginnt der Garbage Collection-Prozess, indem die Reste zuvor gelöschter Objekte aus der Datenbank entfernt werden. Diese Objekte werden als Tombstones bezeichnet. Als Nächstes löscht der Garbage Collection-Prozess unnötige Protokolldateien. Schließlich startet der Prozess einen Defragmentierungsthread, um zusätzlichen freien Speicherplatz zu beanspruchen.

Darüber hinaus gibt es zwei Methoden zum Defragmentieren der Active Directory-Datenbank. Eine Methode ist ein Online-Defragmentierungsvorgang, der als Teil des Garbage Collection-Prozesses ausgeführt wird. Der Vorteil dieser Methode besteht darin, dass der Server nicht offline geschaltet werden muss, damit der Vorgang ausgeführt wird. Diese Methode reduziert jedoch nicht die Größe der Active Directory-Datenbankdatei (Ntds.dit). Mit der anderen Methode wird der Server offline geschaltet und die Datenbank mithilfe des Hilfsprogramms Ntdsutil.exe defragmentiert. Bei diesem Ansatz muss die Datenbank im Reparaturmodus gestartet werden. Der Vorteil dieser Methode besteht darin, dass die Größe der Datenbank geändert und nicht verwendeter Speicherplatz entfernt wird. Daher wird die Größe der Datei Ntds.dit reduziert. Um diese Methode verwenden zu können, muss der Domänencontroller offline geschaltet werden.

Grenzwerte für garbageCollPeriod:
Der Mindestwert ist 1, und der Höchstwert beträgt 168 für eine Woche. Der Standardwert für den Wert ist 12 Stunden.

Mindestwert für Tombstone-Lebensdauer:
Der Mindestwert für die Tombstone-Lebensdauer beträgt 2 Tage für die Berechnung der KCC-Ausführungsdauer.

Die AD-Datenbankebene erzwingt eine zusätzliche Metrik. TSL-Tage dürfen nicht das Dreifache des Garbage Collector-Intervalls sein. Basierend auf dem Standardwert von 12 Stunden beträgt die TSL mindestens 2 Tage. Wenn das GC-Intervall 20 Stunden beträgt, beträgt das TSL-Minimum 3 Tage (muss größer als 60 Stunden sein). Wenn das GC-Intervall 25 Stunden beträgt, erreichen Sie mehr als drei Tage (mit 75 Stunden), und das TSL-Minimum beträgt 4 Tage.

Der Abfang mit den Überprüfungen, die sowohl die Datenbankebene als auch die KCC durchführen, besteht darin, dass, wenn die TSL niedriger als der zulässige Mindestwert ist, nicht auf den Mindestwert von 2 oder mehr Tagen rückgängig machen, sondern auf den Standardwert von 60 oder 180 Tagen.

Wichtig

Falls TSL aufgrund eines Konflikts auf den Standardwert korrigiert wird, wird der Wert für das Garbage Collection-Intervall ebenfalls auf den Standardwert von 12 Stunden festgelegt.

Standardwerte für die Tombstone-Lebensdauer

Verlauf

Die Standard-Tombstone-Lebensdauer (TSL) in Windows Server 2003 betrug 60 Tage und war als zu kurz erwiesen. Beispielsweise kann ein vorab bereitgestellter Domänencontroller länger als 60 Tage in der Übertragung sein. Ein Administrator kann einen Replikationsfehler erst beheben oder einen Offlinedomänencontroller in Betrieb nehmen, bis die TSL überschritten wird. Windows Server 2003 Service Pack 1 (SP1) hat die TSL in den folgenden Szenarien von 60 auf 180 Tage erhöht:

• Ein Windows NT 4.0-Domänencontroller wird mithilfe von Windows Server 2003 SP1-Installationsmedien auf Windows Server 2003 aktualisiert, um eine neue Gesamtstruktur zu erstellen.
• Ein Windows Server 2003 SP1-Computer erstellt eine neue Gesamtstruktur.

Windows Server 2003 SP1 ändert den Wert von TSL nicht, wenn eine der folgenden Bedingungen zutrifft:

• Eine Windows 2000-Domäne wird mithilfe von Installationsmedien für Windows Server 2003 mit SP1 auf Windows Server 2003 aktualisiert.
• Windows Server 2003 SP1 wird auf einem Domänencontroller installiert, auf dem die ursprüngliche Version von Windows Server 2003 ausgeführt wird.

Das Erhöhen der TSL für eine Domäne auf 180 Tage hat die folgenden Vorteile:

• Sicherungen, die in Datenwiederherstellungsszenarien verwendet werden, haben eine längere Lebensdauer.
• Systemstatussicherungen, die für die Installation von Medienaktionen verwendet werden, haben eine längere Nutzungsdauer.
• Domänencontroller können länger offline sein. Vorab bereitgestellte Computer nähern sich dem TSL-Ablauf seltener.
• Ein Domänencontroller kann nach einer längeren Offlinezeit erfolgreich zur Domäne zurückkehren.
• Das Wissen über gelöschte Objekte wird auf dem ursprünglichen Domänencontroller länger aufbewahrt.

Die Standardeinstellung in Ihrer Gesamtstruktur hängt vom Betriebssystem bei der "Geburt" der Gesamtstruktur und den Upgrademethoden ab, wie oben beschrieben.

Wenn Sie sich nicht sicher sind, wie viel TSL in Ihrer Gesamtstruktur verwendet wird, empfiehlt es sich, sie explizit festzulegen, und bei Bedarf auch msDS-deletedObjectLifetime.
Referenz: Der AD-Papierkorb: Verstehen, Implementieren, Bewährte Methoden und Problembehandlung