Domain Controller aufbauen: Voraussetzungen, Promotion, Abnahme

Install-ADDSForest -DomainName corp.example.com — mehr braucht es nicht, und genau darin liegt das Problem. Ohne weitere Argumente fragt das Cmdlet das Wiederherstellungs-Kennwort laut Dokumentation ohne Bestätigung ab: Ein Tippfehler wird stillschweigend gesetzt und fällt erst auf, wenn der Domain Controller nicht mehr startet. Dieses Modul behandelt die Entscheidungen, die eine Promotion mittrifft und die man später nicht zurücknimmt — den Forestnamen, der spätestens bei einer Fusion kollidiert, die Funktionsebenen, die Ablage samt der Regel gegen ReFS, den zweiten Domain Controller und die vier Nachweise, die aus einer erfolgreichen Installation erst einen abgenommenen Betriebszustand machen.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Was eine Promotion wirklich tut

Einen Domain Controller aufzusetzen ist technisch ein einzelner Befehl. Der Grund, warum diesem Befehl trotzdem eine Planung vorausgeht, ist ein anderer: Er trifft mehrere Entscheidungen gleichzeitig, die sich später nicht oder nur mit erheblichem Aufwand zurücknehmen lassen. Der Name des Forests gehört dazu, die Funktionsebene und das Wiederherstellungs-Kennwort ebenso.

Promotion — Der Vorgang, der aus einem gewöhnlichen Windows-Server einen Domain Controller macht: Er legt die Verzeichnisdatenbank ntds.dit an, richtet die Freigaben SYSVOL und NETLOGON ein, registriert die SRV-Records des DCs im DNS und startet die Verzeichnisdienste.

Der Satz, der dieses Modul trägtEine erfolgreich gemeldete Promotion ist kein Abnahmesignal. Sie sagt nur, dass die Installation durchgelaufen ist. Ob der DC seine Aufgabe erfüllt, zeigt sich erst an vier Nachweisen: DNS-Registrierung, SYSVOL-Bereitstellung, erfolgreiche Anmeldung und — ab dem zweiten DC — funktionierende Replikation. Wer diese Nachweise überspringt, baut auf einem Fundament weiter, das er nie geprüft hat.

Der Name ist die teuerste Entscheidung

Der Name der ersten Domäne ist zugleich der Name des Forests, und ihn nachträglich zu ändern ist zwischen aufwendig und unmöglich. Die Dokumentation gibt dafür ein klares Muster vor: Präfix plus Suffix, etwa corp.contoso.com. Das Suffix ist ein Name, den die Organisation bei einer Internet-Namensvergabestelle registriert hat; das Präfix ist ein neues, im Netz noch unbenutztes Label.

Einwortnamen wie corp: Ausdrücklich nicht verwenden — die Dokumentation rät davon explizit ab.
Unregistrierte Endungen wie .local: Nicht empfohlen. Globale Eindeutigkeit ist nicht garantiert.
Neues Präfix auf registriertem Suffix: Der empfohlene Weg: corp.contoso.com neben dem extern genutzten contoso.com.

Warum das mehr ist als FormalismusNur registrierte Namen sind garantiert weltweit eindeutig. Registriert später eine andere Organisation denselben Namen — oder wird sie durch Fusion oder Zukauf plötzlich Teil derselben Infrastruktur —, können die beiden Umgebungen laut Dokumentation nicht miteinander interagieren. Der Fehler zeigt sich also nicht am Tag der Installation, sondern Jahre später beim Zusammenschluss, und dann ist der Name in jedem Client, jedem Zertifikat und jeder Anwendung verankert.

Voraussetzungen, die man nicht nachholen kann

Zwei Dinge müssen vor dem Befehl stimmen, weil der DC sie im Zuge der Promotion selbst benutzt. Erstens eine feste IP-Adresse: Ein Domain Controller registriert seine Adresse im DNS, und ein wechselnder Wert macht diese Registrierung wertlos. Zweitens die DNS-Einstellung des Servers selbst.

Beim allerersten DC eines neuen Forests existiert die Zone noch nicht, die er gleich befüllen wird. Deshalb installiert man den DNS-Dienst üblicherweise mit — der Schalter -InstallDns erledigt das — und richtet den Server nach der Promotion auf sich selbst als Resolver aus. Beim zweiten DC ist es umgekehrt: Er muss auf einen bereits vorhandenen DC zeigen, sonst findet er die Domäne nicht, der er beitreten soll.

Die Reihenfolge, die Einsteiger stolpern lässtDer erste DC zeigt nach der Promotion auf sich selbst, der zweite vor der Promotion auf den ersten. Wer den zweiten DC vorab auf sich selbst zeigen lässt, bekommt die Meldung, dass keine Domäne gefunden wurde — und sucht den Fehler im Netzwerk, wo er nicht ist.

Vor dem eigentlichen Promotionsbefehl steht außerdem die Installation der Rolle selbst, üblicherweise mit Install-WindowsFeature AD-Domain-Services -IncludeManagementTools. Erst danach steht das Modul ADDSDeployment mit den Promotions-Cmdlets zur Verfügung. Das ist der Grund, warum ein frisch aufgesetzter Server Install-ADDSForest zunächst gar nicht kennt — kein Tippfehler, sondern eine fehlende Rolle.

Trockenlauf vor dem ErnstfallZu jedem Promotions-Cmdlet gibt es ein Test--Gegenstück, etwa Test-ADDSForestInstallation. Es führt dieselben Voraussetzungsprüfungen durch wie die echte Promotion, ohne etwas zu verändern. In einer Umgebung, in der ein Fehlschlag einen Server halb konfiguriert zurücklässt, ist dieser Trockenlauf die billigste Versicherung überhaupt — und er kostet nichts außer einer Minute.

Das DSRM-Kennwort und die stille Falle

DSRM (Directory Services Restore Mode) — Ein spezieller Startmodus des Domain Controllers, in dem die Verzeichnisdienste nicht laufen — damit die Datenbank wiederhergestellt werden kann. Weil dabei keine Domänen-Anmeldung möglich ist, existiert ein eigenes, lokales Administrator-Kennwort: das DSRM-Kennwort, das bei der Promotion gesetzt wird.

Dieses Kennwort braucht man genau dann, wenn ohnehin alles brennt: bei einer autoritativen Wiederherstellung oder wenn der DC nicht mehr normal startet. Genau deshalb ist es das Kennwort, das am zuverlässigsten unauffindbar ist, wenn man es benötigt.

Der dokumentierte FallstrickGibt man -SafeModeAdministratorPassword nicht an, fragt das Cmdlet normalerweise nach dem Kennwort und lässt es bestätigen. Werden aber sonst keine weiteren Argumente übergeben, entfällt laut Dokumentation die Bestätigung — es wird nur einmal abgefragt. Die Doku benennt die Folge ausdrücklich: So kann ein vertipptes Kennwort gesetzt werden. Der Tippfehler fällt niemandem auf, weil das Kennwort im Normalbetrieb nie gebraucht wird. Bemerkt wird er im Wiederherstellungsfall — dem denkbar schlechtesten Moment.

Was daraus folgtDas DSRM-Kennwort gehört bei der Promotion in eine dokumentierte, hinterlegte Form und danach in denselben Prozess wie jedes andere Notfall-Geheimnis: hinterlegt, regelmäßig geprüft, bei Personalwechsel gewechselt. Ein Kennwort, das man nie benutzt, verifiziert sich nicht von selbst.

Funktionsebenen: was sie freischalten, und warum man nach oben plant

Bei der Promotion eines neuen Forests legst du zwei Ebenen fest: -ForestMode und -DomainMode. Sie bestimmen, welche AD-Funktionen zur Verfügung stehen und welche Windows-Server-Versionen als Domain Controller betrieben werden dürfen. Die Empfehlung der Dokumentation ist eindeutig: den höchsten Wert setzen, den die Umgebung tragen kann, um möglichst viele Funktionen nutzen zu können.

Die Regel zwischen den beiden EbenenEine Domänen-Funktionsebene darf höher liegen als die des Forests, aber niemals niedriger. Die Forest-Ebene ist damit der Boden, auf dem alle Domänen stehen — und wer sie zu hoch ansetzt, sperrt ältere Domain Controller dauerhaft aus, statt sie nur zu benachteiligen.

Angehoben wird später mit Set-ADForestMode und Set-ADDomainMode. Die Richtung ist dabei die entscheidende Eigenschaft: Das Anheben ist der vorgesehene Weg, und die Rücknahme ist keine gewöhnliche Betriebshandlung. Behandle die Wahl deshalb als Festlegung, nicht als Einstellung.

Wohin die Daten kommen

Die Promotion legt drei Dinge ab, die sich getrennt platzieren lassen: die Verzeichnisdatenbank (-DatabasePath, üblich C:\Windows\NTDS), die Transaktionsprotokolle (-LogPath) und die Freigabe SYSVOL (-SysvolPath), in der Gruppenrichtlinien-Dateien und Skripte liegen und die zwischen den DCs repliziert wird.

Die Regel, die man einmal liest und nie vergisstVerzeichnisdatenbank, Protokolldateien und SYSVOL gehören laut Dokumentation nicht auf ein Volume, das mit ReFS formatiert ist. Das ist eine harte Vorgabe und keine Empfehlung — und sie fällt gerne dann auf, wenn ein Storage-Team ein neues Datenvolume „modern“ bereitgestellt hat.

Der Befehl und was er der Reihe nach tut

Für den ersten DC eines neuen Forests lautet der Befehl Install-ADDSForest. Ein vollständiges Beispiel aus der Dokumentation setzt Namen, beide Funktionsebenen und die drei Ablagepfade in einem Aufruf:

Install-ADDSForest -DomainName corp.contoso.com -InstallDns -ForestMode <Ebene> -DomainMode <Ebene> -DatabasePath "d:\NTDS" -SysvolPath "d:\SYSVOL" -LogPath "e:\Logs"

Voraussetzungen prüfen — Name, feste IP, Rolle installiert↓DSRM-Kennwort setzen, bestätigt und hinterlegt↓Install-ADDSForest ausführen; der Server startet danach neu↓DNS-Einstellung des DCs auf sich selbst umstellen↓Abnahme: DNS, SYSVOL, Anmeldung

Abnahme ist Teil der Installation

Zum Mitschreiben-CreateDnsDelegation legt in der übergeordneten DNS-Zone einen Verweis auf die neue Zone an. Für einen isolierten Forest ohne übergeordnete Zone ist der Schalter unnötig und schlägt eher fehl, als dass er hilft — ein häufiger Fehlstart, der wie ein Rechteproblem aussieht.

Der zweite Domain Controller

Ein einzelner Domain Controller ist kein Betriebszustand, sondern ein Zwischenstand. Fällt er aus, ist keine Anmeldung mehr möglich, und die Wiederherstellung läuft über eine Sicherung statt über einen zweiten Knoten. Der zweite DC gehört deshalb nicht in ein späteres Projekt, sondern in dieselbe Aufbauphase.

Der Befehl dafür ist Install-ADDSDomainController. Drei Parameter lohnen sich zu kennen: -SiteName ordnet den DC einem Standort zu, -ReplicationSourceDC bestimmt, von welchem DC die Erstbefüllung kommt, und -InstallationMediaPath erlaubt die Installation von Medium — die Erstbefüllung stammt dann aus einer zuvor erzeugten Sicherung statt aus dem Netz.

Wofür die Installation von Medium gedacht istEin neuer DC zieht sich bei der Promotion die gesamte Verzeichnisdatenbank vom Replikationspartner. Über eine schmale Standortverbindung kann das Stunden dauern und die Leitung für alles andere blockieren. -InstallationMediaPath verlagert diesen Transfer auf einen Datenträger. Der Preis: Das Medium ist eine vollständige Kopie des Verzeichnisses und damit ein Objekt, das genauso zu schützen ist wie eine Sicherung.

Global Catalog nicht vergessenEin zusätzlicher DC wird nicht automatisch zum Global Catalog. In einem Forest mit mehreren Domänen ist der Zugriff auf einen GC aber Voraussetzung für die Anmeldung — ein Standort ohne erreichbaren GC hat im Ernstfall einen DC, der niemanden anmelden kann. Bei der Promotion lässt sich die Rolle direkt mitgeben; nachträglich ist sie eine Eigenschaft des Servers und in Sekunden gesetzt. Vergessen wird sie trotzdem regelmäßig, weil in einer Ein-Domänen-Umgebung nichts auffällt und der Fehler erst mit der zweiten Domäne sichtbar wird.

Wenn der Standort unsicher istFür Standorte, deren physische Sicherheit nicht gewährleistet ist — eine Filiale ohne verschlossenen Serverraum —, gibt es den schreibgeschützten Domain Controller (RODC). Er hält eine nur lesbare Kopie und speichert standardmäßig keine Kennwort-Hashes; welche Konten dort zwischengespeichert werden dürfen, wird ausdrücklich freigegeben. Der Gewinn ist begrenzter Schaden bei Diebstahl des Servers. Der Preis: Anwendungen, die schreibend ins Verzeichnis greifen, funktionieren dort nicht ohne Weiteres, und die Einrichtung des ersten RODC im Forest verlangt wiederum Rechte auf Forest-Ebene.

Abnahme: vier Nachweise statt eines Häkchens

Nach dem Neustart folgt der Teil, den die Installationsanleitung nicht abnimmt. Die Prüfkette hat eine Reihenfolge, und die ist kein Zufall: Jede Stufe setzt voraus, dass die vorige trägt. Wer mit der Replikationsprüfung anfängt, bekommt Fehler, deren Ursache eine Stufe tiefer liegt.

DNS — sind die SRV-Records des DCs registriert? dcdiag /test:dns und eine Abfrage auf _ldap._tcp.dc._msdcs.<domäne>↓Freigaben — antworten SYSVOL und NETLOGON? net share auf dem DC zeigt beide↓Anmeldung — meldet sich ein Testkonto an einem Client an, und wird ein GPO verarbeitet?↓Replikation — ab dem zweiten DC: repadmin /replsummary ohne Fehler und ohne wachsende Rückstände

Warum SYSVOL an dritter Stelle stehtFehlen SYSVOL und NETLOGON, meldet sich zwar oft noch jemand an, aber keine Gruppenrichtlinie wird verarbeitet — die Dateien dazu liegen genau in dieser Freigabe. Das Symptom ist tückisch, weil die Anmeldung funktioniert und der Fehler damit lange unbemerkt bleibt. net share ist die schnellste Antwort auf die Frage, ob der DC überhaupt vollständig hochgekommen ist.

Was du dabei mitschreibstJeder dieser vier Nachweise erzeugt eine Ausgabe, und die gehört in die Aufbaudokumentation — nicht als Ritual, sondern weil sie der einzige Bezugspunkt ist, wenn Monate später etwas nicht mehr geht. Wer den Ausgangszustand nicht festgehalten hat, kann später nicht unterscheiden, ob ein Befund eine Abweichung oder schon immer so war. Dazu gehören mindestens: der gewählte Name samt NetBIOS-Kurzform, die gesetzten Funktionsebenen, die Ablagepfade, der Ort des hinterlegten DSRM-Kennworts und die Ausgabe von repadmin /replsummary nach dem zweiten DC.

Ein neuer DC in einem bestehenden Forest: die Schema-Vorbereitung

Bis hierher ging es um den Aufbau von null. Der häufigere Fall im Berufsleben ist der andere: Ein Domain Controller mit einer neueren Windows-Server-Version kommt in einen Forest, der schon steht. Dann ist die Promotion nicht der erste Schritt — vorher muss das Schema die Objektklassen und Attribute kennen, die die neue Version mitbringt.

Adprep — Das Werkzeug, das die Schema- und Domänen-Erweiterungen einer neuen Windows-Server-Version in ein bestehendes Verzeichnis einbringt. adprep /forestprep erweitert forest-weit das Schema, adprep /domainprep bereitet die einzelne Domäne vor.

Führt man adprep nicht vorher separat aus, erledigt der Promotionsvorgang das selbst — und fragt dafür nach Anmeldedaten. Welche das sein müssen, ist der Punkt, der Zeitpläne sprengt.

Die drei Mitgliedschaften, die zusammenkommen müssenUm den ersten Domain Controller einer neuen Windows-Server-Version in einen Forest zu bringen, verlangt die Dokumentation Anmeldedaten eines Kontos, das gleichzeitig Mitglied von Enterprise Admins, Schema Admins und Domain Admins derjenigen Domäne ist, die den Schema-Master hält. Das ist kein gewöhnliches Administrationskonto, und in getrennten Verantwortungsmodellen existiert oft überhaupt keines mit allen drei Mitgliedschaften. Wer das erst im Wartungsfenster merkt, verschiebt den Termin.

Der Zusammenhang zur PartitionWarum ausgerechnet Schema Admins? Weil die Schema-Partition auf jedem DC des Forests nur lesbar liegt und allein auf dem Schema-Master beschreibbar ist. adprep /forestprep ist damit ein Schreibvorgang auf dem einzigen Objekt, das forest-weit wirkt und sich nicht zurücknehmen lässt — die hohe Rechteanforderung ist die Absicherung dieser Einbahnstraße, nicht Bürokratie.

Durchgerechnet: von null auf zwei Domain Controller

Ein neuer Forest für eine Testumgebung

Szenario

Du sollst einen isolierten Forest aufbauen, in dem später Gruppenrichtlinien und Sicherheitsübungen laufen. Zwei Server stehen bereit, das Netz ist vom Produktivnetz getrennt.

Anforderungen

Der Name darf einer späteren Verbindung mit anderen Umgebungen nicht im Weg stehen
Nach dem Aufbau muss die Umgebung einen Ausfall eines Servers überstehen
Jeder Schritt braucht einen beobachtbaren Nachweis

Schritte

Namen wählen: ein neues Präfix auf einem registrierten Suffix, etwa lab.beispiel-firma.de. Kein Einwortname, kein .local — auch im Testforest nicht, denn Testumgebungen überleben ihre Testphase regelmäßig.
DC01 vorbereiten: feste IP setzen, AD-DS-Rolle installieren. DSRM-Kennwort vorher festlegen und hinterlegen, nicht im Prompt improvisieren.
DC01 promoten: Install-ADDSForest mit -InstallDns, beiden Funktionsebenen und expliziten Pfaden. Kein -CreateDnsDelegation, weil es keine übergeordnete Zone gibt.
DC01 abnehmen: DNS-Registrierung prüfen, net share auf SYSVOL und NETLOGON, Testkonto anlegen, Client aufnehmen, Anmeldung und GPO-Verarbeitung beobachten.
DC02 vorbereiten: DNS des Servers auf DC01 zeigen lassen — nicht auf sich selbst. Das ist der Punkt, an dem der zweite DC am häufigsten scheitert.
DC02 promoten: Install-ADDSDomainController mit -SiteName. Danach repadmin /replsummary — erst wenn die Replikation in beide Richtungen fehlerfrei ist, gilt die Umgebung als aufgebaut.

Merksatz: Die Reihenfolge folgt den Abhängigkeiten, nicht der Bequemlichkeit: erst Name, dann Namensauflösung, dann Verzeichnis, dann Redundanz — und nach jedem Schritt ein Nachweis, der ohne Interpretation auskommt.

Prüf dich selbst, bevor es zählt

Kurzcheck

Die Promotion von DC01 meldet Erfolg, der Server ist neu gestartet, ein Testkonto kann sich an einem Client anmelden. Ein Kollege will die Umgebung als fertig abnehmen. Was fehlt mindestens noch?

Nichts — eine erfolgreiche Anmeldung beweist, dass Verzeichnis und DNS funktionieren.
Der Nachweis, dass SYSVOL und NETLOGON bereitstehen, und ein zweiter Domain Controller samt geprüfter Replikation.
Das Anheben der Funktionsebene auf den höchsten verfügbaren Wert, damit alle Funktionen bereitstehen.

Treffer. Richtig. Anmeldung ohne SYSVOL ist ein bekannter Zwischenzustand, und ein einzelner DC ist kein Betriebszustand — beides gehört zur Abnahme.

Damit stehen die Achsen dieses Moduls: Namenswahl als teuerste und langlebigste Entscheidung, die Voraussetzungen rund um feste Adresse und Namensauflösung, das DSRM-Kennwort samt seiner dokumentierten Falle, die Funktionsebenen, die Ablage samt ReFS-Regel, der zweite DC und die Abnahmekette aus vier Nachweisen.

Gleich im CheckIn den folgenden Übungen planst und prüfst du selbst — einmal auch an einer echten Konfigurationsnotiz, in der genau einer der hier behandelten Schutzmechanismen umgangen wird.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität12 Primärquellen · zuletzt geprüft: 2026-09-06