Ein automatisiertes Windows Server Deployment einrichten: Tipps aus der Praxis

So sehen die  grundlegenden Schritte für eine Automatisierung einer Windows-Server-Installation aus, die für ESAE Tier-0-Umgebungen dient.

Ein Gastbeitrag der TEAL Technology Consulting GmbH 

Tools für das Windows Server Deployment

Für die Automatisierung gibt es eine Reihe von Tools, die ganz unterschiedliche Szenarien adressieren.

Microsoft stellt das Windows Assessment and Deployment Kit (Windows ADK) zur Verfügung. Dieses beinhaltet eine Reihe von Werkzeugen zum Automatisieren einer Windows-Installation. Dazu gehören unter anderem der Configuration Designer, der System Image Manager oder das Windows Preinstallation Environment (WinPE).

Eine Tool-Suite ist der Microsoft Endpoint Configuration Manager. Mit ihr lässt sich Windows automatisiert auf einer Vielzahl von Nutzer-Endgeräten oder Servern in Rechenzentren installieren. Der Endpoint Configuration Manager nutzt auch die Tools aus dem Windows ADK. Er erleichtert aber den Umgang mit diesen Tools, indem er viele Details vor dem Administrator verbirgt. Zudem stellt die Microsoft-Suite eine Infrastruktur zur Verfügung, um das Deployment auf Tausenden Endgeräten ohne manuelle Eingriffe zu ermöglichen.

In virtualisierten On-Premises-Rechenzentren werden häufig Produkte wie VMware vSphere oder Microsoft Virtual Machine Manager verwendet. Mit diesen lassen sich Templates für virtuelle Maschinen erstellen, die beim Deployment einer großen Anzahl von Virtual Machines zum Einsatz kommen.

Was bringt die Automatisierung?

Eine Windows-Installation sollte auf den Endsystemen – unabhängig, ob es sich um ein Gerät für einen Endanwender oder einen Server in einem Rechenzentrum handelt – möglichst automatisiert und mit wenigen manuellen Tätigkeiten durchgeführt werden.

Denn: Eine Automatisierung führt einerseits zu geringerem Aufwand bei der Installation von Systemen. Andererseits kommt es zu einer Reduktion von Fehlkonfigurationen, die einem bei der Ausführung von vielen manuellen Schritten unterlaufen. Zudem lassen sich automatisierte Systeme im Fehlerfall schnell wieder neu installieren und somit die potenzielle Ausfallzeit erheblich verringern.

Tier 0-Umgebungen nach ESAE weisen normalerweise einen hohen Virtualisierungsgrad auf, weshalb sich dort ein Deployment mit VM-Templates häufig anbietet.

Virtual Machines und die automatisiere Installation

Hier möchten wir den Schwerpunkt auf die Erstellung der Sourcen und Installationsmedien beschränken. Das letztendliche Deployment-Verfahren ist abhängig von dem konkreten Einsatzszenario.

Das Grundprinzip dabei ist, dass eine Virtual Machine mit Windows Server installiert wird. Dazu kommen zusätzliche Konfigurationen, zum Beispiel das Aktivieren von Credential Guard , Virenscanner, Monitoring- und Backup-Agenten oder die Installation der Microsoft Local Administrator Password Solution (LAPS).

Auf Basis dieser VM wird dann ein Template erstellt, mit dem man die Virtual Machines in der Umgebung einrichtet. Die Basis-VM für das Deployment Template lässt sich manuell oder automatisiert installieren.

Bei einer manuellen Einrichtung müssen alle Schritte dokumentiert werden. Derart ist man bei Änderungen in der Lage, eine neue Version des Deployment Templates zu erstellen, die dem definierten Standard entspricht. Mit einer automatisierten Installation fällt der initiale Aufwand zwar höher aus, weitere Änderungen sind dann jedoch einfacher und sicherer umzusetzen.

Automatisierung der Windows-Installation

Grundsätzlich gibt es verschiedene Möglichkeiten, ein Windows Image anzupassen:
    • Beim Online Servicing wird Windows auf einem Referenzgerät installiert. Auf diesem Gerät fügt der Administrator Treiber, Apps und Konfigurationsanpassungen hinzu. Anschließend generalisiert er die Windows-Installation mit dem Tool Sysprep.
    • Beim Offline Servicing kopiert der Admin das Windows-Image vom Installationsmedium und bindet (englisch: “mountet”) es mit dem Tool DISM in ein temporäres Verzeichnis ein. Änderungen wie zusätzliche Treiber, Updates, Applikationen und Konfigurationsänderungen werden in dieses temporäre Verzeichnis injiziert und anschließend in das Image zurückgeschrieben.

Das Image lässt sich dann – unabhängig von der Methode – auf einer beliebigen Anzahl von Systemen installieren.

Vor- und Nachteile der beiden Methoden

Das Offline Servicing hat den Nachteil, dass bei einer neuen Version des Images die Schritte zur Anpassung des Images manuell zu wiederholen sind.

Beim Online Servicing lassen sich die zur Installation hinzugefügten Dateien bei einer neuen Version des Betriebssystems wieder zum Installationsmedium hinzufügen. Und daraus wird eine neue Image-Version erzeugt.

Die letztgenannte Methode stellen wir  hier kurz vor.

Erzeugen einer Autounattend.xml

Die während einer Windows-Installation notwendigen Eingaben (Auswahl der Betriebssystem-Edition, Sprache oder Tastatur-Layout) können mit einer Antwortdatei unterdrückt werden.

Das Windows-Setup-Programm verwendet die in dieser Datei hinterlegten Einstellungen. Die Folge: Es installiert Windows automatisch und zeigt keine Dialoge für Eingaben an.

Zur Erstellung und Anpassung von Antwortdateien enthält das Windows ADK den Windows System Image Manager (Windows SIM). Mit diesem grafischen Tool lassen sich die Einstellungen für das Windows-Setup anpassen.

Das Ergebnis der Windows-SIM-Anpassungen ist eine Antwortdatei im XML-Format. Das sieht im Ausschnitt beispielsweise so aus:

<?xml version=”1.0″ encoding=”utf-8″?>
<unattend xmlns=”urn:schemas-microsoft-com:unattend”>
<settings pass=”windowsPE”>
<component name=”Microsoft-Windows-International-Core-WinPE” processorArchitecture=”amd64″
publicKeyToken=
“31bf3856ad364e35″ language=”neutral” versionScope=”nonSxS” xmlns:wcm=
“http://schemas.microsoft.
com/WMIConfig/2002/State” xmlns:xsi=
“http://www.w3.org/2001/
XMLSchema-instance”>

<InputLocale>en-US;de-DE </InputLocale>
<SystemLocale>en-US</SystemLocale>
<UserLocale>en-US</UserLocale>
<UILanguage>en-US</UILanguage>
</component>
[…]

Die Einstellung der Antwortdatei sind bei Microsoft in der Referenz für das unbeaufsichtigte Windows-Setup dokumentiert.

Die Inhalte des Installationsmedium werden inklusive der Antwortdatei – der Autounattend.xml – in ein Build-Verzeichnis kopiert. Das Windows-Setup verwendet diese dann.

Hinzufügen von bootkritischen Treibern

Windows enthält den sogenannten Driver Store. Der Driver Store beinhaltet Treiberpakete, die in diesem Verzeichnis gespeichert sind: %SystemRoot%\System32\DriverStore
Während der Installation liest Windows die Hardware-IDs der angeschlossenen Geräte aus, sucht im Driver Store (und gegebenenfalls auch über das Windows-Update) nach passenden Treiberpaketen und installiert diese. Wichtig sind hierbei die bootkritischen Treiber.  Ohne die lässt sich Windows nicht einrichten. 
Treiber, die im Lieferumfang von Windows und damit im Driver Store fehlen, müssen in das Build-Verzeichnis integriert werden. Wie? Einfach ein Verzeichnis für die Treiber im Build-Verzeichnis erstellen und in der Autounattend.xml darauf verweisen! Das Windows-Setup nutzt diese dann bei der Installation.
Ein Beispiel: Für die Virtual Machines von VMware ist der Treiber für das VMware Paravirtual SCSI Controller nötig, welcher nicht zum Lieferumfang von Windows gehört. Also muss die VMware Tools ISO in das Verzeichnis .\drivers kopiert werden.

Der Pfad wird in der Antwortdatei autounattend.xml referenziert. Dabei gilt zu beachten, dass das Installationsmedium beim Starten des Windows-Setup-Programms den Laufwerksbuchstaben D: erhält.

<component name=”Microsoft-Windows-PnpCustomizationsWinPE” processorArchitecture=
“amd64” publicKeyToken=
“31bf3856ad364e35″ language=”neutral” versionScope=”nonSxS” xmlns:wcm=”
http://schemas.microsoft.com/
WMIConfig/2002/State” xmlns:xsi=”
http://www.w3.org/2001/
XMLSchema-instance”>
<DriverPaths>
<PathAndCredentials wcm:keyValue=”6b86e64″ wcm:action=”add”>
<Path>D:\drivers</Path>
</PathAndCredentials>
</DriverPaths>
</component>

Hinzufügen von Scripts und Applikationen

Im Verzeichnis .\sources ist ein Unterverzeichnis $OEM$ zu erstellen. Unter diesem Verzeichnis gibt es nun weitere Verzeichnisse mit einer festen Bedeutung:
    • $OEM$
      Enthält zusätzliche Verzeichnisse und Dateien für eine automatisierte oder benutzerdefinierte Installation.
    • $OEM$\$$
      Dateien und Unterverzeichnisse werden nach %SystemRoot% kopiert.
    • $OEM$\$1
      Repräsentiert das Laufwerk, auf dem Windows installiert ist. Dateien und Unterverzeichnisse werden nach %SystemDrive% kopiert

Es gibt mehrere Möglichkeiten während oder nach dem Windows-Setup eigene Scripts und Programme automatisch zu starten. Eine davon ist, im Verzeichnis %SystemRoot%\Setup\Scripts eine Datei SetupComplete.cmd hinzuzufügen. Diese Batch-Datei startet automatisch am Ende des Setups. Diese muss dann im Build-Verzeichnis nach .\sources\$OEM$\$$\Setup\Scripts kopiert werden.

Eine Verzeichnisstruktur unter $OEM$ kann folgendermaßen aussehen:

Mit der Batch-Datei SetupComplete.cmd lassen sich Applikationen einrichten oder weitere Scripts ausführen. Diese müssen in Verzeichnissen unter C:\Install liegen. Dieses Verzeichnis kann am Ende der Installation durch ein Script gelöscht werden.

Erstellen eines Installationsmediums

Nachdem die Installations-Dateien und Scripts hinzugefügt wurden, folgt die Erstellung des Installationsmediums.

USB-Installationsmedium

Für physische Hardware, die zumindest gut zugänglich ist, bietet es sich an, einen USB-Stick mit den Windows-Installationsdateien zu erstellen. Dazu muss der USB-Stick lediglich mit dem Dateisystem FAT32 formatiert und der Inhalt des Build-Verzeichnisses auf den USB-Stick kopiert werden.

ISO-Installationsmedium

Bei physischer Hardware, die sich in einem entfernten Rechenzentrum befindet, und für Virtual Machines nutzt man ein ISO-Installationsmedium. Die Server-Hardware verfügt häufig über Management-Lösungen wie HP Integrated Lights-Out (ILO), mit dem sich eine ISO-Datei an einen physischen Server mounten lässt.

D:\Build\Windows_Server_2019 lautet, erzeugt folgendes Kommando eine ISO-Datei D:\Images\Windows_Server_2019_
Custom.iso:

.\oscdimg.exe -m -o -u2 -udfver102 -bootdata:2#p0,e,bD:\Build\
Windows_Server_2019\boot\
etfsboot.com#pEF,e,b
D:\Build\Windows_Server_2019\
efi\microsoft\boot\efisys.bin D:\Build\Windows_Server_2019 D:\Images\Windows_Server_
2019_Custom.iso

Installationsmedien für neue Windows-Versionen

Ist ein Installationsmedium für eine neue Windows-Version (zum Beispiel für Windows Server 2022) zu erstellen, wird ein neues Build-Verzeichnis angelegt, in das man folgende Dateien und Verzeichnisse kopiert.

.\Autounattend.xml
.\drivers
.\sources\$OEM$

Wenn sonst keine weiteren Anpassungen notwendig sind, lässt sich das Installationsmedium wie beschrieben neu erzeugen. Und schon ist die automatisierte Installation für die neue Windows-Version adaptiert.

 

Über den Autor

Die TEAL Technology Consulting GmbH ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Zudem gehört TEAL zu den führenden Anbietern für die Adaption des Microsoft ESAE-Modells zur sicheren Infrastruktur-Administration. Als Partnerfirma ergänzt TEAL sinnvoll das Portfolio der FB Pro GmbH.

 

Bilder:  www.freepik.com, Microsoft, TEAL

Schreibe einen Kommentar