Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Sunday, May 30, 2010
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!
 
 Sunday, May 30, 2010

Mit Windows Server 2008 führte Microsoft eine neue Funktion ein mit der es möglich ist, eine Momentaufnahme (im englischen Snapshot genannt) des Active Directory (AD) im laufenden Betrieb auf einem DC zu erstellen und das sogar ohne den Betrieb zu beeinflussen. Ein AD-Snapshot kann dann zu Analyse- und Vergleichszwecken bereitgestellt werden. Aber auch zum Begutachten eines früheren Datenbestands eignet sich diese Technik hervorragend. Des Weiteren hat der Administrator mit dieser Funktion die Möglichkeit, ohne den DC im Modus Verzeichnisdienste wiederherstellen starten zu müssen, Daten aus dem AD-Snapshot zu exportieren und in der produktiven Umgebung zu importieren. Dabei ist lediglich ein Lese- und kein Schreibzugriff auf ein AD-Snapshot möglich! Mit dieser Technik die auf dem Volumenschattenkopiedienst (VSS) beruht, kann man in wenigen Augenblicken auf einfache Weise, punktgenaue AD-Snapshots der lokalen Kopie der AD-Datenbank (NTDS.dit) erstellen. Genau genommen wird ein Snapshot des gesamten Volumes erstellt, auf der sich die AD-Datenbank samt -Protokolle und dem SYSVOL-Verzeichnis befindet. Dabei können AD-Snapshots manuell oder automatisiert auf DCs, die mindestens unter Windows Server 2008 laufen erstellt werden. Der Domänenfunktionsmodus hat keine Relevanz.

Es gilt zu beachten, dass ein AD-Snapshot keine vollständige Kopie der AD-Datenbank enthält! Vielmehr stellt ein AD-Snapshot eine Sammlung von Datenträgerblöcken in der AD-Datenbank dar, die seit dem letzten AD-Snapshot geändert wurden. Durch zusammenfügen der Blöcke mit der lokalen Kopie der AD-Datenbank, kann der Volumenschattenkopiedienst die lokale Verzeichnisdatenbank zum Zeitpunkt der Erstellung des Snapshots darstellen.

Ein AD-Snapshot wird mit dem Kommandozeilentool NTDSUTIL erstellt. Man könnte zwar auch ein Snapshot im Betriebssystem erstellen, doch nur wenn das AD-Snapshot mit NTDSUTIL erstellt wird ist sichergestellt, dass die AD-Datenbank konsistent ist!

AD-Snapshots die mit Windows Server 2008 R2 fortgeführt werden helfen dem Administrator zu bestimmen, welche AD-Sicherung die gewünschten wiederherzustellenden Daten enthält. Auch wenn man lediglich überprüfen möchte, welche Werte ein Objekt bzw. ein Attribut vor einer Änderung hatte, eignet sich dieses Verfahren. In den AD Versionen vor Windows Server 2008 muss der Administrator mehrere Sicherungssätze rücksichern um zu bestimmen, welche Sicherung die wiederherzustellenden Daten enthält. Dazu ist es zwingend notwendig, dass der DC im Modus Verzeichnisdienst-wiederherstellen neu gestartet wird. Der Nachteil an den vorherigen AD-Versionen ist auch, dass es keine Möglichkeit gibt die AD-Daten die zu verschiedenen Zeitpunkten erstellt wurden zu vergleichen.

Aber: Ein AD-Snapshot ist nicht zur alleinigen Datensicherung geeignet! Er ist nur als Ergänzung gedacht! Denn aus einem AD-Snapshot können Daten bzw. Objekte nur sehr eingeschränkt mit Bordmittel (mit CSVDE oder LDIFDE) oder aufwändig mit Skripts exportiert und in die produktive AD-Umgebung importiert werden.

 


Ein AD-Snapshot erstellen

Für das Erstellen eines AD-Snapshots werden Domänen-Admin Rechte benötigt. Auf einem DC wird ein AD-Snapshot in der Kommandozeile mit NTDSUTIL wie folgt erstellt:

C:\>NTDSUTIL
NTDSUTIL: Snapshot
Snapshot: Activate Instance NTDS
Aktive Instanz wurde auf "NTDS" festgelegt.
Snapshot: Create
Snapshot wird erstellt...
Der Snapshotsatz {5b9dae90-de11-43b2-a8bb-e842b44ffb62} wurde erfolgreich generiert.
Snapshot:


Ein AD-Snapshot lässt sich auch mit einem Einzeiler erzeugen. Fügt man den folgenden Befehl z.B. in eine Batchdatei und lässt in einem geplanten Task die Batch ausführen (mit entsprechenden Rechten), kann man so das Erstellen von AD-Snapshots zusätzlich zur regelmäßigen System State-Sicherung automatisieren:

C:\>NTDSUTIL Snapshot "Activate Instance NTDS" Create quit quit

NTDSUTIL: Snapshot

Snapshot: Activate Instance NTDS

Aktive Instanz wurde auf "NTDS" festgelegt.

Snapshot: Create

Snapshot wird erstellt...

Der Snapshotsatz {5057fdd0-a0fb-427d-b71a-c36a4d22f9c3} wurde erfolgreich generiert.

Snapshot: quit

NTDSUTIL: quit

 
C:\>



Wenn ein AD-Snapshot erstellt wurde, wird in der Ereignisanzeige unter der Serverrolle Active Directory-Domänendienste die Ereignis-ID 2001 mit der Beschreibung
NTDS (528) NTDSA: Schattenkopieinstanz 2: Fixierung wurde gestartet. protokolliert.

 


Die erstellten AD-Snapshots anzeigen

Alle verfügbaren AD-Snapshots die gegenwärtig vom VSS auf einem DC verwaltet werden, lassen sich mit NTDSUTIL wie folgt Anzeigen:

C:\>NTDSUTIL

NTDSUTIL: Snapshot

Snapshot: List All

 1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

 2:   C: {41d34055-d61f-41f3-84d7-81b7b4016a8f}

 

 3: 2010/05/02:13:39 {f9675e58-54bb-4a51-be21-60c81c44c286}

 4:   C: {110b7077-5c11-4b93-99e2-31411f6ebd8d}

 

 5: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

 6:   C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

Snapshot:


Die Ausgabe in diesem Beispiel stellt jeden AD-Snapshot in zwei Zeilen dar. Wie in dem oberen Beispiel zu sehen ist, wurden drei AD-Snapshots erstellt. Sind die AD-Protokolle auf einer anderen Partition gespeichert als die AD-Datenbank, wird eine weitere Zeile angezeigt.

 


Ein AD-Snapshot löschen

Auch wenn man genau weiß welchen AD-Snapshot man löschen möchte, muss man sich zuerst mit List All auf der Snapshot Ebene in NTDSUTIL alle verfügbaren AD-Snapshots anzeigen lassen. Lässt man sich die verfügbaren AD-Snapshots vorher nicht anzeigen und versucht mit einem Einzeiler direkt ein AD-Snapshot zu löschen, so kommt es zu dieser Fehlermeldung:

C:\>NTDSUTIL Snapshot "Delete 4"

NTDSUTIL: Snapshot

Snapshot: Delete 4

Ungültiger Snapshotindex 4.
Snapshot:



Erst wenn man sich alle bestehenden AD-Snapshots anzeigen lässt, kann man ein AD-Snapshot wie folgt löschen:

C:\>NTDSUTIL Snapshot "List All"

NTDSUTIL: Snapshot

Snapshot: List All

 1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

 2:   C: {41d34055-d61f-41f3-84d7-81b7b4016a8f}

 

 3: 2010/05/02:13:39 {f9675e58-54bb-4a51-be21-60c81c44c286}

 4:   C: {110b7077-5c11-4b93-99e2-31411f6ebd8d}

 

 5: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

 6:   C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

 

Snapshot: Delete 4

Der Snapshot {110b7077-5c11-4b93-99e2-31411f6ebd8d} wurde gelöscht.
Snapshot:



Zum Löschen eines AD-Snapshots kann man einen der beiden Zeilen (die zusammen ein AD-Snapshot darstellen) angeben. Mit
Delete 3 kann man ebenfalls dasselbe AD-Snapshot löschen. Anstatt der Nummern kann man auch die GUID angeben. Mit Delete f9675e58-54bb-4a51-be21-60c81c44c286 oder Delete 110b7077-5c11-4b93-99e2-31411f6ebd8d löscht man ebenso dasselbe AD-Snapshot.

Alle AD-Snapshots auf einmal kann man in der Snapshot Ebene mit Delete * löschen.

 


Ein AD-Snapshot verbinden

Möchte man auf ein AD-Snapshot zugreifen, muss man diesen im ersten Schritt verbinden. Im zweiten Schritt muss dann das verbundene AD-Snapshot mit dem Datenbankbereitstellungstool DSAMAIN bereitgestellt werden. Um ein AD-Snapshot zu verbinden, gilt es entweder die Nummer oder die GUID bei Mount anzugeben. Doch zuerst müssen auch an dieser Stelle mit List All alle verfügbaren AD-Snapshots aufgerufen werden. Erst danach lässt sich ein AD-Snapshot folgendermaßen verbinden:

C:\>NTDSUTIL Snapshot „List All“

NTDSUTIL: Snapshot

Snapshot: List All

 1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

 2:   C: {41d34055-d61f-41f3-84d7-81b7b4016a8f}

 

 3: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

 4:   C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

 

Snapshot: Mount 1

Der Snapshot {41d34055-d61f-41f3-84d7-81b7b4016a8f} wird als C:\$SNAP_201005011523_VOLUMEC$\ bereitgestellt.
Snapshot:



Nach dem das AD-Snapshot verbunden ist, wird dadurch auf dem
%Systemdrive% Laufwerk, beginnend mit der Bezeichnung $SNAP<Erstellungsdatum und Uhrzeit> der AD-Snapshot im Dateisystem eingeblendet. Es ist auch möglich, mehrere AD-Snapshots gleichzeitig zu verbinden. Hat man also mit Mount 1 das erste AD-Snapshot verbunden, kann man anschließend mit Mount 3 das nächste AD-Snapshot zeitgleich verbinden, ohne vorher das erste AD-Snapshot zu trennen. Aus Lastgründen ist es jedoch sinnvoll, nicht mehr als zwei AD-Snapshots gleichzeitig zu verbinden bzw. bereitzustellen!

Es ist auch möglich, die AD-Datenbank aus einer System State-Sicherung zu verbinden und anschließend bereitzustellen. Dazu muss die AD-Datenbank an einen alternativen Ort wiederhergestellt werden.

 


Die verbundenen AD-Snapshots anzeigen

Auf der Snapshot Ebene kann man mit List Mounted alle verbundenen AD-Snapshots auflisten:

C:\>NTDSUTIL Snapshot "List Mounted"

NTDSUTIL: Snapshot

Snapshot: List Mounted

 1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

 2:   C: {41d34055-d61f-41f3-84d7-81b7b4016a8f} C:\$SNAP_201005011523_VOLUMEC$\

 

 3: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

 4:   C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

C:\$SNAP_201005032121_VOLUMEC$\

 
Snapshot:



Wie in diesem Beispiel zu sehen ist, sind zwei AD-Snapshots verbunden.

 


Ein verbundenes AD-Snapshot trennen

Um ein AD-Snaphot zu trennen, muss man auch an dieser Stelle zuerst alle verbundenen AD-Snapshots mit List Mounted anzeigen lassen, ehe man ein oder alle verbundenen AD-Snapshots trennen kann.

C:\>NTDSUTIL Snapshot "List Mounted"

NTDSUTIL: Snapshot

Snapshot: List Mounted

 1: 2010/05/08:14:35 {95c31025-b317-4df6-a7a5-767d0ddbc771}

 2:   C: {65971d9e-5608-46a9-ab92-043d73b4a6af} C:\$SNAP_201005081435_VOLUMEC$\

 

 3: 2010/05/08:17:11 {fef7ad30-a129-466c-9a37-09f2f4e50d84}

 4:   C: {8fcee771-b002-46aa-a878-7e2d9519eaf3} C:\$SNAP_201005081711_VOLUMEC$\

 

Snapshot: Unmount 1

Die Bereitstellung des Snapshots {65971d9e-5608-46a9-ab92-043d73b4a6af} wurde au

fgehoben.

Snapshot:


Sind mehrere AD-Snapshots verbunden, kann man alle auf einmal in der Snapshot Ebene mit Unmount * gleichzeitig trennen.

 


Ein AD-Snapshot mit dem Datenbankbereitstellungstool DSAMAIN bereitstellen

Damit man auf ein AD-Snapshot mit dem man sich bereits verbunden hat zugreifen kann, muss dieser parallel zur lokalen Kopie der AD-Datenbank auf dem DC als zusätzlicher Verzeichnisdienst geladen werden. Deshalb sollte man in einer separaten Eingabeaufforderung mit dem Datenbankbereitstellungstool DSAMAIN, das verbundene AD-Snapshot das mithilfe von NTDSUTIL erstellt wurde bereitstellen. Anschließend kann man dann mit einem LDAP-Tool wie z.B. Active Directory-Benutzer und -Computer, ADSIEdit oder LDP den AD-Snapshot wie jeden anderen aktiven DC durchsuchen oder mit CSVDE bzw. LDIFDE Inhalte exportieren.

Damit das AD-Snapshot bereitgestellt werden kann, muss dieser Befehl in der Kommandozeile eingegeben werden: DSAMain -DBPath <Pfad zur NTDS.dit> -LDAPPORT <ausgewählter LDAP-Port>. Bei dem Parameter -DBPath muss der Pfad zur AD-Datenbank das sich im verbundenen AD-Snapshot befindet angegeben werden. Bei -LDAPPort muss mindestens ein Port spezifiziert werden, über den die parallele AD-Instanz zur Verfügung gestellt wird. Standardmäßig benötigt das AD vier LDAP-Ports, nämlich 389 für LDAP, 636 für LDAP über SSL/TLS, 3268 für den globalen Katalog (GC) und 3269 für den GC über SSL. Da standardmäßig diese vier Ports von dem eigentlichen produktiven AD auf einem DC benutzt werden, ist es zwingend notwendig für das Bereitstellen des AD-Snapshots einen anderen, eigens ausgewählten verfügbaren Port zu wählen. Gibt man lediglich für den erforderlichen LDAPPort den Port 30000 an, wird automatisch für LDAPS der Port 30001, für den GC 30002 und für den GC über SSL der Port 30003 reserviert.


 


Der Befehl zum Bereitstellen eines AD-Snapshots muss mindestens so aussehen:

DSAMain -DBPath C:\$SNAP_201005091521_VOLUMEC$\Windows\NTDS\NTDS.dit -LDAPPort 30000


Möchte man alle benötigten LDAP-Ports selbst spezifizieren, so lautet der Befehl wie folgt:

DSAMain -DBPath C:\$SNAP_201005091521_VOLUMEC$\Windows\NTDS\NTDS.dit -LDAPPort 30000 -sslPort 30100 -gcPort 30200 -gcSslPort 30300



Wenn ein AD-Snapshot bereitgestellt wurde, wird in der Ereignisanzeige unter der Serverrolle Active Directory-Domänendienste die Ereignis-ID 102 mit der Beschreibung NTDS (2924) NTDSA: Das Datenbankmodul (6.01.7600.0000) hat eine neue Instanz gestartet (0).protokolliert. Wird die Bereitstellung aufgehoben, so wird die Ereignis-ID 103 verzeichnet.

Nach durchgeführter Arbeit, kann die Bereitstellung der zusätzlichen AD-Instanz mit CTRL+C beendet werden und man sollte noch mit Unmount * das bzw. die verbundenen AD-Snapshots trennen.

 


Auf den AD-Snapshot zugreifen

  • Wenn der AD-Snapshot bereitgestellt ist, kann man ihn mit der MMC dsa.msc betrachten, in dem man zuerst auf den Eintrag Active Directory-Benutzer und -Computer [FQDN des DCs] mit einem Rechtsklick die Option Domänencontroller ändern… aufruft. Danach wählt man die Option Bestimmter Domänencontroller oder AD LDS-Instanz aus und trägt den Computernamen, FQDN oder die IP-Adresse des DCs ein, auf dem der AD-Snapshot bereitgestellt wurde. Dabei ist zu beachten: Egal welches Tool verwendet wird, es ist zwingend notwendig das man den für die zusätzliche AD-Instanz vergebenen LDAP-Port stets mit angibt!





    Die MMC dsa.msc eignet sich ideal um den AD-Datenbestand zum Erstellungszeitpunkt des AD-Snapshots zu durchforsten, aber nicht um Inhalte zu exportieren um diese dann in die produktive Umgebung zu importieren.


  • Einen Export kann man mit Bordmittel ebenfalls durchführen, nämlich mit CSVDE und LDIFDE. Natürlich lassen sich auch durch eigene Skripte Daten exportieren. Ein Export aller Benutzer mit lediglich den gewünschten Attributen aus einer bestimmten OU, könnte mit CSVDE wie folgt aussehen:

    CSVDE -S <DC> -T <vergebener LDAP-Port> -D „OU=<OU>,DC=Domäne,DC=de“ -R „(sAMAccountType=805306368)“ -L “<gewünschteAttribute>” -P Subtree -M -N -U -F „C:\ADFoto.csv“


    Nach dem Export kann man die CSV-Datei zur weiteren Bearbeitung in Excel importieren. Hat man die Bearbeitung der Datendatei fertiggestellt, kann man dann mit dem folgenden Befehl den Import in der produktiven AD-Umgebung durchführen:

    CSVDE -I –K -F „C:\Datendatei.csv“


    Beim Import in der produktiven AD-Umgebung mit CSVDE gilt es jedoch zu beachten, dass man dieses Kommandozeilentool nicht für die Bearbeitung bestehender Objekte einsetzen kann! Zum Bearbeiten bestehender Objekte bietet sich das Kommandozeilentool LDIFDE an, dass ähnlich wie CSVDE funktioniert. Mit LDIFDE könnte man einen Export aus dem AD-Snapshot folgendermaßen gestalten:

    LDIFDE -S <DC> -T <vergebener LDAP-Port> -D „OU=<OU>,DC=Domäne,DC=de“ -R „(sAMAccountType=805306368)“ -L “<gewünschteAttribute>” -P Subtree -M -N -F „C:\Export.ldf“


    Auch mit diesem Befehl werden alle Benutzer aus der angegebenen OU, mit den gewünschten Attributen aus der Momentaufnahme exportiert. Hat man die gewünschten Informationen aus dem AD-Snapshot exportiert, kann man diese wie folgt in die produktive Umgebung importieren:

    LDIFDE -I -K -Z -F „C:\Import.ldf“


    LDIFDE - LDAP Data Interchange Format Data Exchange


  • Auch mit den ds*-Tools kann man auf den AD-Snapshot zugreifen. Dabei muss man lediglich den Parameter -S mit dem Wert <FQDN des DCs>:<vergebener LDAP-Port> zusätzlich zur Abfrage angeben. Eine Abfrage die alle Benutzer einer bestimmten OU anzeigt, sieht so aus:

    Dsquery * "OU=<OU>,DC=Domäne,DC=de" -Filter "(sAMAccountType=805306368)" -Attr * -Server <FQDN des DCs>:30000 -Limit 0


  • Natürlich kann man auch mit dem State of the Art Werkzeug, nämlich der AD-PowerShell auf die Momentaufnahme zugreifen und Daten daraus exportieren. Doch bevor man mit der AD-PowerShell auf die Momentaufnahme zugreifen kann, muss wie gehabt zuerst in NTDSUTIL das AD-Snapshot verbunden und mit DSAMain bereitgestellt werden. Ist der AD-Snapshot bereitgestellt, muss man in der AD-PowerShell als nächstes ein AD-PowerShell-Laufwerk erstellen. Mit dem folgenden AD-PowerShellbefehl wird ein Laufwerk, basierend auf dem AD-Snapshot erstellt:

    New-PSDrive -Name <frei wählbarer Laufwerksname> -PSProvider ActiveDirectory -Root "" -Server <DC.Domäne.de>:<vergebener LDAP-Port>


    Hat man das AD-PowerShell-Laufwerk erstellt, muss man mit cd <vergebener Laufwerksname>: auf das Laufwerk wechseln.






    Anschließend kann man mit
    cd "<DN der Domänenpartition>" zur Domänenpartition, also auf die Verzeichnispartition in der die Benutzer-, Gruppen- und Computerkonten enthalten sind wechseln.





    Nun kann man sich mit den entsprechenden AD-PowerShellabfragen die gewünschten Informationen ausgeben lassen oder im Zusammenhang mit dem Cmdlet Export-CSV, einen Export der gewünschten Daten in eine CSV-Datei durchführen. Z.B. kann man alle Benutzer aus einer OU mit allen Eigenschaften wie folgt exportieren:

    Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * | Export-Csv C:\Export.txt -NoTypeInformation


    Man muss aber nicht zwangsläufig zuerst ein neues AD-PowerShell-Laufwerk erstellen! Stattdessen kann man auch, nach dem der AD-Snapshot mit DSAMain bereitgestellt wurde, alle Benutzer aus einer OU mit allen Eigenschaften wie folgt exportieren:

    Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * -Server <FQDN des DCs>:<vergebener LDAP-Port> | Export-Csv C:\Export.txt -NoTypeInformation



    Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen

    AD-PowerShell Befehle

 


Nützliche Werkzeuge


Der ADExplorer

Ein hilfreiches Werkzeug im Zusammenhang mit AD-Snapshots stellt der ADExplorer dar. Mit diesem Tool ist es unter anderem zum einen möglich, AD-Snapshots auf Knopfdruck zu erstellen und zum anderen, zwei AD-Snapshots miteinander zu vergleichen. Dabei kann jedoch ein AD-Snapshot weder mit der aktuellen AD-Datenbank, noch mit mehreren AD-Snapshots gleichzeitig verglichen werden! Was das Erstellen und verwalten eines AD-Snapshots mit dem ADExplorer betrifft, gestaltet sich das mit dem Tool bemerkenswert einfacher als mit NTDSUTIL!

Zum Erstellen eines AD-Snapshots startet man den ADExplorer und trägt im Feld Connect to den DC ein mit dem eine Verbindung hergestellt werden soll. In den Feldern User und Password gibt man die entsprechenden Benutzerdaten ein. Führt man stattdessen den ADExplorer direkt auf einem DC aus, muss keins der Felder ausgefüllt werden. Dann verbindet sich der ADExplorer automatisch mit dem DC auf dem es ausgeführt wird und verwendet die Benutzerinformationen, mit dem das Tool gestartet wurde. Nach dem sich der ADExplorer mit dem DC, genauer mit der AD-Datenbank verbunden hat, klickt man entweder in der Symbolleiste auf das Diskettensymbol oder im Menü unter File auf Create Snapshot… um eine Momentaufnahme der AD-Datenbank zu erstellen. Im Feld Specify the path to the snapshot file muss der Pfad inklusive des Dateinamen angegeben werden, in dem das AD-Snapshot erstellt werden soll. Bei dem Dateinamen ist zwingend darauf zu achten, dass die Dateiendung DAT lautet. Zusätzlich kann im Feld Enter an optional description for the snapshot eine Beschreibung angegeben werden, was aber nicht zwingend ist.



Die DAT-Datei die erstellt wurde kann nun auf ein anderes System, das keine Verbindung zur produktiven Umgebung hat transportiert und von dort aus mit dem ADExplorer analysiert werden. Das ist auf der einen Seite zwar ein wesentlicher Vorteil gegenüber NTDSUTIL, hat aber auch auf der anderen Seite einen gravierenden Nachteil! Das AD-Snapshot das mit NTDSUTIL erstellt wurde benötigt die Verbindung zur produktiven Umgebung, um die Momentaufnahme rekonstruieren zu können. Somit kann das AD-Snapshot nicht einfach kopiert und irgendwohin transportiert werden. Das AD-Snapshot das mit dem ADExplorer erstellt wurde benötigt hingegen keine Verbindung zur produktiven Umgebung und befindet sich in genau einer DAT-Datei. Das stellt natürlich ein hohes Sicherheitsrisiko dar! Deshalb ist bei den AD-Snapshots die mit dem ADExplorer erstellt wurden die gleiche Sicherheit zu gewähren, wie der physikalische Zugriff auf DCs oder den Datensicherungen!

Um auf ein AD-Snapshot (die DAT-Datei) zuzugreifen, startet man den ADExplorer, wählt die Option Enter the path of a previous snapshot to load aus und trägt den Pfad zur DAT-Datei ein oder navigiert dorthin. Ist man mit dem ADExplorer bereits mit dem produktiven AD verbunden, kann man sich zusätzlich mit ein oder mehreren AD-Snapshots (nacheinander) unter File - Connect… verbinden. Das eignet sich ideal für das schnelle überprüfen von vorherigen Datenbeständen. Hat man z.B. bei ein oder mehreren Objekten in der produktiven Umgebung Werte versehentlich verändert, kann man mit dem ADExplorer nachschauen welche Werte vorher eingetragen waren, in dem man sich mit dem produktiven AD und einem AD-Snapshot verbindet.

Das Löschen eines AD-Snapshots das mit dem ADExplorer erstellt wurde gestaltet sich ebenfalls einfacher als mit der NTDSUTIL-Variante. Es muss lediglich die DAT-Datei vom Dateisystem gelöscht werden.


Möchte man zwei AD-Snapshots miteinander vergleichen, startet man den ADExplorer mit der Option Enter the path of a previous snapshot to load und gibt das Quell-AD-Snapshot an. Anschließend wählt man im Menü Compare - Compare Snapshot… und gibt im Feld Select an archive to compare to das Ziel-AD-Snapshot an. Sollen nur ausgewählte Klassen und bestimmte Felder bzw. Attribute miteinander verglichen werden, so muss man diese in den beiden unteren Bereichen auswählen.



Mit einem Klick auf Compare werden beide AD-Snapshots verglichen und wenn unterschiede vorhanden sind, werden diese angezeigt.


AD Explorer

 


Das Directory Service Comparison Tool (DSCT)

Ein weiteres nützliches Werkzeug, das mehr Funktionen als der ADExplorer bietet ist das DSCT. Die Beschreibung zu dem Tool sowie den Download findet man auf der folgenden Seite:

Directory Service Comparison Tool 2.0 B3

 


Fazit

Die AD-Snapshots sind eine hervorragende Technik, die die AD-Sicherung sowie -Wiederherstellung ergänzt. Zum Wiederherstellen von AD-Informationen muss der DC nicht erst im Modus Verzeichnisdienste wiederherstellen gestartet werden. Die Wiederherstellung kann im laufenden Betrieb, ohne Beeinträchtigung, mit der AD-Snapshot Funktion erfolgen. Auch für das Vergleichen verschiedener Datenbestände eignet sich diese Technik. Außerdem können aus einem AD-Snapshot gezielt (einzelne) Werte exportiert und in die produktive Umgebung importiert werden. Gerade ab Windows Server 2008 R2 mit dem AD-Papierkorb und der bestehenden AD-Sicherung rundet diese Technik die AD-Wiederherstellung ab! Denn mit dem aktivierten AD-Papierkorb können zwar gelöschte Objekte ohne Datenverlust wiederhergestellt werden, nicht jedoch einzelne Werte. Dazu eignet sich ein AD-Snapshot.

 

 

Weitere Informationen:
Der Active Directory-Papierkorb im Windows Server 2008 R2
Active Directory Wiederherstellung
Der Container Deleted Objects

Sunday, May 30, 2010 9:10:23 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Wiederherstellung  | 
 Sunday, May 16, 2010

Wer für die Administration von Gruppenrichtlinien in einem Windows Netzwerk zuständig ist, der sollte und wird die Gruppenrichtlinien-Verwaltungskonsole (auf Englisch: Group Policy Management Console, kurz GPMC) kennen. Installiert man sich unter Windows XP und Windows Server 2003 die GPMC das separat heruntergeladen werden muss, stehen einem 32 Skripte im Verzeichnis %PROGRAMFILES%\GPMC\Scripts zur Verfügung. Mit diesen GPMC-Skripts kann man viele alltägliche Gruppenrichtlinien-Aufgaben leicht und automatisiert durchführen. Viele Gruppenrichtlinien-Administratoren werden diese Skripte zu schätzen wissen.

Doch mit Vista und Windows Server 2008 stehen die GPMC-Skripte erst mal nicht zur Verfügung. Die GPMC steht zwar ab Vista nach der Installation der Remote Server Administration Tools (RSAT) und unter Windows Server 2008, erst nach Aktivierung der Gruppenrichtlinienverwaltung in den Features weiterhin zur Verfügung, doch die GPMC Skripte fehlen hingegen. Stattdessen stellt Microsoft die GPMC Skripte als separaten Download für Vista und Windows Server 2008 zur Verfügung. Nach der Installation stehen die GPMC Skripte in gewohnter Weise zur Verfügung.

GPMC Sample Scripts


Unter Windows 7 und Windows Server 2008 R2 steht die GPMC ohne die GPMC Skripte in den RSAT auch zur Verfügung. Es gibt jedoch keinen separaten Download der GPMC Skripte für Windows 7 und Windows Server 2008 R2. Aber die GPMC Skripte für Vista und Windows Server 2008 lassen sich auch unter Windows 7 und Windows Server 2008 R2 weiterhin nutzen. Wer allerdings für die Administration der Gruppenrichtlinien zukunftsorientiert sein möchte, der nutzt die PowerShell! Microsoft stellt 25 Cmdlets allein für Gruppenrichtlinien bereit, mit denen weitestgehend die gleichen Administrationsaufgaben durchgeführt werden können wie mit den GPMC Skripts. Die GPO Cmdlets die in der Zukunft erweitert werden, sind die Nachfolger der GPMC Skripts.

Damit die 25 GPO Cmdlets zur Verfügung stehen, müssen diese zuerst mit dem PowerShellbefehl Import-Module GroupPolicy geladen werden. Das Laden der GPO Cmdlets muss sowohl in der AD-PowerShell, als auch in der Windows PowerShell v2 durchgeführt werden. Man kann sich natürlich ein PowerShell-Profil erstellen, damit beim Starten der AD-/PowerShell die GPO Cmdlets beim Öffnen der PowerShell Konsole automatisch geladen werden. Nach dem Import kann man sich die folgenden 25 GPO Cmdlets mit Get-Command *-GP* anzeigen lassen. Startet man dagegen die Konsole Windows PowerShell Modules, wird beim Starten der Konsole unter anderem automatisch das GPO-Modul geladen.

Die 25 GPO Cmdlets sind:

  • Backup-GPO: Mit diesem Cmdlet sichert man das angegebene Gruppenrichtlinienobjekt (GPO) oder alle Gruppenrichtlinienobjekte in einer angegebenen Domäne in ein Sicherungsverzeichnis. Dabei muss das Sicherungsverzeichnis bereits existieren.

  • Copy-GPO: Dieses Cmdlet erstellt eine neue GPO und kopiert die Einstellungen aus der Quell-GPO in die neue GPO. Mit diesem Cmdlet kann eine GPO aus einer Domäne in eine andere Domäne innerhalb der gleichen Gesamtstruktur kopiert werden.

  • Get-GPInheritance: Informationen zur Gruppenrichtlinienvererbung für eine angegebene Domäne oder Organisationseinheit kann man sich mit diesem Cmdlet ausgeben lassen.

  • Get-GPO: Eine bestimmte GPO oder alle GPOs innerhalb einer Domäne kann man sich mit diesem Cmdlet anzeigen lassen.

  • Get-GPOReport: Hiermit wird ein Bericht im XML- oder HTML-Format generiert, in dem die Eigenschaften und Richtlinieneinstellungen für eine angegebene GPO oder für alle GPOs einer Domäne angezeigt werden. Dieses Cmdlet eignet sich ideal zu Dokumentationszwecken. Möchte man alle Richtlinieneinstellungen aller GPOs innerhalb der Domäne in eine HTML Datei exportieren, so gilt es diesen Befehl auszuführen: Get-GPOReport -All -Domain <Domäne.de> -ReportType HTML -Path C:\GPOReport\GPOReport.html. Das Zielverzeichnis muss bereits existieren, sonst erhält man eine Fehlermeldung.

  • Get-GPPermissions: Die Berechtigungen für einen oder mehrere Sicherheitsprinzipale kann man mit diesem Cmdlet in der angegebenen GPO abrufen.

  • Get-GPPrefRegistryValue: Dieses Cmdlet zeigt eine oder mehrere Registrierungseinstellungen die unterhalb der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO getätigt wurden an.

  • Get-GPRegistryValue: Bei diesem Cmdlet werden eine oder mehrere registrierungsbasierte Richtlinieneinstellungen aus der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO abgerufen.

  • Get-GPResultantSetOfPolicy: Mit diesem Cmdlet kann man die Richtlinienergebnissatz-Informationen für einen Benutzer, einen Computer oder für beide in eine Datei im HTML- oder XML-Format ausgeben lassen.

  • Get-GPStarterGPO: Ein bestimmtes oder alle Starter-GPOs werden mit diesem Cmdlet angezeigt.

  • Import-GPO: Dieses Cmdlet importiert die Einstellungen aus einer gesicherten GPO in die angegebene Ziel-GPO. Dabei kann sich das Ziel-GPO in einer anderen Domäne oder in einer anderen Gesamtstruktur befinden als die Sicherungs-GPO und muss vorher nicht existieren.

  • New-GPLink: Eine GPO wird auf eine Organisationseinheit (OU), einen AD-Standort oder auf die Domäne mit diesem Cmdlet verlinkt.

  • New-GPO: Eine neue GPO wird mit diesem Cmdlet erstellt.

  • New-GPStarterGPO: Mit diesem Cmdlet wird eine neue Starter-GPO erstellt.

  • Remove-GPLink: Dieses Cmdlet entfernt eine GPO-Verklinkung von einer OU, einem AD-Standort oder von der Domäne.

  • Remove-GPO: Eine GPO wird mit samt allen Verlinkungen, mit diesem Cmdlet gelöscht.

  • Remove-GPPrefRegistryValue: Eine oder mehrere Registrierungseinstellungen werden aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO mit diesem Cmdlet entfernt.

  • Remove-GPRegistryValue: Um eine oder mehrere Registrierungsbasierte Richtlinieneinstellungen aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO zu entfernen, muss dazu dieses Cmdlet verwendet werden.

  • Rename-GPO: Mit diesem Cmdlet kann man eine GPO umbenennen bzw. der GPO einen anderen Anzeigenamen zuweisen. Dabei bleibt die GUID der umbenannten GPO erhalten.

  • Restore-GPO: Dieses Cmdlet stellt eine GPO-Sicherung in der Domäne wieder her, in der sie ursprünglich gespeichert wurde. Ist die ursprüngliche Domäne oder die GPO nicht mehr in der Domäne vorhanden, tritt ein Fehler auf.

  • Set-GPInheritance: Die Vererbung einer GPO kann mit diesem Cmdlet deaktiviert werden. Oder die Deaktivierung der Vererbung für eine angegebene OU oder Domäne lässt sich ebenfalls mit diesem Cmdlet aufheben.

  • Set-GPLink: Die Eigenschaften einer GPO-Verknüpfung lassen sich mit diesem Cmdlet festlegen.

  • Set-GPPermissions: Die Berechtigungen einer GPO oder für alle GPOs innerhalb einer Domäne lassen sich mit diesem Cmdlet bearbeiten.

  • Set-GPPrefRegistryValue: Dieses Cmdlet konfiguriert eine Registrierungseinstellung unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.

  • Set-GPRegistryValue: Mit diesem Cmdlet konfiguriert man eine oder mehrere registrierungsbasierte Richtlinieneinstellungen unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.


Die Hilfe zu jedem einzelnen Cmdlet lässt sich mit Get-Help <Cmdlet> -Full anzeigen. Also z.B.: Get-Help Get-GPOReports -Full.


Auch an dieser Stelle zeigt sich: Die Zukunft spricht PowerShell! ;-)

 

Weitere Informationen:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
AD-PowerShell Befehle

Sunday, May 16, 2010 11:07:59 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | AD-Powershell | Gruppenrichtlinien  | 
 Sunday, May 09, 2010

Befinden sich alle Benutzer die alle aus einer bestimmten Gruppe entfernt werden sollen in der gleichen OU,
so kann man alle Benutzer in einem Schritt mit dem folgenden AD-PowerShell Befehl aus der Gruppe entfernen:

$Benutzer = Get-ADUser -Filter * -Searchbase "OU=<Benutzer>,DC=Domäne,DC=de"
Remove-ADGroupMember -identity <Gruppe> -Member $Benutzer -Confirm:0

Befinden sich in der OU in der sich die Benutzer befinden auch Benutzer, die nicht Mitglied der entsprechenden Gruppe sind, schlägt der Befehl fehl.


Wenn sich alle Benutzer die Mitglied der Gruppe "Consultants" sind in der OU "IT" befinden, so lautet der Befehl wie folgt:

$Benutzer = Get-ADUser -Filter * -Searchbase "OU=IT,DC=Domäne,DC=de"
Remove-ADGroupMember -identity Consultants -Member $Benutzer -Confirm:0

Dabei spielt es weder eine Rolle um welchen Gruppenbereich es sich dabei handelt (Global, Lokal (in Domäne), Universal),
noch ob es sich um eine Sicherheits- oder Verteilergruppe handelt.

 

Weitere Informationen:
AD-PowerShell Befehle

Sunday, May 09, 2010 4:21:16 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | AD-Powershell  | 
 Sunday, May 02, 2010

Das Active Directory (AD) stets zu pflegen, ist eines der Aufgaben eines AD-Administrators. Mit der Zeit entstehen Leichen was die Computerkonten im AD betrifft. Clients die verschrottet wurden, sind vorher nicht aus der Domäne entfernt worden. Aber auch wenn Clients oder Mitgliedsserver aus der Domäne entfernt und zu einer Arbeitsgruppe (AG) hinzugefügt werden, wird nicht automatisch das Computerkonto im AD gelöscht. Es wird lediglich deaktiviert und bleibt im AD bestehen. Im Nachgang muss dann das Computerkonto manuell entfernt werden.

State oft the Art löscht man die Computerkonten mit der AD-PowerShell. Weitere Möglichkeiten findet man im folgenden Artikel:

Computerkonto löschen


# Alle deaktivierten Computerkonten, also alle Computer (Clients und Mitgliedsserver) die aus der Domäne entfernt und in eine AG hinzugefügt oder manuell deaktiviert wurden, werden mit diesem Befehl angezeigt:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | FT Name -A


Sollen die deaktivierten Computerkonten aus einer bestimmten Organisationseinheit (OU) angezeigt werden, so gilt es diesen Befehl zu verwenden:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object | FT Name -A



# Alle deaktivierten Computerkonten werden auf Nachfrage, nacheinander mit diesem Befehl gelöscht:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object| Remove-ADComputer


Deaktivierte Computerkonten aus einer bestimmten OU werden auf Nachfrage mit diesem Befehl entfernt:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object| Remove-ADComputer


Sollen alle deaktivierten Computerkonten auf einmal ohne Nachfrage gelöscht werden, so muss der Parameter „-Confirm:“ mit dem Wert „$False“ mit angegeben werden. Sprich:
Search-ADAccount –AccountDisabled -ComputersOnly | Remove-ADComputer -Confirm:$False


Ohne Nachfrage werden die deaktivierten Computerkonten aus einer OU wie folgt gelöscht:
Search-ADAccount –AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False



# Alle Computer die sich seit 180 Tagen nicht am AD angemeldet haben werden mit dem folgenden Befehl angezeigt. Damit der Parameter AccountInactive verwendet werden kann, muss sich jedoch der Domänenfunktionsmodus mindestens auf der Ebene “Windows Server 2003” befinden:
Search-ADAccount -AccountInactive –Timespan 180 –ComputersOnly | Sort-Object | FT Name -A


Möchte man sich alle Computer aus einer bestimmten OU anzeigen, die sich seit 180 Tagen nicht mehr am AD angemeldet haben, so sieht der Befehl folgendermaßen aus:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A


Gelöscht werden die Computerkonten dann wie folgt:
Search-ADAccount -AccountInactive –Timespan 180 -ComputersOnly | Remove-ADComputer -Confirm:$False


Aus einer bestimmten OU werden die Computerkonten so entfernt:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False



# Alle Computer die seit dem 01.01.2010 inaktiv sind und sich nicht mehr am AD angemeldet haben, werden wie folgt angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Sort-Object | FT Name -A


Alle Computer aus einer bestimmten OU, die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, werden so angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A


Alle Computerkonten die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, lassen sich dann mit diesem Befehl löschen:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Remove-ADComputer -Confirm:$False


Die Computer einer bestimmten OU, die seit dem 01.01.2010 inaktiv sind, werden wie folgt gelöscht:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Remove-ADComputer -Confirm:$False



Weitere Informationen:
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
AD-PowerShell Befehle

Sunday, May 02, 2010 2:29:23 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | AD-Powershell | Erweiterte Abfragen  | 
 Sunday, April 18, 2010

Zwei wichtige IDs eines Domänencontrollers (DC) sind der DC GUID (Globaly Unique Identifier) und der Datenbank GUID. Beide IDs sind wichtige Bestandteile bei der AD-Replikation. Mit dem Kommandozeilenbefehl Repadmin /Showrepl <DC> kann man sich beide IDs anzeigen lassen. Gibt man den <DC> nicht an, wird der Befehl gegen den DC ausgeführt, auf dem man den Repadmin Befehl ausführt. Führt man den Befehl auf einem Windows Server 2003 DC aus, so erhält man diese Ausgabe auf dem ersten DC einer Gesamtstruktur:

 

Auf einem Windows Server 2008 R2 DC sieht das Ergebnis auf dem ersten DC wie folgt aus:


Jeder DC besitzt eine eindeutige DC GUID innerhalb einer Gesamtstruktur, der auch als Directory Service Agent GUID (kurz DSA-GUID) bekannt ist. Mit der DC GUID der im Attribut objectGUID gespeichert ist, wird der DC in der Gesamtstruktur identifiziert. Dabei spielt es auch keine Rolle in welcher Domäne sich der DC innerhalb einer Gesamtstruktur befindet. Der DC GUID eines DCs ist in der Gesamtstruktur einmalig und ändert sich solange der DC existiert (im Gegensatz zu der invocationId) niemals! Es sei denn, der DC wird zuerst herunter- und anschließend wieder zum DC heraufgestuft. Denn der DC GUID eines DCs wird beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Natürlich ist das manuelle bearbeiten des DC GUIDs ebenso nicht möglich, weil das Attribut objectGUID system-only ist. Das Attribut objectGUID findet man in den Eigenschaften des „NTDS Settings“ Objekts unterhalb des entsprechenden DC-Objekts in der Konfigurationspartition und ist als ein Oktett-String gespeichert. Der LDAP-Pfad zum “NTDS Settings” Objekt lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.

Die objectGUID wird unter anderem auch dazu verwendet, um die Reihenfolge der DCs einer ringförmigen Replikationstopologie zu bestimmen und ist außerdem bei der Wahl des Bridgeheadservers eines AD-Standorts von Bedeutung. Damit der DC für seine Replikationspartner erreichbar ist, erstellt dieser mit der objectGUID in der Forward Lookup Zone _msdcs.Root-Domäne im DNS einen CNAME Eintrag.

Beim heraufstufen eines Servers zu einem DC wird der AD-Datenbank (NTDS.dit) ebenfalls eine GUID zugeordnet, die als Datenbank GUID bezeichnet wird. Diese GUID wird dazu verwendet, um die AD-Datenbank eines DCs bei einem Replikationsaufruf zu identifizieren. Bei der Datenbank GUID handelt es sich um das Attribut invocationId und befindet sich so wie die objectGUID ebenfalls in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs im LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Auch die invocationId wird wie die objectGUID beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Replikationspartner nutzen die invocationId und die Update Sequence Number (USN) um die aktuellen Änderungen für die AD-Replikation zu bestimmen.

Die invocationId des ersten DCs mit dem die Gesamtstruktur erstellt wurde, hat den gleichen Wert wie die objectGUID. Bei allen weiteren DCs einer Gesamtstruktur werden unterschiedliche Werte in den beiden Attributen objectGUID und invocationId gespeichert.

Im Gegensatz zur objectGUID ändert sich die invocationId wenn:

  • eine neue Anwendungsverzeichnispartition erstellt wird. Oder wenn eine bestehende Anwendungsverzeichnispartition entfernt und erneut erstellt wird.

  • der DC mit einer gültigen Sicherung und einer unterstützten Rücksicherungsmethode (supportet von Microsoft!) rückgesichert wird. Eine gültige Sicherung ist eine Sicherung die mit einer Sicherungssoftware durchgeführt wurde, dass das entsprechende API des Betriebssystems verwendet und somit das AD in Kenntnis setzt, dass eine Sicherung durchgeführt wurde. Nur wenn eine gültige und somit eine supportete Sicherung mindestens vom System State durchgeführt wird, erspart man sich je nach Umgebung größeren Schaden im Fall einer Rücksicherung! Ab Windows Server 2003 SP1 kann man mit dem Kommandozeilenbefehl Repadmin /Showbackup überprüfen, ob eine Verzeichnispartition jemals supportet gesichert wurde.

    Eine unterstützte Rücksicherung findet in Abstimmung mit der AD-Replikation statt. Denn nur wenn das AD durch eine ordnungsgemäß durchgeführte System State Sicherung und einer supporteten Rücksicherungsmethode rückgesichert wird, erhält die invocationId auf dem rückgesicherten DC einen neuen Wert. Dadurch erkennen alle anderen DCs, dass die Metadaten für die AD-Replikation zu dem rückgesicherten DC hinfällig sind und das die AD-Replikation ab dem durchgeführten Sicherungsdatum mit dem der DC rückgesichert wurde, neu aufgebaut und durchgeführt werden muss. Einige Sicherungsprogramme (bis Windows Server 2003 NTBACKUP und ab Windows Server 2008 Wbadmin, ARCServe…) führen eine ordnungsgemäße Sicherung und Rücksicherung des System States durch und darauf kommt es an!

    Das entscheidende bei der Rücksicherung ist nun mal, dass die invocationId einen neuen Wert erhalten muss! Das ist genau der Nachteil bei Image-Programmen. Beim klassischen Imagen zieht man sich eine eins zu eins Kopie des DCs. Sollte es nun zum Rückspielen des Images kommen, erhält die invocationId keinen neuen Wert und somit erfahren je nach Umgebung die Replikationspartner auch nicht, dass ein DC rückgesichert wurde und das die Replikation mit dem rückgesicherten DC neu aufgebaut werden muss. Beim rücksichern eines Images schafft man sich ein USN Rollback, was je nach Fall zu einem größeren Schaden für die AD-Umgebung bedeutet! Im günstigsten Fall hätte man sich lediglich den zurück-geimageten DC zerstört. Diesen müsste man dann gewaltsam herunterstufen und anschließend die Metadaten des AD bereinigen (siehe weiterführende Informationen). Im ungünstigsten Fall hätte man mindestens doppelte RIDs verteilt, nicht mehr gültige Computerkontokennwörter und keine funktionierende AD-Replikation mit diesem DC mehr!

    Wenn eine unterstützte Rücksicherung stattgefunden hat, wird der nicht mehr gültige Wert aus dem Attribut invocationId in das Attribut retiredReplDSASignatures (das sich ebenfalls im NTDS Settings Objekt eines DCs befindet) gesetzt.

    Auch eine IFM (Install from Media) Installation eines DCs kommt einer Rücksicherung eines DCs gleich. Denn bei einer IFM-Installation wird der Wert aus dem Attribut invocationId das von der Sicherung stammt, in das Attribut retiredReplDSASignatures auf dem neuen DC geschrieben. Der Grund dafür ist, wenn ein Verbindungsobjekt für die Replikation erstellt wird, überprüft der neue DC sein Attribut retiredReplDSASignatures um festzustellen ob das Attribut einen Wert enthält, der mit den invocationIds im Up-To-Dateness Vector (UTDV) des Ziel-DCs übereinstimmt. Durch diese Vorgehensweise ist sichergestellt, dass nur eine Teilmenge der AD-Datenbank, nämlich nur die Änderungen die ab der Sicherung durchgeführt wurden repliziert wird.

 

Durch die ausschließlich ordnungsgemäß durchgeführte Sicherung und der Rücksicherungsmethode wird ein USN Rollback und somit Schaden verhindert! Wenn man sich nicht sicher ist ob das eingesetzte Sicherungsprogramm eine unterstützte Sicherung sowie Rücksicherung durchführt, sollte man ein klärendes Telefonat mit dem Hersteller führen. Von ungültigen Sicherungsmethoden wie das Rücksichern eines Images, VM-Images und VM-Snapshots (mindestens auf Servern die transaktionale Datenbanken bereitstellen wie ein DC, Exchange und SQL) sollte man stets Abstand halten und wird seitens Microsoft auch nicht supportet!

Auf einem DC ist es Pflicht mindestens das System State zu sichern und das kann man bereits mit Windows-Bordmittel (NTBACKUP, Wbadmin) durchführen!

 

Weiterführende Informationen:
Domänencontroller-Installation von einer Sicherung
Images als Sicherung?
Das Active Directory gewaltsam vom DC entfernen
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Der RID-Master und sein RID-Pool
Lingering Objects (veraltete Objekte)
How to detect and recover from a USN rollback in Windows Server 2003
How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory

Sunday, April 18, 2010 1:18:07 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | Replikation | Wiederherstellung  | 
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: