Der Kommandozeilenserver Server Core ist mit Windows Server 2008 eingeführt worden und wird mit Windows Server 2008 R2 weiterentwickelt. Redmond stellt für den Server Core unter 2008 R2 weitere Rollen sowie optionale Features zur Verfügung, die man sich mit oclist anzeigen lassen kann und mit ocsetup bzw. dism installiert werden.
Gerade aber die Erstkonfiguration des Server Core stellt viele Administratoren die lieber mit der Maus arbeiten vor eine Herausforderung. Denn mit Bordmitteln lässt sich der Server Core ausschließlich über die Kommandozeile konfigurieren, in der lange Befehle eingetippt werden müssen (was nicht gerade jedermanns Geschmackssache ist).
Kostenlose Tools im Internet schaffen Abhilfe und helfen dem Administrator, der sich nur schwer von seiner geliebten Maus trennen kann, die langen und aufwändigen Befehle nicht per Hand eintippen zu müssen.
Nun befindet sich jedoch in der Installationsvariante Server Core des Windows Server 2008 R2 das Skript Sconfig.cmd im Verzeichnis %windir%\System32 bereits „on Bord“, das die Erstkonfiguration des Server Core wesentlich erleichtert. Mit dem Skript können die folgenden Konfigurationen des Server Core vorgenommen werden:
- Domäne/Arbeitsgruppe
- Computername
- Lokalen Administrator hinzufügen
- Remoteverwaltung konfigurieren
- Windows Update-Einstellungen
- Updates herunterladen u. installieren
- Remotedesktop
- Netzwerkeinstellungen
- Datum und Uhrzeit
- Benutzer abmelden
- Server neu starten
- Server herunterfahren
- Zur Befehlszeile wechseln
Der Administrator kann jetzt einfacher die lokale Konfiguration des Server Core mit Bordmitteln vornehmen, damit in Zukunft die Fernwartung über die MMCs durchgeführt werden kann.
Des Weiteren existiert noch ein neues Kommandozeilentool tzutil.exe mit dem die Zeitzone konfiguriert werden kann.
Weitere Informationen:
Windows Server 2008 Core
Tools zum konfigurieren des Server Core
Server Core Installation Option Getting Started Guide
Download details: Server Core Job Aids
Eine weitere Neuheit die ab Windows Server 2008 R2 und Windows 7 eingeführt wird, ist die Möglichkeit einen Computer mit Windows Server 2008 R2 oder Windows 7 zur Domäne hinzuzufügen, ohne das die Maschine eine Verbindung zum Netzwerk hat (Offline Domain join). Diese neue Funktion kann ausschließlich ab Windows Server 2008 R2 und Windows 7 eingesetzt werden. Damit ist es möglich an entfernten Standorten die noch keine Anbindung ans Unternehmensnetzwerk haben Windows Server 2008 R2 Mitgliedserver und Windows 7 Clients zur Domäne hinzuzufügen.
Eine weitere Einsatzmöglichkeit für diese Funktion wäre, dass bereits die bestellten Windows 7 Clients direkt vom PC-Lieferanten vorinstalliert und zur Domäne hinzugefügt werden.
Oder bei der Massenanfertigung von virtuellen Maschinen können direkt nach der Betriebssysteminstallation die VMs zur Domäne hinzugefügt werden. Das ganze hat sogar den Vorteil, dass dadurch ein Neustart erspart bleibt der sonst nach dem Hinzufügen einer VM zur Domäne notwendig wäre.
Auch mit Deployment Tools, wie z.B. dem Windows-System-Image Manager (SIM) der Bestandteil des Windows Automated Installation Kit (WAIK) ist, können bereits während der unbeaufsichtigten (unattended) Installation eines Windows Server 2008 R2 und Windows 7 die Systeme zur Domäne hinzugefügt werden. Das ist möglich durch das Bereitstellen der relevanten Daten in der Unattend.xml-Datei, die für das offline domain join notwendig sind. Die Unattend.xml-Datei für Windows Server 2008 R2 und Windows 7 muss um einen weiteren Abschnitt erweitert werden, damit das Hinzufügen zur Domäne bereits während der Betriebssysteminstallation vonstattengehen kann.
Diese neue Funktion ist Dank einem neuen Kommandozeilentool Namens Djoin.exe möglich, dass nur ab Windows Server 2008 R2 und Windows 7 „on Bord“ ist. Mit diesem Kommandozeilentool lässt sich auch der sichere Kanal zwischen einem Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client und einem Domänencontroller zurücksetzen.
Wie üblich bei den Windows-Kommandozeilentools lässt sich mit dem Befehl djoin /? die Hilfe aufrufen, worin die einzelnen Parameter beschrieben werden.
Einen Windows Server 2008 R2 oder Windows 7 offline zur Domäne hinzufügen
-
Im ersten Schritt muss von einem Windows Server 2008 R2 (DC oder Mitgliedserver) oder Windows 7 das Computerkonto im AD erstellt werden. Dabei wird eine Textdatei generiert, die lokal auf dem zu hinzuzufügenden Windows Server 2008 R2 oder Windows 7 benötigt wird. Diesen Vorgang bezeichnet man auch als bereitgestellte Installation oder auf englisch provision computer account.
-
Bei der bereitgestellten Installation wird das Computerkonto im AD standardmäßig im Container Computers erstellt. Der Befehl lautet so:
Djoin.exe /provision /domain <Domänenname> /machine <Computername> /savefile <blob.txt>
-
Soll stattdessen das Computerkonto in einer OU erstellt werden, so müsste der folgende Befehl ausgeführt werden:
Djoin.exe /provision /domain <Domänenname> /machine <Computername> /machineou <DN der OU> /savefile <blob.txt>
-
Standardmäßig wird mit Ausführen von Djoin.exe das Computerkonto im AD von einem Windows Server 2008 R2 DC erstellt. Durch die Angabe des Parameters /downlevel kann das Computerkonto von einem DC älter als Windows Server 2008 R2 bzw. in einer Windows 2000, Windows Server 2003 oder Windows Server 2008 Domäne erstellt werden:
Djoin.exe /provision /domain <Domänenname> /machine <Computername> /downlevel /savefile <blob.txt>
-
Der mit diesem Befehl erstellte Base64-codierte Metadaten-Blob (Binary Large Object, die Textdatei) enthält sehr sensible Daten. Diese Datei sollte verständlicherweise sicher aufbewahrt werden, denn in dem Blob ist z.B. das Computerkontokennwort, Informationen über die Domäne einschließlich des Domänennamens, der Name eines Domänencontroller und der Security Identifier (SID) der Domäne enthalten. Daher muss zwingend darauf geachtet werden, dass wenn diese Datei physikalisch (über den Postweg) oder über das Netzwerk transportiert wird, die Sicherheit jederzeit gewährleistet ist und diese Datei nicht in fremde Hände gelangt.
Der Blob sieht wie folgt aus:
-
Im zweiten Schritt muss auf dem Windows Server 2008 R2 oder Windows 7 der zur Domäne hinzugefügt werden soll, der folgende Befehl in einer Kommandozeile eingegeben werden. Dabei ist es zwingend, dass die CMD explizit als Administrator gestartet wird:
Djoin.exe /requestodj /loadfile <Pfad zur blob.txt> /windowspath %windir% /localos
-
Zum Schluss ist ein Neustart fällig. Anschließend kann der Rechner ans Netzwerk verkabelt werden und befindet sich automatisch in der Domäne.
-
Mit type blob.txt bekommt man die Datei in der Kommandozeile angezeigt.
Welche Rechte werden benötigt?
Für diese Funktion werden Domänen-Admin Rechte benötigt oder den entsprechenden Personen wurde das Recht Hinzufügen von Arbeitsstationen zur Domäne über die Gruppenrichtlinie erteilt. Besser wäre es jedoch dieses Recht per Objektdelegierung an die jeweiligen Personen zu delegieren.
Clients in die Domäne hinzufügen
Wird eine Logdatei erstellt?
Wenn ein Fehler beim ausführen von Djoin.exe auftritt, erhält man in der Protokolldatei %windir%\debug\netsetup.log weitere Informationen.
Beitreten zur Domäne während einer unbeaufsichtigten Betriebssysteminstallation
Für das Beitreten zur Domäne während der Betriebssysteminstallation muss zuerst mit Djoin.exe das Computerkonto im AD und vor allem der Base64-codierte Metadaten-Blob generiert werden. Anschließend gilt es die Unattend.xml Datei zu erzeugen und einen neuen Abschnitt in der XML zu erstellen. Der Abschnitt sieht folgendermaßen aus:
<Component>
<Component name=Microsoft-Windows-UnattendedJoin>
<Identification>
<Provisioning>
<AccountData>Inhalt des Base64codierten Metadaten-Blob</AccountData>
</Provisioning>
</Identification>
</Component>
Nach dem fertigstellen der Unattended.xml Datei gilt es den Computer der zur Domäne hinzugefügt werden soll im Windows PE (Windows Preinstallation Environment) zu starten. Danach muss das Setup mit der Angabe der Antwortdatei ausgeführt werden:
Setup /unattend:<Pfad zur Unattended.xml>
Den sicheren Kanal (secure channel) mit Djoin.exe zurücksetzen
Wenn der sichere Kanal zwischen einem Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client und einem Domänencontroller nicht mehr funktioniert, entsteht ein typisches Authentifizierungsproblem. Die Lösung für dieses Problem wäre entweder NLTEST auszuführen NLTEST /SC_RESET (NLTEST befindet sich in den Windows Support Tools und ist ab Windows Server 2008 bereits on Bord) oder die Maschine aus der Domäne zu entfernen und erneut hinzuzufügen.
Dieses Problem lässt sich nun auch mit Djoin.exe lösen. Dazu muss man sich entweder an dem betroffenen Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client mit zwischengespeicherten Anmeldeinformationen oder an einem nicht betroffenen Windows Server 2008 R2 Mitgliedserver oder Windows 7 anmelden.
-
Als Erstes muss eine Eingabeaufforderung mit erhöhten Rechten (Start-Alle Programme-Zubehör-Eingabeaufforderung, Rechtsklick --> Als Administrator ausführen) gestartet werden. Danach gilt es diesen Befehl einzugeben:
Djoin.exe /provision /domain <Domänenname> /reuse /machine <betroffener Computername> /savefile C:\blob.txt
-
Steht kein Windows Server 2008 R2 DC zur Verfügung, so muss der Parameter /downlevel mit angegeben werden:
Djoin.exe /provision /domain <Domänenname> /reuse /machine <betroffener Computername> /downlevel /savefile C:\blob.txt
-
Wurde der Befehl auf einem nicht betroffenen System ausgeführt, muss der Blob auf das betroffene System kopiert werden.
-
Auf dem betroffenen System gilt es anschließend diesen Befehl, ebenfalls in einer CMD mit erhöhten Rechten auszuführen:
Djoin.exe /requestodj /loadfile <Pfad zur blob.txt> /windowspath %windir% /localos
-
Zum Abschluss muss der Windows Server 2008 R2 oder Windows 7 neu gestartet werden.
-
Danach sollte der sichere Kanal mit dem folgenden Befehl überprüft werden:
NLTEST /sc_verify:Domäne.TLD
Hinweis zum Parameter /downlevel
Das Kommandozeilentool Djoin.exe im Windows Server 2008 R2 und Windows 7 verwendet in erster Linie das LDAP-Protokoll um das Computerkonto im AD zu erstellen, was von früheren Betriebssystemversionen so nicht unterstützt wird. Wenn der Parameter /downlevel angegeben wird, wird das SAM-Protokoll verwendet falls das Erstellen des Computerkontos mit dem LDAP-Protokoll fehlschlagen sollte. Daher ist der Parameter /downlevel nur dann erforderlich, wenn kein Windows Server 2008 R2 DC in der Domäne existiert. Denn bei dem Parameter /downlevel wird die SE_MACHINE_ACCOUNT_PRIVILEGE-Berechtigung angewendet, anstatt die direkt auf dem Container erteilten Berechtigungen.
Weitere Informationen:
You cannot join a Windows 7 Beta-based or a Windows Server 2008 R2 Beta-based computer to an existing domain, and you receive an error message: "The parameter is incorrect"
Im Active Directory (AD) lassen sich Berechtigungen durch die folgenden Möglichkeiten an die entsprechenden Personen delegieren:
-
Durch den Assistenten zum Zuweisen der Objektverwaltung.
-
Durch das Bearbeiten der Discretionary Access Control List (DACL) im security descriptor des Objekts.
-
Mit dem Kommandozeilentool DSACLS.
Bis auf den Delegierungsassistenten lassen sich mit den beiden anderen Methoden die vergebenen AD-Berechtigungen zum einen anzeigen und zum anderen auch entfernen. Anzeigen sowie Löschen lassen sich die Rechte auch mit dem Kommandozeilentool DSREVOKE.
Der Objektdelegierungsassistent
Ein ungeübter Administrator sollte stets den Delegierungsassistenten verwenden, um die notwendigen Berechtigungen an die gewünschten Personen zu delegieren. Doch leider lassen sich die bereits delegierten Rechte auf einem Objekt durch den Objektdelegierungsassistenten weder anzeigen, noch entfernen. Der Assistent dient einzig und alleine dem vergeben von AD-Berechtigungen.
Der Objektdelegierungsassistent
Die Discretionary Access Control List (DACL)
Über die DACL lassen sich zum einen die Zugriffsrechte auf ein bestimmtes AD-Objekt vergeben sowie entfernen und zum anderen, kann man sich die vergebenen Berechtigungen anzeigen lassen. Damit man sich die vergebenen Berechtigungen z.B. auf einer Organisationseinheit (OU) in der grafischen Oberfläche anzeigen lassen kann, muss zuerst in der MMC Active Directory-Benutzer und -Computer unter Ansicht die Option Erweiterte Funktionen aktiviert werden. Danach erscheint in den Eigenschaften der OU der Reiter Sicherheit. Anschließend kann im security descriptor, den erweiterten Sicherheitseinstellungen der OU, die Person ausgewählt und mit einem Klick auf Bearbeiten… die gesetzten Berechtigungen eingesehen werden. Sollen die vergebenen Berechtigungen dem Benutzer entzogen werden, so ist der Benutzer aus der ACL (Access Control List) im Reiter Sicherheit des Objekts, zu entfernen. Ist es hingegen erforderlich bloß eine einzelne Berechtigung z.B. auf ein einziges Attribut dem Benutzer zu entziehen, so kann lediglich der ACE (Access Control Entrie) Eintrag aus der DACL entfernt werden.
Das Kommandozeilentool DSACLS
Der versierte Administrator kann recht einfach und das sogar automatisiert in einem Skript, wiederkehrende Berechtigungen im AD und in AD LDS (Active Directory Lightweight Directory Services, ehemals ADAM) mit DSACLS delegieren. Denn über die Kommandozeile lassen sich die Berechtigungen auf einem AD-Objekt mit DSACLS, das sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools befindet (z.B. auf der Windows Server 2003 CD im Verzeichnis Support\Tools) und ab Windows Server 2008 bereits im Betriebssystem integriert ist, ebenfalls vergeben sowie entfernen. Der Vorteil an diesem Tool ist, dass man aufwändige Berechtigungen skriptbasiert delegieren und im Fehlerfall die vergebenen Berechtigungen leichter entfernen kann.
Mit dem folgenden Befehl werden die Berechtigungen für die OU „IT“ (im dsa.msc) in einer TXT aufgelistet:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=de > C:\Dsacls.txt
Das DSACLS eignet sich auch sehr gut dazu, um die standardmäßige Sicherheitseinstellungen eines Objekts wiederherzustellen. Die standardmäßigen Sicherheitsinformationen erhält jedes Objekt durch das Active Directory-Schema. Denn jedes erstellte Objekt erhält durch das im entsprechenden classObject enthaltene Attribut Default-Security-Descriptor seine Sicherheitsinformationen.
Das bedeutet konkret, wenn z.B. ein Benutzer erstellt wird, werden die Sicherheitsinformationen vom Attribut defaultSecurityDescriptor
das in der Klasse User enthalten ist, auf das Benutzerkonto angewendet. Die Klasse User befindet sich in der Schemapartition im Pfad:
CN=User,CN=Schema,CN=Configuration,DC=kaan,DC=dikmenoglu,DC=de.
Dadurch erhält nun jedes Objekt bei seiner Erstellung durch den defaultSecurityDescriptor der jeweiligen Klasse seine Sicherheitsinformationen. Die Sicherheitsinformationen werden im Attribut defaultSecurityDescriptor im security descriptor definition language Format (SDDL-String) angegeben. Ausserdem bekommt das Objekt durch die darüberliegenden Einheiten (Domäne, OU) weitere Berechtigungen vererbt.
Hat man an einem AD-Objekt die Berechtigung so verändert das man den Überblick verloren hat, so lassen sich die Sicherheitseinstellungen die für diese Objektklasse im Schema des AD definiert ist wie folgt wiederherstellen: Dsacls <DN des Objekts> /S
Die Standardberechtigungen der OU IT in der Domäne kaan.dikmenoglu.de lassen sich wie folgt zurücksetzen:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=de /S
Befinden sich im Distinguished Name (DN) des Objekts Leerzeichen, muss dieser in „Anführungszeichen“ gesetzt werden.
Hinweis für Windows Server 2008: Wird mit dem Parameter /S unter Windows Server 2008 die Berechtigungen eines Objekts zurückgesetzt, erhält man in der Kommandozeile die Fehlermeldung Falscher Parameter und die Meldung Der Befehl wurde nicht erfolgreich ausgeführt. Aber die Berechtigungen werden trotzdem zurückgesetzt. Der Befehl funktioniert.
Die Berechtigungen eines einzelnen Benutzers oder einer Gruppe lassen sich mit diesem Befehl entfernen:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=de /R <DNS- oder NetBIOS Name der Domäne>\<sAMAccountName des Benutzers oder der Gruppe>
Der Befehl mit dem DNS-Namen der Domäne sieht dann so aus:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=DE /R kaan.dikmenoglu.de\Yusuf
Der Benutzer oder die Gruppe kann auch mit dem userPrincipalName (UPN) angegeben werden:
Dsacls OU=IT,DC=kaan,DC=dikmenoglu,DC=DE /R Yusuf@kaan.dikmenoglu.de
Achtung: Die Parameter in Dsacls sind case-sensitive!
Das Kommandozeilentool DSREVOKE
Die vergebenen Berechtigungen können in Form von ACEs (Access Control Entries) auch mit dem Kommandozeilentool DSREVOKE angezeigt und entfernt werden. Dieses Tool muss aber zuerst von Microsoft heruntergeladen werden und kann anschließend unter allen Serverversionen eingesetzt werden (auch unter Windows Server 2008!). ACLs werden (nicht so wie bei DSACLS) bei diesem Tool nicht berücksichtigt.
Die einzelnen ACEs eines Benutzers oder einer Gruppe lassen sich mit diesem Befehl anzeigen:
Dsrevoke /Report <DN des Objekts> <NetBIOS Name (nicht DNS-Name!) der Domäne>\<sAMAccountName eines Benutzers oder einer Gruppe>
Welche Berechtigungen der Benutzer Yusuf auf der OU IT in der Domäne kaan.dikmenoglu.de hat, lässt sich wie folgt anzeigen:
Dsrevoke /Report OU=IT,DC=kaan,DC=dikmenoglu,DC=de Kaan-Dikmenoglu\Yusuf
Die an den Benutzer Yusuf delegierten AD-Berechtigungen auf der OU IT lassen sich mit diesem Befehl entfernen:
Dsrevoke /Remove OU=IT,DC=kaan,DC=dikmenoglu,DC=de Kaan-Dikmenoglu\Yusuf
Die anschließende Sicherheitsabfrage zum Löschen muss mit einem “y” bestätigt werden.
Alle Berechtigungen eines Benutzers oder einer Gruppe ab einem bestimmten Container wie z.B. einer OU und somit auch von den darunterliegenden Objekten werden mit diesem Befehl entfernt:
Dsrevoke /Remove /root:<DN der OU> <NetBIOS Name der Domäne\sAMAccountName>
Download details: DSREVOKE.EXE
Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Objektdelegierungen einrichten
Das aktivieren/deaktivieren eines Benutzerkontos delegieren
How to Use Dsacls.exe in Windows Server 2003 and Windows 2000
When you use the Dsrevoke command-line tool to report permissions for all the organizational units in a Windows Server 2003-based domain, the tool may not return all the access control entries
Das Active Directory (AD) speichert seine Daten bekanntermaßen in einer Datenbank. Das Herzstück des AD ist die Datenbankdatei, die standardmäßig im Verzeichnis %windir%\NTDS\ gespeichert wird. Diese transaktionale Datenbank und die zugehörige Datenbank-Engine „Extensible Storage Engine (ESE)“, trägt den Namen NTDS.DIT. Dabei steht das „NTDS“ für New Technology Directory Services und das „DIT“ für Directory Information Tree.
Jeder Domänencontroller (DC) in einer Einzel- und Multidomänen-Gesamtstruktur hält seine eigene Kopie dieser AD-Datenbank (NTDS.dit), die kontinuierlich durch lokale Änderungen und durch die Replikationspartner aktualisiert wird. Die AD-Datenbank verändert sich in der Größe zum einen durch die lokalen Änderungen auf dem DC selbst und zum anderen durch die Änderungen die von den Replikationspartnern repliziert werden. Es ist zwingend notwendig, dass die AD-Daten konsistent zwischen den DCs durch die AD-Replikation gehalten werden. Aber die AD-Datenbankdatei ist ohnehin nie bis auf das letzte Bit zwischen mehreren DCs identisch.
Es gibt AD-Daten, die nicht zwischen den DCs repliziert werden. Denn z.B. werden die Indizes die eine performante LDAP-Suche ermöglichen lokal auf jedem DC erstellt. Dies kann bereits zu einem gewissen Maß an Größenunterschied in jeder AD-Datenbankdatei führen. Das einzige was repliziert wird ist die Anweisung, dass ein Attribut im AD indiziert werden soll. Wird in den Eigenschaften eines Attributs im Schema Snap-In die Option Attribut in Active Directory indizieren markiert, repliziert sich diese Änderung bei der nächsten Replikation der Schemapartition auf alle DCs in der Gesamtstruktur.
Die Gründe warum auf zwei DCs die AD-Datenbank unterschiedlich groß ist, sind:
-
Der Whitespace oder zu Deutsch: Der freie Speicherplatz in der AD-Datenbank. Dies trifft dann zu, wenn ein weiterer DC zur Domäne hinzugefügt wird. Wenn ein Server als zusätzlicher DC zu einer Domäne hinzugefügt wird kann es durchaus sein, das die AD-Datenbank des neuen DCs wesentlich kleiner ist als auf den bestehenden DCs. Das ist dann ein klares Indiz für den Whitespace der in der AD-Datenbank auf den bestehenden DCs existiert. Denn wird ein weiterer DC zur Domäne hinzugefügt, wird selbstverständlich nur die Nettokapazität der AD-Datenbank auf den neuen DC repliziert und nicht zusätzlich der unnötige Whitespace.
-
AD-Replikationsprobleme. Bestehen auf einem DC Replikationsprobleme, sei es mit einer oder mit allen Verzeichnispartitionen, bekommt dieser keine Aktualisierungen von seinen Replikationspartnern mehr mit.
-
In einer Multidomänen-Gesamtstruktur ist auf einem DC der globale Katalog (GC) aktiviert und auf dem anderen nicht. Oder auf einem DC wurde der GC „unbemerkt“ deaktiviert.
Die Ursachen in der Praxis sind in der Regel der Whitespace und AD-Replikationsprobleme, die den Unterschied zwischen den AD-Datenbankdateien ausmachen.
Der Whitespace in der AD-Datenbank
Der Whitespace in der AD-Datenbank entsteht folgendermaßen.
Wenn ein AD-Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf TRUE gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt und wandert anschließend in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert). Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Die gelöschten Objekte bleiben nun so lange im Container „Deleted Objects“ und somit in der AD-Datenbank erhalten, bis die Tombstone-Lifetime (TSL) abgelaufen ist. Erst wenn ein gelöschtes Objekt die TSL überschritten hat wird es endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Der Garbage Collection Prozess läuft standardmäßig im 12-Stunden-Takt auf jedem DC in der Gesamtstruktur. Die Zeit lässt sich zwar verändern, jedoch ist das beim täglichen Betrieb nicht notwendig.
Ändern könnte man die Zeit durch das Attribut garbageCollPeriod, welches sich in den Eigenschaften des folgenden Containers befindet (die Angabe der Zeit muss in Stunden erfolgen):
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Wenn die Objekte unwiderruflich aus dem AD entfernt wurden, entsteht freier Speicherplatz (der sogenannte Whitespace) in der AD-Datenbank. Die Datenbankseiten auf denen die Objekte gespeichert waren, werden als frei markiert. Physikalisch wird aber dadurch die AD-Datenbank auf der Festplatte nicht kleiner. Stattdessen werden beim Hinzufügen neuer AD-Objekte diese auf den freien Datenbankseiten geschrieben, ohne dabei eine Speicheroptimierung bei späteren Abfragen dieser Objekte zu berücksichtigen. Durch das wiederbeschreiben der freien Datenbankseiten wird die Gesamtgröße der AD-Datenbank nicht größer. Zwar findet standardmäßig alle 12-Stunden durch den Garbage Collection Prozess auf jedem DC eine Onlinedefragmentierung der AD-Datenbank im laufenden Betrieb statt, jedoch wird dabei die AD-Datenbank ebenfalls nicht kleiner. Ob die Onlinedefragmentierung zweimal am Tag auch wirklich stattfindet, kann im Verzeichnisdienstprotokoll auf jedem DC kontrolliert werden. Denn beim Starten der Onlinedefragmentierung wird die EventID 700 und wenn sie abgeschlossen wurde, die EventID 701 protokolliert.
Bei der Onlinedefragmentierung werden lediglich die leeren Datenbankseiten neu angeordnet um einen zusammenhängenden freien Speicherplatz in der AD-Datenbank zu schaffen. Somit wird die durch die endgültige Löschung der AD-Objekte bedingte Fragmentierung der AD-Datenbank beseitigt und dadurch der Zugriff auf das AD optimiert bzw. beschleunigt. Bei den heutigen Festplattenpreisen ist es aber auch keineswegs tragisch das die AD-Datenbank physikalisch nicht kleiner wird. Dennoch ist es aus Performancegründen empfehlenswert, dass die AD-Datenbank „nur“ so groß ist, damit sie noch in den Arbeitsspeicher des DCs geladen werden kann.
Wie viel freier Speicherplatz in der AD-Datenbank tatsächlich existiert, kann durch eine Registry-Einstellung herausgefunden werden. Dazu gilt es im folgenden Registry-Schlüssel diese Einstellung vorzunehmen:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics
"6 Garbage Collection" = 1 (REG_DWORD)
Anschließend wird beim nächsten Durchlauf des Garbage Collection Prozesses, im Verzeichnisdienstprotokoll des DCs die EventID 1646 protokolliert. In dem Eintrag wird der freie Speicherplatz neben der Gesamtgröße der AD-Datenbank angegeben.
Es reicht in der Regel aus diese Registry-Einstellung nur auf einem DC in der Domäne zu konfigurieren, da sicherlich der freie Speicherplatz auf allen bestehenden DCs (bei gleicher DC Konfiguration) gleich ist.
Eine andere Variante mit der man sich einen tieferen Einblick über die Größe des freien Speicherplatzes in Form von leeren Datenbankseiten sogar der einzelnen Indizes in der AD-Datenbank verschaffen kann, wäre mit Esentutl. Dazu muss jedoch das AD offline sein. Bis einschließlich Windows Server 2003 muss hierzu der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. Unter Windows Server 2008 lässt sich dagegen der Dienst Active Directory-Domänendienste samt den abhängigen Diensten im laufenden Betrieb mit dem Kommandozeilenbefehl net stop ntds /y anhalten. Danach wird mit dem Befehl Esentutl /ms <Pfad zur Ntds.dit> oder durch das Aufrufen von Esentutl aus dem NTDS-Verzeichnis C:\Windows\NTDS>Esentutl /ms ein detaillierter Auszug der Ntds.dit erstellt. Es ist auch möglich die AD-Datenbank aus einer System State-Sicherung an einer alternativen Stelle wiederherzustellen, um diese AD-Datenbank zum überprüfen des freien Speicherplatzes zu nutzen. In der AD-Datenbank wird jede Tabelle zusammen mit der Anzahl der Datenbankseiten die es besitzt, samt der Anzahl der leeren Datenbankseiten die zur Verfügung stehen aufgelistet.
Damit die AD-Datenbank physikalisch kleiner wird, ist eine Offlinedefragmentierung notwendig. Natürlich müsste die Offlinedefragmentierung auf jedem DC erfolgen, damit die AD-Datenbank auf jedem DC auch physikalisch kleiner wird. Aber in den allermeisten AD-Umgebungen ist eine Offlinedefragmentierung nicht nötig. Wobei es jedoch in größeren AD-Gesamtstrukturen wiederum des Öfteren notwendig sein kann, eine Offlinedefragmentierung durchzuführen.
Wann ist eine Offlinedefragmentierung empfehlenswert?
-
Nach einer größeren Löschaktion im AD ist es empfehlenswert, wenn nach Ablauf der Tombstone-Lifetime die gelöschten Objekte endgültig aus der AD-Datenbank entfernt wurden, eine Offlinedefragmentierung der AD-Datenbankdatei durchzuführen.
-
In einer Multidomänen-Gesamtstruktur ist es ratsam, nach der Deaktivierung des globalen Katalogs auf einem DC eine Offlinedefragmentierung der AD-Datenbank durchzuführen.
-
Des Weiteren ist nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2008 eine Offlinedefragmentierung empfehlenswert. Nach einem Inplace-Update von Windows 2000 entsteht in der AD-Datenbankdatei eine erhebliche Menge an freiem Speicherplatz. Das ist aufgrund einer Verbesserung ab Windows Server 2003 möglich, worin eindeutige „security descriptors“ nur einmal (Single Instance Store) und nicht jedes Mal wenn sie verwendet werden in der AD-Datenbank gespeichert werden.
-
Wenn die DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) umgezogen werden, wie es z.B. nach einer Domänenaktualisierung von einer Windows 2000 Domäne zu einer Windows Server 2003 bzw. Windows Server 2008 Domäne der Fall sein könnte, entsteht ebenfalls freier Speicherplatz in der AD-Datenbank (genauer in der Domänenpartition). Die Größe der AD-Datenbank lässt sich dann mit einer Offlinedefragmentierung verkleinern.
Die Größe unter anderem der AD-Datenbank kann man sich mit dem folgenden Befehl anzeigen lassen:
FOR /f %i IN ('Dsquery Server -Domain %userdnsdomain% -o Rdn') DO dir \\%i\Admin$\NTDS
Eine Offlinedefragmentierung durchführen
Die Gesamtgröße der AD-Datenbank wird ausschließlich nur durch eine Offlinedefragmentierung verringert. Diese sollte beim Entfernen einer größeren Anzahl an AD-Objekten, nach dem Entfernen eines globalen Katalogs in einer Multidomänen-Gesamtstruktur, nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2003R2/2008 und nach dem Umzug der DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartition durchgeführt werden.
Die Offlinedefragmentierung wird folgendermaßen durchgeführt:
-
Zuerst sollte eine System State-Sicherung des DCs durchgeführt werden.
-
Damit eine Offlinedefragmentierung der AD-Datenbank auf einem DC durchgeführt werden kann, muss unter Windows 2000 und Windows Server 2003 der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. In diesen Modus gelangt man, wenn während der Bootphase des DCs die F8-Taste betätigt und die Option „Verzeichnisdienstwiederherstellung“ ausgewählt wird.
-
Ab Windows Server 2008 ist das Starten im Modus „Verzeichnisdienstwiederherstellung“ nicht notwendig (was aber möglich wäre). Ab einem Windows Server 2008 DC kann der Dienst Active Directory-Domänendienste im laufenden Betrieb entweder in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds /y samt den abhängigen Diensten angehalten werden.
Active Directory-Domänendienste (AD-DS)
-
In der Eingabeaufforderung oder unter „Start-Ausführen“ gilt es das NTDSUTIL aufzurufen.
-
Ab Windows Server 2008 muss als erstes mit dem Befehl Activate Instance NTDS die NTDS-Instanz aktiviert werden. Unter Windows 2000 und Windows Server 2003/2003R2 muss dieser Schritt übersprungen werden.
-
Als nächstes gilt es den Befehl Files einzugeben.
-
In der „file maintenance“ Ebene werden mit dem Befehl info die aktuellen Informationen über den Pfad und der Größe der AD-Datenbank sowie der zugehörigen Protokolldateien angezeigt. Der Pfad zur AD-Datenbankdatei sollte notiert werden (zumindest sollte man ihn sich merken).
-
Mit dem Befehl compact to <Laufwerk>:\<Verzeichnis> wird eine neue, komprimierte AD-Datenbankdatei im angegebenen Verzeichnis erstellt. Es sollte ein Laufwerk und Verzeichnis an dem ausreichend Speicherplatz zur Verfügung steht ausgewählt werden, um die komprimierte neue AD-Datenbankdatei Ntds.dit zu speichern. Falls im Namen des Verzeichnispfads Leerzeichen enthalten sind, muss der Pfad in Anführungszeichen stehen. Z.B. compact to "C:\Neu NTDS".
-
Sobald die Offlinedefragmentierung abgeschlossen ist, gilt es mit der zweimaligen Eingabe von quit das NTDSUTIL zu verlassen.
-
Nun muss die neu erstellte defragmentierte Datenbankdatei "Ntds.dit" über die alte Datei "Ntds.dit" im aktuellen Pfad zur Active Directory-Datenbank (der in Schritt vier notiert bzw. gemerkt wurde), kopiert werden. Anschließend sind noch die alten Protokolldateien (*.log) zu löschen.
-
Das Kopieren der Datenbankdatei kann auch über die Kommandozeile mit folgendem Befehl erfolgen: Copy „C:\Neu NTDS\Ntds.dit“ „C:\Windows\NTDS\Ntds.dit“
Die darauffolgende Sicherheitsabfrage muss mit einem „j“ bestätigt werden.
-
Die alten Protokolldateien können in der Kommandozeile mit diesem Befehl gelöscht werden:
Del „C:\Windows\NTDS\*.log“
-
Danach gilt es den DC neu zu starten. Unter Windows Server 2008 wird mit net start ntds der Dienst Active Directory-Domänendienste samt den abhängigen Diensten gestartet.
-
Zum Schluss sollte noch eine System State-Sicherung mit der neuen Größe der Ntds.dit durchgeführt werden.
AD-Replikationsprobleme
Ein weiterer Grund warum zwischen zwei DCs die AD-Datenbank unterschiedlich groß ist, könnten AD-Replikationsprobleme sein. Hinweise ob es bei der AD-Replikation Probleme gibt, liefert bereits das Verzeichnisdienstprotokoll der DCs. Ein entscheidender Faktor bei der AD-Replikation ist die Tombstone-Lifetime (TSL). Denn DCs müssen sich mindestens einmal während der TSL mit ihren Replikationspartnern repliziert haben, da ansonsten Lingering Objects (herumlungernde Objekte) in der AD-Datenbank des DCs entstehen und die Replikationspartner den „veralteten“ DC von der AD-Replikation ausschließen.
Lingering Objects (veraltete Objekte)
Oftmals handelt es sich bei Replikationsproblemen um DNS-Probleme, denn für eine AD-Umgebung ist das DNS essentiell. Bevor ein DC die AD-Replikation startet führt dieser zuerst ein DNS-Lookup durch. Somit stellt der DC zwei Dinge sicher, zum einen das sein Replikationspartner online und funktionstüchtig ist und zum anderen, das die Namensauflösung funktioniert. Daher muss bei Replikationsproblemen die Umgebung genauestens untersucht und verifiziert werden, um welche Probleme es sich tatsächlich handelt.
Das nützlichste Werkzeug für die Überprüfung und Problembehandlung bei der AD-Replikation ist für alle Serverversionen Repadmin. Bis einschließlich „Windows Server 2003“ befindet sich Repadmin noch in den Windows Support Tools (auf der Server CD im Verzeichnis Support\Tools) und ab „Windows Server 2008“ ist es „on Bord“. Dieses Tool stellt quasi das Schweizer Messer für die AD-Replikation dar. Mit diesem Kommandozeilentool lässt sich die Replikationstopologie aus der Sicht jedes einzelnen DCs anzeigen.
Den Zustand der AD-Replikation kann man z.B. mit diesem Repadmin-Befehl überprüfen:
Repadmin /Replsum * /Bysrc /Bydest /Sort:Error
Die Replikationsinformationen auf einem DC lassen sich auch in eine CSV-Datei importieren, damit diese Datei z.B. in Excel geöffnet und leichter durchsucht werden kann. Der Befehl ist wie folgt:
Repadmin /showrepl * /csv > C:\Repadmin.csv
Eine andere Methode um Differenzen zwischen den AD-Datenbanken aufzudecken, ist neben Repadmin das DSASTAT. Details dazu liefert der folgende Artikel:
Domänencontroller vergleichen
Es könnte aber auch sein, dass ein Problem in der AD-Datenbank auf einem DC existiert. Dieses lässt sich mit einer Überprüfung der AD-Datenbankdatei herausfinden. Dazu sollte die Integrität der Ntds.dit mit NTDSUTIL untersucht und falls bei der Überprüfung Probleme gemeldet werden, könnten diese sich evtl. mit einem Fixup beheben lassen.
Siehe:
Die Active Directory-Datenbank reparieren
Die unterschiedliche Größe der AD-Datenbank zwischen globalen Katalogen
Wenn in einer Multidomänen-Gesamtstruktur auf einem DC der globale Katalog (GC) aktiviert wird, werden alle AD-Objekte aus allen Domänen in den GC repliziert. Im GC wird die vollständige Domänenpartition (alle Objekte samt allen Attributen) der eigenen Domäne gespeichert, in der sich der GC befindet. Die Domänenpartitionen der anderen Domänen werden ebenfalls in den GC repliziert, es werden jedoch nicht alle Attribute der Objekte gespeichert. Nur die Attribute die für eine Suchoperation relevant sein könnten (z.B. der DN eines Objekts) werden gespeichert.
Wird auf einem DC der GC aktiviert, gibt sich dieser nach Beendigung der Replikation im DNS als solcher bekannt. Das der DC endgültig ein GC ist, wird im Verzeichnisdienstprotokoll mit der EventID 1119 (was zwingend erscheinen muss!) protokolliert.
Ob das Heraufstufen eines DCs zum GC erfolgreich abgeschlossen wurde, lässt sich anhand des folgenden Artikels ermitteln:
Globaler Katalog – Sein oder nicht sein
Falls das Heraufstufen zum GC ordnungsgemäß abgeschlossen wurde und sich die lokale AD-Datenbankdatei dennoch von anderen GCs in der Größe wesentlich unterscheidet (z.B. 50%), so könnte ein DNS- und/oder Replikationsproblem vorliegen. Auch hierbei muss dann ein tiefergehendes Troubleshooting betrieben und die AD-Replikation mit Repadmin untersucht werden. Bei der Fehlersuche sollte die erste Anlaufstelle die Ereignisanzeige des DCs sein, DCDIAG sollte ausgeführt werden und bei Verdacht auf DNS-Probleme könnte man neben dem DCDIAG (mit den DNS-Parametern) noch das DNSLint ausführen.
Weitere Informationen:
Die Tombstone Lifetime
Globaler Katalog (Global Catalog - GC)
Die Protokollierung des Active Directory`s konfigurieren
Extensible Storage Engine Architecture
The Active Directory database garbage collection process
Performing offline defragmentation of the Active Directory database
Im Windows Server 2008 R2 ist ein weiteres neues Werkzeug integriert, das sich Active Directory-Verwaltungscenter (dsac.exe) nennt. Die neue Managementkonsole mit flexiblen Filtermöglichkeiten basiert auf der Powershell Version 2 und stellt im Prinzip eine grafische Shell für die Powershell dar. Denn nach dem die auszuführende Aufgabe in der Konsole ausgewählt wurde, führt dsac.exe die entsprechenden AD-Cmdlets aus. Jede Lese- und Schreibaktion im AD-Verwaltungscenter wird über die AD-Powershell durchgeführt. Das neue Werkzeug verringert den allgemeinen administrativen Aufwand, der in einer AD-Umgebung täglich zu bewältigen ist. Mit dieser neuen aufgabenbasierten Managementkonsole, beginnt im neuen Server-Betriebssystem die MMC 4 Ära.
Die im Vergleich zu der MMC „Active Directory-Benutzer und -Computer“ abgespeckte Managementkonsole „Active Directory-Verwaltungscenter“, ist in erster Linie eher an den Systemadministrator bzw. an den First-Level Support gerichtet. Denn es stehen nicht die gleichen Funktionen wie in der MMC Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Daher kann der AD-Administrator nicht auf die MMC dsa.msc verzichten (auch wenn es theoretisch möglich wäre). Die Personen denen die entsprechenden Rechte im AD delegiert wurden, können mit der neuen Konsole effektiver ihren täglichen Routineaufgaben nachgehen als mit der MMC dsa.msc. Gerade in größeren AD-Umgebungen mit mehreren Domänen spielt dieses Werkzeug seine Stärken aus.
Das AD-Verwaltungscenter ist, neben der AD-Powershell, von dem Dienst Active Directory-Webdienste (ADWS) abhängig, das erst ab Windows Server 2008 R2 zur Verfügung steht. Dsac.exe ist nicht auf die RPC- oder LDAP-Schnittstelle angewiesen. Daher muss in den vertrauten Domänen oder in der vertrauten Gesamtstruktur mindestens ein Windows Server 2008 R2 DC existieren oder das AD Management Gateway Service muss auf einem Windows Server 2003 DC bzw. Windows Server 2008 DC installiert sein, damit dsac.exe remote ausgeführt werden kann. Auf dem Windows Server 2008 R2 DC auf dem dieser Dienst läuft, darf der TCP-Port 9389 von der evtl. aktivierten lokalen Windows-Firewall nicht blockiert werden. Läuft der Dienst AD-Webdienste nicht oder ist dieser wegen einer Firewall nicht erreichbar, funktioniert das dsac.exe nicht.
Damit eine Windows Server 2003 oder Windows Server 2008 Umgebung mit dem AD-Verwaltungscenter (neben der AD-Powershell) administriert werden kann, muss das AD Management Gateway Service installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Das AD-Verwaltungscenter kann lediglich zur Verwaltung von AD DS-Domänen und nicht von AD LDS-Umgebungen eingesetzt werden!
Welche Funktionen stehen im AD-Verwaltungscenter gegenüber der MMC „AD-Benutzer und -Computer“ nicht zur Verfügung?
- Ein Drag & Drop ist nicht möglich.
- Es steht keine Delegierungsfunktion zur Verfügung.
- Die FSMO-Rollen der Domäne können nicht angezeigt werden, wie in der MMC dsa.msc.
Was kann mit dem AD-Verwaltungscenter alles durchgeführt werden?
- Mit dem AD-Verwaltungscenter können neue Benutzerkonten erstellt oder bestehende verwaltet werden.
- Es können neue Gruppenkonten erstellt oder bestehende verwaltet werden.
- Es können mehrere Objekte gleichzeitig ausgewählt und bearbeitet werden.
- Neue OUs können erstellt bzw. bestehende verwaltet werden.
- Auch neue Computerkonten können erstellt oder bestehende verwaltet werden.
- Es ist möglich in der gleichen dsac.exe Instanz, sich mit mehreren Domänen oder Domänencontrollern zu verbinden und sich die AD-Informationen anzuzeigen bzw. Änderungen durchzuführen.
- Durch die vorgegebenen oder eigens kreierten Filter (bei der globalen Suche) können lediglich die benötigten AD-Objekte angezeigt werden.
- Im Gegensatz zu dsa.msc lässt sich aus dem AD-Verwaltungscenter neben dem Domänen- nun auch der Gesamtstrukturfunktionsmodus heraufstufen.
Die Installation des AD-Verwaltungscenter
Das AD-Verwaltungscenter kann ausschließlich auf Windows Server 2008 R2 und Windows 7 Clients, auf folgende Varianten installiert werden:
- Durch das Installieren der AD DS-Rolle auf einem Windows Server 2008 R2.
- Durch das Heraufstufen eines Windows Server 2008 R2 zu einem Domänencontroller.
- Durch das Installieren der RSAT auf einem Windows Server 2008 R2.
- Durch das Installieren der RSAT auf einem Windows 7 Client.
Das AD-Verwaltungscenter wird zusammen mit dem „Active Directory-Modul“ für die Windows PowerShell und dem .NET Framework 3.5.1 installiert. Diese beiden Komponenten sind, neben dem Dienst AD-Webdienste, die Voraussetzung damit das AD-Verwaltungscenter eingesetzt werden kann.
Das Arbeiten mit dem AD-Verwaltungscenter
Wenn das AD-Verwaltungscenter gestartet wird, sticht das zurücksetzen der Benutzerkennwörter sowie das entsperren von Benutzerkonten ins Auge. Diese beiden Optionen sind einer der meisten Fehlerquellen mit denen sich der Administrator im täglichen Leben beschäftigen muss. Des Weiteren sieht man in der linken Hälfte der Managementkonsole den Navigationsbereich. Dort kann man sich durch die einzelnen Container durch hangeln. Die oft besuchten Container werden dabei für den schnellen Zugriff direkt angezeigt.
Das Erstellen eines neuen Benutzerkontos sieht wie folgt aus. Es lassen sich die Kontooptionen, Organisationsinformationen, Gruppenmitgliedschaften und Profileinstellungen in einem Schritt konfigurieren.
In der Domäne oder in einer bestimmten OU lassen sich die Objekte anhand der vorgegebenen Filtermöglichkeiten sogar mit zusätzlichen Attributen anzeigen.
Natürlich kann man auch entsprechende Suchkriterien für Computerkonten auswählen.
Bei der globalen Suche kann man sich mit den vorgegebenen oder selbst erstellten Filtermöglichkeiten die gewünschten Objekte anzeigen lassen. Dabei kann man auch nach der Auswahl der vorgegebenen Filtermöglichkeiten, den echten LDAP-Filter anzeigen lassen.
Des Weiteren ist es wie im Windows Explorer möglich, durch die Eingabe eines bestimmten LDAP-Pfads in der Adresszeile direkt in die gewünschte OU zu navigieren.
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|