| **Aufbau einer Windows-Deployment-Umgebung** | |{{ :intern:ipa:lt2019:ipa-tag10_html_6fb12a307da75cb1.png?800 |}}| | **IPA 2019** | | 12.4.2019 - 29.4.2019 | | Kandidat: Leon Tschudi | ======= Teil 1 - Umfeld und Ablauf ======= ====== 1 Projektorganisation und Aufgabenstellung ====== ===== 1.1 Personen und Adressen ===== | **Kandidat\\ **Leon Tschudi || **Betrieb (=Durchführungsort)\\ **Rafisa Informatik GmbH\\ Bernstrasse 88, PLZ 8953\\ Nat. 079 828 48 46\\ M __[[l.tschudi@rafisa.ch|l.tschudi@rafisa.ch]]__ | | **Verantwortliche Fachkraft**\\ Egil Rüefli\\ Rafisa Informatik GmbH\\ Bernstrasse 88, PLZ 8953\\ T 078 767 84 04\\ G 044 533 36 507\\ M __e.rueefli@rafisa.ch__ ||**BerufsbildernIn/Lehrfirma**\\ Ruedi Wegelin\\ Rafisa Informatik GmbH\\ Bernstrasse 88, PLZ 8953\\ T 076 555 05 55\\ G 044 533 36 54\\ M __[[r.wegelin@rafisa.ch|r.wegelin@rafisa.ch]]__ | | **Hauptexperte\\ **Bruno Bertelli\\ T 079 357 28 24\\ M __[[bruno.bertelli@abraxas.ch|bruno.bertelli@abraxas.ch]]__ || **Nebenexperte\\ **Thomas Koch\\ T 079 304 07 78\\ M __[[kochthomas2002@gmx.ch|kochthomas2002@gmx.ch]]__ | ===== 1.2 Aufgabenstellung ===== Aufbau einer Windows-Deployment-Umgebung ==== 1.2.1 Ausgangslage ==== In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik zu InformatikerInnen EFZ ausgebildet. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatik-Ausbildung sowie Bewerbungs- und Job-Coachings an. Im Zuge dieser Tätigkeiten müssen immer wieder frische PC-Arbeitsplätze eingerichtet werden. Einmal im Jahr - in den Sommerferien - werden alle Lernenden-PC's neu aufgesetzt. Als Basis für die Neuinstallation dient ein Standard-Image, welches mittels Clonezilla einzeln und von Hand aufgespielt wird. Um die Effizienz dieses Prozesses zu erhöhen, wurde beschlossen, eine automatisierte Deploymentlösung zu evaluieren. ==== 1.2.2 Detaillierte Aufgabenstellung ==== Auf der Basis des Windows Deplyoment Services (WDS) soll eine Lösung für das Deployment der Windows-Standard-Images aufgebaut und evaluiert werden. Die Implementatierung der Lösung erfolgt nach der IPA. Die gesamte Serverlandschaft der Rafisa basiert auf der Virtualisierungslösung Proxmox VE. Für die Deployment-Server muss deshalb eine Proxmox-Umgebung aufgebaut werden. Folgende Unteraufgaben sind zu lösen: **Zur Verfügung stehende Mittel:\\ **1x Dell-Server (PowerEdge R410), 1x Office Switch unmanaged\\ 1x Firewall (vorkonfiguriert), 2x Arbeitsplatzrechner für den Staging-Test\\ 1x Windows Notebook für Tests (vorkonfiguriert), 1x externe Festplatte für Image-Backups **1. Erfassung des IST-Zustandes\\ **- Dell-Server: Bezeichnung, CPUs, Memory, Disks, Raid-Controller, Netzwerk-Interfaces\\ - HW der Arbeitsplatzrechner für Staging: Bezeichnung, CPUs, Memory, Disks, Netzwerk Interfaces\\ - Netzplan des Lernenden-Netzwerkes (Server, Switches, Drucker, keine PCs) (I1) **2. Erfassung des SOLL-Zustandes:\\ **- Netzplan der Testumgebung\\ - Einbettung der Deploymentlösung im Netzplan des Lernenden-Netzwerkes (s. Aufgabe 1)\\ - Beschreibung der Vorgaben für das Standard-Image für das Deployment der Lernenden-PCs (Software, Partitionierung) **3. Evaluation des Proxmox-Storage\\ **- Für die Proxmox-VMs bieten sich verschiedene Storage-Typen an, evaluieren Sie die geeignete\\ - Vergleichen Sie mindestens qcow2, raw, vmdk, Thin LVM, LVM, ZFS\\ - Vergleichen Sie mindestens bezüglich folgender Kriterien: Performance, Thin Provisioning, Portability, Snapshots, Block-Storage, File-Storage, Stabilität, Komplexität\\ - KO-Kriterien sind: Snapshot, Thin Provisioning, Stable, keine Interferenzen mit HW-Raid\\ - die Performance-Tests können vor der IPA durchgeführt werden, sollen aber dokumentiert sein **4. Prozessbeschrieb der Deploymentlösung\\ **- Alle Elemente der Deploymentlösung sind identifiziert und beschrieben\\ - Das Zusammenspiel der einzelnen Elemente ist vollständig verstanden **5. Aufbau der Proxmox-Basis\\ **- Firewall (Adressierung vorgegeben und dokumentiert)\\ - Office-Switch unmanaged\\ - Proxmox-Server: OS: aktuelle Proxmox VE-Distribution, IP-Adresse für Verwaltung fix ; Hostname: srv-zh-pxmx-01; FQDN: srv-zh-pxmx-01.rafisa.intern; Raid-Level selbst gewählt, begründet; Partitionierung: Schema selbst gewählt, begründet; Proxmox-Storage: selbst gewählt, begründet, Netzwerk-Konfiguration für alle VMs vorbereitet (I5)\\ - 2 Arbeitsplatzrechner für Staging-Tests **6. Einrichten der virtuellen Server und der Deployment-Lösung\\ **1. AD-Server (I2)\\ - OS: Windows Server 2016, Domain: rafisa.intern, Hostname: srv-zh-ad-01, Adressierung fix, DNS-Server: alle Server eingetragen, DHCP-Server: Gateway, DNS-Server und PXE-Server verteilt, Adresspool selbst gewählt, Konto für Deployment-User eingerichtet\\ 2. Deployment-Server:\\ -Windows Server 2016, Domain: rafisa.intern, Hostname: srv-zh-ds-01, Adressierung fix, Deploymentumgebung dokumentiert (Shares, Tools)\\ 3. Anforderungen an Deploymentlösung (I6):\\ - Es wird ein Windows 10 Enterprise Standard-Image erstellt (Software: gemäss Standardvorgaben Rafisa, dokumentiert, Partitionierung selbst gewählt)\\ - Die PCs müssen via PXE Boot aufgesetzt werden können\\ - Das Aufsetzen muss vollständig automatisiert ablaufen (Benutzereingaben sind begründet)\\ - Das Standard-Image existiert als Offline-Media für die manuelle Installation (auf Boot-Stick)\\ - Für das Deployment wird Multicasting genutzt\\ - Die 2 aufgesetzten PCs sind in der Domäne, alle Programme sind aufgesetzt **7. Backuplösung (I7)\\ **Die VM des Deployment-Servers soll vor und nach jeder Änderung des Images auf eine externe Festplatte gespeichert werden. Dafür ist ein Automounting der externen USB\\ Festplatte auf dem Linux-Proxmox-Server einzurichten. Das Restore der VM soll getestet werden. **Dokumentationen\\ **- Dokumentationen zur Erfassung des IST- sowie des SOLL-Zustandes (1/2)**\\ **- Evaluation Proxmox-Storage (3)**\\ **- Prozessbeschrieb der Deployment-Lösung (4)**\\ **- Deploymentumgebung (Shares, Tools)**\\ **- User-Anleitung für das Aufsetzen der PCs (Deployment) (6)**\\ **- Beschreibung des Standard-Images (Software, Partitionierung, Login-Users) (6) **Tests (mindestens)\\ **- DHCP-Server funktioniert**\\ **- DNS-Server funktioniert**\\ **- PXE-Boot funktioniert**\\ **- Multicasting funktioniert**\\ **- Aufgesetzte PCs sind in der Domain, Login als admin funktioniert**\\ **- Installation per Offline-Media funktioniert**\\ **- Backup funktioniert, Restores funktionieren **Mittel und Methoden\\ **1x Dell-Server (PowerEdge R410)**\\ **1x Office Switch unmanaged**\\ **1x Firewall (vorkonfiguriert)**\\ **2x Arbeitsplatzrechner für den Staging-Test**\\ **1x Windows Notebook für Tests (vorkonfiguriert)**\\ **1x externe Festplatte für Image-Backups\\ Linux, Windows, AD **Neue Lerninhalte\\ **Proxmox Storage Formate, Proxmox Backup / Restore, MDT Konfiguration **Arbeiten in den letzten 6 Monaten\\ **Test-IPA: Migration von Windows Servern und einem Apache Webserver**\\ **Proxmox Linux**\\ **Windows 2016 Server**\\ **Windows 10 Enterprise**\\ **Linux Debian ===== 1.3 Mittel und Methoden ===== 1x Dell-Server (PowerEdge R410)\\ 1x Office Switch unmanaged\\ 1x Firewall (vorkonfiguriert)\\ 2x Arbeitsplatzrechner für den Staging-Test\\ 1x Windows Notebook für Tests (vorkonfiguriert)\\ 1x externe Festplatte für Image-Backups\\ Linux, Windows, AD ===== 1.4 Durchführungsblock ===== | **IPA-Block:** | 12.04.2019 -- 29.04.2019 | | **PA-Durchführung:** | 12.04.2019 -- 29.04.2019 | | **Einreichung bis:** | \\ | \\ \\ ===== 1.5 Vorkenntnisse ===== * Windows Server 2016 * Windows 10 Enterprise * Linux Proxmox Server ===== 1.6 Vorarbeiten ===== Performance Tests Proxmox Storage zusammen mit dem Kandidat Lukas Bischoff. \\ \\ ====== 2 Projektaufbauorganisation ====== Die Prüfungsexperten bilden zusammen mit dem Fachverantwortlichen der Ausbildung und dem Kunden den Auftraggeber. Zusammen sind sie für die Formulierung der Aufgabenstellung und Benotung der Projektarbeit zuständig. ==== 2.1.1 Personen ==== Ausbildner: Egil Rüefli\\ Lernender: Leon Tschudi ==== 2.1.2 Rollen ==== Projektleiter: Leon Tschudi\\ Auftraggeber, Kunde: Egil Rüefli ==== 2.1.3 Aufgaben ==== Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig\\ Der Auftraggeber ist für die Formulierung des Auftrages zuständig. ==== 2.1.4 Verantwortung ==== Die Realisierung der IPA liegt allein in der Verantwortung des Lernenden. ==== 2.1.5 Projektorganigramm ==== {{IPA-Tag10_html_91be8d8edc8c59c.png?605x273 }}\\ \\ \\ ====== 3 Vorgehen ====== ===== 3.1 Projektmethode IPERKA ===== IPERKA ist eine Projektmethode und steht für: **I**nformieren: Sich über etwas eine Übersicht verschaffen. Informationen aus dem Internet suchen. Quellenangaben nicht vergessen. Bilder sollten ebenfalls mit einer Quelle verzeichnet sein. Informationen gut veranschaulichen und wenn nötig gleich erklären. Tatsachen und Umstände definieren und sich Gedanken über eine Umsetzung machen. **P**lanen: Mit den recherchierten Informationen ein notwendiges Konzept für ein Thema (Dienst, Teilauftrag) planen. Die Planung sollte immer einen günstigen Fall bevorzugen und falls möglich mehrere Alternativen zu einer bereits geplanten bzw. gegebenen Umsetzung bieten. **E**ntscheiden: Aufgrund der Planung und deren Möglichkeiten wird hier entschieden, wie die Umsetzung erfolgen sollte. Dabei ist auf eine Präferenzmatrix zu verweisen, welche es dem Betrachter erlaubt, Entscheidungen gut nachzuvollziehen. Die Umsetzung sollte einen günstigen Fall bevorzugen. **R**ealisieren: In diesem Schritt werden getroffene Entscheidungen umgesetzt. Bei der Realisierung sollten getroffene Entscheidungen bzw. mögliche Vorgehensweisen (Planung) beachtet werden und Umgesetztes sollte dokumentiert werden in einer gut verständlichen, korrekten Fachsprache. **K**ontrollieren: Die umgesetzte Arbeit wird kontrolliert. Mögliche Konfigurationen bzw. Einstellungen, welche nicht dem günstigsten Fall entsprechen, sollten diesem angepasst werden. (Testing) **A**uswerten: Hier wird schliesslich dokumentiert, was alles kontrolliert und angepasst wurde. Es wird sozusagen praktisch untermauert, dass (möglichst) alle Konfigurationen dem Idealfall entsprechen und entsprechend dokumentiert sind. Bei der Auswertung werden das Projekt bzw. der Projektverlauf als Ganzes beurteilt. Hier sind auch Rezension bzw. Verbesserungsvorschläge nennenswert. ===== 3.2 Dokumentation ===== Alle sicherheitskritischen Dokumente werden auf OneDrive archiviert und meinem Berufsbildner freigegeben. Jeden Tag sollen Snapshots der Arbeit auf die externe USB Disk gesichert werden. {{IPA-Tag10_html_bb97291a2f984135.png?480x268 }}\\ \\ \\ \\ \\ \\ ====== 4 Zeitplan ====== \\ \\ {{IPA-Tag10_html_b82a64cd469e6cdc.gif}} ====== 5 Arbeitsprotokoll ====== | **TAG 1** || | **Datum** | Fr, 12.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Zeitplan erstellt / überarbeitet Netzwerkpläne erstellt (IST / TEST / SOLL) Spezifikationen der Geräte in Tabellen erfasst RAID konfiguriert, wird später dokumentiert, evaluiert Proxmox aufgesetzt Staging PCs beschriftet (Funktionskontrolle) Die Windows Installation beider zu konfigurierenden VMs wurde gestartet \\ \\ | | **Aufgetretene Probleme** | Bis anhin keine | | **Problemlösung** | - | | **Reflexion** | Ich bin heute gut vorwärtsgekommen. Ich konnte alle im Zeitplan definierten Aktivitäten erreichen. | | **Wissensbeschaffung** | __[[https://wiki.ubuntuusers.de/dmidecode/|https://wiki.ubuntuusers.de/dmidecode/]]__\\ __[[http://australianemploymentparty.org/9-ablaufplan-excel-vorlage/|http://australianemploymentparty.org/9-ablaufplan-excel-vorlage/]]__ | | **Beanspruchte Hilfe** | Egil Rüefli (Fachverantwortlicher) gab mir einige Informationen zu dem Erstellen von Netzwerkplänen. | | **Zeitplan eingehalten** | Ja, teilweise | \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ | **TAG 2** || | **Datum** | Mo, 15.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Basiskonfiguration der VMs Zeitplan angepasst Backup / Restore Planung beschrieben Standardimage für das Deployment beschrieben RAID Evaluation fertig gestellt Evaluation des Proxmox Storage fertig gestellt Die VM srv-zh-ad-01 (AD, DHCP) wurde fertig eingerichtet Es wurde mit der Einrichtung der VM srv-zh-ds-01 begonnen \\ \\ | | **Aufgetretene Probleme** | Keine, alles lief bis anhin problemlos. Ich bin jedoch recht stark vom Soll Zeitplan abgewichen. | | **Problemlösung** | Das nächste Mal sollte ich versuchen, mich nach Möglichkeit mehr an den Zeitplan zu halten. | | **Reflexion** | Ich bin stark vom Soll Zeitplan abgewichen. Ich habe gemerkt, dass gewisse Aufgaben länger benötigen, als zuerst gedacht. Deshalb habe ich mit vielen Aktivitäten früher begonnen als geplant. | | **Wissensbeschaffung** | __[[https://www.acronis.com/de-de/articles/whats-raid10-and-why-should-i-use-it/|https://www.acronis.com/de-de/articles/whats-raid10-and-why-should-i-use-it/]]__ __[[https://apt.iteas.at/|https://apt.iteas.at/]]__ \\ | | **Beanspruchte Hilfe** | Mit dem Fachvorgesetzten wurden die KO Kriterien bezüglich der RAID sowie der Proxmox Storage Evaluation festgelegt. Ich habe mich bezüglich der Proxmox Storage Evaluation mit dem Kandidaten Lukas Bischoff ausgetauscht. | | **Zeitplan eingehalten** | Nein | \\ \\ | **TAG 3** || | **Datum** | Di, 16.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Informieren über das Funktionsprinzip von WDS und MDT Softwarekomponenten, WDS / MDT installiert, weiter eingerichtet, dokumentiert \\ | | **Aufgetretene Probleme** | Keine | | **Problemlösung** | - | | **Reflexion** | - | | **Wissensbeschaffung** | __[[https://de.wikipedia.org/wiki/Windows_Deployment_Services|https://de.wikipedia.org/wiki/Windows_Deployment_Services]]__ __[[https://de.wikipedia.org/wiki/Microsoft_Deployment_Toolkit|https://de.wikipedia.org/wiki/Microsoft_Deployment_Toolkit]]__ __[[http://webcache.googleusercontent.com/search?q=cache:http://techthoughts.info/mdt-with-wds-integration-overview/|http://webcache.googleusercontent.com/search?q=cache:http://techthoughts.info/mdt-with-wds-integration-overview/]]__ \\ | | **Beanspruchte Hilfe** | \\ | | **Zeitplan eingehalten** | Ja | \\ \\ | **TAG 4** || | **Datum** | Mi, 17.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | MDT weiter konfiguriert, DHCP getestet, PXE Boot getestet, Referenz VM aufgesetzt, WDS Server von Grund auf neu aufgesetzt. | | **Aufgetretene Probleme** | Ich habe für das testen der PXE-Client Installation eine VM erstellt. Proxmox hat als virtuelle Netzwerkkarte das falsche Modell genommen. Somit ist der Deployment Prozess mit einem Fehler abgebrochen. / Danach wurde eine Konfigurationsdatei des WDS Servers ohne vorhin getätigten Snapshot abgeändert, mit dem Ziel, das Tastaturformat auf de-ch zu ändern. Der Versuch schlug fehl. Der komplette WDS Server mit MDT hat nicht mehr auf eine nachträgliche Änderung der Konfigurationsdatei auf den Ursprungszustand reagiert. Ich war somit gezwungen, den WDS Server von Grund auf neu aufzusetzen, was ein gravierender Verlust von IPA-Zeit darstellt. Deshalb werde ich am 4. Tag meiner IPA so lange arbeiten, bis ich den Stand des 3. Tages wiederhergestellt habe. Leider schlug auch der Versuch fehl, die VM neu einzurichten, da diese urplötzlich sehr langsam wurde, obwohl weder CPU noch RAM ausgelastet war. | | **Problemlösung** | Ich musste das Modell der virtuellen NIC auf Intel E1000 ändern, damit das Deployment erfolgreich funktionieren kann. Bei einem physikalischen Client hat dieses Problem nicht existiert. / Neu installieren und konfigurieren der kompletten Server Umgebung. | | **Reflexion** | Das nächste Mal muss ich besser darauf achten, welche Art der virtuellen Netzwerkkarte die VM nutzt. Beim nächsten Mal sollte ich vor einer unsicheren Änderung einen Snapshot erstellen. | | **Wissensbeschaffung** | Fachverantwortlicher nach Vorgehensweise gefragt. | | **Beanspruchte Hilfe** | Unterstützung beim Debugging durch Fachverantwortlichen Egil Rüefli und Mitarbeiter der Rafisa (Stefan Kuhn) | | **Zeitplan eingehalten** | Ja, ich bin nicht unter Zeitdruck, die Soll- und IST Werte des Zeitplans unterscheiden sich jedoch stark. | | **TAG 5** || | **Datum** | Do, 18.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Die technische Realisierung wurde von neuem begonnen. Proxmox neu aufgesetzt. Srv-zh-ad-01 installiert / konfiguriert Srv-zh-ds-01 installiert / konfiguriert Die VM pxe-test-clt wurde eingerichtet | | **Aufgetretene Probleme** | Ich habe mir für das Debugging eine Frist von einer Stunde gesetzt. Es konnte innert dieser Zeit kein Debugging für die bestehende Umgebung getätigt werden, deshalb entschied ich mich, meine Umgebung nochmals aufzusetzen. | | **Problemlösung** | Erneutes aufsetzen meiner Umgebung, um weitere Probleme ausschliessen zu können. | | **Reflexion** | Ich konnte «retten», was am Tag davor an Zeit verloren ging. Die Umgebung ist bis auf wenige noch zu tätigende Aufgaben einsatzbereit. Die VM pxe-test-clt wurde eingerichtet, obwohl dies in der Aufgabenstellung nicht verlangt wurde. Dadurch wird die Installation der Standard Software und das Capturing erleichtert. Zusätzlich wird dadurch das Erstellen von Screenshots sowie das Testing erleichtert. Dieser Schritt wurde auch im Kapitel 7.4 notiert. | | **Wissensbeschaffung** | Eigene Erfahrungen bzw. eigene bereits bestehende Dokumentationen zur korrekten Realisierung halfen mir, die Realisierung rasch erneut abschliessen zu können. | | **Beanspruchte Hilfe** | Egil Rüefli (Fachverantwortlicher): gab mir den Rat, nicht länger als 1h für das Debugging zu verwenden. | | **Zeitplan eingehalten** | Ja | \\ \\ | **TAG 6** || | **Datum** | Di, 23.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Software Installation auf Client Capture Prozess durchgeführt, dokumentiert Offline Media erstellt, dokumentiert Allgemeine Anpassungen am Dokument Benutzeranleitung für das Aufsetzen eines Clients geschrieben \\ | | **Aufgetretene Probleme** | Heute sind keine Probleme aufgetreten. Ich konnte die Realisierung erfolgreich abschliessen. | | **Problemlösung** | - | | **Reflexion** | Heute ist alles gut gelaufen. | | **Wissensbeschaffung** | __[[https://theitbros.com/capture-windows-10-reference-image/|https://theitbros.com/capture-windows-10-reference-image/]]__ __[[https://www.vkernel.ro/blog/creating-an-offline-mdt-deployment-media|https://www.vkernel.ro/blog/creating-an-offline-mdt-deployment-media]]__ | | **Beanspruchte Hilfe** | Ich konnte alle an diesem Tag beschriebenen Aktivitäten ohne zusätzliche Hilfe durchführen. | | **Zeitplan eingehalten** | Ja | \\ \\ | **TAG 7** || | **Datum** | Mi, 24.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Staging der beiden PCs mit Referenz Image Staging eines PCs mit Offline Media Testszenario / Drehbuch wurde erstellt Tests wurden durchgeführt \\ | | **Aufgetretene Probleme** | Mir war anfangs nicht ganz klar, wie das Testing zu gestalten ist. | | **Problemlösung** | Der Fachverantwortliche hat mir Inputs gegeben, wie man ein Testkonzept erstellen könnte. Daraufhin konnte ich bereits fast alle Tests dokumentieren. | | **Reflexion** | Alles ist gut gelaufen, Das vom Fachverantwortlichen angegebene Testkonzept Hermes war mir zu kompliziert. Ich habe dieses deshalb auf meine Bedürfnisse angepasst. | | **Wissensbeschaffung** | __[[http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=ergebnis_testkonzept.html|http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=ergebnis_testkonzept.html]]__ | | **Beanspruchte Hilfe** | Egil Rüefli (Fachverantwortlicher): gab mir den Ratschlag, zu Hermes Testkonzept zu recherchieren | | **Zeitplan eingehalten** | Ja | \\ \\ | **TAG 8** || | **Datum** | Do, 25.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Dokumentation nachgeführt Expertenbesuch Tests dokumentiert Auswertung geschrieben | | **Aufgetretene Probleme** | keine | | **Problemlösung** | - | | **Reflexion** | Es ist alles gut verlaufen. Ich bin zufrieden mit dem, was ich heute erreicht habe. | | **Wissensbeschaffung** | - | | **Beanspruchte Hilfe** | Der Fachverantwortliche gab mir Tipps, wie die Auswertung zu schreiben ist. | | **Zeitplan eingehalten** | Ja | \\ \\ | **TAG 9** || | **Datum** | Fr, 26.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Dokumentation erweitert Testing fertig beschrieben Screenshots beschrieben Zeitplan nachgeführt Glossar erweitert Quellenverzeichnis nachgeführt \\ \\ | | **Aufgetretene Probleme** | keine | | **Problemlösung** | - | | **Reflexion** | Ich konnte die aufgeführten Tätigkeiten problemlos durchführen | | **Wissensbeschaffung** | - | | **Beanspruchte Hilfe** | - | | **Zeitplan eingehalten** | Ja | \\ \\ | **TAG 10** || | **Datum** | Mo, 29.04.2019 | | **Arbeitszeit** | 08:00-17:00 | | **Ausgeführte Aufgaben** | Quellenangaben ergänzt Schlusswort überarbeitet Dokumentation überarbeitet Darstellung der Dokumentation angepasst Erste PDF Versionen begutachtet IPA Dokumentation angepasst, fertig gestellt und auf PkOrg hochgeladen | | **Aufgetretene Probleme** | keine | | **Problemlösung** | - | | **Reflexion** | Ich konnte meine IPA Dokumentation gut abschliessen. Ich war zeitlich gut unterwegs und war nicht gestresst. | | **Wissensbeschaffung** | - | | **Beanspruchte Hilfe** | - | | **Zeitplan eingehalten** | Ja | ======= Teil 2 - Projekt ======= ====== 6 Kurzfassung IPA-Bericht ====== \\ \\ **Kurze Ausgangssituation** In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik zu InformatikerInnen EFZ ausgebildet. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatik-Ausbildung sowie Bewerbungs- und Job-Coachings an. Im Zuge dieser Tätigkeiten müssen immer wieder frische PC-Arbeitsplätze eingerichtet werden. Einmal im Jahr - in den Sommerferien - werden alle Lernenden-PC's neu aufgesetzt. Als Basis für die Neuinstallation dient ein Standard-Image, welches mittels Clonezilla einzeln und von Hand aufgespielt wird. Um die Effizienz dieses Prozesses zu erhöhen, wurde beschlossen, eine automatisierte Deploymentlösung zu evaluieren. **Umsetzung** Auf der Basis des Windows Deployment Services (WDS) wurde eine Lösung für das Deployment der Windows-Standard-Images aufgebaut und evaluiert. Es wurde ein RAID nach den Vorgaben der beschriebenen Evaluierung konfiguriert. Die Virtualisierungsumgebung Proxmox wurde daraufhin nach den Vorgaben aufgesetzt. Es wurden zwei virtuelle Server erstellt. Die VM srv-zh-ad-01 wurde installiert. DHCP, DNS und AD wurden darin konfiguriert. Es wurde ein Deployment Admin erstellt, mit welchem sich Clients beim Deployment anmelden können. Die VM srv-zh-ds-01 wurde konfiguriert. Dabei wurden WDS und MDT installiert und konfiguriert. Beide Server wurden in die Domain rafisa.intern aufgenommen. Eine Backup / Restore Lösung wurde evaluiert und konfiguriert. Der PXE Boot wurde getestet. Es wurde ein Standard Image erstellt, welches erfolgreich verteilt werden konnte. Das Testing wurde daraufhin erfolgreich durchgeführt. **Ergebnis** Die Deployment Lösung konnte erfolgreich nach den Vorgaben meiner Aufgabenstellung realisiert werden. Es wurde ein umfangreiches Testkonzept erstellt. Die Bereiche AD Server, WDS Server und Backup / Restore wurden getestet. Jegliche, darin beschriebene Tests wurden durchgeführt und waren erfolgreich. Damit kann die Deployment Lösung nach Abschluss der IPA produktiv eingesetzt werden. \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ ====== 7 Informieren ====== ===== 7.1 Proxmox VE ===== Proxmox VE ist eine auf Debian basierende Open-Source-Virtualisierungsplattform zum Betrieb von virtuellen Maschinen mit einer Web-Oberfläche. Die Umgebung basiert auf QEMU mit der Kernel-based Virtual Machine (KVM). Durch die Verwendung einer Web-Oberfläche wird das Erstellen und Nutzen von VMs erleichtert. Auch Backups können somit einfach getätigt werden. Weiters können Cluster von mehreren PVE-Hostsystemen gebildet werden welche gemeinsam verwaltet werden. Zwischen solchen können virtuelle Maschinen ausgetauscht werden. Dies ermöglicht den Aufbau von Hochverfügbarkeitsclustern. Eine großartige Eigenschaft von PVE ist, dass alle möglichen Pakete des Debian-Projekts mittels dem Debian Package Manager (dpkg) und dem darauf aufbauenden Advanced Packaging Tool (apt) auf dem Proxmox Server nachinstalliert werden können. Auch die Verwaltung und Aktualisierung von Proxmox-Paketen erfolgt über eigene Repositories. Der Veröffentlichungszyklus von PVE liegt bei etwa zwei bis vier Monaten. Die Virtualisierungs-Plattform Proxmox VE wird von der Wiener Proxmox Server Solutions GmbH entwickelt und betreut. ===== 7.2 Funktionsprinzip von WDS: ===== ==== 7.2.1 WDS und MDT ==== Die Aufgabe besteht darin, einen auf den Windows Deployment Services (WDS) basierenden Deployment-Server aufzusetzen und zu testen. WDS wird unter Windows 2008/12/16 verwendet, um Windows-Images im .wim-Format über das Netzwerk zu verteilen. Die Verteilung der Images erfolgt mit Hilfe eines Preboot Execution Environments (PXE), über das eine Miniatur-Version von Windows, das sogenannte Preinstallation Environment (PE) geladen wird. Während WDS nur für die Verteilung von Images zuständig ist, hilft das Microsoft Deployment Toolkit (MDT) auch beim Design und dem Anlegen von Betriebssystem-Images mit Hilfe von Task Sequences und Rules (s. Glossar). MDT verfügt über keinen eigenen Deployment-Mechanismus. Ähnlich wie WDS lässt sich ein Preinstallation Environment, bei MDT Lite Touch genannt, erzeugen. Dieses kann aber durch MDT nicht über das Netzwerk verteilt werden. Deshalb besteht die optimale Lösung darin, WDS und MDT zu kombinieren. \\ \\ ==== 7.2.2 Funktionsweise des Deployment Systems ==== Hier ist das Funktionsprinzip von WDS zu sehen. Der Client sucht sich nach drücken der F12 Taste über das Netzwerk einen DHCP Server. Letzterer gibt die IP Adresskonfiguration und die Adresse des WDS Servers an den Client weiter. Der Client bootet daraufhin die LiteTouch Umgebung, mit welcher eine einfache OS Verteilung möglich ist. In dieser LiteTouch Umgebung wird nach den auf dem WDS Server festgelegten Regeln der Client aufgesetzt. Eine automatische Anmeldung am WDS Server kann ebenfalls hinterlegt werden. Um WDS realisieren zu können, werden sowohl ein DHCP- als auch ein AD Server benötigt. Ich habe mich für MDT entschieden, da es benutzerfreundlicher ist als die manuelle Konfiguration mittels Answer Files. In dieser IPA ist es nicht von Nöten, eine ZTI (zero touch installation) zu konfigurieren, daher brauche ich mich nicht mit SCCM zu befassen. Benutzereingaben während der Lite Touch Installation müssen begründet sein. Zum Beispiel ist das manuelle vergeben eines Hostnamens eine mögliche Benutzereingabe während der PXE-basierten Installation. ===== 7.3 Multicast vs Unicast ===== 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. MDT bietet die Option an, Multicast zu aktivieren. Dadurch wird die Multicast Einstellung automatisch den Windows Bereitstellungsdiensten (WDS) hinzugefügt. \\ \\ ===== 7.4 Netzplan des Lernenden-Netzwerks ===== Hier ist der IST Netzwerkplan der Rafisa GmbH aufgelistet. Gemäss Aufgabenstellung sind hier die Geräte in meinem Testnetzwerk ersichtlich. Auf den folgenden Seiten sind die detaillierten Spezifikationen ersichtlich. Im Plan sind die Hostnames der Geräte angegeben. Der FQDN des Lernenden Netzwerkes ist rafisa.local. \\ \\ {{IPA-Tag10_html_3123accc4091c617.png?363x472}}\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ In der folgenden Tabelle sind die Server aufgelistet: | **Server** ||||||| | **Host-name** | **Funktion** | **IP Adresse** | **Ort** | **Zugang** | **Ansprech-partner** | **Schnitt-stellen** | | SRV-ZH-01 | AD (win2016) | 192.168.77.31 | Rafisa Serverraum Bernstrasse 90 UG | Ausbildner-schlüssel Blau & Lagerschlüssel Grün | Team Server | 4x Ethernet | | SRV-ZH-02 | AD-Repl. (win2016) | 192.168.77.32 | Rafisa Serverraum Bernstrasse 90 UG | Ausbildner-schlüssel Blau & Lagerschlüssel Grün | Team Server \\ | 4x Ethernet \\ | | SRV-ZH-Proxmox | Virtualisierung (Proxmox VE / Debian Stretch) | 192.168.77.34 | Rafisa Serverraum Bernstrasse 90 UG | Ausbildnerschlüssel Blau & Lagerschlüssel Grün \\ | Team Server \\ | 4x Ethernet \\ | \\ \\ Die folgende Tabelle enthält die Netzwerkgeräte: | **Switches / Router** |||||| | **Hostname (FW)** | **IP Adresse** | **Ort** | **Zugang** | **Ansprech-partner** | **Schnittstellen** | | GS1920 (v 4.30) | - | 3. OG Rack A | Fingerabdruck, Rack Schlüssel | Team Server | 48 Port Ethernet | | GS1920 (v 4.30) | - | 3. OG Rack B | Fingerabdruck,Rack Schlüssel | Team Server | 24 Port Ethernet | | GS1920 (v 4.30) | - | 2. OG, Lernende Rack | Fingerabdruck Rack Schlüssel | Team Server | 48 Port Ethernet | | GS1920 (v 4.30) | - | Bernstr. 90, UG Serverraum | Ausbildner-schlüssel Blau & Lagerschlüssel Grün | Team Server | 24 Port Ethernet | | Router_isp (v 4.13) | 192.168.1.1 | Bernstr. 90, UG Serverraum | Ausbildner-schlüssel Blau & Lagerschlüssel Grün \\ | Team Server | 4x Ethernet Port | \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ Untenstehend sind die Drucker aufgelistet | **Drucker** ||||||| | **Hostname** | **Funktion** | **IP Adresse** | **Ort** | **Zugang** | **Ansprech-partner** | **Schnittstellen** | | SEC842519223C57 | - | 77.29 | 3, OG | Fingerprint | Team PC /Drucker | USB Ethernet | | SEC842519223C5D \\ | - | 77.28 | 3, OG | Fingerprint | Team PC /Drucker \\ | USB Ethernet | | PR0022 | Farb-Laserdrucker | 77.22 | 2. Stock, Büro-raum | Fingerprint | Team PC /Drucker | USB Ethernet | | PR0020 | S/W Laserdrucker | 77.20 | 2. Stock, Büro-raum | Fingerprint | Team PC /Drucker | USB Ethernet | \\ \\ ===== 7.5 HW Spezifikationen der eingesetzten Rechner ===== ==== 7.5.1 Ermittlung der Spezifikationen ==== Mit dem Linux Betriebssystem grml können die HW Spezifikationen ermittelt werden. Grml ist eine seit Januar 2005 existierende, auf Debian basierende Linux-Distribution und läuft vorrangig als Live-System. Dieses Betriebssystem kann mit folgenden Befehlen das ermitteln von HW Informationen erleichtern. dmidecode -t processor #Prozessor Infos dmidecode -t memory #Memory Infos hdparm -I /dev/sda #Disk lspci #Netzwerkkarte (PCI Geräte) ==== 7.5.2 Spezifikationen des Dell Servers ==== Nachfolgend sind die Spezifikationen meines Servers aufgelistet. Dieser Server bildet die Grundlage für meine Virtualisierungsplattform. | Modell | CPU | RAM | Disks | RAID Controller | NIC | | PowerEdge R610 | Intel(R) Xeon(R) CPU E5520 2.27GHz \\ | 8x 4096MB DDR3 - 1333 Mhz \\ \\ = 32’768 MB RAM | 4x SAS HDD 2x Seagate 146GB 10k RPM 2x Dell 146GB 15k RPM | LSI Logic MegaRAID SAS 1078 PERC 6/i Integrated RAID Controller (RAID 0, 1, 5, 6, 10, 50 und 60) | Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet | \\ \\ ==== 7.5.3 Spezifikationen des Arbeitsplatz Rechners ==== Nachfolgend liste ich die Spezifikationen des Computers auf, mit welchem ich meine Dokumente verfasse und meine Server konfiguriere. | Modell | CPU | RAM | Disks | OS | NIC | | HP ProBook 4540s | Intel Core i5 2450m 2.5 Ghz \\ | 6GB DDR3 | 750GB SATA HDD 2.5 Zoll | Windows 10 Pro N 64-Bit | Realtek PCIe GBE Family Controller | \\ \\ ==== 7.5.4 Spezifikationen der Rechner für das Staging ==== Hier sind die Spezifikationen der beiden Arbeitsplatzrechner aufgelistet, welche ich für das Staging verwende. | Modell | CPU | RAM | Disks | OS | NIC | | Lenovo ThinkCentre M91p | I5-2400 3.10 Ghz | 8192 MB 1333 Mhz DDR3 | Hitachi 2 TB SATA HDD | - | Intel Gigabit Ethernet | | Lenovo ThinkCentre M91p | I5-2400 3.10 Ghz | 2048 MB 1333 Mhz DDR3 | Hitachi 80GB SATA HDD | - | Intel Gigabit Ethernet | \\ \\ ====== 8 Planen ====== ===== 8.1 Erstellen der Arbeitspakete / Projektziele ===== Hier werden meine Aufgabenstellung bzw. die dadurch geforderten Tätigkeiten in einzelne Schritte zerlegt: | **Arbeitsschritte** | **IPERKA** | | Erfassen der IST Netzwerkumgebung | I | | Erfassen der Spezifikationen des Servers und der PCs | I | | Netzplan der Testumgebung erstellen | I | | Netzplan mit Deployment Lösung | I | | Backup / Restore Planung | P | | Festlegen des Standardimage für das Deployment | P | | Evaluation des Proxmox Storage | E | | Arbeitsplatz einrichten (IPA Umgebung) | R | | RAID konfigurieren, Proxmox aufsetzen | R | | Inst. / Konfig. der VM Win2016 AD Server | R | | Inst. / Konfig. der VM Win2016 WDS Server | R | | Inst. / Konfig. der Deployment Lösung | R | | Referenz-VM über PXE aufsetzen | R | | Software installieren auf Referenz PC | R | | Capture Prozess des Referenz PC | R | | Staging der beiden PCs mit Referenz Image | R | | Offline Media vorbereiten (USB Stick) | R | | Staging eines PCs mit dem Offline Media | R | | Testszenario erstellen | K | | Tests durchführen | K | | Testszenario Auswerten | K | | Auswerten/ Dokumentation der Ergebnisse | A | | Dokumentation/ Reflexion | A | \\ \\ ===== 8.2 Netzplan der Testumgebung ===== Nachfolgend ersichtlich ist der Netzwerkplan meiner Test Umgebung. Die einzelnen Details zu den Objekten sind anschliessend tabellarisch aufgelistet. {{IPA-Tag10_html_664fdddd8305976e.png?346x314}}| **Hostnames** | **IP Adresse** | **Funktion** | **Zugang** | **Schnittstellen** | | Laptop-ZH-201 | 192.168.30.88 | IPA-Dokumentation, Proxmox-Zugriff | Fingerabdruck | 1x Ethernet | | srv-zh-pxmx-01 | 192.168.30.10 | IPA Server (Proxmox VE\\ v. 5.3.5) | Fingerabdruck | 4x Ethernet | | GS1016 | - | Network Switch | Fingerabdruck | 16x Ethernet | | fw | 192.168.30.1 | Firewall Zywall USG 35 (schirmt das Testnetzwerk ab) | Fingerabdruck, Web Interface | 4x Ethernet | | router | 192.168.3.1 | Router des ISP (Zywall USG 40) | Ausbildner Schlüssel-Blau, Lagerschlüssel-Grün, Web Interface | 4x Ethernet | | WAN | - | Internet | mittels ISP | - | | PC-ZH-Staging-01 / PC-ZH-Staging-02 | (DHCP) | PXE-Client Computer | Fingerabdruck | 1x Ethernet | \\ \\ ===== 8.3 SOLL Netzwerkplan ===== \\ \\ Dieser Netzwerkplan zeigt die Einbettung des Deployment Servers im Lernenden Netzwerk der Rafisa. Die Details zu den Geräten können unter dem Kapitel 6 eingesehen werden. Der Deployment Server läuft als virtuelle Maschiene auf srv-zh-pxmx-01. Der Proxmox Server ist per Gigabit Ethernet an die Testumgebung angebunden. Mit Hilfe von Multicasting wird der gesamte Backbone mit nur einem zu sendenden Deployment-File belastet. Alle Switches sind miteinander per Gigabit Uplinks verbunden. {{IPA-Tag10_html_b2a4e42bbf77ef9c.png?362x526}}\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ ===== 8.4Vorgaben für das Standard Image ===== Das Standardimage der Rafisa GmbH ist bewusst sehr einfach gehalten. Es besteht nur aus einer Partition. Als Software sind nur ein Office Paket und verschiedene Webbrowser installiert. Softwaretechnische Anpassungen dieses Images werden je nach Anforderung der verschiedenen Abteilungen manuell vorgenommen. Folgende Anwendungen müssen im Image vorhanden sein: | **OS / Software** | | Windows 10 Enterprise\\ Ohne Windows Apps | | Microsoft Office 2016 Plus | | Firefox | | Chrome | \\ \\ Als Standarduser des Referenz Image ist der Nutzer Administrator vorhanden. Für das Einrichten des Standard Image und das anschliessende Capturing wird eine zusätzliche VM eingerichtet (pxe-test-clt). Dies wird zwar in der Aufgabenstellung nicht gefordert, erleichtert allerdings das Erstellen von Screenshots. ===== 8.5 Backup Planung ===== Für das Backup müssen zunächst die Rahmenbedingungen (Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten und applikatorische Vorgaben) abgeklärt werden. Aus der Aufgabenstellung geht hervor, dass die VM des Deployment Servers vor und nach jeder Änderung des Images auf eine externe Festplatte gespeichert werden soll. Der ganze Vorgang wird manuell durchgeführt. Die theoretische Geschwindigkeit von USB 2.0 beträgt 480Mb/s. Unter realistischen Bedingungen erreicht man maximal 320Mb/s. Wenn wir davon ausgehen, dass die VM srv-zh-ad-01 etwa 50 GB und die VM srv-zh-ds-01 ca. 100GB gross ist, dann kommt man für das Backup auf eine Gesamtdatenmenge von ca. 150GB. Die Datenmenge wird dadurch reduziert, dass lvm-thin die virtuelle Festplatte dynamisch wachsen lässt. Bei unserer Schätzung unten gehen wir deshalb von einem Maximalvolumen aus, denken aber dass das Backup aufgrund lvm-thin weniger Zeit braucht. Mit dem Online-Download-Speed-Calculator lässt sich berechnen, dass bei einer Datenmenge von 150GB und einem Speed von 320 Mb/s ca. 1 Stunde und 7 Minuten Transferzeit anfallen werden. Quelle. __[[https://superuser.com/questions/317217/whats-the-maximum-typical-speed-possible-with-a-usb2-0-drive|https://superuser.com/questions/317217/whats-the-maximum-typical-speed-possible-with-a-usb2-0-drive]]__ Quelle : __[[https://www.download-time.com/|https://www.download-time.com/]]__ Die Rahmenbedingungen sind folgende: * Datenmenge: ca. 150GB (VM des WDS Servers + Images + VM des AD Servers) * Transferzeiten: ca. 1 Stunde und 7 Minuten * Aufbewahrungsfrist: vor und nach jeder Veränderung des Images wird ein Backup der VM durchgeführt. Die ältesten Kopien werden jeweils gelöscht. * Sicherungsperiodizitäten: vor und nach jeder Veränderung des Images wird eine Sicherung der VM durchgeführt. * applikatorische Vorgaben: Es soll eine automount extension für Proxmox installiert werden. ====== 9 Entscheiden ====== ===== 9.1 Evaluation RAID Level ===== \\ \\ Für die Raid-Konfiguration stehen 4 HDDs à 146GB zur Verfügung (s. Kapitel 6.2). Für meine Arbeit wird der folgende Platz benötigt (Schätzung): \\ \\ | **Objekt** | **Platzbedarf [GB]** | | Proxmox-Server | 20GB | | VM-AD | 50GB | | VM-WDS | 100GB | | VM-Windows 10 für Thick Image | 20GB | | Thick Image | 20GB | | Offline Media | 20GB | | ISO-Abbilder | 10GB | | **TOT** | **240GB** | Der Raid-Controller bietet folgende RAID-Levels an: 0, 1, 5 und 10. RAID 10 bietet schnelleres Lesen und Schreiben von Daten als RAID 5, da keine Parität verwaltet werden muss. Raid 1 (Mirroring) ist mit 4 Platten nicht sinnvoll. Die KO-Kriterien sind damit: \\ \\ | **KO-Kriterium (Erfüllt: Ja/Nein)** | **RAID 0** | **RAID 1** | **RAID 5** | **RAID 10** | | 4 HDs | ja | nein | ja | ja | | > 240GB | ja | nein | ja | ja | | Ausfallsicherheit | nein | ja | ja | ja | \\ \\ Nach Auswertung der KO-Kriterien bleiben also RAID 5 und RAID 10 als mögliche Kandidaten. Mit dem Fachverantwortlichen wurden vorgängig folgende Kriterien mit den jeweiligen Gewichten festgelegt: \\ Read-Performance [0-10]: 10 Nutzbarkeit des Festplattenspeichers [0-10]: 5 \\ Der Seite __[[https://www.cyberciti.biz/tips/raid5-vs-raid-10-safety-performance.html|https://www.cyberciti.biz/tips/raid5-vs-raid-10-safety-performance.html]]__kann entnommen werden, dass RAID 10 gegenüber RAID 5 eine etwa doppelte Read-Performance aufweist. Bei RAID 5 können 3 Platten genutzt werden (3 x 146GB = 438GB), bei RAID 10 2 Platten (2 x 146 = 292GB). \\ Damit kann folgende Entscheidungsmatrix erstellt werden: | **Kriterium** | **Gewichtung** **[0-10]** | **RAID 5** **[0-10]** | **RAID 10** **[0-10]** | **RAID 5 gew.** | **RAID 10 gew.** | | Read- Performance | 10 | 5 | 10 | 50 | 100 | | Nutzbarkeit | 5 | 7.5 | 5 | 37.5 | 25 | | **TOTAL** | \\ | \\ | \\ | **87.5** | **125** | \\ Die Entscheidung fällt auf RAID 10. \\ \\ ===== 9.2 Evaluation Proxmox Storage ===== ==== 9.2.1 Die Proxmox Storage Formate ==== **QEMU Image Format (qcow)**:\\ qcow ist ein Dateiformat für Disk-Image-Dateien, das von QEMU, einem gehosteten Monitor für virtuelle Maschinen, verwendet wird. Es steht für "QEMU Copy On Write" und verwendet eine Strategie zur Optimierung des Festplattenspeichers, die die Zuweisung von Speicherplatz verzögert, bis er tatsächlich benötigt wird. Es gibt zwei Versionen des Formats: qcow und qcow2. **Raw Disk Image**:\\ Ein Raw Disk Image enthält eine exakte, Sektor Weise Kopie einer einzelnen Partition oder Festplatte. **VMware Image (vmdk)**:\\ VMDK (kurz für Virtual Machine Disk) ist ein Dateiformat, das Container für virtuelle Festplattenlaufwerke beschreibt, die in virtuellen Maschinen wie VMware Workstation oder VirtualBox verwendet werden. **LVM**:\\ Unter Linux ist der Logical Volume Manager (LVM) ein Gerätezuordnungsziel, das die logische Datenträgerverwaltung für den Linux-Kernel bereitstellt. **LVM-Thin**:\\ LVM weist normalerweise Blöcke zu, wenn ein Volume erstellt wird. LVM Thin Pools weist stattdessen Blöcke zu, wenn sie geschrieben werden. Dieses Verhalten wird Thin-Provisioning genannt. **ZFS**:\\ ZFS ist ein kombinierter Dateisystem- und logischer Volume-Manager, entwickelt von Sun Microsystems. ZFS ist skalierbar und bietet umfassenden Schutz vor Datenkorruption, Unterstützung hoher Speicherkapazitäten, effiziente Datenkompression, Snapshots und Copy-on-Write-Klone, kontinuierliche Integritätsprüfung, automatische Reparatur und kann sehr präzise konfiguriert werden. \\ \\ ==== 9.2.2 Vergleich der Storage Formate und Auswahl gemäss KO-Kriterien ==== | **Kriterien** | **Gewichtung** | **QEMU** | **RAW** | **VMWare** | **LVM** | **LVM-Thin** | **ZFS** | | PVE-Typ | \\ | dir | dir | dir | lvm | lvmthin | zfspool | | Format | \\ | qcow2 | raw | vmdk | lvm | lvmthin | zfs | | Level | \\ | file | file | file | block | block | file | | Shared | \\ | nein | nein | nein | ja | nein | nein | | **Snapshots** | KO-Kriterium | **ja** | **nein** | **nein** | **ja** | **ja** | **ja** | | **Stabil** | KO-Kriterium | **ja** | **ja** | **ja** | **ja** | **ja** | **ja** | | **Auf HW-Raid** | KO-Kriterium | **ja** | **ja** | **ja** | **ja** | **ja** | **nein** | | **Thin Provision** | KO-Kriterium | **ja** | **nein** | **nein** | **nein** | **ja** | **ja** | \\ \\ ==== 9.2.3Performance Test mit Fio (Storage Formate qemu und lvm-thin) ==== Fio bezeichnet eine Abkürzung von “Flexible IO Tester”. Fio ist ein Werkzeug zum Messen von Input-Output-Performance. Geräte wie HDDs werden damit auf ihren Speed geprüft. \\ Dafür wird ein vom Benutzer festgelegter Workload ausgeführt und die anfallenden Performance-Daten ermittelt. \\ Zu Gunsten der Performance-Messung wurde bereits vor der IPA (s. Vorarbeiten) auf einem Proxmox-System eine je 20GB grosse virtuelle Disk im QCOW2-Format bzw. als LVM-Thin-Image angelegt und mit dem nachfolgend aufgeführten Befehl getestet: \\ \\ - fio --randrepeat=1 --ioengine=libaio --direct=1 --name=perftest --filename=/dev/pve/vm-100-disk-0 --iodepth=64 --size=1G --readwrite=randrw --rwmixread=75   \\ \\ Hier die Erläuterung folgender Parameter: \\ **--randrepeat= 1** #Der Zufallsgenerator erzeugt ähnliche Patterns für jegliche Requests **--ioengine=libaio** #libaio ist eine Library zum ausführen paralleler I/O-Requests **--iodepth=64** #Summe der parallelen Requests **--direct=1** #Pagecache bypass **--name=perftest** #Bezeichnung des Tests **--filename=/dev/pve/vm-100-disk-0** #Disk oder Datei, in welche geschrieben werden kann (hier ein Thin-LVM-Image **--size=1G** #Grösse des zu schreibenden und zu lesenden Datenverkehrs (Patterns) **--readwrite=randrw** #Zugriffsvariante, hier, durchmischter, random Workload **--rwmixread=75** #75% des Workloads Schreibzugriffe, 25% Lesezugriffe (vgl. den Wert io= in nachfolgenden Ergebnissen. \\ Hier sind die Resultate des Tests. Der Wert aggrb= zeigt, dass LVM-thin fast 4 Mal zügiger ist als QEMU. Der Wert aggrb liegt bei LVM-thin bei beinahe 12MB/s. Bei QEMU liegt dieser nur bei ca. 3MB/s: {{IPA-Tag10_html_14e603d857fb1546.png?534x219}}\\ Diese Kriterien wurden vorab mit dem Fachverantwortlichen gewichtet: * Performance [0-10]: 8 * Portabilität [0-10]: 4 * Einfachheit [0-10]: 4 \\ Als nächsten Punkt baue ich aus den Resultaten meine Präferenzmatrix auf. Präferenzmatrix für die beiden Storage-Formate QEMU und LVM-thin Die Werte für die Einschätzung und Gewichtung liegen zwischen 0 und 10. \\ | **Kriterium** | **Gewichtung** | **QEMU** | **LVM-Thin** | **QEMU gew.** | **LVM-Thin gew.** | | Performance | 8 | 2.5 | 10 | 20 | 80 | | Portabilität | 4 | 6 | 4 | 24 | 16 | | Einfachheit | 4 | 8 | 4 | 32 | 16 | | **TOTAL** | \\ | \\ | \\ | **76** | **112** | \\ Die Wahl fällt glasklar auf LVM-Thin. ====== 10 Realisieren ====== ===== 10.1 RAID Konfiguration auf dem Dell PowerEdge R610 Server ===== {{IPA-Tag10_html_661997f74a8d289.png?410x307}} Die Konfiguration des Servers startet mit dem Einrichten des RAID. Beim Start des Servers sollte rechtzeitig CTRL + R gedrückt werden, um in die RAID Konfigurationsoberfläche zu gelangen. Mit der Taste F2 werden die Konfigurationsoptionen angezeigt. \\ \\ Hier ist die RAID Konfiguration ersichtlich. Die Entscheidung fiel auf RAID 10. Die Stripe Size des RAID Controllers ist auf dem Maximalwert von 64KB gesetzt worden. Kleine Stripe Sizes eignen sich gut für viele Zugriffe auf kleine Dateien, zum Beispiel bei einem Datenbankserver. Falls grosse Dateien sequenziell gelesen werden, sollte die Stripe Size möglichst gross sein. \\ \\ \\ \\ {{IPA-Tag10_html_27c15d82525b4f39.png?413x295}}\\ \\ ===== 10.2 Installation und Konfiguration von Proxmox ===== ==== 10.2.1 Basisinstallation von Proxmox ==== Zuerst wurde das Proxmox ISO Image in der Version 5.3.5 von der Seite __[[https://www.proxmox.com/de/downloads|https://www.proxmox.com/de/downloads]]__ heruntergeladen. Dieses wurde mit einem entsprechenden Programm auf einen USB Stick kopiert. Hier ist die Erstkonfiguration des Proxmox Servers ersichtlich. Als FQDN Hostname wurde «srv-zh-pxmx-01.rafisa.intern» gewählt. Damit entspricht die Einstellung den Vorgaben meiner Aufgabenstellung. Als IP Adresse wurde «192.168.30.10» gewählt. Ich habe mich bewusst für eine IP Adresse im unteren Bereich des Subnetzes entschieden, da im oberen Bereich, also ab 192.168.30.50 DHCP laufen wird. Als Subnetzmaske wurde eine standardmässige Subnetzmaske gewählt. Als DNS Server wurde die FW angegeben. Hier könnte problemlos auch der DNS von Google (8.8.4.4) angegeben werden. {{IPA-Tag10_html_3327bbc5d7d12600.png?485x331}}\\ \\ ==== 10.2.2 Partitionierung des Proxmox Servers ==== {{IPA-Tag10_html_6308d532eb10c875.png?512x209}} Ich habe bei der Installation die Standardpartitionierung von Proxmox übernommen. Durch meine früheren Erfahrungen mit Proxmox weiss ich, dass der Default-Partitionierungs-Vorschlag von Proxmox vernünftig ist. Auf der Disk sda (RAID Volume) wurde eine kleine Boot Partition sda1 mit einem MB Grösse, eine EFI Bootpartition sda2 mit 512MB Grösse und eine Linux LVM Partition sda3 mit 271.8 GB Grösse erstellt. In dieser lvm Volume Group werden die folgenden weiteren lvm Volumes eingerichtet: D{{IPA-Tag10_html_39472e5544c30891.png?605x143 }}\\ as erste swap lvm Volume ist der SWAP des Proxmox Servers. Das zweite hier ersichtliche Volume ist das Root-System des Proxmox Servers und das 3. Volume ist das thin-volume-group für das Erstellen der Festplatten für die VMs. Unten sieht man noch die HDDs der einzelnen VMs. ==== 10.2.3 Proxmox Netzwerkkonfiguration ==== Für den Proxmox wurde die Default Konfiguration mit einer Bridge gewählt. Das entsprechende Config-File findet sich unter /etc/network/interfaces: Mit dem Eintrag bridge_ports eno1 wird das Interface eno1 mit der virtuellen Bridge verbunden. Der Eintrag bridge_stp (Spanning Tree Protocol) definiert, ob im Falle von mehreren miteinander verbundenen Bridges ein eventueller Loop verhindert werden soll. Auf diesem Proxmox Server existiert allerdings lediglich eine Bridge. Deshalb kann der Eintrag auf dem standardmässigen Wert «off» belassen werden. Somit entsteht kein zusätzlicher Overhead. Der Parameter bridge_fd legt fest, wie lange es dauert, bis das der Bridge hinzugefügte Interface aktiv wird. Da das Spanning Tree Protocol ohnehin ausgeschaltet ist, kann das Interface sofort aktiv werden. Die drei weiteren Interfaces werden in dieser IPA nicht verwendet. {{IPA-Tag10_html_f5497054a4b3e5cf.png?433x336}} Quelle: __[[https://wiki.debian.org/BridgeNetworkConnections|https://wiki.debian.org/BridgeNetworkConnections]]__ \\ \\ ===== 10.3 Unter Proxmox eine VM erstellen ===== {{IPA-Tag10_html_dfd7659eeaae1d34.png?527x386}} Im Bild unten ist ersichtlich, mit welchen Einstellungen die VM srv-zh-ds-01 konfiguriert wurde. Der VM wurden 2 Prozessorkerne und 2GB Arbeitsspeicher zugewiesen. Dies stellt ein guter Mittelwert dar. Als Name der VM wurde der Hostname des virtuellen Servers angegeben. Als Anschluss der virtuellen Festplatte wurde SATA gewählt. Es stehen ausserdem die Optionen SCSI und IDE zur Verfügung. Mit der Option SCSI findet Windows die virtuelle Festplatte aufgrund fehlender Treiber nicht. Die Option IDE führt zu einer etwas langsamen VM. Deshalb habe ich mich für SATA entschieden. Als Netzwerkkarte verwende ich das virtuelle Modell Intel E1000. Damit funktioniert das Deployment problemlos. ===== 10.4 Installation und Konfiguration der VM: Server 2016-AD (DHCP, DNS) ===== ==== 10.4.1 Basisinstallation ==== Für den AD Server ist eine Festplattengrösse von 50GB vorgesehen. Dies reicht gut, da der AD Server lediglich als DHCP Server und zur Authentifizierung dient, allerdings nicht als Dateiserver. {{IPA-Tag10_html_e0f94cda7323d162.png?390x292}}\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ ==== 10.4.2 Grundkonfiguration des Servers ==== {{IPA-Tag10_html_f74a77b371c77eb9.png?262x316}} In den Systemeinstellungen wird der Hostname des Servers festgelegt. Dabei entspricht der Wert srv-zh-ad-01 den Vorgaben meiner Aufgabenstellung. {{IPA-Tag10_html_6c6e932a0be93fe3.png?290x331}} Hier ist die Netzwerkkonfiguration des AD Servers zu sehen. Der AD Server bekommt die IP Adresse 192.168.30.15 und ist damit dem DHCP Bereich nicht im Weg. Als Subnetzmaske wird die standardmässige Subnetzmaske gewählt. Als Gateway gebe ich die FW an. Als bevorzugten DNS Server gebe ich die IP Adresse des Servers selbst an. Dazu gebe ich als alternativen DNS Server die IP Adresse des Google DNS an. \\ \\ ==== 10.4.3 AD Konfiguration ==== {{IPA-Tag10_html_ac10a79acc83ff44.png?506x360}} Die AD Konfiguration des virtuellen Servers srv-zh-ad-01 kann im Server Manager unter «Rollen und Features» eingestellt werden. Dort wird die Option «Active Directory Domänendienste» zur Installation ausgewählt. {{IPA-Tag10_html_a888729748a46e58.png?484x353}} Der nächste Schritt ist die Konfiguration des AD. Zuerst wird der Server zu einem Domänencontroller hinaufgestuft. Dazu muss der Name der Stammdomäne nach Vorgabe meiner Aufgabenstellung angegeben werden. Als nächster Schritt muss das DSRM Kennwort angegeben werden. Zur Vereinfachung wird immer dasselbe Passwort verwendet, in diesem Fall das allgemeine Administratorpasswort. Nach der AD Installation ist ein Neustart erforderlich. Danach kann das AD konfiguriert werden. ==== 10.4.4 DHCP Konfiguration ==== {{IPA-Tag10_html_b93a10694f3a1d16.png?430x305}} Nachdem das AD eingerichtet wurde, ist der nächste zu tätigende Schritt die DHCP Installation und Konfiguration. Dazu wird im Server Manager unter «Rollen und Features hinzufügen» der Punkt «DHCP-Server» ausgewählt. Nachdem DHCP erfolgreich installiert wurde, kann mit der Konfiguration begonnen werden. Im Server Manager unter Tools wird dafür «DHCP» ausgewählt. Es öffnet sich ein neues Fenster. Man klickt auf IPv4 und wählt «neuer Bereich» aus. {{IPA-Tag10_html_cad69020c0b62002.png?386x291}} Danach werden Namen und eine Beschreibung des Bereichs angegeben und der Adressbereich festgelegt, in welchem DHCP tätig ist (192.168.30.50 bis 192.168.30.180). Als nächstes werden die Leasedauer, die Adresse des Standardgateways und die des DNS Servers festgelegt. Jetzt ist DHCP einsatzbereit. Nun wird der DHCP Server dafür vorbereitet, den PXE Boot zu ermöglichen. Dazu wird unter denn DHCP Einstellungen auf «Serveroptionen» geklickt und der Eintrag «Hostname des Startservers» ausgewählt. Schliesslich wird der Hostname des Startservers angegeben. (srv-zh-ds-01). {{IPA-Tag10_html_4d364d651c54d9e9.png?323x327}}\\ \\ Als nächster Schritt vor der Konfiguration des WDS Servers wird das AD konfiguriert. Es muss ein WDS-Administrator erstellt werden, mit welchem man sich beim Deployment Server anmelden kann. Die Funktion dieser Anmeldung setzt voraus, dass der Deployment Server an der Domain angemeldet ist. {{IPA-Tag10_html_891fa8cd301280ff.png?329x279}} Zuerst wird im Server Manager unter «Tools» die Konfigurationsoberfläche «Active Directory Benutzer und Computer» geöffnet. Dann wird auf den Namen der Stamm-Domain geklickt und «Neu»  «Organisationseinheit» ausgewählt. Man gibt der Organisationseinheit (OU) den Namen Deployment-Users. In dieser OU wird der Nutzer WDS Administrator erstellt. (wds.root). \\ \\ {{IPA-Tag10_html_333d0dae197d4b2b.png?354x283}} Um den Nutzer in der entsprechenden OU zu erstellen, wird mit der rechten Maustaste auf die OU geklickt und «Neu»  «Benutzer» ausgewählt. Hier ist der Anmeldename des Nutzers zu sehen (__[[wds.root@rafisa.intern|wds.root@rafisa.intern]]__) Es ist wichtig, die Option «Kennwort läuft nie ab» zu wählen, da der Deployment User für automatisierte Prozesse verwendet wird. Es ist daher unpraktisch und kann unvorhersehbare Folgen haben, dem Deployment User ein Passwort zu geben, welches ablaufen würde. Als nächsten Schritt fügt man den Benutzer in dessen Optionen den Administratoren hinzu, damit dieser die vollständigen Berechtigungen der Domän hat. Schliesslich ist die Konfiguration der VM bzw. des Servers srv-zh-ad-01 abgeschlossen. ===== 10.5 DNS Konfiguration ===== Hier werde ich meine DNS Konfiguration veranschaulichen. Die beiden virtuellen Server r-zh-ad-01 und r-zh-ds-01 wurden automatisch dem DNS Server hinzugefügt. Ich musste nur meinen Proxmox Server manuell hinzufügen. {{IPA-Tag10_html_22c472f77c498e53.png?605x423 }}\\ \\ \\ ===== 10.6 Installation und Konfiguration der VM: Server 2016-WDS (MDT) ===== ==== 10.6.1 Basisinstallation ==== Der Deployment Server benötigt eine 2. Partition, um Images speichern zu können (WDS Share). {{IPA-Tag10_html_cca8e3372b5e13b0.png?422x316}} Es wurde eine 100GB grosse Harddisk erstellt und es sind 40GB davon für das Betriebssystem vorgesehen. Dir restlichen 60GB dienen der 2. Partition. \\ \\ ==== 10.6.2 Grundkonfiguration des Servers ==== {{IPA-Tag10_html_1b51d9538f3bca32.png?260x313}} Hier ist der Hostname zu sehen, welcher dem WDS Server gegeben wurde. Dieser entspricht den Vorgaben meiner Aufgabenstellung. {{IPA-Tag10_html_b322b22fbe6a03a7.png?297x336}} Im unteren Bild ist die Netzwerkkonfiguration des WDS Servers zu sehen. Als IP Adresse habe ich 192.168.30.17 festgelegt. Diese ist bewusst im unteren Bereich des Subnetzes, um dem DHCP Server nicht in den Weg zu kommen. Als Subnetzmaske habe ich die standardmässige Maske genommen. Als Gateway gebe ich die FW an. Damit die Anmeldung an der Domain funktioniert, wurde als primärer DNS Server die Adresse von srv-zh-ad-01 genommen. Damit die Auflösung öffentlicher DNS Anfragen funktioniert, habe ich als sekundären DNS Server die IP des Google DNS Server angegeben. \\ \\ {{IPA-Tag10_html_e5646ea3a4cbd00c.png?299x359}} Als nächster Schritt wird der Server srv-zh-ds-01 der Domain rafisa.intern hinzugefügt. Dieser Schritt ist sehr wichtig, damit sich der Deployment User an der Domain anmelden kann. ==== 10.6.3 Download und Installation von MDT ==== MDT dient der einfachen Konfiguration von OS Deployments. Es umfasst zwei Komponenten. Das eigentliche Microsoft Deployment Toolkit sowie die ADK Komponenten. {{IPA-Tag10_html_b8ea46263503afa1.png?447x298}} Nun wird jegliche für MDT vorausgesetzte Software heruntergeladen und installiert. Die nötige Software mit den Deployment Rules wurde bereits in einem Ordner auf dem IPA Stick hinterlegt. Es muss also lediglich der Inhalt jenes Ordners auf das Laufwerk D:\ des Servers srv-zh-ds-01 kopiert werden. \\ \\ {{IPA-Tag10_html_ce82d941469b2b23.png?424x307}} Anschliessend kann mit der Installation der einzelnen Softwarekomponenten begonnen werden. Es ist von Vorteil, darauf zu achten, dass alle Softwarepakete auf dem Laufwerk D:\ installiert werden. Dies dient auch dem einfachen Überblick über den Speicherort der Deployment Files sowie der Softwarekomponenten. Als Installationspfad für Windows ADK ist «d:\Program Files (x86)\Windows Kits\10\» gewählt worden. Die PE Komponente von Windows ADK bzw. für MDT wurde am selbigen Ort installiert. Als Installationsstandort von MDT wurde die Partition D:\ angegeben. ==== 10.6.4 WDS Konfiguration ==== {{IPA-Tag10_html_ca70ac426fa41908.png?475x322}} Nun können im Server Manager unter «Rollen und Features» die Windows Bereitstellungsdienste installiert werden. \\ \\ {{IPA-Tag10_html_4dccddfc9fffc8ae.png?400x317}} Da die für das Deployment benötigten Rollen und Softwarekomponenten vorhin installiert wurden, fährt man nun mit der Konfiguration von WDS fort. Testmässig kann man ein Windows Image bereitstellen, um zu überprüfen, ob der PXE Boot über WDS erfolgreich gestartet werden kann. Um mit der Konfiguration von WDS zu starten klickt man im Server Manager unter Tools auf den Eintrag «Windows Bereitstellungsdienste». Es öffnet sich ein neues Fenster. Man klickt mit der rechten Maustaste auf den FQDN-Hostnamen des WDS Servers und wählt «Server konfigurieren» aus. Es öffnet sich der Assistent zum Konfigurieren der Windows Bereitstellungsdienste. Da der Server srv-zh-ds-01 in einem vorherigen Schritt bereits in die AD aufgenommen worden ist, kann man hier «Eigenständiger Server» als Option wählen. \\ \\ {{IPA-Tag10_html_cb2017eb1d614e19.png?396x310}} Hier wird als Remoteinstallationsordner erneut ein Pfad auf dem Laufwerk D:\ angegeben. Darin werden alle Pre-Boot Images wie Beispielsweise ein LiteTouch Boot File gespeichert. \\ \\ {{IPA-Tag10_html_767d768969133060.png?403x319}} Als nächstes wird festgelegt, dass der WDS Server jeglichen Client Computern antworten soll, da es in dieser Umgebung nicht von Nöten ist, für den PXE Boot zugelassene Computer per MAC Adresse einzuschränken. \\ \\ ==== 10.6.5 MDT (Deployment Share) konfigurieren ==== Als nächstes kann man MDT konfigurieren. Zunächst öffnet man die Deployment Workbench. Diese dient der Konfiguration des Deployment Prozesses. {{IPA-Tag10_html_a9546728dc645460.png?424x319}} In der geöffneten Deployment Workbench Oberfläche klickt man mit der rechten Maustaste auf die Option «Deploymet Shares» und wählt «New Deployment Share» aus. Im DeploymentShare werden das LiteTouch Image gespeichert, nachdem die Konfiguration in MDT abgeschlossen wurde. {{IPA-Tag10_html_4da8629dfede95ba.png?416x327}} Schliesslich öffnet sich ein neuer Konfigurationsassistent. Es muss erneut ein Pfad angeben werden. Es wird wieder darauf geachtet, dass sich der angegebene Pfad auf dem Laufwerk D:\ befindet. Als nächstes muss der Freigabename des DeploymentShare angegeben werden. Es wird der Standardwert übernommen. Dann folgt die Beschreibung des Deployment Share. Auch hier wird der Einfachheit halber der Standardwert übernommen und die Konfiguration fortgesetzt. Als nächstes zeigt der Wizzard eine Zusammenstellung einiger Optionen. Die Option «Ask if a computer backup should be performed» legt fest ob Daten des Computers, welchen man deployen möchte, zuerst noch gesichert werden sollten. Dies ist in meiner IPA nicht von Nöten, ich entferne daher das Häkchen. Ein Product Key muss hier nicht angegeben werden. Auch das Administrator Passwort wird erst später angegeben. Der Capture Prozess wird später über eine seperate Task Sequence eingeleitet. BitLocker, also Laufwerkverschlüsselung wird in meiner IPA nicht benötigt. Man entfernt somit alle Häkchen, da jene Konfigurationen später über eine Task Sequence erledigt werden. und fährt fort. Schliesslich ist der Deployment Share erstellt worden. ==== 10.6.6 Deployment Rules / Multicast konfigurieren ==== {{IPA-Tag10_html_fd0ebc6e64f85376.png?437x361}} Um das Deployment nun automatisieren zu können, müssen Rules angegeben werden. Diese definieren, wie die PXE Installation ablaufen soll. Zum Beispiel kann die automatische Anmeldung des Clients an der Domain konfiguriert werden. Oder es kann festgelegt werden, ob die finale Zusammenfassung nach erfolgreichem Deployment angezeigt werden soll. Um die Rules festzulegen, klickt man auf den Deployment Share und dann auf Eigenschaften. In der Registerkarte «General» der MDT Eigenschaften aktiviert man zuerst Multicast. {{IPA-Tag10_html_696e72b0b6ebe04e.png?396x198}} Als nächstes wechselt man zur Registerkarte «Rules» und kopiert die bereits erstellten Rules aus dem Text File dorthin. Ausserdem muss für eine erfolgreiche Anmeldung des PXE Clients am Server die bootstrap.ini Datei angepasst werden. Nun wird auf «Edit Bootstrap.ini» geklickt. Danach können die definierten Einstellungen eingefügt werden. Es müssen Rules für 2 Szenarien erstellt werden. Rules für das Deployment (Verteilen des OS Image) und Rules für das Capturing. Capturing ist das Erfassen einer Referenz Computer Umgebung für das Erstellen des Thick Images ==== 10.6.7 Deployment Rules ==== Folgende Deployment Rules sind auf dem Server konfiguriert. Ich habe für jede dieser Optionen herausgesucht, was jene bedeuten. | [Default] | Standard | | OSInstall=Y | (Betriebssysteminstallation wird durchgeführt) | | SkipCapture=YES | (Capture Prozess wird nicht gestartet) | | SkipAdminPassword=YES | (Administrator Passwort überspringen) | | SkipProductKey=YES | (Eingabe des Product-Keys wird übersprungen) | | SkipComputerBackup=YES | (Es wird kein Computer Backup durchgeführt) | | SkipBitLocker=YES | (Laufwerkverschlüsselung überspringen) | | JoinDomain=rafisa.intern | (Der Client tritt der Domain «rafisa.intern» bei) | | DomainAdmin=wds.root | (Anmeldenamen des Domain Admins angeben) | | DomainAdminDomain=rafisa.intern | (Name der Stammdomain angeben) | | DomainAdminPassword=Passw0rd1 | (PW des Domänen Administrators) | | SkipApplications=YES | (Keine Anwendungen über MDT verteilen) | | SkipBDDWelcome=YES | (Die Windows Willkommensseite überspringen) | | SkipComputerName=NO | (Es muss ein PC Hostname vergeben werden) | | SkipDeploymentType=YES | (Deployment Typ wird übersprungen) | | SkipUserData=YES | (Benutzerdaten werden übersprungen) | | SkipFinalSummary=NO | (finale Zusammenfassung nicht überspringen) | | SkipLocaleSelection=YES | (Regionswahl überspringen) | | SkipPackageDisplay=YES | (Display Packung überspringen) | | SkipRoles=YES | (Rollen überspringen) | | SkipSummary=NO | (Zusammenfassung nicht überspringen) | | SkipTaskSequence=NO | (Task Sequence wird nicht übersprungen) | | SkipTimeZone=YES | (Setzen der Zeitzone wird übersprungen) | \\ \\ ==== 10.6.8 Capture-Rules ==== Die Capture-Rules definieren wie das Image auf den Server gespeichert wird. Die Capture-Rules auf dem Server sind die folgenden: | [Default] | Standard | | OSInstall=N | (Es wird kein Betriebssystem installiert) | | SkipCapture=NO | (Der Capture Prozess wird durchgeführt) | | SkipAdminPassword=YES | (Es wird kein Administrator Passwort vergeben) | | SkipProductKey=YES | (Es wird kein Product Key angegeben) | | SkipComputerBackup=YES | (Es wird kein Backup durchgeführt) | | SkipBitLocker=YES | (Es wird keine Laufwerkverschlüsselung verwendet) | | DoCapture=YES | (Der Capture Prozess wird durchgeführt) | \\ \\ ==== 10.6.9 Betriebssystem importieren (MDT) ==== {{IPA-Tag10_html_de32158a655b8a50.png?475x392}} Nun wird das Betriebssystem Windows 10 importiert. Hierfür sollte in der Deployment Workbench mit der rechten Maustaste auf Operating System geklickt und «Import Operating System» gewählt werden. Als nächstes kann «Full set of source files» ausgewählt werden, da zunächst einfach ein standardmässiges Windows verteilt wird. \\ \\ {{IPA-Tag10_html_e731d7a7e057f5df.png?451x377}} Nun kann der Pfad des Installationsmediums angegeben und mit dem Import der Windows Images fortgefahren werden. Als nächstes muss noch der Name des Zielverzeichnisses angegeben der Import des OS gestartet werden. ==== 10.6.10 Task Sequence erstellen ==== I{{IPA-Tag10_html_e303cf6f261e9de9.png?430x93 }}\\ n der Task Sequence werden Prozesse definiert, die während des Deployments oder des Capturings nacheinander abgearbeitet werden. Als Input Parameter dieser Prozesse dienen die vordefinierten Rules. Um das standardmässige Deployment von Windows konfigurieren zu können, muss nun eine neue Task Sequence erstellt werden. Dort sind einige Angaben erforderlich. Insgesamt werden 3 Task Sequences erstellt: \\ \\ Ich habe 3 Task Sequences erstellt: * **Basic-Deployment** Nur Windows installieren \\ \\ * **Capture-Process** Softwareumgebung eines Clients als Image speichern (erfordert das Anpassen der Rules) \\ \\ * **Reference-Image-Deployment** (Deployment with Software) Standardimage mit SW installieren \\ \\ Folglich wird beispielhaft gezeigt, wie eine Task Sequence bezüglich des Basic Deployments erstellt wird.{{IPA-Tag10_html_d17d7a8d2b7aa8b8.png?456x381}} In der Microsoft Deployment Workbench von MDT kann nun mit der rechten Maustaste auf «Task Sequence» geklickt und «New Task Sequence» ausgewählt werden. Es öffnet sich ein neues Fenster. Der Task Sequence kann eine ID, einen Namen und einen Kommentar angegeben werden. Schliesslich fährt man mit der Konfiguration der Task Sequence fort. Auf der nächsten Seite wird die standardmässige Option «Standard Client Task Sequence» gewählt. {{IPA-Tag10_html_7e806409dc452637.png?442x368}} Als nächstes kann das vorher in MDT aufgenommene Betriebssystem (Windows 10) ausgewählt werden. Danach kann ein Product Key angegeben werden. In diesem Falle wird kein Product Key angegeben und zur nächsten Seite gewechselt. Nun wird der Name des Benutzers, der Name der Organisation und die Standardhomepage für Internet Explorer angegeben. Als nächstes gibt man das standardmässige Administratorpasswort an und bestätigt dieses. Schliesslich folgt eine kurze Übersicht über die zu konfigurierenden Optionen. Es wird bestätigt. Schliesslich wurde die Task Sequence erstellt. ==== 10.6.11 Deployment Share aktualisieren und LiteTouch Image hinzufügen ==== Nun ist die Erstkonfiguration des MDT Deployment Shares abgeschlossen. Als nächstes kann der Deployment Share aktualisiert werden. Dadurch wird ein LiteTouch Image erstellt, welches WDS hinzugefügt werden kann. Um den Deployment Share zu aktualisieren, wird mit der rechten Maustaste auf den Deployment Share geklickt und «Update Deployment Share» ausgewählt. Es öffnet sich ein Assistent. Die standardmässigen Optionen werden übernommen und der Prozess wird fortgesetzt. Schliesslich wurden die benötigten Images erstellt. Im Verzeichnis D:\DeploymentShare\Boot und befindet sich nun ein 64 Bit LiteTouch Image. {{IPA-Tag10_html_5fd7e0cd2550457c.png?498x435}} In der Oberfläche Windows Bereitstellungsdienste (WDS) muss nun der Assistent zum Hinzufügen eines neuen Start-Images gestartet werden. Um den Assistenten zu starten klickt man unter WDS mit der rechten Maustaste auf Startabbilder und wählt «Startabbild hinzufügen» aus. Schliesslich fährt man mit der Einrichtung des Start Images fort. Auf der nächsten Seite können der Abbildname sowie die Abbildbeschreibung angegeben werden. Die Standardwerte können übernommen und der Vorgang fortgesetzt werden. Schliesslich wird das Image dem Server hinzugefügt. Nun kann die erste, automatisierte PXE-Installation bereits getestet werden. ===== 10.7 PXE Client aufsetzen (Referenz-Client-Computer) ===== {{IPA-Tag10_html_5a37cbe37085030d.png?516x384}} Um mit dem Installationsvorgang über PXE zu starten, sollte zuerst eine VM unter Proxmox erstellt werden. Sie sollte über eine 50GB grosse virtuelle Harddisk verfügen. Das folgende Bild zeigt, dass der Client den WDS Server und dessen Images nach Auswahl der Option PXE-Boot erfolgreich gefunden hat. Das vorhin auf WDS hinterlegte LiteTouch Image des Deployment Toolkit kann nun gestartet werden. \\ \\ \\ \\ \\ \\ ===== 10.8 Softwareinstallation auf Client und Capture Prozess ===== ==== 10.8.1 Software Installation ==== Als nächstes folgt die Software Installation auf dem Client. Danach kann mit dem Capture-Prozess begonnen werden. Es sollte sich überlegt werden, welche Software das Standardimage enthalten soll. Folgende Anwendungen sollen auf dem Referenz Computer installiert sein: | Microsoft Office 2016 Plus | | Firefox | | Chrome | \\ \\ Hier ist ersichtlich, dass die aufgelisteten Programme auf dem Client ins{{IPA-Tag10_html_1bb1596a5fe5ba57.png?449x336}} talliert wurden. \\ \\ ==== 10.8.2 Deinstallation der Windows Apps ==== Nun müssen alle vorinstallierten Windows Apps per PowerShell deinstalliert werden.\\ {{IPA-Tag10_html_f1f7564476d2a144.png?510x95}} Hierfür müssen folgende Befehle ausgeführt werden: \\ \\ \\ \\ \\ \\ Quelle: __[[https://social.technet.microsoft.com/Forums/en-US/58200c26-bc8b-4563-9a97-71bca4bd009c/sysprep-fails-on-microsoftlanguageexperiencepackhu-on-windows-10-build-1803?forum=win10itprosetup|https://social.technet.microsoft.com/Forums/en-US/58200c26-bc8b-4563-9a97-71bca4bd009c/sysprep-fails-on-microsoftlanguageexperiencepackhu-on-windows-10-build-1803?forum=win10itprosetup]]__ ==== 10.8.3 Capturing ==== Beim Capturing wird die Softwareumgebung des Referenz Computers mitsamt dem Windows 10 Betriebssystem als Image auf den Server hochgeladen, um dieses später an Clients verteilen zu können. Um mit dem Capture Prozess des Referenz Computers fortzufahren, müssen nun einige Punkte beachtet werden: * Der Client muss von der Domain abgemeldet werden * Als Template für die Capture Task Sequence muss «Sysprep and Capture» gewählt werden. * Auf dem Server müssen die Deployment Rules durch die Capture Rules ersetzt werden * Der Capture Prozess wird über den Deployment Share auf dem laufenden Client gestartet und kann viel Zeit in Anspruch nehmen {{IPA-Tag10_html_291388391cbd54d1.png?319x529}} Zunächst wird der Client aus der Domain entfernt. Dies kann in den erweiterten Systemeinstellungen erledigt werden. \\ \\ \\ \\ {{IPA-Tag10_html_4152c8fdb6d99cdd.png?527x390}} Benötigte Software wurde auf dem Client installiert. Der Client ist nun nicht mehr in der Domain. Ausserdem wurden alle vorinstallierten Windows Apps entfernt. Auf dem Server wurde eine Task Sequence für den Capture Prozess erstellt. Es wurden die Deployment Rules in den Rules eingetragen. Nun kann auf dem Client in das DeploymentShare Verzeichnis des Servers gewechselt werden. Dort wird unter Scripts der Deployment Prozess gestartet. \\ \\ Hier ist zu sehen, dass der Capture-Prozess nun gestartet werden kann. Die Umgebung des Clients wird als Image auf den Server hochgeladen und kann später wieder verteilt werden. Zur späteren Verteilung wird eine neue Standard Client Task Sequence erstellt und als OS das während des Capture Prozesses auf den Server hochgeladene Windows IBS Image %%(*%%.wim-File) ausgewählt. \\ \\ ===== 10.9 Erstellen des Offline-Media ===== {{IPA-Tag10_html_6a6160cd293593fa.png?400x331}} Um das Offline Medium (USB Stick) erstellen zu können, wird unter MDT auf «Advanced Configuration» geklickt und dann mit der rechten Maustaste auf «Selection Profiles». Danach kann «New Selection Profile» gewählt werden. {{IPA-Tag10_html_82b547338122a83d.png?429x356}} Es öffnet sich ein neues Fenster. Nun kann der Name des Profils sowie ein Kommentar angegeben werden. Schliesslich kann fortgefahren werden. Hier sollte darauf geachtet werden, nur das benötigte OS Image zu wählen und nicht einfach alle Betriebssysteme. \\ \\ {{IPA-Tag10_html_39c4b555146b0c1d.png?440x364}} Hier ist der Speicherort des Offline Media anzugeben. Ausserdem sollte das vorhin erstellte Selection Profile gewählt werden. Schliesslich sollte der New Media Wizzard abgeschlossen werden. \\ \\ {{IPA-Tag10_html_d9546ac614fd8c47.png?448x370}} Als nächstes gilt es, das erstellte Media auszuwählen und die Eigenschaften des Media zu öffnen. Es müssen nun noch die Deployment Rules eingefügt werden. \\ \\ Nun ist das Einrichten des Offline Media fast abgeschlossen. Als nächsten Schritt muss das Media nun erstellt werden. Dazu klickt man unter «Media» auf «Update Media Content». Durch den Befehl «Update Media Content» wird eine ISO Datei erstellt, mit welcher später ein bootbarer USB Stick erstellt werden kann. Es empfiehlt sich, die ISO auf einen physikalischen Computer zu kopieren, um auf diesem mit Rufus einen Boot Stick erstellen zu können. ===== 10.10 Deployment ===== Der Deployment Prozess an sich ist beschrieben in der User Anleitung im Anhang. Im Testing Teil ist das Deployment ausführlich getestet worden. Folgende Benutzerinteraktionen sind notwendig: * Start des Client Computers und drücken von F12 für den Start des PXE-Boot-Vorgangs. * Auswählen des Tastaturlayouts. * Der PC-Hostname muss angegeben werden. In der Rafisa gibt es Mitarbeiter unterschiedlicher Herkunft. Diese haben alle unterschiedliche Ansprüche bezüglich der Wahl des Tastaturformates. Deswegen ist es sinnvoll, dass die Einstellung des Tastaturformates manuell angegeben werden muss. Ausserdem muss der Host-Name des zu installierenden Clients manuell angegeben werden. Dieser muss entsprechend nach den Namensrichtlinien der Rafisa vergeben werden. \\ \\ ===== 10.11 Proxmox Backup ===== ==== 10.11.1 Vorbereiten der Backupdisk ==== \\ \\ Die Backupdisk wird an einen USB2-Port angeschlossen. Mit dem Befehl dmesg wird die Disk ermittelt: [621718.440644] sd 3:0:0:0: [sdb] Attached SCSI disk Die angeschlossen Disk ist /dev/sdb. Zunächst werden die vorhandenen Partitionen mit fdisk gelöscht, danach eine neue Partition erstellt und schliesslich mit mkfs.ext3 /dev/sdb1 als Ext3 formatiert: cfdisk /dev/sdb m{{IPA-Tag10_html_476329bcdf05f41b.png?605x122 }} kfs.ext3 /dev/sdb1 Die Backup-Platte ist jetzt vorbereitet. \\ \\ ==== 10.11.2 USB-Automounter für Proxmox installieren (Putty) ==== Als nächstes wird aus einer fremden Quelle der PVE-Automounter installiert, damit die USB Disk nach dem Anschliessen automatisch erkannt und gemountet wird. Zuerst werden die entsprechenden Pakte-Quellen (Repositories) in /etc/apt/sources.list eingetragen //echo "deb https://apt.iteas.at/iteas stretch main" > /etc/apt/sources.list.d/iteas.list// Anschliessend wird mit apt-get update und apt-get install pve5-usb-automount das Automount-Paket installiert. Nach der Installation wechselt man in die Proxmox-GUI.{{IPA-Tag10_html_12929886095df892.png?620x177}} ===== =====Hier ist zu sehen, dass die USB Festplatte (usb-sdb1) automatisch eingebunden wird, sobald man diese einsteckt. ==== 10.11.3 Backup durchführen ==== Um das Backup durchzuführen wechselt man auf die Proxmox GUI und klickt auf die zu sichernde VM. Danach klickt man auf «Backup» und wählt «Backup now» aus. {{IPA-Tag10_html_1b5e68ef45306940.png?534x339 }}\\ \\ \\ \\ \\ \\ ==== ======== ======== ======== ======== ======== ====\\ \\ \\ \\ A{{IPA-Tag10_html_c79289b50414093d.png?270x159 }} ls nächstes wird unter Storage die USB Festplatte ausgewählt. Als Modus wird der standardmässige Snapshot ausgewählt. Storage beschreibt das Medium, auf welchem das Backup gesichert werden soll. Hier wird die eingebundene USB Festplatte als Medium ausgewählt. Unter Mode wählt man, wie gewährleistet wird, dass das Backup auf konsistente Daten zurückgreifen kann. Dabei kann die VM entweder mit shutdown heruntergefahren werden oder mit suspend in einen Ruhemodus versetzt werden. Andernfalls kann mit Snapshot ein Backup des aktuell ausgeführten Systems getätigt werden. Ich habe mich für die Snapshot Option entschieden, da diese den Vorteil einer Konsistenz bietet und man während des Backups weiter arbeiten kann. Bei der Kompression stehen gzip und lzo zur Verfügung. LZO ist schneller als gzip. Gzip bietet eine höhere Kompressionsrate an. LZO habe ich gewählt, da es einen guten Kompromiss zwischen Geschwindigkeit und Kompressionsrate darstellt. ==== 10.11.4 Restore durchführen ==== Falls das Backup auf einen Datenträger durchgeführt wurde, kann man dieses nun wiederherstellen. Ich gehe davon aus, dass ein Backup vorhanden ist. Nun kann einfach ein neuer Proxmox Server aufgesetzt werden. Danach kann man die Erweiterung PVE-Automounter installieren. Anschliessend kann man einfach die USB Festplatte am Proxmox Server anschliessen. Die externe Harddisk sollte dann in der Proxmox GUI ersichtlich sein. Dann wechselt man auf die USB Festplatte und wählt «Restore» aus. ====== 11 Kontrollieren ====== ===== 11.1 Testziele ===== Im Testing werden die wichtigsten Funktionen in 3 Bereiche aufgeteilt und getestet: - Funktionen des AD Servers - Funktionen des Deployment Servers - Backup / Restore ===== 11.2 Testinfrastruktur ===== {{IPA-Tag10_html_df01d2caea0adcbf.png?370x297}}Alle Tests werden von dem IPA Notebook durchgeführt. Es wird eine https-Verbindung auf das GUI des Virtualisierungsservers hergestellt (__[[https://192.168.30.10:8006/|https://192.168.30.10:8006]]__). Um das Testing innerhalb des Subnetzes der virtuellen Testumgebung durchführen zu können, wurde ein virtueller Windows 10 Client aufgesetzt (pxe-test-clt). Die Tests werden über das Konsolen-GUI der einzelnen VMs durchgeführt. ===== 11.3 Testbeschreibungen ===== In den 3 Bereichen sollen folgende Tests durchgeführt werden. ==== 11.3.1 Funktionen des AD Servers ==== | **Testfall Nr.** | **Beschreibung** | | **01** | DHCP wird getestet | | **02** | DNS wird getestet | | **03** | Zugriff des Deployment Users auf den Deployment Share | \\ \\ ==== 11.3.2 Funktionen des Deployment Servers ==== | **Testfall Nr.** | **Beschreibung** | | **04** | PXE-Boot funktioniert | | **05** | Multicast funktioniert | | **06** | Nach dem Deployment befinden sich die PCs automatisch in der Domain | | **07** | Login als Administrator funktioniert | | **08** | Installation per Offline Media funktioniert | | **09** | Der aufgesetzte PC entspricht den Vorgaben (vgl. Kapital 7.4) | \\ \\ ==== 11.3.3 Backup / Restore ==== | **Testfall Nr.** | **Beschreibung** | | **10** | Backup funktioniert | | **11** | Restore funktioniert | | **12** | Test der Transfer Zeiten beim Backup | \\ \\ ===== 11.4 Testprotokoll ===== Bei allen Tests wird folgendes Protokoll eingesetzt: | **Testfall Nr.** | #1 | | **Beschreibung** | \\ | | **Vorgehen** | \\ | | **Voraussetzungen** | \\ | | **Erwartetes Resultat** | \\ | | **OK / nicht OK** | \\ \\ \\ | | **Aufgetretene Fehler / Bemerkungen** | \\ | \\ \\ Die Beschreibung enthält eine Definition des Testzieles. Beim Vorgehen wird nachvollziehbar beschrieben, wie beim Testing vorzugehen ist. Danach werden die Testvoraussetzungen und das erwartete Resultat konkretisiert. Als Fehlerklasse ist OK / NICHT OK einzutragen. Am Schluss werden aufgetretene Fehler und Bemerkungen festgehalten. \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ ===== 11.5 Testing: Durchführung und Ergebnisse ===== \\ \\ | **Testfall Nr.** | 01 | | **Beschreibung** | DHCP Dienst auf srv-zh-ad-01 (192.168.30.15) wird getestet | | **Vorgehen** | Mit virtuellem Client pxe-test-clt überprüfen, ob eine DHCP Konfiguration bezogen werden kann (ipconfig /all) | | **Voraussetzungen** | Der DHCP Server muss konfiguriert sein und einsatzbereit | | **Erwartetes Resultat** | Der Client pxe-test-clt hat eine IP Adresse aus dem Subnetz 192.168.30.0/24, den Gateway 192.168.30.1 sowie den DNS Server 192.168.30.15 als Netzwerkkonfiguration bekommen. | | **OK / nicht OK** | O{{IPA-Tag10_html_232000761a2418b0.png?409x120 }} {{IPA-Tag10_html_59d25ebff4a32c18.png?434x256 }}\\ K \\ | | **Aufgetretene Fehler / Bemerkungen** | Der DHCP Test war erfolgreich. | \\ \\ | **Testfall Nr.** | 02 | | **Beschreibung** | DNS Dienst auf srv-zh-ad-01 (192.168.30.15) wird getestet | | **Vorgehen** | Mit virtuellem Client pxe-test-clt überprüfen, ob DNS Auflösung der Hostnamen srv-zh-ds-01 (intern) und __[[http://www.rafisa.ch/|www.rafisa.ch]]__ (extern) funktioniert. (nslookup srv-zh-ds-01; nslookup __[[http://www.rafisa.ch/|www.rafisa.ch]]__ ; nslookup srv-zh-pxmx-01) | | **Voraussetzungen** | Funktionierender DNS Server | | **Erwartetes Resultat** | Srv-zh-ds-01  192.168.30.17\\ __[[http://www.rafisa.ch/|www.rafisa.ch]]__ 213.239.213.233\\ srv-zh-pxmx-01  192.168.30.10 | | **OK / nicht OK** | OK {{IPA-Tag10_html_956e2609af87f75c.png?369x249}} {{IPA-Tag10_html_27d98b542857a372.png?380x155}} | | **Aufgetretene Fehler / Bemerkungen** | Der DNS Test war erfolgreich. | \\ \\ | **Testfall Nr.** | 03 | | **Beschreibung** | Zugriff des Deployment Users auf den Deployment Share | | **Vorgehen** | Auf dem Client wird versucht, sich mit dem User wds.root auf die Freigabe __[[::::srv-zh-ds-01:deploymentshare$|\\srv-zh-ds-01\deploymentshare$]]__ zu verbinden | | **Voraussetzungen** | Der Server srv-zh-ds-01 ist an der Domain angemeldet\\ Der User wds.admin hat Administratorenrechte | | **Erwartetes Resultat** | Der uneingeschränkte Zugriff bzw. die Anmeldung auf den DeploymentShare ist erfolgreich möglich | | **OK / nicht OK** | OK: Der User konnte sich an dem Deployment Share anmelden und sowohl Dokumente schreiben als auch löschen. | | **Aufgetretene Fehler / Bemerkungen** | Der Zugriff auf den Deployment Share war erfolgreich | \\ \\ | **Testfall Nr.** | 04 | | **Beschreibung** | PXE-Boot | | **Vorgehen** | Es wird getestet, ob der Client pxe-test-clt vom WDS Server starten kann. Der Client wird über das Testnetzwerk gestartet. Während des Startvorgangs wird die Taste F12 gedrückt, um den Start über PXE einzuleiten bzw. um diesen zu bestätigen. | | **Voraussetzungen** | WDS ist installiert und konfiguriert. Ein Image zur Verteilung ist vorbereitet. Der Hostname des Startservers ist in den DHCP Optionen angegeben. | | **Erwartetes Resultat** | Der Client pxe-test-clt findet den WDS Server srv-zh-ds-01 (192.168.30.17) und startet von diesem. | | **OK / nicht OK** | O{{IPA-Tag10_html_4b4d190a6a09f31c.png?385x314 }}\\ K: Das System bootet erfolgreich in die PXE Umgebung und das LiteTouch Image kann als Startimage ausgewählt werden. \\ | | **Aufgetretene Fehler / Bemerkungen** | Der PXE-Boot funktioniert. Der Client findet den PXE Server srv-zh-ds-01 (192.168.30.17) und startet davon. | \\ \\ | **Testfall Nr.** | 05 | | **Beschreibung** | Multicasting | | **Vorgehen** | Mit dem Client pxe-test-clt wird getestet, ob Multicast beim Deployment aktiv ist. | | **Voraussetzungen** | Multicast muss in den Optionen von MDT auf dem Server srv-zh-ds-01 aktiviert sein. | | **Erwartetes Resultat** | Multicast wird verwendet während des Deployments | | **OK / nicht OK** | O{{IPA-Tag10_html_2bc8eb88c852e9de.png?375x176 }} K: Multicast ist einsatzbereit. \\ | | **Aufgetretene Fehler / Bemerkungen** | Multicast während des Deployments funktioniert | \\ \\ | **Testfall Nr.** | 06 | | **Beschreibung** | Aufgesetzte Clients sind in der Domain angemeldet | | **Vorgehen** | Überprüfen, ob ein frisch installierter Client (pxe-test-clt) automatisch an der Domain rafisa.intern angemeldet wird. | | **Voraussetzungen** | Der Beitritt zur Domain ist in den MDT Rules des Servers srv-zh-ds-01 angegeben. | | **Erwartetes Resultat** | Der Client (pxe-test-clt) wird während des Deployments automatisch an die Domain angemeldet | | **OK / nicht OK** | O{{IPA-Tag10_html_6d23834bd7665622.png?365x398 }} K: Der Client wird automatisch an der Domain angemeldet \\ | | **Aufgetretene Fehler / Bemerkungen** | Der Client wurde während des Deployment automatisch an die Domain rafisa.intern angemeldet. | \\ \\ \\ \\ \\ \\ | **Testfall Nr.** | 07 | | **Beschreibung** | Auf dem PXE Client (pxe-test-clt) wird das Login als Administrator getestet | | **Vorgehen** | Es wird getestet, ob das Login als Administrator funktioniert. Der Client wird gestartet und es wird versucht, sich als Administrator anzumelden | | **Voraussetzungen** | Ein Client wurde über PXE aufgesetzt. Das über MDT vergebene Administrator Passwort ist bekannt. | | **Erwartetes Resultat** | Das Login als Administrator funktioniert problemlos. | | **OK / nicht OK** | OK: Das Login als Administrator ist problemlos möglich. | | **Aufgetretene Fehler / Bemerkungen** | Der Test war erfolgreich | \\ \\ | **Testfall Nr.** | 08 | | **Beschreibung** | Installation per Offline-Media wird getestet | | **Vorgehen** | Das vorab erstellte Offline Medium (USB Stick) wird an den USB Anschluss des Clients angeschlossen. Dann wird der Boot Vorgang über den USB Stick überprüft. Der Test gilt als bestanden, falls das Deployment per Offline Media erfolgreich durchführbar ist. | | **Voraussetzungen** | Offline Media mittels MDT auf dem Server srv-zh-ds-01 erstellt. USB Stick wurde vorbereitet. | | **Erwartetes Resultat** | Offline Deployment per USB Stick problemlos möglich | | **OK / nicht OK** | OK: Das System lässt sich über das Offline Medium aufsetzen. | | **Aufgetretene Fehler / Bemerkungen** | Das Deployment per Offline Media funktioniert | \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ | **Testfall Nr.** | 09 | | **Beschreibung** | Der aufgesetzte PC entspricht den Vorgaben | | **Vorgehen** | PXE Client aufsetzen (pxe-test-clt) Überprüfen der SW Konfiguration nach abgeschlossenem Deployment | | **Voraussetzungen** | Ein captured Image mit darin installierter SW ist auf dem Server srv-zh-ds-01 zur Verteilung vorhanden | | **Erwartetes Resultat** | Die Installation des PXE-Client entspricht den vorgeschriebenen Konfigurationen | | **OK / nicht OK** | OK: Der Client ist den Vorgaben entsprechend konfiguriert. | | **Aufgetretene Fehler / Bemerkungen** | Der Test war erfolgreich. | \\ \\ | **Testfall Nr.** | 10 | | **Beschreibung** | Backup | | **Vorgehen** | In der Proxmox GUI wählt man die VM aus, welche man sichern will und klickt auf Backup. | | **Voraussetzungen** | Backup Planung abgeschlossen, USB Automounter installiert. USB Festplatte vorhanden und formatiert. | | **Erwartetes Resultat** | Backup funktioniert | | **OK / nicht OK** | OK: Das Backup konnte problemlos durchgeführt werden. {{IPA-Tag10_html_b8fc501f1b1374a3.png?423x145}} | | **Aufgetretene Fehler / Bemerkungen** | Der Backup Prozess war erfolgreich \\ | \\ \\ \\ \\ \\ \\ | **Testfall Nr.** | 11 | | **Beschreibung** | Restore (Desaster Recovery) | | **Vorgehen** | Proxmox aufsetzen, Proxmox automounter installieren, Backup HDD anschliessen, in der Proxmox GUI zur Seite der HDD wechseln. Backup-File wählen, auf «Restore» klicken | | **Voraussetzungen** | Backup-Prozess erfolgreich durchgeführt | | **Erwartetes Resultat** | Restore funktioniert (Wiederherstellung der beiden VMs problemlos ausführbar) | | **OK / nicht OK** | OK: Der Restore-Vorgang war erfolgreich | | **Aufgetretene Fehler / Bemerkungen** | Der Restore Vorgang konnte problemlos durchgeführt werden. | \\ \\ | **Testfall Nr.** | 12 | | **Beschreibung** | Test der Transfer Zeiten beim Backup | | **Vorgehen** | Es wird getestet, ob die geschätzte Transferzeit des Backups etwa der Realität entspricht. Für den Backup Prozess wird eine externe HDD über USB 2.0 verbunden. Bei USB 2.0 liegt eine geschätzte Geschwindigkeit von 320 Mbit/s an. Die Schätzung der Transferzeit wurde mit etwa 1 Stunde und 7 Minuten bei 150GB Grösse angegeben. Das tatsächliche Datenvolumen, welches gesichert werden muss, ist dank lvm-thin nur ca 33 GB gross. Falls 320Mbit/s an Geschwindigkeit der Realität entsprechen würden, so würde die Transferzeit 15 Minuten ergeben. {{IPA-Tag10_html_4ab78c05ac84d90.png?403x105 }}\\ \\ | | **Voraussetzungen** | Das Backup wurde erfolgreich durchgeführt | | **Erwartetes Resultat** | Für die beiden Backups werden 15 Minuten an Transferzeit beansprucht. | | **OK / nicht OK** | NICHT OK | | **Aufgetretene Fehler / Bemerkungen** | Das Backup hat 1 Stunde und 20 Minuten an Zeit beansprucht. Die Vermutung ist, dass das Komprimieren des Backups zusätzliche Zeit in Anspruch nimmt. {{IPA-Tag10_html_2f1df098890064f.png?457x153 }}\\ \\ | \\ \\ \\ \\ ====== 12 Auswerten ====== Im Testing wurden drei grosse Bereiche getestet: * AD Server * Deployment Server * Backup / Restore An dieser Stelle werde ich noch einmal kurz die Resultate meiner Tests zusammenfassen: | **Test der Funktionalität des AD Servers** ||| | **Test Nr** | **Beschreibung** | **Erfolgreich / Nicht erfolgreich** | | 01 | DHCP | Erfolgreich | | 02 | DNS | Erfolgreich | | 03 | Zugriff des Deployment Users auf den Deployment Share | Erfolgreich | \\ \\ | **Test der Funktionalität des Deployment Servers** ||| | **Test Nr** | **Beschreibung** | **Erfolgreich / Nicht erfolgreich** | | 04 | PXE Boot | Erfolgreich | | 05 | Multicast | Erfolgreich | | 06 | Nach dem Deployment befinden sich die PCs automatisch in der Domain | Erfolgreich | | 07 | Login als Administrator | Erfolgreich | | 08 | Installation per Offline Media | Erfolgreich | | 09 | Der aufgesetzte PC entspricht den Vorgaben | Erfolgreich | \\ \\ \\ \\ \\ \\ \\ \\ | **Test der Funktionalität von Backup / Restore / Transferzeit** ||| | **Test Nr** | **Beschreibung** | **Erfolgreich / Nicht erfolgreich** | | 10 | Backup | Erfolgreich | | 11 | Restore | Erfolgreich | | 12 | Test der Transfer Zeiten beim Backup | Nicht erfolgreich | \\ \\ Alle Tests, bis auf den letzten waren erfolgreich. Damit ist die technische Realisierung meiner IPA durchaus erfolgreich verlaufen. ====== 13 Schlusswort ====== Ich bin zufrieden mit dem Ergebnis meiner IPA. Ich konnte viel dazu lernen. Die Realisierung meiner Arbeit war nicht immer einfach. Am Tag 4 meiner IPA hatte ich vor, eine Konfiguration abzuändern, was dazu geführt hat, dass ich die komplette technische Realisierung wiederholen musste. Dies hat mich daran erinnert, dass es wichtig ist, immer Backups zu tätigen. Schlussendlich konnte ich die Realisierung dennoch erfolgreich abschliessen. Das nächste Mal hüte ich mich davor, versuchstechnische Änderungen an einem System vorzunehmen, ohne vorhin eine Sicherung durchgeführt zu haben. ====== 14 Quellenverzeichnis ====== WDS: __[[https://de.wikipedia.org/wiki/Windows_Deployment_Services|https://de.wikipedia.org/wiki/Windows_Deployment_Services]]__ MDT: __[[https://de.wikipedia.org/wiki/Microsoft_Deployment_Toolkit|https://de.wikipedia.org/wiki/Microsoft_Deployment_Toolkit]]__ WDS Aufbau: __[[http://webcache.googleusercontent.com/search?q=cache:http://techthoughts.info/mdt-with-wds-integration-overview/|http://webcache.googleusercontent.com/search?q=cache:http://techthoughts.info/mdt-with-wds-integration-overview/]]__ RAID 10: __[[https://www.acronis.com/de-de/articles/whats-raid10-and-why-should-i-use-it/|https://www.acronis.com/de-de/articles/whats-raid10-and-why-should-i-use-it/]]__ Offline Media: __[[https://www.vkernel.ro/blog/creating-an-offline-mdt-deployment-media|https://www.vkernel.ro/blog/creating-an-offline-mdt-deployment-media]]__ Quellen für PVE-Automount: __[[https://apt.iteas.at/|https://apt.iteas.at/]]__ Spanning Tree in einer virtuellen Bridge: __[[https://wiki.debian.org/BridgeNetworkConnections|https://wiki.debian.org/BridgeNetworkConnections]]__ IPERKA: __[[http://c-jacob.ch/iperka/iperka.pdf|http://c-jacob.ch/iperka/iperka.pdf]]__ Powershell Befehle: __[[https://social.technet.microsoft.com/Forums/en-US/58200c26-bc8b-4563-9a97-71bca4bd009c/sysprep-fails-on-microsoftlanguageexperiencepackhu-on-windows-10-build-1803?forum=win10itprosetup|https://social.technet.microsoft.com/Forums/en-US/58200c26-bc8b-4563-9a97-71bca4bd009c/sysprep-fails-on-microsoftlanguageexperiencepackhu-on-windows-10-build-1803?forum=win10itprosetup]]__ Linux OS grml : __[[https://de.wikipedia.org/wiki/Grml|https://de.wikipedia.org/wiki/Grml]]__ USB 2.0 Speed in der Realität: __[[https://superuser.com/questions/317217/whats-the-maximum-typical-speed-possible-with-a-usb2-0-drive|https://superuser.com/questions/317217/whats-the-maximum-typical-speed-possible-with-a-usb2-0-drive]]__ Online-Download-Speed-Calculator: __[[https://www.download-time.com/|https://www.download-time.com/]]__ RAID Performance Vergleich: __[[https://www.cyberciti.biz/tips/raid5-vs-raid-10-safety-performance.html|https://www.cyberciti.biz/tips/raid5-vs-raid-10-safety-performance.html]]__ Capture Prozess: __[[https://theitbros.com/capture-windows-10-reference-image/|https://theitbros.com/capture-windows-10-reference-image/]]__ Testing: __[[http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=ergebnis_testkonzept.html|http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=ergebnis_testkonzept.html]]__ \\ ====== 15 Glossar ====== | ***.wim Dateiformat** | Dateiformat für Windows Betriebssystemabbilder | | **ADK** | Zusätzliches Softwarepaket, Voraussetzung für MDT | | **ADK+WinPE** | Zusätzliches Softwarepaket, Voraussetzung für MDT | | **BIOS / UEFI** | Firmware eines jeden Computers.\\ UEFI= Unified Extensible Firmware Interface\\ BIOS= Basic Input Output System Im Falle einer beschädigten Firmware weiss ein Computer nicht mehr, wie er sich nach drücken des Power Knopfes verhalten soll und bleibt deshalb relativ tot. | | **Capture-Prozess** | Vorgang, bei welchem ein bereits aufgesetzter Client mit Software versehen und dessen Installation als Image auf den Server hochgeladen wird. | | **Clonezilla** | Open Source Software zum klonen von Harddisks. (Abbilder von HDDs erstellen) | | **Deployment** | Automatisierte Verteilung von Software oder Betriebssystemen über das LAN oder per Offline Media | | **Lite Touch** | Ein Lite Touch Deployment bezeichnet das Aufsetzen von PCs über das Netzwerk mit mindestens einer Benutzereingabe | | **MDT** | Microsoft Deployment Toolkit: bietet eine einfache Handhabung von OS-Deployments. | | **Offline Media** | Datenträger, mit welchem das OS-Deployment ohne aktive Netzwerkverbindung erfolgen kann. | | **POST** | Power-On-Self-Test | | **PXE** | Netzwerk-Boot Vorgang | | **RAID** | Redundant Array of Independent Disks (Dient in vielen Fällen der Ausfallsicherheit und der Performance) | | **RJ45** | Bezeichnung des Steckertyps von LAN Kabeln | | **Rules** | Hilft dabei, Optionen des Deployment zu konfigurieren | | **SCCM** | System Center Configuration Manager: Dient vor allem grösseren Firmen, welche ein Zero Touch Deployment bevorzugen. (z.B. Notebookhersteller, Banken) | | **Task Sequence** | Hilft dabei eine Aufgabe (Deployment) zu konfigurieren | | **Unicast, Multicast** | Unicast\\ Server schickt jedem Client separat die Daten\\ Multicast\\ Mehrere aktive Clients, welche in einem Stream Dateien beziehen | | **WDS** | Windows Deployment Services, Bereitstellungsdienste (PXE-Boot) Stellt Betriebssysteme über das Netzwerk bereit | | **Zero Touch** | Ein Zero Touch Deployment bezeichnet das Aufsetzen von PCs über das Netzwerk ohne zusätzlichen Input durch den Benutzer. | \\ \\ \\ \\ Teil 3 -- Anhang ====== 16 Weitere Materialien ====== ===== 16.1 Benutzeranleitung für das Aufsetzen eines Clients ===== Um einen Client mittels PXE (MDT) aufsetzen zu können, muss man zuerst überprüfen, ob der Client bzw. der Zielcomputer den Netzwerk Boot unterstützt. Manche tragbare Computer wie Notebooks oder Tablets (beispielsweise Surface) haben keinen integrierten LAN Anschluss mehr und unterstützen daher auch keinen PXE-Boot. Desktop PCs hingegen sollten den PXE-Boot in über 90% der Fälle unterstützen. Beim Start eines Clients ist darauf zu achten, was nach erfolgreichem POST auf dem Bildschirm angezeigt wird. In vielen Fällen muss man lediglich F12 drücken, um den Netzwerkboot-Vorgang zu starten. Manchmal muss man den PXE-Boot über den Bootmanager auswählen. Dies ist je nach Computerhersteller unterschiedlich. N{{IPA-Tag10_html_970246ca8b389a3.png?446x357 }}\\ achdem als Boot Medium PXE ausgewählt wurde, sucht der Client mittels DHCP nach einem Startserver. Findet der Client einen Startserver, wird dessen FQDN und die IP-Adresse angezeigt. Nun muss man erneut F12 drücken, um den Start des Netzwerk-Boots zu bestätigen. \\ \\ {{IPA-Tag10_html_fd1733d576deda39.png?447x358}} Auf der nächsten Seite kann man nun zwischen den Startabbildern wählen, welche unter WDS hinterlegt wurden. Man wählt das MDT Startabbild (Lite Touch Windows PE) und bestätigt anschliessend mit Enter. \\ \\ N{{IPA-Tag10_html_a842bc2ca3ddbc56.png?605x134 }}\\ un lädt der Client das Boot Image vom Netzwerk herunter und startet anschliessend die Lite Touch PE Umgebung. \\ \\ \\ \\ {{IPA-Tag10_html_480faac57b6194a3.png?605x449}} Schliesslich ist die Lite Touch PE Umgebung gestartet. Man wählt als Tastaturformat de-ch aus und klickt anschliessend auf «Run the Deployment Wizard to install a new OS» \\ \\ Nun kann man auswählen, welche Aufgabe ausgeführt werden soll. Ich habe verschiedene Aufgaben erstellt. \\ \\ * **Basic-Deployment** Nur Windows installieren \\ \\ * **Capture-Process** Softwareumgebung eines Clients als Image speichern (erfordert das Anpassen der Rules) \\ \\ * **Reference-Image-Deployment** (Deployment with Software) Standardimage mit SW installieren {{IPA-Tag10_html_a832514ffaa318ba.png?502x369}} In der Regel sollte man die Aufgabe «Final Deployment-Process» auswählen. Damit wird ein Client mit dem Standardimage aufgesetzt und automatisch an die Domain angemeldet. Schliesslich klickt man auf «weiter», sofern man mit der Auswahl zufrieden ist. {{IPA-Tag10_html_4147e2852e498a78.png?449x336}} Auf der nächsten Seite muss man lediglich den Hostnamen des neuen Rechners angeben. Die Informationen zum Beitritt in die Domain sind bereits durch MDT Rules festgelegt worden. Schliesslich klickt man auf «weiter». {{IPA-Tag10_html_6e071dfd6f5ade35.png?500x369}} Nun klickt man auf «starten» und der Deployment Prozess kann beginnen. \\ \\ \\ \\