Einsatzszenarien für Windows Server 2012, Teil 1

3. April 2013

Wie sich der Windows Server 2012 für die Anwendungsbereiche als Domänencontroller (DC) mit dem Active Directory (AD), als Dateiserver, als Host für den SQL Server 2012, als Basis für Exchange 2013 und als Fundament für Sharepoint 2013 am besten konfigurieren lässt, zeigt diese mehrteilige Serie. Den Anfang macht das Konfigurieren eines Domänencontrollers.

Bild 2. Dialog zur Eingabe eines alternativen Pfades zu den benötigten Dateien. Mit einem Klick auf den Hyperlink unten im Dialog kommt ein weiteres Fenster zum Vorschein.
Bild 3. Hier kann der Systembetreuer den alternativen Pfad zu den Installationsdateien angeben.

Auch wenn der Windows Server 2012 nun schon seit einiger Zeit verfügbar ist, so haben bei weitem nicht alle Unternehmen die Umstellung von früheren Windows-Serverplattformen auf den neuen Vertreter in ihren Produktivumgebungen durchgeführt. Das liegt sicher nicht an der Funktionalität des Windows Server 2012 – denn diese Version ist definitiv das beste Server-Betriebssystem, das Microsoft jemals vorgestellt hat. Der Grund ist vielmehr darin zu suchen, dass fast alle Unternehmen erst eine Zeit vergehen lassen, bis sie auf das aktuellste Betriebssystem umsteigen. Das kann in manchen Fällen sogar Jahre dauern, bis der Schritt vollzogen wird.

Anzeige
CS espresso series

Applikationen sind noch nicht bereit

Beim Windows Server 2012 kommt noch ein weiterer Umstand dazu, der diese Verzögerung beeinflusst: Einige andere Server-Produkte von Microsoft, die im Einsatz sind und den offiziellen Microsoft-Support genießen, wie etwa Exchange Server 2010 und Sharepoint Server 2010, werden offiziell nicht auf dem Windows Server 2012 unterstützt. Daher werden viele Firmen erst dann umsteigen, wenn sie auch den Schritt zu Exchange 2013 und Sharepoint 2013 absolvieren.

Wer sich nun mit dem Einsatz der neuesten Windows-Serverplattform befasst, dem wird diese Artikelreihe zeigen, wie er den Windows Server 2012 am besten in fünf gängigen Anwendungsbeispielen zum Einsatz bringen kann:

  • als Domänencontroller (DC) mit dem Active Directory (AD),
  • als Dateiserver,
  • als Host für den SQL Server 2012,
  • als Basis für Exchange 2013 und
  • als Fundament für Sharepoint 2013.

Beim Windows Server 2008 Release 2 musste der Administrator das Installationsmedium nicht mehr anfassen, nachdem der Server einmal installiert war. Denn im Zuge des Installationsvorgangs wurden alle Dateien, die für ein späteres Hinzufügen von Rollen (oder Features) nötig sind, in ein spezielles Verzeichnis auf der Festplatte kopiert.

Angenommen es sollte eine weitere Rolle (wie zum Beispiel das AD oder der BITS – Background Intelligent Transfer Service) hinzugefügt werden, galt es nur den zugehörigen Assistenten aufzurufen und dann ging die Sache los.Beim Windows Server 2012 schaut das anders aus: Um die Größe des Installationsumfang bei Server 2012 zu reduzieren, hat Microsoft nicht alle Dateien bei der Installation des Betriebssystems mit abgelegt, die für das spätere Installieren von sämtliche Rollen und Features benötigt werden.

Das Nachinstallieren von Rollen und Features wird mit Hilfe des Servermanagers abgewickelt (siehe Bild 1). Daher erfordert das Nachinstallieren von Features und Rollen in vielen Fällen den Zugriff auf das Installationsmedium. Dabei ist vor allem ein Punkt zu nennen, der die Administratoren immer wieder „nervt“: Das Hinzufügen von Features wie beim .NET-Framework 3.5

Ist dieses Feature zu installieren, muss der Administrator einen alternativen Pfad zu den Quelldateien angeben (siehe Bild 2). Wenn das Installationsmedium vorhanden ist, lautet der Quellpfad im entsprechenden Laufwerk (etwa G: beim DVD-Laufwerk) \sources\sxs. Mit einem Klick auf den Hyperlink unten im Dialog von Bild 2 kommt ein weiteres Fenster zum Vorschein (siehe Bild 3).

Nachladen aus dem Internet

Ist der Rechner dagegen mit dem Internet verbunden, dann lädt der Windows Server 2012 die notwendigen Dateien direkt von der Microsoft-Website. Der Systembetreuer kann aber auch einen Speicherort im Netzwerk angeben. Daher ist es für häufigere Installationsaufgaben der bessere Weg, eine Netzwerkfreigabe einzurichten und dort das Verzeichnis sxs anzulegen und die entsprechenden Dateien dort abzulegen. Dann hat es der Administrator bei seinen Installationsvorhaben im Unternehmen immer gleich griffbereit.

Beim Windows Server gibt es zwei Möglichkeiten, um weitere Rollen oder Features hinzuzufügen. Die eine ist das Aufrufen des “Assistenten zum Hinzufügen von Rollen und Features” (Add Roles and Features), die zweite der Einsatz des Powershell-Cmdlets Install-WindowsFeature.

Wer mit Hilfe der Powershell das .Net Framework 3.5 installieren möchte, der muss beim Aufruf des Cmdlets die Quelle angeben, in der die notwendigen Dateien liegen. Dabei kann dieser Ort das Verzeichnis \sources\sxs auf dem Installationsmedium sein, oder eine install.wim-Datei oder auch eine parallele Installation des Windows Server 2012.

Liegt das Installationsmedium zum Beispiel auf dem Volume G, dann wird die Installation des .NET Framework 3.5 mit dem folgenden Powershell-Kommando gestartet:

Install-WindowsFeature NET-Framework-Core -Source G:\Sources\SxS

Das Problem beim .NET Framework 3.5 ergibt sich recht häufig, weil viele Softwarepakete, die auf Windows Server 2012 laufen, diese Umgebung als Voraussetzung benötigen. Wenn der Windows Server 2012 nicht mit dem Internet verbunden ist, sollte man daran denken, dass der Zugriff auf das Installationsmedium schnell gelingt.

Bild 4. Die Seiten zu “Alle Server Aufgabendetails und Benachrichtigungen”
Bild 5. Die Seite mit den Domänencontrolleroptionen

Einsatz als Domänencontroller mit dem Active Directory

In den Vorgängerversionen von Windows Server 2012 wurde ein Rechner ganz einfach, durch den Einsatz von dcpromo.exe, zu einem Domänencontroller (DC) heraufgestuft. Beim Windows Server 2012 läuft der Vorgang etwas anders. Viele einzelne Schritte – wie etwa das Laufenlassen von adprep.exe, um die Gesamtstruktur und die Domäne separat vorzubereiten, werden nun automatisch beim Einführen eines DC ausgeführt.

Beim AD selbst sind viele Verbesserungen im Kontext des AD dazu gekommen. Dazu gehört eine bessere Unterstützung von virtualisierten DCs, das Cloning von DCs und die Gruppenverwalteten Dienstkonten (Group Managed Service Accounts).

Im ADAC (Active Directory Administrative Center) finden sich nun auch Tools, die einige Sachen vereinfachen. Dazu gehört zum Beispiel das Einsetzen von feingliedrigen Kennwortrichtlinien oder ein intuitives Interface für das Nutzen des AD-Paperkorbs.

Mehr Informationen zu den Verbesserungen beim AD (unter Windows Server 2012) bietet ein Microsoft-Beitrag im Technet: "What’s New in Active Directory Domain Services (AD DS)".

Voraussetzungen klären

Ehe der Administrator die DC-Rolle bei einem Computer aufspielt, sollte er die folgenden Aktionen im Vorfeld ausführen:

  • Der Rechner sollte eine statische IP-Adresse zugewiesen bekommen. Es ist zwar auch machbar, einem DC eine IP-Adresse zu geben, die über die DHCP Reservation vergeben wird. Doch der Setup-Assistent wird immer empfehlen, dass man für einen DC eine statische IP-Adresse vergibt.
  • Der Computer braucht einen sinnvollen Namen. Wenn man den Windows Server 2012 installiert, bekommt der Computer zwar einen Namen verpasst – doch der ist ziemlich willkürlich. Generell sollte man aber eine für die eigene Umgebung aussagekräftige Bezeichnung wählen – etwa Melbourne-DC-1, wenn es der erste DC am Standort Melbourne ist. Das kann man vor der DC-Installation erledigen, doch dazu muss man nach dem Namenswechsel einen Neustart einplanen.
  • Auch die Entscheidung, ob ein DC auch als DNS Server und als GC (Global Catalog) Server agiert, sollte im Vorfeld getroffen werden. Die meisten Administratoren setzen die DNS-Rolle auf einem DC ein. Dabei lässt sich auch festlegen, ob der DC als GC Server agieren soll, oder man kann das “Universal Group Membership Caching” aktivieren.
  • Auch das DSRM-Kennwort (Directory Services Restore Mode) sollte man sich gut überlegen. Es ist nötig, damit man später im Wiederherstellungsmodus für das Verzeichnis die nötigen Aktionen ausführen darf. Dabei lautet eine sinnvolle Empfehlung: Für alle DCs in einem Unternehmen sollte man dasselbe DSRM-Kennwort einsetzen. Dann läuft bei der Wiederherstellung alles wesentlich einfacher ab. Weniger Komplexität bei Aktionen im Umfeld der Fehlerbehebung ist immer ein gutes Argument.
Bild 6. Die Seite für das Überprüfen der Installationsoptionen
Bild 7. Das Cmdlet Install-ADDSForest der Powershell

Um den Windows Server 2012 als DC zu konfigurieren, sind die folgenden Schritte nötig:

  • In der Konsole des Servermanagers ist im Menü auf Verwalten zu klicken und dann im aufklappenden Kontextmenü auf “Rollen und Features hinzufügen” (Add Roles and Features). Auf der Seite zur Auswahl des Installationstypus ist die “Rollenbasierte oder die featurebasierte Installation” anzugeben (siehe Bild 1).
  • Aus dem Pool der verfügbaren Server das System auswählen, auf dem das AD installiert werden soll. Beim Windows Server 2012 ist es möglich, mehrere Server gleichzeitig über den Servermanager zu verwalten – daher eignet sich dieser Assistent dazu, Rollen wie  AD DC sowohl auf einem lokalen, als auch auf einem entfernten System aufzuspielen.
  • Auf der Seite mit der Auswahl der Serverrollen ist Active Directory Verzeichnisdienste (AD DS, Active Directory Domain Services) zu selektieren. Dann wird man auch gleich aufgefordert, die RSAT (Remote Server Administration Tools) mit zu installieren – es sei den, man hat sie bereits auf dem lokalen System installiert.
  • Dann muss der Systembetreuer solange auf Weiter klicken, bis er zu dem Dialog gelangt, in dem er auf Installieren klicken kann. Nach dem entsprechenden Klick werden die Binärdaten  für die AD-Verzeichnisdienste auf das System gespielt. Danach noch ein Klick auf Fertigstellen und dann wird der Assistent verlassen.

Nach all diesen Aufgaben befindet sich zwar die notwendige Software für das AD auf dem System. Doch das Heraufstufen des Servers zu einem DC ist damit noch nicht erfolgt. Dazu sind weitere Schritte nötig:

  • Im Servermanager ist auf den Arbeitsbereich AD DS zu klicken und dann in der gelb hinterlegten Benachrichtigung, die angibt, dass noch weitere Konfigurationsaufgaben für die “Active Directory-Domänendienste” auf dem Server erforderlich sind (Configuration required for Active Directory Domain Services), auf die Details zu klicken. Danach erscheint die Seite “Alle Server Aufgabendetails und Benachrichtigungen” (All Servers Task Details and Notifications, siehe Bild 4). Hier ist dann noch auf den Punkt “Server zum Domänencontroller heraufstufen” (Promote this server to domain controller) zu klicken.
  • Auf der Seite zur Bereitstellungskonfiguration (Deployment Konfiguration) wird noch gefragt, ob der DC zu einer bereits bestehenden Domäne hinzugefügt werden soll, oder ob eine neue Domäne zu einer bestehenden Gesamtstruktur hinzukommen soll, oder ob eine neue Gesamtstruktur hinzugenommen werden soll.
  • Auf der Seite zu den Domänencontrolleroptionen (siehe Bild 5) gilt es noch die funktionalen Ebenen für die Domäne und die Gesamtstruktur anzugeben. Hier lässt sich selektieren, ob der DC auch die Aufgaben eines DNS- oder eines GC-Servers übernehmen soll. Dabei ist aber zu beachten: Der erste DC in einer Organisation muss immer auch ein GC-Server sein. Zudem ist hier das Kennwort für DSRM anzugeben.
  • Ist die Wahl gefallen, dass man einen DC einsetzen will, bekommt man noch die Option angezeigt, ob eine DNS-Delegierung eingerichtet werden soll. Das ist allerdings nicht möglich, wenn das System die übergeordnete DNS-Zone nicht findet, oder wenn der DNS-Dienst noch nicht ausgeführt ist. Notfalls muss der Administrator die DNS-Delegierung später noch konfigurieren.
    Wenn man dagegen eine neue Gesamtstruktur oder eine neue Domäne erzeugt, wird ein automatisch erzeugter NetBIOS-Name für die Domäne angelegt. Diese Bezeichnung darf (genauer sollte) man für die eigenen Bedürfnisse anpassen.
  • Auf der Seite zu den Pfaden kann der Administrator dann noch die Datenbankordner, das Verzeichnis für die Protokolldateien sowie das SYSVOL-Verzeichnis angeben, die be idem DC verwendet werden sollen. In den meisten Fällen sind die Standardvorgaben eine gute Wahl.
  • Nachdem der Administrator dann im nächsten Schritt seine Optionen noch einmal überprüfen kann (Bild 6), kann er über einen weiteren Klick ein Skript anzeigen. Es verdeutlicht, wie die Installation später ausgeführt wird. In Bild 7 ist das Powershell-Cmdlet Install-ADDSForest gezeigt und wie damit die DC-Rolle zum Einsatz gebracht und konfiguriert wird.
  • Nachdem die ausgewählten Installationsoptionen nochmals geprüft wurden, führt das System einen Test im Vorfeld der DC-Installation aus. Dabei wird geklärt, ob alle Voraussetzungen erfüllt sind. Ist das der Fall, kann man die DC-Rolle installieren. Dabei wird das System dann auch einen Neustart ausführen und damit das Hochstufen zum DC abschließen.

Orin Thomas/rhh

Lesen Sie auch