Zentrales PC-Deployment auf Basis eines Linux-Deployment-Servers - IPA Lea

Glossar

Informieren

Erfassung der benötigten Hardware

Hardware Server und PCs

Zur Erfassung der Hardware wurde die Linux-Distribution GRML¹⁾ eingesetzt. GRML ist ein auf Debian basierendes Live-System, das v.a. als Rettungssystem für Systemadministratoren bekannt ist. Die Geräte wurden mit GRML gebootet. Danach wurden mit dem Befehl dmidecode²⁾ die Infos zu Modell, CPU und Memory ermittelt. Mit lspci wurde die die Info zum Netzadapter gefunden, mit smartclt -a /dev/mydrive die Informationen zu den Disks.

Hardware Switch

Erfassung der benötigten Services

Die Virtualisierungsplattform Proxmox VE

Proxmox VE ist eine Open Source-Virutalisierungsplattform für Server³⁾. Sie basiert auf der Linux-Distribution Debian. Unterstützt werden KVM- und Container-basierte Virtualisierung. Ûber eine webbasierte Verwaltungsoberfläche lassen sich virtutelle Maschinen, Container, Storage, virtuelle Netzwerke sowie Hochverfügbarkeits-Cluster verwalten.

Beim vorgängig erstellten Proxmox-System handelt es sich um einen Einzelserver ohne Clusteranbindung. Als Storages stehen local für Betriebssystem-ISO's und lokale Backups sowie lvm-thin für VM's zur Verfügung. Das Webinterface erreicht man unter der URL https://172.16.53.x:8006.

Beim Erstellen einer virtuellen Maschine müssen zu folgenden technischen Details Entscheidungen getroffen werden:

• Auf welchem Node wird die VM erstellt (bei einem Cluster)
• Grafikkarte
• Disk-Controller
• Harddisk
• CPU
• Memory
• Netzwerk

Die Backup-Services mittels BackupPC

In der Rafisa kommt die Backuplösung BackupPC⁴⁾ zum Einsatz. Dabei handelt es sich um eine freie Disk-zu-Disk Backup-Suite, die in PHP geschrieben ist. Als Übertragungsarten stehen smb für das Backup von Windows-Shares, sowie rsync für die Sicherung der Daten mit Hilfe des rync-Protokolls zur Verfügung. Zusätzlich lassen sich die Funktionalitäten mit Pre- und Post-Backupscripts erweitern. Die Hauptfeatures der Lösung sind:

• Webbasiertes Administrationsinterface: Konfiguration von Backups, Analyse der Logfiles, manuelles Starten und Stoppen von Backups, Browse und Restore von Backupdaten
• Datendeduplikation: Identische Files von mehreren Backups des selben Clients oder von verschiedenen Clients werden nur einmal gespeichert. Das erlaubt Einsparungen im Bereich der benötigten Kapazitäten sowie des Disk I/Os.
• Kompression: Da nur neue Files komprimiert werden müssen, werden die CPUs nur moderat beansprucht
• Open-Source: BackupPC wird auf Github gehostet und unter einer GPL-Lizenz verteilt
• Es wird keine clientseitige Software benötigt

Im Rahmen von Vorarbeiten wurde beim Team SRB (ServiceRestoreBackup) ein Zugang zum firmeninternen Backupserver beantragt. Der SLA #001: Backup und Restore v.01⁵⁾ entnimmt man folgende für das vorliegende Projekt wichtige Informationen:

• Der Service Backup und Restore wird durch das Team SBR angeboten.
• Der Zugang zum Webinterface von BackupPC ist nur über das Management-VLAN möglich
• Der oder die Systemverantwortliche muss die Backupdaten bestimmen und die Strategie mit dem Team SBR absprechen
• Es stehen folgende Backuparten zur Verfügung: Backup von SMB-Shares, File-Backup von Serversystemen, Image Backup von Proxmox-VMs, Backup von Datenbank-Systemen, Backup der Konfigurationsdateien von Switches und Firewalls

Mit dem Team Backup und Restore wurde als Vorarbeit der Backup-User rafisa-backup auf dem Proxmox-System angelegt. Über diesen User hat BackupPC Zugriff auf den Proxmox-Server.

In der Planung müssen folgende Punkte berücksichtigt werden:

• Zugriff ins Management-VLAN
• Festlegen von Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten gemeinsam mit dem Teamleader SBR
• Bestimmen der angemessenen Backupart

Die Deploymentlösung FOG Project

Was ist FOG

FOG⁶⁾ ist eine Linux-basierte, freie und quelloffene Computer-Imaging-Lösung für verschiedene Versionen von Windows (XP, Vista, 7, 8/8.1, 10), Linux und Mac OS X. Spezialisierte Open-Source-Tools werden integriert und können über eine PHP-basierte Administrationsoberfläche verwaltet werden. Zur Anbindung von Clients werden keine Boot-Medien verwendet, sondern es werden ausschliesslich TFTP und PXE eingesetzt. Die Clients booten über PXE und laden automatisch einen schlanken Linux-Client herunter, der das Imaging der Maschinen übernimmt. Der Kernel des Linux-Clients unterstützt eine Vielzahl von marktüblichen Netzwerkadaptern, so dass man sich im Normalfall nicht um Netzwerktreiber kümmern muss. Sollte ein spezieller Treiber benötigt werden, kann ein angepasster Kernel für den Boot-Client kompliert werden. Unterstützt werden unter anderem die Anpassung der Diskgrösse an kleinere Ziel-Disks, Multicasting sowie die Verschlüsselung des Zugriffs auf die Weboberfläche und des Imaging-Streams.

Features

Folgende Features stehen zur Verfügung⁷⁾:

• PXE-Boot-Umgebung (DHCP, iPXE, TFTP, schneller HTTP-Download von großen Boot-Dateien wie Kernel und initrd)
• Imaging von Windows (XP, Vista, 7, 8/8.1, 10), Linux und Mac OS X
• Partitionen, volle Festplatte, mehrere Festplatten, grössenveränderbar, raw
• Snapins zum Installieren von Software und Ausführen von Jobs/Skripten auf den Clients
• Drucker-Verwaltung
• Hostname ändern und Domäne beitreten
• Verfolgen von Benutzerzugriffen auf Computern, automatisches Abmelden und Herunterfahren bei Leerlaufzeitüberschreitungen
• Virenschutz
• Löschen von Festplatten
• Gelöschte Dateien wiederherstellen
• Suche nach fehlerhaften Blöcken

Unterschiede zwischen WDS/MDT und FOG

In einer früheren IPA⁸⁾ wurde eine Windows-Deployment-Umgebung auf Basis der Windows Deployment Services (WDS) aufgesetzt. Das Management des Setup-Prozesses wurde dabei durch das Microsoft Deployment Toolkit (MDT) vorgenommen. Mit MDT können die Phasen des Windows-Setups gesteuert und durch Vorgabewerte in einem Answer-File kontrolliert werden.

Der Hauptunterschied zwischen WDS/MDT und FOG besteht darin, dass es sich bei FOG um ein Block-Imaging-Tool (BIT), bei WDS/MDT um ein File-Level-Imaging-Tool (FLIT) handelt⁹⁾. Bei einem BIT werden Datenblöcke von einem lokalen Speicher auf einen Netzwerk-Speicher (Capturing) und zurück (Deploying) kopiert. Dabei werden meistens fertige, vorher vorbereitete Betriebssystemimages verteilt. Bei einem FLIT werden Files vom Deploymentsystem zum Zielcomputer kopiert, aus welchen das Betriebssystem auf dem Zielcomputer erst aufgebaut wird. Bei WDS/MDT hat man auch nach Abschluss des Building-Prozesses mehr Möglichkeiten, das Image über weitere Verteilprozesse zu verändern und anzupassen. Bei FOG wird eine fertiges FAT-Image verteilt, das sich im Nachhinein nur bedingt noch verändern lässt. Dafür ist die FOG-Lösung wesentlich schneller als WDS/MDT. Während der Aufbau eines Betriebssystems unter WDS/MDT gerne 60min und mehr in Anspruch nehmen kann, ist das FOG Image bei einem schnellen Netzwerk sehr schnell verteilt und betriebsbereit. Der für die Rafisa wichtigste Unterschied besteht aber darin, dass sich über WDS/MDT nur Windows-Images verteilen lassen (es ist zwar möglich, Linux zu verteilen, dann verliert man aber alle Vorteile der Lösung), während die FOG-Lösung auch für andere Betriebssysteme offen ist.

Einbettung der Testumgebung in das Netzwerk der Rafisa

Die Testumgebung der IPA ist eingebettet in das Netzwerk der Rafisa Informatik GmbH. Es ist für das Gelingen der IPA - z.B. im Falle einer Netzstörung, die sich auf meine Testumgebung auswirkt - wichtig, dass die zentralen Parameter dieser Einbettung bekannt sind. Deshalb wird ein L3-Netzplan (oder auch L3-Diagramm¹⁰⁾ erstellt, das IPA-VLAN (VLAN53_LAB03 / 172.16.53.0/24) im Gesamtzusammenhang des Rafisa-Netzwerks zeigen soll. Dem Rafisa-Wiki lassen sich die Firmenstandards für die VLANs entnehmen.

VLANs der Rafisa Dietikon

zh.rafisa.org - 172.16.0.0/12

Berechtigungsmatrix

Die Matrix wird Zeile nach Spalte gelesen (Zugriff von Zeile nach Spalte erlaubt/nicht erlaubt)

L3-Diagramm des Rafisa-Netzwerkes

Als Gateway haben die Geräte das Firewall VLAN-Interface des entsprechenden Subnetzes, für das VLAN01-MGMT also z.B. 172.16.1.1/24. Der Gateway für die IPA-Testumgebung ist demnach 172.16.53.1/24. Der Berechtigungsmatrix kann man entnehmen, dass die Zugänge zu allen anderen VLAN's der Rafisa durch Filterrules auf der Firewall geblockt werden. Die Firewall stellt ausser dem Gateway für den Internetzugang einen DHCP-Dienst zur Verfügung, über welchen IP-Adressen aus dem entsprechenden Subnetz, die Gateway-IP sowie die IP-Adressen der DNS-Server verteilt werden. Alle im L3-Diagramm festgehaltenen System verfügen über statische IP-Adressen.

---

---

Beschreibung der Firmenstandards für das Rafisa Standard-Image

Die Firmenstandards für das Standardimage können dem Rafisa Wiki¹¹⁾ entnommen werden:

Partitionierung

Nur eine Datenpartition C: mit maximaler Grösse für Windows und Programme.

Software

Anpassungen

Applikationen

Wallpaper

Hier findet sich das Standard-Hintergrundbild:

Es wird nach C:\Windows\Web\Wallpaper heruntergeladen und dann mit dem Desktop verknüpft.

Standardbenutzer

Auf jedem System muss der Nutzer sysadmin vorhanden sein. Der Benutzer soll der Gruppe Administratoren angehören.

Beschreibung der Firmenstandards für das Namenskonzept

Benutzer

Benuternamen setzen sich zusammen aus dem ersten Buchstaben des Vornamens plus dem Nachnamen. Sollten sich bei neuen Nutzern gleichlautende Benutzernamen ergeben, wird die Anzahl Buchstaben des Vornamenkürzels um 1 erhöht.Bei identischen Vor- und Nachnamen wird das Benutzerkürzel um eine fortlaufende Nummer, beginnend bei 01 ergänzt.

Beispiele:

• h.muster → Hans Muster
• he.muster → Hedwig Muster
• her.muster → Herta Muster
• h.muster01 → Hans Muster

Geräte

Der Gerätename setzt sich zusammen aus einem Kürzel für die Funktion, dem Kürzel für den physikalischen Standort sowie einer fortlaufenden Nummer, beginnend bei 01.

Beispiele:

• dc-zh-ruga-01
• sw-zh-r02a-03

Kürzel für die Funktionsbezeichnungen

Physikalische Standorte

Der physikalische Standort setzt sich zusammen aus dem Kürzel für den Standort sowie einer internen Raumangabe. Bei Geräten, welche in einem Rack stehen, werden anstelle der Raumangabe das Kürzel für das Rack angegeben.

Beispiele:

• zh-ruga
• zh-201

Kürzel für die Standorte

Kürzel für die internen Räume

Kürzel für Racks

Planen

Einrichten der Testumgebung

Wie im L3-Netzplan gezeigt, steht für dieses Projekt das Labor-VLAN VLAN53_LAB03 (Subnetz 172.16.53.0/24) zur Verfügung. Das Labornetz hat über den Gateway 172.16.53.1/24 Zugang zum Internet. Der Zugang zu allen anderen VLAN's der Rafisa wird durch die Firewall gesperrt. Für eine funktionierende Lösung müssen in der Testumgebung folgende Netzwerk-Dienste zur Verfügung gestellt werden:

• DHCP (mit den für das Deployment nötigen Bereichsoptionen)
• DNS (mit A-Records für alle L3-Geräte der Testumgebung)
• TFTP (zum Laden des FOG Boot-Images über PXE)
• AD

Grundsätzlich können die meisten Dienste von unterschiedlichen Systemen in der Testumgebung zur Verfügung gestellt werden:

Für das Subnetting der Testumgebung gibt es nicht viele Varianten. Es liegt nahe, direkt das Labornetz 172.16.53.0/24 zu verwenden. Alle anderen Subnetze müssten zusätzlich über den Gateway 172.16.53.1 geroutet werden, was nur zusätzlichen Aufwand (z.B. Einrichten eines Servers als Router) mit sich bringen würde.

OS-Versionen

Windows 2019 Servers

Auf der Seite der Firma Thomas Krenn¹⁸⁾ findet man einen sehr nützlichen Vergleich der Windows Editionen.

Sowohl bei Datacenter/Standard als auch bei Essentials stehen alle benötigten Serverrollen zur Verfügung. Auch die Unterschiede in den Features fallen nicht ins Gewicht.

Ubuntu Server

Beim Betriebssystem Ubuntu müssen in zwei Bereichen Entscheidungen getroffen werden:

1. Desktop-Version vs. Server-Version
2. LTS vs. Standard-Releases

Desktop-Version vs. Server-Version

Die Desktop-Version verfügt über eine vollständige grafische Oberfläche, die Server-Version nur über die Kommandozeile. Die Serverversion benötigt deshalb wesentlich weniger Ressourcen. Die folgende Tabelle zeigt die Unterschiede zwischen den Versionen¹⁹⁾:

LTS vs. Standard-Releases

LTS steht für „Long-Term-Support“. LTS-Releases waren ursprünglich für Geschäftsanwender gedacht, um ihnen eine stabile Plattform zu bieten, die sie installieren können und die über Jahre hinweg mit Sicherheitsupdates unterstützt wird.²⁰⁾

Allerdings produziert Ubuntu auch alle sechs Monate neue Versionen. Traditionell hielten sich Durchschnittsanwender an die alle sechs Monate erscheinenden Versionen. Diese waren der Standardweg, um Ubuntu zu bekommen, bevor die LTS-Versionen veröffentlicht wurden. Selbst nach den ersten LTS-Versionen bot jede neue Version von Ubuntu überzeugende Funktionen und wichtige neue Software-Versionen, was sie für durchschnittliche Desktop-Benutzer interessant machte.

Virtuelle Hardwareressourcen und Partitionierung

Beim Erstellen der Windows 2019 Server-VM auf dem Proxmox-Server müssen Entscheidungen zu den Hardware-Ressourcen²¹⁾ sowie zur Partitionierung getroffen werden. Bei den Ressourcen gibt es immer mehrere Möglichkeiten, die virtuellen Geräte zu emulieren:

Harddisk Bus / Device

QEMU kann verschiedene Speicher-Controller emulieren:

Disk-Format

Netzwerkadapter

CPU

Wie im Ist-Zustand festgehalten verfügt der phsyische Server, auf dem Proxmox VE installiert ist, über 1 Socket und 4 Cores mit je zwei Threads, dh. über 8 logische CPUs. Um eine bessere Auslastung der Ressourcen zu erhalten, können den VMs mehr CPUs zugeteilt werden, als physisch vorhanden sind. Man spricht dann von Überbuchen²²⁾. Man darf aber nicht vergessen, dass der Proxmox-Server auch noch CPU-Ressourcen braucht.

Memory

Der Proxmox-Server verfügt über 16GB Ram. Auch hier muss man beachten, dass nicht vollständig alles RAM den VMs zugeteilt wird, da der Proxmox-Server ebenfalls noch Memory benötigt.

Partitionierung

Für die Partitionierung des Windows 2019 Servers muss entschieden werden, ob nur eine Windows-Partition oder noch zusätzliche Partitionen erstellt werden. Bei Ubuntu kann die Partitionierung automatisch oder manuell vorgenommen werden. Es muss ebenfalls entschieden werden, ob man eine grosse Root-Partition macht, oder den Linux-Verzeichnissen einzelne Partitionen zuteilt.

AD-OU-Struktur

Für das Erfassen der geforderten Benutzer und Computer können die AD-Standardcontainer Users und Computers verwendet werden. Ausserhalb von Testumgebungen besteht das Ziel des AD-Designs aber im Entwurf einer Struktur, die der Verwaltung der Objekte innerhalb eines Betriebs möglichst dienlich ist. In der Rafisa hat sich als Standard folgende einfache Struktur herausgebildet:

Erstellen des Windows Standard-Images

Sysprep vs. Fat-Image mit integrierten Treibern

Es gibt zwei Möglichkeiten ein Windows-Image für die Verteilung mit FOG zu erstellen. Man kann Windows mit allen benötigten Applikationen und allen Vorgaben auf einem Computer einrichten und dann davon eine Abbilddatei erstellen (Fat-Image). Als zweite Möglichkeit lässt sich ein Masterimage im sogenannten Audit Mode erstellen. Nach Abschluss aller gewünschten Installationen und Konfigurationen im Audit-Modus, werden alle eindeutigen Systeminformationen automatisch aus der Windows-Installation per Sysprep entfernt. Sysprep setzt folgende Einstellungen zurück:

• Alle Einträge in der Ereignisanzeige
• Alle Wiederherstellungspunkte
• es deaktiviert das Konto des lokalen Administrators und löscht sein Profil
• Security Identifier (SID)
• Plug- und Play-Gerätetreiber, die während der Installation hinzugefügt wurden

Nach der Verteilung des Images startet das frisch verteilte System dann im Windows-Konfigurations-Schritt „specialize“. Die Windows Konfigurations-Schritte sind Phasen, die bei einer Windows-Installation durchlaufen werden²³⁾.

Erstellen des Windows Standard-Images: MBR vs. GPT-Image

Einrichten des Ubuntu Servers

Version

Virtuelle Hardwareressourcen, Partitionierung

Einrichten des FOG-Server

Welche Features werden benötigt

Im Kapitel Informieren sind die Features von FOG aufgezeigt worden (Maximalvariante). In der folgenden Tabelle wird gezeigt, welche Features für die Erfüllung des Auftrages tatsächlich notwendig sind.

Verschlüsselte vs. unverschlüsselte Kommunikation

Es besteht die Möglichkeit, bei FOG den Webzugang über HTTP mit SSL (HTTPS) zu verschlüsseln. Dieser Zugang wird für drei Funktionen verwendet:

1. Zugang zum Web-Administrationsinterface
2. Das FOG-Boot-Image, das über PXE geladen wird, kann das Image von FOG-Server verschlüsselt oder unverschlüsselt erhalten
3. Der FOG-Client, der als Applikation unter Windows installiert ist, kann sich verschlüsselt oder unverschlüsselt mit dem FOG Server verbinden

Bei der Entscheidung für die Verschlüsselung muss man berücksichtigen, dass Verschlüsselung immer mit einem höheren Aufwand an den Prozessor und damit mit einer etwas geringeren Geschwindigkeit verbunden ist.

Unicast vs. Multicast-Deployment

Multicast stellt in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe dar und ist daher eine Form der Mehrpunktverbindung. Unicast stellt in der Telekommunikation die Adressierung einer Nachricht an einen einzigen Empfänger dar.

Multicast bietet beim Deployment den grossen Vorteil, dass eine Image Datei im Netzwerk nur einmal übertragen werden muss. Dabei melden sich die Clients alle bei der Multicast Session an. Clients, welche sich inmitten der Multicast Übertragung dazugesellen, müssen am Ende der Übertragung den ersten Teil der Übertragung mitgeteilt bekommen.

Ich habe mir in einem Flussdiagramm überlegt, wann es sinnvoll ist, Unicast zu verwenden, und wann sinnvollerweise Multicast zum Einsatz kommt: DIAGRAMM

Backup und Restore

Backupart

BackupPC bietet verschiedene Backuparten an:

• Backup von SMB-Shares,
• File-Backup von Serversystemen
• Image Backup von Proxmox-VMs
• Backup von Datenbank-Systemen
• Backup der Konfigurationsdateien von Switches und Firewalls

Für Backup der Server kommt File-Backup und Image-Backup infrage.
Funktionsweise File-Backup: BackupPC startet zur gewünschten Zeit den rsync-Befehl und kopiert alle gewünschten Files von einem Server. Wenn man als Zielverzeichnis / angibt, wird der gesamte Server kopiert.
Funktionsweise Image-Backup : Zur gewünschten Zeit loggt sich BackupPC auf dem Proxmox-Server ein und führt mit dem Befehl vzdump²⁴⁾ ein Image-Backup der VMs durch.

Rahmenbedingungen

Entscheiden

Backup und Restore

Backupart

• für ds-zh-202-01 beides möglich, für dc-zh-202-01 nur Image-Backup möglich.
• ds-zh-202-01 enthält auch grosse Image-Files → Vorteile des Filebackup gehen verloren
• → für beide Server wird ein Image-Backup mit vzdump gemacht

Rahmenbedingungen

Erwartete Datenmengen und Transferzeiten wurden dem Team Backup und Restore gemeldet und sind bestätigt.

Ubuntu Server

Desktop-Version vs. Server-Version

Wie gesehen benötigt die Server-Version wesentlich weniger Ressourcen, als die Desktop-Version. Der Verzicht auf einen vollständigen Desktop bietet auch Stabilitäts und Sicherheitsvorteile. Ein Linux-Server kann zudem vollständig über die Kommandozeile verwaltet werden, eine grafische Oberfläche ist nicht notwendig.

LTS vs. Standard-Releases

Bei einem Server steht Stabilität und Sicherheit im Vordergrund. Neue Features werden nur in Ausnahmefällen benötigt. Deshalb soll die letzte LTS-Version, nämlich Ubuntu Server 20.04 LTS eingesetzt werden.

Realisieren

Backup und Restore

• Der Backupserver ist unter der IP-Adresse 172.16.1.100/backuppc erreichbar.
• Nach Login erstellen eines neuen Hosts: Im Menu links Edit Hosts drücken

Erstellen des Windows 10 Images

Basisinstallation Windows 10 Enterprise N

Unter Proxmox wird das heruntergeladene Windows 10 Enterprise N 20H2 ISO installiert. Vor der Installation sollte das virtuelle Netzwerkkabel gezogen werden, da Windows sonst während des Installationsvorgangs automatisch aktiviert wird. (SCREENSHOTS von den Hardware-Einstellungen auf Proxmox)

In den Audit-Mode wechseln

Nach der Installation bootet das System in diesen Konfigurations-Screen:

Um in den Audit-Mode²⁷⁾ zu gelangen, drückt man an dieser Stelle CTRL + SHIFT und dann die F3-Taste. Das System startet unverzüglich neu, nach dem Reboot befindet man sich im Audit-Mode. Das virtuelle LAN-Kabel kann nun wieder verbunden werden. Im automatisch erscheinenden Sysprep-Dialog klickt man auf Abbrechen. Da es sich um ein Firmennetzwerk handelt, kann zugelassen werden, dass der PC von anderen Geräten im Netzwerk gesehen wird.

Installation von Windows-ADK

Um das System konfigurieren und die ensprechenden Answer-Files²⁸⁾ anlegen zu können, benötigt man die Windows-Bereitstellungstools aus dem Windows Assessment and Deployment Kit (ADK)²⁹⁾. Es wird die Version ADK für Windows 10, Version 2004 heruntergeladen³⁰⁾. Während der Installation werden im Feature-Dialog ausschliesslich die Bereitstellungstools ausgewählt:

Windows-Image anpassen

Alle die Anpassungen, die im Audit-Mode vorgenommen werden, werden ins Default-Profil geschrieben und stehen dann allen BenutzerInnen zur Verfügung. Die Anpassungen bleiben auch im Domain-Modus erhalten.

Zunächst werden die im Kapitel Informieren beschriebenen Anpassungen (Explorer, Teams, Remote-Desktop und Wallpaper) vorgenommen. Nachdem die Anpassungen vorgenommen worden sind, werden die für das Image benötigten Programme installiert (s. Kapitel Informieren). Die Programme werden alle in den Default-Einstellungen installiert.

Danach werden die Layout-Anpassungen für das Startmenu und die Taskleiste vorgenommen. Die Layouteinstellungen sind in einer XML-Datei gespeichert. Nachdem man das Menu und die Taskleiste angepasst hat, kann man die Layoutdatei mit dem Befehl Export-StartLayout –path C:\LayoutModification.xml exportieren und dann über die lokale GPO-Richtlinie Administrative Vorlagen/Startmenü und Taskleiste/Startlayout einbinden:

Für die Standardzuordungen der Applikationen muss auch ein XML-File exportiert und danach wieder importiert werden. Mit dem Befehl dism /Online /Export-DefaultAppAssociations:„C:\DefaultAppAssociations.xml“ nach C:\DefaultAppAssociations.xml kopiert. Um es für neue Userprofile dauerhaft zu speichern wird es mit dem Befehl 'dism /Online /Import-DefaultAppAssociations:„C:\DefaultAppAssociations.xml“ wieder importiert.

Einrichten des Windows System Image Managers (WSIM)

Im Windows System Image Manager (WSIM) wird im nächsten Abschnitt die Antwortdatei erzeugt, mit welcher die Installation von Windows 10 nach dem Deployment auf dem Zielgerät gesteuert wird. Zunächst erstellt man den Ordner C:\customize\Win10 und kopiert sämtliche Installationsdateien vom virtuellen CD-Laufwerk dorthin:

Als nächstes muss unter C:\customize der Ordner Distribution mit folgenden Unterordnern erstellt werden:

• $OEM$
• LangPacks
• Out-of-Box Drivers
• Packages

Danach gibt man im Suchfeld Windows System Image Manager ein und startet das Programm. Danach wird über den Menupunkt Datei die Windows-Abbilddatei C:\customize\win10\sources\install.wim eingelesen. Im folgenden Dialog wird die entsprechende Windows-Datei (Windows 10 Enterprise N) ausgewählt. Wenn noch keine Katalogdatei angelegt worden ist, muss dies nun gemacht werden:

Im Distribution-Ordner wird auch das Antwortfile erstellt. Dazu wird im Windows System Image Manager im Menu Datei der Punkt Distributionsfreigabe auswählen angewählt und als Ordner C:\customize\Distribution angegeben. Danach wird mit Datei/Neue Antwortdatei… eine neue Antwortdatei angelegt:

Erzeugen der Antwortdatei für den Sysprep-Vorgang

Eine Antwortdatei enthält sieben verschiedene Stufen oder Schritte, die bei einem Windows-Setup durchlaufen werden. Für diese Stufen erstellt man ein Answer-File mit den Antworten auf Konfigurationsfragen. So müssen die Antworten nicht während des Setups von Hand eingegeben werden, sondern das Setup kann völlig automatisch ablaufen. Ein mit sysprep zurückgesetztes Image startet nach der Verteilung in der Stufe 4 specialize, danach wird die Stufe 7 oobeSystem durchlaufen. Für diese beiden Stufen werden Answer-Files angelegt.

Pass 4 specialize

Wenn während der Installation im Windows System Image Manager zusätzliche Einstellungen wie Modell, Hersteller, Computername, Eigentümername, Zeitzone und mehr konfiguriert werden soll, benötigt man die Komponente amd64_Microsoft-Shell-Setup.
1. Im Abschnitt Windows-Image den Ordner Components erweitern.
2. Die Komponente amd64_Microsoft-Shell-Setup erweitern.
3. Mit der rechten Maustaste auf die Komponente OEMInformation klicken und die Option Add Setting to Pass 4 specialize auswählen.

4. Im Abschnitt Antwortdatei auf der rechten Seite die Komponente amd64_Microsoft-Shell-Setup auswählen.
5. Unter dem Abschnitt Einstellungen auf der rechten Seite die folgenden Werte setzen:

• ComputerName: Keiner, da dieser vom FOG-Server gesetzt wird
• CopyProfile: true
• RegisteredOrganization: Stiftung Informatik für Autisten
• RegisteredOwner: Stiftung Informatik für Autisten

Pass 7 oobeSystem

Mit diesen Schritten wird die Out-of-Box-Erfahrung konfiguriert:

1. Unter Windows Image den Components-Ordner erweitern.
2. Klicken Sie mit der rechten Maustaste auf die Komponente amd64_Microsoft-Windows-International-Core und wählen Sie die Option Add Setting to Pass 7 oobeSystem.
3. Im Abschnitt Windows-Image die Komponente amd64_Microsoft-Shell-Setup erweitern.
4. Mit der rechten Maustaste auf die OOBE-Komponente klicken und die Option Add Setting to Pass 7 oobeSystem auswählen.

5. Die Komponente UserAccounts erweitern.
6. Die Komponente LocalAccounts erweitern.
7. Mit der rechten Maustaste auf die Komponente LocalAccount klicken und die Option Add Setting to Pass 7 oobeSystem auswählen.

8. Unter dem Abschnitt Antwortdatei die Komponente amd64_Microsoft-Windows-International-Core auswählen.
9. Im Abschnitt Einstellungen auf der rechten Seite die Spracheinstellungen festlegen:

• InputLocale: de-CH
• SystemLocale: de-CH
• UILanguage: de-CH
• UILanguageFallback: en-US
• UserLocale: de-CH

10. Im Abschnitt „Antwortdatei“ die Komponente amd64_Microsoft-Shell-Setup erweitern.
11. Die OOBE-Komponente auswählen.
12. Unter dem Abschnitt Einstellungen auf der rechten Seite die folgenden Werte einsetzen:

• HideEULAPage: true
• HideOEMRegistrationScreen: true
• HideOnlineAccountScreens: true
• HideWirelessSetupinOOBE: true
• ProtectYourPC: 3

In der Einstellung ProtectYourPC wird defniniert, wie die Express-Einstellungen gehandhabt werden sollen. Wenn man den Wert 1 verwendet, teilt man dem Setup mit, dass es die Express-Einstellungen mit den Standardeinstellungen aktivieren soll.

1. Die Komponente UserAccounts auswählen.
2. Mit der rechten Maustaste auf die Komponente LocalAccounts klicken und die Option Neue LocalAccount einfügen auswählen. 3. Im Abschnitt „Einstellungen“ auf der rechten Seite die folgende Konfiguration wählen, um ein primäres lokales Konto zu erstellen:

• Description: Sysadmin-Konto
• DisplayName: sysadmin
• Group: Administratoren
• Name: sysadmin

Mit den obigen Einstellungen wird ein Konto namens sysadmin für den Benutzer sysadmin erstellt und das Konto der Gruppe Administratoren hinzugefügt.

Danach wird die Komponente „LocalAccount“ erweitert. 4. Die Komponente Passwort auswählen.
5. Im Abschnitt Einstellungen auf der rechten Seite im Feld Value ein Passwort eingeben.

Man sieht das Passwort im Klartext sehen, der Wert wird aber nach dem Speichern der Datei customize.xml verschlüsselt.

Zunächst wird die Antwortdatei über das Menu Extras/Antwortdatei überprüfen validiert und allfällge überflüssige Keys gelöscht.

Dann kann die Datei über Datei/Antwortdatei speichern nach C:\customize\customize.xml abgespeichert werden.

2.7 Durchführen von Sysprep

Damit der Ordner C:\customize auf den Zielsystemen nicht stört, kann er mit dem Konsolen-Befehl (als Administrator ausführen) attrib +s +h „C:\customize“ unsichtbar gemacht werden. Mit attrib -s -h „C:\customize“ macht man den Ordner wieder sichtbar.

Da zuletzt die Datei customize.xml verwendet wurde, sieht der Benutzer, der sich nach dem Staging des Imgages anmeldet, die Datei immer noch im Abschnitt der zuletzt verwendeten Dateien im Windows Explorer.

Um dies zu verhindern, kann man ein kleines Skript implementieren, das diese Einträge entfernt. Das Skript wird nur einmal ausgeführt und löscht sich danach selbst. Dazu navigiert man im Explorer nach %appdata%\Microsoft\Windows\Start Menu\Programs\Startup und erstellt eine Datei namens runonce.bat. Man muss sicherstellen, dass die Dateierweiterung korrekt ist und nicht .txt. In die Datei wird folgender Code eingefügt:

Del /F /Q %APPDATA%\Microsoft\Windows\Recent\*
Del /F /Q %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\*
Del /F /Q %APPDATA%\Microsoft\Windows\Recent\CustomDestinations\*
REG Delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU /VA /F
REG Delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths /VA /F 
del %0

Mit diesem Code werden sämtliche Orte, an denen Windows die History speichert, zurückgesetzt.

Nun kann Sysprep ausgeführt werden. Zunächst wird ein SNAPSHOT der VM angelegt, damit man immer an diesen Ort zurückkehren kann, sollte Sysprep nicht funktionieren.

Man öffnet CMD als Administrator und wechselt ins Sysprep-Verzeichnis:

cd C:\Windows\System32\Sysprep

Um Interferenzen mit dem Sysprep-Befehl zu vermeiden, stoppt man vorsichtshalber den Windows Media Networking Service:

net stop wmpnetworksvc

Jetzt beginnt man mit Sysprep. Nach Eingabe des Befehls, wird Sysprep das Image vorbereiten. Währenddessen sollten auf dem Computer keine Aktionen ausgeführt werden.

sysprep.exe /generalize /oobe /shutdown /unattend:C:\customize\customize.xml

Sollte Sysprep fehlschschlagen, sollte folgender Befehl in der Powershell ausgeführt werden:³¹⁾

Remove-AppxPackage -Package Microsoft.WindowsStore_11602.1.26.0_x86__8wekyb3d8bbwe

Nachdem Sysprep erfolgreich durchgeführt worden ist, fährt das System automatisch herunter. Es ist sehr wichtig, dass danach die VM nicht versehentlich gestartet wird, da dadurch das Setup ausgeführt und der ganze Prozess rückgängig gemacht würde. Das generalisierte Image muss jetzt auf die FOG-Plattform importiert werden³²⁾