LDAP://Yusufs.Directory.Blog/ - Active Directory|Installation

Warum es ein dedizierter DC sein sollte!

Yusuf Dikmenoglu — Sun, 01 Aug 2010 10:24:05 GMT

Was in größeren und weltweiten AD-Umgebungen für selbstverständlich gehalten wird, sieht in kleineren und mittelständischen Unternehmen (KMUs) ganz anders aus.

Diese Frage wird oft gestellt: Warum sollte der Server ausschließlich als DC betrieben werden und kann der DC nicht weitere Dienste oder Applikationen zur Verfügung stellen?

Die Antwort darauf lautet: Ja, ein DC kann und darf weitere Dienste zur Verfügung stellen. Beispielsweise ist seitens Microsoft auch unterstützt, Applikationen wie z.B. Exchange oder SQL auf einem DC zu installieren. Doch es ist keineswegs empfohlen weitere Dienste oder Applikationen auf einem DC zu betreiben. Die Gründe folgen.

Viele Administratoren bringen an dieser Stelle nun den Einwand, dass der SBS doch das Paradebeispiel dafür ist. Ein SBS muss ein DC und darf nicht ein Mitgliedsserver sein. Des Weiteren existieren doch auch Exchange und SQL auf einem SBS. Die Antwort auf diese Argumentation lautet jedoch: Der SBS ist ein Spezialfall und ist gezielt für die Produktpositionierung so konzipiert worden. Mit dem SBS 2008 (Premium) wurde das entsprechend angepasst, in dem bspw. eine extra Windows Server Lizenz für die SQL Serverinstallation mitgeliefert wird.

Ein Schelm, wer Böses dabei denkt, dass der SBS kein echter Server sei. ;-)

Die Gründe weshalb es empfohlen ist, den Server nur als dedizierten DC zu betreiben und keine anderen Dienste zur Verfügung zu stellen sind:

Performance: Werden auf einem DC weitere Applikationen und Dienste installiert, kostet das Ressourcen. Damit steigt das Risiko, dass wenn sich viele Benutzer zur gleichen Zeit an der Domäne authentisieren, dem DC nicht genügend Ressourcen zur Verfügung stehen um jede Authentisierung eines Benutzers erfolgreich durchzuführen. Wenn intensiv mit AD-Abfragen gearbeitet wird, können die fehlenden Ressourcen den DC unnötig auslasten und von Nachteil sein.
Sicherheit: Werden auf einem DC Applikationen oder Dienste installiert, muss man bei entsprechender Rollentrennung dem Betreuer dieser Applikation bzw. der Dienste Rechte auf dem DC einräumen. Oftmals wird dann der Benutzer in die Gruppe der BuiltIn\Administratoren oder in die Gruppe der Domänen-Admins hinzugefügt, was beides selbstverständlich keineswegs gewünscht ist. Denn zum einen sind das zu viele Rechte die man dem Benutzer einräumt und zum anderen, birgt das Gefahren. Der Benutzer, wenn der DC auch noch der Einzige in der Domäne ist, könnte die Domäne gefährden.

Mit Einführung von Windows Server 2008 und dem RODC hat man die Situation entschärft, was die Sicherheit der AD DS anbetrifft. Der Administrator für die Anwendung kann auf einem RODC lokale Adminrechte erhalten und hat dennoch keine weiteren Rechte auf die AD DS.

Es sollten alle Server hinter Schloss und Riegel stehen und nur Befugten sollte der Zugang erlaubt sein. Doch aus AD-Sicht ist es nicht weiter tragisch wenn „nur“ der Applikationsserver anstatt eines DCs unter dem Schreibtisch steht.
Rollentrennung: Folgt man der Empfehlung und betreibt dedizierte DCs, kann man in einem Problemfall einen DC in einer Umgebung mit mehreren DCs einfach ersetzen. Ist jedoch auf dem DC eine wichtige Applikation installiert, gestaltet sich der Austausch besonders schwierig!
Stabilität: Das Installieren von Applikationen und Diensten gefährdet die Stabilität eines DCs (RWDC und RODC). Denn bereits das Installieren eines zusätzlichen nicht kompatiblen (Drucker?) Treibers kann zu Instabilitäten führen, so dass es regelmäßig zum BSOD (Blue Screen of Death) kommt. Dies kann natürlich auch zum Totalausfall des Active Directories führen, bspw. durch Inkonsistenzen die durch solche Abstürze entstehen. Wenn sich in der Domäne mehrere DCs befinden, kann man einen dedizierten DC im laufenden Betrieb herunterstufen, den Computernamen ändern und anschließend wieder zum DC heraufstufen. Ob das die installierte Applikation auf dem DC verkraftet ist fraglich. Ein installierter Exchange Server verhindert dies sehr wirkungsvoll.

Das sind die Hauptargumente warum es ein dedizierter DC sein sollte. Natürlich ist die Welt da draußen alles andere als rosarot und die Realität in der Praxis sieht anders aus. Man muss selbstverständlich unterscheiden, ob es sich um ein fünf-Mann oder um ein weitweites Unternehmen mit 500.000 Mitarbeitern handelt. In einem fünf Mann Unternehmen ist das Budget für IT-Kosten meist knapp und mit einem dedizierten DC würde man in solch einer Umgebung sicherlich mit Kanonen auf Spatzen schießen.

Daher gilt für Unternehmen die sich aus welchen Gründen auch immer keinen dedizierten DC leisten (können oder wollen), folgende Empfehlung:

Was die Performance des DCs anbetrifft, sollte eine Applikation bzw. Dienst vor dem Einsatz auf einem DC in einer produktiven Umgebung, ausgiebig in einer Testumgebung möglichst realitätsgetreu getestet werden. Das wichtigste dabei ist das Monitoring. Erst wenn die Tests nach mehreren Tagen zufriedenstellende Ergebnisse geliefert haben, sollte man die Applikation oder den Dienst auf dem DC in der produktiven Umgebung installieren. Bei den Tests die als Referenz dienen, sollte man über mehrere Tage die Auslastung des DCs (CPU, RAM, HDD, NIC) zu verschiedenen Zeitpunkten verteilt über den Tag aufzeichnen. Wurde die Applikation bzw. der Dienst auf dem produktiven DC installiert, sollte man die Auslastung des DCs ständig mit der Referenz vergleichen.
Natürlich ist das ein Kraftakt den sich ein Unternehmen mit 5 Angestellten zwei Mal überlegt, ob er diese Tests durchführen soll bzw. kann. Ich kann es aber jedem nur ans Herz legen!
Derjenige der die Applikation bzw. den Dienst auf einem DC mit Domänen-Adminrechten betreut, muss vertrauenswürdig sein. Schließlich kann der Betreuer mit Domänen-Adminrechten der Domäne schaden bis hin zu zerstören! Die Virtualisierung ist eine Möglichkeit, die einem bei der Rollentrennung behilflich sein kann.
Es sollten ausschließlich vertrauenswürdige Applikationen und Dienste die vorher ausgiebig getestet wurden auf einem DC installiert werden. Dabei sollte die Datensicherung mit höchster Priorität sichergestellt sein. Sowohl die tatsächliche Durchführung einer funktionierenden System State Sicherung auf der einen Seite, als auch die Sicherung der Daten auf der anderen Seite sollte stets überprüft werden.

Deshalb lautet die Empfehlung: Wann immer möglich sollte ein dedizierter DC eingesetzt werden! Ist das aus welchen Gründen auch immer nicht möglich, sollten vorher ausreichende Tests und eine regelmäßige Datensicherung durchgeführt werden. Dabei sollte die regelmäßige Überprüfung des Gesundheitszustands des DCs nicht vernachlässigt werden (Eventlog, DCDIAG etc.).

Warum Exchange nicht auf einem DC installiert werden sollte

Das Installieren von Exchange auf einem DC ist zwar seitens Microsoft supportet, es wird jedoch nicht empfohlen!

Die Gründe die zusätzlich zu den oben genannten Punkten gegen das Installieren von Exchange auf einem DC sprechen sind:

Wiederherstellung: Beide Technologien, AD und Exchange erfordern im Falle eine Rücksicherung eine hohe Aufmerksamkeit. Für die Rücksicherung beider Technologien müssen bestimmte Arbeitsschritte durchgeführt werden. Erschwerend kommt dann noch hinzu, dass bei einem Servercrash die Zeit für die Rücksicherung eine umso größere Rolle spielt. Wenn der DC der Einzige in der Domäne ist, dann umso mehr. Deshalb ist es aus Wiederherstellungsgründen einfacher, lediglich eine Technologie rücksichern zu müssen.
Abhängigkeit: Exchange benötigt zwingend ein funktionierendes AD! Wenn auf einem (wo möglich Einzigen?) DC ein Problem besteht, hat das evtl. Auswirkungen auf Exchange. Wenn sich das DC-Problem nicht lösen lässt, steht unter Umständen Exchange nicht zur Verfügung.
Sicherheit: Stellt man den Benutzern Outlook Web Access (OWA) zur Verfügung, hat der Benutzer durch den IIS aus dem Internet per HTTP Zugriff auf den DC. Doch meistens ist das nicht gewünscht, dass ein DC von extern egal über welches Protokoll erreichbar ist.

Der Exchange Administrator ist standardmäßig Mitglied in der Gruppe BuiltIn\Administratoren und ist dadurch Administrator auf den DCs! Das ist natürlich zwecks Rollentrennung und vor allem in größeren Umgebungen mit verteilter Administration nicht erwünscht.
Alle Exchange Dienste werden als LocalSystem ausgeführt, was ein größeres Sicherheitsrisiko darstellt wenn eine Sicherheitslücke entsteht. Existiert z.B. ein Sicherheitsloch im AD das einem Angreifer den Zugriff auf das AD erlaubt, kann dieser auch auf Exchange (und umgekehrt) zugreifen.
Ressourcen: Werden die zur Verfügung stehenden Ressourcen auf dem Exchange Server knapp (CPU, RAM, HDD, NIC), leidet darunter auch der DC. Denn läuft z.B. Exchange aus welchen Gründen auch immer voll, hat nicht nur Exchange ein Problem sondern auch der DC! Oder wenn sich ein Exchange-Dienst aufhängt und somit den ganzen Server auslastet, zieht das auch den DC in Mitleidenschaft so das dieser unter Umständen keine Anfragen mehr beantworten kann.
Neustart: Es kann bis zu zehn Minuten dauern den DC herunterzufahren bzw. neu zu starten. Denn standardmäßig wird der Dienst LSASS.exe in dem das AD ausgeführt wird eher beendet, bevor die Exchange Dienste die vom AD abhängig sind beendet werden. Dadurch kommt es zu mehreren Timeouts und deshalb zu dem langsamen Verhalten. Eine mögliche Abhilfe für dieses Problem ist die Exchange-Dienste (insbesondere den Informationstore) manuell zu stoppen, bevor der DC heruntergefahren oder neu gestartet wird.
DCPROMO: Des Weiteren ist das Ausführen von DCPROMO auf einem Exchange Server nicht supportet! Das bedeutet, wurde Exchange auf einem DC installiert, darf der DC nicht heruntergestuft werden. Zuerst müsste Exchange deinstalliert werden, ehe der DC anschließend heruntergestuft werden kann. Oder wenn Exchange auf einem Mitgliedsserver installiert wurde, darf dieser nicht mit DCPROMO zum DC heraufgestuft werden.

Siehe (unter dem Abschnitt "Directory Server Architecture\Installing Exchange 2010 on Directory Servers"):
Exchange 2010 System Requirements: Exchange 2010 Help
Exchangeabhängigkeit vom GC: Selbst wenn man mehr als einen DC/GC in der Domäne besitzt, wird Exchange immer den DC/GC nutzen, auf dem es installiert ist. Das bedeutet im Umkehrschluss, dass Exchange den Betrieb einstellt, sollte mit der DC Funktion auf dem Server etwas im Argen liegen.

Exchange resident on domain controller that is not a global catalog server >

Fazit: Als Best Practice ist es empfehlenswert einen dedizierten DC zu betreiben und Exchange auf einem Mitgliedsserver anstatt auf einem DC zu installieren. Ist das aus organisatorischen Gründen (Kosten etc.) nicht möglich, ist eine funktionierende Datensicherung neben dem Monitoring das Mindeste das regelmäßig durchgeführt werden sollte! Bei der Rollentrennung und bei der Installation von Exchange ist die Virtualisierung eine hilfreiche Option.

Virtualization Support Wizard
Exchange Server Supportability Matrix

Weitere Informationen:
Wie viele DCs pro Domäne werden benötigt?
Die Besonderheiten eines Small Business Server`s (SBS)
Images als Sicherung?
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Security Considerations for a SQL Server Installation

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Hinweise zu ADPREP

Yusuf Dikmenoglu — Sun, 21 Feb 2010 13:21:44 GMT

Bevor der erste Server, der mit einem neueren Serverbetriebssystem installiert ist als die bereits bestehenden Domänencontroller (DCs) einer Gesamtstruktur, als DC zur Gesamtstruktur hinzugefügt werden kann, muss vorher zwingend mit dem Active Directory Preparation Tool (ADPREP) das Active Directory-Schema aktualisiert werden. Erst nachdem ADPREP ausgeführt wurde, kann der neue Server als DC zur Gesamtstruktur hinzugefügt werden. Dabei muss ADPREP stets von der CD/DVD ausgeführt werden, mit dem der neue Server installiert wurde. Möchte man also einen Windows Server 2008 oder Windows Server 2008 R2 in eine Windows 2000 bzw. Windows Server 2003 Gesamtstruktur hinzufügen, so muss das ADPREP von der Windows Server 2008 bzw. Windows Server 2008 R2 DVD ausgeführt werden.

ADPREP muss aber nur dann ausgeführt werden, wenn der Server mit dem neueren Serverbetriebssystem zum DC gestuft werden soll! Wird der neue Server lediglich als Mitgliedsserver zur Domäne hinzugefügt, so muss das ADPREP nicht ausgeführt werden.

Soll der Server, der mit einem neuerem OS (Operating System = Betriebssystem) installiert ist als die existierenden DCs, zu einer bestehenden Domäne als zusätzlicher DC hinzugefügt werden, muss zuerst ADPREP /FORESTPREP auf dem Schemamaster und anschließend ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster in der Domäne ausgeführt werden, zu der der neue Server als DC hinzugefügt werden soll.

Wird jedoch mit dem neuen Server eine neue Subdomäne in einer bestehenden Gesamtstruktur erstellt, muss lediglich das ADPREP /FORESTPREP ausgeführt werden. Das ADPREP /DOMAINPREP /GPPREP muss und kann in diesem Szenario nicht ausgeführt werden, da es keine zu aktualisierende Domäne gibt. Schließlich wird mit dem neuen DC erst eine (weitere) Subdomäne erstellt.

Weitere Details beschreibt der folgende Artikel: >

Das Active Directory Preparation Tool - ADPREP

Fehler die beim Ausführen von ADPREP auftreten können

Wenn das Ausführen von ADPREP aus welchen Gründen auch immer fehl schlagen sollte, ist es empfehlenswert als erstes immer ins ADPREP-Protokoll zu schauen. Das ADPREP-Log wird im Verzeichnis %windir%\System32\Debug\Adprep\Logs erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
Bevor der erste Server mit neuerem OS als die bereits existierenden DCs, als DC zur Gesamtstruktur hinzugefügt werden kann, muss zuerst das ADPREP /FORESTPREP in der Kommandozeile auf dem Schemamaster ausgeführt werden. Das Benutzerkonto mit dem dieser Befehl ausgeführt wird, muss Mitglied in den Gruppen Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Wenn ADPREP /FORESTPREP auf dem Schemamaster mit den notwendigen Rechten ausgeführt wurde und es trotzdem zu einem Fehler führt, weil ADPREP keinen Kontakt zum Schemamaster herstellen konnte (in seltenen Fällen), sollte der Schemamaster zuerst auf einen anderen DC und erneut zurück verschoben werden. Anschließend ist der Befehl ADPREP /FORESTPREP nochmals auszuführen.
Befindet sich das Benutzerkonto beim ausführen von ADPREP hingegen nicht in den entsprechenden Gruppen, kommt es zu diesem Fehler:

Adprep encountered a Win32 error.
Error code: 0x5 Error message: Access is denied

Das Benutzerkonto muss zum ausführen von ADPREP /FORESTPREP Mitglied in den folgenden Gruppen sein:

- Schema-Admins
- Organisations-Admins
- Domänen-Admin in der Domäne, in der sich der Schemamaster befindet.
Zum ausführen von ADPREP /DOMAINPREP /GPPREP muss das Benutzerkonto Mitglied in der Gruppe Domänen-Admins in der Domäne sein, in der dieser Befehl auf dem Infrastrukturmaster ausgeführt wird.
Kommt es beim ausführen von ADPREP /FORESTPREP zu diesem Fehler:

Es war Adprep nicht möglich, das Schema zu erweitern.

[Status/Folgen]

Der Schemamaster schloss einen Replikationszyklus nach dem letzten Neu-Start nicht ab. Der Schemamaster muss mindestens einen Replikationszyklus, bevor das Schema erweitert werden kann, abschließen.

[Benutzeraktion]

Überprüfen Sie, dass der Schemamaster mit dem Netzwerk verbunden ist, und mit anderen Domäne-Controllern kommunizieren kann…

liegt ein AD-Replikationsproblem vor. Es ist zwingend, dass zuerst das Replikationsproblem behoben wird, bevor das Ausführen von ADPREP erfolgreich durchgeführt werden kann. Einen ersten Ansatz zur Fehlersuche bei der AD-Replikation sollte neben dem Eventlog, auch das Schweizer Messer der AD-Replikation REPADMIN zum Vorschein bringen. Mit ausführen von Repadmin /Showreps bzw. Repadmin /Showrepl auf dem Schemamaster sieht man recht schnell, mit welchen DCs der Schemamaster nicht replizieren kann.

Wenn die DCs identifiziert wurden mit denen der Schemamaster nicht replizieren kann, sollte man versuchen sich per UNC auf die DCs zu verbinden. Bekommt man auf dem Schemamaster mit \\DC-Computername und \\FQDNdesDCs keine Verbindung zu den betroffenen DCs hin, liegt entweder ein Netzwerkproblem, ein DNS Problem, ein gebrochener sicherer Kanal (secure channel) oder ein Zeitunterschied von mindestens fünf Minuten zwischen den DCs vor. Gerade das DNS ist für eine AD-Umgebung von großer Bedeutung! Ein Ping sowohl auf die IP-Adresse als auch auf den Computernamen sollte von und zu den betroffenen DCs erfolgreich sein. Funktioniert ein Ping auf die IP-Adresse nicht, liegt höchstwahrscheinlich ein Netzwerkproblem vor. Es sollte der Weg vom Schemamaster zum betroffenen DC untersucht werden.

Funktioniert hingegen ein Ping auf den Computernamen oder FQDN des DCs nicht, liegt höchstwahrscheinlich ein DNS-Problem vor. In den TCP/IP-Einstellungen des DCs sollte ein zentraler DNS-Server als primärer DNS-Server eingetragen werden. Des Weiteren sollte in der Forward Lookup Zone überprüft werden, ob die SRV-Einträge existieren.
Mit Repadmin /KCC <DC> sollte anschließend die eingehende Replikationstopologie auf den DCs neu berechnet werden.
Auch durch Schemakonflikte kann ADPREP Fehler verursachen. Wurden benutzerdefinierte Schemaänderungen vorgenommen oder Schemaänderungen durch Drittanbieterlösungen durchgeführt die mit einer Schemaaktualisierung durch ADPREP in Konflikt stehen, kann es ebenfalls zu Fehlern kommen. Die Fehler die angezeigt werden können darauf hindeuten, dass der Object Identifier (OID) nicht geändert wurde und somit keine neuen Klassen dem AD-Schema hinzugefügt werden können. Das Konfliktobjekt wird im ADPREP-Protokoll protokolliert. Wenn das Objekt das den Konflikt verursacht hat durch eine Drittanbieterlösung ins AD-Schema hinzugefügt wurde, sollte man sich für eine Lösung des Problems an den Hersteller wenden. Andernfalls sollte man sich an den (kostenpflichtigen) Microsoft Produkt Support Service (MS PSS) wenden.
Ein weiterer Schemakonflikt könnte entstehen, wenn eine Verknüpfungskennung (Link Identifier) für ein Attribut durch eine Drittanbieterlösung bereits vergeben ist und ADPREP beim aktualisieren von bestehenden Attributen oder beim hinzufügen von neuen, dieselbe Verknüpfungskennung ebenfalls vergeben möchte. In diesem Fall sollte der MS PSS kontaktiert werden.
Wenn beim ausführen von ADPREP /FORESTPREP der Fehler Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden erscheint, ist der Schuldige der Virenscanner. Der Echtzeitscanner (On-Access) agiert im Hintergrund als Systemdienst und scannt unsichtbar alle Dateien, Programme und den Arbeitsspeicher. Hat der Echtzeitscanner eine Datei oder ein Verzeichnis im Zugriff worauf ebenfalls beim ausführen von ADPREP /FORESTPREP der Zugriff auf dieselben Dateien oder Verzeichnisse benötigt wird, erscheint diese Fehlermeldung. Wenn dieser Fehler erscheint, muss der Virenscanner deaktiviert und anschließend erneut ADPREP /FORESTPREP ausgeführt werden. Danach kann der Virenscanner aktiviert werden.
Die Fehlermeldung Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden kann auch erscheinen, wenn ADPREP /DOMAINPREP /GPPREP ausgeführt wurde. Dann muss der Virenscanner zuerst deaktiviert und anschließend ADPREP /DOMAINPREP /GPPREP erneut ausgeführt werden. Oder wenn im ADPREP-Protokoll der Fehler Error 0x80070020 (Error_sharing_Violation) protokolliert wird, liegt das ebenso am Virenscanner. Das Deaktivieren des Virenscanners sollte auch in diesem Fall zum Erfolg führen.

Führt das deaktivieren des Virenscanners nicht zum Ziel, könnte es noch an den folgenden Ursachen liegen:

1. Der Registry-Eintrag HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SYSVOL ist nicht vorhanden oder zeigt nicht auf das echte SYSVOL Verzeichnis %windir%\SYSVOL\sysvol. Wenn der Eintrag fehlt, muss ein REG_SZ Eintrag mit dem Pfad zum SYSVOL-Verzeichnis erstellt werden.

2. Die Default Domain Policy (die GUID ist {31B2F340-016D-11D2-945F-00C04FB984F9} ) und Default Domain Controllers Policy (die GUID ist {6AC1786C-016F-11D2-945F-00C04fB984F9} ) fehlen im SYSVOL Verzeichnis.

3. Im SYSVOL Verzeichnis fehlt das SCRIPTS Verzeichnis.
4. Der NTFS-Bereitstellungspunkt und/oder die Bereitstellungspunkte zwischen %windir%\SYSVOL\sysvol\domain und %windir%\SYSVOL existieren nicht (mehr). Sollten die Bereitstellungspunkte fehlen, so können diese mit dem Tool LINKD erneut gesetzt werden.

Die Befehle lauten:

LINKD %windir%\SYSVOL\SYSVOL\<DNS-Domänenname> %windir%\sysvol\domain
LINKD %windir%\SYSVOL\staging areas\<DNS-Domänenname> %windir%\SYSVOL\staging\domain
LINKD %windir%\SYSVOL\sysvol\<FQDN>
Wenn ADPREP /FORESTPREP ausgeführt wurde, müssen die Änderungen zuerst auf den Infrastrukturmaster in der Domäne repliziert werden, in der der neue Server als zusätzlicher DC hinzugefügt werden soll. Erst dann kann mit Domänen-Admin Rechten der Befehl ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster ausgeführt werden. Wurden die Änderungen noch nicht auf den Infrastrukturmaster repliziert oder wenn ADPREP /FORESTPREP nicht ausgeführt wurde, meldet das ADPREP /DOMAINPREP /GPPREP einen Fehler der darauf hinweist, dass die Gesamtstrukturweiten Informationen zuerst aktualisiert werden müssen.
Der Domänenfunktionsmodus muss sich im einheitlichen Modus (Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Ansonsten schlägt das Ausführen von ADPREP /DOMAINPREP /GPPREP fehl!

Domänen- und Gesamtstrukturfunktionsmodus
Wenn ADPREP /RODCPREP mit Organisations- und Domänen-Admin Rechten auf einem Infrastrukturmaster ausgeführt wird, kann es zu folgendem Fehler kommen:

Adprep konnte kein Replikat für Partition DC=ForestDnsZones,DC=Root-Domäne erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

und

Adprep konnte kein Replikat für Partition DC=DomainDnsZones,DC=Domäne,DC=de erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).
Dann muss der Infrastrukturmaster den entsprechenden DNS-Anwendungsverzeichnispartition idealerweise auf den aktuellen Infrastrukturmaster der Domäne verschoben werden. Wie das vonstattengeht, beschreibt der folgende Artikel:

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen

Weitere Informationen:
Die FSMO-Rollen verschieben

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Ein Server kann in einer Subdomäne nicht als zusätzlicher DC heraufgestuft werden

Yusuf Dikmenoglu — Fri, 16 Oct 2009 16:28:33 GMT

Was bis Windows Server 2003 möglich ist, funktioniert ab Windows Server 2008 nicht mehr. Bis Windows Server 2003 ist es möglich einen zusätzlichen Server in einer Subdomäne zum Domänencontroller (DC) zu stufen, ohne das eine Verbindung zwischen der Sub- und Root-Domäne besteht.

Ab Windows Server 2008 ist das nicht mehr möglich. Existiert zum Zeitpunkt des Heraufstufens zwischen der Sub- und Root-Domäne keine (VPN-) Verbindung, kann ein Server nicht als zusätzlicher DC in einer Subdomäne heraufgestuft werden. Dabei spielt es keine Rolle, ob es sich um einen Standalone- oder Mitgliedsserver handelt!

Das Heraufstufen eines zusätzlichen DCs schlägt über die grafische Oberfläche mit dem DCPROMO-Assistenten und in der Kommandozeile (CMD) mit der Unattendedvariante (unbeaufsichtigte DC-Installation) fehl. Es schlägt auch dann fehl, wenn lediglich die DNS- und LDAP-Kommunikation zwischen der Sub- und Root-Domäne gestört ist.>

Die irreführende Fehlermeldung über den DCPROMO-Assistenten lautet wie folgt:

Auch die Fehlermeldung mit der Unattendedvariante in der Kommandozeile ist nicht Aufschlussreich:

Die Ursache für dieses Fehlverhalten ab Windows Server 2008 liegt darin begründet, dass das DCPROMO versucht einen DC aus der Root-Domäne zu erreichen, um Gesamtstrukturinformationen abzurufen. Leider weisen die Fehlermeldungen keineswegs darauf hin. Die Gesamtstrukturinformationen können aber von jedem DC egal aus welcher Domäne geliefert werden.

Nun hat Microsoft reagiert und einen Hotfix veröffentlicht. Der Hotfix kann von diesem KB-Artikel aus angefordert werden:

You cannot install Active Directory Domain Services on a member server that is running Windows Server 2008 in a branch office if the DNS and LDAP communication between the branch office and the forest root domain is blocked

Nach der Installation des Hotfixes ist kein Neustart notwendig.
Anschließend ist das Heraufstufen über die grafische Oberfläche und in der CMD möglich, ohne das eine Verbindung zwischen der Sub- und Root-Domäne existiert.

Das Problem besteht leider auch unter Windows Server 2008 R2!
Auch für die „2008 R2“ Version wird Microsoft einen Hotfix veröffentlichen. Sobald dieser verfügbar ist, wird ein entsprechender Hinweis an dieser Stelle erfolgen.

16.10.2009: Leider gibt es zur Zeit mit der x32Bit Version des Hotfixes ein Problem. Microsoft ist bereits informiert und wird es schnellstmöglich beheben. Die x64 Version funktioniert ohne Probleme. >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der Active Directory Best Practice Analyzer

Yusuf Dikmenoglu — Sun, 08 Mar 2009 09:43:39 GMT

Endlich wird es in Zukunft auch einen Best Practice Analyzer (BPA) für die Active Directory Domain Services (kurz AD DS-BPA) geben. Der BPA der bereits seit längerem für verschiedene Microsoft Produkte existiert (Siehe Abschnitt „Weitere BPAs“), ist für viele Administratoren ein unverzichtbares Werkzeug. Denn mit dem BPA lassen sich Konfigurationsprobleme schnell und einfach aufspüren.

Der BPA für die AD DS-Rolle wird erstmals im Windows Server 2008 R2 eingeführt und hilft dem Administrator dabei, Best Practices bei der Konfiguration der AD DS-Umgebung zu implementieren. Ein oder mehrere DCs lassen sich gegen eine Reihe von vordefinierten Best Practices überprüfen. Der AD DS-BPA erstattet nach der Durchführung Bericht, ob der DC mit den Best Practices kompatibel oder nicht konform ist.

Wenn die AD DS-Umgebung installiert und alles Notwendige konfiguriert wurde, ist es empfehlenswert die durchgeführten Konfigurationen anschließend auf Fehler zu überprüfen. Doch dies ohne den AD DS-BPA zu verifizieren ist gar nicht so einfach und dauert unter Umständen viele Stunden. Aber mit dem neuen AD DS-BPA lassen sich schnell und einfach Konfigurationsfehler und Schwachstellen in der AD DS-Umgebung auf Knopfdruck aufspüren.

Der AD DS-BPA lässt sich zum einen über die grafische Oberfläche und zum anderen, über die Powershell-Kommandozeile ausführen. In der grafischen Oberfläche befindet sich der AD DS-BPA ausschließlich im Server Manager des Windows Server 2008 R2. Der Server Manager ist erstmals auch in den RSAT für den Windows 7 Client enthalten.

Der BPA scannt die AD DS-Rolle so wie sie auf dem Windows Server 2008 R2 DC konfiguriert ist. Nach der Durchführung werden im Server Manager in den Reitern „Nicht Kompatibel“ und „Kompatibel“ die Ergebnisse angezeigt. Ein Ergebnis kann dabei als „Schweregrad“ Fehler, Warnung oder Kompatibel enthalten.

>

Bei Fehlern die im Reiter „Nicht Kompatibel“ angezeigt werden und somit gegen die „Best Practices“ verstoßen (wenn z.B. kein DNS-Server für die Domäne erreichbar ist), werden in der Beschreibung die Punkte „Problem“, „Auswirkung“ und „Lösung“ angezeigt. Durch die genauen Angaben erfährt man, welche Auswirkung das gefundene Problem hat und vor allem, wie es sich lösen lässt.

Die Ergebnisse können gefiltert werden, indem einzelne Berichte für die zukünftigen Durchführungen des BPA vorübergehend ausgeschlossen und zu einem späteren Zeitpunkt erneut einbezogen werden.

Im AD DS-Umfeld steht der BPA unter Windows Server 2008 R2 vorerst für die folgenden Rollen zur Verfügung:>>

Active Directory Certificate Services
Active Directory Domain Services
DNS Server

Der BPA wird über die “Windows Updates” stetig verbessert und erweitert.

Was ist möglich?

Der AD DS-BPA lässt sich über den Server Manager oder über die Powershell, nur auf Windows Server 2008 R2 DCs ausführen.
Der AD DS-BPA kann über den Server Manager oder über die Powershell lokal und remote auf einem Windows Server 2008 R2 Vollinstallation, Windows Server 2008 R2 RODC und Windows Server 2008 R2 Core ausgeführt werden.
Auf einem Windows Server 2008 R2 Core kann lokal der AD DS-BPA ausschließlich über die Powershell ausgeführt werden, da der Server Manager in der grafischen Oberfläche auf einem Windows Server 2008 R2 Core nicht existiert.
Von einem Windows 7 Client worauf das RSAT (Remote Server Administration Tools) installiert ist, kann der AD DS-BPA über den Server Manager oder über die Powershell remote auf einem Windows Server 2008 R2 Vollinstallation oder Windows Server 2008 R2 Core ausgeführt werden.
Nur über die Powershell können mehrere Rollen zur gleichen Zeit überprüft werden (z.B. die AD DS- und DNS-Rolle).

Was ist nicht möglich?

Der Server Manager vom Windows Server 2008 R2, worin sich der AD DS-BPA befindet, lässt sich nicht auf Windows 2000, Windows Server 2003/2003 R2 oder Windows Server 2008 installieren.
Der AD DS-BPA lässt sich nicht über den Server Manager remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.
Der AD DS-BPA lässt sich nicht über die Powershell remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.

Wie wird der AD DS-BPA im Server Manager installiert?

>>>

Sobald auf einem Windows Server 2008 R2 Vollinstallation die AD DS-Rolle installiert und dieser zum Domänencontroller gestuft wird, steht der AD DS-BPA automatisch im Server Manager zur Verfügung. Es ist auch nicht notwendig weitere Komponenten zu installieren um den AD DS-BPA zu nutzen.

Auf einem Windows Server 2008 R2 Core kann der AD DS-BPA lokal ausschließlich über die Powershell ausgeführt werden.

Die Bestandteile des AD DS-BPA

Der Server-Manager im Windows Server 2008 R2 beinhaltet eine Engine mit dem der AD DS-BPA ausgeführt wird. Dabei besteht der AD DS-BPA aus den folgenden Komponenten:

AD DS-BPA PowerShell Skript: Das Skript sammelt AD DS-Konfigurationsdaten und speichert sie in ein XML-Dokument.
XML-Schema: Das Schema definiert das Format des XML-Dokuments, das vom AD DS-BPA PowerShell Skript erzeugt wurde.
AD DS-BPA Regeln: Die Regeln definieren die Best Practice-Konfiguration einer AD DS Umgebung.
AD DS-BPA Leitfaden: Diese Informationen helfen dem Administrator ihre AD DS-Umgebung entsprechend den Best Practices zu konfigurieren.

Die Funktionsweise des AD DS-BPA

Wenn der AD DS-BPA auf einem DC ausgeführt wird, werden die folgenden Schritte durchgeführt:

Die BPA Engine sammelt in der bestehenden AD DS-Umgebung mit dem „AD DS-BPA Powershell Skript“ Informationen über die AD DS-Konfiguration und speichert sie in ein XML-Dokument.
Danach wird das XML-Dokument gegen das „XML-Schema“ validiert.
Nach dem Anwenden der „AD DS-BPA Regeln“ auf das XML-Dokument wird anschließend ein Bericht anhand des „AD DS-BPA Leitfaden“ erstellt.

Den AD DS-BPA lokal in der grafischen Oberfläche ausführen

Der AD DS-BPA lässt sich mit der Maus im Server Manager eines Windows Server 2008 R2 DCs Vollinstallation ausführen. Dort findet man ihn nach Auswahl der Rolle Active Directoy-Domänendienste in der Zusammenfassung.

Das Ausführen des AD DS-BPA lokal auf einem Windows Server 2008 R2 DC Vollinstallation, in der AD-Powershell

In der Powershell-Kommandozeile lässt sich der AD DS-BPA ebenfalls ausführen.

Als erstes gilt es das Server Manager-Modul mit dem folgenden Befehl in die Powershell-Sitzung zu importieren.
Import-Module ServerManager
Im zweiten Schritt muss das BPA-Modul mit diesem Befehl importiert werden.
Import-Module BestPractices
Mit diesem Befehl werden alle verfügbaren BPAs aufgelistet.
Get-BPAModel
Nach der Durchführung des AD DS-BPA werden die Ergebnisse mit diesem Befehl angezeigt.
Get-BPAResult Microsoft/Windows/DirectoryServices
Die AD DS-Rolle wird mit diesem Befehl überprüft.
Invoke-BPAModel Microsoft/Windows/DirectoryServices
Einzelne Ergebnisse werden mit diesem Befehl ausgeschlossen bzw. erneut einbezogen.
Set-BPAResult

Den AD DS-BPA remote im Server Manager ausführen

Mit dem Server Manager lässt sich nun auch unter Windows Server 2008 R2 wie es bei MMCs üblich ist, remote eine Verbindung zu anderen Servern aufbauen. Das war vor Windows Server 2008 R2 nicht möglich. Der Server Manager steht unter Windows Server 2008 R2 sowie auf dem Windows 7 Client nach dem Installieren der RSAT zur Verfügung.

Doch bevor man sich mit dem Server Manager zu einem anderen DC verbinden kann, muss der zu verwaltende DC dies vorher zulassen. Das Zulassen für die Remoteverwaltung kann ebenfalls im Server Manager erfolgen. Die notwendigen Einstellungen werden bei aktivierter Windows-Firewall automatisch vorgenommen.

Über die Powershell muss auf dem zu verwaltenden DC zuerst der Befehl set-executionPolicy -executionPolicy remotesigned ausgeführt werden. Alle dazu benötigten Windows-Firewalleinstellungen werden durch diesen Befehl Configure-SMRemoting.ps1 -force -enable vorgenommen.

Anschließend lässt sich die AD DS-Rolle auf einem beschreibbaren Windows Server 2008 R2 DC, Windows Server 2008 R2 RODC oder Windows Server 2008 R2 Core DC von der Ferne aus überprüfen.

Den AD DS-BPA lokal auf einem Windows Server 2008 R2 Core DC ausführen

Ein lokales Ausführen des AD DS-BPA auf einem Windows Server 2008 R2 Core DC ist nur über die Powershell möglich. Die Powershell ist jedoch standardmäßig nicht installiert. Dazu müssen die folgenden Features installiert werden:

start /w ocsetup NetFx3-ServerCore
start /w ocsetup ServerCore-WOW64
start /w ocsetup MicrosoftWindowsPowerShell
start /w ocsetup MicrosoftWindowsPowerShell-WOW64
start /w ocsetup ActiveDirectory-PowerShell

Achtung: Die Featurenamen sind case sensitive!

Nach der Installation der Features, lässt sich die Powershell aus dem Verzeichnis %windir%\system32\windowspowershell\v1.0 mit dem Befehl powershell aufrufen. Anschließend gilt es die folgenden Powershell-Module zu laden:

import-module activedirectory
import-module servermanager
import-module bestpractices

Überprüfen lässt sich danach die AD DS-Rolle mit diesem Befehl:
Get-WindowsFeature AD-Domain-Services | invoke-bpamodel

Die Ergebnisse nach der Durchführung des AD DS-BPAs lassen sich mit diesem Befehl anzeigen:
Get-WindowsFeature AD-Domain-Services | get-bparesult >

Den AD DS-BPA remote auf einem Windows Server 2008 R2 Core DC ausführen

Bevor man den AD DS-BPA von der Ferne aus über den Server Manager oder über die AD-Powershell auf einem Windows Server 2008 R2 Core ausführen kann, muss zuerst auf dem Server Core die Fernadministration erlaubt werden. Mit dem folgenden Befehl werden die entsprechenden Konfigurationen in der Windows-Firewall vorgenommen: winrm quickconfig.

Anschließend kann man mit dem Server Manager oder über die Powershell von einem Windows Server 2008 R2 oder von einem Windows 7 Client (mit installierten RSAT) remote den AD DS-BPA auf einem Windows Server 2008 R2 Core DC ausführen.

Weitere BPAs für verschiedene Microsoft Produkte

Für Gruppenrichtlinien, Exchange, ISA, SQL und einige mehr gibt es den BPA schon seit längerer Zeit.

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Yusuf Dikmenoglu — Sun, 18 Jan 2009 11:07:24 GMT

Microsoft veröffentlicht im Herbst 2009 sein nächstes Serverbetriebssystem namens Windows Server 2008 R2. Das Minor Release wird ausschließlich in der x64-Bit Version und nicht mehr wie bisher in der 32-Bit Version erscheinen.

Ein Highlight-Feature im neuen Serverbetriebssystem stellt der Active Directory-Papierkorb dar, mit dem gelöschte Objekte samt allen Informationen (inklusive der Backlinks, wie z.B. die Gruppenmitgliedschaften eines Benutzers) wiederhergestellt werden können. Somit hat ein versehentliches löschen von Active Directory-Objekten in den Active Directory Domain Services (AD DS) und Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) keine weiteren Folgen. Weder entsteht bei der Wiederherstellung ein Verlust von Informationen, noch muss dafür der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden.

Die Voraussetzung um dieses Feature nutzen zu können, ist der Gesamtstrukturfunktionsmodus Windows Server 2008 R2. Das bedeutet, alle Domänencontroller (DC) in allen Domänen einer Gesamtstruktur müssen unter Windows Server 2008 R2 betrieben werden.

>>>

Was ist möglich

Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller zu einer Windows 2000 32bit Domäne hinzugefügt werden. >
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller einer Windows Server 2003 bzw. Windows Server 2003 R2 Domäne hinzugefügt werden. Dabei können die bestehenden DCs sowohl unter einem 32bit, 64bit als auch iA64 Serverbetriebssystem betrieben werden.
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller einer Windows Server 2008 Domäne hinzugefügt werden. Die bereits existierenden DCs können ebenfalls unter 32bit, 64bit oder iA64 laufen.
Ein Windows Server 2003 ab SP2 64bit DC oder Windows Server 2003 R2 mit SP2 64bit DC kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
Ein 64bit Windows Server 2008 DC kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
Ein 64bit Windows Server 2008 Core DC kann per Inplace-Update auf einen Windows Server 2008 R2 Core aktualisiert werden.

Hinweis 1: Auch wenn die Mindestvoraussetzung für ein Inplace-Update ein Windows Server 2003 SP2 ist, sollte das System natürlich vor dem Update auf dem aktuellen Service Pack- sowie Patch-Stand sein. Wobei es ohnehin ratsam wäre, die Domänenaktualisierung durch einen zusätzlichen DC durchzuführen.

Hinweis 2: Vor einem Inplace-Update muss überprüft werden, ob auf dem DC die installierten Applikationen auch weiterhin unter Windows Server 2008 R2 noch funktionieren. Ein Telefonat mit dem Hersteller der Applikation sollte das schnell klären.

>>>>>>>>

Was ist nicht möglich

>>>>>>>>

Ein Inplace-Update von Windows NT auf Windows Server 2008 R2 wird nicht unterstützt. Es müsste zuerst ein Inplace-Update des NT-PDCs auf Windows Server 2003 SP1/SP2/2003 R2 und anschließend auf Windows Server 2008 R2 durchgeführt werden. Oder man migriert mit ADMT in eine Windows Server 2008 R2 Domäne.

Durch die Änderung des Secure Channel (die Option "Secure channel: Require strong (Windows 2000 or later) session key" wurde nun mit Windwos Server 2008 R2 hard coded und lässt sich nicht mehr abschwächen wie es noch unter Windows Server 2008 möglich ist) zugunsten der Sicherheit ist es nicht mal möglich, Windows NT Clients sowie NT Mitgliedsserver in einer Windows Server 2008 R2 Domäne zu betreiben! Des Weiteren kann auch keine Vertrauensstellung zwischen einer Windows Server 2008 R2 und einer Windows NT Domäne erstellt werden.
Ein DC älter als ein Windows Server 2003 SP2 x64-System, kann nicht per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
Ein Inplace-Update von Windows Server 2003 SP1/SP2/2003 R2 x64 oder Windows Server 2008 x64 Vollinstallation (kein Server Core), ist auf den Windows Server 2008 R2 Core nicht möglich.
Ein Inplace-Update eines x64 Windows Server 2008 Core DCs kann nicht auf Windows Server 2008 R2 Vollinstallation durchgeführt werden.

Windows Server 2008 Core
Ein Cross-Update von einem x86 auf x64 System wird nicht unterstützt. Ebenso wenig wie von einem iA64 auf x64 System. Das bedeutet, es ist nicht möglich auf einem 32bit Windows Server 2003 SP1/SP2/2003 R2/2008 DC eine Windows Server 2008 R2 DVD einzulegen, um das System per Inplace-Update zu aktualisieren.
Ein Cross-Update auf eine andere Betriebssystem-Sprache wird nicht unterstützt. Als Beispiel: Auf einem deutschen Windows Server 2003 SP2 x64 DC wird die englische Windows Server 2008 R2 DVD eingelegt um den DC, auf einen englischen Windows Server 2008 R2 DC zu aktualisieren.

Die Voraussetzungen für eine Windows 2000/2003/2003 R2/2008 Gesamtstruktur, damit der erste Windows Server 2008 R2 DC hinzugefügt werden kann

Die Domäne in der man den Windows Server 2008 R2 DC hinzufügen möchte, muss sich im einheitlichen Domänenfunktionsmodus (entweder Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Denn wenn sich die Domäne nicht im einheitlichen Domänenfunktionsmodus befindet, lässt sich der Befehl Adprep /Domainprep /Gpprep nicht ausführen. In welchem Modus sich der Gesamtstrukturfunktionsmodus befindet, spielt dabei keine Rolle.
Ist jedoch der Einsatz eines Windows Server 2008 oder Windows Server 2008 R2 RODCs in der Gesamtstruktur geplant, so ist das erst ab der Gesamtstrukturfunktionsebene Windows Server 2003 möglich. Des Weiteren muss sich bereits ein Windows Server 2008 DC oder Windows Server 2008 R2 DC in der Domäne befinden, in der man den RODC hinzufügen möchte.
Alle Domänencontroller in der Gesamtstruktur sollten sich mindestens auf Windows 2000 Server mit Service Pack 4 oder höher befinden.

Schritt für Schritt-Anleitung für eine 32bit oder x64 Windows 2000/2003/2003 R2/2008 Gesamtstruktur, damit der erste Windows Server 2008 R2 DC hinzugefügt werden kann

Zuerst muss das Active Directory Preparation Tool (kurz ADPREP), das sich auf der Windows Server 2008 R2 DVD im Verzeichnis <DVD-Laufwerk>:\Support\Adprep befindet, mit dem Parameter /Forestprep auf dem Schema-Master ausgeführt werden. Allerdings befinden sich im Adprep-Verzeichnis zwei ADPREP-Dateien. Eine „Adprep.exe“ für x64-DCs und eine „Adprep32.exe“ für 32bit-DCs. Mit ausführen von Adprep32 /Forestprep auf einem 32bit Schema-Master, wird die Gesamtstruktur auf Windows Server 2008 R2 aktualisiert. Befindet sich der Schema-Master auf einem x64 DC, so lautet der Befehl Adprep /Forestprep.

Hinweis: Im weiteren Verlauf des Artikels wird die x32Bit Version des Adpreps angegeben, da sicherlich in den meisten Unternehmen noch hauptsächlich 32bit DCs existieren.

Der Parameter /Forestprep muss und kann nur ein einziges Mal in der Gesamtstruktur ausgeführt werden. Dabei muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied der folgenden drei Gruppen sein:

- Organisations-Admins
- Schema-Admins
- Domänen-Admins in der Domäne, in der der Schema-Master Mitglied ist
Ruft man das Adprep32 /Forestprep nicht auf dem Schema-Master auf, bringt das Tool den Hinweis, dass die Gesamtstrukturaktualisierung nur auf dem Schema-Master durchgeführt werden kann und bricht den Vorgang ab. Microsoft empfiehlt das Verzeichnis „Adprep“ (mit dem kompletten Inhalt!) vorher auf den DC zu kopieren, um z.B. Lesefehler des DVD-Laufwerks während der Ausführung von Adprep zu vermeiden.

An error occurs when you run the ADPREP/FORESTPREP command on a Windows Server 2003-based or Windows Server 2008-based computer: "An attribute with the same link identifier already exists"
Das Adprep32 /Forestprep aktualisiert die Gesamtstruktur auf Windows Server 2008 R2, in dem neue Attribute sowie Klassen dem Schema hinzugefügt bzw. bestehende (z.B. die Berechtigungen) geändert werden. Nach dem Aufruf von Adprep32 /Forestprep werden abhängig von der Schema-Version die LDF-Dateien, die zur Schema-Aktualisierung benötigt werden, aus dem Verzeichnis „Support\Adprep“ auf dem DC in das Verzeichnis „%windir%\system32“ kopiert.

In einer Windows 2000 Gesamtstruktur werden die LDF-Dateien ab sch14.ldf, in einer Windows Server 2003 ab sch31.ldf, in einer Windows Server 2003 R2 ab sch32.ldf und in einer Windows Server 2008 Umgebung ab sch45.ldf bis zur sch47.ldf in das Schema importiert. Das Schema wird somit auf die Version 47 aktualisiert.

Die Schema-Versionen sind (in Dezimal):

- Schema-Version 13 = Windows 2000 RTM mit allen Service Packs
- Schema-Version 30 = Windows Server 2003 RTM mit allen Service Packs
- Schema-Version 31 = Windows Server 2003 R2 RTM mit allen Service Packs
- Schema-Version 44 = Windows Server 2008 RTM mit allen Service Packs
- Schema-Version 47 = Windows Server 2008 R2 mit allen Service Packs

Die Schema-Version kann man sich auf jedem DC in der Gesamtstruktur zum einen in der Registry in dem folgenden Pfad ansehen:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>
Zum anderen lässt sich im Attribut objectVersion, das sich in den Eigenschaften der Schema-Partition CN=Schema,CN=Configuration,DC=<Root-Domäne>,DC=<TLD> befindet, die Schemaversion anzeigen (z.B. mit ADSIEdit.msc oder LDP.exe).

Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Wenn das Adprep32 /Forestprep durchgeführt wurde, wird in der Konfigurationspartition der Container CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=<Root-Domäne> erstellt. Der Container selbst bleibt leer. Das Attribut Revision in den Eigenschaften des Containers CN=ActiveDirectoryUpdate erhält den Wert 5. Danach sollte sichergestellt werden, dass sich dieser Container zuerst auf alle DCs der Gesamtstruktur repliziert, um dann den nächsten Schritt mit Adprep durchzuführen.

In erster Linie sollten die DC`s der einzelnen Domänen die Aktualisierung empfangen haben, die die FSMO-Rolle des Infrastruktur-Master innehaben. Dazu gilt es den nächsten Punkt zu beachten.

Hinweis für Windows Server 2008 Umgebungen: Falls schon ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne besteht oder es sich um eine reine Windows Server 2008 Umgebung handelt, existiert bereits der Container CN=ActiveDirectoryUpdate. Das Attribut Revision enthält dagegen als Wert 2. Wird nun das Adprep32 /Forestprep von der Windows Server 2008 R2 DVD ausgeführt, wird der Wert auf 5 geändert.

Hinweis: Im Gegensatz zu Windows Server 2008 Zeiten kann nun auch auf einem deutschen Schemamaster das ADPREP von einer englischen Windows Server 2008 R2 DVD ausgeführt werden. Zu Zeiten Windows Server 2008 gab es an dieser Stelle ein Sprach-Problem und nach dem Ausführen von ADPREP passierte einfach nichts, es erschien noch nicht einmal eine Fehlermeldung. Aber: Existiert ein englischer Schemamaster und man führt das ADPREP von einer deutschen Windows Server 2008 R2 DVD aus, besteht der Fehler weiterhin. Der Cursor blinkt in der nächsten Zeile ohne das irgendetwas passiert. Besteht ein englischer Schemamaster, kann man entweder den Schemamaster auf einen deutschen DC verschieben und danach das ADPREP von einer deutschen DVD ausführen oder man führt das ADPREP gleich von einer englischen DVD aus!
ADPREP "multi-language"
Im zweiten Schritt muss das Adprep32 mit den Parametern /Domainprep /Gpprep auf dem Infrastruktur-Master in der Domäne, in der man den Windows Server 2008 R2 als DC hinzufügen möchte, ausgeführt werden. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied der Sicherheitsgruppe Domänen-Admins sein. Mit Ausführen von /Domainprep /Gpprep wird die Domäne auf Windows Server 2008 R2 aktualisiert. Der Parameter /Domainprep bewirkt, dass neue Objekte erstellt sowie die ACLs an diversen Objekten in der Domänenpartition geändert werden. Der Parameter /Gpprep sorgt dafür, dass die Berechtigungen der Gruppenrichtlinienobjekte die sich im Sysvol-Verzeichnis befinden, angepasst werden. Führt man diesen Befehl aus, noch bevor die Gesamtstrukturaktualisierung auf den Infrastruktur-Master repliziert wurde, bricht der Vorgang ab. Dieser bricht auch dann ab, wenn der Befehl nicht auf dem Infrastruktur-Master ausgeführt wird. Durch Ausführen dieses Befehls wird der folgende Container in der Domänenpartition erstellt: CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=<Domäne>

Auch dieser Container bleibt leer. Das Attribut Revision das sich in den Eigenschaften des Containers CN=ActiveDirectoryUpdate befindet, bekommt ebenfalls den Wert 5. Es ist möglich zuerst das Adprep lediglich mit dem Parameter /Domainprep auszuführen und zu einem späteren Zeitpunkt die Berechtigungen der GPOs, mit Adprep /Domainprep /Gpprep zu aktualisieren. Empfehlenswert ist jedoch, beide Parameter in einem Schritt durchzuführen.

Hinweis für Windows Server 2008 Umgebungen: Wenn sich aber bereits ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne befindet oder es sich um eine reine Windows Server 2008 Umgebung handelt, besteht bereits der Container CN=ActiveDirectoryUpdate in der Domänenpartition. Der Wert im Attribut Revision wird dann von 3 auf 5 geändert. In den Umgebungen wo bereits ein Windows Server 2008 DC existiert, ist es auch nicht notwendig den Parameter /Gpprep auszuführen, da bereits die Berechtigungen der GPOs im Sysvol-Verzeichnis angepasst wurden. Das gilt aber nur für die Umgebungen, in denen bereits beim hinzufügen des zusätzlichen Windows Server 2008 DCs der Parameter /Gpprep mit angegeben wurde. In einer Windows Server 2008 Domäne ist der Parameter /Gpprep ohnehin nicht notwendig. Es ist aber nicht weiter tragisch wenn der Parameter doch mit angegeben werden sollte, denn der Assistent bringt lediglich den Hinweis, dass die Berechtigungen der GPOs bereits angepasst wurden.
Wenn der Einsatz eines Read-Only Domain Controllers (RODC) in irgendeiner Domäne der Gesamtstruktur geplant ist, dann ist das Adprep32 mit dem Parameter /Rodcprep lediglich einmalig aufzurufen. Der DC, auf dem dieser Befehl ausgeführt wird, muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen dieses Befehls werden die einzelnen Infrastruktur-Master der Domänen kontaktiert, um die Berechtigungen (Security Descriptor, SD) der Domänen- sowie Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.

Es reicht völlig aus, diesen Befehl erst vor dem Hinzufügen des ersten RODC`s in der Gesamtstruktur auszuführen. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied in der Sicherheitsgruppe Organisations-Admins sein. Nach Ausführung von /Rodcprep wird der folgende Container, der ebenfalls leer bleibt, erstellt:
CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<Root-Domäne>.

Das Attribut Revision in den Eigenschaften des Containers, erhält als Wert 2.

Hinweis für Windows Server 2008 Umgebungen: Existiert bereits ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne oder handelt es sich um eine reine Windows Server 2008 Umgebung, so kann ein Windows Server 2008 R2 als RODC zur Domäne hinzugefügt werden. Es ist nicht unbedingt notwendig, dass bereits ein Windows Server 2008 R2 DC in der Domäne besteht um einen Windows 2008 R2 als RODC zur Domäne hinzuzufügen. Denn die Voraussetzungen um einen RODC zur Domäne hinzuzufügen sind schließlich, dass sich der Gesamtstrukturfunktionsmodus mindestens auf „Windows Server 2003“ befindet, sich bereits ein Windows Server 2008 DC in der Domäne befindet und das Adprep32 /Rodcprep ausgeführt wurde.

Read-Only Domain Controller (RODC)
Die Installation eines RODC
Wird eine neue Gesamtstruktur unter Windows Server 2008 R2 erstellt, so ist das Ausführen von Adprep/Adprep32 keineswegs notwendig. Weder der Parameter /Forestprep, noch /Domainprep /Gpprep oder /Rodcprep müssen angewendet werden.
Es wird bei jedem Ausführen von Adprep im Verzeichnis %Systemroot%\Debug\Adprep\Logs ein Ordner erstellt, dass als Namen das aktuelle Datum sowie die Uhrzeit erhält. Darin befindet sich (neben anderen) das Adprep-Protokoll mit dem Namen ADPrep.log, welches einen detaillierten Bericht zum Vorgang liefert. Wenn Adprep abbrechen oder einen Fehler melden sollte, ist dieses Protokoll bei der Fehlersuche hilfreich.

Debug Protokollierung
Nach der Domänenaktualisierung auf Windows Server 2008 R2, kann nun der neue Server als "zusätzlicher DC der bestehenden Domäne" hinzugefügt werden. Während dem Heraufstufen zum DC sollte an entsprechender Stelle, dass DNS mit installiert und zusätzlich der globale Katalog aktiviert werden. Anschließend sollten noch die FSMO-Rollen auf den Windows Server 2008 R2 DC verschoben werden.

Globaler Katalog (Global Catalog – GC)
Der PDC-Emulator
Die FSMO-Rollen verschieben

Szenario 1

Eine Domänenaktualisierung von Windows 2000 auf Windows Server 2008 R2 durchführen

In einer Windows 2000 Active Directory Umgebung kann die Domänenaktualisierung auf Windows Server 2008 R2 über einen zusätzlichen Windows Server 2008 R2 DC realisiert werden. Dazu ist zuerst die Schritt für Schritt-Anleitung die am Anfang dieses Artikels beschrieben ist durchzuführen. Anschließend kann ein Windows Server 2008 R2 als zusätzlicher Domänencontroller der bereits bestehenden Domäne hinzugefügt werden.
Es ist zuerst ein Inplace-Update von Windows 2000 auf Windows Server 2003 mit mindestens dem Service Pack 2 (besser aktueller) durchzuführen. Erst dann kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden, natürlich auch erst nach Ausführung der Schritt für Schritt-Anleitung.

Szenario 2

Eine Domänenaktualisierung von Windows Server 2003 auf Windows Server 2008 R2 durchführen

Wie in einer Windows 2000 Gesamtstruktur sollte auch in einer Windows Server 2003 Gesamtstruktur die Domänenaktualisierung über einen zusätzlichen Windows Server 2008 R2 Domänencontroller erfolgen. Selbstverständlich auch nur dann, wenn die Schritt für Schritt-Anleitung durchgeführt wurde.
Ist mindestens das Service Pack 2 für den Windows Server 2003 auf dem DC installiert, so kann mit einem Inplace-Update der Windows Server 2003 DC auf Windows Server 2008 R2 aktualisiert werden. Die Schritt für Schritt-Anleitung die am Anfang dieses Artikels beschrieben wird, ist dabei zuerst durchzuführen.

Szenario 3

Eine Domänenaktualisierung von Windows Server 2003 R2 auf Windows Server 2008 R2 durchführen

Da in einem Windows Server 2003 R2 ein Windows Server 2003 mit mindestens dem Service Pack 2 enthalten ist, kann nach vorheriger Ausführung der Schritt für Schritt-Anleitung ein zusätzlicher Windows Server 2008 R2 DC zur bestehenden Domäne hinzugefügt werden.
Des Weiteren kann ein Windows Server 2003 R2 SP2 DC per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden, wenn vorher die Schritt für Schritt-Anleitung durchgeführt wurde.

Szenario 4

Eine Domänenaktualisierung von Windows Server 2008 auf Windows Server 2008 R2 durchführen

Eine Domänenaktualisierung kann durch hinzufügen eines zusätzlichen Windows Server 2008 R2 DCs durchgeführt werden. Die Schritt für Schritt-Anleitung am Anfang des Artikels gilt es zuerst durchzuführen. Hier in Kurzform: Zuerst muss auf dem Schema-Master das Adprep32 /Forestprep und auf dem Infrastruktur-Master das Adprep32 /Domainprep ausgeführt werden.
Ein Windows Server 2008 DC kann auch per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden. Vorher muss ebenfalls auf dem Schema-Master das Adprep32 /Forestprep und auf dem Infrastruktur-Master das Adprep32 /Domainprep durchgeführt werden.

Szenario 5

Eine Domänenaktualisierung von einem x64Bit Windows Server 2008 Core auf Windows Server 2008 R2 Core durchführen

Die Domänenaktualisierung kann hier ebenfalls durch hinzufügen eines zusätzlichen Windows Server 2008 R2 Core DCs erfolgen. Natürlich muss auch in diesem Fall vorher das ausführen von Adprep32 /Forestprep auf dem Schema-Master und das Adprep32 /Domainprep auf dem Infrastruktur-Master erfolgen.
Der x64Bit Windows Server 2008 Core DC lässt sich per Inplace-Update auf einen Windows Server 2008 R2 Core aktualisieren. Auch hier gilt es im ersten Schritt auf dem Schema-Master das Adprep /Forestprep und im zweiten, auf dem Infrastruktur-Master das Adprep /Domainprep auszuführen.

Szenario 6

Eine Windows Server 2008 R2-Subdomäne in einer Windows 2000/2003/2003 R2/2008 Gesamtstruktur erstellen

Soll in einer Gesamtstruktur die erste Windows Server 2008 R2-Domäne und somit der erste Windows Server 2008 R2-DC zur Gesamtstruktur hinzugefügt werden, so muss lediglich auf dem Schema-Master das Adprep /Forestprep ausgeführt werden. Anschließend kann mit dem Windows Server 2008 R2 die Subdomäne erstellt werden.

Befindet sich in einer Windows 2000 Umgebung die FSMO-Rolle des Domänennamenmasters auf einem Windows 2000 DC, wird das Attribut msDS-BehaviorVersion im entsprechenden crossRef-Objekt nicht aktualisiert, wenn eine Subdomäne bzw. eine neue Domänenstruktur (Tree) unter Windows Server 2008 oder Windows Server 2008 R2 erstellt wird. In diesem Fall kann es bei einigen Anwendungen zu Kompatibilitätsproblemen kommen. Insbesondere wenn mit DCDIAG die AD-Replikation überprüft werden soll, schlägt der Replikationstest fehl. Die Abhilfe dieses Problems ist, die Rolle des Domänennamenmasters entweder auf einen Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 DC zu übertragen, bevor eine neue Subdomäne bzw. eine neue Domänenstruktur (Tree) erstellt wird. >> >

>>>>>>>
Weitere Informationen:
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Schemaupdate beim Windows Server 2003 R2
Einen zusätzlichen DC in die Domäne hinzufügen
Die AD-Powershell im Windows Server 2008 R2
Das Active Directory Preparation Tool – ADPREP
Domänen- und Gesamtstrukturfunktionsmodus
Windows Server 2008 R2 Upgrade Paths
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Wie viele DCs pro Domäne werden benötigt?

Yusuf Dikmenoglu — Mon, 05 Jan 2009 20:38:27 GMT

So einfach wie die Frage im ersten Moment klingt, so schwierig ist sie zu beantworten. Gleich vorweg, letztendlich lässt sich diese Frage nicht pauschal beantworten, denn es gibt keine Faustformel dazu, die Anzahl der benötigten Domänencontroller (DCs) zu berechnen.

Aber eins kann man mit Gewissheit empfehlen, jede Domäne muss wegen der Ausfallsicherheit und Verfügbarkeit mindestens zwei DCs enthalten!

Damit ist zumindest sichergestellt, dass bei einem DC-Crash der zweite DC die Domäne noch am Leben erhält. In vielen Umgebungen wird die Anzahl der DCs an der Ausfallsicherheit, der Standortverteilung oder der Anzahl der Benutzer pro Standort bestimmt. Die Bandbreitenanbindung bei bestehen von mehreren Standorten ist für die Anzahl an DCs, ebenfalls von elementarer Bedeutung.

Es kommt bei der Ermittlung der genauen Anzahl an DCs immer auf die Umgebung an.

Wie viele DCs in der Domäne benötigt werden, hängt außerdem von den Ansprüchen des Unternehmens ab. Natürlich hat ein großes Unternehmen mit vielen Standorten andere Ansprüche bzgl. der hohen Verfügbarkeit, Fehlertoleranz sowie Redundanz, als kleinere und mittlere Unternehmen (KMU) mit vielleicht nur einem Standort.

Die folgenden Kriterien helfen bei der Definition der Anzahl an DCs pro Domäne:

Wie viele AD-Standorte existieren?
In wie vielen Ländern?
Mit welcher (stabilen?) Bandbreite?
Wie viele Benutzer existieren pro Standort?
Wie viel Last besteht auf den DCs während der Benutzerauthentifizierungen?
Existiert eine Exchange-Umgebung?
Existieren Applikationen die vom AD abhängig sind?
Gibt es Standorte, die besonders AD-lastig arbeiten?
Existieren Standorte, in denen mehr gesamtstrukturweite Abfragen, sprich der globale Katalog überwiegend beansprucht wird?
Besteht aktuelle Hardware für die Domänencontroller?

Alle diese Faktoren helfen die Anzahl der DCs innerhalb einer AD-Domäne festzulegen. Jedoch schließt das Installieren von mehreren DCs natürlich keineswegs eine regelmäßige Datensicherung des System-State aus. Diese muss ohnehin durchgeführt werden. Die Sicherung des Systemstatus ist das Mindeste, was auf einem DC gesichert werden muss!

Bei der Hardware der DCs kommt es insbesonders auf die CPU (welcher Prozessor und wie viele existieren?), Festplattenspeicher und vor allem dem Arbeitsspeicher an. Denn idealerweise sollte die Active Directory-Datenbank „NTDS.dit“ in den Arbeitsspeicher geladen werden können. Dabei läuft das Active Directory in dem LSASS Prozess.

Microsoft stellt auf der folgenden Seite seine Tests dar, die sie vor einigen Jahren mit HP-Proliant Servern durchgeführt hatten. Dort gewinnt man ebenfalls einige Anhaltspunkte zu der benötigten Anzahl an DCs.

Determining the Minimum Number of Domain Controllers Required>>>>>>>>>>>>

Weitere Ansätze über die Anzahl und Hardwareausstattung der DCs, liefern diese Seiten:

Step B2: Determine the Number of Domain Controllers
Planning Domain Controller Capacity: Active Directory

Größere Unternehmen mit mehreren Standorten sollten sich dieses Whitepaper durchlesen:

Windows Server 2003 Active Directory Branch Office Guide

>>
Oftmals ist es gerade in kleineren und mittleren Unternehmen so, das die Maschine die als einziger DC fungiert, nicht nur die Funktion eines DCs wahrnimmt. Dieser ist Datei- sowie Applikationsserver und wenn nicht sogar noch Mailserver zugleich (SBS). In diesen Umgebungen kann man sich oftmals keinen dedizierten zweiten DC leisten. Dabei reicht schon eine nicht ganz veraltete Client-Hardware aus, um auf diesem einen weiteren DC zu installieren (natürlich wird eine weitere Server-Lizenz benötigt). Falls dennoch kein zweiter DC installiert werden kann, ist umso mehr auf die regelmäßige und funktionierende System-State Sicherung zu achten.

Wenn es aber auf dem einzigen DC zu Performanceproblemen kommt, sollte eine Auslastungsanalyse über einen längeren Zeitraum durchgeführt werden (z.B. eine Woche). Dabei ist ein besonderes Augenmerk auf den Speicherverbrauch der Lsass.exe zu werfen. Erst nach der Analyse lässt sich ableiten, ob der DC überlastet bzw. die Hardware nicht ausreichend ist. Die Lösung könnte dann z.B. eine aktuelle Hardware, ein x64-DC oder ein weiterer DC sein. Wobei mit Blick auf das nächste Serverbetriebssystem, der Windows Server 2008 R2 ohnehin nur noch als x64-Bit Version ausgeliefert wird.

Weitere Informationen:
Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

RODC Compatibility Pack

Yusuf Dikmenoglu — Thu, 29 May 2008 18:22:30 GMT

Wer an den Einsatz eines Windows Server 2008 Read-Only Domänencontroller in einer Umgebung mit Windows XP und Windows Server 2003 nachdenkt,
könnte in der Praxis auf die verschiedensten Probleme bezgl. des RODCs stoßen.

Die Probleme können deshalb auftreten, da diese Systeme nicht die volle Kompatibilität eines RODCs gewährleisten.

Microsoft hat reagiert und einen Compatibility Pack (CP) für die Betriebssysteme Windows XP sowie Windows Server 2003 veröffentlicht.

Das CP behebt zehn Symptome die in einer gemischten Umgebung mit Windows XP Clients sowie Windows Server 2003 auftreten können.

Welche das sind, steht in dem folgenden Microsoft-Artikel.
Von dort aus kann auch das CP heruntergeladen werden.

Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die Installation eines RODC

Yusuf Dikmenoglu — Sun, 24 Feb 2008 12:45:28 GMT

Der Read-Only Domänencontroller ist ein DC der für Standorte konzipiert wurde, die keine physikalische Sicherheit dem DC und somit
auch der Domäne bzw. Gesamtstruktur bieten können. Wie es im Namen bereits zu lesen ist, handelt es sich dabei um einen DC der
ausschließlich nur eine Leseberechtigung auf die Active Directory-Daten hat. Falls Änderungen im Active Directory durchgeführt werden sollen,
leitet der RODC diesen Vorgang auf einen beschreibbaren DC weiter. Das gilt auch für Aktualisierungen im DNS.
Zusätzlich stellt die einseitige (unidirektionale) Replikation eine weitere Sicherheitsfunktion dar. Auf dem RODC findet nur eine
eingehende (Inbound)-Replikation statt. Es wird nichts vom RODC zu einem beschreibbaren DC repliziert. Die einseitige Replikation
wird für die Active Directory-Domain Services und für die DFS-Replikation des SYSVOL-Verzeichnisses angewendet.

Weitere Details zum RODC werden in diesem Artikel erläutert:
Read-Only Domain Controller (RODC)

Die Voraussetzungen um den ersten RODC in der Domäne zu installieren

Der Modus für die Gesamtstruktur muss sich mindestens auf Windows Server 2003 oder höher befinden,
damit die Linked Value Replikation (LVR) zur Verfügung steht.
Der RODC kann sich die Domänenpartition ausschließlich von einem beschreibbaren Windows Server 2008
oder Windows Server 2008 R2 Domänencontroller replizieren. Daher muss sich bereits ein beschreibbarer
Windows Server 2008/2008 R2/Core/Core R2 Domänencontroller in der Domäne befinden. Wenn das nicht der Fall wäre,
würde die Option zum erstellen eines RODC an entsprechender Stelle nicht zur Verfügung stehen.
Das Active Directory Preparation Tool (ADPREP) muss mit dem Parameter /RODCPREP ausgeführt worden sein.
Dabei werden die Berechtigungen (Security Descriptor, SD) von allen DNS-Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) in der Gesamtstruktur aktualisiert. Der Befehl muss mit Organisations-Administrator Rechten durchgeführt werden und kann auf irgendeinem DC ausgeführt werden. Dieser DC muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen von ADPREP /Rodcprep werden die einzelnen Infrastrukturmaster der Domänen kontaktiert, um die Berechtigungen der Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.

Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com"
Wird für die bereitgestellte Installation zuerst das RODC-Computerkonto in der OU Domain Controllers im AD DS erstellt,
darf der zukünftige RODC nicht bereits Mitglied der Domäne sein.

Die Installation eines RODC auf einem Windows Server 2008 (Vollinstallation) durch den DCPROMO-Assistenten

Der Read-Only Domänencontroller kann auf mehrere Varianten bereitgestellt werden.
Die eine Variante wäre die Installation des RODCs durch das Ausführen des DCPROMO-Assistenten. Dies kann von einem
Domänen- bzw. Organisations-Administrator durchgeführt werden. Dabei kann der Server entweder ein standalone- oder
Mitgliedsserver sein. Nach der Betriebssysteminstallation kann der Administrator direkt das DCPROMO aufrufen und somit
den Server zum RODC stufen. Die Installation gestaltet sich nicht sonderlich anders als die Installation eines beschreibbaren DCs.
Es ist lediglich darauf zu achten, dass beim ausführen des DCPROMO-Assistenten die Option
Schreibgeschützter Domänencontroller (RODC) auf der Seite der Domänencontrolleroptionen ausgewählt wird.

Empfehlenswert wäre es, nach dem Aufruf von DCPROMO die Option Installation im erweiterten Modus verwenden auszuwählen.
Ich empfehle diese Option bei jeder DC-Installation zu aktivieren. Erst durch den erweiterten Modus erscheint die zusätzliche
Auswahl (bei einer RODC-Installation) Richtlinie für Kennwortreplikation angeben (Password Replication Policy, kurz PRP),
in der festgelegt werden kann welche Kennwörter auf den RODC repliziert werden dürfen und welche verwehrt bleiben.
Die Replikation der Kennwörter von einzelnen Benutzern, Gruppenmitgliedern oder Computern können auf dem RODC zugelassen
bzw. verwehrt werden. Dabei bleiben standardmäßig die Kennwörter administrativer Konten dem RODC verwehrt.
Wenn dabei ein Benutzerkonto in der abgelehnten- sowie zulässigen RODC-Kennwortreplikationsgruppe Mitglied ist,
so hat die abgelehnte Gruppe Vorrang!

Die Konfiguration der Kennwort-Replikation kann natürlich auch im Nachhinein jederzeit geändert und muss nicht unbedingt während
der Installation festgelegt werden. Weitere Optionen die erst mit aktivieren des erweiterten Installationsmodus erscheinen, wäre die
IFM-Option und die Auswahl eines Quelldomänencontrollers mit dem die Replikation über das Netzwerk durchgeführt werden soll.

Die Installation eines RODC auf einem Windows Server 2008 Core

Der RODC kann ebenfalls auf einer Installation des Windows Server Core bereitgestellt werden. Da das Heraufstufen zu einem
RO-/DC auf einem Windows Server Core nicht wie gewohnt über die GUI des DCPROMO-Assistenten durchgeführt werden kann,
ist der Administrator gezwungen die Installation, entweder durch die einzelne Eingabe der Parameter in der Kommandozeile
(DCPROMO /unattend /ReplicaOrNewDomain=ReadOnlyReplica…) oder mit einer Antwortdatei durchzuführen.

Eine Beispiel-Antwortdatei zum Heraufstufen eines RODCs befindet sich am Ende dieses Artikels:
Windows Server 2008 Core

Die bereitgestellte Installation eines RODC

Eine andere Variante wäre die Installation eines RODCs in zwei Schritten durchzuführen. Dabei erstellt ein Domänen- bzw.
Organisations-Administrator im ersten Schritt zuerst das RODC-Computerkonto im Active Directory und bekommt dabei die Möglichkeit,
die vor Ort Installation sowie die Verwaltung des RODCs entweder von einem Domänen-Administrator durchführen zu lassen
oder an einen Benutzer oder besser einer Benutzergruppe dieses Privileg zu delegieren. Zur leichteren Administration sollte
eine Benutzergruppe angegeben werden. Die Delegierung an dieser Stelle hat den positiven Nebeneffekt, dass der Benutzer
oder die Gruppe denen dieses Recht delegiert wurde, gleichzeitig auch der lokale Administrator des Systems ist. Die Änderungen
am System, sei es Treiberaktualisierungen, Softwareinstallationen oder Hardwaretausch kann von nun an von einem normalen Benutzer
durchgeführt werden, der keine Rechte auf das Active Directory hat. In den vorherigen Server-Versionen stellte genau dieses
Szenario in verteilten Umgebungen oftmals ein Problem dar. Im zweiten Schritt wird durch das Ausführen von DCPROMO auf dem
Server die RODC-Installation endgültig abgeschlossen.

Die Vorgehensweise für die bereitgestellte Variante wäre folgende >

In der MMC Active Directory-Benutzer und -Computer ist auf einem beschreibbaren Windows Server 2008 Domänencontroller,
mit einem Rechtsklick auf der OU Domain Controllers die Option Konto für schreibgeschützten Domänencontroller vorbereiten… auszuwählen.>
Auf der Willkommensseite gilt es die Option Installation im erweiterten Modus verwenden zu aktivieren.
Im nächsten Schritt bekommt man einen Hinweis bezgl. der Betriebssystemkompatibilität. Der Assistent weißt einen darauf hin,
das durch die verbesserten Sicherheitseinstellungen im Windows Server 2008 Probleme mit älteren Windows-Betriebssystemen
(Windows NT) entstehen kann. Es wird dabei auf diesen KB-Artikel verwiesen:

When a Windows NT 4.0-based computer tries to use the NETLOGON service to establish a security channel to a Windows Server 2008-based domain controller, the operation may fail
Als nächstes werden die Anmeldeinformationen eines Domänen- oder Organisations-Administrators benötigt. Wenn man auf dem
System, auf der man das RODC-Computerkonto erstellt als Domänen-Administrator angemeldet ist, reichen die aktuellen
Anmeldeinformationen aus und es müssen keine alternativen Anmeldeinformationen eingegeben werden. Ansonsten werden
alternative Anmeldeinformationen benötigt. Wenn die angegebenen Anmeldeinformationen nicht über die benötigten Rechte verfügen,
folgt eine Warnung mit dem Hinweis, dass das angegebene Benutzerkonto in keines der genannten Gruppen Mitglied ist. Es ist zwar
trotzdem möglich mit dem Assistenten fortzufahren, aber spätestens nach der Zusammenfassung erscheint erneut der Hinweis,
dass die eingegeben Anmeldeinformationen nicht ausreichen. Aber auch hier bekommt man dann die Option,
ein berechtigtes Benutzerkonto einzugeben.
Auf der nächsten Seite muss der Computername des zukünftigen RODCs eingetragen werden. Des Weiteren wird der Hinweis angezeigt,
dass der Computername an dieser Stelle vergeben werden muss. Weiterhin wird darauf hingewiesen, dass der Server erst mit Ausführen
von DCPROMO zur Domäne hinzugefügt werden darf. Falls der Server zu diesem Zeitpunkt bereits Mitglied der Domäne wäre,
würde an dieser Stelle eine Fehlermeldung erscheinen:
Nun muss der Standort ausgewählt werden, an dem der RODC eingesetzt werden soll.
Im darauffolgenden Schritt ist die Auswahl der zusätzlichen Domänencontrolleroptionen zu treffen. Es stehen insgesamt drei Optionen
zur Auswahl, wobei die letzte Option Schreibgeschützter Domänencontroller (RODC) aktiviert und ausgegraut ist. Die beiden anderen
Optionen wären DNS-Server und Globaler Katalog (was vorteilhaft wäre diese aktiviert zu lassen).
An dem nächsten Punkt angelangt, kann man die Richtlinie für die Kennwortreplikation bearbeiten. Die Kennwortreplikation beeinflusst
das Anmeldeverhalten eines Benutzers bei nicht erreichen eines beschreibbaren DCs.

Der genaue Vorgang wird auf diesen Seiten erklärt:
Appendix B: How the Authentication Process Works with RODCs
Password Replication Policy

Wichtig an dieser Stelle wäre zu erwähnen, möchte man das der RODC einen Benutzer (oder Dienstkonto) eigenständig authentifiziert,
ohne das ein beschreibbarer DC kontaktiert werden soll (z.B. wenn die WAN-Verbindung unterbrochen ist), so muss neben dem Kennwort
des Benutzerobjekts noch das Computerkontokennwort an dem sich der Benutzer anmeldet, bereits auf den RODC repliziert worden sein.
Natürlich müssen die betroffenen Benutzer- sowie Computerkonten vorher in der Richtlinie für die Kennwortreplikation zugelassen werden.

Falls das Kennwort eines Benutzers (und/oder Computerkontos, an dem sich der Benutzer anmeldet) nicht auf den RODC repliziert wurde
und es entsteht eine WAN-Störung, kann sich der Benutzer zu diesem Zeitpunkt lediglich mit seinen zwischengespeicherten
Benutzerinformationen (cached Credentials) anmelden. Das kann der Benutzer wiederum nur, wenn er sich vorher einmal von
dem Computer aus, erfolgreich an der Domäne authentifiziert hat.

Der RODC trägt sich bekanntermaßen als Key Distribution Center (KDC) im Active Directory für seinen Standort ein und somit kann der
RODC dem Client das Ticket-Granting Ticket (TGT) ausstellen.

Die Replikation der Kennwörter lässt sich manuell anstoßen. Zum einen ist das mit Repadmin möglich. Der Befehl dazu lautet:
Repadmin /Rodcpwdrepl <RODC*> <beschreibbarer DC> <DN des Benutzerkontos> <DN des Clients>

Repadmin /rodcpwdrepl

Zum anderen lässt sich die Replikation der Kennwörter auch über die grafische Oberfläche realisieren. Dazu gilt es in der MMC
Active Directory-Benutzer und -Computer die Eigenschaften des RODC-Computerkontos zu öffnen. Dort im Reiter
Kennwortreplikationsrichtlinie ist die Option Erweitert auszuwählen. In der erweiterten Kennwortreplikation hat man nun die
Möglichkeit über die Auswahl von Kennwörter auffüllen… die entsprechenden Kennwörter sofort zu replizieren.

>
Der Assistent fragt als nächstes nach einem Benutzer oder einer Gruppe, die das Recht delegiert bekommen sollen den RODC
fertig zu installieren (durch Ausführen von DCPROMO). Zudem wird darauf hingewiesen das die angegeben Konten über lokale
Administratorberechtigungen verfügen. Erfolgt an dieser Stelle keine Eingabe, so kann die Installation des RODCs ausschließlich
von einem Domänen- oder Organisations-Administrator abgeschlossen werden.
Erneut der Hinweis; Die hier angegebenen Konten bekommen keine weiteren Rechte auf das AD!
Es folgt die Zusammenfassung in der die gewählten Einstellungen überprüft werden können.
Anschließend wird mit Fertig Stellen der Vorgang zum erstellen des RODC-Computerkontos abgeschlossen.

Zum Fertigstellen der RODC-Installation ist es als letzten Schritt notwendig, an dem zukünftigen RODC den DCPROMO-Assistenten auszuführen.

Die Vorgehensweise wäre folgende:

Mit dem Befehl Dcpromo /UseExistingAccount:Attach gilt es unter Start - Ausführen den DCPROMO-Assistenten aufzurufen.

Falls man die Installation mit Hilfe einer Install from Media (IFM) -Sicherung durchführen möchte, sollte die Option
Installation im erweiterten Modus verwenden aktiviert werden. Auch wenn man explizit einen DC auswählen möchte
von dem die Replikation erfolgen soll, ist der erweiterte Modus zu aktivieren.

Im nächsten Schritt muss die Domäne angegeben werden zu der der RODC hinzugefügt werden soll. Zusätzlich sind die
alternativen Benutzerinformationen eines Benutzers anzugeben, der beim erstellen des RODC-Computerkontos das Recht der
Installation delegiert bekommen hat (siehe oben Punkt 9). Natürlich kann hier auch der Domänen-Administrator angegeben werden.

Danach muss das bereits erstellte RODC-Computerkonto ausgewählt werden.

>
Wurde der erweiterte Modus auf der Willkommensseite ausgewählt, kann an dieser Stelle eine Sicherung angegeben werden.
Falls keine Sicherung angegeben wird, kann als nächstes ein Quelldomänencontroller ausgewählt werden,
von dem aus die Replikation ausgeführt wird.
Auf der nächsten Seite kann der Pfad zur Active Directory-Datenbank, den Protokolldateien und dem SYSVOL-Verzeichnis konfiguriert werden.
Dann muss ein Kennwort für den Wiederherstellungsmodus für Verzeichnisdienste vergeben werden.
Zum Schluss erfolgt die Zusammenfassung der Einstellungen die vorgenommen wurden, bevor es dann mit der Installation beginnt.

Die Verwaltung des RODC

Die Information wer den RODC lokal administrieren darf wird im Active Directory, genauer, im Attribut managedBy das sich im RODC-Computerkonto
befindet gespeichert. Ist es notwendig die lokale Verwaltung des RODCs an einen anderen Benutzer bzw. Benutzergruppe zu delegieren, so kann
diese Einstellung in den Eigenschaften des RODC-Computerkontos, im Reiter Verwaltet von vorgenommen werden.

>

Oder es wird im Reiter Attribut-Editor der Distinguished Name des Benutzers (oder der Benutzergruppe) direkt im
Attribut managedBy eingetragen, der zukünftig den RODC verwalten soll.

Zusätzlich wird in der Registry auf dem RODC im folgenden Pfad:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RODCROLES

im Schlüssel RepairAdmin die SID des Benutzers/der Benutzergruppe gespeichert, die im Attribut managedBy eingetragen wurde.

Eine andere Variante einen lokalen Administrator zu definieren wäre über die beiden Kommandozeilentools DSMGMT.exe oder NTDSUTIL.exe.
Dadurch können auch feinere Rechte gesetzt werden, in dem z.B. der Domänen-Benutzer in die Gruppe der Sicherungs-Operatoren
oder Server-Operatoren auf dem RODC hinzugefügt wird.

Dieses erreicht man durch folgende Vorgehensweise:

- Start - Ausführen - DSMGMT.exe oder NTDSUTIL.exe (die Eingabe der folgenden Befehle gelten sowohl für DSMGMT als auch für NTDSUTIL)
- Local Roles
- Add <DOMÄNE>\<Domänen-Benutzer> Server-Operatoren

Mit Show Role Server-Operatoren können die Mitglieder dieser Gruppe angezeigt werden.
Wenn ein Benutzer über diese Methode zu einer Gruppe hinzugefügt wurde, wird im o.g. Registry-Pfad ein weiterer
Schlüssel erstellt, das als Wert die SID des Benutzers enthält. Der Schlüssel trägt als Namen das letzte Oktett der Well-Known SID von der
entsprechenden Gruppe, in der der Benutzer hinzugefügt wurde. Wird z.B. ein Benutzer zu der Builtin-Gruppe Server-Operatoren hinzugefügt,
so lautet der Name des erstellten Schlüssels 549. Wird hingegen der Benutzer zu der Builtin-Gruppe Konten-Operatoren hinzugefügt,
so trägt der Schlüssel den Namen 548.

Well-known security identifiers in Windows operating systems

Wird der Benutzer mit dem Befehl Remove <DOMÄNE>\<Domänen-Benutzer> <Gruppe>
aus der Gruppe entfernt, bleibt der erstellte Schlüssel zwar bestehen, jedoch wird der als Wert eingetragene SID entfernt.

Weitere Informationen:
Read-Only Domain Controllers and Account Lockouts
Performing a Staged RODC Installation
Applications That Are Known to Work with RODCs

>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Domänencontroller-Installation von einer Sicherung

Yusuf Dikmenoglu — Sun, 27 Jan 2008 22:27:26 GMT

Seit Windows Server 2003 ist es möglich einen Server mit Hilfe einer Systemstatus-Sicherung (System State) von einem
bestehenden Domänencontroller (DC), durch die Install from Media (IFM) Funktion, zu einem zusätzlichen DC hochzustufen.
Diese Art des Heraufstufens zu einem DC bietet sich in den Fällen an, in denen ein Server an einem entfernten Standort zum
DC heraufgestuft werden soll und vor Ort nur eine geringe Bandbreite zur Verfügung steht. Damit dann eben nicht die gesamte
Active Directory-Datenbank (NTDS.dit) über die schmale Leitung repliziert werden muss, kann das Volumen der Replizierung Dank
der Sicherung gering gehalten werden. Es werden lediglich die Änderungen die seit der Sicherung stattgefunden haben über
die Leitung repliziert. Dadurch hat die IFM-Funktion zum einen den Vorteil, dass weniger Netzwerkressourcen in Anspruch
genommen und zum anderen, dass der Domänencontroller früher bereitgestellt werden kann.

So kann nun ein Server in der Zentrale installiert und an den Standort verschickt werden, ohne ihn vorher zum DC zu stufen.
Damit wäre sichergestellt, dass auf dem Weg zum Ziel-Ort der DC (und somit die Domäne bzw. Gesamtstruktur)
nicht kompromittiert werden kann. Auf einem anderen Weg kann dann das Sicherungsmedium auf dem die
Systemstatus-Sicherung enthalten ist, getrennt vom Server verschickt werden.

Ganz wichtig ist aber, wenn das Sicherungsmedium auf dem sich die Systemstatus-Sicherung befindet an einen
anderen Ort versandt werden sollte (auf welchem Weg auch immer), ist die gleiche Sicherheit zu gewährleisten,
wie bei einem Transport eines DCs. Denn in der Systemstatus-Sicherung befinden sich unter anderem sämtliche
Kennwörter der Domäne sowie die Objekt-SIDs.

Nach dem Heraufstufen müssen zusätzliche Aufgaben weiterhin ausgeführt werden, wie z.B. den DNS Dienst zu installieren.

Einen zusätzlichen DC in die Domäne hinzufügen >

IFM unter Windows Server 2003

Diese Art des Heraufstufens zu einem DC, ist nur bei einem zusätzlichen Domänencontroller einer bereits existierenden Domäne möglich!
Die Sicherung des Systemstatus muss von einem Windows Server 2003 DC aus der gleichen Domäne stammen.

Dabei kann eine Sicherung von einem bestehenden Windows 2000 DC nicht als Grundlage dienen!
Des Weiteren wird die IFM-Funktion bei Nutzung einer Sicherung eines 32Bit DCs, dass als Grundlage für das Heraufstufen
eines 64Bit Servers dienen soll nicht unterstützt. Das gleiche gilt auch im umgekehrten Fall.

Zum Sichern des Systemstatus eignet sich das im Betriebssystem enthaltene Sicherungsprogramm NTBACKUP.
Mit dem Sichern des Systemstatus werden die folgenden Elemente gesichert:

Active Directory (NTDS.dit)
Systemstart Dateien
COM+ Datenbank zur Registrierung von Klassen
Registry
SYSVOL
Falls eine CA auf dem DC installiert wäre, dann auch diese

In der Praxis ist es für den Administrator hilfreich, wenn er bereits im Dateinamen der Sicherungsdatei erkennen kann,
welche Informationen in der Sicherung enthalten sind. Im Dateinamen könnte sich z.B. der FQDN, SP-Stand, GC und das Datum
des gesicherten DCs befinden. Wichtig ist das Datum, denn die Sicherung darf nur solange verwendet werden,
bis die Tombstone Lifetime (TSL) ausläuft. Die Tombstone Lifetime beträgt in den meisten Umgebungen 60 Tage.
Erst wenn beim Erstellen einer Gesamtstruktur, der erste DC ein Windows Server 2003 SP1 ist, beträgt die TSL 180 Tage.

Es ist darauf zu achten das beim Heraufstufen mit der IFM-Funktion, der Ziel-Server auf dem gleichen Service Pack-Stand
wie der Quell-DC ist. Damit der neue Server zu einem zusätzlichen DC gestuft werden kann, benötigt er zum Zeitpunkt der
Ausführung von DCPROMO eine bestehende Namensauflösung. Dazu ist ein bestehender DNS-Server in den TCP/IP-Einstellungen
einzutragen, der natürlich während dem Heraufstufen erreichbar sein muss. Es ist wohl naheliegend das der Server eine Verbindung
zu der Domäne dem er hinzugefügt werden soll haben muss, damit er unter anderem den Träger der FSMO-Rollen (z.B. RID-Master)
erreichen kann.

Sollen die bestehenden Anwendungsverzeichnispartitionen wie es z.B. DomainDNSZones oder ForestDNSZones darstellen,
ebenfalls mit der IFM-Funktion bereitgestellt werden, muss der Quell-DC mindestens das Service Pack 1 installiert haben.
Zusätzlich muss sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 befinden.
Wenn auf dem neuen DC auch der globale Katalog (GC) aktiviert werden soll, können die Daten eines GCs ebenfalls mit der
IFM-Funktion bereitgestellt werden. Dazu muss auf dem Quell-DC auf dem die Sicherung durchgeführt werden soll,
ebenfalls der GC aktiviert sein.

Die Sicherungsdatei in der die Systemstatus-Sicherung enthalten ist, muss wiederhergestellt werden. Ein simples Hineinkopieren
der Sicherungsdatei auf ein lokales Laufwerk reicht nicht aus. Die wiederhergestellten Systemstatusdateien könnte man auf eine
CD/DVD oder auf einen USB-Stick/HDD kopieren. Anschließend kann beim Ausführen des Active Directory-Assistenten DCPROMO
auf das entsprechende Medium verwiesen werden. Wichtig ist, dass es sich dabei um ein lokales Laufwerk handelt.
Das Auswählen der Systemstatusdateien über die Angabe eines UNC-Pfads oder ein verbundenes Netzlaufwerk, wird nicht unterstützt.

Sollen die Systemstatusdateien auf dem Ziel-Server wiederhergestellt werden, ist darauf zu achten die Wiederherstellung
in ein alternatives Verzeichnis und keinesfalls an den ursprünglichen Bereich durchzuführen. Nach dem Heraufstufen sollte
dieses temporäre Verzeichnis gelöscht werden. Wenn stattdessen die Dateien an ihren Ursprungsort wiederhergestellt werden,
können das System und das AD irreparable Schäden annehmen. Denn mit Rücksichern der Systemstatusdateien wird auch die
Registry wiederhergestellt, in der bekanntlich nicht nur Hardware- sowie Treiberinformationen enthalten sind, sondern auch der Computername.

Auf dem Ziel-Server muss das Dcpromo mit dem Parameter /ADV (für Advanced) zum Heraufstufen aufgerufen werden.
Erst mit diesem Befehl ist es möglich, eine Sicherung anzugeben.

Die einzelnen Schritte unter Windows Server 2003, können in diesem Artikel nachgelesen werden:
How to use the Install from Media feature to promote Windows Server 2003-based domain controllers

IFM unter Windows Server 2008

Die IFM-Option ist weiterhin auch unter Windows Server 2008 verfügbar. Wobei nun unter Windows Server 2008 der
erweiterte Schalter /ADV (der weiterhin funktioniert) in den Dcpromo-Assistenten eingebaut wurde. Direkt beim Aufruf von Dcpromo
lässt sich auf der Willkommens-Seite die Option Installation im erweiterten Modus verwenden aktivieren.

Während unter Windows Server 2003 eine Sicherung des Systemstatus z.B. mit Ntbackup erstellt werden muss, wird das nun
unter Windows Server 2008 mit NTDSUTIL erledigt. Denn das Ntbackup existiert nicht mehr unter Windows Server 2008.

Zum erstellen einer Sicherung gilt es folgende Schritte durchzuführen:

In einer Kommandozeile oder über Start-Ausführen gilt es zuerst NTDSUTIL zu starten.>
Als nächstes muss die NTDS-Instanz aktiviert werden.
Dieses erreicht man durch die Eingabe von Activate Instance NTDS.
Mit Eingabe von IFM gilt es auf die Install from Media-Ebene zu gelangen.
Dort angelangt, kann nun die IFM-Sicherung erstellt werden.
Erstellt man die IFM-Sicherung auf einem beschreibbaren DC, so können Sicherungsmedien für einen beschreibbaren
DC oder für einen RODC erstellt werden. Man kann dabei wählen, ob jeweils das SYSVOL-Verzeichnis mit gesichert
werden soll oder nicht.
Wird hingegen die IFM-Sicherung auf einem RODC erstellt, kann ausschließlich das Sicherungsmedium für einen RODC erstellt
werden und nicht für einen beschreibbaren DC. In der erstellten IFM-Sicherung werden dabei alle replizierten Kennwörter entfernt.
Auf einem Server Core können die gleichen IFM-Sicherungen erstellt werden, wie auf einem beschreibbaren DC.

Wird das SYSVOL-Verzeichnis nicht mit gesichert, wird es beim Heraufstufen eines DCs über die Leitung repliziert.

Unter Windows Server 2008 ist es jetzt möglich, IFM-Sicherungen auf einem 32Bit System zu erstellen, um diese als Grundlage
auf einem 64Bit System zu nutzen. Im umgekehrten Fall ist das ebenfalls möglich. Eine IFM-Sicherung die auf einem 64Bit System
erstellt wurde, kann auf einem 32Bit System verwendet werden.

Beim Erstellen eines Sicherungsmediums kommt die Volume Shadow Copy Service (VSS) Technologie zum Einsatz.
Im laufenden Betrieb wird ein Snapshot von der Active Directory-Datenbank erstellt und anschließend offline defragmentiert.

Die IFM-Sicherung die auf einem beschreibbaren DC erstellt wurde, kann zum Heraufstufen eines beschreibbaren DC,
RODC oder für eine Active Directory Lightweight Directory Services (AD LDS, ehemals ADAM) Instanz verwendet werden.

Weitere Informationen:
Error message when you try to create a RODC IFM in Windows Server 2008 if an earlier IFM procedure was canceled or has closed unexpectedly: “Could not initialize the Jet engine: Jet Error -1216”

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Yusuf Dikmenoglu — Sun, 13 Jan 2008 13:23:21 GMT

Der Windows Server 2008 bringt einige Verbesserungen bzw. Funktionen mit, die aber erst im Domänenfunktionsmodus
Windows Server 2008 zur Verfügung stehen. Damit z.B. mehrere Kennwortrichtlinien (Password Settings Objects)
in einer Domäne eingesetzt werden können, muss sich der Domänenfunktionsmodus auf Windows Server 2008 befinden.
Oder die Replikation des Sysvol-Verzeichnisses über die Distributed File System Replikation (DFS-R), ist ebenfalls nur im
Domänenfunktionsmodus Windows Server 2008 möglich.

Damit diese (und weitere) Funktionen genutzt werden können, muss zuerst eine Domänenaktualisierung der bestehenden
Gesamtstruktur auf Windows Server 2008 erfolgen.

Was ist möglich?

In einer Windows 2000 Gesamtstruktur kann ein Windows Server 2008 als zusätzlicher Domänencontroller (DC)
zu einer bestehenden Domäne hinzugefügt werden.
In einer Windows Server 2003/R2 oder SBS 2003 SP1/R2 Gesamtstruktur kann ein Windows Server 2008
als zusätzlicher Domänencontroller zu einer bestehenden Domäne hinzugefügt werden.
Ein Windows Server 2003 mit mindestens dem Service Pack 1 oder Windows Server 2003 R2 Domänencontroller,
kann per Inplace-Update auf Windows Server 2008 aktualisiert werden.

Was ist nicht möglich?

Ein Inplace-Update von Windows NT auf Windows Server 2008 ist nicht möglich.
Ein Inplace-Update von Windows 2000 auf Windows Server 2008 ist nicht möglich.
Ein Inplace-Update von einem Windows Server 2003/R2 Domänencontroller (oder Mitgliedsserver) worauf der
Exchange Server 2007 ohne/mit SP1 installiert ist, kann auf Windows Server 2008 nicht durchgeführt werden.

Ein installierter Exchange-Server auf einem DC ist nur ein Beispiel. Es muss vor einem Inplace-Update geprüft werden,
ob die installierten Applikationen auf dem DC, unter Windows Server 2008 noch funktionieren.
Ein Inplace-Update von früheren Server Betriebssystemen, ist auf den Windows Server 2008 Core nicht möglich.

Windows Server 2008 Core
Ein Cross-Update von einem x86 auf x64 System wird nicht supportet.
Ein Cross-Update auf eine andere Betriebssystem-Sprache wird nicht unterstützt. Als Beispiel, auf einem deutschen
Windows Server 2003 DC wird die englische Windows Server 2008 DVD eingelegt um den DC, auf einen
englischen Windows Server 2008 DC zu aktualisieren.

Voraussetzungen für eine Windows 2000/2003/R2 Gesamtstruktur, damit der erste
Windows Server 2008 DC hinzugefügt werden kann

Die Domäne in der man den Windows Server 2008 DC hinzufügen möchte, muss sich im einheitlichen Domänenfunktionsmodus
(entweder Windows 2000 pur oder Windows Server 2003) befinden. Dabei spielt es keine Rolle, auf welchem Modus sich der
Gesamtstrukturfunktionsmodus befindet.
Ist jedoch der Einsatz eines RODCs in der Gesamtstruktur geplant, so ist das erst ab der Gesamtstrukturfunktionsebene
Windows Server 2003 möglich. Des Weiteren muss sich bereits ein Windows Server 2008 DC in der Domäne befinden,
in der man den RODC hinzufügen möchte!
Alle Domänencontroller in der Gesamtstruktur sollten sich mindestens auf Windows 2000 Server mit Service Pack 4 befinden.

Step-by-Step Anleitung für eine Windows 2000/2003/R2 Gesamtstruktur, damit der erste
Windows Server 2008 DC hinzugefügt werden kann

Im ersten Schritt muss das Active Directory Preparation-Tool ADPREP, das auf der Windows Server 2008 DVD im Verzeichnis
"<DVD-Laufwerk>:\Sources\Adprep" mitgeliefert wird, mit dem Parameter /Forestprep auf dem Windows 2000 Server bzw.
Windows Server 2003 Schema-Master ausgeführt werden. Dadurch wird die Gesamtstruktur auf Windows Server 2008 aktualisiert.
Der Parameter /Forestprep wird nur ein einziges Mal in der Gesamtstruktur ausgeführt. Das Benutzerkonto mit dem das
Adprep /Forestprep ausgeführt wird, muss Mitglied der folgenden drei Sicherheitsgruppen sein:

- Organisations-Admins
- Schema-Admins
- Domänen-Admins in der Domäne, in der der Schema-Master Mitglied ist
Ruft man das Adprep /Forestprepnicht auf dem Schema-Master auf, bringt das Tool den Hinweis, dass die
Gesamtstrukturaktualisierung nur auf dem Schema-Master durchgeführt werden kann und bricht den Vorgang ab.
Es ist nun auch möglich, dass ADPREP von der 64Bit DVD des Windows Server 2008 auf einem
32Bit Windows Server 2003 DC auszuführen!

Microsoft empfiehlt das Verzeichnis <DVD-Laufwerk>:\Sources\Adprep vorher auf den Server zu kopieren, um z.B. Lesefehler
des DVD-Laufwerks während der Ausführung von Adprep zu vermeiden.

An error occurs when you run the ADPREP/FORESTPREP command on a Windows Server 2003-based or Windows Server 2008-based computer: "An attribute with the same link identifier already exists"
Mit Ausführen von Adprep /Forestprep wird die Gesamtstruktur auf Windows Server 2008 vorbereitet,
in dem neue Attribute sowie Klassen dem Schema hinzugefügt werden. Nach dem Aufruf von Adprep /Forestprep werden
abhängig von der Schema-Version die LDF-Dateien, die zur Schema-Aktualisierung benötigt werden, aus dem Verzeichnis
\Sources\Adprep in das Verzeichnis %windir%\system32 kopiert.

In einer Windows 2000 Gesamtstruktur werden die LDF-Dateien ab sch14.ldf, in einer Windows Server 2003
ab sch31.ldf und in einer Windows Server 2003 R2 Umgebung ab sch32.ldf bis zur sch44.ldf in das Schema importiert.
Das Schema wird somit auf die Version 44 aktualisiert.

Die Schema-Versionen wären (in Dezimal):

- Schema-Version 13 = Windows 2000 (ohne/mit allen SPs)
- Schema-Version 30 = Windows Server 2003 ohne/mit SP1/SP2 (und höhere SPs)
- Schema-Version 31 = Windows Server 2003 R2 ohne/mit SP2 (und höhere SPs)
- Schema-Version 44 = Windows Server 2008
- Schema-Version 47 = Windows Server 2008 R2

Die Schema-Version kann man sich auf jedem DC in der Gesamtstruktur zum einen in der Registry im Pfad:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>

… und zum anderen in dem Attribut objectVersion (z.B. mit ADSIEdit.msc oder LDP.exe), das sich in den
Eigenschaften der Schema-Partition CN=Schema,CN=Configuration,DC=<Domäne>,DC=<TLD> befindet, anzeigen lassen.

Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion

>
Wenn das Adprep /Forestprep durchgeführt wurde, wird in der Konfigurationspartition das Objekt
CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=<ForestRootDomäne> erstellt.

Dabei erhält das Attribut Revision im Objekt CN=ActiveDirectoryUpdate den Wert 2. Danach sollte sichergestellt werden,
dass sich dieses Objekt zuerst auf alle DCs der Gesamtstruktur repliziert, um dann den nächsten Schritt mit Adprep durchzuführen.
In erster Linie sollten die DC`s der einzelnen Domänen die Aktualisierung empfangen haben,
die die FSMO-Rolle des Infrastruktur-Master innehaben. Dazu gilt es den nächsten Punkt zu beachten.

Achtung: Wenn man das ADPREP /FORESTPREP auf dem Schema-Master ausführt und anschließend einfach nichts passiert,
also weder die Schemaerweiterung durchgeführt, noch eine Fehlermeldung angezeigt wird, so liegt mit hoher Wahrscheinlichkeit
ein "Sprach-Problem" vor. Wenn z.B. der Schema-Master auf einem englischen Betriebssystem läuft und man führt das ADPREP /FORESTPREP
von einer deutschen Windows Server 2008 DVD aus, so kommt es genau zu diesem Verhalten. Es ist zwingend notwendig auf einem
deutschen System, dass ADPREP von einer deutschen Windows Server 2008 DVD auszuführen.

Im zweiten Schritt muss das Adprep mit den Parametern „/Domainprep /Gpprep“ auf dem Infrastruktur-Master in der Domäne,
in der man den Windows Server 2008 als DC hinzufügen möchte, ausführen. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird,
muss Mitglied der Sicherheitsgruppe Domänen-Admins sein. Mit Ausführen von „/Domainprep /Gpprep“ wird die Domäne auf
Windows Server 2008 aktualisiert. Der Parameter /Domainprep bewirkt, dass neue Objekte erstellt sowie die ACLs an diversen
Objekten in der Domänenpartition geändert werden. Der Parameter /Gpprep sorgt dafür, dass die Berechtigungen der
Gruppenrichtlinienobjekte die sich im Sysvol-Verzeichnis befinden, angepasst werden.

Führt man diesen Befehl aus, noch bevor die Gesamtstrukturaktualisierung auf den Infrastruktur-Master repliziert wurde,
bricht der Vorgang ab. Dieser bricht auch dann ab, wenn der Befehl nicht auf dem Infrastruktur-Master ausgeführt wird.
Durch Ausführen dieses Befehls wird das folgende Objekt erstellt:
CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=<Domäne>

Das Attribut Revision im Objekt CN=ActiveDirectoryUpdate bekommt dabei den Wert 3.
Es ist möglich zuerst das Adprep lediglich mit dem Parameter /Domainprep auszuführen und zu einem späteren Zeitpunkt
die Berechtigungen der GPOs, mit Adprep /Domainprep /Gpprep zu aktualisieren. Empfehlenswert ist es aber,
dass in einem Schritt durchzuführen.
Wenn der Einsatz eines Read-Only Domain Controllers in irgendeiner Domäne der Gesamtstruktur geplant ist,
dann ist das Adprep mit dem Parameter /Rodcprep lediglich einmalig aufzurufen. Der DC, auf dem dieser Befehl
ausgeführt wird, muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen dieses Befehls werden die einzelnen
Infrastruktur-Master der Domänen kontaktiert, um die Berechtigungen (Security Descriptor, SD) der Domänen- sowie
Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.

Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com"

Es reicht völlig aus, diesen Befehl erst vor dem Hinzufügen des ersten RODC`s in der Gesamtstruktur auszuführen.
Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied in der Sicherheitsgruppe Organisations-Admins sein.
Nach Ausführung von /Rodcprep wird das folgende Objekt erstellt:
CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<ForestRootDomäne>.

Das Attribut Revision erhält dabei den Wert 2.

Read-Only Domain Controller (RODC)
Wenn eine Gesamtstruktur mit Windows Server 2008 erstellt wird, ist das Ausführen von Adprep in keinster Weise notwendig.
Weder der Parameter /Forestprep, noch „/Domainprep /Gpprep“ oder /Rodcprep müssen angewendet werden.
Es wird bei jedem Ausführen von Adprep im Verzeichnis %Systemroot%\Debug\Adprep\Logs ein Ordner erstellt,
dass als Namen das aktuelle Datum sowie die Uhrzeit erhält. Darin befindet sich das Adprep-Protokoll mit dem Namen ADPrep.log,
welches einen detaillierten Bericht zum Vorgang liefert. Wenn Adprep abbrechen oder einen Fehler melden sollte,
ist dieses Protokoll bei der Fehlersuche hilfreich.
Nach der Domänenaktualisierung auf Windows Server 2008, kann nun der neue Server als "zusätzlicher DC der bestehenden Domäne"
hinzugefügt werden. Während dem Heraufstufen zum DC sollte an entsprechender Stelle, dass DNS mit installiert und zusätzlich
der globale Katalog aktiviert werden. Anschließend sollten noch die FSMO-Rollen auf den Windows Server 2008 DC verschoben werden.

Globaler Katalog (Global Catalog - GC)
Der PDC-Emulator

Szenario 1

Migrations-Möglichkeiten von Windows NT auf Windows Server 2008

Es muss zuerst ein Inplace-Update vom Windows NT-PDC auf Windows Server 2003 mit mindestens dem Service Pack 1
durchgeführt werden. Erst dann kann per Inplace-Update auf Windows Server 2008 aktualisiert werden.
Das Update könnte mit einer VM durchgeführt werden.

Statt des Inplace-Updates von Windows Server 2003 auf Windows Server 2008, kann natürlich auch ein
zusätzlicher Windows Server 2008 hinzugefügt werden.

Im ersten Schritt kann von der NT-Domäne mit ADMT in eine Windows Server 2003 SP1 Domäne migriert und im zweiten Schritt
dann ein Inplace-Update auf Windows Server 2008 durchführt werden. Es bleibt abzuwarten, ob Microsoft ein aktualisiertes ADMT
veröffentlicht, wovon ich aber ausgehe.

Anstatt dann den Windows Server 2003 DC auf Windows Server 2008 zu aktualisieren, kann nach der Anwendung von Adprep ein
zusätzlicher Windows Server 2008 DC zur Domäne hinzugefügt werden.

>>

Szenario 2

Migrations-Möglichkeiten von Windows 2000 auf Windows Server 2008
1. Es ist zuerst ein Inplace-Update von Windows 2000 auf Windows Server 2003 mit mindestens dem Service Pack 1 durchzuführen.
  Erst dann kann per Inplace-Update auf Windows Server 2008 migriert werden.
  Ein Windows 2000 DC kann nicht direkt auf Windows Server 2008 aktualisiert werden, denn dieses wird erst ab
  Windows Server 2003 mit Service Pack 1 unterstützt.
  
  Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
  >>
  
  Szenario 3
  
  Migrations-Möglichkeiten von Windows Server 2003 auf Windows Server 2008
  1. Ist mindestens das Service Pack 1 für den Windows Server 2003 auf dem DC installiert, so kann mit einem Inplace-Update der
    Windows Server 2003 DC auf Windows Server 2008 aktualisiert werden. Die Step-by-Step Anleitung die am Anfang dieses Artikels
    beschrieben wird, ist dabei zuerst durchzuführen.
    >>
    
    Szenario 4
    
    Migrations-Möglichkeiten von Windows Server 2003 R2 auf Windows Server 2008
    1. Des Weiteren kann ein Windows Server 2003 R2 DC per Inplace-Update auf Windows Server 2008 aktualisiert werden.
      
      >>
      
      Probleme die nach dem Hinzufügen des ersten Windows Server 2008 DC entstehen können
      
      Client computers may not work correctly when you add a Windows Server 2008-based domain controller to an existing pre-Windows Server 2008 domain
      When a Windows NT 4.0-based computer tries to use the NETLOGON service to establish a security channel to a Windows Server 2008-based domain controller, the operation may fail
      Modify Default Security Policies on Windows Server 2008-Based Domain Controllers
      Group Policy settings are not applied on member computers that are running Windows Server 2008 or Windows Vista SP1 when certain SMB signing policies are enabled
      Office Communications Server 2007 or Live Communications Server 2005 does not work correctly after you upgrade a domain controller to Windows Server 2008
      You cannot locally configure or locally delete the application partitions that are created for IP telephony after you upgrade from Windows Server 2003 to Windows Server 2008
      RODC Compatibility Pack
      DCDIAG: NCSecDesc Fehler
      Description of the Microsoft server applications that are supported on Windows Server 2008
      You cannot remotely access encrypted files after you upgrade a Windows Server 2003 file server to Windows Server 2008
      
      Weitere Informationen:
      Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
      Information and resources to use when you plan to upgrade Windows Server 2003 to Windows Server 2008
      Adding a Server Running Windows Server 2008 to a Windows Small Business Server 2003 Network
      How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008 or Windows Vista
      How to back up and then restore printers when you upgrade from Windows Server 2003 to Windows Server 2008
      Client computers may not work correctly when you add a Windows Server 2008-based domain controller to an existing pre-Windows Server 2008 domain
      Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains
      
      >>>>>>> >>> >
      
      Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Windows Server 2008 Core

Yusuf Dikmenoglu — Sat, 29 Dec 2007 23:37:33 GMT

Microsoft führt mit dem Windows Server 2008 eine neue Installationsart ein.
Man könnte sagen, dass es ein abgespeckter Server ist. In dieser Installationsart steht z.B. weder der Windows Explorer,
noch eine GUI-Shell zur Verfügung. Bei dieser Variante der Installation, stehen lediglich einige wenige Serverrollen zur Verfügung.
Die Rede ist vom Windows Server Core. Die möglichen Rollen die auf einem Windows Server Core installiert werden können,
wären unter anderem: AD DS, AD LDS, DHCP, DNS, Hyper-V, Datei- Druck- sowie Webserver.
Welche Rollen oder Funktionen noch auf einem Server Core unterstützt werden, zeigt diese Seite:
Server Core Installation of Windows Server 2008

Dem Administrator steht nach der Betriebssysteminstallation lediglich eine Kommandozeile (CMD) zur Verfügung.
Für die Administratoren die sich schwer von der Maus trennen können (und wollen), hat Microsoft ebenfalls vorgesorgt.
Es besteht die Möglichkeit, sich remote über die MMCs auf einen Server Core zu verbinden, um diesen dann über die Snap-Ins zu administrieren.
Neben der Fernwartung durch die MMCs, lässt sich der Server Core mit den folgenden Punkten administrieren:

Terminal Services Remote Desktop
der Windows Remote Shell (WinRS)
dem Task Scheduler
SNMP
RPC und DCOM
WMI
GPOs

Darüber hinaus werden die Microsoft Operations Manager- sowie Systems Management Server-Agents, ebenso auf dem Server Core unterstützt.

Demzufolge das weniger Dienste und Applikationen auf einem Server Core laufen, reduziert sich die Verwaltung sowie Wartung des Servers.
Die Anzahl der zu installierenden Patches/SPs reduziert sich dabei ebenfalls, denn es gilt weniger Dienste abzusichern.
Der Server Core benötigt auch viel weniger Festplattenkapazität und ist schneller im Startverhalten als eine Vollinstallation.
Dadurch das weniger Funktionen bereitgestellt werden können, bietet der Server Core eine geringe Angriffsfläche an.
Folglich ist das Aufstellen eines solchen Servers z.B. in Umgebungen die eine hohe Sicherheitsanforderung haben, von Interesse.
Ein anderes Einsatzszenario wären Standorte. Dort wird oftmals ebenfalls ein Server vor Ort benötigt, sei es nun einen
Domänencontroller oder Mitgliedsserver, der aber dafür weniger Dienste als ein Server in der Zentrale bereitstellen muss.
Zusätzlich kommt noch hinzu, dass vor Ort in den Standorten meistens weniger IT Know-How als in der Zentrale zur Verfügung steht.
Auch in diesem Fall, würde sich das Aufstellen eines Server Cores vor Ort anbieten.

Falls vor Ort ein DC gewünscht ist, der nicht die gleiche physikalische Sicherheit wie ein DC in der Zentrale genießt,
würde sich eher der Read-Only Domain Controller (RODC) anbieten. Eine weitere Empfehlung wäre, Bitlocker einzusetzen.

Der Windows Server Core wurde in erster Linie für Umgebungen mit mehreren Servern entwickelt.
Der Großteil der Konfiguration des Server Cores, erfolgt mit dem Kommandozeilentool NETSH.

Anzeigen sowie installieren der Rollen bzw. optionalen Features

Mit Oclist werden nicht nur die zur Verfügung stehenden Serverrollen sowie die
optionalen Features angezeigt, sondern natürlich auch die bereits installierten.

Mit Ocsetup können die zur Verfügung stehenden Rollen sowie Features installiert- oder deinstalliert werden.
Zum installieren lautet die Syntax:

start /w ocsetup <Rolle>
start /w ocsetup <Feature>

Zum deinstallieren lautet es:

start /w ocsetup <Rolle> /uninstall
start /w ocsetup <Feature> /uninstall >

Achtung: Die Installation der einzelnen Rollen bzw. Features mit Ocsetup ist - warum auch immer - case sensitive!

Die Einschränkungen des Server Core

Es ist nicht möglich, auf einen Server Core von früheren Server-Version
(Windows 2000 Server oder Windows Server 2003/R2) zu aktualisieren

Eine Vollinstallation vom Windows Server 2008 kann nicht auf den Server Core konvertiert werden.

Der Server Core kann ebenfalls nicht zu einer Vollinstallation konvertiert werden.>
Der Server muss mit der gewünschten Version neu installiert werden.
Die verfügbaren APIs werden ausschließlich für die Entwicklung von Monitoring sowie Management Tools supportet.
Es existiert keine Explorer-Shell.
Es ist auch kein .Net Framework verfügbar. Im Windows Server 2008 R2 sind jedoch Teile des .NET Frameworks enthalten.
Der Server Core ist nicht die Plattform, auf dem die Entwicklung von Applikationen stattfinden sollte.
Es wird nicht die Windows Powershell unterstützt. Erst ab Windows Server 2008 R2 wird die Powershell auf dem Server Core unterstützt.
Es existieren keine MMCs auf dem Server Core.

Die Installation des Server Core

Das lokale Administrator-Kennwort vergeben

Nach der Betriebssysteminstallation wird man nach der Eingabe des Benutzernamens Administrator (ohne Kennwort) aufgefordert,
ein Kennwort für den lokalen Administrator, dass den lokalen Sicherheitsrichtlinien entspricht, einzugeben (z.B. Pa$$w0rd!).
Mit Eingabe von net user administrator * kann ein neues Kennwort vergeben werden.

Die Auflösung verändern

Standardmäßig existiert nach der Betriebssysteminstallation eine Auflösung von 640x480.
Dies kann in der Registry wie folgt geändert werden:

- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\<GUID>\0000\
Der Wert im Schlüssel DefaultSettings.XResolution muss bearbeitet werden (z.B. 1280 Dezimal).

- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\<GUID>\0000\
Der Wert im Schlüssel DefaultSettings.YResolution muss bearbeitet werden (z.B. 1024 Dezimal).

Unter Video existieren mehrere GUIDs. Die richtige GUID ist diejenige, die das Unterverzeichnis VolatileSettings beinhaltet.

Den Computernamen ändern

Während der Betriebssysteminstallation wird dem Server automatisch ein Computername vergeben.
Da aber bereits in vielen Unternehmensnetzwerken eine festgelegte Namenskonvention existiert, passt der vergebene Name
sicherlich nicht in die meisten Umgebungen. In Erfahrung kann man den Computernamen mit dem Befehl
Hostname oder IPCONFIG –ALL bringen.
Ein neuer Computername kann mit folgendem Befehl vergeben werden:
Netdom Renamecomputer ALTERCOMPUTERNAME /Newname:NEUERCOMPUTERNAME

Die anschließende Sicherheitsfrage ist mit einem Y zu bestätigen.
Im Anschluss ist ein Neustart mit dem Befehl shutdown –r bzw. shutdown –r –t 0 fällig.
Man kann aber auch direkt beide Befehle in einem zusammenfassen.
Das ganze würde dann so aussehen:
Netdom Renamecomputer ALTERCOMPUTERNAME /Newname:NEUERCOMPUTERNAME /Force /Reboot:ZahlinSekunden

Ist der Server Core bereits ein Mitgliedsserver, so lässt sich der Computername auf diese Weise ändern:
Netdom Renamecomputer ALTERCOMPUTERNAME /NewName:NEUERCOMPUTERNAME /userd:<Domäne\Administrator> /passwordd:*

Die IPv4 Adresse eintragen

Bevor eine IP-Adresse eingetragen werden kann, muss sichergestellt sein, dass der Treiber für die Netzwerkkarte installiert wurde.
Wird beim Aufruf von IPCONFIG lediglich der Eintrag Windows-IP-Konfiguration angezeigt, so ist die Netzwerkkarte nicht installiert.
Es sollte der Eintrag „Ethernet-Adapter LAN-Verbindung“ auftauchen.

Mit dem folgenden Befehl:
Netsh int ipv4 set addr "LAN-Verbindung" static 192.168.178.10 255.255.255.0 192.168.178.1

wird die IPv4-Adresse 192.168.178.10, dass Subnetz 255.255.255.0 und das Gateway 192.168.178.1 vergeben.
Wichtig an dieser Stelle wäre zu erwähnen, dass der Name der LAN-Verbindung bekannt sein muss!
Diesen erfährt man mit dem Befehl Netsh int ip sh int oder durch IPCONFIG –ALL.
Denn auf einem englischen System lautet dieser: Local Area Connection.
Eine andere Vorgehensweise zum vergeben der IPv4-Adresse wäre, zuerst mit dem Befehl Netsh interface ipv4 show interfaces
den Wert in der Spalte idx für die Netzwerkverbindung herauszufinden und anschließend mit dem Befehl (alles in einer Zeile)
Netsh int ipv4 set address name="<IDX-Wert>" source=static address=192.168.178.10 mask=255.255.255.0
gateway=192.168.178.1 die IP-Adresse einzutragen.

Das IPv6-Protokoll deaktivieren

Wenn das IPv6-Protokoll nicht verwendet wird, kann es deaktiviert werden.
Dazu gilt es mit Regedit die Registry aufzurufen und im Pfad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\ den Schlüssel DWORD-32Bit
(sowohl auf einem 32Bit als auch auf einem 64Bit System) DisabledComponents mit dem Hex-Wert 0xFFFFFFFF zu erstellen.
Nach einem Neustart ist das IPv6-Protokoll deaktiviert.

Eine DNS-Server IP-Adresse eintragen/entfernen

Die IP-Adresse eines bestehenden DNS-Servers lässt sich wie folgt eintragen:
Netsh int ip set dns "LAN-Verbindung" static 192.168.178.5 primary
Einen weiteren DNS-Server trägt man mit diesem Befehl ein:
Netsh int ip add dns "LAN-Verbindung" 192.168.178.6
Entfernen lässt sich eine DNS-Server Adresse mit diesem Befehl:
Netsh int ip delete dns "LAN-Verbindung" 192.168.178.6
Alle DNS-Server Adressen lassen sich folgendermaßen entfernen:
Netsh int ip delete dns "LAN-Verbindung" all

Eine WINS‑Server IP-Adresse eintragen/entfernen

Ein WINS-Server lässt sich auf diese Art eintragen:
Netsh int ip add winsserver "LAN-Verbindung" 192.168.178.5
Einen zweiten WINS-Server kann man wie folgt eintragen:
netsh interface ipv4 add winsserver name="Local Area Connection" address=10.0.0.12 index=2
Entfernen lässt sich ein WINS-Eintrag mit diesem Befehl:
Netsh int ip delete wins "LAN-Verbindung" 192.168.178.5
Möchte man alle WINS-Einträge entfernen, so geht das folgendermaßen:
Netsh int ip delete wins "LAN-Verbindung" all

Den Server zu/aus der Domäne hinzufügen/entfernen

Mit diesem Befehl, lässt sich der Server Core zum Mitgliedsserver einer Domäne hinzufügen:
Netdom join <ComputerName> /domain:<DomänenName> /userd:Administrator /passwordd:Pa$$w0rd!
Aus der Domäne lässt sich der Server Core wie folgt nehmen:
Netdom remove /d:<Domäne> <PC-Name Core>

Den Server Core zum Domänencontroller heraufstufen (promoten)

Das Active Directory lässt sich auf einem Server Core nicht wie die anderen Rollen mit Ocsetup,
sondern ausschließlich durch den Dcpromo-Assistenten installieren. Der Aufruf von Dcpromo, kann auf einem
Server Core nicht wie auf den normalen Server-Versionen gestartet, sondern muss entweder mit einer Antwortdatei
oder durch die unbeaufsichtigte Installation Dcpromo /unattend aufgerufen werden.
Mit der Angabe einer Antwortdatei wird der Server Core wie folgt zum Domänencontroller (DC) gestuft:
DCPROMO /unattend:E:\DCCorepromote.txt

Durch die Antwortdatei, kann auf dem Server Core das DNS gleich mit installiert sowie der globale Katalog
aktiviert werden (was beides zu empfehlen wäre). Zur Arbeitserleichterung kann man sich beim Ausführen von Dcpromo
auf einem vollinstallierten Server, am Ende des Assistenten die Einstellungen exportieren lassen.
Wie eine solche Antwortdatei aussehen könnte, steht am Ende dieses Artikels.
Der Befehl für einen zusätzlichen Server Core DC, könnte bei der unbeaufsichtigten Variante wie folgt aussehen (alles in einer Zeile):

dcpromo /unattend /replicaOrNewDomain:replica /replicaDomainDNSName:intra.dikmenoglu.de
/sitename:Default-First-Site-Name /InstallDns:yes /CreateDNSDelegation:no /confirmGC:yes /UserDomain:intra.dikmenoglu.de
/UserName:intra.dikmenoglu.de\Administrator /Password:DomänenAdminKennwort /databasePath:"C:\Windows\Ntds"
/logPath:"C:\Windows\Ntds" /sysvolpath:"C:\Windows\Sysvol" /safeModeAdminPassword:SchweresPa$$w0rd!
/rebootOnCompletion:yes

Promotion Operation
Wird der Server Core, der erste Windows Server 2008 Domänencontroller in einer Windows 2000 oder
Windows Server 2003 Gesamtstruktur, so muss vorher das ADPREP von der Windows Server 2008 DVD
(aus dem Verzeichnis DVD-Laufwerk:\Sources\Adprep) ausgeführt werden. Microsoft empfiehlt vorher das Verzeichnis
Adprep auf den Server zu kopieren und anschließend, dass ADPREP von dort zu starten. Damit sollen Lesefehler des
DVD-Laufwerks vorgebeugt werden, die während dem Ausführen von ADPREP auftreten könnten.
Das ADPREP ist zuerst auf dem Schemamaster mit dem Parameter /FORESTPREP und auf dem Infrastrukturmaster in
der Domäne, zu der der Windows Server 2008 hinzugefügt werden soll, mit den Parametern „/DOMAINPREP /GPPREP“ auszuführen.

Soll der Server Core der erste Windows Server 2008 als RODC in einer Windows Server 2003 Gesamtstruktur werden
(dazu muss sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 befinden), so gilt es vorher das
ADPREP mit dem Parameter /RODCPREP lediglich ein einziges Mal für die Gesamtstruktur (und nicht in jeder Domäne) auszuführen.

Den Server Core zum Mitgliedsserver herunterstufen (demoten) >

Herunterstufen (demoten) zu einem Mitgliedsserver lässt sich der Server Core DC ebenfalls, entweder mit DCPROMO
und einer Antwortdatei (siehe unten stehende Antwortdatei Beispiele) oder durch die unbeaufsichtigte Variante.
Der Aufruf mit einer Antwortdatei, sieht so aus: DCPROMO /unattend:E:\DCCoredemote.txt
Das Herunterstufen zu einem Mitgliedsserver bei der unbeaufsichtigten Variante, könnte auf einem zusätzlichen Server Core DC
der nicht die FSMO-Rollen trägt, wie folgt aussehen (alles in einer Zeile):

dcpromo /unattend /AdministratorPassword:"Pa$$w0rd!" /IgnoreIsLastDnsServerForZone:yes
/IgnoreIsLastDCInDomainMismatch:yes /RebootOnSuccess:yes

Demotion Operation >

>>>

DHCP-Server installieren/deinstallieren

Möchte man den DHCP-Server auf einem Server Core installieren, so lässt sich das mit diesem Befehl realisieren:
start /w ocsetup DHCPServerCore
Deinstallieren lässt sich der DHCP mit einem /uninstall am Ende: start /w ocsetup DHCPServerCore /uninstall
Die Konfiguration des DHCP-Servers (Bereiche, Optionen etc.) erfolgt über NETSH oder remote von
einem anderen Server aus, mit dem DHCP Snap-In.
Die DHCP-Konfiguration über NETSH könnte wie folgt aussehen:

netsh dhcp server 192.168.178.5 add scope 192.168.178.0 255.255.255.0 DHCPCore CoreBereich

Den DHCP-Bereich festlegen
netsh dhcp server 192.168.178.5 scope 192.168.178.0 add iprange 192.168.178.1 192.168.178.254

Ausschlussbereich
netsh dhcp server 192.168.178.5 scope 192.168.178.0 add excluderange 192.168.178.40 192.168.178.60

Die Router-Option setzen
netsh dhcp server 192.168.178.5 scope 192.168.178.0 set optionvalue 003 IPADDRESS 192.168.178.1

Den DNS-Server setzen
netsh dhcp server 192.168.178.5 scope 192.168.178.0 set optionvalue 006 IPADDRESS 192.168.178.5 192.168.178.6

Den DHCP-Bereich aktivieren
netsh dhcp server 192.168.178.5 scope 192.168.178.0 set state 1
Der Dienst des DHCP-Servers wird nach der Installation nicht gestartet.
Des Weiteren steht der Starttyp des DHCP-Servers in der Dienstesteuerung nach der Installation, auf Deaktiviert.
Um den DHCP-Server Dienst zu starten, ist folgender Befehl auszuführen: net start dhcpserver
Den Starttyp stellt man mit diesem Befehl auf Automatisch:
sc config dhcpserver start= auto (Achtung: Nach dem Gleichheitszeichen muss ein Leerzeichen folgen!)
Deaktiveren lässt sich der Starttyp so: sc config dhcpserver start= disabled
Befindet sich der Server Core in einer Active Directory Umgebung, so muss der DHCP-Server zusätzlich noch
im Active Directory autorisiert werden. Auch dies lässt sich über NETSH (neben der DHCP-MMC auf einem
vollwertigen Server) realisieren. Der Befehl zum autorisieren lautet:
netsh dhcp add server Lhcore01.intra.dikmenoglu.de 192.168.178.5
Wenn hingegen ein DHCP-Server aus der Liste der autorisierten DHCP-Server im Active Directory entfernt werden soll,
so lautet der Befehl: netsh dhcp delete server Lhcore01.intra.dikmenoglu.de 192.168.178.5

DNS-Server installieren/deinstallieren

Den DNS-Server installiert man wie folgt: start /w ocsetup DNS-Server-Core-Role
Deinstallieren lässt sich der DNS-Server auf diese Weise: start /w ocsetup DNS-Server-Core-Role /uninstall
Der DNS-Server lässt sich zum einen mit dem Kommandozeilen-Tool dnscmd und zum anderen remote mit dem DNS Snap-In konfigurieren.

WINS-Server installieren/deinstallieren

Der WINS-Server lässt sich folgendermaßen installieren: start /w ocsetup WINS-SC
Die Deinstallation des WINS-Servers, lässt sich auf die Art durchführen: start /w ocsetup WINS-SC /uninstall

Hyper-V auf einem Server Core installieren

Das Hyper-V lässt sich auf einem Windows Server 2008 Enterprise - Server Core wie folgt installieren:
bcdedit /set hypervisorlaunchtype auto (dieser Befehl ist nicht zwingend, aber ohne ihn sind zwei Neustarts fällig)
start /w ocsetup Microsoft-Hyper-V
Von einem vollwertigen Server auf dem das Hyper-V ebenfalls installiert ist, kann nun das Hyper-V auf dem Server Core
konfiguriert werden. Microsoft arbeitet aber zurzeit an einer MMC für Windows Vista/Windows Server 2008 Vollinstallation.

Die Druckdienste installieren/deinstallieren

Die Druckdienste können wie folgt installiert: start /w ocsetup Printing-ServerCore-Role
…und auf diese Art deinstalliert werden: start /w ocsetup Printing-ServerCore-Role /uninstall

Den Server Core aktivieren

Der Server Core kann mit diesem Befehl aktiviert werden: Cscript C:\Windows\system32\SLmgr.vbs –ato
Das Ablaufdatum der Lizenz, kann man wie folgt herausfinden: Cscript C:\Windows\system32\slmgr.vbs -xpr
Falls zum Zeitpunkt der Aktivierung keine Internetverbindung besteht, kann durch einen gebührenfreien Anruf
(Deutschland Tel.: 0800-284 828 3) bzw. den gebührenpflichtigen Anruf (Deutschland Tel.: 069-500 700 25)
bei Microsoft der Server telefonisch aktiviert werden. Eine andere Möglichkeit wäre mittels dem Key Management Server (KMS)
die Aktivierung zu vollziehen. Die Rufnummern für die einzelnen Länder stehen im übrigen in der Datei phone.inf,
dass sich im folgenden Pfad befindet: %windir%\system32\slui\phone.inf.
Die Installations-ID für die telefonische Aktivierung, kann so herausgefunden werden: Cscript C:\Windows\system32\slmgr.vbs -dti
Anschließend kann der Server manuell aktiviert werden: Cscript c:\windows\system32\slmgr.vbs –atp GUID <Bestätigungs-ID>

Die AD LDS installieren

Die Active Directory Lightweight Directory Services lassen sich auf diese Art installieren:
start /w ocsetup DirectoryServices-ADAM-ServerCore

Die Windows Remote Shell aktivieren

Die Windows Remote Shell (WinRS) lässt sich so aktivieren: WinRM quickconfig
Durch die Bestätigung mit Y wird die WinRS endgültig aktiviert.
Nun kann von einem Remote-Host durch Aufruf des folgenden Befehls in einer Kommandozeile,
der Server Core aus der CMD heraus, administriert werden: winrs -r:<ServerCore> cmd

Eine neue Kommandozeile CMD öffnen

Hat man aus Versehen die Kommandozeile geschlossen, kann man durch drücken von STRG+SHIFT+ENTF den Taskmanager
aufrufen und mit einem neuen Task die CMD erneut aufrufen. Oder im Taskmanager ABMELDEN wählen und sich neu an dem
System anmelden. Ein Neustart bringt die CMD natürlich genauso zum Vorschein.
Deshalb wäre es sinnvoll gleich zu Beginn der Anmeldung, eine weitere CMD mit start cmd /separate zu starten.

Die Windows Firewall konfigurieren

netsh advfirewall

Die Energieeinstellungen konfigurieren

Powercfg

Die Windows Updates konfigurieren

Um die automatischen Windows Updates zu aktivieren, gilt es diesen Befehl einzugeben:
Cscript C:\Windows\system32\Scregedit.wsf /au 4
Deaktivieren lassen sich die Windows Updates wie folgt: Cscript C:\Windows\system32\Scregedit.wsf /au 1
Die aktuelle Einstellung kann wie folgt herausgefunden werden: Cscript C:\Windows\system32\Scregedit.wsf /au /v

Die Systeminformationen anzeigen lassen

Die Systeminformationen lassen sich durch die Eingabe von systeminfo.exe anzeigen.

Die Zeit/Zeitzone sowie Regions- und Sprachoptionen konfigurieren

Das Datum, die Zeit oder die Zeitzone lassen sich durch die Eingabe von control timedate.cpl konfigurieren.
Die gewünschte Regions- und Sprachoptionen kann man mit dem Befehl control intl.cpl auswählen.

Die Installation von Treibern

Wenn der Treiber im Server Core enthalten ist, wird der Treiber für die Hardware automatisch bei der Betriebssysteminstallation installiert.
Oder wenn die Hardware nachträglich eingebaut wird, installiert sich der Treiber dank Plug and Play (PNP) automatisch.
Ist der Hardware-Treiber nicht im Betriebssystem enthalten, so gilt es diesen beim Hersteller zuerst herunterzuladen.
Falls keine Windows Server 2008 Treiber vom Hersteller bereitgestellt werden, reicht oftmals der Treiber für Windows Vista aus.
Der heruntergeladene Treiber sollte entweder entpackt und wie folgt installiert werden:
Pnputil –i –a <Pfad>\<Treiber>.inf

..oder der Treiber (evtl. eine Setup.exe) lässt sich direkt vom USB-Sick/CD auf dem Server Core ausführen und installieren.
Wird eine bestehende z.B. on-Board Intel Netzwerkkarte nicht bei der Betriebssysteminstallation gleich mit installiert,
ist zuerst der entsprechende Treiber herunterzuladen (der Treiber für Windows Vista), diesen auf einen USB-Sick bzw. CD
zu packen und anschließend die heruntergeladene Setup.exe auszuführen. Der Assistent für den Treiber der einen durch die
Installation führt, ist der gleiche wie auf einem vollwertigen Server.

Wenn jemandem die langen und aufwändigen Befehle in der Kommandozeile zum konfigurieren des Server Core nicht so sehr liegt, der sollte sich einmal diese Tools anschauen:
Tools zum konfigurieren des Server Core

Beispiele einer Antwortdatei

Erster DC einer neuen Gesamtstruktur:

[DCInstall]
; New forest promotion
ReplicaOrNewDomain=Domain
NewDomain=Forest
NewDomainDNSName=intra.dikmenoglu.de
ForestLevel=3
DomainNetbiosName=DIKMENOGLU
DomainLevel=3
InstallDNS=Yes
CreateDNSDelegation=No
ConfirmGc=Yes
DatabasePath=C:\Windows\NTDS
LogPath=C:\Windows\NTDS
SYSVOLPath=C:\Windows\SYSVOL
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
; CriticalReplicationOnly=Yes
RebootOnCompletion=Yes
TransferIMRoleIfNecessary=No

Zusätzlicher Domänencontroller:

[DCInstall]
; Replica DC promotion
ReplicaOrNewDomain=Replica
ReplicaDomainDNSName=intra.dikmenoglu.de
SiteName=Default-First-Site-Name
InstallDNS=Yes
CreateDNSDelegation=No
ConfirmGc=Yes
UserDomain=intra.dikmenoglu.de
UserName=dikmenoglu\administrator
Password=Pa$$w0rd!
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
; CriticalReplicationOnly=Yes
RebootOnCompletion=Yes

Erster DC einer neuen Sub-Domäne:

[DCInstall]
; New child domain promotion
ReplicaOrNewDomain=Domain
NewDomain=Child
ParentDomainDNSName=intra.dikmenoglu.de
ChildName=child
DomainNetbiosName=CHILDDOMAENE
DomainLevel=2
SiteName=Mainz
InstallDNS=Yes
CreateDNSDelegation=Yes
ConfirmGc=Yes
DNSDelegationUserName=dikmenoglu\administrator
DNSDelegationPassword=*
UserDomain=intra.dikmenoglu.de
UserName=dikmenoglu\administrator
Password=Pa$$w0rd!
ReplicationSourceDC=LHDCON01.intra.dikmenoglu.de
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
RebootOnCompletion=Yes

RODC:

[DCInstall]
; Read-Only Replica DC promotion
ReplicaOrNewDomain=ReadOnlyReplica
ReplicaDomainDNSName=intra.dikmenoglu.de
; RODC Password Replication Policy
PasswordReplicationDenied="VORDEFINIERT\Administratoren"
PasswordReplicationDenied="VORDEFINIERT\Server-Operatoren"
PasswordReplicationDenied="VORDEFINIERT\Sicherungs-Operatoren"
PasswordReplicationDenied="VORDEFINIERT\Konten-Operatoren"
PasswordReplicationDenied="DIKMENOGLU\Abgelehnte RODC-
Kennwortreplikationsgruppe"
PasswordReplicationAllowed="DIKMENOGLU\Zulässige RODC-Kennwortreplikationsgruppe"
PasswordReplicationAllowed=Gruppe1
PasswordReplicationAllowed=Benutzer1
PasswordReplicationAllowed=ComputerName1
DelegatedAdmin="DIKMENOGLU\RODC-Admins"
SiteName=Default-First-Site-Name
InstallDNS=Yes
ConfirmGc=Yes
CreateDNSDelegation=No
UserDomain=intra.dikmenoglu.de
UserName=intra.dikmenoglu.de\Administrator
Password=Pa$$w0rd!
; In der nächsten Zeile kann man einen Quell-DC angeben,
; mit dem die AD-Replikation stattfinden soll.
ReplicationSourceDC=LHDCON01.intra.dikmenoglu.de
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\SYSVOL"
SafeModeAdminPassword=SchweresPa$$w0rd!
; Run-time flags (optional)
; CriticalReplicationOnly=Yes
RebootOnCompletion=Yes

Einen Domänencontroller herunterstufen (demoten):

[DCINSTALL]

AdministratorPassword="Pa$$w0rd!"

IgnoreIsLastDnsServerForZone=Yes

IgnoreIsLastDCInDomainMismatch=Yes

RebootOnSuccess=Yes

Gesamtstrukturfunktionsmodus (ForestLevel):

0 = Windows 2000
Wenn diese Gesamtstrukturfunktionsebene gewählt wird, dann kann sich der Domänenfunktionsmodus (DomainLevel) der einzelnen
Domänen im Modus Windows 2000 pur (0), Windows Server 2003 (2) und Windows Server 2008 (3) befinden.

2 = Windows Server 2003
In dieser Gesamtstrukturfunktionsebene können Domänen im Domänenfunktionsmodus Windows Server 2003 (2) und
Windows Server 2008 (3) existieren.

3 = Windows Server 2008
In dieser Gesamtstrukturfunktionsebene können ausschließlich Domänen in der Domänenfunktionsebene
Windows Server 2008 (3) in der bestehenden Gesamtstruktur existieren.

4 = Windows Server 2008 R2
In dieser höchsten Gesamtstrukturfunktionsebene können ausschließlich Domänen in der Domänenfunktionsebene
Windows Server 2008 R2 (4) in der bestehenden Gesamtstruktur existieren.

Weitere Informationen:
Server Core Installation Option of Windows Server 2008 Step-By-Step Guide
Determining if Server Core is Running (Windows)
How to Use Netsh.exe to Authorize, Unauthorize and List DHCP Servers in Active Directory

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.