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
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.
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 BestPrctices
- 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.
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.
- 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 Schema-Master 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.
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
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 DCs zu berechnen.
Aber eins kann man mit Gewissheit empfehlen, jede Domäne sollte (um nicht zu sagen müsste) wegen der Ausfallsicherheit und Verfügbarkeit mindestens zwei Domänencontroller enthalten.
Damit ist zumindest sichergestellt, dass bei einem DC-Crash der andere 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
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
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.
-
-
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
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”
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 /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.
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
-
In einer Windows 2000 Active Directory Umgebung kann die Domänenaktualisierung auf Windows Server 2008 über einen
zusätzlichen Windows Server 2008 DC realisiert werden. Dazu ist zuerst die Step-by-Step Anleitung durchzuführen,
die am Anfang dieses Artikels beschrieben ist. Anschließend kann ein Windows Server 2008 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 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
-
Wie in einer Windows 2000 Gesamtstruktur kann auch in einer Windows Server 2003 Gesamtstruktur die Domänenaktualisierung über einen
zusätzlichen Windows Server 2008 Domänencontroller erfolgen. Natürlich auch nur dann, wenn die Step-by-Step Anleitung durchgeführt wurde.
-
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
-
Da in einem Windows Server 2003 R2 ein Windows Server 2003 mit mindestens dem Service Pack 1 enthalten ist,
kann nach vorheriger Ausführung von Adprep ein zusätzlicher Windows Server 2008 DC zur bestehenden Gesamtstruktur hinzugefügt werden.
-
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
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:
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
-
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
Jeder der mit der Additional Account Info DLL (acctinfo.dll) schon einmal gearbeitet hat, weiß diese zusätzlichen Angaben zu schätzen.
Die zusätzlichen Angaben werden in einem weiteren Reiter, in den Benutzereigenschaften angezeigt. Diese DLL befindet sich in den
Account Lockout and Management Tools. Dort ist sie mit der Versionsnummer 1.0.0.1111 vorhanden. Nach dem registrieren dieser DLL,
taucht in den Eigenschaften eines Benutzerobjekts eine weitere Registerkarte auf. Dieser Reiter erscheint nur auf der Maschine,
auf dem diese DLL registriert wurde (und steht somit nicht domänenweit auf jedem Client/Server zur Verfügung). Dort steht z.B.
wann die letzte Benutzeranmeldung erfolgt ist oder wann das Kennwort des Benutzers ausläuft.
Siehe: Die letzte Benutzeranmeldung herausfinden
Der Reiter taucht aber nur dann auf, wenn das Benutzerobjekt direkt (Doppelklick auf das Benutzerobjekt) oder über eine
gespeicherte Abfrage aufgerufen wird. Wird hingegen die Active Directory Suche verwendet, erscheint dieser Reiter nicht.
Das kommt daher, da die Version 1.x lediglich eine Erweiterung in Form einer weiteren Registerkarte in den Eigenschaften des Benutzerobjekts ist.
Die Suche im Active Directory erfolgt z.B. im Snap-In Active Directory-Benutzer und -Computer mit einem Rechtklick auf einer OU oder auf den FQDN.
Des Weiteren ist in der Version 1.x ein Fehler enthalten, denn es zeigt einen Wert im Last-Logon-Timestamp an, obwohl sich die
Domäne nicht im Domänenfunktionsmodus Windows Server 2003 befindet.
Es existiert mittlerweile eine neuere Version dieser DLL und trägt den Namen Acctinfo2.dll (beachtet unten stehende Anmerkung).
In der neueren Version ist die acctinfo2.dll nicht nur ein weiterer Reiter, sondern ein Display Specifier. Dadurch taucht nun auch bei
einer Suche der Reiter auf. Mit dieser Version der DLL, wird desweiteren nicht mehr der Last-Logon-Timestamp im Reiter angezeigt,
sondern erst, wenn sich die Domäne tatsächlich im Domänenfunktionsmodus Windows Server 2003 befindet. Außerdem werden
zusätzliche Informationen bereitgestellt.
Installation
Die Acctinfo2.dll muss zuerst ins Verzeichnis %windir% verschoben werden.
Im nächsten Schritt ist diese DLL, entweder unter Start - Ausführen oder in einer Kommandozeile mit dem Befehl
regsvr32 acctinfo2.dll zu registrieren.
Als nächstes ruft man ADSIEdit (aus den Windows Support Tools) auf und navigiert in der Konfigurationspartition zu folgendem Pfad:
CN=user-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=TLD
Hinweis: Läuft der Windows Server mit einer englischen Betriebssystem Version, so lautet die Länderkennung nicht CN=407 sondern CN=409.
Dort angelangt, sind die Eigenschaften von CN=user-Display aufzurufen.
Anschließend gilt es im Attribut adminPropertyPages den folgenden Eintrag hinzuzufügen:
2,{5969F63F-CACF-40bf-8891-CA580EB589E9}
Am Anfang des Eintrags (2,..) ist ein freier oder der nächst höhere Wert zu wählen, gefolgt von einem Komma und der GUID
der Acctinfo2.dll (in geschweiften Klammern).
Danach steht ab sofort der neue Reiter in den Benutzereigenschaften zur Verfügung.
Weiterhin ist es möglich, dass beide Versionen (1.x sowie 2.x) nebeneinander existieren.
Anmerkung: Die aktuelle und von Microsoft unterstütze AcctInfo.dll ist in den Account Lockout and Management Tools enthalten und kann
kostenlos heruntergeladen werden. Wann und ob Microsoft die Version 2.x veröffentlichen wird (zum Download bereitstellt), ist zum jetzigen
Zeitpunkt nicht bekannt. Sobald es Nähere Informationen darüber geben wird, werde ich es hier veröffentlichen.
Möchte man die letzte Anmeldung eines Benutzers herausfinden, so führen zu diesem Vorhaben mehrere Wege zum Ziel.
Die benötigte Information lässt sich wie vieles (aufwändig) über das ADSI auslesen.
Das Attribut in dem die letzte Anmeldung gespeichert wird, lautet Last-Logon.
Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern repliziert wird.
Es gilt also das Attribut Last-Logon auf jedem Domänencontroller in der Domäne abzufragen um das aktuellste Datum herauszufinden.
Additional Account Info - AcctInfo.dll
Eine recht einfache Möglichkeit wäre (unter Windows 2000/2003/2008), sich die Account Lockout and Management Tools herunterzuladen
und die AcctInfo.dll zu nutzen. Diese DLL muss vorher registriert werden. Dazu extrahiert man zuerst die heruntergeladene Datei in ein
Verzeichnis (z.B. C:\Tools), öffnet eine Kommandozeile (CMD) und navigiert zu den entpackten Dateien. Anschließend registriert man mit
folgendem Befehl die DLL: regsvr32 acctinfo.dll. Danach erscheint im Snap-In Active Directory-Benutzer und -Computer in den
Eigenschaften der Benutzer ein weiterer Reiter. Dieser neue Reiter zeigt unter anderem die letzte Benutzeranmeldung an:
Hinweis: Wenn ein Benutzer in der MMC über eine Suche aufgerufen wird, ist dieser Reiter nicht zu sehen.
Dieser Reiter erscheint lediglich auf dem Arbeitsplatz/Server, auf dem die DLL registriert wurde. Um den Reiter zu entfernen,
muss der Befehl (über Start – Ausführen) regsvr32 /u <Pad zur AcctInfo.dll> ausgeführt werden.
Das Attribut Last-Logon-Timestamp
Wie vieles andere wurde auch dieses Verhalten in Windows Server 2003 verbessert.
Im Schema des Windows Server 2003 wurde ein neues Attribut namens Last-Logon-Timestamp dem Benutzer-Objekt hinzugefügt.
Wenn sich die Domäne im Domänenfunktionsmodus Windows Server 2003 befindet, kann man das Attribut Last-Logon-Timestamp nutzen.
Dieses Attribut ist aber vom Attribut Last-Logon abhängig. Würde z.B. bei einer Benutzer-Anmeldung das Attribut Last-Logon nicht gesetzt,
wird auch das Attribut Last-Logon-Timestamp nicht aktualisiert. Es bietet allerdings den Vorteil, dass es auf andere DCs repliziert wird und somit
einem das durchsuchen aller DCs erspart bleibt. Jedoch wird Last-Logon-Timestamp (um die Replikationslast gering zu halten) standardmäßig alle 14 Tage,
abzüglich einer zufällig gewählten Differenz von bis zu 5 Tagen aktualisiert. Das Attribut wird also zwischen zehn und vierzehn Tagen repliziert.
Wird nun das Attribut Last-Logon aktualisiert, überprüft der DC ob das Aktualisierungsintervall das in dem Attribut ms-DS-Logon-Time-Sync-Interval
angegeben ist, erreicht wurde, um dann Last-Logon-Timestamp zu aktualisieren.
Das Aktualisierungsintervall von Last-Logon-Timestamp wird im Attribut ms-DS-Logon-Time-Sync-Interval gesteuert.
Dieses Attribut befindet sich in den Eigenschaften der Domänenpartition und lässt sich z.B. mit ADSIEdit bearbeiten.
Der Wert dieses Attributs ist standardmäßig <Not Set> und bedeutet einen Standardwert von 14 Tagen.
Dieser Wert kann zwischen 1 und 100.000 Tage betragen. Trägt man als Wert 0 ein, wird das Attribut Last-Logon-Timestamp nicht mehr aktualisiert.
Ein zweimonatiger Test mit 50 Benutzerkonten in einer produktiven Umgebung hat ergeben, dass die Aktualisierung von Last-Logon-Timestamp
(mit einem Standardwert im Attribut ms-DS-Logon-Time-Sync-Interval) bei 80% der Benutzerkonten, ausgeglichen zwischen zehn und elf Tagen lag.
Wenn ein DC unter Windows Server 2003 (ohne SP1) läuft, kann es unter Umständen vorkommen, dass dieses Attribut nicht aktualisiert wird:
A network logon that uses NTLM authentication does not update the lastLogonTimestamp attribute in the Active Directory schema of a Windows Server 2003-based domain controller
Sowohl das Attribut Last-Logon, als auch Last-Logon-Timestamp, sind Integer8 Datentypen.
Diese haben eine Länge von 8 Byte bzw. 64 Bit. Die Zeit wird ab dem 1. Januar 1601 12:00 AM im 100 Nanosekunden Intervall berechnet.
Der Wert aus Last-Logon oder Last-Logon-Timestamp wird in der Greenwich Mean Time (GMT) Zone im Active Directory gespeichert und muss
in ein leserliches Datumsformat konvertiert werden, da man ansonsten mit dem Wert (der in etwa so aussieht: 128362271633877741) nicht
sonderlich viel anfangen kann. Zum konvertieren gibt man in der Kommandozeile den Befehl w32tm /ntte <Wert> ein.
Benutzer die sich länger nicht an der Domäne angemeldet haben
Benutzerkonten die sich seit längerem an der Domäne nicht authentifiziert haben, lassen sich recht schnell auf verschiedene Weise herausfinden.
Hinweis: Die folgenden Beispiele benötigen die Domänenfunktionsebene Windows Server 2003!
1. Das Snap-In Active Directory-Benutzer und –Computer (ADBuC)
In der MMC ADBuC kann man sich eine Allgemeine Abfrage durch eine Suche (Rechtsklick auf die Domäne) oder durch eine Gespeicherte Abfrage erstellen.
Dort gilt es die Auswahl bei der Option Tage seit der letzten Anmeldung zwischen 30, 60, 90, 120 oder 180 zu treffen.
Der Wert ist nicht frei definierbar sondern fest vorgegeben:
2. Dsquery
Mit einem der DS*-Tools die standardmäßig im Windows Server 2003 integriert sind, lässt sich eine einfache Abfrage erstellen.
Die Rede ist von DSQUERY. Die Abfrage z.B. in einer Kommandozeile, könnte wie folgt aussehen:
dsquery user domainroot –inactive <Anzahl der Wochen>
Damit werden alle Benutzerkonten der Domäne, die während der angegebenen Anzahl an Wochen (oder länger) nicht angemeldet waren angezeigt.
Hinweis: Die Abfrage in ADBuC sowie Dsquery nutzen bei der Abfrage das Attribut Last-Logon-Timestamp.
3. Ab Windows Server 2008 und Windows Vista steht eine weitere Option zur Verfügung, um die letzte interaktive Domänenanmeldung herauszufinden:
Die letzte interaktive Domänenanmeldung anzeigen
Weitere Beispiele
Wie bekomme ich heraus, wann ein User sich zuletzt ans AD angemeldet hat?
Die Scipting-Guys haben dazu zwei Artikel veröffentlicht:
http://www.microsoft.com/technet/technetmag/issues/2006/01/ScriptingGuy/default.aspx
http://www.microsoft.com/technet/scriptcenter/topics/win2003/lastlogon.mspx
How can I report all inactive user accounts, and optionally disable them?
TRUELAST.EXE freeware outputs the last logon time a particular user logged onto the current or a specified domain
The Windows Server 2003 Active Directory lastLogonTimeStamp attribute is replicated across all domain controllers
Using the lastLogonTimestamp attribute in Windows Server 2003
Weitere Informationen:
Account Info DLL Version 2
How to convert date/time attributes in Active Directory to standard time format
The lastLogon attribute is not updated when a client computer runs an LDAP simple bind operation against a Windows Server 2003-based domain controller
Steht eine Domänenaktualisierung von Windows 2000 auf Windows Server 2003/2003 R2 oder auf Windows Server 2008/2008 R2 bevor,
sei es durch ein Inplace-Upgrade oder durch das Hinzufügen des ersten Windows Server 2003/2003 R2/2008/2008 R2 Domänencontroller zur Gesamtstruktur,
so gilt es zuerst das AD-Schema zu aktualisieren.
Doch bevor dieser Schritt durchgeführt wird, wäre es empfehlenswert die Ausgangssituation zu überprüfen.
Die Active Directory- sowie die NTFRS/DFSR- Replikation sollte und muss ohnehin ordnungsgemäß auf allen Domänencontrollern funktionieren.
Das Verzeichnisdienstprotokoll auf den Domänencontrollern sollte weder Warnungen, noch Fehler vorweisen.
Diverse Tests mit den Tools DCDIAG, NetDIAG, FRSDiag sowie REPADMIN sind einem beim sicherstellen der fehlerfreien Funktion der DCs sowie der Replikation hilfreich.
Die genannten Tools befinden sich bis einschließlich Windows Server 2003 in den Windows Support Tools und sind ab Windows Server 2008 bereits "on Bord."
Was noch alles zu beachten und auszuführen wäre, erfährt man aus diesen Artikeln:
Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Den einzigen Domänencontroller austauschen
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Hinweis zu Exchange
Wenn ein Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, so ist zuerst die Exchange Schema-Erweiterung zu „korrigieren“.
Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der
Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren.
Der Befehl dazu lautet:
Ldifde.exe /i /f inetOrgPersonFix.ldf /c "DC=X" "DC=Domäne,DC=TLD".
Führt man diesen Schritt vorher nicht aus, würde es zu entstellten Attributen kommen:
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Soll im Zuge der AD Migration gleichzeitig auch ein Update auf Exchange 2003 erfolgen, so ist es einfacher,
erst das Exchangesetup mit dem Schalter /Forestprep durchzuführen. Der oben beschriebene Fix wird dadurch unnötig.
Hinweis: Im weiteren Verlauf ist zwar die Rede von "Windows Server 2003", doch die einzelnen Schritte gelten auch für neuere Serverbetriebssystemversionen.
Das Ausführen von ADPREP
Wenn alles soweit in Ordnung ist, kann die eigentliche Schemaaktualisierung durchgeführt werden.
Dazu ist das Active Directory Preparation Tool (kurz ADPREP) von der Windows Server 2003 CD zum einen auf dem Schemamaster
und zum anderen auf dem Infrastrukturmaster der jeweiligen Domäne, mit jeweils anderen Parametern auszuführen.
Alle Windows 2000 Domänencontroller in der Gesamtstruktur sollten idealerweise das aktuelle Service Pack 4 und alle weiteren Updates installiert haben.
Prepare Your Infrastructure for Upgrade
Hotfixes to install before you run adprep /Forestprep on a Windows 2000 domain controller to prepare the Forest and domains for the addition of Windows Server 2003-based domain controllers
Im ersten Schritt, muss zuerst die Gesamtstruktur mit dem Befehl ADPREP /Forestprep auf dem Domänencontroller,
der die Rolle des Schemamaster innehat, auf eine Windows Server 2003 Gesamtstruktur aktualisiert werden.
Würde die Gesamtstruktur (oder Domäne) nicht auf Windows Server 2003 aktualisiert werden, würde der Active Directory-Assistent DCPROMO
beim Heraufstufen des ersten Windows Server 2003/R2 zum Domänencontroller an entsprechender Stelle bzgl. des ADPREP`s einen Fehler melden.
Danach hat man immer noch Zeit das ADPREP auszuführen um anschließend mit dem Heraufstufen des Servers fortzufahren.
Im zweiten Schritt ist das ADPREP mit dem Parameter /Domainprep /GPPREP auf dem Infrastrukturmaster in der Domäne, in der man
den neuen Windows Server 2003 DC hinzufügen möchte auszuführen. Somit wird die Domäne auf Windows Server 2003 aktualisiert.
Wenn man ab Windows Server 2008 einen Read Only Domain Controller (RODC) zur Domäne hinzufügen möchte, so sollte der Befehl ADPREP /RODCPREP auf einem Infrastrukturmaster ausgeführt werden.
Falls das ADPREP in einer Gesamtstruktur oder Domäne nicht ausgeführt wurde, so wird während dem Heraufstufen eines DCs eine Fehlermeldung
bzgl. ADPREP angezeigt und der Vorgang bleibt stehen. Danach kann man jederzeit das ADPREP nachholen und anschließend mit dem Heraufstufen
des DCs fortfahren.
Wie stellt man nun sicher, dass die Änderungen die auf dem Schemamaster mit ADPREP /Forestprep durchgeführt wurden,
auch auf allen Domänencontrollern in der Gesamtstruktur repliziert wurde?
Mit dem Ausführen von ADPREP /Domainprep /GPPREP muss solange gewartet werden, bis die durch ADPREP /Forestprep
vorgenommenen Änderungen vom Schemamaster, auf den Infrastrukturmaster (in der Domäne, in der man den neuen
Windows Server 2003 hinzufügen möchte) repliziert worden ist.
Wenn ADPREP erfolgreich (oder nicht) durchgeführt wurde, wird das in der Kommandozeile angezeigt.
Auf dem Schema-Master wird in der Konfigurationspartition die folgenden beiden Container erstellt und
diese müssen auf allen DCs in der Gesamtstruktur repliziert werden:
CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
CN=Operations,CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
Mit Ausführen von Adprep /Forestprep werden 36 Änderungen in der CN=Configuration und CN=Schema Verzeichnispartition des Schemamasters durchgeführt.
Für jede Operation die durch den Befehl ADPREP /Forestprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations.
Jede GUID stellt eine Operation dar.
Wenn alle 36 Operationen erfolgreich durchgeführt wurden, wird anschließend der folgende Container erstellt:
CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC= Domäne,TLD.
Im Container CN=Windows2003Update muss das Attribut Revision den Wert 9 enthalten.
Das ADPREP /Forestprep wird nur einmal auf dem Schemamaster in der Gesamtstruktur ausgeführt.
Welche Änderungen im Detail ausgeführt werden, zeigt dieser Artikel:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest
Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!
Was wird mit ADPREP /Domainprep durchgeführt?
Es werden 50 Änderungen auf dem Infrastrukturmaster vorgenommen.
Auf dem Infrastrukturmaster wird in der Domänenpartition die folgenden beiden Container erstellt und diese müssen auf allen DCs in der Domäne repliziert werden:
CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Für jede Operation die durch den Befehl ADPREP /Domainprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Jede GUID stellt eine Operation dar. Im Container CN=Windows2003Update muss das Attribut Revision den Wert 8 enthalten.
Das ADPREP /Domainprep muss in jeder Domäne, in der ein Windows Server 2003 hinzugefügt werden soll, auf dem Infrastrukturmaster ausgeführt werden.
Für detailierte Infos siehe:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest
Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!
Was macht der Befehl ADPREP /Domainprep /Gpprep?
Dieser Befehl steht ab Windows Server 2003 zur Verfügung und ist bei einer Domänenaktualisierung von Windows 2000 zwingend auszuführen!
Er führt das gleiche wie der Befehl ADPREP /Domainprep aus. Zusätzlich wird durch den Parameter /Gpprep
den Gruppenrichtlinienobjekten im SYSVOL-Verzeichnis vererbbare Zugriffssteuerungseinträge hinzugefügt.
Gibt es etwas vor dem Ausführen von ADPREP zu beachten?
Das Windows 2000 Active Directory-Schema muss eine Schemaaktualisierung zulassen:
Schema Updates Require Write Access to Schema in Active Directory
Des Weiteren wurde in früheren Microsoft-Artikeln empfohlen, den Schemamaster vor dem Ausführen von ADPREP /Forestprep vorübergehend
in ein privates Netzwerk zu isolieren bzw. „offline“ zu nehmen. In der Praxis hat sich diese Vorgehensweise eher als Nachteil erwiesen.
Denn die Schemaänderungen wurden teilweise nach dem Neustart des Schemamasters „zurückgewiesen“.
Wenn man dennoch den Schemamaster vor dem Ausführen von ADPREP /Forestprep isolieren möchte,
dann wäre es empfehlenswert die ausgehende Active Directory-Replikation vorübergehend zu deaktivieren.
Die AD-Replikation lässt sich mit REPADMIN aus den Windows Support Tools deaktivieren. Der Befehl dazu lautet:
REPADMIN /Options +DISABLE_OUTBOUND_REPL
Nach dem Ausführen von ADPREP /Forestprep ist folgendes zu prüfen:
-
Der Befehl Adprep /Forestprep wurde ohne Fehler in der Kommandozeile ausgeführt.
-
Der Container CN=Windows2003Update wurde unter "CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD" erstellt.
Der Wert des Attributs Revision im Container CN=Windows2003Update muss 9 sein.
-
Die Schemaversion wurde auf Version 30 bzw. 31 erhöht. Überprüfen lässt sich die Schema-Version entweder durch die Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\“SchemaVersion“ (die Zahl in Klammern gibt die Version an)
oder durch das Attribut
ObjectVersion das sich unter "CN=Schema,CN=Configuration,DC=Domäne.TLD befindet.
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
Vorausgesetzt dass der Vorgang erfolgreich durchgeführt wurde, ist anschließend die ausgehende Replikation zu aktivieren.
Dazu muss der folgende Befehl in der Kommandozeile ausgeführt werden:
REPADMIN /Options -DISABLE_OUTBOUND_REPL
How to upgrade Windows 2000 domain controllers to Windows Server 2003
Von welcher CD/DVD muss das ADPREP ausgeführt werden?
Das ADPREP muss immer von der Server-CD ausgeführt werden, auf die man aktualisieren möchte.
Das ADPREP befindet sich auf der Windows Server 2003 CD im Verzeichnis CD-Laufwerk:\i386.
Ist der neue DC ein Windows Server 2003 R2, so muss das ADPREP von der zweiten R2-CD aus dem Verzeichnis CD-Laufwerk:\CMPNENTS\R2\ADREP ausgeführt werden.
Unter Windows Server 2008 befindet sich das ADPREP im Verzeichnis: <DVD-Laufwerk>:\Sources\Adprep
Und unter Windows Server 2008 R2 im Verzeichnis: <DVD-Laufwerk>:\Support\Adprep. Achtung: Unter Windows Server 2008 R2 gibt es zwei ADPREP-Versionen.
Eine Version lautet Adprep.exe, mit der man das AD-Schema auf einem x64Bit DC aktualisieren muss. Die andere Version lautet Adprep32.exe, mit der man das AD-Schema auf einem x32Bit DC aktualisieren muss.
Wird hingegen der erste Windows Server 2003 R2 in der 64Bit Version einer 32Bit Windows 2000/2003 Gesamtstruktur hinzugefügt,
so muss von Microsoft entweder ein Hotfix angefordert oder die 32Bit-Trial Version heruntergeladen und von dort das ADPREP ausgeführt werden.
Siehe dazu: Schemaupdate beim Windows Server 2003 R2
Wenn der erste SBS 2003 oder SBS 2003 R2 hinzugefügt werden soll, dann ist das ADPREP von der ersten SBS-CD, im Verzeichnis i386 auszuführen.
In welchen Gruppen muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied sein?
Das Benutzerkonto mit dem das ADPREP ausgeführt wird, muss beim ausführen des Parameters /Forestprep Mitglied in den Gruppen
Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Oder die entsprechenden Berechtigungen müssen dem Benutzerkonto delegiert worden sein.
Beim ausführen von ADPREP mit dem Parameter /Domainprep oder /Domainprep /Gpprep muss das Benutzerkonto Mitglied in der Gruppe
Domänen-Admins sein. Die Delegierung der entsprechenden Berechtigungen an das Benutzerkonto wäre ebenfalls möglich.
Für das Ausführen von ADPREP /RODCPREP muss das Benutzerkonto Mitglied in der Gruppe Organisations-Admins sein.
Auf welche Schema-Version wird das Schema aktualisiert?
Die Schema-Version lässt sich in der Registry (das es unter Start-Ausführen-Regedit aufzurufen gilt) des DCs überprüfen.
Anschließend navigiert man zu folgendem Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters.
Dort kontrolliert man den Eintrag "Schema Version". Die Zahl in Klammern, gibt die Schema-Version an.
Diese wären:
- (13) = Windows 2000 (ohne/mit allen SPs)
- (30) = Windows Server 2003 ohne/mit SP1/SP2 (und höhere SPs)
- (31) = Windows Server 2003 R2 ohne/mit SP2 (und höhere SPs)
- (44) = Windows Server 2008
- (47) = Windows Server 2008 R2
Die Schema-Version lässt sich ebenfalls mit ADSIEdit oder dem Active Directory Explorer überprüfen.
Das zu überprüfende Attribut lautet objectVersion und befindet sich im Container:
CN=Schema,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>.
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
Gibt es auch ein Protokoll vom ADPREP?
Es wird ein ADPREP-Protokoll im Verzeichnis %Systemroot%\System32\Debug\Adprep\Logs
erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
Weitere wichtige Informationen
When you run the "Adprep /forestprep" command to prepare Windows 2000 Active Directory for Windows Server 2003, the forest preparation operation fails
Aktualisieren von einer Windows 2000-Domäne
Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Upgrading from Windows 2000 Server to Windows Server 2003
Irgendwann muss auch der letzte Mohikaner gehen bzw. ausgetauscht werden. 
Was ist alles zu beachten, wenn man den ersten und einzigsten Domänencontroller austauschen möchte/muss:
1. Zu allererst sollte ein aktuelles Backup vom System State sowie den Daten existieren.
2. In den TCP/IP Einstellungen des neuen Servers trägt man als ersten und einzigsten DNS-Server den bereits bestehenden DC ein. Erst wenn die AD-Replikation (bei einer AD-integrierten Forward Lookup Zone, kurz FLZ) nach dem Heraufstufen zwischen den beiden DCs stattgefunden hat, trägt man den neuen DC sich selbst als ersten DNS-Server in seinen TCP/IP-Einstellungen
ein bzw. Welcher DNS-Server sollte eingetragen werden ?.
3. Der neue Server ist als zusätzlicher DC der Domäne hinzuzufügen. Außerdem muss das DNS entweder vor oder nach dem Heraufstufen des DCs installiert werden. Das DNS muss aber lediglich installiert und nicht noch zusätzlich konfiguriert werden, da das DNS bereits auf dem ersten DC konfiguriert ist. Es ist darauf zu achten, dass auf dem ersten DC die FLZ AD-integriert gespeichert ist, denn nur dann werden die DNS-Informationen automatisch dank der AD-Replikation auf den neuen DC repliziert. Des Weiteren ist es nur bei einer AD-integrierten FLZ möglich, die Option "Nur sichere" Updates zuzulassen (was anzuraten ist).
Einen zusätzlichen DC in die Domäne hinzufügen
4. Falls der neue Server, der erste Windows Server 2003 R2 Domänencontroller werden soll, so muss vorher das ADPREP von der zweiten R2-CD ausgeführt
werden. Für weitere Details siehe: Schemaupdate beim Windows Server 2003 R2
Ist der neue Server der erste Windows Server 2008 DC, so muss das Schema wie folgt aktualisiert werden:
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Wenn es sich dagegen um den ersten Windows Server 2008 R2 DC handelt, so ist das Schema folgendermaßen zu aktualisieren:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
5. Danach müssen die 5 FSMO Rollen, samt den Infrastrukturmasterrollen der einzelnen Anwendungsverzeichnispartitionen (ab Windows Server 2003) auf den neuen DC verschoben werden:
- Schemamaster
- Domänennamenmaster
- RID-Master
- PDC-Emulator
- Infrastrukturmaster
Die FSMO-Rollen verschieben
6. Zusätzlich sollte der neue DC zum Global Catalog-Server (GC) deklariert werden. Dazu ist im Snap-In Active Directory-Standorte und -Dienste in den Eigenschaften
des NTDS-Settings Objekt, das sich unterhalb des neuen DC-Objekts befindet, der Haken bei "Globaler Katalog" zu setzen.
Globaler Katalog (Global Catalog - GC)
7. Bevor der alte DC mit DCPROMO aus der Domäne entfernt wird, gilt es noch das EFS-Zertifikat zu sichern:
Was muss ich tun, um den ersten DC zu deinstallieren?
8. Falls der DC auch ein DHCP-Server wäre, ist es möglich, die DHCP-Datenbank vom "alten" DC zu exportieren und auf dem neuen zu importieren:
How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running Windows Server 2003
Die DHCP-Konfiguration samt den Leases, kann man mit folgendem Befehl (unter Windows Server 2003) sichern:
"netsh dhcp server export C:\Dhcp.txt all".
Um die exportierte Datei einzuspielen, gilt es folgenden Befehl einzugeben:
"netsh dhcp server import C:\Dhcp.txt all".
Wird der DHCP-Server von einem Windows Server 2003 auf Windows Server 2008 verschoben, so gilt es den folgenden Artikel durchzuführen:
How to move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008
9. Ein WINS-Server sollte auch heute noch in einer Domäne existieren.
Der WINS erleichtert einem das tägliche Leben und kostet nicht viel Arbeit:
Wie sollte WINS konfiguriert werden?
10. Falls der DC auch Freigaben zur Verfügung stellt, können diese ebenfalls exportiert und auf dem neuen DC importiert werden:
Start - Ausführen - Regedit - HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
Anschließend ist der Serverdienst neu zu starten.
... oder man benutzt das File Server Migration Toolkit (FSMT).
Mit diesem Tool werden die Daten samt Berechtigungen kopiert und die Freigaben automatisch wieder erstellt:
http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en
Das Whitepaper zum FSMT kann hier heruntergeladen werden.
11. Drucker können mit dem Print Migrator kopiert/verschoben werden:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9B9F2925-CBC9-44DA-B2C9-FFDBC46B0B17&displaylang=en
12. Danach gilt es noch die Anmeldeskripte anzupassen.
Die Daten können z.B. mit NTBACKUP gesichert und auf dem neuen DC wiederhergestellt werden.
ROBOCOPY oder XCOPY /O würden ebenfalls funktionieren, sowie diverse andere Programme/Tools.
Komfortabel lassen sich die Dateien allerdings mit dem File Server Migration Toolkit (FSMT) oder RichCopy auf den neuen Server kopieren.
Mit beiden Tools bleiben die Berechtigungen erhalten.
Wenn alle Daten sowie Dienste vom "alten" DC auf den neuen DC übernommen wurden, muss der Domänencontroller mit DCPROMO
aus dem Active Directory entfernt werden, damit die DC-Informationen ordnungsgemäß aus den Metadaten des AD entfernt werden.
Entfernt man jedoch den DC nicht mit DCPROMO aus der Domäne, sondern schaltet diesen einfach aus und installiert z.B. das Betriebssystem neu, so müssen die DC-Informationen in mühseliger Handarbeit aus den Metadaten des AD entfernt werden.
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Falls man jetzt noch möchte, dass der neue DC die IP-Adresse sowie den Computernamen des alten DCs erhält,
so kann man beides folgendermaßen durchführen: Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
Die IP - Adresse eines Domänencontrollers ändern
Anschließend ist ein Neustart des Servers fällig.
Es sei an dieser Stelle angemerkt das es ratsam ist in jeder Domäne mindestens zwei DCs zu installieren, um die Ausfallsicherheit im Falle eines DC-Crashs zu gewährleisten!
Eine weitere Alternative zeigt dieser Artikel:
How to move a Windows installation to different hardware
Weitere Informationen:
Über Backup und Restore
Migrating Windows Small Business Server 2003 to New Hardware
How to replace single domain controller in domain with a single domain controller?
Das sichern des System State (Systemstatus) ist das mindeste,
was ein Administrator auf seinen Domänencontrollern sichern sollte, wenn nicht sogar "muss".
Denn dadurch kann man z.B. bei einem Servercrash in einer Domäne, in dem bloß ein einziger Domänencontroller existiert,
sich die „Domäne“ samt Active Directory rücksichern und braucht somit nicht erneut jeden User einzeln anlegen oder die Computer
aus der „alten“ Domäne zu entfernen und in die neue einzubinden. Alleine wegen der Ausfallsicherheit ist es empfehlenswert,
in jeder Domäne min. zwei DCs zu installieren. Der zweite DC könnte auch (wegen finanziellen Engpässen) auf eine
„ältere“ Client-Maschine installiert werden.
Weitere Informationen erhalten Sie unter: Wie stelle ich das AD wieder her?
Neben der Sicherung des System States, sollte natürlich ein Disaster-Recovery, Backup Konzept und ein Notfallplan
existieren und vor allem auch regelmäßig an die aktuellen Gegebenheiten angepasst werden.
http://www.microsoft.com/technet/community/events/windows2003srv/tnt1-94.mspx
Für Exchange:
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/disrecopgde.mspx
Mit sichern des System States werden folgende Dateien gesichert:
- Die Active Directory Datenbank – NTDS.DIT
- SYSVOL
- Systemstart Dateien
- Registry
- COM+
Falls eine CA installiert wäre, dann auch diese.
Man sollte und muss auf das Alter des System States beim rücksichern achten, genauer auf das Alter des Attributs „TombstoneLifetime”.
Die Sicherung des Systemstatus darf nicht älter als der eingestellte Wert sein.
Den eingestellten Wert der „TombstoneLifetime“ kann man sich mit ADSIEdit
(aus den Windows Support Tools) im folgenden Pfad anschauen:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne,DC=TLD
Dort findet man in den Eigenschaften des Containers CN=Directory Service das Attribut tombstoneLifetime.
Ist dort ein Wert gesetzt, beträgt die Tombstone Lifetime (TSL) den eingetragenen Wert in Tagen.
Steht im Attribut als Wert hingegen <Not Set>, so beträgt die TSL den Standardwert von 60 Tagen.
Die TSL wird mit dem installieren des allerersten DCs in einer Gesamtstruktur und zwar für alle
Domänen festgelegt. Dieser Wert kann nicht pro Domäne konfiguriert werden. Er lässt sich aber manuell verändern.
Die TSL beträgt unter:
- Windows 2000 (mit allen SPs) = 60 Tage
- Windows Server 2003 ohne SP = 60 Tage
- Windows Server 2003 mit Service Pack 1 = 180 Tage
- Windows Server 2003 R2 (mit SP1) = 60 Tage
- Windows Server 2003 mit Service Pack 2 = 180 Tage
- Windows Server 2003 R2 ab Service Pack 2 = 180 Tage
- Windows Server 2008 = 180 Tage
- Windows Server 2008 R2 = 180 Tage
Siehe folgenden Artikel: Das Geheimnis der Tombstone Lifetime
Angenommen man hätte einen Festplatten - Crash in einem Domänencontroller der der einzigste DC der Domäne wäre,
dann gilt es den Server zu reparieren, in Form von Festplatten tauschen und anschließend neu installieren des Betriebssystems
„Windows Server 2003 R2“. Dabei spielt es keine Rolle welchen Computernamen sowie IP - Einstellungen man dem Server vergibt,
denn nach dem rücksichern des System State, bekommt der Server die Daten, die er beim sichern des System State hatte.
Nach dem installieren des Betriebssystems gilt es danach das Betriebssystemeigene Sicherungsprogramm „NTBACKUP“
über „Start - Ausführen - Ntbackup“ zu starten und eine Rücksicherung des System States zu starten (ausgegangen davon,
dass man das SYSTEM STATE über das NTBACKUP sichert). Dabei ist es auch egal auf was gesichert
wurde und welchen Laufwerksbuchstaben das Sicherungslaufwerk hatte.
Nach dem rücksichern und anschließendem neu starten des Servers fehlen die Active Directory - Snap - Ins
wie z.B. Active Directory Benutzer- und Computer oder „Standorte und Dienste“ etc. unter „Start - Programme - Verwaltung“.
Nun könnte man mit „Start - Ausführen - dsa.msc“ (für AD- Benutzer- und Computer) oder dssite.msc (für AD-Standorte- und Dienste)
die Snap - Ins aufrufen. Eine andere Alternative wäre, dass man sich selbst eine MMC erstellt und diese
ganzen Snap-Ins dort hinzufügt und speichert. Wer das alles nicht will und den gewohnten „Standard“ haben möchte,
sprich, die ganzen Snap-Ins unter „Start - Programme - Verwaltung“ haben möchte, der installiert sich das „Adminpack.msi“
aus %systemroot\system32\ und bekommt anschließend das gewohnte Bild unter „Start - Programme -Verwaltung“.
Zum Schluss müsste noch das DNS sowie DHCP installiert und konfiguriert werden.
Es gibt auch eine Möglichkeit, dass DCPROMO mit dem Schalter „/ADV“ auszuführen. Das wäre für den Fall ideal,
wenn man z.B. einen weiteren Server zum Domänencontroller promoten möchte, dieser aber an einem Standort mit einer
geringen Anbindung steht. Damit eben nicht die komplette Active Directory - Datenbank repliziert werden muss, sichert
man an einem bestehenden DC der Domäne, zu der der neue Server als weiterer DC heraufgestuft wird, dass System State
und kopiert dieses auf eine externe Fesplatte oder CD/DVD. Damit stuft man dann den neuen Server zum DC und anschließend
muss dann nur noch die Änderung seit der erstellten System State Sicherung repliziert werden.
Weitere Inforamtionen:
Domänencontroller-Installation von einer Sicherung
Install from Media
|
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by | |