Lange Zeit gabt es für Windows Vista gar keine Möglichkeit, mit unterstützten Methoden eine Windows-Infrastruktur fernzuverwalten. Nur mit Umwegen gelang es etwa, eine funktionsreduzierte Adminpak-Installation hinzubekommen. Erst anderthalb Jahre nach dem Vista-Release kam die Abhilfe: Der Nachfolger des Adminpaks nennt sich „Remote Server Administration Tools“ (RSAT). Die RSAT können unter den Vista-Versionen Business, Enterprise und Ultimate installiert werden und unterstützen sowohl die x86- als auch die x64-Architektur. Die Voraussetzung für die RSAT ist das Service Pack 1 für Windows Vista. Aber: Ganz vollständig sind die Tools zunächst nicht. Wie man dem für zwei wichtige Fälle abhilft, beschreibt dieser Artikel.

In Betrieb nehmen

Die RSAT lassen sich hier herunterladen:

• Downloaddetails: Microsoft Remoteserver-Verwaltungstools für Windows Vista 32-Bit Edition (KB941314)
  http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960
• Downloaddetails: Microsoft Remoteserver-Verwaltungstools für Windows Vista SP1 64-Bit Edition (KB941314)
  http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=d647a60b-63fd-4ac5-9243-bd3c497d2bc5

Nach der Installation der RSAT müssen noch die gewünschten Tools aktiviert werden. Damit etwa die AD-Snap-Ins angezeigt werden, gilt es die folgenden Schritte durchzuführen:

1. Im ersten Schritt ist in der Systemsteuerung unter Programme und Funktionen auf der linken Seite die Aufgabe Windows-Funktionen ein- oder ausschalten auszuwählen.
2. Im zweiten Schritt kann im darauf erscheinenden Dialogfenster Windows-Funktionen unter dem Punkt Remoteserver-Verwaltungstools – Rollenverwaltungstools – Tools für die Active Directory-Domänendienste die Komponente Tools für Active Directory-Domänencontroller aktiviert werden.

Anschließend stehen dem Administrator die drei AD-Snap-Ins (dsa.msc, dssite.msc und domain.msc) samt dem ADSI Edit in gewohnter Weise in der Systemsteuerung unter Verwaltung zur Verfügung. Wer die Programme lieber über das Startmenü aufruft, geht ähnlich vor wie unter Windows XP: Rechtsklick auf das Startmenü, Befehl „Eigenschaften“. Dort das Menü anpassen und auswählen: „Systemverwaltung: Im Menü Alle Programme anzeigen“ (fast ganz unten in der Liste).

Da fehlt doch was?

Wenn man nun in der MMC Active Directory-Benutzer und –Computer unter Ansicht die Erweiterten Features aktiviert, erscheinen weniger Reiter in den Eigenschaften eines Benutzerkontos als auf einem DC oder unter einem Windows-XP-Client mit installiertem Adminpak.

Möchte man aber die Einstellung „Terminaldienste-Benutzerprofil“ im Reiter Terminaldienstprofile konfigurieren, ist man gezwungen, diese Konfiguration entweder per RDP oder per Turnschuh direkt am DC vorzunehmen. Denn der Reiter Terminaldienstprofile, in dem diese Einstellung vorgenommen werden kann, erscheint auf einem Vista-Client nicht. Wer nun glaubt, dass dies an einem Windows-2008-basierenden Active Directory liegt und die Reiter in einer Windows-2000- oder Windows-Server-2003-Umgebung erscheinen, der irrt. Egal, in welcher Domäne sich der Vista-Client befindet, die Reiter erscheinen zu keinem Zeitpunkt.

Nun gibt es aber eine nicht supportete Möglichkeit, den Reiter Terminaldienstprofile und noch weitere drei Reiter in den RSAT anzuzeigen. Dazu sind die folgenden Schritte notwendig:

1. Zuerst müssen entweder von einem Mitgliedsserver unter Windows Server 2008, auf dem unter den Features die Komponente Tools für Active Directory-Domänencontroller installiert wurde, oder von einem Windows Server 2008 DC die beiden Dateien
   %windir%\system32\tsuserex.dll und %windir%\system32\de-DE\tsuserex.dll.mui auf den Vista-Client in die gleichen Verzeichnisse kopiert werden. Dabei ist auf die gleiche Architektur zu achten. Das bedeutet, die beiden Dateien müssen von einem 32-Bit-Server stammen, wenn es sich um einen 32-Bit-Vista-Client handelt.
2. Falls es sich um englische Systeme handelt, so lautet der Pfad zu der Datei „ususerex.dll.mui“ folgendermaßen: %windir%\system32\en-US\tsuserex.dll.mui.
3. Auf dem Vista-Client gilt es dann mit administrativen Rechten diesen Befehl auszuführen:
   regsvr32.exe tsuserex.dll.
4. Anschließend stehen die folgenden vier Reiter ohne Funktionsverlust zusätzlich auf dem Vista-Client zur Verfügung:

• Remoteüberwachung
• Sitzungen
• Terminaldienstprofile
• Umgebung

Mit dem folgenden Befehl verschwinden die Reiter wieder:

regsvr32.exe tsuserex.dll /u

Der Reiter Attribut-Editor unter Windows Vista

Der Reiter Attribut-Editor, der sich in Domänen unter Windows Server 2008 in der MMC „Active Directory-Benutzer und -Computer“ in den Eigenschaften der Objekte befindet, ist eine Erleichterung für den Administrator, um Änderungen von einzelnen Attributen direkt am Objekt vorzunehmen. Der Reiter erscheint jedoch erst, wenn unter Ansicht in der MMC „Active Directory-Benutzer und -Computer“, die Erweiterten Features aktiviert wurden.

Bis zu Windows-Server-2003-Zeiten musste der Administrator die Änderungen an einzelnen Attributen in Objekten z.B. mit ADSI Edit durchführen. Nun kann er das von einem Vista-Client oder einem Windows Server 2008, auf dem die RSAT und anschließend die Komponente Tools für Active Directory-Domänencontroller installiert wurden, durchführen.

Befindet sich der Vista-Client in einer Umgebung unter Windows Server 2008, erscheint standardmäßig beim Aufruf der Eigenschaften eines Objekts in der MMC ADBuC der Reiter Attribut-Editor. Ist jedoch der Vista-Client oder ein Windows Server 2008 (worauf die Komponente Tools für Active Directory-Domänencontroller installiert ist) Mitglied einer Windows-2000- oder Windows-Server-2003-Gesamtstruktur, so erscheint der Reiter nicht. Der Grund dafür ist, dass die Windows-2000-/2003-Gesamtstruktur diesen Reiter nicht kennt. Denn bei einem Upgrade einer Windows-2000- oder Windows-Server-2003-Domäne auf Windows Server 2008 werden einige Schema- und Konfigurationsänderungen in Active Directory ausgeführt, von denen eine genau diesen Reiter betriffr. Das ADPREP /FORESTPREP von der Windows-Server-2008-DVD aktualisiert nämlich auch den Display Specifier in der Konfigurationspartition, der genau diesen Reiter zum Vorschein bringt. Diese Änderung existiert natürlich in einer Gesamtstruktur unter Windows 2000/2003 nicht. Man kann sie aber wie folgt mit Domänen-Admin Rechten der Root-Domäne händisch hinzufügen:

1. Mit ADSIEdit oder LDP, die sich beide in den Windows Support Tools befinden, gilt es zuerst zu diesem Pfad zu navigieren:
   CN=computer-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
   Dort angekommen, ruft man mit einem Rechtsklick auf “computer-Display” die Eigenschaften auf und fügt im Attribut “adminPropertyPages” diese Zeile hinzu:
   8,{c7436f12-a27f-4cab-aaca-2bd27ed1b773}
2. Als nächstes ruft man die Eigenschaften von dem Objekt “default-Display” auf:
   CN=default-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
   Dort ist dann in dem Attribut “adminPropertyPages”, das sich ebenfalls in den Eigenschaften des Objekts befindet, dieser Wert einzutragen:
   4,{c7436f12-a27f-4cab-aaca-2bd27ed1b773}
3. Zum Schluss ist noch in den Eigenschaften des Objekts “user-Display”, das sich in diesem Pfad befindet:
   CN=user-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
   im Attribut “adminPropertyPages” dieser Wert einzutragen:
   10,{c7436f12-a27f-4cab-aaca-2bd27ed1b773}

Handelt es sich um englische Systeme, so muss die Änderung nicht im Container „CN=407“, sondern „CN=409“ erfolgen; Entsprechendes gilt für andere Sprachen. Des Weiteren kann bei den einzutragenden Werten die Zahl links vom Komma variieren. In den jeweiligen Objekten befinden sich bereits mehrere Werte im Attribut „adminPropertyPages“. Es sollte lediglich eine Zahl vergeben werden, die noch nicht existiert.

Anschließend steht der Reiter Attribut-Editor in der MMC ADBuC zur Verfügung, natürlich nur, wenn die „Erweiterten Features“ unter Ansicht aktiviert wurden.

Die Änderungen an den Objekten werden in der Konfigurationspartition durchgeführt, die bekanntlich in der Gesamtstruktur repliziert wird und somit alle Domänen in der Gesamtstruktur betrifft.

Verwandte Beiträge:

1. RSAT für Windows 7 RC
   Es ist wie im Admin-Himmel: Mit Windows 7 denkt Microsoft...
2. RSAT für Windows 7 RTM sind RTW
   Wow, welch eine Überschrift. Die Remote Server Administration Tools für...
3. Windows Server 2008: Service Pack 1 schon eingebaut
   Das gerade freigegebene Windows Server 2008 ist das erste Betriebssystem,...

Eine Abfrage der Erstellungsdaten per Skript könnte folgendermaßen aussehen:
How Can I Get a List of All the Objects that have been Added to Active Directory Since a Specified Date?
http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan06/hey0125.mspx

Ein ähnliches Attribut ist Create-Time-Stamp (RFC 2251). Es ist zwar im Schema definiert, aber es enthält selbst keinen Wert. Die Attributwerte werden allerdings im Moment der Abfrage errechnet. Diese Art von Attribut wird "Operational Attribute" oder auch "Constructed Attribute" genannt. Da das Attribut Create-Time-Stamp "constructed"  ist, kann es nicht repliziert werden. Sein Wert wird auch nicht in den GC übertragen.

Um die Kompatibilität mit X.500/LDAP herzustellen, erhält man bei einer Abfrage des Attributs Create-Time-Stamp den Wert von When-Created zurück. Möchte man dieses Attribut per Skript abfragen, so muss dies explizit über die GetInfoEx-Methode erfolgen.
http://msdn2.microsoft.com/en-us/library/ms675468.aspx
http://www.microsoft.com/technet/scriptcenter/guide/sas_ads_jdaa.mspx?mfr=true

MMC Snap-In "Active Directory-Benutzer und -Computer"

Recht einfach lässt sich das Erstellungsdatum eines Benutzerobjekts über die grafische Benutzerverwaltung anzeigen. Im Snap-In "Active Directory-Benutzer und -Computer" ist es notwendig, unter "Ansicht" die Option "Erweiterte Funktionen" zu aktivieren, um weitere Registerkarten im Benutzerobjekt anzeigen zu lassen. Anschließend ruft mandie Eigenschaften des gewünschten Benutzers auf. Im Reiter Objekt befindet sich der Eintrag "Erstellt am".

MMC Active Directory Service Interface Editor – ADSIEdit

Es ist ebenfalls möglich, mit ADSIEdit.msc (aus den Windows Support Tools) sich das Attribut anzeigen zu lassen. Dazu ist ADSIEdit.msc über "Start/Ausführen/ADSIEdit.msc" aufzurufen und die Domain-Partition zu öffnen (falls noch keine Verbindung besteht). Als nächstes erweitert man die Einträge "Domain" sowie den Container DC=<Domäne>,DC=<TLD>. Im Anschluss navigiert man zu dem Container, in dem sich die Benutzerobjekte befinden, und wählt mit einem Rechtsklick auf das Benutzerobjekt "CN=<Benutzername>" die Eigenschaften aus.  Nun kann man im Eigenschaften-Fenster des Benutzers das Attribut "whenCreated" kontrollieren.

Befehlszeilen-Abfrage mit DSQUERY

Neben der grafischen Oberfläche lässt sich das Attribut auch über die Befehlszeile abfragen. Dazu bietet sich eines der DS-Tools, dass im Windows Server 2003 Betriebssystem integriert ist an. Das Tool das sich dazu eignet, heißt dsquery. Der Befehl für die Abfrage könnte folgendermaßen lauten (alles in einer Zeile):

dsquery * domainroot -filter "(&(objectClass=User)(objectCategory=Person))" -attr distinguishedName sAMAccountName whenCreated -Limit 0

How do I know what attribute names to use when performing a 'DSQUERY *'?
http://www.jsifaq.com/SF/Tips/Tip.aspx?id=7992

Dsquery
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/46ba1426-43fd-4985-b429-cd53d3046f01.mspx?mfr=true

Befehlszeilen-Abfrage mit ADFind

Ein weiteres Befehlszeilenprogramm, das auf keinem administrativen PC fehlen sollte, ist das von Joe Richards entwickelte Tool "ADFind". Die Abfrage könnte z.B. folgendermaßen lauten:  

Adfind -b DC=<Domäne>,DC=<TLD> -f "&(objectclass=user)(objectcategory=person)" sAMAccountName whencreated

Download: http://www.joeware.net/win/free/tools/adfind.htm

Verwandte Beiträge:

1. Wie bekomme ich heraus, wann ein User sich zuletzt ans AD angemeldet hat?
   Es gibt für diesen Zweck im AD ein Attribut namens...
2. Mitglieder einer AD-Gruppe mit Zusatzdaten ausgeben
   MItglieder einer Gruppe werden in Active Directory an zwei Stellen...
3. Wie finde ich heraus, welcher Benutzer an welchem PC arbeitet?
   Es gibt leider keine einfache und hundertprozentig verlässliche Möglichkeit, diese...

Weiterhin soll mit NAP das „Zusammenspiel“ zusätzlicher Technologien gefördert sowie der Schutz gegen Spy-/Malware und Viren erhöht werden, sobald Computer auf Unternehmensnetzwerke zugreifen. NAP wurde also entworfen, um dem Administrator ein weiteres Hilfsmittel im täglichen Berufsleben zur Verfügung zu stellen. NAP kann aber nicht verhindern, dass sich nicht autorisierte Anwender unerlaubten Zugang zum Netzwerk verschaffen, um somit evtl. Viren einzuschleusen oder Angriffe zu starten.

Eigentlich sollte NAP schon in Windows Server 2003 R2 integriert sein, kommt nun aber vermutlich erst mit Windows Server 2008 auf den Markt. NAP ist allerdings bereits in Windows Vista und den aktuellen Betas von Windows Server 2008 enthalten. Mit NAP werden die folgen drei Aspekte berücksichtigt:

1. Die Gültigkeit der Netzwerkrichtlinien

Wenn ein Computer eine Verbindung mit dem Netzwerk aufbauen möchte, wird zuerst der aktuelle Sicherheitsstatus des Clients überprüft, und zwar anhand der Zugangsrichtlinien, die der Administrator festgelegt hat. Kommt lediglich die NAP-Überwachung zum Einsatz, so wird eine Verletzung der Richtlinien zwar notiert, aber dem unsicheren Client trotzdem der Zugang zum Netzwerk gewährt. Ist stattdessen das NAP für die strikte Isolation konfiguriert, wird dem Client bei Nichterfüllung der Zugangsrichtlinien der Zugriff auf das Netzwerk verwehrt.

2. Die Einhaltung und Erfüllung der Netzwerkrichtlinien

NAP stellt dem Administrator diverse Werkzeuge zur Verfügung, womit sich die gewünschten Unternehmensrichtlinien leicht einrichten bzw. erreichen lassen. Computer, die diese Richtlinien nicht erfüllen, werden zunächst isoliert und in einen Quarantänebereich verschoben (sog. Netzwerkisolation).

3. Die Netzwerkisolation

Erfüllt ein Client die gewünschten Richtlinien nicht, so kann der Client in einen Quarantänebereich verschoben werden, um nachträglich die gewünschte Sicherheitskonfiguration nachzuholen. Alternativ kann dem Client aber auch der Zugriff auf das komplette Netzwerk oder auf bestimmte Bereiche verweigert werden. Schließlich ist es ebenfalls möglich einen Quarantänebereich für Gast-PCs zu erstellen, die somit keinen Zugriff auf das Unternehmensnetzwerk haben, aber z.B. ins Internet dürfen.

Bisher hat der Administrator eine Überprüfung des Benutzernamens und/oder der IP vorgenommen. Mit NAP bekommt er nun darüber hinaus die Möglichkeit, die folgenden festgelegten Policys (Richtlinien) zu prüfen:

• Zentrale Konfiguration der Richtlinien 
• Automatische Aktualisierung der Systeme, um permanente Einhaltung der Sicherheitsrichtlinien sicherzustellen
• Überprüfung der Systeme noch vor dem Zugang bzw. der Kommunikation mit dem Netzwerk
• Wahlweise Isolation der Systeme in einen Quarantänebereich des Netzes, bis die Systeme auf den aktuellen Stand gebracht werden

Mit diesen Möglichkeiten wird eine weitere Hürde für den Zugang zu einem Netzwerk errichtet und dieses auf der anderen Seite natürlich weiter abgesichert. Zum Beispiel ist es nun möglich festzulegen, dass auf den Systemen der vorgeschriebene (und sich auf dem aktuellen Stand befindende) Virenscanner, das vorgeschriebene Betriebssystem und/oder die korrekt konfigurierte lokale Firewall installiert sein müssen. Diese Einstellungen sind gerade für Laptop-Anwender bzw. Heim-Arbeitsplätze sehr wichtig. So kann man sicherstellen, dass sich jedes System, das sich am Netzwerk anmelden möchte, sei es per VPN/RAS oder direkt, den Firmenrichtlinien entspricht. Anderenfalls ist eine Anmeldung nicht möglich. Durch diese Sicherheitsrichtlinien ist die Netzwerkkommunikation wesentlich sicherer, denn so ist gewährleistet, dass sich von einem Heimarbeitsplatz oder einem HotSpot kein Virus/Wurm/Trojaner/Mal-/Spyware sich ins Firmennetz einschleusen kann. NAP kann ebenfalls um Anwendungen von Drittanbietern erweitert werden, so dass ggf. noch andere Voraussetzung erfüllt werden müssen, wie z.B. Update-Stand der einzelnen Programme usw.
NAP umfasst Server- und Client-Komponenten:

• NAP-fähige Clients (Windows Vista, Longhorn Server), die folgende Dienste unterstützen; DHCP, RAS/VPN, IEEE 802.1x sowie IPSec
• NAP-fähige Server (ab Longhorn Server), die die gleichen Dienste unterstützen wie der Client (IEEE 802.1x, DHCP etc.) und worauf ein IAS ausgeführt werden kann
• IAS (= Internet Authentication Service) Server (der auf einem Longhorn Server läuft), der die Systeme auf die Einhaltung der Richtlinien hin überprüft
• Richtlinienserver, die festlegen, wie der Status eines jeden Systems, das ins Netzwerk möchte, sein muss und ggf. weitere Patches/Anwendungen für die Systeme bereithält
• Zertifikatsserver (unter Longhorn), die IPSec-fähigen NAP-Systemen Zertifikate ausstellen

Die Client-Komponente besteht aus dem SHA (= System Health Agent), der z.B. dafür sorgt, dass die Virenscannersignatur oder die Stände des Betriebssystemupdates an den Richtlinienserver übermittelt werden. Ein weiterer Teil der Client-Komponente ist der Quarantäneagent. Dieser ist für den Pflegestatus des NAP–Clients zuständig und kommuniziert diese Information an die darüber liegenden (SHA) und an die darunter liegenden (QEC = Quarantine Enforcement Client) Dienste. Die dritte und letzte Komponente des Clients ist die QEC (= Quarantine Enforcement Client )-Komponente. Es gibt für jeden Netzwerkverbindungs-Dienst einen Agenten der z.B. für DHCP, VPN-Verbindungen oder IPSec zuständig ist. Die SHAs übergeben SoHs (Statement of Health), die z.B. den Status der zuletzt installierten Betriebssystemupdates oder des Virenscanners prüfen und an die Quarantäneagenten übermitteln.

Screenshot von Windows Vista:

Die Server-Architektur von NAP besteht aus dem NAP-Server, dem IAS-Server, dem Quarantäneserver und einer Schicht mit SHV (= System Health Validators)-Komponenten. Der IAS-Server empfängt vom NAP-Server bzw. von der Komponente QES eine Liste mit den SoHs, die der Client über RADIUS an den Server übermittelt hat. Der IAS vermittelt zwischen dem NAP-Server und dem Quarantäneserver. Der Quarantäneserver erstellt Systemanalysen anhand der vorgegebenen Richtlinien und ist für die Kommunikation zwischen jeder SHV und dem IAS zuständig.

Die SHV-Komponente ist wie beim Client der SHA (= System Health Agent) für die Aktualität der Virenscannersignatur und der Betriebssystemupdates verantwortlich und übermittelt diese an den jeweiligen Richtlinienserver. Beispielsweise übermittelt ein bestimmter SHV die Informationen über den Virenscanner an einen bestimmten Richtlinienserver und eine andere SHV übermittelt die Stände des Betriebssystemupdates an einen anderen bestimmten Richtlinienserver.
Des Weiteren gestaltet sich der Quarantänebereich von NAP folgendermaßen:

• Jeder DHCP-Client bezieht seine IP-Adresse von einem DHCP-Server. Daher gibt es einen DHCP-Quarantänebereich, so dass, wann immer ein Client eine IP-Adresse anfordert bzw. diese erneuert, der DHCP-Server die Zugangsanforderung überprüfen kann und somit entscheidet, wie die Anfrage des Clients weiter verarbeitet wird. Dieses ist die einfachste und schwächste Netzwerkisolation.
• Dann gibt es noch die IPSec-Quarantäne, die nichts anderes macht als zu überprüfen, ob der Status der Quarantäneclients in Ordnung ist und (wenn dem so ist) vom Zertifikatsserver X.509 Zertifikate für die Clients abzurufen. Diese werden im privaten Netz von den NAP-Clients für die Authentifizierung sowie IPSec-Kommunikation zwischen den NAP-Clients benötigt. Bei dieser Variante können lediglich die Clients eine Kommunikation aufbauen, die auch über einen gültigen Status verfügen. Mit IPSec ist es möglich Anforderungen basierend auf IP-Adressen oder Portnummern zu definieren. Anders als bei der DHCP- sowie VPN-Quarantäne grenzt die IPSec-Quarantäne die Kommunikation auf die Verbindung und die Übertragung einer gültigen IP-Konfiguration der Clients ein. Mit der IPSec-Quarantäne erreicht man die stärkste Isolation. 
• Schließlich gibt es noch die VPN-Quarantäne. Hier werden die Anforderungen für den Zugriff auf das Netzwerk vom VPN-Server gesetzt – und zwar immer dann, wenn sich ein Client per VPN mit dem Netzwerk verbinden möchte. Mit diesem Quarantänebereich wird eine sehr starke Netzwerkisolation erreicht.

Diese Überprüfungsarten können erweitert werden, indem Softwarehersteller SHAs für den NAP-Client und SHVs für den IAS-Server, den NAP-Server und ggf. für den Richtlinienserver herstellen.

Verwandte Beiträge:

1. TS Web Access 2008 über ISA Server veröffentlichen
   Windows Server 2008 hat die Terminaldienste deutlich erweitert. Unter anderem...
2. OCS Communicator Web Access R2 – Teil 1: Neue Funktionen, Zusammenhänge und Einsatzmöglichkeiten
   Mit dem Communicator Web Access R2 bietet das Rollenset des...
3. OCS Communicator Web Access R2 – Teil 2: Aus administrativer Perspektive
   Dem Teil 1 zum Thema CWA R2 folgend, hier nun...

DCDIAG überprüft den Status der Domänencontroller in Active Directory auf ihre Funktionsfähigkeit. Es prüft die Replikation, die Topologie und Funktion von Active Directory und liefert eine Zusammenfassung der Ergebnisse mit detaillierten Informationen zu jedem getesteten Domänencontroller und eine Diagnose etwaiger Sicherheitsfehler. Des Weiteren wird DNS (Domain Name System) bezüglich der folgenden Punkte geprüft: Konnektivität, Verfügbarkeit von Diensten, Weiterleitungen und Stammhinweise, Delegierung, dynamische Updates, Registrierung von Locatoreinträgen, externe Namensauflösung und Unternehmensinfrastruktur.

DCDIAG.exe ist ein Kommandozeilen-Programm und befindet sich mit weiteren nützlichen Tools wie NetDIAG, NetDOM, LDP etc. in den "Windows Support Tools", die sich wiederum auf der Windows-CD im Verzeichnis "Support\Tools" befinden (SUPTOOLS.MSI). Es sollte darauf geachtet werden, dass man immer die richtige Version der Tools zum Betriebssystem benutzt, also nicht etwa das DCDIAG von Windows 2000 in einem Netzwerk unter Windows 2003 anwendet.

Ausgabe des Befehls "DCDIAG"

Hinweis: Diese Ausgabe von DCDIAG wurde ohne eine weitere Angabe eines Schalters ausgeführt.

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

Doing initial required tests
  
   Testing server: Mainz\MZDCON01
      Starting test: Connectivity
         ……………………. MZDCON01 passed test Connectivity

Mit diesem Test wird überprüft, ob der Domänencontroller im DNS registriert ist, ob er per Ping erreichbar ist und ob er per RPC (= Remote Procedure Call) bzw. LDAP (= Lightweight Directory Access Protocol) erreichbar ist.
Hierdurch wird festgestellt,  ob eine Verbindung zum Active Directory besteht, der mit dem Eintrag "passed" quittiert sein muss.

Doing primary tests
  
   Testing server: Mainz\MZDCON01
      Starting test: Replications
         ……………………. MZDCON01 passed test Replications

Hier geht es um die Überprüfung der zeitgerechten Replikation mit weiteren Domänencontrollern und ob Replikationsprobleme mit anderen DCs bestehen. Dieser Eintrag muss auf "passed" stehen. Wenn man erst vor kurzem (< 30 Min.) einen Domänencontroller installiert hat, kann es zu einem "failed" kommen. Hier sollte man es nach ca. 1 Std. erneut versuchen und darauf achten, das dieser Eintrag dann zu "passed" geändert wurde.

      Starting test: NCSecDesc
         ……………………. MZDCON01 passed test NCSecDesc

Bei diesem Eintrag wurde geprüft, ob eine Verbindung mit LDAP zum Active Directory vorhanden ist. Dieser Test muss unbedingt mit einem "passed" abgeschlossen werden. Falls hier kein positiver Eintrag erscheint, sondern ein "failed", könnte dies auf ein DNS-Problem zurückzuführen sein.
    
 Starting test: NetLogons
         ……………………. MZDCON01 passed test NetLogons

Hier wurde geprüft, ob eine Anmeldung am Active Directory möglich war und die Anmeldeinformationen ausreichen, um die Replikation stattfinden bzw. fortfahren zu lassen. Auch hier muss der Eintrag "passed" erscheinen.

      Starting test: Advertising
         ……………………. MZDCON01 passed test Advertising

Mit diesem Test überprüft DCDIAG, ob die Anmeldung am Active Directory möglich war und ob der Domänencontroller in der Lage ist, sich im Active Directory bekannt zu geben. Falls dieser Test nicht erfolgreich mit "passed" abgeschlossen wird, kann das Problem auch darin bestehen, dass der Netlogon Dienst "hängt" oder nicht starten konnte.

      Starting test: KnowsOfRoleHolders
         ……………………. MZDCON01 passed test KnowsOfRoleHolders

Dieser Test prüft, ob sich der Domänencontroller zu allen fünf FSMO-Rollen im Active Directory, verbinden konnte, die sich entweder auf ihm selbst oder auf einem anderen Domänencontroller befinden. Es leuchtet unmittelbar ein, dass dieser Test selbstverständlich mit einem "passed" beendet werden muss.

      Starting test: RidManager
         ……………………. MZDCON01 passed test RidManager

An dieser Stelle prüft das Tool, ob der Domänencontroller, der die Rolle des RID-Masters innehat, erreichbar ist und ob die Informationen richtig sind. Auch dieser Test muss mit einem "passed" abgeschlossen werden.

      Starting test: MachineAccount
         ……………………. MZDCON01 passed test MachineAccount

Hier wird geprüft, ob das Computerkonto im Active Directory in Ordnung ist und ob das Computerkonto sich richtig registriert hat. Man kann den Parameter  "/RecreateMachineAccount" verwenden, um eine Reparatur zu versuchen, falls das Computerkonto fehlt. Mit "/FixMachineAccount" kann man die Computerkontoeinstellungen korrigieren, wenn diese falsch sein sollten. Ein Testabschluss mit "passed" ist hier zwingend erforderlich.

Tipp: Falls DCDIAG Fehler bei dem Test von "MachineAccount" melden sollte, kann man diese mit dem Schalter /FIX beheben. Der Schalter "FIX" behebt Fehler im SPN (Service Principal Name) des Domänencontroller-Computerkonto-Objekts.

      Starting test: Services
         ……………………. MZDCON01 passed test Services

Hier wird überprüft, ob die Domänencontroller-Dienste laufen.

      Starting test: ObjectsReplicated
         ……………………. MZDCON01 passed test ObjectsReplicated

An dieser Stelle wird geprüft, ob der Domänencontroller sein Computerkonto und die DSA (= Directory Service Agent)-Objekte repliziert hat. Mit den Parametern "/objectdn:dn" mit "/n:nc", kann man zusätzlich ein weiteres zu überprüfendes Objekt angeben. Des Weiteren wird geprüft, ob alle Objekte des Active Directory mit den anderen Domänencontrollern repliziert worden sind.

      Starting test: frssysvol
         ……………………. MZDCON01 passed test frssysvol

Hier wird geprüft, ob der FRS (= File Replication Service) die Anmeldeskripte und GPOs im SYSVOL-Verzeichnis mit anderen Domänencontrollern repliziert hat. 

      Starting test: frsevent
         ……………………. MZDCON01 passed test frsevent

Bei diesem Test des FRSEVENT wird geprüft, ob Fehler bzw. Probleme mit dem File Replication Service bestehen. Falls die Replikation der SYSVOL-Freigabe nicht ordnungsgemäß durchgeführt werden konnte, könnte dies auf ein Problem mit den Richtlinien hindeuten.

      Starting test: kccevent
         ……………………. MZDCON01 passed test kccevent

Hier stellt der Knowledge Consistency Checker sicher, dass dieser Domänencontroller alle weiteren Domänencontroller finden kann, um Replikationsverbindungen aufzubauen.

      Starting test: systemlog
         An Error Event occured.  EventID: 0xC0002715
            Time Generated: 05/11/2006   18:41:27
            (Event String could not be retrieved)
         ……………………. MZDCON01 passed test systemlog

Hier wird geprüft, ob das System fehlerfrei läuft. DCDIAG prüft das SYSTEM-Eventlog und gibt die Fehlermeldungen der letzten 60 Minuten aus, was man aber natürlich auch selbst mit einem Blick in das System-Log prüfen kann.

      Starting test: VerifyReferences
         ……………………. MZDCON01 passed test VerifyReferences

Dieser Test überprüft, ob bestimmte Systemreferenzen wie der File Replication Service (FRS) und die Replikationsinfrastruktur intakt sind.

   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ……………………. ForestDnsZones passed test CrossRefValidation

Dieser Test überprüft die Gültigkeit von Querverweisen der ForestDNSZones-Anwendungsverzeichnispartition.

      Starting test: CheckSDRefDom
         ……………………. ForestDnsZones passed test CheckSDRefDom

Dieser Test überprüft, ob in der ForestDNSZones  Anwendungsverzeichnispartition eine "reference domain" gesetzt ist.

Hinweis: "CheckSDRefDom" prüft, ob für die Partition eine "Security Desriptor Reference Domain (SDRefDom)" konfiguriert ist. Diese SDRefDom wird speziell bei Anwendungspartitionen verwendet, die Replikate auf DCs verschiedener Domänen im Forest besitzen können, um zu entscheiden, aus welcher Domäne der "Default Security Descriptor" verwendet werden soll.

   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ……………………. DomainDnsZones passed test CrossRefValidation

Dieser Test überprüft die Gültigkeit von Querverweisen der DomainDNSZones-Anwendungsverzeichnispartition.

      Starting test: CheckSDRefDom
         ……………………. DomainDnsZones passed test CheckSDRefDom

Dieser Test überprüft, ob in der DomainDNSZones-Anwendungsverzeichnispartition eine "reference domain" gesetzt ist.

  
   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ……………………. Schema passed test CrossRefValidation

Dieser Test überprüft die Gültigkeit von Querverweisen in der Schemapartition.

      Starting test: CheckSDRefDom
         ……………………. Schema passed test CheckSDRefDom
  
Dieser Test überprüft, ob in der Schemapartition eine "reference domain" gesetzt ist.

   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ……………………. Configuration passed test CrossRefValidation

Dieser Test überprüft die Gültigkeit von Querverweisen in der Konfigurationspartition.

      Starting test: CheckSDRefDom
         ……………………. Configuration passed test CheckSDRefDom
  
Dieser Test überprüft, ob in der Konfigurationspartition eine "reference domain" gesetzt ist.

   Running partition tests on : intra
      Starting test: CrossRefValidation
         ……………………. intra passed test CrossRefValidation

Dieser Test überprüft die Gültigkeit von Querverweisen in der Anwendungsverzeichnispartition INTRA.

      Starting test: CheckSDRefDom
         ……………………. intra passed test CheckSDRefDom
  
Dieser Test überprüft, ob in der INTRA-Anwendungsverzeichnispartition eine "reference domain" gesetzt ist.

   Running enterprise tests on : intra.dikmenoglu.de
      Starting test: Intersite
         ……………………. intra.dikmenoglu.de passed test Intersite

Hier wird geprüft, ob der ISTG (= Intersite Topology Generator) arbeitet. Zudem wird abgeschätzt, wann automatisch ein anderer als ITSG ernannt wird.

      Starting test: FsmoCheck
         ……………………. intra.dikmenoglu.de passed test FsmoCheck

Dieser Test überprüft, ob der Domänencontroller den Dienst KDC (= Key Distribution Center-Schlüsselverteilungscenter) kontaktiert und ob er einen Zeitserver, einen bevorzugten Zeitserver, einen Domänencontroller, der die Rolle des PDC-Emulators innehat, und einen globalen Katalog erreichen kann. Dieser Test prüft nicht die Erreichbarkeit aller 5 bestehenden FSMO-Rolleninhaber.

Schalter für DCDIAG

Mit dem Schalter "/V" (Verbose) kann man sich weiterreichende Informationen anzeigen lassen, die bei der Fehlersuche nützlich sein könnten.

Der Schalter "/FIX" hat nur Auswirkung auf den "MachineAccount"-Test. Dieser Test repariert den SPN (= Service Principal Name) auf dem Domänencontroller-Computerkonto-Objekt. Wenn Probleme mit dem Computerkonto eines DCs bestehen sollten, dürfte der Schalter /Fix der richtige sein.

Mit dem Schalter "/A" testet man alle Domänencontroller, die sich am gleichen Standort befinden.

Mit "/E" werden alle Server in der Gesamtstruktur getestet. Dieser Schalter überschreibt den Schalter "/A".

Um sich nur die Fehler auf dem Domänencontroller anzeigen zu lassen, benutzt man den Schalter "/Q".

Mit dem Schalter " /S:<Domänencontroller>" kann man von dem Server, auf welchem sich das Tool DCDIAG befindet, jeden beliebigen Domänencontroller testen. Das Gute daran ist, dass man nicht auf jedem Server/DC das DCDIAG ausführen muss, sondern das Ganze von einem einzigen Server aus ausführen kann.

Wenn man die Ausgabe von DCDIAG in ein Logfile haben möchte, muss nun der Schalter "/F:Logfile.txt" angegeben werden, wobei "Logfile" den Dateinamen des Logs darstellt und dieser natürlich geändert werden kann. Wenn man den Schalter so wie in diesem Beispiel eingibt, wird das Log in der Root von C: erstellt, also "C:\Logfile.txt". Man kann natürlich auch mit dem Befehl "C.\dcdiag > C:\dcdiaglog.txt" ein Logfile erstellen lassen.

Ein ähnlicher Schalter ist "/FERR:Errorlog.txt". Dieser Befehl erstellt ein Logfile, das nur fatale Fehler enthält.

Möchte man einen einzigen Test testen, verwendet man den Schalter "/TEST:Testname" (z.B. C:\dcdiag /test:Netlogons). Zusätzlich wird immer der Test "Connectivity" ausgeführt, egal, welchen Test man prüfen möchte. Dies kann auch nicht abgestellt werden.

Der Schalter "/C" (steht für Comprehensive und bedeutet ausführlich bzw. übergreifend) kann verwendet werden, wenn man detaillierte Angaben erhalten möchte. 

Möchte man wissen, ob ein Domänencontroller z.B. einen GC oder Key Distribution Center zur Verfügung stellt, so gilt es folgenden Parameter einzugeben "/V /S:<Domänencontrollername> /test:advertising"

Mit "/U:Domäne\Benutzername /P:{* | Password | ""} " kann man ein anderes Benutzerkonto angeben, falls man derzeit mit eingeschränkten Rechten angemeldet sein sollte.
Falls das Benutzerkonto kein Kennwort haben sollte, gibt man <""> ein. Möchte man das Kennwort nicht sofort eingeben, kann man zunächst auch <*> eingeben. Dann wird man, nach Bestätigen des Befehls, nach dem Kennwort gefragt.

Beispiel

Dieses Skript erzeugt ein Log (als TXT) und speichert dieses unter C:\DCDIAG.txt ab. Eine eventuell vorher bestehende DCDIAG.TXT auf C:\ wird dabei gelöscht. Damit wird jeder DC in der Gesamtstruktur ausführlich getestet. Wenn der Test durchlaufen und das Log erstellt wurde, öffnet sich das Log automatisch.
Evtl. muss man den Pfad zum Programm-Verzeichnis (Support Tools) entsprechend der eigenen Umgebung anpassen.

@echo off

c:
cd \
cd "program files\support tools"

del c:\dcdiag.txt
dcdiag /e /c /v /s:DC-Name /f:c:\dcdiag.txt
start c:\dcdiag.txt

Eine Übersicht der einzelnen möglichen Parameter bekommt man mit dem Schalter "/?" oder hier: http://technet2.microsoft.com/WindowsServer/en/Library/39d6c272-5c2e-4db0-a79a-4d8fbf52dd411033.mspx?mfr=true

Weitere Beispiel-Ausgaben von DCDIAG kann man hier sehen:
http://technet2.microsoft.com/WindowsServer/en/Library/824f106c-a90b-421b-aa44-ebc1403c8b4c1033.mspx?mfr=true

Verwandte Beiträge:

1. Was macht DCDiag eigentlich?
   Auf dem Active-Directory-Teamblog ist ein guter Artikel erschienen, der die...
2. Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
   Wenn man einen Domänencontroller umbenennen muss, so kann man das...
3. RDP-Neuerungen unter Windows Server 2008
   Für die tägliche Arbeit der Administratoren gehört mittlerweile die RDP-Verbindung...

• Einstellungen des Gruppenrichtlinienobjekts
• Vom Benutzer angegebene Beschreibung der Sicherung
• Datums- und Zeitstempel der Erstellung der Sicherung
• Der GUID (Globally Unique Identifier) des Gruppenrichtlinienobjekts und die Domäne
• Die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL) im Gruppenrichtlinienobjekt
• Die WMI-Filterverknüpfung, falls vorhanden, nicht jedoch der Filter selbst
• Verknüpfungen zu IP-Sicherheitsrichtlinien, falls vorhanden
• XML-Bericht mit den Einstellungen des Gruppenrichtlinienobjekts, die als HTML-Text innerhalb der Gruppenrichtlinien-Verwaltungskonsole angezeigt werden können

Es werden nur die Daten eines Gruppenrichtlinienobjekts gespeichert, die sich innerhalb des GPO befindet. Die Daten die sich außerhalb des GPO befinden, wie z.B.:

• WMI-Filter
• IP-Sicherheitsrichtlinie
• Die Verknüpfung zu einem Standort/Domäne/OU

werden nicht mitgesichert und stehen bei der Wiederherstellung nicht zur Verfügung.

Mit der Gruppenrichtlinien-Verwaltungskonsole GPMC (Group Policy Management Console) kann man Gruppenrichtlinien (automatisiert) sichern, wiederherstellen, importieren sowie kopieren. Mit der Datensicherung der GPMC ist es nicht nur möglich GPOs rückzusichern, sondern es können auch Einstellungen von GPOs aus Sicherungen in andere Richtlinien importiert werden. Falls Gruppenrichtlinienobjekte in andere Domänen oder Gesamtstrukturen kopiert oder importiert werden sollen, helfen Migrationstabellen dabei, Sicherheitsprinzipale (SID) und UNC-Pfade im Quell-Gruppenrichtlinienobjekt auf die neuen Werte im Ziel-Gruppenrichtlinienobjekt zu aktualisieren. Dadurch ist es z.B. auch möglich, Gruppenrichtlinienobjekte aus einer Testumgebung in die Produktivumgebung zu überführen. 
Eine Migrationstabelle wird als XML-Datei mit der Dateierweiterung .MIGTABLE gespeichert und lässt sich mit dem in der GPMC integrierten "Migration Table Editor" bearbeiten.

Wenn die GPMC nicht zum Einsatz kommt, würde man zur Sicherung sowie Wiederherstellung von Gruppenrichtlinien, genauso für den Im- und Export, dass System State sichern bzw. wiederherstellen und somit wären zwei Serverneustarts fällig. Damit man für eine Rücksicherung "einer" Gruppenrichtlinie nicht gleich den System State rücksichern muss, bietet auch hier die GPMC ihre Funktionen an. Da die GPMC scriptingfähig ist, werden 37 Skripts im Pfad "%PROGRAMFILES%\GPMC\Scripts" mit installiert. Dort gibt es z.B. das "BackupAllGPOs"-Skript, das man dazu nutzen kann, sich per Batch täglich die GPOs zu sichern. So lässt sich die Rücksicherung eines GPO leichter handhaben.

Die Sicherung der Richtlinien über die GPMC findet grundsätzlich auf Festplatte statt, und es ist nicht möglich, die Sicherung direkt auf ein Bandlaufwerk zu schreiben.

In der GPMC hat man die Möglichkeit entweder einzelne (was z.B. ideal vor einer Richtlinienänderung wäre) oder alle Richtlinien zu sichern. Mit einem Rechtsklick auf den Container "Gruppenrichtlinienobjekte" gilt es den Eintrag "Alle sichern&" auszuwählen. Im darauf folgenden Fenster gibt man den Speicherort und eine aussagekräftige Beschreibung an:

Nach der Sicherung bekommt man den Sicherungsstatus angezeigt, in dem angezeigt wird, wie viele Richtlinien erfolgreich bzw. nicht gesichert wurden.
Der Speicherort sieht danach wie folgt aus:

Für jede Gruppenrichtlinie wird im angegebenen Speicherort ein Unterordner erstellt, dessen Name eine eindeutige Backup-ID ist. In den Unterordnern wird die Struktur der jeweiligen Richtlinie, wie sie im SYSVOL-Verzeichnis eines DCs existiert, inklusive der INF-, POL- und ADM-Dateien gesichert. Neben den Unterordnern existiert die Datei "manifest.xml", die dafür dient, dass die gesicherten GPOs anhand ihres benutzerfreundlichen Namens identifiziert werden können.

Die GPMC erzeugt (jeweils in einem Ordner) zusätzlich drei XML-Dateien, die wichtige Informationen bezgl. der Gruppenrichtlinie sowie Sicherung enthalten.
Diese sind:

• Backup.xml: Hier werden Informationen wie z.B. Berechtigungen, DNS- sowie NetBIOS-Domänenname, WMI-Filter, Versionsinfos und Gruppenrichtlinienerweiterungen gespeichert.
• Bkupinfo.xml: Diese (versteckte) Datei enthält eher allgemeine Informationen wie z.B. die Gruppenrichtlinien-GUID, den Domänennamen, den Domänencontroller, der die Sicherung durchgeführt hat, die Sicherungszeit sowie die Beschreibung.
• Gpreport.xml: Diese Datei speichert die Eigenschaften der Gruppenrichtlinie wie Deaktivierungen, Verknüpfungen und Berechtigungen.

Ebenfalls lassen sich die Sicherungen über das Kontextmenü des Containers "Gruppenrichtlinienobjekte" verwalten. Das Dialogfeld öffnet sich standardmäßig in dem Pfad, in dem die letzte Sicherung durchgeführt wurde. Hier kann man sich eine Übersicht über alle gesicherten GPOs in einem Pfad anzeigen lassen:

Mit dem Kontrollkästchen "Für jedes Gruppenrichtlinienobjekt nur die neueste Version anzeigen" lässt sich die Ansicht der Sicherungen auf die jeweils aktuellste Version beschränken.
  
Über die Schaltfläche "Wiederherstellen" lässt sich die ausgewählte Richtlinie wiederherstellen. Dabei würde eine evtl. bestehende Gruppenrichtlinie überschrieben werden.

Mit "Löschen" kann die ausgewählte GPO-Sicherung oder mehrere Sicherung durch betätigen der STRG-Taste markiert und gelöscht werden. 

Über die Schaltfläche "Einstellungen anzeigen&" lässt sich ein HTML-Bericht anzeigen, der die konfigurierten Einstellungen wie vorhandene WMI-Filter, verknüpfte Container usw. anzeigen lässt.

Download: GPMC mit SP1
http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&DisplayLang=de

Verwandte Beiträge:

1. TechNet-Webcast: Active Directory richtig sichern und wiederherstellen
   Am 23. August 2006 habe ich für Microsoft TechNet einen...
2. GPMC 2.0: Interessante Erkenntnisse bei GPO-Kommentaren
   Die neue Gruppenrichtlinienverwaltungskonsole (GPMC), die mit Windows Server 2008 und...
3. Active-Directory-Daten online wiederherstellen
   Grabsteine beleben mit Werding Das Problem Eben schnell das Windows-Anmeldekonto...

Das tombstoneLifetime-Attribut findet man (beispielsweise mit ADSIEdit) unter:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domain>,DC=<TLD>
Die Tombstone Lifetime gilt für den ganzen Forest und kann nicht für jede Domäne separat eingestellt werden. Entscheidend ist, wie der erste DC eines Forests installiert wurde. Letztlich sieht die TombstoneLifetime auf den einzelnen Serverversionen wie folgt aus:

1. Neu installierter Windows 2000 DC (mit allen SPs) : 60 Tage (Attribut = <not set>)
2. Upgrade von NT / 2000 DC auf 2003 DC : 60 Tage (Attribut = <not set>)
3. Upgrade von NT / 2000 DC auf 2003 SP1 DC : 60 Tage (Attribut = <not set>)
4. Upgrade von NT / 2000 DC auf 2003 SP1 / R2 DC : 60 Tage (Attribut = <not set>)
5. Neu installierter Windows 2003 DC : 60 Tage (Attribut = <not set>)
6. Upgrade von 2003 DC auf 2003 SP1 DC : 60 Tage (Attribut = <not set>)
7. Upgrade von 2003 DC auf 2003 SP1 / R2 DC : 60 Tage (Attribut = <not set>)
8. Neu installierter Windows 2003 SP1 DC : 180 Tage (Attribut = 180)
9. Neu installierter Windows 2003 R2 DC (NUR CD1) : 180 Tage (Attribut : 180)

Wichtig ist: Wenn man sich das Attribut mit ADSI Edit anschaut, und es steht auf "<not set>", bedeutet dies immer, dass die Tombstone Lifetime 60 Tage beträgt. Erst wenn dort ein anderer Wert angezeigt wird, gilt dieser – egal, ob er manuell oder über das System eingetragen wurde. Die Systemvorgabe wird bei der Installation des ersten Domänencontroller im Forest durch den Active-Directory-Installationsassistenten (dcpromo) aus der Datei "schema.ini" vom Verzeichnis %windir%\system32 erzeugt. Diese Datei enthält Angaben zum Basisschema der jeweiligen Betriebssystemversion. Installiert man den Server von einer Windows-Server-2003-CD, hat die schema.ini korrekterweise keinen Eintrag zur Tombstone Lifetime. Installiert man den Server von einer CD mit Windows Server 2003 SP1 (slipstreamed), so existiert in der Schema.ini der Eintrag "tombstoneLifetime=180". Das ist ebenfalls richtig.
Der schema.ini-Eintrag sieht wie folgt aus:

; Explict TSL default set in W2K3 SP1 to increase shelf-life of backups and allow longer
; disconnection times.
tombstoneLifetime=180

Installiert man den Domänencontroller mit der ersten CD von Windows Server 2003 R2 (bevor man die zweite CD installiert), so existiert der Eintrag "tombstoneLifetime=180" noch. Nach der Installation der zweiten R2-CD verschwindet der Eintrag aus der schema.ini. Dieses ist sicherlich so nicht beabsichtigt und scheint ein Bug zu sein.

Das kann man auch einfach auf den CDs kontrollieren. Auf der ersten R2-CD im Pfad "i386" existiert in der schema.ini der Eintrag "tombstoneLifetime=180". In der schema.ini-Datei, die sich auf der zweiten R2-CD in den Pfaden
"\CMPNENTS\R2\PACKAGES\COREBINS\I386\SCHEMA.INI" sowie "\CMPNENTS\R2\ADPREP" befindet, existiert dieser Eintrag nicht. Da diese Datei bei der Installation der zweiten CD die bereits im System vorhandene Datei überschreibt, läuft ein Active Directory, das auf dieser Basis installiert wird, wieder mit einer Tombstone Lifetime von 60 Tagen. Entscheidend ist stets die schema.ini-Dateiversion des ersten installierten Domänencontrollers.

Installiert man also den Server mit der ersten R2-CD, stuft ihn zum Domänencontroller und installiert danach die zweite R2 CD, bleibt der Wert "180" erhalten. Installiert man den Server mit der ersten und der zweiten R2-CD, stuft ihn zum Domänencontroller, ist der Wert <not set> definiert, was 60 Tage bedeutet.

Verwandte Beiträge:

1. Welchen Wert soll man der „Deleted Object Lifetime“ zuweisen?
   Eine Frage aus den englischsprachigen Microsoft Newsgroups (sinngemäß): Gibt es...
2. Schema-Versionen vergleichen
   In dem kürzlich hier erschienenen Artikel "Schema-Erweiterungen auffinden" habe ich...
3. Wo finde ich eine Dokumentation des AD-Schemas?
   Folgende sind die einfachsten Möglichkeiten: Untersuche das Schema mit dem...

• Windows Server 2003 SP1 muss installiert sein
• Die zweite CD von der R2 Version muss vorhanden sein
• Der Windows Server 2003 R2 Produkt-Key muss vorhanden sein (was auch eine gültige Lizenz voraussetzt: Entweder hat man R2 neu erworben oder man verfügt für den vorhandenen Windows Server 2003 über eine Software Assurance)

Wenn man die CD2 in den Server einlegt, erscheint dieses Fenster.
Klickt man nun auf den Menüpunkt "Windows Server 2003 R2 Setup fortsetzen"&

& wird man dann darauf hingewiesen, dass zuerst ein Schemaupdate durchführen muss, ehe man auf R2 updaten kann:

Also gilt es, zuerst in die Kommandozeile zu gehen, ins Verzeichnis "CD-LaufwerkCMPNENTSR2ADREP" zu wechseln und von dort den Befehl "adprep /forestprep" auszuführen. ADPREP sollte man auf dem Domänencontroller ausführen, der die Rolle des Schemamasters innehat, da es sich ja um eine Anpassung des Active Directory-Schemas handelt.

Hinweis: Nicht das ADPREP von der ersten 2003 R2 – CD benutzen, sondern von der zweiten CD! Sonst geschieht Folgendes: http://support.microsoft.com/kb/917385/en-us

Nach Bestätigung des Befehls "adprep /forestprep" erhält man einige Informationen, die auf nötige Voraussetzungen für die anderen DCs hinweisen. Falls diese Bedingungen erfüllt sind, geht es weiter mit der Eingabe von "C" und ENTER. Falls man an dieser Stelle abbrechen möchte, muss man mit einer beliebigen Taste und anschließender Bestätigung durch ENTER diesen Vorgang beenden.

Falls alles korrekt gelaufen ist, wird die Schemaaktualisierung mit einer Erfolgsmeldung beendet.

Nun kann man mit dem Update auf R2 beginnen. Mit Klick auf "Windows Server 2003 R2 Setup fortsetzen" kann das Update starten.

Der Assistent begrüßt den User mit der "Willkommens-Seite". Hier kann man zunächst noch auswählen, dass eine Desktopverknüpfung mit dem Dokument, das die neuen Features vom R2 beschreibt, erstellt wird.

Im nächsten Fenster muss der R2-Produkt-Key eingegeben werden:

Nach der Eingabe erscheint das Fenster mit der EULA, dem Lizenzvertrag für Endbenutzer, dem man zustimmen muss. Anschließend klickt man auf "Weiter".

Bevor das Update tatsächlich startet, erhält man nun nochmals eine Zusammenfassung der Aktionen:

Anhand der Fortschritts-Anzeige kann man beobachten, wie weit der Vorgang fortgeschritten ist:

Falls alles reibungslos funktioniert hat, beendet man dann das Update mit einem Klick auf "Fertig stellen":

Nun hat man den Domänencontroller auf Windows Server 2003 R2 aktualisiert.

Verwandte Beiträge:

1. Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
   Wenn man einen Domänencontroller umbenennen muss, so kann man das...
2. Installation von NT4-Druckertreibern auf Windows Server 2003
   Für die meisten Drucker gibt es auf der Windows Server...
3. Wie kann man einen DHCP-Server unter Windows ausfallsicher gestalten?
   Der erste Gedanke zielt an dieser Stelle meist in Richtung...

Es gibt zwei Möglichkeiten, einen Domänencontroller umzubenennen. Die erste Variante läuft über das GUI (Graphical User Interface) ab, die andere über das Tool Netdom, das in den Windows Support Tools enthalten ist. Bei der Umbenennung über die grafische Oberfläche spielt die Domänenfunktionsebene keine Rolle, daher kann der DC jederzeit umbenannt werden. Voraussetzung für die Umbenennung über Netdom ist, dass sich die Domänenfunktionsebene zwingend im Modus "Windows Server 2003" befinden muss.

Man sollte darauf achten, dass zu dem Zeitpunkt der Namensänderung keine Client-Server-Aktivitäten stattfinden, sonst kann es zu Problemen kommen.

Vorgehensweise über das GUI

Über "Start – Einstellungen – Systemsteuerung – System" oder mit einem Rechtsklick auf "Arbeitsplatz" und Auswahl von "Eigenschaften" erscheint das Fenster "Systemeigenschaften"

Im Reiter "Computername" klickt man dann auf "Ändern"

Es erscheint eine Warnmeldung, die zunächst gelesen werden sollte. Akzeptiert man die Warnung, bestätigt man mit OK. Andernfalls kann man den Vorgang mit ABBRECHEN an dieser Stelle beenden:

Im darauf folgenden Fenster kann man im Feld "Computername" den neuen Computernamen eingeben.

Wenn man den neuen Computernamen eingegeben hat und dieser länger als 15 Zeichen ist, &

& erscheint ein Hinweisfenster mit der Meldung, dass der NetBIOS-Name auf 15 Zeichen gekürzt wird:

Idealerweise wählt man einen Namen, der den Konventionen entspricht:

Wenn der neue Computername eingegeben wurde und man das Fenster mit OK bestätigt hat, muss man einen Benutzer eingeben, der Mitglied der Gruppe "Domänen-Administratoren" ist oder über die entsprechenden Rechte verfügt:

Nach erfolgter Authentifizierung des Benutzers und erfolgreichem Umbenennen des Domänencontrollers wird man zum Schluss darauf hingewiesen, dass die Änderungen erst nach einem Neustart wirksam werden:

Nach Bestätigung dieser Meldung mit OK muss zum Abschluss ein Neustart durchgeführt werden.

Jetzt gilt es noch, das DNS zu kontrollieren bzw. statische Einträge im DNS und WINS und wo der Servername sonst noch eine Rolle spielt (z.B. Netzwerk-Applikationen) zu korrigieren.

Tipp: Falls die Clients eine Netzwerk-Applikation ausführen, basierend auf dem Servernamen, kann man sich mit einem CNAME Eintrag im DNS behelfen.

Vorgehensweise über das in den Windows Support Tools enthaltene Programm "Netdom"

Um NETDOM zu nutzen, müssen die Windows Support Tools installiert werden. Diese befinden sich auf der Windows-Server-2003-CD im Verzeichnis "Support" – oder man lädt sie von der Microsoft-Webseite herunter: http://download.microsoft.com/download/3/e/4/3e438f5e-24ef-4637-abd1-981341d349c7/WindowsServer2003-KB892777-SupportTools-x86-ENU.exe

Um den Domänencontroller von MZDCON01 in DOMCON01 umzubenennen, geht man wie folgt vor:

1. In ein CMD-Fenster muss Folgendes eingegeben werden:
netdom computername <FQDN> /add:<FQDN mit neuem Namen>
In diesem Beispiel also:
netdom computername mzdcon01.intra.dikmenoglu.de /add:DOMCON01.intra.dikmenoglu.de

Falls sich die Domäne nicht im Domänenfunktionsmodus "Windows Server 2003" befindet, bekommt man nach Bestätigung des Befehls eine Fehlermeldung, so wie hier im Screenshot angezeigt:

2. Nach Heraufstufen des Domänenmodus auf "Windows Server 2003" läuft der Befehl durch:

Mit diesem Befehl wird der ServicePrincipalName (SPN) im Active Directory für das Computerkonto aktualisiert. Weiterhin wird im DNS ein Resource Record mit dem neuen Namen registriert.

Nach der Eingabe des Befehls muss die Replikation mit den anderen Domänencontrollern abgewartet werden. Erst wenn die Änderung des SPN sowie der DNS-Eintrag sich repliziert haben, kann es mit dem Umbenennen weiter gehen. Mit ADSIEDIT.msc, das sich durch die Windows Support Tools mitinstalliert, kann man kontrollieren, ob der neue Name in den Eigenschaften des DCs (im Attribut "msDS-AdditionalDnsHostName"), hinzugefügt wurde. Das Attribut steht in der Domänenpartition, das sich im folgenden Distinguished Name (DN) befindet, wobei der DN in diesem Beispiel lautet:
DC=intra, DC=dikmenoglu, DC=de, OU=Domain Controllers, CN=MZDCON01.

3. Nun gilt es, den soeben hinzugefügten neuen Namen DOMCON01 mit folgender Eingabe als primären Namen zu deklarieren:
netdom computername mzdcon01.intra.dikmenoglu.de /makeprimary:DOMCON01.intra.dikmenoglu.de

Der neue Distinguished Name lautet nun:
DC=intra, DC=dikmenoglu, DC=de, OU=Domain Controllers, CN=DOMCON01.
Weiterhin steht im Attribut "msDS-AdditionalDnsHostName" ebenfalls der Name "MZDCON01.intra.dikmenoglu.de" und nicht mehr DOMCON01. Nach dieser Änderung muss ein Neustart des Servers durchgeführt werden, was aber auch in der Meldung steht.

4. Zum Abschluss muss noch der "alte" Servername MZDCON01 entfernt werden.
Dies geschieht mit dem folgenden Befehl:
netdom computername DOMCON01.intra.dikmenoglu.de /remove:MZDCON01.intra.dikmenoglu.de

Auch hier gilt es zu überprüfen, ob sich die Änderungen bzw. die Löschung auf die anderen Domänencontroller repliziert haben bzw. das DNS zu kontrollieren, ob die SRV-Records aktualisiert wurden (_gc, _kerberos, _kpasswd, _ldap), ggf. "alte" Einträge bestehen und wenn ja, diese anzupassen oder zu entfernen.

5. Man kann auch den Computernamen mit folgendem Befehl auf dem Server ändern:
netdom renamecomputer mzdcon01.intra.dikmenoglu.de /newname:DOMCON01
Danach öffnet sich ein kleines Fenster und das NetDom fragt nach, ob man mit dieser Änderung fortfahren möchte:

Wenn man diese Meldung mit "Ja" bestätigt, wird der Computername geändert. Auch hier werden die Änderungen erst beim nächsten Neustart übernommen:

Danach muss erneut das DNS kontrolliert und die Einträge müssen ggf. angepasst werden.

Mit dem folgenden Befehl kann man feststellen, welche (alternativen/primären) Namen für den Server konfiguriert wurden:
netdom computername <FQDN> /enumerate:

Falls Exchange auf dem Server läuft, ist dieser Artikel zu beachten
http://support.microsoft.com/?id=842116

Verwandte Beiträge:

1. Wie aktualisiert man einen Domänencontroller auf Windows Server 2003 R2?
   Das Release Windows Server 2003 R2 basiert auf zwei CDs....
2. Wie kann man einen DHCP-Server unter Windows ausfallsicher gestalten?
   Der erste Gedanke zielt an dieser Stelle meist in Richtung...
3. Kann ich eine Domäne oder einen DC umbenennen?
   Das Umbenennen einer Domäne oder eines Domänencontrollers wurde zwischen Windows...

Was sind die Voraussetzungen, um das "Active Directory Migration Tool" in der Version 3 einzusetzen?

• Eine bestehende "physikalische" Verbindung zwischen den Domänen (LAN, WAN, VPN).
• Eine Vertrauensstellung, zumindest "One-Way", so dass in der Quelldomäne festgelegt wird, dass der Zieldomäne vertraut werden soll. Optional kann die Zieldomäne derart konfiguriert werden, der Quelldomäne zu vertrauen. Dies erleichtert zwar die Konfiguration, ist jedoch nicht erforderlich, um die ADMT-Migration abzuschließen.
• Funktionierende Namensauflösung.
• Idealerweise Domänen-Administrator-Rechte in der Quell- sowie Zieldomäne oder zumindest das Recht, Konten in der Quell- und Zieldomäne zu erstellen und zu löschen.
• Wenn Computerkonten verschoben/migriert werden sollen, müssen diese bei Anwendung des ADMT gestartet sein, da das Tool auf den Rechnern einen Agenten installieren muss.
• Die Zieldomäne muss Windows 2000 oder 2003 ausführen und sich zwingend im einheitlichen Modus befinden (dies ist anders als noch in der Version ADMT 2.0).

Das Tool muss auf einem Server und kann nicht auf einer Workstation installiert werden, es wird auch auf dem Server eine MSDE installiert. Die unterstützten Systeme sowie der Download des Tools können hier nachgelesen bzw. gedownloadet werden:
http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=6F86937B-533A-466D-A8E8-AFF85AD3D212

In dem Beispiel, das ich hier zeige, habe ich einen User von der Rootdomäne in eine Subdomäne migriert (im gleichen Forest). Bitte habt Verständnis dafür, dass ich nicht jedes Szenario vorführen kann, da es dann nicht mehr bei einem "kleinen How-To" bleiben, sondern zu einem Wälzer werden würde.

1. Nach dem Installieren des ADMT auf dem Quell-Server taucht ein weiteres MMC unter START – PROGRAMME – VERWALTUNG – ACTIVE DIRECTORY MIGRATION TOOL auf. Nach dem Aufruf des Tools kann man mit einem "Rechtsklick" auf den Stamm-Ordner auswählen, welche Aktion man ausführen möchte. Da ich einen User migrieren möchte, habe ich "User Account Migration Wizard" gewählt:

2. Danach begrüßt der Wizard den User, und mit einem Klick auf "Weiter" geht es zum nächsten Schritt:

3. Hier muss man nun die Quell- sowie Zieldomäne (NetBIOS-Name der Domäne) samt der jeweiligen Domänencontroller angeben. Ganz wichtig, die DCs, die die Rolle des "RID-Master" haben, müssen erreichbar sein. Hinweis: Die Zieldomäne muss sich im einheitlichen Modus befinden!

4. An diesem Punkt wählt man dann "Select users from Domain":

5. Im nächsten Fenster geht es mit einem Klick auf "Add&" weiter:

6. Hier gilt es nun, die gewünschten User auszuwählen, die in die "neue" Domäne migriert/verschoben werden sollen:

7. Wenn man dann die Userkonten ausgewählt hat und "Weiter" klickt, gelangt man zu dem nachfolgenden Fenster. Hier muss man festlegen, in welchem Ordner bzw. in welcher Organisationseinheit das Konto in der ZIEL-Domäne erstellt werden soll. Mit Klick auf "Browse&" :

8. ..gelangt man zu diesem Fenster (der Zieldomäne). In diesem Beispiel wird "Users"ausgewählt:

11. Wenn man die Option "Migrate associated user groups" nicht auswählt, erscheint die nachfolgende Meldung:

9. Dann taucht der aufgelöste DN-Name ( Distinguished-Name) auf und mit
einem Klick auf "Weiter" geht's zum nächsten Fenster:

10. Hier kann man nun verschiedene Optionen auswählen, wie  servergespeicherte Profile, Update der User-Rechte, Migration der Gruppen-Konten:

Falls es sich nicht um zahlreiche Konten mit verstrickten Gruppenkonten handelt, kann man diese Meldung vernachlässigen.

12. Im Anschluss daran folgt dieses Fenster. Je nachdem, welche Optionen vorher ausgewählt wurden, stehen hier eventuell nochmals weitere Optionen zur Verfügung. Der Assistent erfragt, was bei einem Konflikt wie z.B. einem doppelten Usernamen gemacht werden soll:

13. Nun klickt man auf "Fertig stellen" und die Migration kann ablaufen:

14. Wenn der Vorgang abgeschlossen ist, erscheint folgende Meldung:

Mit einem Klick auf "View Log" kann man sich Details des Vorgangs anschauen.
Somit hat man User von A nach B verschoben.

WICHTIG: Innerhalb eines Forests werden die Konten nicht kopiert, sondern verschoben.

15. Der User kann sich danach in der neuen Domäne anmelden.
Dieser wird bei der ersten Anmeldung aufgefordert, ein neues Kennwort zu vergeben, da der Password Migration Wizard nicht ausgeführt wurde.

Ich möchte an dieser Stelle nochmals hier auf die SidHistory aufmerksam machen: Falls sich der Vorgang innerhalb eines Forests abspielt, wandert die SidHistory automatisch mit. Wenn die SidHistory nicht mitwandert, muss man ggf. die Rechtestruktur für Objekte von Hand vergeben. Das ist sicherlich bei 10-20 Konten kein Problem, aber bei mehr als 50 Konten sieht es natürlich anders aus.

Hier noch mal die wichtigsten Links in der Zusammenfassung:

Download von AMT v. 3:
http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=6F86937B-533A-466D-A8E8-AFF85AD3D212

Ein sehr guter Microsoft-Artikel zum ADMT, allerdings in der Version 2:
http://support.microsoft.com/default.aspx/kb/326480

Verwandte Beiträge:

1. Wie kann ich Benutzerprofile migrieren?
   Unter Mitarbeit von Robert Pieroth Bei der Migration von einer...
2. Warum kann ich einen User nicht mit dem "memberOf"-Attribut einer Gruppe hinzufügen?
   Das Feld "memberOf" ist ein sog. "Backlink"-Feld, das zur Abfragezeit...

Ein Standort besteht aus einem oder mehreren Subnetzen und muss einer Standortverknüpfung angehören. Dabei kann ein Standort mehreren Domänen und eine Domäne kann mehreren Standorten angehören. In erster Linie besteht der Sinn von Standorten darin, dass man sowohl standortintern (Intra-Site) als auch standortübergreifend (Inter-Site) die Replikationsabläufe verwalten kann. Dort kann man durch Kosten, Intervall, Bridgeheadserver und Replikationspartner die Replikation beeinflussen. Damit die Replikation auch ordnungsgemäß verläuft, wird auf allen Domänencontrollern ein Konsistenzprüfungsdienst (Knowledge Consistency Checker – KCC) ausgeführt, der ständig prüft ob sich an den Gegebenheiten etwas verändert hat. Falls das so ist, passt der Prozess KCC die Replikationstopologie den Gegebenheiten an.

Mit dem Snap-In "Active Directory-Standorte und -Dienste" kann man seine Unternehmensstruktur abbilden. Dort kann man unter anderem:

• Standorte erstellen
• Standorte umbenennen
• Standorte löschen
• Subnetze erstellen
• Standorte einem Subnetz zuordnen
• Subnetze löschen
• Globaler-Katalog-Server erzeugen
• Intervalle zur Replikation festlegen (standardmäßig alle 180 Minuten, min. 15 bis max. 10.080 Minuten)
• Replikation an bestimmten Wochentagen oder zu bestimmten Zeiten festlegen, z.B. nur nachts
• Repliziervorgang "sofort" einsetzen (jetzt replizieren)

Die Replikation zwischen DCs innerhalb des gleichen Standortes basiert auf Benachrichtigungen, die innerhalb von fünf Minuten nach einer Objektänderung ausgegeben wird. Wenn eine Änderung an einem Objekt vorgenommen wurde, dauert es in der Regel 15 Sekunden, bis eine Änderungsnachricht (Change Notification) an den nächstliegenden Replikationspartner versandt wird. Wenn der Quelldomänencontroller mehrere Replikationspartner hat, werden nach und nach Benachrichtigungen, standardmäßig alle 3 Sekunden, an die weiteren Replikationspartner versandt (bei der Gesamtstrukturfunktionsebene Windows Server 2003).

Wenn die Domäne von Windows Server 2000 auf Windows Server 2003 aktualisiert wurde oder die Gesamtstruktur sich im "Windows Server 2000"-Modus befindet, sind es 300 Sekunden für eine Replikationsankündigung und 30 Sekunden Wartezeit (Verzögerung) für die weiteren Replikationspartner (Verhältnis 15/3 zu 300/30). Der Grund für diese deutliche Verkürzung der Replikationsverzögerung besteht darin, dass sich der Replikationsdatenverkehr als deutlich geringer herausgestellt hat, als die Entwickler beim Entwurf der ersten Active Directory-Versionen für Windows 2000 angenommen hatten.

Bei einigen Verzeichnisänderungen wie z.B. "Konto gesperrt" oder Änderungen an den Kennwort-Policys bzw. Änderung des Domänen-Administrator-Kennworts gelten die 15 Sekunden Wartezeit nicht, sondern die Replikation erfolgt sofort. Diese sofortige Replikation wird auch als dringende Replikation bezeichnet.

Zeitpläne sind von immenser Bedeutung. Wenn z.B. eine bestimmte Zeit lang nichts verändert und damit auch keine Replikation erfolgen würde, so repliziert das Active Directory dennoch standardmäßig alle 6 Stunden, um sicherzustellen, dass alle Domänencontroller auf dem aktuellen Stand sind und dass die Replikationstopologie intakt ist und keine Verbindungsprobleme bestehen.

Wenn ein Client bootet und sich anmelden möchte, meldet er sich standardmäßig an einem Domänencontroller innerhalb des eigenen Standortes an, und wenn er eine Dienst-Anfrage startet, fragt er an einem Domänencontroller desselben Standortes an. Der Client gehört automatisch dem Standort an, welchem der Server angehört, der dem Client seine Anmeldeinformationen (IP, DNS, usw.) übermittelt hat. Falls der Server oder der Client eine IP-Adresse hat, die keinem Standort zugeordnet ist, wird der Server bzw. Client automatisch dem zuerst erstellten Standort zugeordnet, dem Standort "Standardname-des-ersten-Standorts".

Active Directory repliziert Verzeichnisinformationen innerhalb eines Standortes (Intra-Site) häufiger als zwischen verschiedenen Standorten. So erhalten die Domänencontroller mit den schnellsten Verbindungen, also die, die bestimmte Verzeichnisinformationen am ehesten benötigen, die replizierten Daten zuerst.

Die Domänencontroller in den anderen Standorten erhalten die Änderungen ebenfalls, nur nicht so häufig, um Bandbreite zu sparen. Die Replikation zwischen den Standorten (Inter-Site) wird von Active Directory anders behandelt als standortintern, da standortübergreifend weniger Bandbreite zur Verfügung steht als standortintern. Standortintern geschieht die Replikation unkomprimiert, während sie standortübergreifend komprimiert repliziert wird.

Bei entsprechend konfigurierten Diensten kann das Datenvolumen bei der standortinternen Active Directory-Replikation Folgendes enthalten:

• Änderung an der Active Directory-Datenbank (NTDS.dit)
• Replikation des SYSVOL-Ordners
• Replikation des DFS (Distributed File Systems)

Beispiele für das Einrichten eines oder mehrerer Standorte

Das "optimale" Replikationsverhalten hängt sehr von der physikalischen Struktur des Netzwerks ab. Wenn z.B. ein Unternehmen nur einen Standort (ein Netz) mit hoher Bandbreite hat, empfiehlt sich ein Einzelstandort. Falls das Unternehmen mehrere Standorte hat, die evtl. durch "langsame" WAN Anbindungen untereinander verbunden sind, dann sollten mehrere Standorte eingerichtet werden, um das Replikationsverhalten präziser zu steuern. Auch reduziert sich im Zusammenhang mit der Authentifizierung die Wartezeit und die Netzwerklast ist geringer im WAN.

Vorteile eines Einzelstandorts sind:

• Einfache Replikation
• Replikation geschieht mehr oder weniger automatisch durch Änderungsnachricht – dadurch sind alle DCs stets auf dem aktuellen Stand
• Keine Replikationskonfiguration
• Weniger Hardware
• Weniger Administration

Vorteile mehrerer Standorte sind:

• Bessere Steuerung und effiziente Ausnutzung der WAN-Bandbreite bei der Replikation
• Reduzierung der Wartezeiten bei der Authentifizierung (Client sucht zuerst einen Domänencontroller am gleichen Standort, um sich anzumelden).
• Präzise Replikationssteuerung durch relative Kostenkontrolle

KCC (Knowledge Consistency Checker)

Der KCC (= Konsistenzprüfungsdienst) ist ein Prozess des Active Directory und dafür zuständig, dass die Verbindung zwischen den Replikationspartnern besteht und in der Gesamtstruktur eine effiziente Replikationstopologie entsteht. Ebenfalls sorgt der KCC für eine Konsistenz der verteilten Active Directory-Datenbank auf allen Domänencontrollern in der Gesamtstruktur. Wenn z.B. eine Verbindung/Leitung ausfällt, stellt der KCC wieder eine neue Verbindung zum Replikationspartner her. In der Regel nimmt der KCC alle 15 Minuten eine erneute Berechnung der Replikationstopologie für den Domänencontroller vor, damit Änderungen an der Active Directory-Struktur automatisch berücksichtigt werden und somit ein manuelles Eingreifen nicht erforderlich ist. Der Administrator kann weitere Verbindungen erstellen. Falls aber die Verbindung an irgendeiner Stelle abbricht, greift der KCC erneut ein und behebt dies. Dabei wird das Verfahren des Least-Cost-Spanning-Tree-Algorithmus (Inter-Site = standortübergreifend) angewendet, das auf Bandbreiteneffizienz ausgelegt ist.

Der KCC erstellt anhand eines Ringentwurfs automatisch eine effiziente Replikationstopologie innerhalb eines Standortes (Intra-Site) und eine für die standortübergreifende Replikation (zwischen den Standorten – Inter-Site).
Diese Ringtopologie versucht zwecks Fehlertoleranz mindestens zwei Verbindungen zu jedem Domänencontroller zu erstellen mit maximal 3 Hops zwischen den beliebigen DCs (dies wegen Reduzierung der Replikationswartezeit). Weiter erstellt der KCC für jede Verzeichnispartition eine eigene Replikationstopologie (Schema-, Konfigurations-, Anwendungs- sowie Domänenverzeichnispartition). Er überwacht (dynamisch) permanent die Gegebenheiten wie z.B., wenn DCs einem Standort hinzugefügt, entfernt oder verschoben werden, die Kosten sich ändern oder wenn ein Domänencontroller nicht erreichbar ist. In diesen Fällen "justiert" der KCC nach, so dass die Replikation weiter reibungslos verläuft.

Falls man nicht möchte, dass der KCC die Replikationstopologie automatisch erstellt, kann man dies abstellen. Das bedeutet aber, dass man selbst für die Replikation des evtl. bestehenden VPNs zuständig ist, und was noch viel wichtiger ist, man bemerkt nicht sofort, wenn ein Replikationsproblem besteht. Zwar beschreibt dieser Artikel, wie man das KCC deaktiviert, aber die Empfehlung ist: Finger weg – der KCC macht seine Arbeit schnell und ordentlich: http://support.microsoft.com/kb/242780/de

ISTG (Intersite Topology Generator)

Der ISTG ist eine Komponente des KCC und für die Verwaltung und Überwachung von standortübergreifenden Replikationsverbindungen verantwortlich. Er ermittelt den jeweiligen Bridgeheadserver eines Standortes (den Domänencontroller, der für die konkrete Replikationsverbindung zwischen zwei Standorten zuständig ist), und falls dieser nicht  mehr zur Verfügung steht, sucht er sich einen neuen. Der erste Domänencontroller eines Standortes bekommt automatisch die Rolle des ISTG zugewiesen – auch wenn weitere DCs dem Standort hinzugefügt werden, behält er diese Funktion. Erst wenn dieser erste DC nicht mehr zur Verfügung steht, wird die Rolle an einen anderen Domänencontroller dieses Standortes vergeben.

In einem bestimmten Intervall (standardmäßig 30 Minuten) informiert der ISTG die anderen DCs des gleichen Standortes, dass er noch vorhanden ist. Das Intervall kann man über folgenden Registry-Schlüssel beeinflussen: "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters"
(Attribut "InterSiteTopologyGenerator").

Falls das Intervall verstreicht und die Information nicht repliziert wurde, geht der KCC davon aus, das dieser DC nicht mehr zur Verfügung steht und bestimmt einen neuen Domänencontroller, der die Rolle des ISTG übernimmt.
Im Active Directory des Windows 2000 Server hatte der ISTG-Algorithmus seine Grenzen und arbeitete ab ca. 300 Standorten nicht mehr effizient, so dass man diesen ISTG-Algorithmus ausschalten und die Definition und Verwaltung von Verbindungen manuell erledigen musste. Bei Windows Server 2003 wurde die Skalierbarkeit erheblich erweitert und nun ist es auch möglich, bei 3.000 Standorten immer noch eine effiziente Replikationstopologie zu ermitteln. 

FRS (File Replication Service)

Der Dateireplikationsdienst ist zuständig für die Replikation der Daten im SYSVOL Verzeichnis eines Domänencontrollers. FRS wird unter Windows 2000 und Windows Server 2003 bis SP1 zudem für die Replikation des verteilten Dateisystems (DFS = Distributed File System) verwendet. An dieser Stelle sei erwähnt, dass sich dieses Verhalten in Windows Server 2003 R2 ändert, dort repliziert DFS sich über sein eigenes Replikationsverfahren.

Die eigentlichen Inhalte von Gruppenrichtlinien werden nicht im Active Directory gespeichert, sondern im Dateisystem eines Domänencontrollers(ADM-Dateien, POL-Dateien, Skripts usw.). In einer Umgebung, in der mehrere Domänencontroller existieren, sorgt FRS dafür, dass die Daten im Active Directory und auch im SYSVOL-Verzeichnis erfolgreich auf alle DCs repliziert werden, damit auch jeder Benutzer sowie Client überall die gleichen Einstellungen erhält – egal von welchem Domänencontroller er angemeldet wird. Der FRS arbeitet so wie das Active Directory nach der Multi-Master-Replikation, so dass Änderungen an jedem Domänencontroller zulässig sind. Anders als bei der Active Directory-Replikation werden die Daten bei FRS standortübergreifend nicht komprimiert, daher kann es bei großen Datenmengen eine Weile dauern, bis alle Daten repliziert worden sind, ebenso wie die Erst-Replikation eines Domänencontroller eine gewisse Zeit in Anspruch nimmt.

FRS speichert Logs, die ggf. bei Problemen behilflich sein können, im Verzeichnis "%Systemroot%\Debug" mit den Namen Ntfrs_0001.log bis Ntfrs_0005.log. Ebenfalls wird ein Log-File erstellt (Ntfrsapi.log), wenn ein Server zum Domänencontroller herauf- oder herabgestuft wird.

FRS hat folgende Inhalts- und Datengrenzen:

• Eine maximale Dateigröße von 20 GB
• Maximal 64 GB an Daten
• Maximal 500.000 Dateien unter dem Replikationsstamm
• Maximal 1.000.000 gleichzeitige Änderungsanforderungen

Ferner hat FRS folgende Topologiegrenzen:

• Maximal 1.000 Replikationspartner
• Maximal 150 Repliken pro Computer

Replikations-Transport-Protokolle

Das Active Directory repliziert standardmäßig über Remoteprozeduraufrufe (Remote Procedure Call = RPC) over Internetprotokoll (IP). Diese Protokolle werden sowohl für die standortinterne als auch die standortübergreifende Replikation verwendet. Für die Sicherheit bei der Übertragung der Daten durch diese Protokolle sorgt einmal die Authentifizierung mit dem Kerberos V5-Authentifizierungsprotokoll und des Weiteren die Datenverschlüsselung. Eine Komprimierung der Daten findet dabei nicht statt. Die standortübergreifende IP-Replikation benutzt standardmäßig Zeitpläne, die sich aber auch ignorieren lassen.

Als weiteres Protokoll kann auch SMTP (Simple Mail Transfer Protocol) verwendet werden. SMTP kann aber NUR standortübergreifend eingesetzt werden und nicht standortintern. Da SMTP kein sicheres Protokoll ist, braucht man ebenfalls eine Organisationszertifizierungsstelle (CA), um die Replikationsinformationen digital signieren und verschlüsseln zu können. Nur so kann sichergestellt werden, dass die gesendeten Daten unverändert und die Echtzeit den Daten auf der Empfängerseite entsprechen. Eine weitere Einschränkung ist, dass man zwar die Schema-, Konfigurations- sowie Anwendungsverzeichnispartition replizieren kann, jedoch nicht die Domänenverzeichnispartition. Aus diesen Gründen wird dieses Verfahren in der Praxis so gut wie nie eingesetzt.

Verwandte Beiträge:

1. Das „Wer mit wem“ in der Active Directory-(intra-site) Replikation
   Die Active Directory-Replikation ist für viele Administratoren ein Buch mit...
2. Active-Directory-Replikation im Detail
   Dieser Artikel soll einen etwas tieferen Einblick in die Replikation...
3. Replikation: Standorte & Standortverknüpfungsbrücken
   In diesem Artikel: Kostendefinitionen bei der Active Directory Replikation (wann und...