====== Zentrales PC-Deployment auf Basis eines Linux-Deployment-Servers - IPA Lea =====
====== Glossar ======
^ Begriff ^ Erklärung ^
| KVM | |
| Linux Container | |
| Debian Linux | |
| Proxmox VE | |
| Datendeduplikation | |
| LVM | |
| rsync | |
| TFTP | |
| PXE | |
| Kernel | |
| Unicasting / Multicasting | |
| WDS/MDT | |
| Datenblock | |
| Capturing | |
| Deploying | |
| L3-Diagramm | |
| Testmittel | |
| Testmethoden | |
| Testfall | |
| Capture/Deploy | |
| VLAN | |
| Sysprep | |
| Windows Setup-Konfigurationsphasen | |
| Answer File | |
====== Informieren ======
===== Erfassung der benötigten Hardware =====
==== Hardware Server und PCs ====
Zur Erfassung der Hardware wurde die Linux-Distribution GRML((https://grml.org/)) 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''((https://www.thomas-krenn.com/de/wiki/Hardwareinfos_mit_dmidecode_auslesen)) 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.
^ Gerät ^ Modellbezeichnung ^ CPU ^ Memory ^ HD ^ NW-Adapter ^
| Server-PC | | | | |
| Staging-PC 01 | | | | |
| Staging-PC 02 | | | | |
| Arbeitsplatzrechner | | | | |
==== Hardware Switch ====
^ Gerät ^ Modellbezeichnung ^ Übertragungsrate ^ Anzahl Ports ^
| Switch | | | |
===== Erfassung der benötigten Services =====
==== Die Virtualisierungsplattform Proxmox VE ====
Proxmox VE ist eine Open Source-Virutalisierungsplattform für Server((https://www.proxmox.com/de/proxmox-ve)). 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''.
{{:team:egil-rueefli:proxmox-ve-6-3-cluster-summary.png?800|}}
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((https://backuppc.github.io/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
{{:team:egil-rueefli:backuppcserversummary.png?800|}}
Im Rahmen von Vorarbeiten wurde beim Team SRB (ServiceRestoreBackup) ein Zugang zum firmeninternen Backupserver beantragt. Der ''SLA #001: Backup und Restore'' v.01((https://wiki.rafisa.net/doku.php?id=sla:sla-backup-and-restore)) 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((https://wiki.fogproject.org/wiki/index.php?title=Introduction#What_is_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((https://wiki.fogproject.org/wiki/index.php?title=Introduction#What_is_FOG)):
* 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((https://wiki.rafisa.net/doku.php?id=intern:ipa:lt2019:ipa_lt2019)) 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((https://community.spiceworks.com/topic/2231703-wds-2012r2-vs-fog-project-deployment-speed)). 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.
^ Vergleichsgrösse ^ WDS/MDT ^ FOG ^
| Übertragene Daten | Files | Datenblöcke |
| Geschwindigkeit | gering, da Betriebssystem auf Zielhost aufgebaut wird | hoch |
| Kontrollmöglichkeiten | auch nach dem Imagingprozess hoch | gering (Nachinstallieren von Software durch Snapins) |
| Unterstützte Client OS's | Windows | Windows, Linux, Mac |
===== 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((https://books.google.ch/books?id=NpJnvwL4G2MC&lpg=PA17&ots=3DJnD964Tp&dq=Comptia%20network%2B&lr&hl=de&pg=PP1#v=onepage&q=Comptia%20network+&f=false)) 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 ===
^ VLAN Name ^ Kürzel ^ Funktion ^ VID ^ IP-Adresse ^ FW-Interface-Name ^ DHCP-Server ^
| ::: |||||||
^ VLAN Management ^ ^ ^ 01 ^ ^ ^ ^
| VLAN01 | MGMT | Management | 01 | 172.16.1.0/24 | VLAN01_MGMT | ❌|
^ VLAN Server ^ ^ ^ 10-19 ^ ^ ^ ^
| VLAN10 | SRVAUTH | Server Authentifizierung | 10 | 172.16.10.0/24 | VLAN10_SRVAUTH | ❌|
| VLAN14 | SRVEMPL | Server Ausbildner | 14 | 172.16.14.0/24 | VLAN14_SRVEMPL |❌|
| VLAN15 | SRVLEARN | Server Lernende | 15 | 172.16.15.0/24 | VLAN15_SRVLEARN |❌|
^ VLAN Clients ^ ^ ^ 20-29 ^ ^ ^ ^
| VLAN21 | CLEMPL | Clients Ausbildner | 21 | 172.16.21.0/24 | VLAN21_CLEMPL |✔️|
| VLAN22 | CLLEARN | Clients Lernende | 22 | 172.16.22.0/24 | VLAN22_CLLEARN |✔️|
| VLAN23 | CLGUEST | Clients Guest (WLAN) | 23 | 172.16.23.0/24 | VLAN23_CLGUEST |✔️|
^ VLAN Drucker ^ ^ ^ 40 ^ ^ ^ ^
| VLAN40 | LP | Drucker | 40 | 172.16.40.0/24 | VLAN40_LP |❌|
^ VLAN Labor ^ ^ ^ 50-59 ^ ^ ^ ^
| VLAN51 | LAB01 | Labor 01 | 51 | 172.16.51.0/24 | VLAN51_LAB01 |✔️|
| VLAN52 | LAB02 | Labor 02 | 52 | 172.16.52.0/24 | VLAN52_LAB02 |✔️|
| VLAN53 | LAB03 | Labor 03 | 53 | 172.16.53.0/24 | VLAN53_LAB03 |✔️|
| VLAN54 | LAB04 | Labor 04 | 54 | 172.16.54.0/24 | VLAN54_LAB04 |✔️|
| VLAN55 | LAB05 | Labor 05 | 55 | 172.16.55.0/24 | VLAN55_LAB05 |✔️|
=== Berechtigungsmatrix ===
Die Matrix wird Zeile nach Spalte gelesen (Zugriff von Zeile nach Spalte erlaubt/nicht erlaubt)
^VLAN^ 01^10^14^15^21^22^23^40^ 51^52^53^54^55^WAN^DHCP^
| 01 |✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|❌|
| 10 |❌|✔️|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|
| 14 |❌|❌|✔️|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|
| 15 |❌|❌|❌|✔️|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|
| 21 |❌|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|✔️|
| 22 |❌|✔️|❌|❌|❌|✔️|❌|✔️|❌|❌|❌|❌|❌|✔️|✔️|
| 23 |❌|❌|❌|❌|❌|❌|✔️|❌|❌|❌|❌|❌|❌|✔️|✔️|
| 40 |❌|❌|❌|❌|❌|❌|❌|✔️|❌|❌|❌|❌|❌|✔️|❌|
| 51 |❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|❌|❌|❌|✔️|✔️|
| 52 |❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|❌|❌|✔️|✔️|
| 53 |❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|❌|✔️|✔️|
| 54 |❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|✔️|✔️|
| 55 |❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|✔️|✔️|
|WAN |❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|❌|✔️|❌|
==== 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.
----
{{drawio>team:sabareeshan-nadeswaran:rafisa_zh_l3netzplan}}
----
^ FQDN ^ IP-Adresse ^ OS ^ Services ^ Service-Team ^ Owner ^
^ Server ^^^^^^
| prox-zh-ruga-01.zh.rafisa.org | 172.16.1.21/24 | Proxmox VE | Virtualisierungsplattforn | Team Server Services | RS |
| prox-zh-ruga-02.zh.rafisa.org | 172.16.1.22/24 | Proxmox VE | Virtualisierungsplattform | Team Server Services | RS |
| dc-zh-ruga-02.zh.rafisa.org | 172.16.10.22/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS |
| dc-zh-ruga-04.zh.rafisa.org | 172.16.10.24/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS |
| fs-zh-ruga-01.zh.rafisa.org | 172.16.14.21/24 | Windows Server 2019 | Fileserver Employees | Team Server Services | RS |
| fs-zh-ruga-01.zh.rafisa.org | 172.16.15.21/24 | Windows Server 2019 | Fileserver Learners | Team Server Services | RS |
| bkp-zh-r02b-01.zh.rafisa.org | 172.16.1.100/24 | Windows Server 2019 | Fileserver Learners | Team Server Services | RS |
| uni-zh-ruga-01.zh.rafisa.org | 172.16.1.30/24 | Ubuntu 20.04 LTS | Ubiquiti WLAN Controller | Team Network Services | ER |
| ap-zh-01-05.zh.rafisa.org | 172.16.1.31-35/24 | AirOS | AP, WPA-Enterprise Radius Auth | Team Network Services | ER |
^ Firewall ^^^^^^
| fw-zh-ruga-01.zh.rafisa.org | VLAN 172.16.1.1/24\\ WAN 46.140.45.118 | pfSense (BSD) | VLAN-Routing, Filtering, VPN Concentrator, DHCP | Team Network Services | ER |
===== Beschreibung der Firmenstandards für das Rafisa Standard-Image =====
Die Firmenstandards für das Standardimage können dem Rafisa Wiki((https://wiki.rafisa.net/doku.php?id=intern:clients:windows10-client-sysbi-dietikon)) entnommen werden:
==== Partitionierung ====
Nur eine Datenpartition C: mit maximaler Grösse für Windows und Programme.
==== Software ====
^ Software ^ Standardimage ^ Notebook-Image ^ Default ^
| Windows 10 Enterprise N v20H2 | ✔️ | ✔️ | |
| Microsoft Office Professional Plus 2019(([[de:technische-dokumentationen:tutorials:installation_von_office_2019_pro_plus_mit_hilfe_des_office-deploymenttools|Installation von Office 2019 pro]])) | ✔️ | ✔️| docx, xslx, potx, mailto |
| Visio 2019 Professional(([[de:technische-dokumentationen:tutorials:installation_von_office_2019_pro_plus_mit_hilfe_des_office-deploymenttools|Installation von Office 2019 pro]])) | ✔️ |✔️ | |
| LibreOffice-Suite | ✔️ | ✔️| |
| Notepad++ |✔️ |✔️ | |
| Acrobat Reader | ✔️ | ✔️|pdf |
| 7-zip | ✔️ | ✔️| |
| Firefox | ✔️ | ✔️| |
| Chrome | ✔️ |✔️ | |
| Brave | ✔️ |✔️ | html |
| Putty | ✔️ | ✔️| |
| Filezilla |✔️ | ✔️| |
| FOG-Client | ✔️ | ✔️ | |
| WinSCP |✔️ | ✔️ | |
| Win32 Disk Imager | ✔️| ✔️| |
| Rufus | ✔️| ✔️| |
| Teams |✔️|✔️ | |
| VirtualBox |✔️ |✔️ | |
| Git-Client((https://git-scm.com/downloads)) |✔️ |✔️ | |
| draw.io((https://www.diagrams.net/)) |✔️ |✔️ | |
| VLC Media Player((https://www.videolan.org)) | ✔️| ✔️| video + audio |
|OneDrive (Business deinstallieren, 365 installieren) |✔️ | ✔️| |
|OpenVPN Client((https://openvpn.net/community-downloads/)) | ❌ | ✔️| |
==== Anpassungen ====
=== Applikationen ===
^ Applikation ^ Anpassung ^
| Teams | Kein Autostart |
| Explorer | Dateinamenerweiterungen einblenden: Im Menu ''Ansicht'' des Explorers ''Dateinamenerweiterungen'' markieren |
| Remote Desktop | Remotedesktopverbindung zulassen\\ {{:intern:clients:rdp.png?400|}} |
| Windows Taskbar | Als Icons: Windows Explorer, Brave, Word, Excel, Powerpoint, Outlook |
| Windows Startmenu | Als Kacheln eingeblendet: Word, Excel, Powerpoint, Outlook, Teams, Visio, Brave, draw.io, Windows Explorer\\ {{:intern:clients:screenshot_20210404_142719.png?200|}}|
=== Wallpaper ===
Hier findet sich das Standard-Hintergrundbild: {{technische-dokumentationen:installationsanleitungen:371580.jpg|Butterfly Wallpaper}}
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 ===
^ Kürzel ^ Funktion ^
| bkp | Backup Server |
| dc | Domain Controller |
| ds | Deployment Server |
| fw | Firewall |
| nb | Notebook |
| pc | PC |
| prox | Proxmox VE Server |
| sw | Switch |
==== 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 ^ Standortbezeichnung ^
| be | Bern |
| fr | Fribourg |
| zg | Zug |
| zh | Zürich |
=== Kürzel für die internen Räume ===
^ Dietikon ^^
^ Kürzel ^ Ort ^
| 200 | Raum 200 im 2. Stock |
| 201 | Raum 101 im 2. Stock |
=== Kürzel für Racks ===
^ Dietikon ^^
^ Kürzel ^ Racknummer ^
| ruga | Rack A im Untergeschoss |
| rugb | Rack B im Untergeschoss |
| r02a | Rack A im 2. Stock |
| r02b | Rack B im 2. Stock |
| r03a | Rack A im 3. Stock |
| r03b | Rack B im 3. Stock |
| r03c | Rack C im 3. Stock |
| r03d | Rack D im 3. Stock |
| r04a | Rack A im 4. Stock |
====== 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:
^ System ^ DHCP ^ DNS ^ TFTP ^ AD ^
| Windows 2019 Server | möglich (Serverrolle DHCP-Server) | möglich (Serverrolle DNS-Server) | möglich (Serverrolle Windows-Bereitstellungsdienste) | möglich (Serverrolle Active-Directory-Domänendienste)|
| Ubuntu Server | möglich (Paket isc-dhcp-server) | möglich (Paket bind9) | möglich (Paket tftpd-hpa) | möglich (Paket samba) |
| pfSense Firewall | möglich | nicht möglich (nur DNS-Forwarder) | nicht möglich | nicht möglich |
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((https://www.thomas-krenn.com/de/wiki/Windows_Server_2019_Editionsunterschiede)) findet man einen sehr nützlichen Vergleich der Windows Editionen.
^ Edition ^ Ideal für ... ^ Virtualisierungsrechte ^ Lizenzierungsmodell ^ Zugriffslizenzen ^ RAM Limit ^ CPU Limit ^
| Essentials | Kleine Unternehmen mit Basisanforderungen an die IT; sehr kleine oder keine eigene IT Abteilung | Installation 1x physikalisch oder 1x virtuell | CPU-basiert | keine CALs erforderlich (Limitierung auf 25 User / 50 Geräte) | 64 GB RAM | max. 2 CPUs |
| Standard | Für alle Unternehmen, die erweiterte Features benötigen und im geringeren Umfang virtualisieren | 2 virtuelle Maschinen oder 2 Hyper-V Container | Core-basiert | CALs erforderlich **** | 24 TB RAM | unlimitierte Kerne |
| Datacenter | Für alle Unternehmen mit hohen Anforderungen an die IT Workloads mit großer Anzahl von virtuellen Systemen | Unlimitiert viele virtuelle Maschinen und Hyper-V Container | Core-basiert | CALs erforderlich | 24 TB RAM | unlimitierte Kerne |
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:
- Desktop-Version vs. Server-Version
- 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((https://de.wikipedia.org/wiki/Ubuntu)):
{{:team:egil-rueefli:ubuntu-versionen-01.png?600|}}
== 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.((https://www.howtogeek.com/162768/should-you-use-ubuntu-lts-or-upgrade-to-the-latest-release/#:~:text=If%20you%20stick%20with%20the,not%20be%20completely%20finished%20yet.))
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((https://prox-hell-01.rafisa.net:8006/pve-docs/chapter-qm.html#qm_system_settings)) sowie zur Partitionierung getroffen werden. Bei den Ressourcen gibt es immer mehrere Möglichkeiten, die virtuellen Geräte zu emulieren:
^ Ressource ^ Varianten ^
| Harddisk Bus/Device | IDE, SATA, VirtIO, SCSI |
| Disk-Format | Raw Disk Image, QEMU Image Format, VMWare Image Format |
| Grösse der Harddisk | frei (max. ist Storage-Grösse)|
| CPU Sockets | frei |
| CPU Cores | frei |
| Grösse Memory | frei |
| Netzwerkadapter | Intel E1000, VirtIO, Realtek RTL8139, VMware |
== Harddisk Bus / Device ==
QEMU kann verschiedene Speicher-Controller emulieren:
^ Harddisk Bus/Device ^ Vorteile ^ Nachteile ^
| IDE | Sehr gute Unterstützung durch alle Betriebssysteme | nicht sehr performant, nur 4 Devices |
| SATA | Gute Unterstützung durch Betriebssysteme | performant, nur 6 Devices |
| VirtIO | Bis zu 14 Devices | Benötigt unter Windows spezielle Guest-Treiber, abgelöst durch SCSI |
| SCSI | Sehr performant, bis 14 Devices | Benötigt unter Windows spezielle Guest-Treiber |
== 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((https://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echte-cpus/)). 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:
{{:team:egil-rueefli:ad_stiftung.ifa.png?600|}}
==== 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((https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/how-configuration-passes-work)).
^ Situation nach Verteilung ^ Fat-Image ^ Masterimage mit Sysprep ^
| Treiber | fertig intalliert | Treiberdatenbank zurückgesetzt, wird während Setup der HW angepasst |
| Konfiguration | fertig konfiguriert | Es werden noch Setup-Phasen durchlaufen |
| SID | identisch mit dem Quell-Image | wird neu erzeugt |
| Geschwindigkeit | sehr rasch benutzbar, da schon fertig | Setup muss zunächst durchlaufen werden |
| Mögliche Probleme | Bluescreens wegen fixen Treibern | Interaktion nötig, da Setup durchlaufen wird |
=== 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.
^ Feature ^ Für Auftrag nötig ^ Kommentar ^
| PXE-Boot-Umgebung | ja | wird benötigt, um die Clients über das Netzwerk booten zu können |
| Imaging von Windows, Linux und Mac OS X | ja | Wird für Windows-Image benötigt |
| Partitionen, volle Festplatte, mehrere Festplatten | ja/nein | Es wird nur das Imaging von vollen Festplatten benötigt, keine Partitionsimages |
| Snapins | ja | Wird zur nachträglichen Installation von OpenVPN benötigt |
| Drucker-Verwaltung | nein | Möglichkeit, Printerdefinitionen mit Hosts zu verbinden und automatisch Printer installieren zu lassen |
| Hostname ändern und Domäne beitreten | ja | wird für den automatischen Domänenbeitritt benötigt |
| Monitoring von Benutzerzugriffen | nein | |
| Virenschutz | nein | verlangsamt das Erstellen von Images |
| Löschen von Festplatten | nein | eigene Tools |
| Gelöschte Dateien wiederherstellen | nein | eigene Tools |
| Suche nach fehlerhaften Blöcken | nein | eigene Tools |
=== 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:
- Zugang zum Web-Administrationsinterface
- Das FOG-Boot-Image, das über PXE geladen wird, kann das Image von FOG-Server verschlüsselt oder unverschlüsselt erhalten
- 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((https://pve.proxmox.com/pve-docs/vzdump.1.html)) ein Image-Backup der VMs durch.
^ ^ File-Backup ^ Image-Backup ^
| Technologie | rsync | vzdump |
| Backup-OS | nur Linux | Linux und Windows |
| Platzbedarf auf Backupserver | gering, da Kompression möglich | hoch, da Kompressionseffekt gering bei Imagefile |
| Full Metal Restore | möglich aber kompliziert | möglich, Image muss nur auf Proxmox wiederhergestellt und dann importiert werden |
| Datenmenge für Backup | entspricht Serverdaten | entspricht etwa Serverdaten |
| Datenmenge auf Backup-Server | bis 80% Kompression | entspricht etwa Serverdaten |
| Transferraten | bis 35MB/s (Erfahrungswert Team Backup und Restore) | bis ca. 10MB/s (Erfahrungswert Team Backup und Restore) |
=== Rahmenbedingungen ===
^ Rahmenbedingungen Backup ^ File-Backup ^ Image-Backup |
| Datenmenge | Ist abhängig von der Datenmenge der VM's ||
| Transferzeiten | 35MB/s -> 280Mbit/sec -> Pro Gigabyte ca. 30sec((https://www.download-time.com/)) | 10MB/sec -> 80Mbit/sec -> Pro Gigabyte ca. 2min((https://www.download-time.com/)) |
| Aufbewahrungsfrist | min. bis Ende IPA/ max. 90 Tage (s. SLA Rafisa-Backup) ||
| Sicherungsperiodizitäten | manuell bei Ânderungen oder automatisch zwischen 19:30 und 07:00 (s. SLA Rafisa-Backup) ||
| Applikatorische Vorgaben | BackupPC mit Pre- und Post-Backupscripts ||
====== 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 ===
^ Rahmenbedingungen Image-Backup ^ Hosts ^ IPA ^ Vorschlag Produktive Umgebung ^
| Sicherungsperiodizitäten | dc-zh-202-01 | automatisch jede Nacht zwischen 19:30 und 07:00, inkrementelles Backup | nicht in Produktion übernommen |
| | ds-zh-202-01 | automatisch jede Nacht zwischen 19:30 und 07:00, inkrementelles Backup | manuell bei Ânderungen, 90 Tage max. |
| Datenmenge | dc-zh-202-01 | ca. 30GB x 7 = 210GB | nicht in Produktion übernommen |
| | ds-zh-202-01 | ca. 40GB (Server + Image) x 7 = 280GB | muss abgeklärt werden, hängt von Anzahl Images ab |
| Transferzeiten | dc-zh-202-01 | 30GB, 2min pro GB -> ca. 60min | nicht in Produktion übernommen |
| | ds-zh-202-01 | 40GB, 2min pro GB -> ca. 80min | muss abgeklärt werden, hängt von Anzahl Images ab |
| Aufbewahrungsfrist | dc-zh-202-01 | bis Ende IPA | nicht in Produktion übernommen |
| | ds-zh-202-01 | bis Ende IPA | max. 90 Tage |
| Applikatorische Vorgaben | BackupPC mit Pre- und Post-Backupscripts |BackupPC mit Pre- und Post-Backupscripts |
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:\\
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_21_07_2020_16_49_54.png?600|}}
Um in den Audit-Mode((https://www.thewindowsclub.com/what-is-audit-mode-in-windows-10)) 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.
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_21_07_2020_17_24_42.png?600|}}
==== Installation von Windows-ADK ====
Um das System konfigurieren und die ensprechenden Answer-Files((https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/answer-files-overview#:~:text=An%20answer%20file%20is%20an,which%20product%20key%20to%20apply.)) anlegen zu können, benötigt man die Windows-Bereitstellungstools aus dem Windows Assessment and Deployment Kit (ADK)((https://en.wikipedia.org/wiki/Windows_Assessment_and_Deployment_Kit)). Es wird die Version ''ADK für Windows 10, Version 2004'' heruntergeladen((''ADK für Windows 10, Version 2004'')). Während der Installation werden im Feature-Dialog ausschliesslich die Bereitstellungstools ausgewählt:
{{:technische-dokumentationen:installationsanleitungen:bildschirmfoto_vom_2020-07-21_18-00-20.png?600|}}
==== 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:
{{:team:egil-rueefli:layout.png?600|}}
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:
{{:technische-dokumentationen:installationsanleitungen:create-windows-10-image-for-deployment-with-fog-server-0003.png?600|}}
Als nächstes muss unter ''C:\customize'' der Ordner ''Distribution'' mit folgenden Unterordnern erstellt werden:
* $OEM$
* LangPacks
* Out-of-Box Drivers
* Packages
{{:technische-dokumentationen:installationsanleitungen:bildschirmfoto_vom_2020-07-23_16-31-17.png?600|}}
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:
{{:technische-dokumentationen:installationsanleitungen:bildschirmfoto_vom_2020-07-22_17-26-20.png?600|}}
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:
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_16_40_25.png?600|}}
==== 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.
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_22_46_08.png?600|}}
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
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_image_25_07_2020_17_59_36.png?600|}}
=== 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.\\
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_23_01_28.png?600|}}
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.\\
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_23_04_53.png?600|}}
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
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_23_09_29.png?600|}}
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
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_23_14_37.png?600|}}
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
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_23_07_2020_23_21_51.png?600|}}
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.
{{:technische-dokumentationen:installationsanleitungen:virtualbox_windows10_ent_n_1909_image_25_07_2020_18_12_02_01.jpg?600|}}
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.
{{:technische-dokumentationen:installationsanleitungen:2018-01-24-13_45_32.png?600|}}
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
{{:technische-dokumentationen:installationsanleitungen:2017-09-08-12_51_29.png?400|}}
Sollte Sysprep fehlschschlagen, sollte folgender Befehl in der Powershell ausgeführt werden:((https://www.windowspro.de/script/windows-store-app-loeschen-wiederherstellen-powershell))\\
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(([[de:technische-dokumentationen:tutorials:capturing-image-with-fog-server|Capturing eines Windows-Images mit dem FOG-Server]]))