Nachverfolgung verteilter Links auf Windows-basierten Domänencontrollern
In diesem Artikel wird beschrieben, wie Sie die Distributed Link Tracking-Dienste in Windows verwenden können, um die Erstellung und Verschiebung verknüpfter Dateien über NTFS-formatierte Volumes und Server nachzuverfolgen.
Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 312403
Übersicht über die Nachverfolgung von verteilten Links
Sie können den Distributed Link Tracking Server-Dienst und den Distributed Link Tracking Client-Dienst verwenden, um Links zu Dateien auf NTFS-formatierten Partitionen nachzuverfolgen. Die Nachverfolgung verteilter Links verfolgt Links in Szenarien nach, in denen der Link zu einer Datei auf einem NTFS-Volume hergestellt wird, z. B. Shellverknüpfungen und OLE-Links. Wenn diese Datei umbenannt, auf ein anderes Volume auf demselben Computer verschoben, auf einen anderen Computer verschoben oder in anderen ähnlichen Szenarien verschoben wird, verwendet Windows die Nachverfolgung von verteilten Links, um die Datei zu finden. Wenn Sie auf einen verschobenen Link zugreifen, sucht die Distributed Link-Nachverfolgung den Link. Sie wissen nicht, dass die Datei verschoben wurde oder dass die Nachverfolgung von verteilten Links verwendet wird, um die verschobene Datei zu finden.
Verteilte Linknachverfolgung besteht aus einem Clientdienst und einem Serverdienst. Der Distributed Link Tracking Server-Dienst wird ausschließlich auf Windows Server-basierten Domänencontrollern ausgeführt. Es speichert Informationen in Active Directory und stellt Dienste zur Unterstützung des Distributed Link Tracking Client-Diensts bereit. Der Distributed Link Tracking Client-Dienst wird auf allen Windows 2000- und Microsoft Windows XP-basierten Computern ausgeführt, einschließlich der Computer in Arbeitsgruppenumgebungen oder auf Computern, die sich nicht in einer Arbeitsgruppe befinden. Es bietet die einzige Interaktion mit Distributed Link Tracking-Servern.
Distributed Link Tracking-Clients stellen dem Distributed Link Tracking Server-Dienst gelegentlich Informationen zu Dateilinks bereit, die der Distributed Link Tracking Server-Dienst in Active Directory speichert. Distributed Link Tracking-Clients können auch diese Informationen vom Distributed Link Tracking Server-Dienst abfragen, wenn eine Shellverknüpfung oder ein OLE-Link nicht aufgelöst werden kann. Distributed Link Tracking-Clients fordern den Distributed Link Tracking-Server auf, Links alle 30 Tage zu aktualisieren. Der Distributed Link Tracking Server-Dienst löscht Objekte, die seit 90 Tagen nicht aktualisiert wurden.
Wenn eine Datei, auf die von einem Link verwiesen wird, auf ein anderes Volume (auf demselben Computer oder auf einem anderen Computer) verschoben wird, benachrichtigt der Distributed Link Tracking-Client den Distributed Link Tracking-Server, der ein linkTrackOMTEntry-Objekt in Active Directory erstellt. Ein linkTrackVolEntry-Objekt wird in Active Directory für jedes NTFS-Volume in der Domäne erstellt.
Hinweis
In Windows Server 2008 und höher ist der Distributed Link Tracking Server-Dienst nicht mehr in Windows enthalten. So können Sie die Objekte sicher aus Active Directory entfernen.
Distributed Link-Nachverfolgung und Active Directory
Verteilte Linknachverfolgungsobjekte werden auf allen Domänencontrollern in der Domäne repliziert, in der das Computerkonto gehostet wird, und auf allen globalen Katalogservern in der Gesamtstruktur. Der Distributed Link Tracking Server-Dienst erstellt Objekte im folgenden Distinguished Name Path:
CN=FileLinks,CN=System,DC= Domänennamecontainer von Active Directory
Distributed Link Tracking-Objekte befinden sich in den folgenden beiden Tabellen im Ordner CN=FileLinks,CN=System:
- CN=ObjectMoveTable,CN=FileLinks,CN=System,DC= Domänenname:
Dieses Objekt speichert Informationen zu verknüpften Dateien, die in der Domäne verschoben wurden.
CN=VolumeTable,CN=FileLinks,CN=System,DC= Domänenname:
Dieses Objekt speichert Informationen zu jedem NTFS-Volume in der Domäne.
Verteilte Linknachverfolgungsobjekte verbrauchen nur wenig Speicherplatz, aber sie können große Mengen an Speicherplatz in Active Directory verbrauchen, wenn sie sich im Laufe der Zeit ansammeln dürfen.
Wenn Sie die Nachverfolgung von verteilten Links deaktivieren und die Objekte für die Nachverfolgung von verteilten Links aus Active Directory löschen, kann das folgende Verhalten auftreten:
- Die Größe der Active Directory-Datenbank kann reduziert werden (dieses Verhalten tritt auf, nachdem die Objekte tombstoned und garbage collection wurden und nachdem Sie eine Offline-Defragmentierung durchgeführt haben).
- Der Replikationsdatenverkehr zwischen Domänencontrollern kann reduziert werden.
Standardeinstellungen für den Distributed Link Tracking Server-Dienst auf Windows Server-basierten Domänencontrollern
In Windows 2000, Windows XP und Windows Server 2003 ist der Startwert für den Distributed Link Tracking Client-Dienst auf Automatisch festgelegt. Auf Windows 2000-basierten Servern wird der Distributed Link Tracking Server-Dienst standardmäßig manuell gestartet. Wenn Sie jedoch Dcpromo.exe verwenden, um einen Server in eine Domäne hochzustufen, wird der Dienst Für die Nachverfolgung von verteilten Links so konfiguriert, dass er automatisch gestartet wird.
Bei Windows Server 2003-basierten Servern ist der Dienst für die Nachverfolgung von verteilten Links standardmäßig deaktiviert. Wenn Sie Dcpromo.exe verwenden, um einen Server in eine Domäne hochzustufen, ist der Distributed Link Tracking Server-Dienst nicht für den automatischen Start konfiguriert. Wenn ein Windows 2000-basierter Domänencontroller auf Windows Server 2003 aktualisiert wird, wird auch der Distributed Link Tracking Server-Dienst während des Upgrades deaktiviert. Wenn Sie ein Administrator sind und den Distributed Link Tracking Server-Dienst verwenden möchten, müssen Sie entweder Gruppenrichtlinie verwenden oder manuell festlegen, dass der Dienst automatisch gestartet wird. Darüber hinaus versucht der Distributed Link Tracking Client-Dienst auf Computern, auf denen Windows Server 2003 oder Windows XP SP1 ausgeführt wird, nicht standardmäßig, den Distributed Link Tracking Server-Dienst zu verwenden. Wenn Sie diese Computer so konfigurieren möchten, dass sie den Distributed Link Tracking Server-Dienst nutzen, aktivieren Sie die Richtlinieneinstellung Distributed Link Tracking-Clients die Verwendung von Domänenressourcen erlauben. Öffnen Sie dazu den Knoten Computerkonfiguration/Administrative Vorlagen/System in Gruppenrichtlinie.
Microsoft-Empfehlungen für die Nachverfolgung von verteilten Links auf Windows 2000-basierten Servern
Microsoft empfiehlt die Verwendung der folgenden Einstellungen für die Nachverfolgung verteilter Links auf Windows 2000-basierten Servern:
Deaktivieren Sie den Distributed Link Tracking Server-Dienst auf allen Domänencontrollern (dies ist die Standardkonfiguration auf allen Windows Server 2003-basierten Servern).
Aufgrund des Replikationsaufwands und des Speicherplatzes, den FileLinks-Tabellen in Active Directory verwenden, empfiehlt Microsoft, den Distributed Link Tracking Server-Dienst auf Active Directory-Domänencontrollern zu deaktivieren. Verwenden Sie eine der folgenden Methoden, um den Dienst zu beenden:
Doppelklicken Sie im Snap-In Dienste (Services.msc oder compmgmt.msc) auf den Dienst Distributed Link Tracking Server, und klicken Sie dann im Feld Starttyp auf Deaktiviert.
Definieren Sie den Startwert im Knoten Computerkonfiguration/Windows-Einstellungen/Systemdienste der Gruppenrichtlinie.
Definieren Sie die Richtlinieneinstellungen für eine Organisationseinheit, die alle Windows 2000-Domänencontroller hostet.
Starten Sie die Domänencontroller nach der Replikation der Richtlinie neu, damit die Richtlinie angewendet wird. Wenn Sie die Domänencontroller nicht neu starten, müssen Sie den Dienst auf jedem Domänencontroller manuell beenden.
Löschen von Objekten für die Nachverfolgung von verteilten Verbindungen von Active Directory-Domänencontrollern.
Weitere Informationen zum Löschen von Distributed Link Tracking-Objekten finden Sie im Abschnitt "Löschen des Nachverfolgungsobjekts für verteilte Verknüpfungen" dieses Artikels. Es wird empfohlen, Objekte nach dem Deaktivieren des Distributed Link Tracking Server-Diensts zu löschen.
Hinweis
Die Größe der Verzeichnisinformationsstruktur (Directory Information Tree, DIT) auf Domänencontrollern wird erst reduziert, wenn die folgenden Aktionen abgeschlossen sind.
Objekte werden aus dem Verzeichnisdienst gelöscht.
Hinweis
Gelöschte Objekte werden im Container "Gelöschte Objekte" gespeichert, bis die Tombstone-Lebensdauer abläuft. Der Standardwert für eine Tombstone-Lebensdauer beträgt 60 Tage. Der Mindestwert beträgt zwei Tage. Standardmäßig beträgt der Wert 180 Tage für neue Gesamtstrukturen, die zusammen mit Windows Server 2003 Service Pack 1 oder einer höheren Version von Windows Server 2003 installiert werden.
Sofern Sie nicht über eine starke Active Directory-Replikationsüberwachung verfügen, wird empfohlen, den Wert für 180 Tage zu verwenden. Verringern Sie diesen Wert nicht, um DIT-Größenprobleme zu behandeln. Wenn Sie Probleme mit der Datenbankgröße haben, wenden Sie sich an den Microsoft-Kundendienst.
Die Garbage Collection wurde bis zum Abschluss ausgeführt.
Sie verwenden Ntdsutil.exe, um die Datei Ntds.dit im Dsrepair-Modus zu defragmentieren.
Löschen von Objekten für die Nachverfolgung von verteilten Links
Es ist nicht wichtig, dass Sie die Distributed Link Tracking-Objekte manuell löschen, nachdem Sie den Serverdienst für die Nachverfolgung von verteilten Verbindungen beendet haben, es sei denn, Sie müssen den Speicherplatz, der von diesen Objekten genutzt wird, so schnell wie möglich freigeben. Distributed Link Tracking-Clients fordern den Distributed Link Tracking-Server auf, Links alle 30 Tage zu aktualisieren. Der Distributed Link Tracking Server-Dienst löscht Objekte, die seit 90 Tagen nicht aktualisiert wurden.
Wenn Sie die Dltpurge.vbs VBScript ausführen, werden alle Active Directory-Objekte, die vom Distributed Link Tracking Server-Dienst verwendet werden, aus der Domäne gelöscht, in der das Skript ausgeführt wird. Sie müssen das Skript auf einem Domänencontroller für jede Domäne in einer Gesamtstruktur ausführen. So führen Sie Dltpurge.vbs aus:
Rufen Sie das Dltpurge.vbs-Skript vom Microsoft-Produktsupport ab.
Beenden Sie den Distributed Link Tracking Server-Dienst auf allen Domänencontrollern in der Domäne, für die Dltpurge.vbs verwendet wird.
Verwenden Sie Administratorrechte, um sich bei der Konsole eines Domänencontrollers oder eines Mitgliedscomputers in der Domäne anzumelden, auf die Dltpurge.vbs abzielt.
Verwenden Sie die folgende Syntax, um Dltpurge.vbs über eine Befehlszeile auszuführen:
cscript dltpurge.vbs -s myserver -d dc=mydomain,dc=mycompany,dc=comIn dieser Befehlszeile:
- -s ist der DNS-Hostname des Domänencontrollers, auf dem Sie Distributed Link Tracking-Objekte löschen möchten.
- -d ist der Distinguished Name Pfad der Domäne, in der Sie Distributed Link Tracking-Objekte löschen möchten.
Führen Sie eine Offline-Defragmentierung der Datei Ntds.dit aus, nachdem die Objekte tombstoned und garbage collection wurden. Weitere Informationen zum Garbage Collection-Prozess finden Sie im folgenden Artikel der Microsoft Knowledge Base:
198793 Der Garbage Collection-Prozess der Active Directory-Datenbank
Ein Beispiel für eine Kundenerfahrung
Das worst-case-Szenario, das in diesem Abschnitt beschrieben wird, veranschaulicht einige Probleme, die beim Löschen einer großen Anzahl von Distributed Link Tracking-Objekten in einer großen Produktionsdomäne zu berücksichtigen sind.
Trey Research, ein fiktiver Fortune 500-Kunde mit über 40.000 Mitarbeitern weltweit, stellt eine einzelne Active Directory-Gesamtstruktur bereit, die aus einer leeren Stammdomäne mit untergeordneten Domänen besteht, die wichtige geografische Regionen der Welt (Nordamerika, Asien, Europa usw.) abbilden. Die größte Domäne in der Gesamtstruktur enthält etwa 35.000 Benutzerkonten und die gleiche Anzahl von Computerkonten.
Die Ntds.dit-Dateien wurden auf Raid-Arrays mit 18 Gigabyte (GB) platziert. Seit der ersten Bereitstellung von Windows 2000 sind die globalen Katalogdateien auf 17 GB angewachsen.
Trey Research möchte Windows Server 2003 innerhalb der nächsten 10 Tage bereitstellen, benötigt jedoch mindestens 1,5 GB verfügbaren Speicherplatz auf der Datenbankpartition, bevor das Upgrade initiiert wird. Sie benötigen so viel Speicherplatz, da Adprep.exe je nach zuvor installierten Hotfixes und Service Packs drei bis fünf geerbte Aces hinzufüge. Die folgenden Bedingungen tragen zur großen globalen Kataloggröße oder zum Mangel an Speicherplatz bei:
Bedingung 1: Trey Research war ein Early Adopter von Windows 2000, und die größten Laufwerke, die sie vom bevorzugten Hardwareanbieter erhalten haben, waren 9 GB oder 18 GB, als sie in einem Raid-Array konfiguriert wurden. Aktuelle Laufwerke sind doppelt so groß wie die Hälfte der Kosten.
Bedingung 2: Das DNS-Scavenging war für Active Directory-integrierte DNS-Zonen, die an jede Domäne in der Gesamtstruktur delegiert wurden, nicht aktiviert.
Bedingung 3: Domänenbenutzer durften Computerkonten in der Domäne erstellen. Administratoren hatten keinen wiederkehrenden Prozess, um verwaiste Computerkonten zu identifizieren und zu löschen.
Bedingung 4: Im Laufe der Zeit wurden Sicherheitsbeschreibungen von Administratoren, Service Packs und Hotfixes für NC-Köpfe (cn=schema, cn=configuration, cn= domain) und andere Container definiert, die Tausende von Objekten in Active Directory hosten. Darüber hinaus wurde die Überwachung für die gleichen Partitionen aktiviert. Wenn Sie Berechtigungen festlegen und die Überwachung für Objekte in Active Directory aktivieren, nimmt die Größe der Datenbank zu. Das Tool, das Windows 2000-Gesamtstrukturen und -domänen für Windows Server 2003-basierte Domänencontroller (Adprep) vorbereitet, fügt auch geerbte Asse hinzu. Daher musste Trey Research Speicherplatz auf dem Laufwerk freigeben, bevor die Domäne aktualisiert wurde.
Bedingung 5: Trey Research hat nicht regelmäßig Offline-Defragmentierungsverfahren von Ntds.dit-Dateien im Dsrepair-Modus ausgeführt.
Bedingung 6: Bei der Überprüfung des Domänennamencontainers CN=FileLinks,CN=System,DC= in der größten Domäne wurden mehr als 700.000 Objekte für die Nachverfolgung verteilter Links angezeigt. Die Sicherheitsbeschreibung für jedes Distributed Link Tracking-Objekt betrug etwa 2 Kilobyte (KB). Jede dieser Bedingungen wurde für ihren Beitrag zur 17-GB-DIT-Datei ausgewertet:
Bedingung 1: Trey Research entschied sich aufgrund der Kosten und der Zeit, die dafür erforderlich wäre, keine neuen Laufwerke bereitzustellen. Außerdem benötigten sie den Speicherplatz nur vorübergehend, da sie erwartet haben, dass die Active Directory-Datenbank nach dem Upgrade auf Windows Server 2003 und dem Abschluss des SIS-Prozesses (Single Instance Store) verkleinern wird (SIS implementiert eine effizientere Speicherung von Berechtigungen in Active Directory-Datenbanken).
Bedingungen 2 und 3: Trey Research entschied, dass diese Bedingungen die besten Methoden waren; Aber selbst wenn Trey Research sie implementieren würde, würden sie nicht die erforderlichen Ergebnisse erzielen. Sie haben beschlossen, das DNS-Scavenging zu aktivieren, da es einfach implementiert werden kann.
Bedingung 4: Trey Research erkannte, dass sie, wenn sie Sicherheitsbeschreibungen und Systemzugriffssteuerungslisten (SACLs) neu definieren würden, die gewünschten Ergebnisse erzielen würden, aber sie entschieden, dass die Implementierung dieses Verfahrens zeitaufwändig wäre, bis sie die Größenreduzierung, den Replikationsaufwand und vor allem die Programm-/Verwaltungskompatibilität in dem Labszenario, das die Produktionsumgebung widerspiegelt, gründlich testen konnten.
Da Trey Research Windows 2000 SP2 und einige Hotfixes bereitgestellt hat, wurde erwartet, dass die von Adprep hinzugefügten inkrementellen geerbten Ass (zu Objekten in der Domäne NC) bis zu 300 Megabyte (MB) betragen könnten. Sie können dieses Verhalten in einer Labumgebung überprüfen, die zum Testen von Upgrades der Produktionsgesamtstruktur verwendet wird.
Bedingung 5: Trey Research hat erkannt, dass sie bei einer Offline-Defragmentierung möglicherweise keine "Leerzeichen" in der Datei "Ntds.dit" wiederherstellen. Tatsächlich bemerkten Trey Research-Administratoren unmittelbar nach Abschluss der Offline-Defragmentierung einen Anstieg der Datenbankgröße. Dieses Verhalten ist auf eine Ineffizienz in der Windows 2000-Datenbank-Engine zurückzuführen. Diese Engine wurde in Windows Server 2003 verbessert.
Bedingung 6: Trey Research stimmte zu, dass die offensichtliche Vorgehensweise darin besteht, eine einfache Massenlöschung aller Distributed Link Tracking-Objekte aus dem CN=FileLinks,CN=System,DC= -Domänennamencontainer auf einem Domänencontroller in jeder Domäne in der Gesamtstruktur durchzuführen. Sie erkannten jedoch, dass in diesem Schritt kein zusätzlicher Speicherplatz freigegeben würde, bis die Objekte tombstoned und garbage collection wurden und bis sie eine Offline-Defragmentierungsprozedur auf jedem Domänencontroller in dieser Domäne abgeschlossen haben. Während der Tombstone-Lebensdauerwert auf Werte von nur zwei Tagen festgelegt werden kann, waren mehrere Domänencontroller in der Trey Research-Gesamtstruktur offline, während sie auf Hardware- und Softwareupdates warteten. Wenn Objekte vor der End-to-End-Replikation tombstoned werden, können gelöschte Objekte reanimiert werden oder inkonsistente Daten können von globalen Katalogservern in der Gesamtstruktur gemeldet werden. Um sofort Abhilfe zu schaffen, führte Trey Research das folgende Verfahren aus:
- Sie haben den Standardsicherheitsdeskriptor für Schemaklassenobjekte der Distributed Link-Nachverfolgung entfernt und durch einen einzelnen Sicherheitsprinzipal (Benutzerkonto) ersetzt.
- Sie haben ein VBScript-Programm geschrieben, das alle vorhandenen Sicherheitsbeschreibungen entfernt und dann durch ein explizites Ace für einen einzelnen Sicherheitsprinzipal ersetzt.
- Sie haben Distributed Link Tracking-Objekte in Schritten von 10.000 Einheiten mit einer Verzögerung von drei Stunden zwischen den einzelnen Objektlöschungen gelöscht.
- Sie haben eine Offline-Defragmentierung auf jedem Domänencontroller in der Domäne ausgeführt, nachdem alle Distributed Link Tracking-Objekte gelöscht wurden. Nachdem Trey Research den Deskriptor entfernt und den Defragmentierungsvorgang ausgeführt hat, hat die Datenbank etwa 1,5 GB Speicherplatz auf allen Domänencontrollern in der Domäne wiederhergestellt. Dieser Speicherplatz reichte aus, um das Adprep-Tool bequem auszuführen und alle Windows 2000-basierten Domänencontroller und globalen Kataloge auf Windows Server 2003 zu aktualisieren.
Nachdem Trey Research ein Upgrade des Betriebssystems auf Windows Server 2003 durchgeführt hatte, wurde mehr Speicherplatz freigegeben, als die Einzel instance speicherfunktion in Windows Server 2003 die Datenbankgröße auf etwa 8 GB reduzierte (Sie müssen eine Offlinedefragmentierung durchführen, um diese Ergebnisse zu erhalten). Nach Ablauf des TSL-Intervalls wurde mehr Speicherplatz wiederhergestellt, Objekte für die Distributed Link-Nachverfolgung wurden garbage collection und eine Offline-Defragmentierung durchgeführt.
Trey Research hat einen neuen Windows 2000-basierten Replikatdomänencontroller in die Domäne hochgestuft und das Computerkonto in einer anderen Organisationseinheit als normalerweise verwendet. In zwei Tagen waren auf dem Windows 2000-basierten Domänencontroller etwa 8.000 Objekte für die Nachverfolgung verteilter Verbindungen vorhanden. Trey Research hat entweder die Nachverfolgung von verteilten Links beendet oder eine Richtlinie zum Beenden des Diensts erstellt und dann die Richtlinie mit Organisationseinheiten verknüpft, die Windows 2000-basierte Domänencontroller hosten. Schließlich hat Trey Research Dltpurge.vbs verwendet, um die verbleibenden Distributed Link Tracking-Objekte zum Löschen zu markieren.
Anatomie der DLT-Objektlöschung
DLT-Objekte selbst enthalten nur wenige Attribute und verwenden nur wenig Platz in Active Directory. Wenn ein Objekt zum Löschen (Tombstoned) markiert ist, werden alle unnötigen Attribute entfernt, mit Ausnahme der Attribute, die zum Nachverfolgen des Objekts erforderlich sind, bis es aus Active Directory gelöscht wird.
Bei den Linknachverfolgungsobjekten bedeutet das Markieren des Objekts zum Löschen nur zwei Attribute, die entfernt werden: dscorepropagationdata und objectcategory. Das Löschen der beiden Attribute führt zu anfänglichen Einsparungen von 34 Bytes. Beim Markieren des Linkverfolgungsobjekts zum Löschen wird das Objekt jedoch auch aktualisiert, indem ein IS_DELETED-Attribut (4 Byte) hinzugefügt wird und das RDN und die Attribute "allgemeiner Name" verwaltet werden, wodurch jedes dieser Attribute um etwa 80 Byte anwächst. Darüber hinaus wächst das Attribut "Replikationsmetadaten" ebenfalls um etwa 50 Byte, um die für dieses Objekt durchgeführten Updates widerzuspiegeln. Wenn Sie also ein Linkverfolgungsobjekt zum Löschen markieren, wächst das Objekt um etwa 200 Bytes. Der NTDS. DIT zeigt keine Verkleinerung der Größe, bis die gelöschten Objekte tombstoned, garbage collection und eine Offline-Defragmentierung durchgeführt wurden.
Hinweis
Wenn der Dienst wie in diesem Artikel empfohlen deaktiviert ist, erfolgt die automatische Bereinigung nicht.
Textversion von Dltpurge.vbs
Gehen Sie wie folgt vor, um dieses Skript zu verwenden:
- Kopieren Sie den gesamten Text zwischen dem <Tag "Hier> kopieren starten" und dem <Tag "Hier kopieren> beenden" in diesem Artikel, und fügen Sie den Text dann in eine ASCII-Text-Editor-Datei (z. B. eine Microsoft Editor-Datei) ein.
- Speichern Sie die Datei als "Dltpurge.vbs". 3 Führen Sie das unter Löschen von Objekten für die Nachverfolgung von verteilten Links beschriebene Verfahren aus.
<Start Copy Here>
'==============================================================================
'==============================================================================
'
' Copyright (C) 2001 by Microsoft Corporation. All rights reserved.
'
' This script deletes all Active Directory objects used by the
' Distributed Link Tracking Server service.
'
' It is assumed that the DLT Server service has been disabled,
' and you wish to recover the DIT space these objects occupy.
'
' Usage: cscript DltPurge.vbs <options>
' Options: -s ServerName
' -d distinguishedname dc=mydomain,dc=mycompany,dc=com
' -b BatchSize BatchDelayMinutes
' -t (optional test mode)
'
' The objects are deleted in batches - BatchSize objects are deleted,
' then there is a BatchDelayMinutes delay before the next batch.
'
'==============================================================================
'==============================================================================
Option Explicit
'
' Globals, also local to main.
'
Dim oProvider
Dim oTarget
Dim sServer
Dim sDomain
Dim bTest
Dim BatchSize
Dim BatchDelayMinutes
'
' Set defaults
'
BatchSize = 1000
BatchDelayMinutes = 15
bTest = False
'==============================================================================
'
' ProcessArgs
'
' Parse the command-line arguments. Results are set in global variables
' (oProvider, oTarget, sServer, sDomain, BatchSize, and BatchDelayMinutes).
'
'==============================================================================
public function ProcessArgs
Dim iCount
Dim oArgs
on error resume next
'
' Get the command-line arguments
'
Set oArgs = WScript.Arguments
if oArgs.Count > 0 then
'
' We have command-line arguments. Loop through them.
'
iCount = 0
ProcessArgs = 0
do while iCount < oArgs.Count
select case oArgs.Item(iCount)
'
' Server name argument
'
case "-s"
if( iCount + 1 >= oArgs.Count ) then
Syntax
ProcessArgs = -1
exit do
end if
sServer = oArgs.Item(iCount+1)
if Len(sServer) > 0 then sServer = sServer & "/"
iCount = iCount + 2
'
' Enable testing option
'
case "-t"
iCount = iCount + 1
bTest = True
'
' Domain name option
'
case "-d"
if( iCount + 1 >= oArgs.Count ) then
Syntax
ProcessArgs = -1
Exit Do
end if
sDomain = oArgs.Item(iCount+1)
iCount = iCount + 2
'
' Batching option (batch size, batch delay)
'
case "-b"
if( iCount + 2 >= oArgs.Count ) then
Syntax
ProcessArgs = -1
exit do
end if
Err.Clear
BatchSize = CInt( oArgs.Item(iCount+1) )
BatchDelayMinutes = CInt( oArgs.Item(iCount+2) )
if( Err.Number <> 0 ) then
wscript.echo "Invalid value for -b argument" & vbCrLf
Syntax
ProcessArgs = -1
exit do
end if
iCount = iCount + 3
'
' Help option
'
case "-?"
Syntax
ProcessArgs = -1
exit do
'
' Invalid argument
'
case else
' Display the syntax and return an error
wscript.echo "Unknown argument: " & oArgs.Item(iCount) & vbCrLf
Syntax
ProcessArgs = -1
Exit Do
end select
loop
else
'
' There were no command-line arguments, display the syntax
' and return an error.
'
Syntax
ProcessArgs = -1
end if
Set oArgs = Nothing
end function ' ProcessArgs
'==============================================================================
'
' Syntax
'
' Show the command-line syntax
'
'==============================================================================
public function Syntax
wscript.echo vbCrLf & _
"Purpose: Delete Active Directory objects from Distributed Link Tracking" & vbCrLf & _
" Server service (Assumes that DLT Server has been disabled" & vbCrLf & _
" on all DCs)" & vbCrLf & _
vbCrLf & _
"Usage: " & wscript.scriptname & " <arguments>" & vbCrLf & _
vbCrLf & _
"Arguments: -s Server" & vbCrLf & _
" -d FullyQualifiedDomain" & vbCrLf & _
" -b BatchSize BatchDelayMinutes (default to 1000 and 15)" & vbCrLf & _
" -t (optional test mode, nothing is deleted)" & vbCrLf & _
vbCrLf & _
"Note: Objects are deleted in batches, with a delay between each" & vbCrLf & _
" batch. The size of the batch defaults to 1000 objects, and" & vbCrLf & _
" the length of the delay defaults to 15 minutes. But these" & vbCrLf & _
" values can be overridden using the -b option." & vbCrLf & _
vbCrLf & _
"Example: " & wscript.scriptname & " -s myserver -d distinguishedname dc=mydomain,dc=mycompany,dc=com "
end function ' Syntax
'==============================================================================
'
' PurgeContainer
'
' Delete all objects of the specified class in the specified container.
' This subroutine is called once for the volume table and once for
' the object move table.
'
'==============================================================================
sub PurgeContainer(ByRef oParent, ByVal strClass)
dim oChild
dim iBatch
dim iTotal
On Error Resume Next
iTotal = 0
iBatch = 0
' Loop through the children of this container
For Each oChild in oParent
'
' Is this a DLT object?
'
if oChild.Class = strClass Then
'
' Yes, this is a DLT object, it may be deleted
'
iTotal = iTotal + 1
iBatch = iBatch + 1
'
' Delete the object
'
if bTest then
wscript.echo "Object that would be deleted: " & oChild.adspath
else
oParent.Delete oChild.Class, oChild.Name
end if
'
' If this is the end of a batch, delay to let replication
' catch up.
'
if iBatch = BatchSize then
iBatch = 0
wscript.stdout.writeline "" ' ignored by wscript
wscript.echo "Deleted " & BatchSize & " objects"
wscript.echo "Pausing to allow processing (will restart at " & DateAdd("n", BatchDelayMinutes, Time) & ")"
wscript.sleep BatchDelayMinutes * 60 * 1000
wscript.echo "Continuing ..."
end if
else
' oChild.Class didn't match strClass
wscript.echo "Ignoring unexpected class: " & oChild.Class
end if
oChild = NULL
Next
wscript.echo "Deleted a total of " & iTotal & " objects"
end sub ' PurgeContainer
'==============================================================================
'
' Main
'
'==============================================================================
if (ProcessArgs=-1) then wscript.quit
on error resume next
'
' Explain what's about to happen
'
wscript.stdout.writeline "" ' ignored by wscript
wscript.echo "This script will purge all objects from the Active Directory" & vbCrLf & _
"used by the Distributed Link Tracking Server service (trksvr)." & vbCrLf & _
"It is assumed that this service has already been disabled on" & vbCrLf & _
"all DCs in the domain."
'
' When running in cscript, pause to give an opportunity to break out
' (These 3 lines are for cscript and ignored by wscript.)
'
wscript.stdout.writeline ""
wscript.stdout.writeline "Press Enter to continue ..."
wscript.stdin.readline
'
' Get an ADSI object
'
Set oProvider = GetObject("LDAP:")
'
' Purge the System/FileLinks/ObjectMoveTable
'
wscript.stdout.writeline "" ' ignored by wscript
wscript.echo "Purging ObjectMoveTable"
Set oTarget = oProvider.OpenDSObject( "LDAP://" & sServer & "cn=ObjectMoveTable,CN=FileLinks,CN=System," & sDomain ,_
vbNullString, vbNullString, _
1) ' ADS_SECURE_AUTHENTICATION
call PurgeContainer( oTarget, "linkTrackOMTEntry" )
oTarget = NULL
'
' Purge the System/FileLinks/VolumeTable
'
wscript.stdout.writeline "" ' ignored by wscript
wscript.echo "Purging VolumeTable"
Set oTarget = oProvider.OpenDSObject("LDAP://" & sServer & "cn=VolumeTable,CN=FileLinks,CN=System," & sDomain ,_
vbNullString, vbNullString, _
1) ' ADS_SECURE_AUTHENTICATION
call PurgeContainer( oTarget, "linkTrackVolEntry" )
oTarget = NULL
oProvider = NULL
<END Copy Here>
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für