Seit Windows 2000 gibt es nicht mehr die beiden Funktionen BDC (Backup Domain Controller) sowie PDC (Primary Domain Controller), die es zu Zeiten von NT gab. Damals konnten Änderungen nur auf dem PDC ausgeführt werden (Single Master Replikation). Das Active Directory (AD) ab Windows 2000 verhält sich grundlegend anders als Windows NT 4.0-Domänen, denn eine Unterscheidung (ob BDC oder PDC) gibt es in einer Active Directory-Domäne nicht mehr. Vielmehr sind alle Domänencontroller (DC) einer Active Directory-Domäne (fast) gleichberechtigt. Somit können in einer AD-Domäne die Änderungen an Attributen und Objekten die auf einem DC getätigt wurden, unter allen DCs mitgeteilt, sprich repliziert werden (Multimaster-Replikation).  

Nun gibt es Situationen, in denen eine ausschließliche Multimaster-Replikation eher zu Konflikten führen würde.
Das betrifft beispielsweise eine Active Directory-Schema Erweiterung, die aus Gründen der Konsistenz lediglich von einem einzigen Domänencontroller ausgeführt werden sollten (nämlich dem DC, der die Rolle des Schemamasters innehat). Daher findet beim Active Directory zusätzlich zur Multimaster-Replikation für die Verzeichnispartition bzw. Namenskontexte für bestimmte Aufgaben, ein Einzelmaster-Betrieb statt. Denn für spezielle Aufgaben, darf nur ein einziger DC entweder in der Domäne oder Gesamtstruktur, diese ausführen. Aus diesem Grund spricht Microsoft auch von „Flexible Single Master Operations“, kurz FSMO.

Ab Windows 2000 kamen fünf Betriebsmaster hinzu, die eine besondere Rolle in einer Domäne/Gesamtstruktur einnehmen.
Die fünf FSMO-Rollen wären:

1. Schemamaster (existiert nur einmal pro Gesamtstruktur)
2. Domänennamenmaster (existiert nur einmal pro Gesamtstruktur)
3. RID-Master (Relative ID) (existiert nur einmal pro Domäne)
4. PDC-Emulator (existiert nur einmal pro Domäne)
5. Infrastrukturmaster (existiert nur einmal pro Domäne)
6. Des Weiteren existiert je eine Infrastrukturmasterrolle pro Anwendungsverzeichnispartition, wie es z.B. ab Windows Server 2003 die ForestDNSZones und DomainDNSZones darstellt.

Es gibt Vorgaben, was die Aufteilung der FSMO-Rollen auf einem oder mehreren DCs betrifft:

1. Der Schemamaster sowie Domänennamenmaster sollten zusammen auf einem DC liegen (und dieser sollte auch ein GC sein).
2. Der RID-Master sowie PDC-Emulator sollten ebenfalls auf dem gleichen DC liegen.
3. Wenn mehrere Domänen in einer Gesamtstruktur existieren, darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs (GC=Global Catalog) trägt, es sei denn, man deklariert jeden DC dieser Domäne zum GC.
   

   Genauer gesagt, es muß jeder DC einer Domäne auch GC sein, wenn der Infrastrukturmaster dieser Domäne auf einem GC liegt.
   Unabhängig davon, wieviele DCs in anderen Domänen der Gesamtstruktur existieren.
   

   Wenn allerdings jeder Domänencontroller einer Domäne, der Bestandteil einer Gesamtstruktur mit mehreren Domänen ist, auch den globalen Katalog enthält, gibt es keine Arbeit für den Infrastrukturmaster. Der Infrastrukturmaster kann auf einen beliebigen Domänencontroller in dieser Domäne gestellt werden.
   
   Oder wenn die Umgebung aus einem Single-Domänen Forest besteht, dann spielt es auch keine Rolle, ob der DC auf dem der Infrastrukturmaster liegt ebenfalls auch globaler Katalog ist oder nicht.
   
   FSMO placement and optimization on Active Directory domain controllers
   
   
   

   Ansonsten wird auf dem Infrastrukturmaster auf dem der GC aktiviert ist, ständig die EventID 1419 protokolliert.
   Dieser Fehler wird nur dann behoben, wenn der Infrastrukturmaster auf einen DC verschoben wird der kein GC ist oder der GC
   auf einem DC aktiviert wird, der nicht die Rolle des Infrastrukturmasters innehat. Der Fehler wird auch dann nicht mehr
   protokolliert, wenn auf jedem DC einer Domäne (sei es ein Single-Domänen oder Multi-Domänen Forest) der GC aktiviert wurde.
   
   Event ID 1419 Generated on a Domain Controller

    

4. In 99% der Umgebungen ist es empfehlenswert, alle Rollen auf einem DC zu halten.

Man kann alle Rollen auf einen anderen DC im laufenden Betrieb, ohne das die Benutzer dadurch beeinträchtigt werden geschweige denn davon etwas mitbekommen, seit Windows 2000 entweder über die grafische Oberfläche oder in der Kommandozeile mit NTDSUTIL verschieben. Mittels der MMCs lassen sich die FSMO-Rollen in den Snap-Ins Active Directory-Schema, Active Directory-Domänen- und -Vertrauensstellungen sowie Active Directory-Benutzer und -Computer übertragen.

Die Rollen werden aber auch automatisch während dem Herunterstufen des Rolleninhabers auf einen anderen DC übertragen.

Die FSMO-Rollen mit DCPROMO verschieben

Tipp: Es ist empfehlenswert das Übertragen der Rollen in der grafischen Oberfläche direkt von dem zukünftigen Rolleninhaber durchzuführen. Somit ist es nicht notwendig weder in den MMCs noch mit NTDSUTIL zuerst eine Verbindung zum Ziel-DC herzustellen und es sind vor allem weniger "Schritte" notwendig.

Die Besonderheit der Infrastrukturmasterrolle ab Windows Server 2003

Es gibt ab Windows Server 2003 eine Besonderheit was die Rolle des Infrastrukturmasters anbetrifft. Denn mit Windows Server 2003 wurden Anwendungsverzeichnispartitionen eingeführt, wie z.B. im DNS die ForestDNSZones und DomainDNSZones. Ab Windows Server 2003 existiert nämlich zusätzlich je ein Infrastrukturmaster pro Anwendungsverzeichnispartition (1 Infrastrukturmaster für ForestDNSZones und je ein Infrastrukturmaster pro DomainDNSZones).

Das bedeutet für eine Gesamtstruktur mit zehn Domänen in der lediglich die Standard-Anwendungsverzeichnispartition (im DNS) genutzt werden, folgende Aufteilung der FSMO-Rollen:

1. Ein Schemamaster
2. Ein Domänennamenmaster
3. Zehn RID-Master (Relative ID)
4. Zehn PDC-Emulatoren
5. Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
6. Ein Infrastrukturmaster für die Anwendungsverzeichnispartition "ForestDNSZones"
7. Zehn Infrastrukturmaster für die Anwendungsverzeichnispartition "DomainDNSZones"

Es existieren also insgesamt 21 Infrastrukturmaster in der Gesamtstruktur. Leider werden aber die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen beim Übertragen (Rolleninhaber ist online) auf einen anderen DC weder über die GUI noch über NTDSUTIL (NTDSUTIL - Transfer) mit "verschoben". Diese müssen zusätzlich noch händisch auf einen anderen DC übertragen werden. Auch beim übernehmen (Rolleninhaber ist offline, z.B. DC-Crash) der FSMO-Rollen auf einen anderen DC, müssen zusätzlich die Infrastrukturmaster der Anwendungsverzeichnispartitionen händisch übernommen werden.

Die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen "ForestDNSZones und "DomainDNSZones" lassen sich wie folgt auf einen anderen DC verschieben:

1. Unter Windows 2000 und Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren.
2. Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits "on Bord" ist.
3. Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag "ADSI Edit" die Option "Connect to..." aus.
4. Im darauffolgenden Fenster "Connection Settings" ist im Bereich "Connection Point" die Option "Select or type a Distinguished Name or Naming Context" auszuwählen.
5. In dem Feld trägt man dann den Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition ein, um sich mit dieser Verzeichnispartition zu verbinden. Im Fall der "ForestDNSZones" würde der DN so lauten:
   DC=ForestDNSZones,DC=Root-Domäne,DC=TLD
6. Anschließend verbindet man sich noch mit den einzelnen (je nach Anzahl der Domänen) "DomainDNSZones" Partitionen. Der DN lautet wie folgt:
   DC=DomainDNSZones,DC=Domäne,DC=TLD
7. Wenn man nun im ADSIEdit auf der linken Seite die einzelnen Verzeichnispartitionen mit denen man sich verbunden hat erweitert, findet man auf der rechten Seite das Objekt CN=Infrastructure. Mit einem Rechtsklick auf dieses Objekt ruft man die Eigenschaften des Objekts auf und ändert dort den Wert im Attribut fSMORoleOwner.
8. Der Wert im Attribut sieht z.B. so aus:
   CN=NTDS Settings,CN=DCON01,CN=Servers,CN=<Standort>,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de

Existieren evtl. noch selbst erstellte Anwendungsverzeichnispartitionen, so müssen die Infrastrukturmasterrollen dieser Vezeichnispartitionen ebenfalls auf einen anderen DC verschoben werden, wenn der Ursprungsrollenträger aus der Domäne entfernt werden soll oder nicht mehr zur Verfügung steht.

Der folgende Befehl kann dazu verwendet werden, die Verzeichnispartitionen die in der Gesamtstruktur existieren sich anzeigen zu lassen:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne -attr ncname

Möchte man sich lediglich die Anwendungsverzeichnispartitionen die in der Gesamtstruktur existieren anzeigen lassen, so ist das mit diesem Befehl möglich:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne -filter (systemflags=5) -attr ncname

Die Infrastrukturmasterrollen der jeweiligen DomainDNSZones-Partition lässt sich wie folgt herausfinden:
Dsquery * CN=Infrastructure,DC=DomainDNSZones,DC=<die jeweilige Domäne>,DC=TLD -attr fSMORoleOwner

Siehe auch:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen


 

Den Schemamaster in der grafischen Oberfläche online übertragen

Die Rolle des Schemamasters kann innerhalb einer Gesamtstruktur, auf jeden DC egal aus welcher Domäne übertragen werden. Um die Rolle des Schemamasters vom ursprünglichen auf einen anderen Domänencontroller über die grafische Oberfläche zu übertragen, muss zuerst das Schema Snap-In registriert werden. Dazu geht man auf „Start-Ausführen“ und gibt dort folgenden Befehl ein regsvr32 schmmgmt.dll. Danach lässt sich das Schema Snap-In in einer MMC hinzufügen. Das Schema Snap-In erscheint nicht unter „Start-Programme-Verwaltung“ wie die bereits existierenden AD-Snap-Ins.

Die genaue Vorgehensweise ist wie folgt, wozu Schema-Admins Rechte benötigt werden:

1. Unter Start-Ausführen öffnet man mit der Eingabe von MMC eine leere MMC-Konsole.
   
   
2. In der MMC klickt man auf Datei - Snap-In hinzufügen/entfernen...
   
   
3. Unterhalb von Verfügbare Snap-Ins: wählt man das Snap-In Active Directory-Schema aus und klickt auf die Schaltläche Hinzufügen und anschließend auf OK.
   
   
4. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf Active Directory-Schema [FQDN] im Kontextmenü den Eintrag Active Directory-Domänencontroller ändern... auszuwählen.
   
   
5. Es muss der DC ausgewählt werden, auf dem die Schemamasterrolle übertragen werden soll.
   
   Hinweis: Führt man das übertragen der Schemamasterrolle gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.
   
   
6. Mit einem erneuten Rechtsklick auf Active Directory-Schema [FQDN] muss diesmal im Kontextmenü der Eintrag Betriebsmaster... ausgewählt werden.
   
   
7. Im Dialogfenster Schemamaster ändern klickt man auf die Schaltfläche Ändern und bestätigt die nachfolgende Abfrage mit Ja.
   
   
8. Die fehlerfreie Übertragung auf den Ziel-DC ist mit OK zu bestätigen.
   
   
9. Zum Schluss schließt man mit einem Klick auf Schließen das Dialogfenster Schemamaster ändern.

Den Domänennamenmaster in der grafischen Oberfläche online übertragen

Die Rolle des Domänennamenmasters kann innerhalb einer Gesamtstruktur, auf jeden DC egal aus welcher Domäne übertragen werden. Die Rolle des Domänennamenmasters lässt sich vom ursprünlglichen auf einen anderen DC in der MMC Active Directory-Domänen und -Vertrauensstellungen mit Organisations-Admins Rechten übertragen.
Die einzelnen Schritte wären folgende:

1. Zuerst ruft man das Snap-In Active Directory-Domänen und -Vertrauensstellungen unter Start-Programme-Verwaltung auf.
   
   
2. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen [FQDN] die Option Domänencontroller ändern... auszuwählen.
   
   
3. Nun muss der DC ausgewählt werden, auf den die Betriebsmasterrolle übertragen werden soll.
   
   Hinweis: Führt man das übertragen der Domänennamenmasterrolle gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.
   
   
4. Dann ist mit einem Rechtsklick auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen [FQDN] der Eintrag Betriebsmaster... auszuwählen.
   
   
5. Im Dialogfenster Betriebsmaster wird mit einem Klick auf Ändern und bestätigen der nachfolgenden Abfrage mit Ja die Domänennamenmasterrolle auf den angegebenen DC übertragen. 
   
   
6. Mit OK ist die fehlerfreie Übertragung auf den Ziel-DC zu bestätigen.
   
   
7. Zum Schluss schließt man mit einem Klick auf Schließen das Dialogfenster Betriebsmaster.

Wo befinden sich die FSMO-Rollen?

Auf welchem DC die FSMO-Rollen liegen, kann man sich recht einfach mit dem Kommandozeilen-Befehl NETDOM (aus den Windows Support Tools) anzeigen lassen.
Der Befehl dazu lautet: NETDOM QUERY FSMO.

Die etwas aufwändigere Abfrage wäre mit DSQUERY:

dsquery server -hasfsmo schema
dsquery server -hasfsmo name
dsquery server -hasfsmo rid
dsquery server -hasfsmo pdc
dsquery server -hasfsmo infr

Oder mit DCDIAG: DCDIAG /Test:Knowsofroleholders /v


Wer diese Informationen gerne über die grafische Oberfläche erfahren möchte, der kann sich dazu die Windows Support Tools installieren und startet anschließend unter Windows 2000 und Windows Server 2003 das REPLMON. Im nächsten Schritt verbindet man sich mit einem DC und wählt mit einem Rechtsklick auf den NetBIOS-Namen des DCs, die Option Properties aus. Im Reiter FSMO Roles bekommt an dann die oder den Träger der FSMO-Rollen zu sehen.

Weitere Informationen:
Die FSMO-Rollen mit der AD-Powershell verschieben
Reagieren auf Betriebsmasterausfälle
How To Find Servers That Hold Flexible Single Master Operations Roles
How to view and transfer FSMO roles in Windows Server 2003
How to view and transfer FSMO roles in the graphical user interface
Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
How to Find the FSMO Role Owners Using ADSI and WSH

Auf der Seite von Mark Heitbrink http://www.gruppenrichtlinien.de habe ich über die Scripte, die mit der Installation der GPMC mitinstalliert werden, einen Artikel geschrieben.

Ich erläutere, für was die jeweiligen Scripte zu gebrauchen sind.

Hier der Link zum Artikel:

http://www.gruppenrichtlinien.de/index.html?/Scripting/scripte_der_gpmc.htm

Yusuf

Der Small Business Server hat folgende Merkmale:

1. Der SBS erzeugt seine eigene Root - Domäne
2. Ein SBS kann in eine bereits bestehende Active Directory Domäne integriert werden,
   muss dann allerdings zum einen alle FSMO - Rollen übertragen bekommen und zum anderen, muss der globale Katalog (GC) auf dem SBS aktiviert werden:
   How to install Small Business Server 2003 in an existing Active Directory domain
3. Es können keine Anbindungen bzw. Vertrauensstellungen zu anderen Domänen aufgebaut werden
4. Es ist nicht möglich Subdomänen zu erstellen
5. Es können keine 2 SBS in einer Domäne existieren, falls ein weiterer Server z.B. Domänencontroller wegen Redundanz nötig
   ist, dann kann es ein Windows Server 2000/2003 Standard Edition sein oder höher
6. Alle Server-Applikationen müssen auf einem SBS laufen und können nicht getrennt installiert werden wie z.B. den Exchange Server auf
   eine andere Maschine
7. Es sind keine Terminalservices vorhanden, nur Remote Desktop
8. Ein Terminal Server ist nur als zusätzlicher Memberserver möglich, dann allerdings sind weitere Terminal Services CALs nötig
9. Weitere Server können in eine SBS Domäne integriert werden (DCs oder Memberserver)
10. Beim SBS ist es empfehlenswert die Assistenten zu nutzen um etwas zu konfigurieren bzw. einzurichten und ist nicht zu vergleichen wie
    die Standard-Edition
11. Es sind maximal 75 Anwender bzw. Clients in einer SBS Domäne möglich

Haben mehrere Benutzer die gleiche Anforderung, um zum Beispiel auf die gleiche Ressource oder Freigabe zuzugreifen, ist es empfehlenswert den Zugriff der jeweiligen Gruppe zu erteilen und nicht einzelnen Benutzerkonten.
Wann immer eine Maßnahme nicht nur einen Benutzer, sondern mehrere betrifft, bieten sich Gruppen an.
Wenn die Rede von einer Gruppe ist, betrifft das automatisch auch alle als Mitglieder geführten Benutzer.
Das bedeutet, eine Berechtigung die einer Gruppe zugeteilt wurde, gilt automatisch auch für alle Benutzer die ihr als Mitglied angehören.

Das Active Directory kennt dabei zwei Gruppentypen, von denen einer bei der Erstellung einer Gruppe ausgewählt werden muss.
Falls sich die Domäne im einheitlichen Domänenfunktionsmodus befindet (Windows 2000 pur oder Windows Server 2003), ist es möglich eine Umwandlung des Gruppentyps (über den Umweg einer universelle Gruppe, das geht aber nicht wenn die Mitgliedschaftsregeln nicht eingehalten werden können) zu einem späteren Zeitpunkt zu ändern. In beiden Ebenen wird das Verschachteln von Gruppen, zum Beispiel eine globale Gruppe in eine andere globale Gruppe unterstützt, nicht aber in den Domänenfunktionsebenen "Windows 2000 gemischt" sowie "Windows Server 2003 Interim" (Verteilergruppen können auch im mixed Mode geschachtelt werden). Folgende beiden Gruppentypen existieren:

1. Sicherheitsgruppen:
   Sicherheitsgruppen können Berechtigungen auf Active Directory-Objekte (Drucker etc.) oder für das NTFS-Dateisystem erteilt werden.
   Damit entsprechen Sicherheitsgruppen dem Konzept der Gruppen bei Windows NT.
   Des Weiteren ist es möglich, Sicherheitsgruppen als E-Mail Verteilungslisten zu nutzen. 
2. Verteilergruppen:
   Dieser Gruppentyp ist erstmals mit dem Active Directoy von Windows 2000 eingeführt worden.
   Mit diesem Gruppentyp ist es möglich (in Verbindung mit einer E-Mail Applikation wie es z.B. Exchange darstellt), diese als Verteilerliste zu nutzen
   und Nachrichten über die Verteilergruppe an alle ihr angehörenden Mitglieder schicken zu können.
   Der Nachteil dieser Gruppe: Es lassen sich keine Berechtigungen vergeben, wie es bei einer Sicherheitsgruppe der Fall ist.
   Exchangemäßig kann eine Sicherheitsgruppe gleichzeitig auch eine Verteilergruppe sein.

Diese beiden Gruppen erstrecken sich im Active Directory auf einen bestimmten Bereich, den Gruppenbereich.
Microsoft hat das bereits aus Windows NT bekannte Konzept der Gruppen beim Active Directory erweitert, denn NT kennt lediglich lokale und globale Gruppen, bei denen es sich automatisch um Sicherheitsgruppen handelt.
Das Active Directory kennt zusätzlich lokale Domänengruppen sowie universelle Gruppen.

Domänenlokale Gruppen haben folgende Einstellungen:

1. Sie sind in allen Gesamtstruktur- und Domänenfunktionsebenen vorhanden.
2. Sie können nur auf Windows 2000, Windows XP oder Windows Server 2003-Systemen in einer Domäne angewendet werden, natürlich nur, wenn sich die Domäne im einheitlichen Modus (Native) befindet. Wenn sich die Domäne z.B. in der Funktionsebene "Windows 2000 gemischt" befindet, kann eine domänenlokale Gruppe nur auf Domänencontrollern verwendet werden, ähnlich wie eine lokale Gruppe.
   Oder anders ausgedrückt, befindet sich die Domäne nicht im Domänenfunktionsmodus Windows 2000 pur oder Windows Server 2003,
   werden domänenlokale Gruppen nur auf den DCs und nicht auf den Mitgliedsservern angezeigt.
3. Sie können nur auf Systemen in derselben Domäne angewendet werden, in der die Gruppe definiert ist.
   Es ist z.B. nicht möglich, Berechtigungen für Ressourcen die außerhalb der Domäne einer domänenlokalen Gruppe liegen, dieser domänenlokalen Gruppe zuzuweisen.
4. Eine domänenlokale Gruppe kann Mitglieder von globalen Gruppen in derselben Domäne oder einer beliebigen vertrauenswürdigen Domäne, von universellen Gruppen in derselben Gesamtstruktur oder einer beliebigen vertrauenswürdigen Gesamtstruktur sowie von anderen domänenlokalen Gruppen in derselben Domäne umfassen. Oder auch direkt Benutzer aus vertrauten Domänen.

Hinweis: Es ist empfehlenswert, Benutzerkonten nicht direkt zu einer domänenlokalen Gruppe hinzuzufügen. Stattdessen sollten einzelne Benutzer mit gemeinsamen Merkmalen zu einer globalen Gruppe und diese globale Gruppe in eine domänenlokale Gruppe hinzugefügt werden. Auf diese Weise sind domänenlokale Gruppen einfacher zu verwalten.

Universelle Sicherheitsgruppen besitzen folgende Merkmale:

1. Diese Gruppe ist nur in den Domänenfunktionsebenen Windows 2000 pur und Windows Server 2003 vorhanden
   (Universelle Verteilergruppen gibt es auch im nicht einheitlichen Domänenmodus).
2. Sie können Mitglieder sämtlicher Domänen innerhalb der eigenen Gesamtstruktur enthalten, ebenfalls globale Gruppen und andere universelle Gruppen.
3. Universelle Gruppen werden auf globalen Katalogservern (GC) in der Gesamtstruktur gespeichert, in der die Gruppe definiert wurde (incl. aller Mitglieder).
4. Sie können dazu verwendet werden, um Rechte oder Berechtigungen für Ressourcen einer beliebigen Domäne innerhalb einer Gesamtstruktur zuzuweisen, und auch aller vertrauenden Domänen außerhalb der Gesamtstruktur.

Es ist wichtig den Unterschied zwischen Berechtigungen und Rechte zu kennen. Bei Berechtigungen kann man Benutzern eine bestimmte Zugriffsebene auf gemeinsam genutzte Netzwerkressourcen gewähren, zum Beispiel die Fähigkeit, eine Datei zu lesen oder Dokumente für einen bestimmten Drucker zu verwalten. 
Zum Beispiel ist die Fähigkeit, sich lokal an einem Domänencontroller anzumelden, ein Benutzerrecht; genauso die Fähigkeit, Dateien und Ordner zu sichern.

In der Praxis hat sich folgende Verfahrensweise etabliert: Das A - G - DL - P Prinzip.
Accounts go in Global Groups nested in Domain Local Groups that are granted Permissions.
Man fügt ein Benutzerkonto (Account) in eine Globale Gruppe, anschließend in eine dömänenlokale Gruppe und vergibt die gewünschte Berechtigung auf die Ressource. 

Natürlich sollte man heutzutage die Festplatten sowie die Partitionierung dieser auf den Domänencontrollern, zukunftsorientiert aus- bzw. einrichten.

Falls einem dann doch mal die Systempartition C: worauf die Active Directory-Datenbank sowie Logs darauf liegen, knapp wird, ist es möglich die AD-Datenbank samt Logs auf eine andere Partition zu verschieben.

Das Verschieben unter Windows 2000 und Windows Server 2003

Die Active Directory-Datenbank sowie die Log-Dateien können unter Windows 2000 sowie Windows Server 2003 folgendermaßen verschoben werden:

• Zuerst gilt es den Domänencontroller im Modus Verzeichnisdienstwiederherstellung zu starten.
  Der Eintrag erscheint beim Startvorgang des Servers, mit betätigen der F8-Taste.
  
  
• Am Anmeldebildschirm angelangt, muss man sich als Administrator und dem "Kennwort für den Wiederherstellungsmodus" (das während dem Heraufstufen zum DC vergeben wurde) anmelden.
  
  
• Wenn man angemeldet ist gilt es entweder unter Start-Ausühren oder aus einer Kommandozeile (CMD) heraus, dass NTDSUTIL zu starten um in den speziellen Active Directory-Bearbeitungsmodus zu gelangen. Wie bei allen Windows Tools, kann man sich auch hier mit dem Schalter /? eine Hilfe anzeigen lassen
  
  
• An der NTDSUTIL-Eingabeaufforderung gibt man folgendes ein: FILES
  
  
• In der "File Maintenance" - Eingabeaufforderung, kann zwischen zwei Optionen gewählt werden:
  
  
  • Zum Verschieben der Active Directory-Datenbank "NTDS.DIT", kann mit dem Befehl move db to <Laufwerk:\\Zielort> die NTDS.DIT an ihren neuen Zielort (z.B. "D:\NTDS\") verschoben werden.
    
    
  • Zum Verschieben der Active Directory Log Dateien "EDB*.LOG" (mit je 10 MB Größe), tippt man den Befehl move logs to <Laufwerk:\\Zielort> ein.
    Wenn der <Zielort> (bei der Datenbank sowie Logs) Leerzeichen im Verzeichnisnamen enthält, gilt es die Bezeichnung in Anführungszeichen zu setzen.
    
    
• Mit dem Befehl info wird eine Übersicht und der neue Speicherort der Active Drectory-Datenbank sowie Log-Dateien angezeigt.
  
  
• Um die Integrität der NTDS.DIT an dem neuen Speicherort zu überprüfen, gibt man den Befehl integrity ein.
  
  
• Mit der zweimaligen Eingabe von quit gelangt man zur Eingabeaufforderung.
  
  
• Anschließend gilt es noch sicherzustellen, dass die Dateiberechtigung auf NTFS-Ebene für das neue Verzeichnis in der die Active Directory-Datenbank sowie Log-Dateien gespeichert sind stimmen.
  Die vier Gruppen "Administratoren, Ersteller-Besitzer, Lokaler Dienst und System" müssen eingetragen sein und die Rechtevergabe hat folgendermaßen auszusehen:
  
  Administratoren=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Ersteller-Besitzer=Vollzugriff. Als Vererbung ist einzustellen "Nur Unterordner und Dateien".
  SYSTEM=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Lokaler Dienst=Ordner erstellen, Daten anhängen. Als Vererbung ist einzustellen "Dieser Ordner und Unterordner".
  
  Die Berechtigungen sind direkt auf dem neuen Verzeichnis zu setzen und sollten nicht vererbt werden!
  
  
• Nun startet man den Domänencontroller im normalen Modus.

Das Verschieben ab Windows Server 2008

Ab Windows Server 2008 kann die AD-Datenbank sowie die Log-Dateien ohne das der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden muss verschoben werden. Denn eines der Neuerungen ab Windows Server 2008 ist die Möglichkeit des Stoppen und Starten des Dienstes Active Directory-Domänendienste (AD-DS). Die Vorgehensweise wäre wie folgt:

• Im ersten Schritt muss der Dienst Active Directory-Domänendienste in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds gestoppt werden. Zeitgleich werden dann die abhängigen Dienste Dateireplikationsdienst, Kerberos-Schlüsselverteilungsdienst, Standortübergreifender Messagingdienst und DNS-Server ebenfalls mit angehalten.
  
  
• Es gilt zunächst das NTDSUTIL aufzurufen, entweder unter Start-Ausführen oder direkt in der Kommandozeile. 
  
  
• In NTDSUTIL muss anschließend die Active Directory-Instanz aktiviert werden. Dieses ist mit dem Befehl activate instance ntds möglich.
  
  
• Danach wechselt man mit dem Befehl Files in das File maintenance Submenü.
  
  
• In der "File Maintenance" - Eingabeaufforderung, kann zwischen zwei Optionen gewählt werden:
  
  

  • Zum Verschieben der Active Directory-Datenbank "NTDS.DIT", kann mit dem Befehl move db to <Laufwerk:\\Zielort> die NTDS.DIT an ihren neuen Zielort (z.B. "D:\NTDS\") verschoben werden.
    
    
  • Zum Verschieben der Active Directory Log Dateien "EDB*.LOG" (mit je 10 MB Größe), tippt man den Befehl move logs to <Laufwerk:\\Zielort> ein.
    Wenn der <Zielort> (bei der Datenbank sowie Logs) Leerzeichen im Verzeichnisnamen enthält, gilt es die Bezeichnung in Anführungszeichen zu setzen.
    
    
• Mit dem Befehl info wird eine Übersicht und der neue Speicherort der Active Drectory-Datenbank sowie Log-Dateien angezeigt.
  
  
• Um die Integrität der NTDS.DIT an dem neuen Speicherort zu überprüfen, gibt man den Befehl integrity ein.
  
  
• Mit der zweimaligen Eingabe von quit gelangt man zur Eingabeaufforderung.
  
  
• Anschließend gilt es noch sicherzustellen, dass die Dateiberechtigung auf NTFS-Ebene für das neue Verzeichnis in der die Active Directory-Datenbank sowie Log-Dateien gespeichert sind stimmen.
  Die vier Gruppen "Administratoren, Ersteller-Besitzer, Lokaler Dienst und System" müssen eingetragen sein und die Rechtevergabe hat folgendermaßen auszusehen:
  
  Administratoren=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Ersteller-Besitzer=Vollzugriff. Als Vererbung ist einzustellen "Nur Unterordner und Dateien".
  SYSTEM=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Lokaler Dienst=Ordner erstellen, Daten anhängen. Als Vererbung ist einzustellen "Dieser Ordner und Unterordner".
  
  Die Berechtigungen sind direkt auf dem neuen Verzeichnis zu setzen und sollten nicht vererbt werden!
  
  
• Zuletzt startet man den Dienst Active Directory-Domänendienste samt den abhängigen Diensten entweder in der Dienstesteuerung oder in der Kommandozeile mit dem Befehl net start ntds.
  

   

Wichtig: Vor- und nach dem Verschieben der Datenbank sowie Protokolldateien, sollte zwingend eine Datensicherung des System States existieren!
Gerade nach dem Verschieben ist es wichtig eine System State-Sicherung zu tätigen, da bei einem Restore einer älteren Sicherung, der Pfad zur NTDS.DIT nicht mehr stimmt.

 
Weitere Informationen:
Die Active Directory-Datenbank reparieren
Relocating SYSVOL Manually
Reset the File Replication service staging folder to a different logical drive
How To Move the Ntds.dit File or Log Files
When you perform a system state backup on a domain controller that is running Windows Server 2003 with Service Pack 1, Backup may fail
"Directory Services cannot start" error message when you start your Windows-based or SBS-based domain controller