Windows Server Deployment
5396
post-template-default,single,single-post,postid-5396,single-format-standard,bridge-core-2.9.0,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-28.5,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-6.7.0,vc_responsive

Windows Server Deployment

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.

Das Ergebnis der Anpassungen in Windows SIM ist eine Antwortdatei im XML-Format. Nachstehend ein gekürzter Ausschnitt aus einer beispielhaften Antwortdatei zu Illustrationszwecken.

<?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 in ein sogenanntes Build-Verzeichnis kopiert. Die Antwortdatei wird in diesem Build-Verzeichnis abgelegt und erhält den Namen Autounattend.xml. Das Windows Setup sucht auf dem Root-Verzeichnis des Installationsmediums nach einer Datei mit diesem Namen und verwendet diese dann.

Das Ergebnis der Anpassungen in Windows SIM ist eine Antwortdatei im XML-Format. Nachstehend ein gekürzter Ausschnitt aus einer beispielhaften Antwortdatei zu Illustrationszwecken.

<?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 in ein sogenanntes Build-Verzeichnis kopiert. Die Antwortdatei wird in diesem Build-Verzeichnis abgelegt und erhält den Namen Autounattend.xml. Das Windows Setup sucht auf dem Root-Verzeichnis des Installationsmediums nach einer Datei mit diesem Namen und verwendet diese dann.

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.

<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>

<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

Seit den ersten Windows NT-Versionen verfügt Windows über einen Mechanismus, Dateien zur Installation hinzuzufügen. Im Verzeichnis .\sources wird ein Unterverzeichnis $OEM$ erstellt. 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$\$1Reprä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 es, zum Verzeichnis %SystemRoot%\Setup\Scripts eine Datei SetupComplete.cmd hinzuzufügen. Diese Batchdatei wird am Ende des Setups automatisch ausgeführt. Diese muss dann im Build-Verzeichnis nach .\sources\$OEM$\$$\Setup\Scripts kopiert werden.

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

In der Batchdatei SetupComplete.cmd können dann Applikationen installiert oder weitere Scripts ausgeführt werden, die in Verzeichnissen unter C:\Install vom Windows-Setupprogramm kopiert werden. Dieses Verzeichnis kann dann am Ende der Installation durch ein Script gelöscht werden.

Hinzufügen von Scripts und Applikationen

Seit den ersten Windows NT-Versionen verfügt Windows über einen Mechanismus, Dateien zur Installation hinzuzufügen. Im Verzeichnis .\sources wird ein Unterverzeichnis $OEM$ erstellt. 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$\$1Reprä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 es, zum Verzeichnis %SystemRoot%\Setup\Scripts eine Datei SetupComplete.cmd hinzuzufügen. Diese Batchdatei wird am Ende des Setups automatisch ausgeführt. Diese muss dann im Build-Verzeichnis nach .\sources\$OEM$\$$\Setup\Scripts kopiert werden.

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

In der Batchdatei SetupComplete.cmd können dann Applikationen installiert oder weitere Scripts ausgeführt werden, die in Verzeichnissen unter C:\Install vom Windows-Setupprogramm kopiert werden. Dieses Verzeichnis kann dann am Ende der Installation durch ein Script gelöscht werden.

Erstellen eines Installationsmediums

Nachdem die Installationsdateien und Scripts hinzugefügt wurden, wird das Installationsmedium erstellt.

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 werden 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 VMs wird ein ISO-Installationsmedium verwendet. 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.

Zum Erstellen des ISO-Installationsmedium wird das Tool Oscdimg verwendet, das Bestandteil der Deployment Tools im Windows ADK ist. Wenn das Build-Verzeichnis 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

Bei der Verwendung von vSphere, kann nach der Installation von Windows auf einer Referenz-VM diese in ein Template kopiert werden. VMs können nun auf Basis dieses Templates installiert werden und dabei eine Anpassung von Windows durchgeführt werden, das Sysprep ausführt, den Computername ändert und einen Domänenbetritt durchführt.

Erstellen eines Installationsmediums

Nachdem die Installationsdateien und Scripts hinzugefügt wurden, wird das Installationsmedium erstellt.

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 werden 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 VMs wird ein ISO-Installationsmedium verwendet. 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.

Zum Erstellen des ISO-Installationsmedium wird das Tool Oscdimg verwendet, das Bestandteil der Deployment Tools im Windows ADK ist. Wenn das Build-Verzeichnis 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

Bei der Verwendung von vSphere, kann nach der Installation von Windows auf einer Referenz-VM diese in ein Template kopiert werden. VMs können nun auf Basis dieses Templates installiert werden und dabei eine Anpassung von Windows durchgeführt werden, das Sysprep ausführt, den Computername ändert und einen Domänenbetritt durchführt.

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.

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

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.

LATEST POSTS

  • In der Blog Kategorie „Secure Administration Environment" möchten wir unsere Erfahrungen von Kundenprojekten rund um Microsofts Enhanced Security Administration Environment (ESAE) wiedergeben, sodass andere von unseren Erfahrungen lernen können...

  • Wie in unserem Einleitungsartikel zur ESAE Serie angekündigt, möchten wir hier im zweiten Artikel näher auf die Kundensituation und die Architektur der Lösung eingehen. Obwohl der Kunde in zahlreichen Ländern...

  • Wie bereits im letzten Artikel (LINK) zur ESAE Serie angekündigt, möchten wir in diesem Artikel den technischen Kern der an ESAE orientierten Umgebung, der die Just-in-Time-Administration möglich...