Unser Blog-Beitrag für diesen Monat beschäftigt sich mit einem Thema, das nicht direkt mit Informationssicherheit zu tun hat. Dennoch darf dieses Thema nicht unterschätzt und vernachlässigt werden. Es geht um die automatisierte Installation von Windows Server im Unternehmen. Das hört sich erst einmal unspektakulär an, wir werden aber im Laufe des Artikels noch ausführen, wo die Stolpersteine versteckt sind.  

Für das automatisierte Deployment von Windows im Unternehmen 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 wie den Configuration Designer, den System Image Manager oder das Windows Preinstallation Environment (WinPE). 

• • Tool-Suiten wie Microsoft Endpoint Configuration Manager, die Windows automatisiert auf einer Vielzahl von Endgeräten für Benutzer oder Servern in Rechenzentren installieren können. Der Endpoint Configuration Manager nutzt auch die Tools aus dem Windows ADK, erleichtert aber den Umgang mit diesen Tools, indem er viele Details vor dem Administrator verbirgt und stellt eine Infrastruktur zur Verfügung, um das Deployment auf tausenden Endgeräten ohne manuelle Eingriffe zu ermöglichen. 
  • In virtualisierten On-Premises Rechenzentren werden Produkte der Virtualisierungshersteller wie VMware vSphere oder Microsoft Virtual Machine Manager verwendet, um Templates für virtuelle Maschinen zu erstellen, die zum Deployment einer großen Anzahl von VMs verwendet werden können. 

Die Windows-Installation soll auf den Endsystemen – unabhängig ob es sich um ein Endgerät für einen Endanwender oder einen Server in einem Rechenzentrum handelt – möglichst automatisiert mit wenigen manuellen Tätigkeiten durchgeführt werden. Eine Automatisierung führt zu geringerem Aufwand bei der Installation von Systemen und zu einer Reduktion von Fehlkonfigurationen, die bei der Ausführung von vielen manuellen Schritten immer wieder vorkommen. Zudem können automatisierte Systeme im Fehlerfall schnell wieder neu installiert werden und somit die potenzielle Ausfallzeit erheblich verringern.    

Tier 0-Umgebungen nach ESAE weisen normalerweise einen hohen Virtualisierungsgrad auf, weshalb sich dort die dritte Option mit dem Deployment von VM-Templates häufig anbietet. Wir möchten in diesem Blog den Schwerpunkt auf der Erstellung der Sourcen und Installationsmedien beschränken. Das letztendliche Deploymentverfahren ist abhängig von dem konkreten Einsatzszenario. Bei zusätzlichen Fragen könnt ihr jedoch gerne auf uns zukommen 😊.  

Das Grundprinzip dabei ist, dass eine VM mit Windows Server installiert wird, zusätzliche Konfigurationen durchgeführt werden, wie das Aktivieren von Credential Guard und die zusätzlich notwendige Software wie Virenscanner, Monitoring- und Backupagenten oder die Microsoft Local Administrator Password Solution (LAPS) installiert werden. Auf Basis dieser VM wird dann ein Template erstellt, mit dem die VMs in der Umgebung installiert werden.   

Die Basis-VM für das Deployment Template kann manuell oder automatisiert installiert werden. Bei einer manuellen Installation müssen dann alle Schritte dokumentiert werden, um auch bei Änderungen in der Lage zu sein, eine neue Version des Deployment Templates zu erstellen, die dem definierten Standard entspricht. Mit einer automatisierten Installation ist der initiale Aufwand höher, weitere Änderungen sind dann jedoch einfacher und sicherer umzusetzen. 

Automatisieren 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 werden Treiber, Apps und Konfigurationsanpassungen hinzugefügt und anschließend wird die Windows-Installation mit dem Tool Sysprep generalisiert. 
  • Beim Offline Servicing wird das Windows-Image vom Installationsmedium kopiert und mit dem Tool DISM in ein temporäres Verzeichnis eingebunden (englisch: mounted). Die Ä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.  

Unabhängig welche Methode gewählt wurde, kann das Image dann auf einer beliebigen Anzahl von Systemen installiert werden. 

Das Offline Servicing hat den Nachteil, dass bei einer neuen Version des Images die Schritte zur Anpassung des Images manuell wiederholt werden müssen. Beim Online Servicing können die zur Installation hinzugefügten Dateien bei einer neuen Version des Betriebssystems zum Installationsmedium hinzugefügt werden und dabei eine neue Image-Version erzeugt werden. Diese Methode soll hier kurz vorgestellt werden. 

Erzeugen einer Autounattend.xml

Die während einer Windows-Installation notwendigen Eingaben wie die Auswahl der Betriebssystem-Edition oder Sprache und Tastaturlayout können mit einer Antwortdatei unterdrückt werden. Das Windows-Setupprogramm verwendet die in dieser Datei hinterlegten Einstellungen und installiert Windows automatisch und zeigt keine Dialoge für Eingaben an. 

Zur Erstellung und Anpassung von Antwortdateien enthält das Windows ADK das Tool Windows System Image Manager (Windows SIM). Mit diesem grafischen Tool können die Einstellungen für das Windows Setup angepasst werden.

Hinzufügen von bootkritischen Treibern

Windows enthält den sogenannten Driver Store. Der Driver Store enthält Treiberpakete, die im Verzeichnis %SystemRoot%\System32\DriverStore gespeichert sind. Während der Installation liest Windows die Hardware-IDs der angeschlossenen Geräte aus und sucht im Driver Store (und ggf. auch auf Windows Update und zusätzlichen Lokationen) nach passenden Treiberpaketen und installiert diese.

Bootkritische Treiber sind Treiber, die unbedingt installiert und geladen werden müssen, so dass Windows überhaupt installiert werden kann. Das sind insbesondere Treiber für I/O-Controller, die den Zugriff auf die Festplatte steuern. Denn ohne einen funktionierenden Treiber ist natürlich auch kein Zugriff auf die Festplatte möglich und damit kann Windows nicht installiert werden.

Treiber, die nicht im Lieferumfang von Windows und damit nicht im Driver Store enthalten sind, müssen in das Build-Verzeichnis integriert werden. Dazu wird ein Verzeichnis für die Treiber im Build-Verzeichnis erstellt und auf dieses Verzeichnis wird in der Autounattend.xml referenziert. Die Treiber in diesem Verzeichnisbaum werden dann vom Windows-Setupprogramm installiert.

Ein weitverbreitetes Beispiel, in dem ein bootkritischer Treiber benötigt wird, ist bei VMware VMs, die den VMware Paravirtual SCSI Controller verwenden. Die notwendigen Treiber sind nicht im Lieferumfang von Windows enthalten und werden von der VMware Tools ISO in das Verzeichnis .\drivers kopiert.

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

Erstellen eines Installationsmediums für neue Windows-Version

Wird ein Installationsmedium für eine neue Windows-Version wie z.B. für Windows Server 2022 benötigt, wird ein neues Build-Verzeichnis erstellt und folgende Dateien und Verzeichnisse in das Build-Verzeichnis kopiert.

Wenn sonst keine weiteren Anpassungen z.B. durch geänderte Einstellungen der neuen Windows-Version in der Antwortdatei notwendig sind, kann das Installationsmedium wie oben beschrieben neu erzeugt werden und schon ist die automatisierte Installation für die neue Windows-Version adaptiert.

Fazit

Der Artikel beschreibt die grundlegenden Schritte für eine Automatisierung einer Windows-Installation, die für ESAE Tier 0-Umgebungen ohne Tool-Suite wie Endpoint Configuration Manager oder als Basis für eine weitgehend automatisierte Erstellung von vSphere Templates dienen kann und wir hoffen, dass das für den Arbeitsalltag hilfreich ist.