Inhaltsverzeichnis
Zentrales PC-Deployment auf Basis eines Linux-Deployment-Servers
IPA 2021
10.5.2021-31.5.2021
Kandidatin: Lea Cotar
Teil 1-Umfeld und Ablauf
Projektorganisation und Aufgabenstellung
Personen und Adressen
| Kandidat Lea Cotar | Betrieb (=Durchführungsort) Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T +41 79 122 99 14 M l.cotar@rafisa.ch |
|---|---|
| Verantwortliche Fachkraft Rüefli Egil Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T +41 78 767 84 04 M e.rueefli@rafisa.ch | BerufsbildernIn/Lehrfirma Wegelin Ruedi Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 P +41 76 555 05 55 M r.wegelin@rafisa.ch |
| Hauptexperte Ziegler Rolf P +41 79 284 40 56 M ipa@pegasus-informatik.ch | Nebenexperte North Daniel P +41 76 341 47 39 M daniel.north@gmail.com |
Tabelle 1: Personen und Adressen
Detaillierte Aufgabenstellung
Titel der Arbeit
Zentrales PC-Deployment auf Basis eines Linux-Deployment-Servers
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.
Dem Workplace Management kommt innerhalb der Firma eine wichtige Bedeutung zu. Die vorwiegend auf Windows 10 basierenden Arbeitsplätze werden heute mit Hilfe der Microsoft Deployment-Lösung WDS/MDT verteilt. Da immer häufiger Linux-Arbeitsplätze nachgefragt werden, wurde beschlossen, im Rahmen einer IPA die Open-Source-Deploymentlösung FOG Project zu evaluieren. Im Zentrum der Evaluation stehen die Windows 10-Arbeitsplätze, da sich die Verteilung der Linux-Images als wenig problematisch herausgestellt hat.
Detaillierte Aufgabenstellung
Auf der Basis der Deployment-Lösung FOG Project soll ein Deployment-Service für Windows-Standard-Images aufgebaut und evaluiert werden. Die Server und das Windows-Image werden in der Virtualisierungsumgebung Proxmox VE erstellt. Zudem soll ein virtueller Windows Server 2019 für Netzwerkdienste und das Testing installiert und konfiguriert werden. Die Deploymentlösung FOG wird auf Basis eines virtuellen Ubuntu-Servers eingerichtet. Das Deployment ist für zwei PCs zu testen. Die Implementierung der Lösung erfolgt nach der IPA.
Zur Verfügung stehende Hardware und Services
Hardware
1x Dedizierter PC als Server
1x Office Switch unmanaged
2x PCs für den Staging-Test
1x Arbeitsplatzrechner für Doku und Testing (Installation als Vorarbeit)
Services
Proxmox-VE Virtualisierungsplattform (Installation als Vorarbeit)
Eigenes VLAN für den Aufbau der Testumgebung
Zugang zu eigener Instanz auf dem Backup-Server der Rafisa
Volumenlizenzen (MAK) für Windows und Office
Folgende Unteraufgaben sind zu lösen (Verweise auf die individuellen Beurteilungskriterien sind mit den Kürzeln I1-I7 gekennzeichnet):
- Erfassung IST-Zustand (I1)
Eine gute Planung setzt voraus, dass der Auftrag zunächst geklärt wird.
Dazu sollen Informationen zu mindestens folgenden Bereichen eingeholt werden:
- Erfassung der zur Verfügung gestellte Hardware (Server und PCs: Modellbezeichnung, CPUs, Memory, Festplatten, Netzwerk-Interfaces. Switch: Modellbezeichnung, Übertragungsrate, Anzahl Ports)
- Erfassung der zur Verfügung gestellte Services: Kurzbeschreibung Proxmox-VE-Umgebung (Technologie, Features, Bedienung), Kurzbeschreibung Backup-Server der Rafisa (Technologie, Features, Bedienung) als Vorarbeit
- Einbettung der IPA-Testumgebung in Layer 3-Netzplan des Rafisa-Netzwerkes Dietikon (produktive Server, produktive VLANs, Firewall, keine Switches, keine Drucker, keine PCs) (I2)
- Beschreibung der Firmenstandards für das Rafisa Windows-Standard-Image: Software, Partitionierung, Layout, Spezielle Einstellungen (Informationen können dem Rafisa-Wiki entnommen werden)
- Beschreibung der Firmenstandards für das Namenskonzept (Information kann dem Rafisa-Wiki entnommen werden)
- Firmenstandard bezüglich lokalen Admin-Usern
- Kurzbeschreibung des FOG-Servers: Technologie, Features, Bedienung, Unterschiede zu WDS/MDT
<HTML><ol start=„2“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Aufzeigen von Lösungsvarianten<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Bei IT-Projekten gibt es oft verschiedene Lösungen zur Erreichung der Projektvorgaben.
Zu folgenden Vorgaben sollen Lösungsvarianten gesucht werden:
- Einrichten der Testumgebung: Durch welche Systeme werden welche Netzwerkdienste (DHCP, DNS, TFTP, AD) zur Verfügung gestellt?
- Einrichten der Testumgebung: Subnetze, welche gehen, welche nicht?
- Win2019 Server: Version
- Win2019 Server: virtuelle Hardwareressourcen, Partitionierung
- Win2019 Server: AD-OU-Struktur (User/Computer)
- Erstellen des Windows-Standard-Images: Sysprep vs. Fat-Image mit integrierten Treibern
- Erstellen des Windows Standard-Images: MBR vs. GPT-Image
- Einrichten des Ubuntu Servers: Version
- Einrichten des Ubuntu Servers: virtuelle Hardwareressourcen, Partitionierung
- Einrichten des FOG-Servers: Welche Features werden benötigt (Varianten, z.B. max/min)
- Einrichten des FOG-Servers; Verschlüsselte vs. unverschlüsselte Kommunikation
- Einrichten des FOG Servers; Unicast vs. Multicast-Deployment
- Backup und Restore: File-Backup vs. Image-Backup
<HTML><ol start=„3“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Entscheidung für Lösungsvariante (I3)<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Nachdem Lösungsvarianten erarbeitet worden sind, müssen nun in untenstehenden Bereichen begründete Entscheidungen getroffen werden.
Zudem soll ein SOLL-Netzplan der Testumgebung erstellt werden:
- SOLL-Planung, welche auf begründeten Entscheidungen über die Lösungsvarianten beruht (s. Aufgabe 2)
- SOLL-Netzplan der Testumgebung mit allen beteiligten Systemen (Server, Switch, Arbeitsplatzrechner, Staging-PCs)
<HTML><ol start=„4“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Einrichten der Testumgebung (I4)<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Die Vorgaben für die Basiseinrichtung der Testumgebung sind:
- Die Adressierung des Subnetzes ist vorgenommen (selbst gewählt)
- Network-Services: DHCP, TFTP, DNS (Hostnames aller Server eingetragen), AD-Domain (rafisa.ipa)
- Die Hostnames der Server sind gemäss Firmenstandard vergeben und in DNS eingetragen
- Virtueller Windows 2019 Server ist installiert, die für die Aufgabe wichtigen Dienste funktionieren (Hostname: gemäss Firmenstandards, Adressierung fix, Hardwareressourcen selbst festgelegt, Partitionierung selbst gewählt)
- Konto für Deployment-Administrator ist eingerichtet, Konto für Domänen-Benutzer für Testing ist eingerichtet
- Virtueller FOG Server auf Ubuntu Server ist eingerichtet (Version selbst gewählt, Hostname gemäss Firmenstandards, Adressierung fix, Partitionierung selbst gewählt, FOG-Admin kann sich über Web-GUI einloggen)
<HTML><ol start=„5“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Erstellen des Windows-Standard-Images (I5)<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Es soll ein Windows-Standard-Image erstellt und auf zwei PCs verteilt werden.
Folgende Vorgaben werden nach der Erstanmeldung eines Domänen-Benutzers am frisch verteilten System getestet:
- Software nach Vorgabe eingerichtet
- Layout nach Vorgabe eingerichtet
- Alle Gerätetreiber installiert (oder Begründung für fehlende Treiber)
- Domänenbenutzer kann sich anmelden
- Standardapplikationen: Standardapplikationen nach Vorgabe zugeordnet (PDF: Acrobat Reader, WEB: Brave, Bilder: MS Foto, Mail: Outlook, Filme: VLC-Player, Office-Dokumente: MS Office)
- Taskbar: Die Taskbar zeigt für einen Benutzer nach der Erstanmeldung folgende Applikationen: Suchleiste, Browser, Windows-Explorer, Word, Excel, Powerpoint, Outlook
<HTML><ol start=„6“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Einrichten des FOG-Servers (I6)<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Der Fog-Server soll gemäss Konzept installiert und konfiguriert werden.
Folgende Anforderungen sind zu erfüllen:
- Die PCs müssen via PXE-Boot aufgesetzt werden können
- Das Aufsetzen muss vollständig automatisiert ablaufen (Benutzereingaben sind begründet)
- Der Domänenbeitritt soll automatisiert erfolgen
- Es soll nachträglich der OpenVPN-Client auf die Clients verteilt werden
- Die Administratoren sollen sich über AD authentifizieren können
<HTML><ol start=„7“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Backup und Restore (I7)<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Im Rahmen von Vorarbeiten klärt die Kandidatin, welche Ressourcen sie auf dem Backup-Server der Rafisa benötigt und beantragt diese beim zuständigen Service-Team. Im Rahmen der IPA klärt sie die Rahmenbedingungen des Backups, realisiert Backup und Restore und testet die Lösung.
<HTML><ol start=„8“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Dokumentationen<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Kurzbeschreibung Proxmox VE
Kurzbeschreibung BackupPC
Kurzbeschreibung FOG Project
Layer3-Netzplan der Rafisa
Netzplan der Testumgebung
<HTML><ol start=„9“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Testing (mindestens)<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Alle Services in der Testumgebung funktionsfähig
Vorgaben Windows-Standard-Image erfüllt
Vorgaben FOG-Server erfüllt
Backup und Restore funktionieren
Mittel und Methoden
Windows 2019 Server AD
Linux Ubuntu
Deployment-Lösung FOG Project
Sysprep
Vorkenntnisse
- Erfahrungen mit der Deploymentlösung FOG
- Erfahrungen mit Windows 2019 Server
- Erfahrungen mit Linux Ubuntu
- Erfahrungen mit Sysprep
Vorarbeiten
- Installation Proxmox VE auf Server
- Installation Arbeitsplatz-PC
- Beantragung und Aufschalten der Backup-Dienstleistungen beim zuständigen Service-Team
- Kurzberschreibung BackupPC
Neue Lerninhalte
- Kontrolle über Standardapps und Taskleiste in Image
- Backup auf Rafisa Backup Server aufsetzen (Abklärungen als Vorarbeit)
- AD-Anmeldung FOG-Server
Arbeiten in den letzten 6 Monaten
- Mitarbeit im Server-Team. Aufsetzen und Wartung von Windows 2019 AD, Ubuntu Server
- Mitarbeit im Deployment-Team: Tests mit FOG Project, Aufsetzen von Windows-PCs mit Sysprep und Answer-Files
Durchführungsblock
| IPA-Block 13, KW19: | 10.05.2021-14.05.2021 |
|---|---|
| IPA-Durchführung: | 10.05.2021-11.06.2021 |
| Einreichung bis: | 12.04.2021 |
Tabelle 2: Durchführungsblock
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.
Personen
Ausbildner: Egil Rüefli
Lernende: Lea Cotar
Rollen
Projektleiterin: Lea Cotar
Auftraggeber, Kunde: Egil Rüefli
Aufgaben
Die Projektleiterin ist für die komplette Realisierung und Dokumentation der IPA zuständig. Der Auftraggeber ist für die Formulierung des Auftrages zuständig.
Verantwortung
Die Realisierung der IPA liegt allein in der Verantwortung der Lernenden.
Projektorganigramm
Vorgehen
Projektmethode IPERKA
Ich habe mich für die Projektmethode IPERKA entschieden, da es für meine IPA am besten anwendbar und am einfachsten überprüfbar ist. (1)
IPERKA ist eine Projektmethode und steht für:
Informieren: 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.
Planen: 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.
Entscheiden: Aufgrund der Planung und deren Möglichkeiten wird hier entschieden, wie die Umsetzung erfolgen sollte. Die Umsetzung sollte einen günstigen Fall bevorzugen.
Realisieren: 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.
Kontrollieren: Die umgesetzte Arbeit wird kontrolliert. Mögliche Konfigurationen bzw. Einstellungen, welche nicht dem günstigsten Fall entsprechen, sollten diesem angepasst werden. (Testing)
Auswerten: 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 Verbesserungsvorschläge zu nennen.
Dokumentation
Sichern der Dokumentation mit git
Die Dokumentation wird in git verwaltet. Unten sind die verwendeten Befehle angegeben.
Befehle
| Befehl | Bedeutung |
|---|---|
| git add . | |
| git commit -m „Nachricht“ | Die Ordner und deren Dateien werden mit einer Nachricht kommentiert. |
| git push | Die Ordner inklusive der Dateien werden hochgeladen. |
| git pull | Zeigt an, ob der Ordner aktualisiert ist. |
| git status | Zeigt den aktuellen Status an. |
| git clone https://github.com/LeaCotar/Tagesjournal.git | Die Ordner mit den Dokumenten werden heruntergeladen. |
Tabelle 3: GitHub Befehle
Upload
Die Dokumentationen werden lokal auf meinem Laptop bearbeitet und in dem Ordner C:\Users\Lea Sophia\Desktop\Rafisa\IPA\Tagesjournal\Tag 1 bis \Tag 11 abgespeichert. Die Dokumentationen werden kurz vor 17:00 auf GitHub hochgeladen. Der Tagesjournal Ordner auf GitHub ist an die E-Mail-Adresse e.rueefli@rafisa.ch Egil Rüefli, Verantwortliche Fachkraft, freigegeben.
Download
Um die Ordner und deren Dateien herunterzuladen, wechselt man im git CMD an den gewünschten Speicherort. Sobald man am gewünschten Speicherort (Git CMD) ist gibt man „git clone https://github.com/LeaCotar/Tagesjournal.git“ ein und die Ordner mit deren Dateien werden heruntergeladen und um zu überprüfen, ob alles aktuell ist, gibt man „git pull“ in einem der heruntergeladenen Ordner ein.
Sichern der Server mit BackupPC
Von Tag 3 an werden die Server realisiert. Vor diesem Schritt wird der Backupserver eingerichtet, so dass die Arbeitsergebnisse jeden Tag automatisch gesichert werden.
Zeitplan
Arbeitsprotokoll
Tag 1
| TAG 1 | |
|---|---|
| Datum | Di, 11.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | * Zeitplan erstellt * Erfassung der Hardware & Services * Beschreibung der Firmenstandards * Kurzbeschreibung des FOG-Deployment-Servers * Erstellen eines L3-Netzplans * Planen der Testumgebung * Planen des Windows 2019 Servers (Version, virtuelle HW, Partitionierung, AD) |
| Aufgetretene Probleme | a) Geräte für L3-Plan nicht alle bekannt b) Visio hat kein Icon für Access-Points c) Fragen beim Beschreiben von FOG und BackupPC |
| Problemlösung | a) Von VF verbindliche Liste erhalten b) Mit Router-Symbol gemacht c) Mit VF diskutiert |
| Reflexion | Das Unterscheiden von wichtigen und unwichtigen Informationen für Zusammenfassungen ist schwierig. |
| Wissensbeschaffung | VF https://backuppc.github.io/backuppc/ https://wiki.fogproject.org/wiki/index.php?title=Introduction#What_is_FOG https://community.spiceworks.com/topic/2231703-wds-2012r2-vs-fog-project-deployment-speed |
| Beanspruchte Hilfe | Diskussion mit VF Formulierungshilfen Liste der Geräte für L3-Plan von VF |
| Zeitplan eingehalten | Informieren ist im Zeitplan Planen sollte etwas weiter sein |
Tag 2
| TAG 2 | |
|---|---|
| Datum | Mi, 12.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | * Planen des Windows-Images (Sysprep vs. Fat, MBR vs. GPT) * Planen des Ubuntu-Servers (Version, virtuelle HW, Partitionierung) * Planen des FOG-Servers (Features, Verschlüsselung, Uni- vs. Multicast) * Planen von Backup und Restore (File- vs. Image-Backup, Rahmenbedingungen) * Entscheidungen Testumgebung * Entscheidungen Windows 2019 Server (Version, virtuelle HW, Partitionierung, AD) * Entscheidungen Windows-Images (Sysprep vs. Fat, MBR vs. GPT) * Entscheidungen Ubuntu-Server (Version, virtuelle HW, Partitionierung) * Entscheidungen FOG-Server (Features, Verschlüsselung, Uni- vs. Multicast) * Entscheidungen Backup und Restore (File- vs. Image-Backup, Rahmenbedingungen) |
| Aufgetretene Probleme | a) Das Verbinden der Icons im Visio machte teilweise mühe b) Angepasste verbindliche Liste von VF erhalten c) Soll-Netzplan noch nicht erstellt |
| Problemlösung | a) Verbinden der Icons im Visio erfolgreich b) Netzplan an verbindliche Liste angepasst c) Soll-Netzplan wird als „Hausaufgabe“ erledigt |
| Reflexion | Das Umschreiben von Texten fällt mir nicht besonders leicht, da mir teilweise die Worte fehlen oder der Satzbau ist danach noch etwas komplizierter. |
| Wissensbeschaffung | https://pve.proxmox.com/pve-docs/vzdump.1.html |
| Beanspruchte Hilfe | Diskussion mit VF Formulierungshilfen Liste der Geräte für L3-Plan von VF |
| Zeitplan eingehalten | Planen ist im Zeitplan Entscheiden teilweise noch im Rückstand |
Tag 3
| TAG 3 | |
|---|---|
| Datum | Mo, 17.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | * Backup für alle geplanten Systeme vorbereiten und Aufträge erstellt * Einrichten Windows 2019 Server (Alle Dienste einrichten, User eröffnen) „Komplett fertig installiert“ * Einrichten Ubuntu Server (Installiert, IP-Adresse konfiguriert) |
| Aufgetretene Probleme | Eckige Klammern [ ] konnten im Ubuntu nicht erstellt werden |
| Problemlösung | Eckige Klammern [ ] „ALT + 91“ [ „ALT + 93“ ] |
| Reflexion | BackupPC Auftrag muss Morgen noch dokumentiert werden |
| Wissensbeschaffung | https://www.diesteckdose.net/viewtopic.php?t=2802 |
| Beanspruchte Hilfe | Diskussion mit VF bezüglich BackupPC Auftrag |
| Zeitplan eingehalten | Entscheidungen und Realisierung sind im Zeitplan |
Tag 4
| TAG 4 | |
|---|---|
| Datum | Di, 18.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | * Backup für alle geplanten Systeme vorbereiten Dokumentation * Backup für alle geplanten Systeme vorbereiten Kontrolle * Einrichten Ubuntu Server (Alle Dienste einrichten) * Einrichten des FOG-Servers (Features gemäss Planung einrichten) * Erstellen des Windows-Images (Software, User, Layout) * Capture des Images |
| Aufgetretene Probleme | a) Backup für alle geplanten Systeme konnte nicht ausgeführt werden b) Konnte im Windows System Image Manager das File install.wim hinzufügen |
| Problemlösung | a) Der Hostname wurde nicht richtig aufgelöst: die Namen mussten von dc-zh-202-01 auf dc-zh-202-01.stiftung.ifa geändert werden FQDN b) Ich habe die Version von ADK 1903 deinstalliert und die 20.04 ADK Version installiert |
| Reflexion | Das Dokumentieren des BackupPC wurde heute Morgen dokumentiert. |
| Wissensbeschaffung | Die Wissensbeschaffung konnte ich aus eigener Erfahrung beschaffen |
| Beanspruchte Hilfe | Diskussion mit VF bezüglich BackupPC Problemlösung |
| Zeitplan eingehalten | Bei der Realisierung komme ich sehr gut voran. |
Tag 5
| TAG 5 | |
|---|---|
| Datum | Mi, 19.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | * Deplyoment des Images (Automatisiertes Aufsetzen + Domain-Beitritt) * Kontrolle des Stagings, allenfalls Nachbesserungen (z.B. Treiber) * Nachträgliches Verteilen des OpenVPN-Clients * Authentifizierung der FOG-Admins über Admin einrichten (LDAP AD Anbindung) * Dokumentation |
| Aufgetretene Probleme | a) Bei dem LDAP (AD-Anbindung) habe ich noch Probleme mich einzuloggen (über einen anderen User) |
| Problemlösung | a) Da das Problem bei dem LDAP (AD-Anbindung) sehr minimal ist, ist teilweise problematisch dieses Problem herauszufinden. |
| Reflexion | Heute habe ich zwar nicht so an der Realisierung gearbeitet, aber dafür umso mehr an der Dokumentation |
| Wissensbeschaffung | Ich habe mein Wissen aus anderen Dokumentationen, die ich geschrieben haben, beschafft. |
| Beanspruchte Hilfe | Diskussion mit VF über LDAP (AD-Anbindung) |
| Zeitplan eingehalten | Bei der Realisierung bin ich weiterhin sehr gut im Zeitplan |
Tag 6
| TAG 6 | |
|---|---|
| Datum | Fr, 21.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | * Kontrolle des Stagings, allenfalls Nachbesserungen (z.B. Treiber) * Nachträgliches Verteilen des OpenVPN-Clients * Authentifizierung der FOG-Admins über Admin einrichten (LDAP AD Anbindung) |
| Aufgetretene Probleme | a) Das LDAP Login wurde fehlerhaft erstellt |
| Problemlösung | a) Problem überprüft und korrigiert. |
| Reflexion | Heute habe ich die Realisierung abgeschlossen und dokumentiert. Ich habe heute mit dem VF über die Hauptthemen Planen und Entscheiden diskutiert. |
| Wissensbeschaffung | Diskussionen mit VF |
| Beanspruchte Hilfe | a) Korrektur und Diskussion des LDAP Login Problems |
| Zeitplan eingehalten | Bei der Realisierung bin ich sehr gut im Zeitplan Realisierung abgeschlossen |
Tag 7
| TAG 7 | |
|---|---|
| Datum | Di, 25.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | a) Korrektur im Abschnitt Planen b) Korrektur im Abschnitt Entscheiden |
| Aufgetretene Probleme | Es müssen noch Texte umgeschrieben werden. Ich muss noch gewisse Begründungen im Abschnitt Entscheiden schreiben. |
| Problemlösung | Die Texte konnten grössten Teils umgeschrieben werden |
| Reflexion | Ich konnte die Korrektur im Abschnitt Entscheiden sehr gut umschreiben. Dennoch muss ich noch einige Dinge in der Dokumentation verbessern. Ich habe am Montag etwa drei Stunden an der Doku gearbeitet. |
| Wissensbeschaffung | Diskussion mit einem Lernenden Feedback eingeholt |
| Beanspruchte Hilfe | Ausser der Diskussion mit dem Lernenden, habe ich keine Hilfe beanspruchen müssen. |
| Zeitplan eingehalten | Den Zeitplan konnte ich bisher gut einhalten |
Tag 8
| TAG 8 | |
|---|---|
| Datum | Mi, 26.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | a) Testkonzept erstellen b) Tests durchführen Software Testen gestartet |
| Aufgetretene Probleme | Heute sind keine Probleme aufgetreten. |
| Problemlösung | Da es keine Probleme gab, gibt es auch keine Problemlösung |
| Reflexion | Heute war der zweite Experten Besuch. Ich konnte bis auf ein paar wenige Fragen alles beantworten. Zudem war ich zu Beginn des Expertenbesuchs etwas nervös, aber diese Nervosität hat sich im Laufe des Besuchs aufgelöst. |
| Wissensbeschaffung | Ich habe gründlich nachgedacht, auf dem Windows Server 2019 nachgeschaut und mir alles notiert |
| Beanspruchte Hilfe | Tipps vom Experten |
| Zeitplan eingehalten | Der Zeitplan wurde von mir sehr gut eingehalten |
Tag 9
| TAG 9 | |
|---|---|
| Datum | Fr, 28.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | a) Testkonzept bearbeiten b) Tests durchführen Software Testen |
| Aufgetretene Probleme | Es sind keine Probleme aufgetreten. Dafür sind einige Unklarheiten aufgetaucht, bei denen ich nicht mehr weiterwusste. Mir war nicht klar, was Testmethoden sind. |
| Problemlösung | Habe im Internet nach der Definition der Testbegriffe gesucht. |
| Reflexion | Ich bin sehr gut vorwärts gekommen |
| Wissensbeschaffung | a) https://docs.fogproject.org/en/latest/management/user-management.html (2) b) https://wiki.fogproject.org/wiki/index.php?title=Power_Management (3) c) https://wiki.fogproject.org/wiki/index.php/Multicasting (4) |
| Beanspruchte Hilfe | Mit anderem IPA-Kandidaten Testkonzept und Testdurchführung besprochen. |
| Zeitplan eingehalten | Der Zeitplan wurde sehr gut eingehalten. |
Tag 10
| TAG 10 | |
|---|---|
| Datum | Mo, 31.05.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | a) Tests durchführen Software Testen b) Kontrolle der Realisierung c) Testszenario Auswerten d) Auswerten/Dokumentation der Ergebnisse/Reflexeion |
| Aufgetretene Probleme | a) Testmethoden sind noch nicht notiert worden |
| Problemlösung | a) Die Testmethoden werden Morgen, dem 01.06.2021 nachgetragen |
| Reflexion | Das Unterscheiden von wichtigen und unwichtigen Informationen für Zusammenfassungen ist schwierig. |
| Wissensbeschaffung | Keine |
| Beanspruchte Hilfe | Dokumentation zum Durchlesen meiner Mutter vorgelegt. |
| Zeitplan eingehalten | Auswerten ist so weit im Zeitplan |
Tag 11
| TAG 11 | |
|---|---|
| Datum | Di, 01.06.2021 |
| Arbeitszeit | 08:00-17:00 |
| Ausgeführte Aufgaben | a) Testkonzept erweitert b) Ergänzen von fehlenden Dokumentationen c) Kontrolle der Realisierung |
| Aufgetretene Probleme | a) Aufrufen einer verschlüsselten Seite b) Backup c) Restore |
| Problemlösung | Da die Punkte a bis c noch nicht bei den Testprotokolle erstellt wurden, mussten diese noch nachträglich nachgeführt werden |
| Reflexion | Heute konnte ich die einzelnen Text stellen nochmals kurz umgeschrieben |
| Wissensbeschaffung | https://www.ionos.de/digitalguide/online-marketing/verkaufen-im-internet/excel-tabelle-in-word-einfuegen/ (5) |
| Beanspruchte Hilfe | Letzte Tipps von meine VF. |
| Zeitplan eingehalten | Mit dem Auswerten bin ich sehr gut in der Zeit |
Teil 2-Projekt
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 offeriert die Rafisa genauso Eignungsabklärungen, Arbeitstrainings, Sozialkompetenztraining, Vorbereitungen für eine Informatik-Ausbildung sowohl Bewerbungs- und Job-Coachings an. Im Zuge jener Handlungen müssen immer wieder frische PC-Arbeitsplätze installiert werden. Als Grundlage für die Neuinstallation dient ein Standard-Image, welches via MDT aufgespielt wird. Damit auch Linux und MAC OSX installiert werden können, wurde beschlossen, die FOG Lösung zu evaluieren.
Umsetzung
Auf der Grundlage des FOG Project wurde ein Lösungskonzept für das Deployment der Windows-Standard-Images aufgebaut und evaluiert. Die Virtualisierungsumgebung Proxmox wurde als Vorarbeit aufgesetzt. Es wurden zwei virtuelle Server erstellt. Die VM srv-zh-202-01 wurde eingerichtet. DHCP, DNS und AD wurden darin konfiguriert. Es wurde ein Deployment Sysadmin erstellt, mit welchem sich Clients beim Deployment anmelden können. Die VM ds-zh-202-01 wurde mit dem Ubuntu Server 20.04 LTS aufgesetzt und konfiguriert. Das FOG Project wurde eingerichtet und konfiguriert. Eine Backup/Restore Lösung wurde von dem Backup & Restore Team evaluiert, konfiguriert und mir zur Verfügung gestellt. Der PXE Boot wurde getestet. Es wurde ein Standard Image erstellt, welches erfolgreich verteilt werden konnte. Die Testings wurden danach erfolgreich durchgeführt.
Ergebnis
Die Deployment Lösung konnte erfolgreich nach den Vorgaben meiner Aufgabenstellung eingerichtet werden. Es wurde ein umfangreiches Testkonzept erstellt. Die Bereiche AD Server, Deployment Server und Windows 10 Enterprise N wurden getestet. Jegliche darin beschriebenen Tests wurden durchgeführt und waren erfolgreich. Die Deployment Lösung kann nach Abschluss der IPA produktiv eingesetzt werden.
Informieren
Erfassung der zur Verfügung gestellten Hardware
Hardware-Server & PC’s
Mithilfe der Befehle von GRML konnte ich verschiedene wichtige Informationen der Computer herausfinden. GRML ist eine Linux-Liveversion für Sysadmins. In der folgenden Tabelle sind die Befehle zum Erfassen der Hardware aufgelistet.
| Hardware | Befehl | |
|---|---|---|
| Netzwerkadapter | lspci | |
| Harddisk | smartctl -a /dev/sda | more |
| Memory (RAM) | dmidecode -t memory | more |
| CPU | dmidecode -t processor | more |
Tabelle 4: Hardware-Server & PC’s Befehle
| Gerät | Modellbe-zeichnung | CPU | Memory | HD | NW-Adapter | BIOS-Spezifi-kationen |
|---|---|---|---|---|---|---|
| Server-PC (Proxmox) | Asus M32 | i7-6700 CPU @ 3.40GHz Quad Core | 16GB DDR4 | WDC WD1002FBYS-02A6B0 SATA 2.5, 3Gbit/s, 1TB | RTL8111/8168/84111 PCI Express Gigabit Ethernet Controller | UEFI |
| Arbeitsplatz-rechner | HP Pavilion | i5-2320 CPU @ 3.00GHz Quad Core | 8GB DDR3 Dual | LW: C:\ NTFS 111.24GB | UEFI | |
| pc-zh-202-01 | STEG | i3-4130 CPU @ 3.40GHz Quad Core | 4GB DDR3 Dual | WDC WD5000AAKX-08U6AA0 SATA 3.0, 6Gb/s, 500GB | RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller Ethernet 802.3 Realtek | UEFI |
| pc-zh-202-02 | STEG | i3-4130 CPU @ 3.40GHz Quad Core | 4GB DDR3 Dual | WDC WD5000AAKX-08U6AA0 SATA 3.0, 6Gb/s, 500GB | RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller Ethernet 802.3 | UEFI |
Tabelle 5: Hardware-Server & PC’s
Hardware-Switch
Diese Informationen konnten ich gut von dem Switch ablesen.
| Gerät | Modellbezeichnung | Übertragungsrate | Anzahl Ports |
|---|---|---|---|
| Switch | Netgear GS305 | 1 Gbit/s | 5 |
Tabelle 6: Hardware-Switch
Erfassung der zur Verfügung gestellten Services
Die Virtualisierungsplattform Proxmox VE
Proxmox VE ist eine Open Source-Virtualisierungsplattform für Server. Er kombiniert KVM- und Container-basierte Virtualisierung und verwaltet virtuelle Maschinen, Container, Storage, virtuelle Netzwerke und Hochverfügbarkeits-Cluster. Alle Funktionen sind über eine zentrale WEB-Managementoberfläche verwaltbar.
Beim vorgängig erstellten Proxmox-System handelt es sich um einen Einzelserver ohne Clusteranbindung. Als Storages stehen local für Betriebssystem-ISO's und lokale Backups sowie lvm-thin für VM's zur Verfügung.
Beim Erstellen einer virtuellen Maschine müssen zu folgenden technischen Details Entscheidungen getroffen werden:
- Auf welchem Node wird die VM erstellt (bei einem Cluster)
- Disk-Controller
- Harddisk
- CPU
- Memory
- Netzwerk (2)
Die Backup-Services mittels BackupPC
In der Rafisa kommt die Backuplösung BackupPC zum Einsatz. Dabei handelt es sich um eine freie Disk-zu-Disk Backup-Suite, die in PHP geschrieben ist. Als Übertragungsarten stehen smb für das Backup von Windows-Shares, sowie rsync für die Sicherung der Daten mit Hilfe des rsync-Protokolls zur Verfügung. Zusätzlich lassen sich die Funktionalitäten mit Pre- und Post-Backupscripts erweitern.
Die Hauptfeatures der Lösung sind:
- Webbasiertes Administrationsinterface: Konfiguration von Backups, Analyse der Logfiles, manuelles Starten und Stoppen von Backups, Browse und Restore von Backupdaten
- Datendeduplikation: Identische Files von mehreren Backups desselben Clients oder von verschiedenen Clients werden nur einmal gespeichert. Das erlaubt Einsparungen im Bereich der benötigten Kapazitäten sowie der Disks I/Os.
- Kompression: Da nur neue Files komprimiert werden müssen, werden die CPUs nur moderat beansprucht
- Open-Source: BackupPC wird auf Github gehostet und unter einer GPL-Lizenz verteilt
- Es wird keine clientseitige Software benötigt
Im Rahmen von Vorarbeiten wurde beim Team SRB (ServiceRestoreBackup) ein Zugang zum firmeninternen Backupserver beantragt.
In der Rafisa SLA #001: Backup und Restore v.01 kann man folgende für das Projekt wichtige Informationen lesen:
- Der Service Backup und Restore wird durch das Team SBR angeboten.
- Der Zugang zum Webinterface von BackupPC ist nur über das Management-VLAN möglich
- Der oder die Systemverantwortliche muss die Backupdaten bestimmen und die Strategie mit dem Team SBR absprechen
- Es stehen folgende Backuparten zur Verfügung: Backup von SMB-Shares, File-Backup von Serversystemen, Image Backup von Proxmox-VMs, Backup von Datenbank-Systemen, Backup der Konfigurationsdateien von Switches und Firewalls
In der Planung müssen folgende Punkte berücksichtigt werden:
- Zugriff ins Management-VLAN
- Festlegen von Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten gemeinsam mit dem Teamleader SBR
- Bestimmen der angemessenen Backupart
Einbettung der Testumgebung in das Netzwerk der Rafisa
Die Testumgebung der IPA ist integriert in das Netzwerk der Rafisa Informatik GmbH. Es ist für das Gelingen der IPA-z.B. im Falle einer Netzstörung, die sich auf meine Testumgebung auswirkt-wichtig, dass die Einbettung und die Systemgrenzen meiner Testumgebung bekannt sind. Deshalb wird ein L3-Netzplan (oder L3-Diagramm) erstellt, der das IPA-VLAN (VLAN53_LAB03/172.16.53.0/24) im Gesamtzusammenhang des Rafisa-Netzwerks zeigen soll. Im Rafisa-Wiki findet man die Firmenstandards für die VLANs (siehe Anhang).
VLANs der Rafisa Dietikon
zh.rafisa.org-172.16.0.0/12
| VLAN Name | Kürzel | Funktion | VID | IP-Adresse | FW-Interface-Name | DHCP-Server |
|---|---|---|---|---|---|---|
| VLAN Management | 01 | |||||
| VLAN01 | MGMT | Manage-ment | 01 | 172.16.1.0/24 | VLAN01_MGMT | ❌ |
| VLAN Server | 10-19 | |||||
| VLAN10 | SRVAUTH | Server Authentifi-zierung | 10 | 172.16.10.0/24 | VLAN10_SRV-AUTH | ❌ |
| VLAN14 | SRVEMPL | Server Ausbildner | 14 | 172.16.14.0/24 | VLAN14_SRV-EMPL | ❌ |
| VLAN15 | SRVLEARN | Server Lernende | 15 | 172.16.15.0/24 | VLAN15_SRV-LEARN | ❌ |
| VLAN Clients | 20-29 | |||||
| VLAN21 | CLEMPL | Clients Ausbildner | 21 | 172.16.21.0/24 | VLAN21_CL-EMPL | ✔️ |
| VLAN22 | CLLEARN | Clients Lernende | 22 | 172.16.22.0/24 | VLAN22_CL-LEARN | ✔️ |
| VLAN23 | CLGUEST | Clients Guest (WLAN) | 23 | 172.16.23.0/24 | VLAN23_CL-GUEST | ✔️ |
| VLAN Drucker | 40 | |||||
| VLAN40 | LP | Drucker | 40 | 172.16.40.0/24 | VLAN40_LP | ❌ |
| VLAN Labor | 50-59 | |||||
| VLAN51 | LAB01 | Labor 01 | 51 | 172.16.51.0/24 | VLAN51_LAB01 | ✔️ |
| VLAN52 | LAB02 | Labor 02 | 52 | 172.16.52.0/24 | VLAN52_LAB02 | ✔️ |
| VLAN53 | LAB03 | Labor 03 | 53 | 172.16.53.0/24 | VLAN53_LAB03 | ✔️ |
| VLAN54 | LAB04 | Labor 04 | 54 | 172.16.54.0/24 | VLAN54_LAB04 | ✔️ |
| VLAN55 | LAB05 | Labor 05 | 55 | 172.16.55.0/24 | VLAN55_LAB05 | ✔️ |
Tabelle 7: zh.rafisa.org-172.16.0.0/12
L3-Diagramm des Rafisa-Netzwerkes
Als Gateway haben die Geräte das Firewall VLAN-Interface des adäquaten Subnetzes, für das VLAN01-MGMT also z.B. 172.16.1.1/24. Der Gateway für die IPA-Testumgebung ist deshalb 172.16.53.1/24. Die Firewall stellt ausser dem Gateway für den Webzugang einen DHCP-Dienst zur Bereitschaft, über welchen IP-Adressen aus dem stimmigen Subnetz, die Gateway-IP sowohl die IP-Adressen der DNS-Server verteilt werden. Alle im L3-Diagramm festgehaltenen Systeme verfügen über statische IP-Adressen.
| FQDN | IP-Adresse | OS | Services | Service-Team | Owner |
|---|---|---|---|---|---|
| Server | |||||
| prox-zh-ruga-01.zh.rafisa.org | 172.16.1.21/24 | Proxmox VE | Virtualisierungsplattform | Team Server Services | RS |
| prox-zh-ruga-02.zh.rafisa.org | 172.16.1.22/24 | Proxmox VE | Virtualisierungsplattform | Team Server Services | RS |
| dc-zh-ruga-02.zh.rafisa.org | 172.16.10.22/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS |
| dc-zh-ruga-04.zh.rafisa.org | 172.16.10.24/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS |
| fs-zh-ruga-01.zh.rafisa.org | 172.16.14.21/24 | Windows Server 2019 | Fileserver Employees | Team Server Services | RS |
| fs-zh-ruga-01.zh.rafisa.org | 172.16.15.21/24 | Windows Server 2019 | Fileserver Learners | Team Server Services | RS |
| bkp-zh-r02b-01.zh.rafisa.org | 172.16.1.100/24 | Ubuntu 20.04 LTS | Backup Server Rafisa | Team Network Services | ER |
| uni-zh-ruga-01.zh.rafisa.org | 172.16.1.30/24 | Ubuntu 20.04 LTS | Ubiquiti WLAN-Controller | Team Network Services | ER |
| ap-zh-01-05.zh.rafisa.org | 172.16.1.31-35/24 | AirOS | AP, WPA-Enterprise Radius Auth | Team Network Services | ER |
| Firewall | |||||
| fw-zh-ruga-01.zh.rafisa.org | VLAN 172.16.1.1/24 WAN 46.140.45.118 | pfSense (BSD) | VLAN-Routing, Filtering, VPN Concentrator, DHCP | Team Network Services | ER |
Tabelle 8: L3-Diagramm des Rafisa Netzwerks
Beschreibung der Firmenstandards für das Rafisa Standard-Image
Die Firmenstandards für das Standardimage können dem Rafisa Wiki entnommen werden (siehe Anhang):
Partitionierung
Nur eine Datenpartition C:\ mit maximaler Grösse für Windows und Programme.
Software
| Software | Standardimage | Notebook-Image | Default |
|---|---|---|---|
| 7-zip | ✔️ | ✔️ | |
| Acrobat Reader | ✔️ | ✔️ | |
| Brave (Default) | ✔️ | ✔️ | html |
| Diagrams.net-Client | ✔️ | ✔️ | |
| FileZilla | ✔️ | ✔️ | |
| FOG-Smartinstaller | ✔️ | ✔️ | |
| GitHub | ✔️ | ✔️ | |
| Google Chrome | ✔️ | ✔️ | |
| LibreOffice-Suite | ✔️ | ✔️ | |
| Microsoft Office Professional Plus 2019 | ✔️ | ✔️ | docx, xslx, potx, mailto |
| Microsoft Teams | ✔️ | ✔️ | |
| Microsoft Visio 2019 Professional | ✔️ | ✔️ | |
| Mozilla Firefox | ✔️ | ✔️ | |
| Notepad++ | ✔️ | ✔️ | |
| OneDrive (Business deinstallieren, 365 installieren) | ✔️ | ✔️ | |
| OpenVPN (nur auf Notebooks) | ❌ | ✔️ | |
| PowerShell 7 x64 | ✔️ | ✔️ | |
| Putty | ✔️ | ✔️ | |
| Rufus | ✔️ | ✔️ | |
| VirtualBox | ✔️ | ✔️ | |
| VLC Media Player | ✔️ | ✔️ | Video + Audio |
| Win32 Disk Imager | ✔️ | ✔️ | |
| WinSCP | ✔️ | ✔️ |
Tabelle 9: Software
Anpassungen
Applikationen
| Applikation | Anpassung |
|---|---|
| Teams | Kein Autostart |
| Explorer | Dateinamenerweiterungen einblenden: Im Menu Ansicht des Explorers Dateinamenerweiterungen markieren |
| Remote Desktop |  Remotedesktopverbindung zulassen |
| Windows Taskbar | Als Icons: Windows Explorer, Brave, Word, Excel, Powerpoint, Outlook |
| Windows Startmenu | Als Kacheln eingeblendet: Word, Excel, Powerpoint, Outlook, Teams, Visio, Brave, draw.io, Windows Explorer |
Tabelle 10: Applikationen
Wallpaper
Es wird nach C:\Windows\Web\Wallpaper heruntergeladen und dann mit dem Desktop verknüpft.
Standardbenutzer
Auf jedem System muss der Nutzer sysadmin vorhanden sein. Der Benutzer soll der Gruppe Administratoren angehören.
Beschreibung der Firmenstandards für das Namenskonzept
Benutzer
Benutzernamen setzen sich zusammen aus dem ersten Buchstaben des Vornamens plus der Nachnamen, z.B. l.cotar. Sollten sich bei neuen Nutzern gleichlautende Benutzernamen ergeben, wird die Anzahl Buchstaben des Vornamenkürzels um 1 erhöht. Bei identischen Vor- und Nachnamen wird das Benutzerkürzel um eine fortlaufende Nummer, beginnend bei 01 ergänzt.
Beispiele:
- h.muster Hans Muster
- he.muster Hedwig Muster
- her.muster Herta Muster
- h.muster01 Hans Muster
Geräte
Der Gerätename setzt sich zusammen aus einem Kürzel für die Funktion, dem Kürzel für den physikalischen Standort sowie einer fortlaufenden Nummer, beginnend bei 01.
Beispiele:
- dc-zh-ruga-01
- sw-zh-r02a-03
- Kürzel für die Funktionsbezeichnungen
| Kürzel | Funktion |
|---|---|
| bkp | Backup Server |
| dc | Domain Controller |
| ds | Deployment Server |
| fw | Firewall |
| nb | Notebook |
| pc | PC |
| prox | Proxmox VE Server |
| sw | Switch |
Tabelle 11: Kürzel der Funktionen
Physikalische Standorte
Der physikalische Standort setzt sich zusammen aus dem Kürzel für den Standort sowie einer internen Raumangabe. Bei Geräten, welche in einem Rack stehen, werden anstelle der Raumangabe das Kürzel für das Rack angegeben.
Beispiele:
- zh-ruga
- zh-201
<HTML><ol start=„2“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Kürzel für die Standorte<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
| Kürzel | Standortbezeichnung |
|---|---|
| be | Bern |
| fr | Fribourg |
| zg | Zug |
| zh | Zürich |
Tabelle 12: Kürzel der Standorte
<HTML><ol start=„3“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Kürzel für die internen Räume<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
| Dietikon | |
|---|---|
| Kürzel | Ort |
| 200 | Raum 200 im 2. Stock |
| 201 | Raum 101 im 2. Stock |
Tabelle 13: Kürzel der internen Räume
<HTML><ol start=„4“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Kürzel für Racks<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
| Dietikon | |
|---|---|
| Kürzel | Racknummer |
| ruga | Rack A im Untergeschoss |
| rugb | Rack B im Untergeschoss |
| r02a | Rack A im 2. Stock |
| r02b | Rack B im 2. Stock |
| r03a | Rack A im 3. Stock |
| r03b | Rack B im 3. Stock |
| r03c | Rack C im 3. Stock |
| r03d | Rack D im 3. Stock |
| r04a | Rack A im 4. Stock |
Tabelle 14: Kürzel der Racks
Die Deploymentlösung FOG Project
Was ist FOG
FOG ist eine kostenlose Open-Source-Computer-Imaging-Lösung auf Linux-Basis, die auf verschiedene Versionen von Windows (XP, Vista, 7, 8/8.1, 10), Linux und Mac OSX anwendbar ist. Sie kombiniert einige Open Source-Tools und eine PHP-basierte Website-Oberfläche. FOG verwendet keine Bootdisketten oder CDs, alles erfolgt über TFTP und PXE. Der PC bootet über PXE und lädt automatisch einen kleinen Linux-Client herunter, der die ganze Arbeit des Imaging des Computers erledigt.
Mit FOG sind viele Netzwerktreiber auch im Kernel des Clients (normales Linux) integriert, sodass man sich keine Gedanken über Netzwerktreiber machen muss (es sei denn, es gibt keine Kernelunterstützung). FOG unterstützt auch das Importieren von Images von einem Computer mit einer 80-GB-Partition auf einen Computer mit einer 40-GB-Festplatte, sofern die Daten weniger als 40 GB betragen. FOG unterstützt Multicast, d.h. man kann im selben Stream mehrere PCs gleichzeitig aufsetzten. (3)
Features
FOG ist nicht nur eine Imaging-Lösung, sondern auch eine Imaging-/Klon- und Netzwerkverwaltungslösung.
- PXE-Boot-Umgebung (DHCP, iPXE, TFTP, schneller HTTP-Download von grossen Boot-Dateien wie Kernel und initrd)
- Imaging von Windows (XP, Vista, 7, 8/8.1, 10), Linux und Mac OS X
- Partitionen, volle Festplatte, mehrere Festplatten, grössenveränderbar, raw
- Snapins zum Installieren von Software und Ausführen von Jobs/Skripten auf den Clients
- Drucker-Verwaltung
- Hostname ändern und Domäne beitreten
- Verfolgen von Benutzerzugriffen auf Computern, automatisches Abmelden und Herunterfahren bei Leerlaufzeitüberschreitungen
- Virenschutz
- Löschen von Festplatten
- Gelöschte Dateien wiederherstellen
- Suche nach fehlerhaften Blöcken (4)
Unterschiede zwischen WDS/MDT und FOG
In einer früheren IPA wurde eine Windows-Bereitstellungsumgebung basierend auf Windows Deployment Services (WDS) eingerichtet. Der Einrichtungsprozess wird vom Microsoft Deployment Toolkit (MDT) verwaltet. Man verwendet MDT, um die Phase der Windows-Installation über die Standardwerte in der Antwortdatei zu steuern.
Der Hauptunterschied zwischen WDS/MDT und FOG besteht darin, dass es sich bei FOG um ein Block-Imaging-Tool (BIT), bei WDS/MDT um ein File-Level-Imaging-Tool (FLIT) handelt. Bei einem BIT werden Datenblöcke von einem lokalen Speicher auf einen Netzwerk-Speicher (Capturing) und zurück (Deploying) kopiert. Dabei werden zumeist fertige, vorweg vorbereitete Betriebssystemimages verteilt. Bei einem FLIT werden Files vom Deploymentsystem zum Zielcomputer kopiert, aus welchen das Betriebssystem auf dem Zielcomputer erst aufgebaut wird. Bei WDS/MDT hat man nach Abschluss des Building-Prozesses mehr Perspektiven, das Image über alternative Verteilprozesse zu verändern und anzupassen. Bei FOG wird ein fertiges FAT-Image verteilt, das sich nachträglich bloss bedingt noch verändern lässt. Aus diesem Grund ist die FOG-Lösung wesentlich schneller als WDS/MDT. Währenddessen der Aufbau eines Betriebssystems unter WDS/MDT gerne 60min dauern kann, ist das FOG Image innerhalb eines schnellen Netzwerks überaus zügig verteilt und betriebsbereit. Der für die Rafisa wichtigste Unterschied besteht allerdings darin, dass sich über WDS/MDT allein Windows-Images verteilen lassen (es ist zwar möglich, Linux zu verteilen, man verliert aber sämtliche Benefits der Lösung), die FOG-Lösung genauso für übrige Betriebssysteme offen ist. (5)
| Vergleichsgrösse | WDS/MDT | FOG |
|---|---|---|
| Übertragene Daten | Files | Datenblöcke |
| Geschwindigkeit | gering, da Betriebssystem auf dem Zielhost aufgebaut wird | hoch |
| Kontrollmöglichkeiten | auch nach dem Imagingprozess hoch | gering (Nachinstallieren von Software durch Snapins) |
| Unterstützte Client OS's | Windows | Windows, Linux, Mac |
Tabelle 15: Vergleichsgrösse
Planen
Lösungsvarianten
Bei IT-Projekten gibt es oft verschiedene Lösungen zur Erreichung der Projektvorgaben.
Einrichten der Testumgebung
Für eine funktionierende Lösung müssen in der Testumgebung nachstehende Netzwerk-Dienste zur Bereitschaft gestellt werden:
- DHCP (mit den für das Deployment nötigen Bereichsoptionen)
- DNS (mit A-Records für alle L3-Geräte der Testumgebung)
- TFTP (zum Laden des FOG Boot-Images über PXE)
- AD
Grundsätzlich können die häufigsten Dienste von verschiedenartigen Systemen in der Testumgebung zur Auswahl gestellt werden:
| System | DHCP | DNS | TFTP | AD |
|---|---|---|---|---|
| Windows Server 2019 | möglich (DHCP-Server) | möglich (DNS-Server) | möglich (Windows-Bereitstellungsdienste) | möglich (Active-Directory-Domänendienste) |
| Ubuntu Server | möglich (isc-dhcp-server) | möglich (bind9) | möglich (tftpd-hpa) | möglich (samba) |
| pfSense Firewall | möglich | nicht möglich (nur DNS-Forwarder) | nichts möglich | nicht möglich |
Tabelle 16: Dienste
Für das Subnetting der Testumgebung existieren nicht viele Varianten. Es liegt nahe, das Labornetz 172.16.53.0/24 zu verwenden. Alle sonstigen Subnetze müssten zudem über den Gateway 172.16.53.1 geroutet werden, was lediglich weiteren Aufwand (z.B. Einrichten eines Servers als Router) mit sich bringen würde.
Versionen der Betriebssysteme
Windows Server 2019 (6)
| Editionen | Beschreibung | Lizenzmodell CAL | CAL Anforderung |
|---|---|---|---|
| WinSRV2019 Datacenter | Für stark virtualisierte Rechenzentrums- & Cloudumgebung | Kern-basiert | Windows Server 2019 CAL |
| WinSRV2019 Standard | Für physische oder minimal virtualisierte Umgebungen | Kern-basiert | Windows Server 2019 CAL |
| WinSRV2019 Essentials | Für kleinere Unternehmen mit bis zu 25 Benutzern & 50 Geräten | Server-basiert | Keine CAL erforderlich |
Tabelle 17: Windows Server 2019 Versionen
- Windows Server 2019 Essentials
Die einfachste und günstigste Version des Betriebssystems ist die Windows Server Essentials Version. Während der Funktionsumfang von Standard und Datacenter sehr ähnlich ist, hat Microsoft die Essentials Variante mit einem reduzierten Funktionsumfang und einer kleinen Zahl von möglichen Lizensierungen ausgestattet.
<HTML><ol start=„2“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Windows Server 2019 Standard<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Der Funktionsumfang der Standard-Variante ist bereits deutlich grösser als der der Essentials Version. Es können mit der Standard-Version zwei Virtualisierungsrechte für zwei virtuelle Maschinen genutzt werden. Die Standard-Version bietet die Möglichkeit weitere Rechte dazu zu kaufen.
<HTML><ol start=„3“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Das Windows Server 2019 Datacenter<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Mit dem höheren Preis für das Datacenter sind im Gegensatz zur Standard-Version auch unbegrenzte Visualisierungsrechte enthalten, womit sich diese Version vor allem an grössere Unternehmen richtet, die besonders hohe Anforderungen an ihre IT-Systeme und einen hohen Virtualisierungsbedarf haben.
Ubuntu Server 20.04
Beim Betriebssystem Ubuntu müssen in zwei Bereichen Entscheidungen getroffen werden:
- Desktop-Version vs. Server-Version
- LTS vs. Standard-Releases
- Desktop-Version vs. Server-Version
Die Desktop-Version verfügt über eine vollständige grafische Oberfläche, die Server-Version lediglich über die Kommandozeile. Die Serverversion braucht aufgrund dessen wesentlich weniger Ressourcen. Die sich anschliessende Tabelle zeigt die Unterschiede: (7)
| Empfohlene Systemvoraussetzungen für Ubuntu 18.04 (für x86-Systeme) | ||
|---|---|---|
| Hardware | Desktop-Edition (mit Desktop-Umgebung) | Server-Edition (mit CLI) |
| Prozessor | 2 GHz Doppelkernprozessor | 1,2 GHz/1200 MHz |
| RAM | 2GB | 256MB |
| GPU | VGA ab 1024 × 768 Bildschirmauflösung | Grafikkarte und Monitor ab 640 × 480 Pixel |
| Datenspeicher | 25GB | 1,5GB |
<HTML><ol start=„2“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>LTS vs. Standard-Releases<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
LTS steht für “Long-Term-Support”. LTS-Releases waren für Geschäftsanwender gedacht, um ihnen eine stabile Plattform zu bieten, die sie einrichten können und die über Jahre hinweg mit Sicherheitsupdates versorgt wird. Allerdings produziert Ubuntu gleichwohl sämtliche 6 Monate Updates. Traditionell hielten sich Durchschnittsanwender an die alle 6 Monate erscheinenden Upgrades. Diese waren der Standardweg, um Ubuntu zu bekommen, bevor die LTS-Versionen publiziert wurden. Selbst nach den ersten LTS-Versionen bot jedes Upgrade von Ubuntu überzeugende Leistungsmerkmale und essentielle moderne Software-Versionen, was sie für durchschnittliche Desktop-Benutzer interessant machte.
Virtuelle Hardwareressourcen und Partitionierung
Beim Erstellen der Windows 2019 Server-VM auf dem Proxmox-Server müssen Entscheidungen zu den Hardware-Ressourcen wie auch zur Partitionierung getroffen werden.
Bei den Ressourcen existieren viele Varianten, die virtuellen Gerätschaften zu emulieren:
| Ressource | Varianten |
|---|---|
| Harddisk Bus/Device | * IDE * SATA * VirtIO Block * SCSI |
| Disk-Format | * Raw Disk Image * QEMU Image Format * VMWare Image Format |
| Netzwerkadapter | * Intel E1000 * VirtIO * Realtek RTL8139 * VMware |
| CPU | Variabel |
| Memory | Variabel |
| Grösse der Harddisk (Ubuntu Server) | Variable Grösse * Geführt-vollständige Festplatte verwenden * Geführt-gesamte Platte verwenden und LVM einrichten * Geführt-gesamte Platte mit verschlüsseltem LVM * Manuell |
Tabelle 18: Ressourcen und Varianten
- Harddisk Bus/Device
- IDE: Bietet sehr gute Unterstützung durch alle Betriebssysteme. Es ist nicht sehr performant und unterstützt nur 4 Devices.
- SATA: Bietet sehr gute Unterstützung durch Betriebssysteme. Ist performant und bietet Unterstützung für 6 Device
- VirtIO: Bis zu 14 Devices. Benötigt unter Windows spezielle Guest-Treiber, abgelöst durch SCSI.
- SCSI: Sehr performant, bis 14 Devices. Benötigt unter Windows spezielle Guest-Treiber
<HTML><ol start=„2“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Disk Format<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
- Das QEMU-Image-Format ist ein Copy-on-Write-Format, das Snapshots und Thin Provisioning des Festplatten-Images gestattet.
- Das Raw-Disk-Image ist ein Bit-zu-Bit-Image einer Festplatte. Dieses Format unterstützt kein Thin Provisioning oder keine Snapshots. Es kann abgesehen davon bis zu 10% schneller sein als das QEMU-Image-Format.
- Das VMware-Image-Format macht nur für den VMWare-Export Sinn.
<HTML><ol start=„3“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>CPU<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Wie im Ist-Zustand festgehalten, verfügt der physische Server, der auf dem Proxmox VE eingerichtet ist, über 1 Socket und 4 Cores mit je zwei Threads, d.h. über 8 logische CPUs. Um eine bessere Auslastung der Ressourcen zu erhalten, können den VMs mehr CPUs zugeordnet werden, als physisch vorhanden sind. Man nennt das Überbuchen. Man muss aber berücksichtigen, dass auch der Proxmox-Server noch CPU-Ressourcen benötigt.
<HTML><ol start=„4“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Memory<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Der Proxmox-Server verfügt über 16GB RAM. Auch hier muss man beachten, dass nicht alles RAM den VMs zugesichert wird, da der Proxmox-Server auch noch Memory braucht.
<HTML><ol start=„5“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Partitionierung<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Für die Partitionierung des Windows 2019 Servers muss entschieden werden, ob ausschliesslich eine Windows-Partition oder noch übrige Partitionen erstellt werden. Bei Ubuntu kann die Partitionierung automatisch oder manuell vorgenommen werden. Es muss ebenso entschieden werden, ob man eine grosse Root-Partition macht, oder den Linux-Verzeichnissen eigene Partitionen zuteilt.
AD-OU-Struktur
Für das Erfassen der geforderten Benutzer und Rechner können die AD-Standardcontainer Users und Computers genutzt werden. Ausserhalb von Testumgebungen besteht das Ziel des AD-Designs nichtsdestotrotz im Entwurf einer Architektur, die die Verwaltung der Objekte innerhalb eines Betriebs möglichst unterstützt.
In der Rafisa hat sich als Standard folgende Gliederung herausgebildet:
Einrichten des FOG-Servers
Welche Features werden benötigt (Varianten, z.B. max/min)
Im Kapitel Informieren sind die Features von FOG aufgezeigt worden (Maximalvariante). In der folgenden Tabelle wird gezeigt, welche Features für die Erfüllung des Auftrages tatsächlich notwendig sind. (8)
| Feature | Für Auftrag nötig | Kommentar |
|---|---|---|
| PXE-Boot-Umgebung | ja | Wird benötigt, um die Clients über das Netzwerk booten zu können |
| Imaging von Windows, Linux und Mac OS X | ja | Wird für Windows-Image benötigt |
| Partitionen, volle Festplatte, mehrere Festplatten | ja/nein | Das Imaging wird nur von vollen Festplatten benötigt. Es werden keine Partitionsimages benötigt |
| Snapins | ja | Wird zur nachträglichen Installation von OpenVPN benötigt. |
| Drucker-Verwaltung | nein | Möglichkeit besteht, Printerdefinitionen mit Hosts zu verbinden und automatisch Printer installieren zu lassen. |
| Hostname ändern und Domäne beitreten | ja | Wird für den automatischen Domänenbeitritt benötigt. |
| Monitoring von Benutzerzugriffen | nein | Da besitzen wir eigene Tools |
| Virenschutz | nein | Verlangsamt das Erstellen von Images, eigene Tools |
| Löschen von Festplatten | nein | Da besitzen wir eigene Tools |
| Gelöschte Dateien wiederherstellen | nein | Da besitzen wir eigene Tools |
| Suche nach fehlerhaften Blöcken | nein | Da besitzen wir eigene Tools |
Erstellen des Windows-Standard-Images
Sysprep vs. Fat-Image mit integrierten Treibern
Es existieren zwei Möglichkeiten, ein Windows-Image für die Verteilung mit FOG zu entwerfen. Man kann Windows mit allen zwingenden Anwendungen und allen Vorgaben auf einem PC einrichten und anschliessend hiervon eine Abbilddatei anlegen (Fat-Image). Als zweite Möglichkeit lässt sich ein Masterimage im sogenannten Audit Mode erzeugen. Nach Abschluss aller gewählten Installationen und Konfigurationen im Audit-Modus, werden sämtliche eindeutigen Systeminformationen automatisch aus der Windows-Installation mittels Sysprep entfernt. (9)
Sysprep setzt folgende Einstellungen zurück:
- Alle Einträge in der Ereignisanzeige
- Alle Wiederherstellungspunkte
- es deaktiviert das Konto des lokalen Administrators und löscht sein Profil
- Security Identifier (SID)
- Plug- und Play-Gerätetreiber, die während der Installation hinzugefügt wurden
Nach der Verteilung des Images beginnt das frisch verteilte System danach im Windows-Konfigurations-Schritt „specialize“. Die Windows Konfigurations-Schritte sind Phasen, die innerhalb einer Windows-Installation durchlaufen werden. (10)
MBR vs. GPT-Image
MBR: Master Boot Record
Der MBR befindet sich im Bootsektor und er beinhaltet Informationen über die Typen der Partitionen und auch den Code, der beim Booten des Betriebssystems des Computers gebraucht, wird. Er hat eine Grösse von 512 Byte.
GPT: GUID Partition Table
GPT ist der Nachfolger des MBR. GPT legt ebenfalls die Partitionstabellen auf der Festplatte fest.
MBR vs. GPT:
In der folgenden Tabelle finden sich die wichtigsten Unterschiede zwischen MBR und GPT. (11)
| Point of Comparison | MBR-Master Boot Record | GPT-GUID Partition Table |
|---|---|---|
| Number of Primary Partitions | 4 | Up to 128 for Windows OS. |
| Maximum Partition size | 2 TB | 18 exabytes (18 billion gigabytes) |
| Maximum hard drive size | 2 TB | 18 exabytes (18 billion gigabytes) |
| Security | No check sum on data sector | CRC values are used to ensure data security. Back up GUID partition table. |
| Specifications | BIOS | UEFI |
| Partition Name | Is stored in the partition | Has a unique GUID and a 36 character name |
| Multiple boot supported | Poor support | Boot loader entries are in different partitions |
| Operating System Support | Windows 7 and other older versions like Windows 95/98, Windows XP etc. | All major OS like MAC and latest versions of Windows like Windows 10. |
| Data recovery | Data cannot be recovered easily. | Data can be easily recovered. |
| Data Corruption | No way to detect corruption of data. | Easy to detect |
| Method of Partition Addressing | CHS (Cylinder Head Cycle) or LBS (Logical Block Addressing) | LBA is the only method of addressing partitions. |
| Size | 512 bytes | 512 bytes per LBA. Each partition entry is 128 bytes. |
| Partition type code | 1 byte code | 16 byte GUID is used. |
| Stability | Less stable as compared to GPT | Offers more security. |
| Bootable Version of OS | Boots 32 bit operating system | Boots 64 bit operating system |
| Storage | Only upto 2TB capacity. Disk size > 2TB is marked as unallocated and cannot be used. | Disk capacity of 9.44 million TB |
| Performance | Lower in performance compared to GPT. | Offers superior performance if UEFI boot is supported. |
Tabelle 19: MBR vs. GPT
Verschlüsselte vs. unverschlüsselte Kommunikation
Es besteht die Möglichkeit, den WEB Zugang von FOG über HTTP mit SSL (HTTPS) zu verschlüsseln.
Dieser Zugang wird für drei Funktionen verwendet:
- Zugang zum Web-Administrationsinterface
- Das FOG-Boot-Image, das über PXE aufgeladen wird, kann das Image von FOG-Server verschlüsselt oder unverschlüsselt erhalten
- Der FOG-Client, der als Anwendung unter Windows eingerichtet ist, kann sich verschlüsselt oder unverschlüsselt mit dem FOG Server verbinden
Bei der Entscheidung für die Kryptographie muss man berücksichtigen, dass Verschlüsselung mit einem höheren Aufwand an den Prozessor und hiermit mit einer ein bisschen geringeren Geschwindigkeit verbunden ist.
Unicast vs. Multicast-Deployment
Multicast stellt in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe dar und ist daher eine Form der Mehrpunktverbindung. Unicast stellt in der Telekommunikation die Adressierung einer Nachricht an einen einzigen Empfänger dar.
Multicast bietet beim Deployment den grossen Vorteil, dass eine Image Datei im Netzwerk nur einmal übertragen werden muss. Dabei melden sich die Clients alle bei der Multicast Session an. Clients, welche sich inmitten der Multicast Übertragung dazugesellen, müssen am Ende der Übertragung den ersten Teil der Übertragung mitgeteilt bekommen. (12)
Ich habe mit einem Flussdiagramm versucht, ein Modell für den Deployment Prozess in unserem Betrieb zu entwickeln. Im Flussdiagramm sieht man auch, wann es sinnvoll ist, Multicast bzw. Unicast zu verwenden.
Backup und Restore
Backupart
BackupPC bietet verschiedene Backuparten an:
- Backup von SMB-Shares,
- File-Backup von Serversystemen
- Image Backup von Proxmox-VMs
- Backup von Datenbank-Systemen
- Backup der Konfigurationsdateien von Switches und Firewalls
Für das Backup meiner Server kommt File-Backup und Image-Backup infrage.
Funktionsweise File-Backup: BackupPC startet zur gewünschten Zeit den rsync-Befehl und kopiert alle gewünschten Files eines Servers. Wenn man als Zielverzeichnis / angibt, wird der gesamte Server kopiert.
Funktionsweise Image-Backup: Zur gewünschten Zeit loggt sich BackupPC auf dem Proxmox-Server ein und führt mit dem Befehl vzdump ein Image-Backup der VMs durch. (13)
| File-Backup | Image-Backup | |
|---|---|---|
| Technologie | rsync | vzdump |
| Backup-OS | nur Linux | Linux und Windows |
| Platzbedarf auf Backupserver | gering, da Kompression möglich | hoch, da Kompressionseffekt gering bei Imagefile |
| Inkrementelles Backup | möglich | nicht möglich, da nur ein Image-File |
| Full Metal Restore | möglich, aber kompliziert | möglich, Image muss nur auf Proxmox wiederhergestellt und dann importiert werden |
| Datenmenge für Backup | entspricht Serverdaten | entspricht etwa Serverdaten |
| Datenmenge auf Backup-Server | bis 80% Kompression | entspricht etwa Serverdaten |
| Transferraten | bis 35MB/s (Erfahrungswert) | bis ca. 10MB/s (Erfahrungswert) |
Abbildung 9: Planung File-Backup vs. Image-Backup
Entscheiden
Lösungsvarianten
Einrichten der Testumgebung
Subnetze:
Für das Subnetting der Testumgebung existieren nicht viele Varianten. Es liegt nahe, das Labornetz 172.16.53.0/24 zu verwenden. Alle sonstigen Subnetze müssten über den Gateway 172.16.53.1 geroutet werden, was lediglich weiteren Aufwand (z.B. Einrichten eines Servers als Router) mit sich bringen würde.
DHCP:
Ich habe mich dafür entschieden, dass ich den DHCP-Dienst auf dem Windows Server 2019 installiere. Es ist sinnvoll, wenn man eine Windows Domäne einrichtet, die Funktionen AD, DNS und DHCP zusammen zu haben, da sich diese Dienste ergänzen. Beim DHCP darf nicht vergessen werden, folgende Optionen für den PXE-Boot hinzuzufügen.
Es geht um die Optionen Nr. „066 Boot Server Hostname“ und die Nr. „067 Startdatei“.
Die zwei Einstellungen müssen ebenfalls noch gemacht werden.
066 Boot Server Hostname: 172.16.53.102
067 Startdatei: undionliy.kpxe
DNS:
Der DNS und das AD gehören zwingend zusammen und werden deshalb auf dem Windows Server 2019 installiert und konfiguriert.
TFTP:
Das TFTP möchte ich auf dem Ubuntu Server installiert haben, weil der TFTP Server automatisch mit der FOG-Umgebung installiert wird.
AD:
Das AD könnte zwar auch als Samba4 Server auf Ubuntu installiert werden. Da in der Testumgebung ein Windows Server 2019 vorhanden ist, wäre das viel zu kompliziert.
Die folgende Tabelle zeigt meine Entscheidung für die Netzwerkdienste:
| System | DHCP | DNS | TFTP | AD |
|---|---|---|---|---|
| Windows Server 2019 | möglich (DHCP-Server) | möglich (DNS-Server) | möglich (Windows-Bereitstellungsdienste) | möglich (Active-Directory-Domänendienste) |
| Ubuntu Server | möglich (isc-dhcp-server) | möglich (bind9) | möglich (tftpd-hpa) | möglich (samba) |
| pfSense Firewall | möglich | nicht möglich (nur DNS-Forwarder) | nicht möglich | nicht möglich |
Tabelle 20: Entscheid Dienste
Win2019 Server
Version
- Windows Server 2019 Standard
Ich habe beschlossen Windows Server 2019 Standard zu installieren, weil diese Version bereits auf allen Servern der Rafisa verwendet wird und ich mich damit gut auskenne.
| Editionen | Beschreibung | Lizenzmodell CAL | CAL Anforderung |
|---|---|---|---|
| WinSRV2019 Datacenter | Für stark virtualisierte Rechenzentrums- & Cloudumgebung | Kern-basiert | Windows Server 2019 CAL |
| WinSRV2019 Standard | Für physische oder minimal virtualisierte Umgebungen | Kern-basiert | Windows Server 2019 CAL |
| WinSRV2019 Essentials | Für kleinere Unternehmen mit bis zu 25 Benutzern & 50 Geräten | Server-basiert | Keine CAL erforderlich |
Tabelle 21: Entscheid Windows Server 2019 Versionen
Virtuelle Hardwareressourcen und Partitionierung
Die folgende Tabelle zeigt meine Entscheidung für die Hardwareressourcen:
| Ressource | Varianten | Begründung |
|---|---|---|
| Harddisk Bus/Device | * IDE * SATA * VirtIO Block * SCSI | Ich habe mich für SATA entschieden, da das IDE zu langsam ist und VirtIO Block & SCSI extra Treiber brauchen. |
| Disk-Format | * Raw Disk Image * QEMU Image Format * VMWare Image Format | Der Grund, warum ich mich für das QEMU-Image-Format entschieden habe, ist, dass das QEMU-Image-Format Snapshots und Thin Provisioning erlaubt. |
| Grösse der Harddisk | 100GB Partitionieren: * C:\ 80GB * D:\ 20GB | Ich werde die Partitionierung möglichst klein halten, um auf dem Backup Server Platz zu sparen (BackupPC) |
| CPU Sockets | 1 Sockets | |
| CPU-Cores | 4 Cores | |
| Grösse Memory | 5GB | Der Windows Server 2019 benötigt genug Memory, da er ansonsten langsam sein wird. |
| Netzwerkadapter | * Intel E1000 * VirtIO * Realtek RTL8139 * VMware | Der Intel E1000 ist der am besten unterstützte Adapter für VM’s |
Tabelle 22: Entscheid Ressourcen und Varianten
AD-OU-Struktur
Die folgende Abbildung zeigt meine Entscheidung für die OU-Struktur:
Die OU-Struktur ist möglichst ähnlich der Standardstruktur der Rafisa.
OU-IPA
IPA_Computers
IPA_Gruppen
IPA_Users
Einrichten des Ubuntu Servers
Version
Meinen Entscheid fällt auf die Version Ubuntu 20.04 LTS Server, da ich keine GUI benötige, und der Server weniger Ressourcen braucht. Zudem ist es wichtig, für einen Server eine möglichst stabile Version zu haben.
Virtuelle Hardwareressourcen, Partitionierung
Die folgende Tabelle zeigt meine Entscheidung für die Hardwareressourcen:
| Ressource | Varianten | Begründung |
|---|---|---|
| Harddisk Bus/Device | * IDE * SATA * VirtIO Block * SCSI | Ich habe mich für SATA entschieden, da das IDE zu langsam ist und VirtIO Block & SCSI extra Treiber brauchen. |
| Disk-Format | * Raw Disk Image * QEMU Image Format * VMWare Image Format | Der Grund, warum ich mich für das QEMU-Image-Format entschieden habe, ist, dass das QEMU-Image-Format Snapshots und Thin Provisioning erlaubt. |
| Grösse der Harddisk | 100GB * Geführt-vollständige Festplatte verwenden * Geführt-gesamte Platte verwenden und LVM einrichten * Geführt-gesamte Platte mit verschlüsseltem LVM * Manuell | Ich werde 100GB brauchen, da ich sicher ein Windows 10 Enterprise N Image und eventuell noch ein zweites Windows 10 FAT-Image benötige, welches auch etwa 30 GB gross sein wird. |
| CPU Sockets | 1 Sockets | |
| CPU-Cores | 4 Cores | |
| Grösse Memory | 5GB | Der Ubuntu Server 20.04 benötigt genug Memory, da er ansonsten extrem langsam ist. |
| Netzwerkadapter | * Intel E1000 * VirtIO * Realtek RTL8139 * VMware | Der Intel E1000 ist der am besten unterstützte Adapter für VM’s |
Tabelle 23: Entscheid Virtuelle Hardwareressourcen, Partitionierung
Einrichten des FOG-Servers
Welche Features werden benötigt (Varianten, z.B. max/min)
Im Kapitel Informieren sind die Features von FOG aufgezeigt worden (Maximalvariante). Aus Zeitgründen habe ich beschlossen, FOG in der Minimalvariante zu installieren.
| Feature | Für Auftrag nötig | Begründung |
|---|---|---|
| PXE-Boot-Umgebung | Ja | |
| Imaging von Windows, Linux und Mac OS X | Ja | |
| Snapins | Ja | |
| Hostname ändern und Domäne beitreten | Ja |
Tabelle 24: Features
Erstellen des Windows-Standard-Images
Sysprep vs. Fat-Image mit integrierten Treibern
Das von mir erstellte Image muss auf zwei baugleiche Systeme verteilt werden. Ich habe deshalb entschieden, zunächst ein Masterimage mit Sysprep zu erstellen. Dieses generalisierte Image wird dann, wie im Flussdiagramm bestimmt, mit Unicast auf das erste System verteilt und danach die Treiber installiert. Da nur zwei Computer eingerichtet werden müssen, verzichte ich auf das Erstellen eines FAT-Images mit eingerichteten Treibern.
MBR vs. GPT:
Da die beiden Systeme, auf die ich deployen muss, über GPT-Unterstützung verfügen, möchte ich die Vorteile von GPT nutzen und werde ein GPT-Image erstellen. Für die Produktion können nachträglich MBR-Images erstellt werden.
Verschlüsselte vs. unverschlüsselte Kommunikation
Um einen sicheren Datentransport zu gewährleisten, wird der Zugang zum Webserver mit SSL verschlüsselt.
Backup und Restore
Backupart
Obwohl die Transferraten nur bei etwa ca. 10MB/s liegt, entscheide ich mich dennoch für das Image-Backup. Denn bei dem Image-Backup wird ein Full-Backup erstellt und alle Daten werden gesichert. Ein ganz wichtiger Punkt dabei ist, dass das Image-Backup auf Windows und Linux funktioniert. (13)
| File-Backup | Image-Backup | |
|---|---|---|
| Technologie | rsync | vzdump |
| Backup-OS | nur Linux | Linux und Windows |
| Platzbedarf auf Backupserver | gering, da Kompression möglich | hoch, da Kompressionseffekt gering bei Imagefile |
| Inkrimentelles Backup | möglich | nicht möglich, da nur ein Image-File |
| Full Metal Restore | möglich, aber kompliziert | möglich, Image muss nur auf Proxmox wiederhergestellt und dann importiert werden |
| Datenmenge für Backup | entspricht Serverdaten | entspricht etwa Serverdaten |
| Datenmenge auf Backup-Server | bis 80% Kompression | entspricht etwa Serverdaten |
| Transferraten | bis 35MB/s (Erfahrungswert) | bis ca. 10MB/s (Erfahrungswert) |
Tabelle 25: File-Backup vs. Image-Backup
Rahmenbedingungen
Die folgende Tabelle zeigt meine Entscheidung für die Backup-Rahmenbedingungen:
| Rahmenbedingungen Image-Backup | Hosts | IPA | Vorschlag Produktive Umgebung |
|---|---|---|---|
| Sicherungsperiodizitäten | dc-zh-202-01 | automatisch jede Nacht zwischen 19:30 und 07:00, inkrementelles Backup | nicht in Produktion übernommen |
| ds-zh-202-01 | automatisch jede Nacht zwischen 19:30 und 07:00, inkrementelles Backup | manuell bei Ânderungen, 90 Tage max. | |
| Datenmenge | dc-zh-202-01 | ca. 30GB x 7 = 210GB | nicht in Produktion übernommen |
| ds-zh-202-01 | ca. 40GB (Server + Image) x 7 = 280GB | muss abgeklärt werden, hängt von Anzahl Images ab | |
| Transferzeiten | dc-zh-202-01 | 30GB, 2min pro GB ca. 60min | nicht in Produktion übernommen |
| ds-zh-202-01 | 40GB, 2min pro GB ca. 80min | muss abgeklärt werden, hängt von Anzahl Images ab | |
| Aufbewahrungsfrist | dc-zh-202-01 | bis Ende IPA | nicht in Produktion übernommen |
| ds-zh-202-01 | bis Ende IPA | max. 90 Tage | |
| Applikatorische Vorgaben | BackupPC mit Pre- und Post-Backupscripts | BackupPC mit Pre- und Post-Backupscripts |
Tabelle 26: Rahmenbedingungen für Backup
Namenskonzept
Windows Server:
Den Windows Server 2019 werde ich dc-zh-202-01 nennen. Damit ich mich an das Namenskonzept der Firmenstandards halte.
FOG-Server:
Den Deployment Server werde ich mit ds-zh-202-01 benennen. Damit ich mich an das Namenskonzept der Firmenstandards halte.
Computers:
Die Computer werde ich mit Win10EntImg, pc-zh-202-01 und pc-zh-202-02 benennen, da ich einen benötige, um das Image zu erstellen und die anderen beiden benötige ich, um das Image zu testen.
- Firmenstandard bezüglich lokalen Admin-Usern
dc-zh-ruga-01:
Der Administrator auf dem dc-zh-ruga-01 wird mit Sysadmin benennt.
ds-zh-ruga-01:
Der Admin-User wird ebenfalls sysadmin genannt.
Win10EntImg:
Der Admin User des Images wird im Laufe des Prozesses von Administrator auf sysadmin geändert, um Klarheit zu schaffen.
Einrichten der Testumgebung
Wie im L3-Netzplan gezeigt, steht für dieses Projekt das Labor-VLAN VLAN53_LAB03 (Subnetz 172.16.53.0/24) zur Verfügung. Das Labornetz hat über den Gateway 172.16.53.1/24 Internetzugang. Der Zugang zu allen anderen VLAN's der Rafisa wird durch die Firewall gesperrt. Nur der Zugang zum Backup Server im VLAN01 wurde erlaubt.
Meilensteine
Meine Meilensteine sind nach IPERKA geordnet:
| Meilenstein | Datum geplant | Datum erreicht |
|---|---|---|
| Informieren | 12.05.2021 | 12.05.2021 |
| Planen | 12.05.2021 | 12.05.2021 |
| Entscheiden | 17.05.2021 | 17.05.2021 |
| Realisieren | 26.05.2021 | 21.05.2021 |
| Kontrollieren | 31.05.2021 | 01.06.2021 |
| Auswerten | 01.06.2021 | 01.06.2021 |
Arbeitspakete
| Realisieren | Erledigt |
|---|---|
| Backup für alle geplanten Systeme vorbereiten | ✔️ |
| Einrichten Windows 2019 Server (Alle Dienste einrichten, User eröffnen) | ✔️ |
| Einrichten Ubuntu Server (Alle Dienste einrichten) | ✔️ |
| Einrichten des FOG-Servers (Features gemäss Planung einrichten) | ✔️ |
| Erstellen des Windows-Images (Software, User, Layout) | ✔️ |
| Capture und Deplyoment des Images (Automatisiertes Aufsetzen + Domain-Beitritt) | ✔️ |
| Kontrolle des Stagings, allenfalls Nachbesserungen (z.B. Treiber) | ✔️ |
| Nachträgliches Verteilen des OpenVPN-Clients | ✔️ |
| Authentifizierung der FOG-Admins über Admin einrichten (LDAP AD Anbindung) | ✔️ |
| Kontrollieren | ✔️ |
| Testkonzept erstellen | ✔️ |
| Tests durchführen Software Testen | ✔️ |
| Kontrolle der Realisierung | ✔️ |
| Auswerten | |
| Testszenario Auswerten | ✔️ |
| Auswerten/Dokumentation der Ergebnisse/Reflexeion | ✔️ |
| Reserve/Ergänzen von fehlenden Dokumentationen/Versenden der Arbeit | ✔️ |
Realisieren
Windows Server 2019
Erzeugen der VM auf Proxmox
Die VM für den Windows Server 2019 wird mit den festgelegten Parametern erzeugt (siehe Kapitel Entscheiden)
Installation
Bei der „Installationssprache“ gibt es nur eine Auswahl (Deutsche Installation). Hier wird die „Uhrzeit und Währungsformat“ auf „Deutsch (Schweiz)“ geändert. Die „Tastatur oder Eingabemethode“ passt sich automatisch mit „Deutsch (Schweiz)„der „Uhrzeit und Währungsformat“ an.
Bei der Betriebssystemauswahl gibt es vier Möglichkeiten den Windows Server 2019 zu installieren. Für diese Installation wird „Windows Server 2019 Standard (Desktopdarstellung)“ ausgewählt und installiert.
Für die Installationsart wird mit „Benutzerdefiniert: nur Windows installieren (für fortgeschrittene Benutzer“ ausgewählt, da man die Dateien auch im Nachhinein noch installieren kann.
Windows wird auf dem „Nicht zugewiesener Speicherplatz auf Laufwerk…“ installiert. Die Partitionierung kann dann in der Computerverwaltung erstellt werden.
Standard Einstellungen
Ich habe den Windows Server 2019 mit folgenden Einstellungen eingerichtet:
- Computername dc-zh-202-01
- Dem DVD ROM den LW-Buchstaben E:\ zuordnen
- Eine Primäre Partition D:\ erstellen (restl. Freier Speicher verwenden)
- Volumenbezeichnung ist Daten
- Enstprechende Verzeichnisse anlegen:
Install
Daten
Dokumente
Profiles
IP Adressierung
- IPv6 deaktivieren (alle Schnittstellen)
- IP Adressierung (Wenn der Kunde schon ein bestehendes Netzwerk hat, muss man abklären welche IPs vorhanden sind)
IP Adresse: 172.16.53.101
Subnetzmaske: 255.255.255.0
Standard Gateway: 172.16.53.1
Primärer DNS: 127.0.0.1 wird automatisch, nach Forward-Lookupzone Installation, erstellt
Active Directory und DNS Server installieren
- Im Server Manager Dashboard wird die Rolle „Active Directory-Domänendienste“ hinzufügt und installiert. Die dazu erforderlichen Features werden automatisch aufgelistet, diese werden mitinstalliert. Falls nach Umbenennung des Servers noch kein Neustart ausgeführt wurde, muss dies jetzt noch nachgeholt werden, bevor etwas installiert wird!
- Server zu einem Domänencontroller heraufstufen:
Das AD wurde mit folgenden Einstellungen eingerichtet:
- Neue Gesamtstruktur hinzufügen
- Name der Stammdomäne: rafisa.ipa
- Funktionsebene (Gesamt- und Domänen-) auf „Windows Server 2016“ belassen
- DNS-Server mitinstallieren
- Netbios-Domänenname: RAFISA
- Pfade für die AD Dateien auf Standard belassen
- Installation abschliessen und Server neu starten
Reverse-Lookupzone (DNS-Server) konfigurieren
Die Reverse-Lookupzone wurde mit folgenden Einstellungen eingerichtet:
- Reverse Lookupzone einrichten
- Neue Zone
- Primäre Zone „Zone in Active Directory speichern“ aktivieren
- Auf allen DNS-Servern in dieser Domäne
- IPv4 Reverse-Lookupzone
- Netzwerk-ID: 172.16.53.
- Nur sichere dynamische Updates zulassen
OU (Organization Unit) erstellen
Im Active Directory-Verwaltungszenter unter „IPA (lokal)“ folgende OU‘s erstellen:
- OU-IPA
- IPA_Computers
- IPA_Gruppen
- IPA_Users
Folgender Batch wird als Administrator ausgeführt:
D:\Install\Server\GPO\redircmp.bat
Dies bewirkt, dass Computer, die neu der Domäne hinzugefügt werden, automatisch in der OU „IPA_Computers“ abgelegt werden (der Sourcecode für den Batch befindet sich im Anhang).
Benutzerkonten
Benutzerkonten erstellen
Es wird ein Admin User mit dem Namen „Sysadmin“ erstellt. In der folgenden Maske wird eingestellt, dass das Passwort des Sysadmin nicht einfach geändert werden kann und auch nicht abläuft.
Servergespeicherte Profile
Allgemeiner User: Es werden die User, l.cotar und e.rueefli erstellt und mit dem folgenden Profilpfad zusätzlich zum User Ordner noch ein Unterordner mit dem PC-Namen erstellt. Somit hat jeder PC sein eigenes Profil.
Profilpfad User: %logonserver%\Profiles$\%Username%\%Computername%
(vor „%logonserver%“ braucht es keine „\\“)
DHCP
DHCP Server Installieren
Der Servermanager wird geöffnet und unter „Rollen und Features“ den DHCP-Server hinzufügt und installiert.
DHCP Server konfigurieren
Der DHCP wird mit folgenden Einstellungen eingerichtet:
- DHCP Konfiguration abschliessen
- DHCP Server autorisieren Praxis\Sysadmin
- Neuer Bereich einrichten Bereich1
- IP-Pool 172.16.53.120-160
- Leasedauer 8 Tage
- DHCP Optionen jetzt konfigurieren wählen
- Router 172.16.53.1
- Übergeordnete Domäne rafisa.ipa (IP Adresse des Servers muss aufgelistet sein)
- DNS-Server 172.16.53.101
- Bereichsoptionen Option „066 Hostname des Startservers“ & „067 Name der Startdatei“ hinzufügen
Ubuntu Server 20.04
Erzeugen der VM auf Proxmox
Die VM für den Ubuntu Server 20.04 LTS wird mit den festgelegten Parametern erzeugt (siehe Kapitel Entscheiden)
Installation
Als erstes wird die Deutsch Schweizer Tastatur ausgewählt. Als Rechnername wird wie geplant „ds-zh-202-01“ eingegeben, als Benutzer für diese Maschine „sysadmin“.
Wie geplant wird für die Partitionierung „Geführt-vollständige Festplatte verwenden“ verwendet.
Bei der Softwareauswahl wähle ich lediglich die Software OpenSSH Server aus, damit dieser gleich mitinstalliert wird. Die anderen Dienste werden nicht ausgewählt, da diese bereits auf dem Windows Server 2019 installiert sind.
Konfiguration
IP-Adresse
Um die IP-Adresse für den ds-zh-202-01 im Konfigurationsfile von Netplan zu erstellen, habe ich folgende Konfiguration erstellt.
network:
version: 2
renderer: networkd
ethernets:
ens18:
addresses:
- 172.16.53.102/24
dhcp4: no
gateway4: 172.16.53.1
nameservers:
addresses: [172.16.53.101]
FOG Konfiguration
Bevor ich mit der Installation des FOG-Project beginne, wechsle ich mit „sudo su“ oder „su-“ zum root user und danach installiere ich das Programm Git mit dem Befehl „apt-get install git“.
FOG-Project wird heruntergeladen mit dem Befehl:
„git clone https://github.com/FOGProject/fogproject“.
Zuerst wechsle ich in den Ordner “/fogproject/bin“ und führe dort die Datei „./installfog.sh“ aus. Die folgende Tabelle zeigt meine Installationsentscheide:
| Frage: | Empfohlene Antwort: |
|---|---|
| What version of Linux would you like to run the installa-tion for? | 2 (debian-based, Ubuntu) |
| Detected a potential need to reinstall apache and php files […] | Y |
| What type of installation would you like to do? | N (normale Installation). |
| What is the IP address to be used by this FOG-Server? | IP-Adresse des FOG-Servers |
| Would you like to change the default network inter-face from enp0s3? | N, um die automatisch erkannte Schnittstelle zu verwenden |
| Would you like to setup a router address for the DHCP Server? | Y, wenn FOG DHCP-Server ist IP-Adresse des DHCP Server |
| What is the IP address to be used for the router on the DHCP server? | IP-Adresse des Standard-Gateways |
| Would you like DHCP to handle DNS? | Y, wenn FOG DHCP-Server ist IP-Adresse des DHCP Server |
| What DNS address should DHCP allow? | IP-Adresse des DNS-Servers |
| Would you like to use the FOG-Server for DHCP Service? | Abhängig von der geplanten Netzwerkstruktur Y oder N |
| This version of FOG has internationalization support, would you like to install the additional language packs? | Es gab immer wieder Schwierigkeiten mit übersetzten FOG-Versionen, daher wird N empfohlen |
| Using encrypted connections is state of the art on the web and we encourage you to enable this for your FOG server. But using HTTPS has…Would you Like to enable secure HTTPS on your FOG Server? | Yes |
| Which hostname would you like to use? Currently is: FOG-Master Note: This hostname will be in the certificate we generate for your FOG webserver. The hostname…Would you like to change it? If you are not sure, select No. | No |
Tabelle 27: Fragen zu FOG Installation
Wenn alles korrekt ist, kann die Installation gestartet werden.
Die Installation wird zwischendurch kurz unterbrochen, damit über das WEB Interface von FOG, das unter der Adresse https://172.16.53.102/fog/management erreichbar ist, die Datenbank installiert werden kann.
Sobald die Installation fertig ist, werden noch einige wichtige Informationen ausgegeben.
Windows 10 Enterprise N-Image
Erzeugen der VM auf Proxmox
Die VM für das Windows 10 Enterprise N Image wird mit den festgelegten Parametern erzeugt (siehe Kapitel Entscheiden).
Bevor die Windows 10 Enterprise N Installation gestartet wird, muss unter der erstellten Win10EntImg in der Einstellung Hardware die Funktion im BIOS von „Default (SeaBIOS)“ auf „OVMF (UEFI)“ geändert werden.
Installation
Bei der „Installationssprache“ gibt es nur eine Auswahl (Deutsche Installation). Hier wird die „Uhrzeit und Währungsformat“ auf „Deutsch (Schweiz)“ geändert. Die „Tastatur oder Eingabemethode“ passt sich automatisch mit „Deutsch (Schweiz)„der „Uhrzeit und Währungsformat“ an.
Wie geplant wird Windows 10 Enterprise N ausgewählt.
Für die Installationsart wird mit „Benutzerdefiniert: nur Windows installieren (für fortgeschrittene Benutzer“ ausgewählt, da man die Dateien auch im Nachhinein noch installieren kann.
Windows wird wie geplant auf einer C:\ Partition eingerichtet
Um in den Audit-Mode zu gelangen, drückt man an dieser Stelle CTRL + SHIFT und dann die F3-Taste. Das System startet unverzüglich neu, nach dem Reboot befindet man sich im Audit-Mode. Das virtuelle LAN-Kabel kann nun wieder verbunden werden.
Im automatisch erscheinenden Sysprep-Dialog klickt man auf Abbrechen. Da es sich um ein Firmennetzwerk handelt, kann zugelassen werden, dass der PC von anderen Geräten im Netzwerk gesehen wird.
Installation von Windows-ADK
Um das System konfigurieren und die ensprechenden Answer-Files anlegen zu können, benötigt man die Windows-Bereitstellungstools aus dem Windows Assessment and Deployment Kit (ADK). Es wird die Version ADK für Windows 10, Version 2004 heruntergeladen, da ansonsten das Answer File nicht erstellt.
Während der Installation werden im Feature-Dialog ausschliesslich die Bereitstellungstools ausgewählt:
Konfiguration
Windows-Image anpassen
Alle die Anpassungen, die im Audit-Mode vorgenommen werden, werden ins Default-Profil geschrieben und stehen dann allen BenutzerInnen zur Verfügung. Die Anpassungen bleiben auch im Domain-Modus erhalten.
Zunächst werden die im Kapitel Informieren beschriebenen Anpassungen (Explorer, Teams, Remote-Desktop und Wallpaper) vorgenommen. Nachdem die Anpassungen vorgenommen worden sind, werden die für das Image benötigten Programme installiert (s. Kapitel Informieren). Die Programme werden alle in den Default-Einstellungen installiert.
Danach werden die Layout-Anpassungen für das Startmenu und die Taskleiste vorgenommen. Die Layouteinstellungen sind in einer XML-Datei gespeichert.
Nachdem man das Menu und die Taskleiste angepasst hat, kann man die Layoutdatei mit dem Befehl Export-StartLayout -path C:\LayoutModification.xml exportieren und dann über die lokale GPO-Richtlinie Administrative Vorlagen/Startmenü und Taskleiste/Startlayout einbinden:
Für die Standardzuordungen der Applikationen muss auch ein XML-File exportiert und danach wieder importiert werden. Mit dem Befehl dism /Online /Export-DefaultAppAssociations:“C:\DefaultAppAssociations.xml” nach C:\DefaultAppAssociations.xml kopiert. Um es für neue Userprofile dauerhaft zu speichern wird es mit dem Befehl 'dism /Online /Import-DefaultAppAssociations: “C:\DefaultAppAssociations.xml” wieder importiert.
Danach werden die Layout-Anpassungen für das Startmenu und die Taskleiste vorgenommen.
Einrichten des Windows System Image Managers (WSIM)
Im Windows System Image Manager (WSIM) wird im nächsten Abschnitt die Antwortdatei erzeugt, mit welcher die Installation von Windows 10 nach dem Deployment auf dem Zielgerät gesteuert wird.
Zunächst erstellt man den Ordner C:\customize\Win10 und kopiert sämtliche Installationsdateien vom virtuellen CD-Laufwerk dorthin:
Als nächstes muss unter C:\customize der Ordner Distribution mit folgenden Unterordnern erstellt werden:
- $OEM$
- LangPacks
- Out-of-Box Drivers
- Packages
Danach gibt man im Suchfeld Windows System Image Manager ein und startet das Programm. Danach wird über den Menupunkt Datei die Windows-Abbilddatei C:\customize\win10\sources\install.wim eingelesen. Im folgenden Dialog wird die entsprechende Windows-Datei (Windows 10 Enterprise N) ausgewählt. Wenn noch keine Katalogdatei angelegt worden ist, muss dies nun gemacht werden:
Im Distribution-Ordner wird auch das Antwortfile erstellt. Dazu wird im Windows System Image Manager im Menu Datei der Punkt Distributionsfreigabe auswählen angewählt und als Ordner C:\customize\Distribution angegeben.
Danach wird mit Datei/Neue Antwortdatei… eine neue Antwortdatei angelegt:
Erzeugen der Antwortdatei für den Sysprep-Vorgang
Eine Antwortdatei enthält sieben verschiedene Stufen oder Schritte, die bei einem Windows-Setup durchlaufen werden. Für diese Stufen erstellt man ein Answer-File mit den Antworten auf Konfigurationsfragen. So müssen die Antworten nicht während des Setups von Hand eingegeben werden, sondern das Setup kann völlig automatisch ablaufen. Ein mit sysprep zurückgesetztes Image startet nach der Verteilung in der Stufe 4 specialize, danach wird die Stufe 7 oobeSystem durchlaufen. Für diese beiden Stufen werden Answer-Files angelegt.
Pass 4 specialize
Wenn während der Installation im Windows System Image Manager zusätzliche Einstellungen wie Modell, Hersteller, Computername, Eigentümername, Zeitzone und mehr konfiguriert werden soll, benötigt man die Komponente amd64_Microsoft-Shell-Setup.
- Im Abschnitt Windows-Image den Ordner Components erweitern.
- Die Komponente amd64_Microsoft-Shell-Setup erweitern.
- Mit der rechten Maustaste auf die Komponente OEMInformation klicken und die Option Add Setting to Pass 4 specialize auswählen.
<HTML><ol start=„4“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Im Abschnitt Antwortdatei auf der rechten Seite die Komponente amd64_Microsoft-Shell-Setup auswählen.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Unter dem Abschnitt Einstellungen auf der rechten Seite die folgenden Werte setzen:<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
- ComputerName: Keiner, da dieser vom FOG-Server gesetzt wird
- CopyProfile: true
- RegisteredOrganization: Stiftung Informatik für Autisten
- RegisteredOwner: Stiftung Informatik für Autisten
Pass 7 oobeSystem
Mit diesen Schritten wird die Out-of-Box-Erfahrung konfiguriert:
- Unter Windows Image den Components-Ordner erweitern.
- Ich Klicke mit der rechten Maustaste auf die Komponente amd64_Microsoft-Windows-International-Core und wählen Sie die Option Add Setting to Pass 7 oobeSystem.
- Im Abschnitt Windows-Image die Komponente amd64_Microsoft-Shell-Setup erweitern.
- Mit der rechten Maustaste auf die OOBE-Komponente klicken und die Option Add Setting to Pass 7 oobeSystem auswählen.
<HTML><ol start=„5“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Die Komponente UserAccounts erweitern.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Die Komponente LocalAccounts erweitern.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Mit der rechten Maustaste auf die Komponente LocalAccount klicken und die Option Add Setting to Pass 7 oobeSystem auswählen.<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start=„8“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Unter dem Abschnitt Antwortdatei die Komponente amd64_Microsoft-Windows-International-Core auswählen.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Im Abschnitt Einstellungen auf der rechten Seite die Spracheinstellungen festlegen:<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
- InputLocale: de-CH
- SystemLocale: de-CH
- UILanguage: de-CH
- UILanguageFallback: en-US
- UserLocale: de-CH
<HTML><ol start=„10“ style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Im Abschnitt “Antwortdatei” die Komponente amd64_Microsoft-Shell-Setup erweitern.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Die OOBE-Komponente auswählen.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Unter dem Abschnitt Einstellungen auf der rechten Seite die folgenden Werte einsetzen:<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
- HideEULAPage: true
- HideOEMRegistrationScreen: true
- HideOnlineAccountScreens: true
- HideWirelessSetupinOOBE: true
- ProtectYourPC: 3
In der Einstellung ProtectYourPC wird defniniert, wie die Express-Einstellungen gehandhabt werden sollen. Wenn man den Wert 1 verwendet, teilt man dem Setup mit, dass es die Express-Einstellungen mit den Standardeinstellungen aktivieren soll.
- Die Komponente UserAccounts auswählen.
- Mit der rechten Maustaste auf die Komponente LocalAccounts klicken und die Option Neue LocalAccount einfügen auswählen.
- Im Abschnitt “Einstellungen” auf der rechten Seite die folgende Konfiguration wählen, um ein primäres lokales Konto zu erstellen:
- Description: Sysadmin-Konto
- DisplayName: sysadmin
- Group: Administratoren
- Name: sysadmin
Mit den obigen Einstellungen wird ein Konto namens sysadmin für den Benutzer sysadmin erstellt und das Konto der Gruppe Administratoren hinzugefügt.
Danach wird die Komponente “LocalAccount” erweitert.
- Die Komponente Passwort auswählen.
- Im Abschnitt Einstellungen auf der rechten Seite im Feld Value ein Passwort eingeben.
Man sieht das Passwort im Klartext sehen, der Wert wird aber nach dem Speichern der Datei customize.xml verschlüsselt.
Zunächst wird die Antwortdatei über das Menu Extras/Antwortdatei überprüfen validiert und allfällige überflüssige Keys gelöscht.
Dann kann die Datei über Datei/Antwortdatei speichern nach C:\customize\customize.xml abgespeichert werden.
Durchführen von Sysprep
Damit der Ordner C:\customize auf den Zielsystemen nicht stört, kann er mit dem Konsolen-Befehl (als Administrator ausführen) attrib +s +h “C:\customize” unsichtbar gemacht werden. Mit attrib -s -h “C:\customize” macht man den Ordner wieder sichtbar.
Da zuletzt die Datei customize.xml verwendet wurde, sieht der Benutzer, der sich nach dem Staging des Images anmeldet, die Datei immer noch im Abschnitt der zuletzt verwendeten Dateien im Windows Explorer.
Um dies zu verhindern, kann man ein kleines Skript implementieren, das diese Einträge entfernt. Das Skript wird nur einmal ausgeführt und löscht sich danach selbst. Dazu navigiert man im Explorer nach %appdata%\Microsoft\Windows\Start Menu\Programs\Startup und erstellt eine Datei namens runonce.bat. Man muss sicherstellen, dass die Dateierweiterung korrekt ist und nicht .txt.
In die Datei wird folgender Code eingefügt:
Del /F /Q %APPDATA%\Microsoft\Windows\Recent\*
Del /F /Q %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\*
Del /F /Q %APPDATA%\Microsoft\Windows\Recent\CustomDestinations\*
REG Delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU /VA /F
REG Delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths /VA /F
del %0
Mit diesem Code werden sämtliche Orte, an denen Windows die History speichert, zurückgesetzt.
Nun kann Sysprep ausgeführt werden. Zunächst wird ein SNAPSHOT der VM angelegt, damit man immer an diesen Ort zurückkehren kann, sollte Sysprep nicht funktionieren.
Man öffnet CMD als Administrator und wechselt ins Sysprep-Verzeichnis:
cd C:\Windows\System32\Sysprep
Um Interferenzen mit dem Sysprep-Befehl zu vermeiden, stoppt man vorsichtshalber den Windows Media Networking Service:
net stop wmpnetworksvc
Jetzt beginnt man mit Sysprep. Nach Eingabe des Befehls, wird Sysprep das Image vorbereiten. Währenddessen sollten auf dem Computer keine Aktionen ausgeführt werden.
sysprep.exe /generalize /oobe /shutdown /unattend:C:\customize\customize.xml
Sollte Sysprep fehlschschlagen, sollte folgender Befehl in der Powershell ausgeführt werden:
Remove-AppxPackage -Package Microsoft.WindowsStore_11602.1.26.0_x86__8wekyb3d8bbwe
Nachdem Sysprep erfolgreich durchgeführt worden ist, fährt das System automatisch herunter. Es ist sehr wichtig, dass danach die VM nicht versehentlich gestartet wird, da dadurch das Setup ausgeführt und der ganze Prozess rückgängig gemacht würde. Das generalisierte Image muss jetzt auf die FOG-Plattform importiert werden.
FOG-Project
Inventory & Capture
Bevor das Image gecaptured werden kann, muss der Host vorher noch registriert und inventarisiert werden. Dabei gehe ich zuerst mit „F12“ in das Boot Menu und wähle dabei „Realtek…“ aus. Danach dauert es einen Moment, bis ich im FOG-Menu lande.
Sobald Sie auf dieser Seite (siehe Bild „Host is NOT registered“) sind, hat man lediglich ein schmales Zeitfenster von drei Sekunden, um „Perform Full Host Registration and Inventory“ auszuwählen.
Sobald ich „Perform Full Host Registration and Inventory“ ausgewählt habe, muss ich den „Hostname“, pc-zh-202-01, eingeben und das richtige „Image“ mit einer definierten Zahl auswählen, hier die 1. Unten stehende Abbildung zeigt alle Entscheidungen, die ich beim Inventarisieren getroffen habe:
Sobald die Inventarisierung fertig ist, muss der Computer ausgeschaltet werden, bevor Windows wieder aufstartet, da das Image ansonsten kein Sysprep Image mehr ist. Wenn der Computer heruntergefahren wurde, wechseln ich auf das WEB Interface des Deployment Servers und wähle Hosts aus. Dabei lasse ich mir mit „List all Hosts“ alle Hosts anzeigen wähle dann den Host aus.
Da der Host pc-zh-202-02 inventarisiert wurde, wähl ich diesen aus und wechsle in die Auswahl „Basic Task“. Da ich noch kein Image auf dem Deployment Server habe, muss ich „Capture“ auswählen. Bei den „Andvanced Settings“ kann ich die Standardauswahl so belassen und bei „Create Capture Tasking“ einfach den Task bestätigen.
Damit ich das gewünschte Image jetzt Capturen kann, muss ich den inventarisierten Computer starten, und mit „F12“ in das Boot Menu wechseln und den Network-Boot auswählen. Danach läuft das Capture selbstständig durch.
Im WEB Interface sieht man bei den Active Tasks einen Fortschrittsbalken.
Deploy
Um einen Computer zu deployen, starte ich einen beliebigen Computer und gehe dabei mit „F12“ in das Boot Menu. Im Boot Menu wird der Network-Boot ausgewählt. Im FOG-Menu wähle ich „Deploy Image“ aus und gebe meine Login Daten wie Username und das dazugehörige Passwort ein. Danach kommt eine Liste mit allen Images, die gecaptured wurden, ich wähle Windows 10 Enterprise N.
Danach wird das Image auf den Computer übertragen. Dies dauert lediglich einige Minuten.
Sobald das Deployment fertig ist, wird am unteren Bildschirmrand ein schwarzer Balken mit einigen wichtigen Informationen ausgeben. (es wird mitgeteilt, ob das Deployment erfolgreich war oder gescheitert ist).
Snapin
Konfiguration
image58.tmpDie wichtigsten Punkte sind hier der Name des Snapins, das Snapin Template und das jeweilige *.msi File. Dabei gebe ich den Namen des Snapins ein, das ich erstellen will. Bei dem Snapin Template wähle ich MSI aus und bei dem Snapin File wähle ich dann das *.msi Programm aus.
„Reboot after install“ muss deaktiviert werden. Bei „Snapin Command read-only“ wird automatisch generiert, das heisst es wird auf „msiexec.exe /i openvpn-connect-3.2.3.1851_signed.msi /quiet“ definiert.
Installation
image60.tmpUnter „List All Hosts“ im Host wähle ich den PC aus, auf den das Snapin installiert werden soll. Danach wechsle ich von „General“ zu „Basic Tasks“. Ich wähle dabei „Advanced“ aus und wähle danach „Single Snapin“ aus. Bei „Please select an option“ muss ich ein Snapin auswählen. Nebenbei muss ich unter anderem „Wake on LAN?“ aktivieren. Sobald diesen Punkt aktiviert ist, muss ich den Task noch erstellen. Danach wird das Snapin automatisch installiert.
AD Beitritt
Konfiguration
Um die Active Directory Defaults zu erstellen, gehe ich in die FOG Settings, die sich unter der FOG Configuration befinden. Im Feld „AD Default Domainname“ gebe ich meinen Domänennamen, rafisa.ipa, ein. Ich gebe bei „AD Default OU“ den Pfad an wo sich der User Sysadmin befindet. Der „AD Default User“ ist logischerweise der Sysadmin, dazu gebe ich das Passwort des Sysadmin zweimal ein.
Installation
Sobald ich „Join Domain after Deploy“ aktiviert habe, füllen sich die Zeilen „Domain Name“, „Organization Unit (Blank for Default)“, „Sysadmin“ und die Passwörter automatisch aus. Ich muss noch zusätzlich „Name Change/AD Join Forced reboot?“ aktivieren. Danach kann ich mit Update bestätigen.
Diese Option funktioniert nur dann, wenn ich den Computer danach deploye.
LDAP
Konfiguration
Der „LDAP Connection Name“ wird mit „AD Rafisa“ benannt. Die IP-Adresse bei „LDAP Server Address“ ist die IP-Adresse des Domaincontrollers, des Windows Servers 2019. Als „LDAP Server Port“ gebe ich den Port 389 ein. Bei „Search Base DN“ gebe ich an wo der User FOG Admin liegt. Bei der Gruppe „Group Search DN“ ist wichtig ist, dass ich OU und NICHT CN verwende. Bei „Admin Group“ gebe ich den Gruppennamen an.
Der „samAccountName“ wird von mir bei „User Name Attribute“ eingegeben. Der „Group Member Attribute“ ist „member“. Bei „Search Scope“ wähle ich „Subree and Below“ aus. Ich muss den kompletten Pfad des FOG Admins bei dem „Bind DN“ eingeben. Und bei dem „Bind Passwort“ gebe ich das Passwort des Users FOG Admin ein.
Test
Um zu testen ob die Konfiguration funktioniert, logge ich mich als FOG Admin mit fog.admin und dem Passwort ein. Wenn es funktioniert hat, kann ich bei dem System Overview sehen, dass bei username fog.admin steht.
BackupPC
Edit Hosts
Nachdem ich mich unter der IP 172.16.1.100 auf dem WEB Interface von BackupPC eingeloggt habe, füge ich die Hosts „dc-zh-202-01.stiftung.ifa“ und „ds-zh-202-01.stiftung.ifa“ hinzu. Dabei muss der User „backuppc“ und bei moreUsers „backup-leacot“ sein.
Edit Config
Ich wähle einen Host aus den ich erstellt habe und gehe danach auf „Edit Config“. Bei der Zeile „DumpPreUserCmd“ gebe ich den Befehl „$sshPath -q -x -l rafisa-backup $host sudo vzdump 100 –mode snapshot“ ein.
100 = die Virtuelle Maschine auf dem Proxmox
Bei der Zeile „DumpPostUserCmd“ gebe ich den Befehl „$sshPath -q -x -l rafisa-backup $host sudo rm -r /var/lib/vz/dump/*“ ein.
Ich gebe den Pfad “/var/lib/vz/dump/“ bei Insert in der Zeile von „RsyncShareName“ ein.
Diese Optionen lasse ich sowohl bei den Fullbackups als auch bei den Incremental Backups auf dem Standard (siehe Abbildung 75).
Host Summary
Das Host Summary zeigt alle erfolgreichen, sowie die erfolglosen Backups an (siehe Abbildung 71).
Kontrollieren
Zu testendes System und dessen Umgebung
Hier werde ich die verschiedenen Systeme testen, dazu gehört das Capturen und Deployen des Windows 10 Enterprise N Images. Folgende Tabelle zeigt alle Tests, die ich durchführen möchte.
Relevante Testfälle und zu erwartende Ergebnisse
| Test-Nr. | Name | Beschreibung | Erwartetes Resultat |
|---|---|---|---|
| Windows Server 2019 | |||
| #1 | DHCP | Die Verteilung einer IP-Adresse. | Der Client bekommt eine IP-Adresse im konfigurierten Bereich. |
| #2 | DNS | Das Aufrufen und Anzeigen einer beliebigen Website. | Der Benutzer kann eine beliebige Website aufrufen und anzeigen lassen. |
| FOG Deployment Server | |||
| #3 | LDAP Login | Einige User können sich mit dem eigenen Login auf dem Webinterface anmelden. | Die User können sich auf dem Webinterface mit dem eigenen Login anmelden. |
| #4 | Snapin | Verschiedene Software kann über das Netzwerk und das Webinterface installiert werden. | Die Software wird automatisch auf der Maschine installiert. |
| #5 | Capture | Das Image wird über das Netzwerk auf den Deployment Server hochgeladen | Das Image ist auf dem Deployment Server hochgeladen. |
| #6 | Deploy | Das Image wird über das Netzwerk installiert. | Das Image ist auf der Maschine installiert. |
| Windows 10 Enterprise N | |||
| #7 | Startmenu und Taskleiste | Die definierten Apps werden mithilfe eines *.xml Files standardisiert. | Alle definierten Apps sind nach der Installation im Startmenu und in der Taskleiste. |
| #8 | Software | Die Installation der Software wird vor dem Capture gemacht. | Alle definierte Software sind installiert. |
| #9 | Zuordnung der Standardapplikationen | Die definierten Apps werden mithilfe eines *.xml Files standardisiert. | Alle definierten File-Formate sind nach der Installation der richtigen App zugeordnet. |
| #10 | Treiber | Nachträgliche Installation aller Geräte Treiber. | Alle Treiber müssen nach der Installation noch nachträglich installiert sein |
| #11 | Automatischer Domänen beitritt | Automatischer Domänenbeitritt nach dem Deployen | Die Maschine tritt automatisch der Domäne nach dem Deployen bei. |
| #12 | Aufrufen einer verschlüsselten Seite | Verschlüsselte Seite (Webinterface des FOG-Servers unter 172.16.53.102) kann im Browser aufgerufen werden. | Der Browser zeigt links neben der Adresszeile ein Verschlüsselungssymbol. |
| Backup & Restore | |||
| #13 | Backup | Das Backup wird in der Nacht erfolgreich ausgeführt. | Das Backup wird in der Übersicht angezeigt |
| #14 | Restore | Das Restore wird manuell erfolgreich ausgeführt. | Nach dem Restore befindet sich das wiederhergestellte File auf dem Proxmox Server. |
Tabelle 28: Testfälle
Abdeckung der Testfälle Was wird nicht getestet
| Test-Nr. | Name | Beschreibung | Was wird nicht getestet |
|---|---|---|---|
| FOG Web Server | |||
| Multicast | Multicasting in FOG versendet ein gesondertes Bild an etliche PC, wodurch ausschliesslich wenig Bandbreite braucht, wird, als beim Unicast. (14) | Das Aufsetzten von mehreren Hosts gleichzeitig. | |
| Gruppen | Keine Erstellung von Gruppen | Das Erstellen und das Verwenden von Gruppen wird nicht benötigt, das es nur zwei Hosts sind | |
| User Management | Alle Konten werden unter dem Abschnitt „Users“ der FOG Web GUI erstellt. (15) | Das Erstellen von Usern im WEB Server | |
| Power Management | Es kann für jeden Host einen CRON-Zeitplan für Stromversorgungsvorgänge definieren und hat die Opportunität, Stromversorgungsvorgänge wenn nötig auszuführen. (16) | Den Host von dem Webservers nicht herunterfahren oder neu starten | |
| #12 | Aufrufen einer verschlüsselten Seite | Das Webinterface des Servers wird über https aufgerufen | Es wird nicht auf Zertifikatsfehler, wie sie z.B. durch selbst signierte Zertifikate entstehen, getestet |
Tabelle 29: Abdeckung der Testfälle
Relevante Testmittel (HW, SW) und Testmethoden
| Test-Nr. | Name | Relevante Testmittel | Testmethode |
|---|---|---|---|
| #1 | DHCP | dc-zh-202-01 (Windows Server 2019, DHCP Controller), pc-zh-202-01 (Windows 10 Enterprise N 20H1), Switch | Integrationstest |
| #2 | DNS | dc-zh-202-01 (Windows Server 2019, DNS-Controller), pc-zh-202-01 (Windows 10 Enterprise N 20H1), Switch | Integrationstest |
| #3 | LDAP Login | dc-zh-202-01 (Windows Server 2019 AD-OU), ds-zh-202-01 (Ubuntu Server 20.04 LTS), pc-zh-202-01 (Windows 10 Enterprise N 20H1) | Integrationstest |
| #4 | Snapin | dc-zh-202-01 (Windows Server 2019), ds-zh-202-01 (Ubuntu Server 20.04 LTS), pc-zh-202-01 (Windows 10 Enterprise N 20H1), Switch | Integrationstest |
| #5 | Capture | dc-zh-202-01 (Windows Server 2019 DHCP), ds-zh-202-01 (Ubuntu Server 20.04 LTS), Win10EntImg (Windows 10 Enterprise N 20H1), Switch | Systemtest |
| #6 | Deploy | dc-zh-202-01 (Windows Server 2019 DHCP), ds-zh-202-01 (Ubuntu Server 20.04 LTS), pc-zh-202-01 (Windows 10 Enterprise N 20H1), Switch | Systemtest |
| #7 | Startmenu und Taskleiste | Win10EntImg (Windows 10 Enterprise N 20H1), | Komponententest |
| #8 | Software | Win10EntImg (Windows 10 Enterprise N 20H1), Switch | Komponententest |
| #9 | Zuordnung der Standardapplikationen | Win10EntImg (Windows 10 Enterprise N 20H1), | Komponententest |
| #10 | Treiber | Win10EntImg (Windows 10 Enterprise N 20H1), | Komponententest |
| #11 | Automatischer Domänen beitritt | dc-zh-202-01 (Windows Server 2019 DHCP), ds-zh-202-01 (Ubuntu Server 20.04 LTS), pc-zh-202-01 (Windows 10 Enterprise N 20H1), Switch | Systemtest |
| #12 | Aufrufen einer verschlüsselten Seite | pc-zh-202-01 (Win10 + Firefox-Browser), sw-zh-202-01, prox-zh-202-01, ds-zh-202-01 (Ubuntu Server 20.04 LTS + Apache2) | Komponententest, Sicherheitstest |
| #13 | Backup | prox-zh-202-01, bkp-zh-ruga-01, dc-zh-202-01, ds-zh-202-01 | Systemtest |
| #14 | Restore | prox-zh-202-01, bkp-zh-ruga-01, dc-zh-202-01, ds-zh-202-01 | Systemtest |
Tabelle 30: Relevante Testmittel & Testmethoden
Durchführung und Auswertung der Tests
Testprotokolle
Test #1: DHCP
| Testfall Nr. | #1 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 26.05.2021 |
| Beschreibung | Die Verteilung von IP-Adressen. |
| Vorgehen | ipconfig |
| Voraussetzung/Umfeld | Auf dem AD-Server dc-zh-202-01 ist der DHCP-Dienst aktiviert. |
| Erwartetes Resultat | Der Client bekommt eine IP-Adresse im konfigurierten Bereich. DHCP Bereich: 172.16.53.120-160 |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 31: DHCP Test
Test #2: DNS
| Testfall Nr. | #2 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | |
| Beschreibung | Das aufrufen und Anzeigen einer beliebigen Website. Pingen von spezifischen IP-Adressen und Websiten. |
| Vorgehen | ping 8.8.8.8 |
| ping www.google.ch | |
| nslookup pc-zh-202-01 | |
| nslookup dc-zh-202-01 | |
| Voraussetzung/Umfeld | Auf dem AD-Server dc-zh-202-01 ist der DNS-Dienst aktiviert. |
| Erwartetes Resultat | Die Namen und Adressen werden korrekt aufgelöst |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 32: DNS Test
Test #3: LDAP Login
| Testfall Nr. | #3 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 21.05.2021 |
| Beschreibung | Einige User können sich mit dem eigenen Login auf dem Webinterface anmelden. |
| Vorgehen | https://172.16.53.102/fog/management/ Username: fog.admin Password: ********* |
| Voraussetzung/Umfeld | https://172.16.53.102/fog/management/ Login mit User fog |
| Erwartetes Resultat | Die User können sich auf dem Webinterface mit dem eigenen Login, anmelden. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Die Konfiguration muss sehr genau sein und muss mehrmals überprüft werden, wenn ich mich nicht einloggen kann. |
Tabelle 33: LDAP Login Test
Test #4: Snapin
| Testfall Nr. | #4 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 28.05.2021 |
| Beschreibung | Verschiedene Software können über das Netzwerk und das Webinterface installiert werden. |
| Vorgehen | Host |
| Basic Task | |
| Advanced | |
| Single Snapin OpenVPN als Snapin einbinden (siehe Kapitel «Snapin») | |
| Voraussetzung/Umfeld | Snapin wird innert 30 Sekunden installiert. |
| Erwartetes Resultat | Die Software wird automatisch auf der Maschine installiert. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 34: Snapin Test
Test #5: Capture
| Testfall Nr. | #5 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 18.05.2021 |
| Beschreibung | Das Image wird über das Netzwerk auf den Deployment Server hochgeladen |
| Vorgehen | Perform Full Host Registration and Inventory |
|
|
| Voraussetzung/Umfeld | Das Capture wird durchlaufen |
| Erwartetes Resultat | Das Image ist auf dem Deployment Server hochgeladen. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 35: Capture Test
Test #6: Deploy
| Testfall Nr. | #6 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 19.05.2021 |
| Beschreibung | Das Image wird über das Netzwerk installiert. |
| Vorgehen | |
| Image auswählen | |
| Voraussetzung/Umfeld | |
| Erwartetes Resultat | Das Image ist auf der Maschine installiert. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 36: Capture Test
Test #7: Startmenu und Taskleiste
| Testfall Nr. | #7 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 21.05.2021 |
| Beschreibung | Die definierten Apps werden mithilfe eines *.xml Files standardisiert. |
| Vorgehen | Startmenu und Taskleiste mit Vorgabe vergleichen. |
| Voraussetzung/Umfeld | Im PowerShell das File in das Laufwerk C:\ mit dem Befehl „Export-StartLayout -path C:\LayoutModification.xml“ importieren |
| Erwartetes Resultat | Alle definierten Apps sind nach der Installation im Startmenu und in der Taskleiste. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 37: Taskleiste
Test #8: Software
| Testfall Nr. | #8 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 28.05.2021 |
| Beschreibung | Die Installation der Software wird vor dem Capture gemacht. |
| Vorgehen | Jede installierte Software wird gestartet |
| Voraussetzung/Umfeld | Software ist installiert. |
| Erwartetes Resultat | Alle definierte Software ist installiert und lässt sich öffnen. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Die Tests waren erfolgreich |
Tabelle 38: Software Test
Test #9: Zuordnung der Standardapplikationen
| Testfall Nr. | #9 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 18.05.2021/19.05.2021 |
| Beschreibung | Die definierten Apps werden mithilfe eines *.xml Files standardisiert. |
| Vorgehen | Files mit den Endungen .pdf, .html, .jpeg, .mp3, .mp4 werden mit den zugeordneten Applikationen gestartet. |
| Voraussetzung/Umfeld | Das entsprechende XML-File wurde mit dem Befehl dism /Online /Export-DefaultAppAssociations:“C:\DefaultAppAssociations.xml” nach C:\DefaultAppAssociations.xml exportiert. Um es für neue Userprofile dauerhaft zu speichern wurde es mit dem Befehl 'dism /Online /Import-DefaultAppAssociations: “C:\DefaultAppAssociations.xml” wieder importiert. |
| Erwartetes Resultat | Alle Dateien werden mit der korrekten Applikation geöffnet. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 39: Startmenu Test
Test #10: Treiber
| Testfall Nr. | #10 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 19.05.2021 |
| Beschreibung | Nachträgliche Installation aller Geräte Treiber. |
| Vorgehen |  |
| Windows Updates installieren | |
| Treiber suchen, herunterladen und installieren | |
| Voraussetzung/Umfeld | Mindestens das Forward-Lookup Zone des DNS muss installiert sein |
| Erwartetes Resultat | Alle Treiber müssen nach der Installation noch nachträglich installiert sein |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Treiber SM-Bus-Controller kann durch das Installieren der Windows Updates installiert werden |
Tabelle 40: Treiber Test
Test #11: Automatischer Domänen beitritt
| Testfall Nr. | #11 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 21.05.2021 |
| Beschreibung | Automatischer Domänen beitritt nach dem Deployen |
| Vorgehen | Host |
| Active Directory aktivieren | |
| Update | |
| Basic Task | |
| Host Deployen | |
| Voraussetzung/Umfeld | Automatischer Beitritt der Domäne nach dem Deployen |
| Erwartetes Resultat | Die Maschine tritt automatisch der Domäne nach dem Deployen bei. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 41: Automatischer Domänen beitritt Test
Test #12: Aufrufen einer verschlüsselten Seite
| Testfall Nr. | #12 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 21.05.2021 |
| Beschreibung | Verschlüsselte Seite (Webinterface des FOG-Servers unter 172.16.53.102) kann im Browser aufgerufen werden. |
| Vorgehen | Verschlüsselte Seite (Webinterface des FOG-Servers unter 172.16.53.102) wird im Browser aufgerufen. |
| Voraussetzung/Umfeld | Während der Installation von FOG wurde die Option HTTPS für das Webinterface ausgewählt. |
| Erwartetes Resultat | Der Browser zeigt links neben der Adresszeile ein Verschlüsselungssymbol. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreich |
Tabelle 42: Aufrufen einer verschlüsselten Seite
Test #13: Backup
| Testfall Nr. | #13 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 18.05.2021 und 19.05.2021 |
| Beschreibung | Das Backup wird in der Nacht erfolgreich ausgeführt. |
| Vorgehen | Am Morgen wird in der Statusübersicht von BackupPC das Backup kontrolliert |
| Voraussetzung/Umfeld | BackupPC ist wie im Kapitel «Realisieren beschrieben» aufgesetzt. |
| Erwartetes Resultat | image74.tmpDas Backup wird in der Übersicht angezeigt. |
| OK/nicht OK | An 18.05.2021 verlief das Backup nicht erfolgreich. Anschliessend mussten die Hostnames angepasst werden. Am 19.05.2021 wurde das Backup erfolgreich erstellt. |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war nicht erfolgreich (18.05.2021) Der Test war erfolgreich (19.05.2021) |
Tabelle 43: Backup
Test #14: Restore
| Testfall Nr. | #14 |
|---|---|
| Testperson | Lea Cotar |
| Testzeitpunkt | 01.06.2021 |
| Beschreibung | Das Restore wird manuell erfolgreich ausgeführt. |
| Vorgehen | image75.tmpIm Webinterface von BackuPC wird beim Backup des jeweiligen Hosts das Restore ausgewählt. |
| Voraussetzung/Umfeld | BackupPC ist wie im Kapitel «Realisieren beschrieben» aufgesetzt. |
| Erwartetes Resultat | Nach dem Restore befindet sich das wiederhergestellte File auf dem Proxmox Server. |
| OK/nicht OK | OK |
| Aufgetretene Fehler, Bemerkungen, Fazit, Empfehlungen | Der Test war erfolgreichimage76.tmp |
Tabelle 44: Restore
Auswerten
Übersicht über den Projektverlauf
Es war teilweise anstrengend, die Informationen herauszusuchen und am Informieren dranzubleiben. Beim Planen musste ich verschiedene Lösungsmöglichkeit entwickeln. Es waren sehr viele Dinge, die ich notieren musste. Manchmal fiel mir es schwer, mich darauf zu fokussieren. Nach der Planung die Entscheidungen zu treffen, fiel mir leichter. Ich konnte die Tabellen aus der Planung übernehmen und dabei meine Entscheidungen treffen. Die Realisierung fiel mir persönlich am einfachsten, da ich den ganzen Ablauf schon kannte. Trotzdem hatte ich beim LDAP Login (AD-Anbindung) Schwierigkeiten. Denn da habe ich einige Fehler gemacht und die Fehler zu finden, war schwierig. Alle Tests, die ich gemacht habe, waren erfolgreich, wie man der folgenden Zusammenfassung entnehmen kann:
Im Testing wurden drei grosse Bereiche getestet:
- AD Server
- Deployment Server
- Windows 10 Enterprise N
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 |
Tabelle 45: Test der Funktionalität des AD Servers
| Test des FOG Deployment Server | ||
|---|---|---|
| Test Nr. | Beschreibung | Erfolgreich/Nicht erfolgreich |
| #03 | LDAP Login | Erfolgreich |
| #04 | Snapin | Erfolgreich |
| #05 | Capture | Erfolgreich |
| #06 | Deploy | Erfolgreich |
Tabelle 46: Test des FOG Deployment Server
| Test des Windows 10 Enterprise N | ||
|---|---|---|
| Test Nr. | Beschreibung | Erfolgreich/Nicht erfolgreich |
| #07 | Taskleiste | Erfolgreich |
| #08 | Software | Erfolgreich |
| #09 | Startmenu | Erfolgreich |
| #10 | Treiber | Erfolgreich |
| #11 | Automatischer Domänen beitritt | Erfolgreich |
| #12 | Aufrufen einer verschlüsselten Seite | Erfolgreich |
| #13 | Backup | Erfolgreich |
| #14 | Restore | Erfolgreich |
Tabelle 47: Test des Windows 10 Enterprise N
Damit ist die technische Realisierung meiner IPA erfolgreich verlaufen.
Schlussfolgerung und persönliches Fazit
Beim Durchschauen der Tagesjournale sind mir zwei Sachen aufgefallen. Zum einen fiel es mir schwer, Wichtiges von Unwichtigem zu trennen. Dabei half es mir mit dem VF zu diskutieren. In der Diskussion haben sich dabei viele Sachen geklärt. Das hat mir gezeigt, wie wichtig es ist, in einem IT-Projekt Feedback zu bekommen. Zum anderen hatte ich zum Teil Mühe beim Umschreiben von Texten. Dabei habe ich gelernt, dass das Dokumentieren viel Zeit braucht und viel Planung.
Mit meiner IPA bin ich grundsätzlich zufrieden, dennoch konnte ich einiges dazu lernen, obwohl ich das Programm noch nicht so lange kenne.
Literaturverzeichnis
1. Jacob, C. IPERKA. [Online] http://c-jacob.ch/iperka/iperka.pdf.
2. Fogproject. [Online] [Zitat vom: 01. Juni 2021.] https://docs.fogproject.org/en/latest/management/user-management.html.
3. Fog Project. [Online] [Zitat vom: 01. Juni 2021.] https://wiki.fogproject.org/wiki/index.php?title=Power_Management.
4. Fog Project. [Online] [Zitat vom: 01. Juni 2021.] https://wiki.fogproject.org/wiki/index.php/Multicasting.
5. Ionos. [Online] [Zitat vom: 01. 06 2021.] https://www.ionos.de/digitalguide/online-marketing/verkaufen-im-internet/excel-tabelle-in-word-einfuegen/.
6. Proxmox Virtual Environment. [Online] Proxmox, 11. Mai 2021. https://www.proxmox.com/de/proxmox-ve.
7. What is FOG. [Online] FOG-Project. [Zitat vom: 11. Mai 2021.] https://wiki.fogproject.org/wiki/index.php?title=Introduction#What_is_FOG.
8. Features. [Online] [Zitat vom: 11. Mai 2021.] https://wiki.fogproject.org/wiki/index.php?title=Introduction#What_is_FOG.
9. Spicework. [Online] [Zitat vom: 31. Mai 2021.] https://community.spiceworks.com/topic/2231703-wds-2012r2-vs-fog-project-deployment-speed.
10. Thomas Krenn. [Online] [Zitat vom: 31. Mai 2021.] Windows Server 2019 Editionsunterschiede.
11. Wikipedia. [Online] [Zitat vom: 01. Juni 2021.] https://de.wikipedia.org/wiki/Ubuntu.
12. Wiki FOG. [Online] [Zitat vom: 31. Mai 2021.] https://wiki.fogproject.org/wiki/index.php?title=Introduction#What_is_FOG.
13. Microsoft. [Online] Microsoft. [Zitat vom: 11. Mai 2021.] https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/how-configuration-passes-work.
14. Microsoft. [Online] [Zitat vom: 01. Juni 2021.] https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/how-configuration-passes-work.
15. MBR vs. GPT. [Online] [Zitat vom: 11. Mai 2021.] https://www.softwaretestinghelp.com/mbr-vs-gpt/.
16. Digital Guide. [Online] [Zitat vom: 28. Mai 2021.] https://www.ionos.de/digitalguide/server/knowhow/unicast/.
17. vzdump. [Online] vzdump, 12. Mai 2021. [Zitat vom: 12. Mai 2021.] https://pve.proxmox.com/pve-docs/vzdump.1.html.
18. FOG Wiki. [Online] [Zitat vom: 28. Mai 2021.] https://wiki.fogproject.org/wiki/index.php/Multicasting.
19. FOG Project 1.5.9 Documentation. [Online] [Zitat vom: 28. Mai 2021.] https://docs.fogproject.org/en/latest/management/user-management.html.
20. FOG Wiki. [Online] [Zitat vom: 28. Mai 2021.] https://wiki.fogproject.org/wiki/index.php?title=Power_Management.
21. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/BackupPC.
22. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Debian.
23. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Domain_Name_System.
24. FOG Project. [Online] [Zitat vom: 31. Mai 2021.] https://fogproject.org/.
25. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/GitHub.
26. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Proxmox_VE.
27. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Preboot_Execution_Environment.
28. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Server_Message_Block.
29. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol.
30. Wikipedia. [Online] [Zitat vom: 31. Mai 2021.] https://de.wikipedia.org/wiki/Virtual_Local_Area_Network.
31. Ubuntu Version. Wikipedia. [Online] [Zitat vom: 21. Mai 2021.] https://de.wikipedia.org/wiki/Ubuntu.
32. Thomas Krenn, wiki. [Online] [Zitat vom: 21. Mai 2021.] https://www.thomas-krenn.com/de/wiki/Ubuntu_LTS_Hardware_Enablement_Stack.
Glossar
| Begriff | Erklärung |
|---|---|
| ADK | Zusätzliches Softwarepaket |
| Answer File | Antworten auf Konfigurationsfragen |
| BackupPC | BackupPC ist eine freie Disk-zu-Disk Backup-Suite mit einem webbasierten Frontend. Es ist kein spezieller Client notwendig, da der Server selbst unterschiedliche Protokolle unterstützt. (17) |
| BIOS/UEFI | UEFI= Unified Extensible Firmware Interface BIOS= Basic Input Output System Firmware eines jeden Computers. 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 | Vorgang, bei welchem ein bereits aufgesetzter Client mit Software versehen und dessen Installation als Image auf den Server hochgeladen wird. |
| Debian Linux | Debian ist ein gemeinschaftlich entwickeltes freies Betriebssystem. Debian GNU/Linux basiert auf den grundlegenden Systemwerkzeugen des GNU-Projektes sowie dem Linux-Kernel. (18) |
| Deploy | Automatisierte Verteilung von Software oder Betriebssystemen über das LAN oder per Offline-Media |
| DNS-Forward Lookup Zone | Domainnamen in IP-Adressen (19) |
| DNS Reverse-Lookup Zone | IP-Adressen in Domainnamen (19) |
| FOG Project | Eine kostenlose Open-Source-Lösung zum Klonen und Verwalten von Netzwerkcomputern. (20) |
| GitHub | GitHub ist ein netzbasierter Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte. Namensgebend war das Versionsverwaltungssystem Git. (21) |
| GPT | GUID Partition Table ist ein Standard für das Format von Partitionstabellen auf Datenträgern wie beispielsweise Festplatten. |
| MBR | Master Boot Record Enthält ein Startprogramm für BIOS-basierte Computer und eine Partitionstabelle. |
| Multicasting | Mehrere aktive Clients, welche in einem Stream Dateien beziehen |
| Proxmox VE | Proxmox VE ist eine auf Debian basierende Open-Source-Virtualisierungsplattform zum Betrieb von virtuellen Maschinen mit einer Web-Oberfläche zur Einrichtung und Steuerung von x86-Virtualisierungen. (22) |
| PXE | Das Preboot Execution Environment ist ein ursprünglich von der Firma Intel entwickeltes Client-Server-Modell, um netzwerkfähige Rechner, die sogenannten Clients, von einem Server ausgehend über ein lokales Rechnernetz booten zu können. (23) |
| rsync | Startet zur gewünschten Zeit den rsync-Befehl und kopiert alle gewünschten Files eines Servers. |
| smb | Server Message Block, in einer Ur-Version auch als Common Internet File System bezeichnet, ist ein Netzprotokoll für Datei-, Druck- und andere Serverdienste in Rechnernetzen. (24) |
| Sysprep | Nach Abschluss aller gewählten Installationen und Konfigurationen im Audit-Modus, werden sämtliche eindeutigen Systeminformationen selbsttätig aus der Windows-Installation mittels Sysprep entfernt |
| TFTP | Das Trivial File Transfer Protocol ist ein sehr einfaches Dateiübertragungsprotokoll. (25) |
| Unicast | Server schickt jedem Client separat die Datenblöcke |
| VLAN | Ein Virtual Local Area Network ist ein logisches Teilnetz innerhalb eines Switches bzw. eines gesamten physischen Netzwerks. (26) |
Weitere Materialien
redircmp.bat
Firmenstandards Netzerk der Rafisa Informatik GmbH
| Version | Status | Datum | Author | URL |
|---|---|---|---|---|
| 0.1 | Erster Entwurf | 08.08.2019 | Egil Rüefli | |
| 0.2 | Ergänzungen | 08.09.2019 | Richi Stammherr, Tim de Vries, Silvan Dux, Egil Rüefli | |
| 1.0 | Review und Freigabe | 08.09.2020 | Richi Stammherr, Egil Rüefli |
Subnetz-Konzept
Alle Standorte erhalten ein /24 Netz aus dem grösseren privaten Netz 172.16/12, dh. 172.16.0.0/16 bis 172.31.0.0/16. Die VLANs werden dann in die jeweiligen /24-Subnetze unterteilt, also z.B. 172.16.1.0/24, 172.16.2.0/24 usw.
| Netzadressbereich | CIDR-Notation | Verkürzte CIDR-Notation | Anzahl Adressen | Anzahl Netze gemäß Netzklasse (historisch) |
|---|---|---|---|---|
| 172.16.0.0 bis 172.31.255.255 | 172.16.0.0/12 | 172.16/12 | 220 = 1.048.576 | Klasse B: 16 private Netze mit jeweils 65.536 Adressen; 172.16.0.0/16 bis 172.31.0.0/16 |
<HTML><ol start=„2“></HTML> <HTML><li></HTML>
VLANs der Rafisa Dietikon
<HTML><ol></HTML> <HTML><li></HTML>
zh.rafisa.org-172.16.0.0/12
<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>
| VLAN Name | Kürzel | Funktion | VID | IP-Adresse | FW-Interface-Name | DHCP-Server |
|---|---|---|---|---|---|---|
| VLAN Management | 01 | |||||
| VLAN01 | MGMT | Management | 01 | 172.16.1.0/24 | VLAN01_MGMT | ❌ |
| VLAN Server | 10-19 | |||||
| VLAN10 | SRVAUTH | Server Authentifizierung | 10 | 172.16.10.0/24 | VLAN10_SRVAUTH | ❌ |
| VLAN14 | SRVEMPL | Server Ausbildner | 14 | 172.16.14.0/24 | VLAN14_SRVEMPL | ❌ |
| VLAN15 | SRVLEARN | Server Lernende | 15 | 172.16.15.0/24 | VLAN15_SRVLEARN | ❌ |
| VLAN Clients | 20-29 | |||||
| VLAN21 | CLEMPL | Clients Ausbildner | 21 | 172.16.21.0/24 | VLAN21_CLEMPL | ✔️ |
| VLAN22 | CLLEARN | Clients Lernende | 22 | 172.16.22.0/24 | VLAN22_CLLEARN | ✔️ |
| VLAN23 | CLGUEST | Clients Guest (WLAN) | 23 | 172.16.23.0/24 | VLAN23_CLGUEST | ✔️ |
| VLAN Drucker | 40 | |||||
| VLAN40 | LP | Drucker | 40 | 172.16.40.0/24 | VLAN40_LP | ❌ |
| VLAN Labor | 50-59 | |||||
| VLAN51 | LAB01 | Labor 01 | 51 | 172.16.51.0/24 | VLAN51_LAB01 | ✔️ |
| VLAN52 | LAB02 | Labor 02 | 52 | 172.16.52.0/24 | VLAN52_LAB02 | ✔️ |
| VLAN53 | LAB03 | Labor 03 | 53 | 172.16.53.0/24 | VLAN53_LAB03 | ✔️ |
| VLAN54 | LAB04 | Labor 04 | 54 | 172.16.54.0/24 | VLAN54_LAB04 | ✔️ |
| VLAN55 | LAB05 | Labor 05 | 55 | 172.16.55.0/24 | VLAN55_LAB05 | ✔️ |
Berechtigungsmatrix
Die Matrix wird Zeile nach Spalte gelesen (Zugriff von Zeile nach Spalte erlaubt/nicht erlaubt)
| VLAN | 01 | 10 | 14 | 15 | 21 | 22 | 23 | 40 | 51 | 52 | 53 | 54 | 55 | WAN | VPN-EXT |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 01 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 10 | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
| 14 | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 15 | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 21 | ❌ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 22 | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 23 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 40 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 51 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 52 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| 53 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ✔️ | ❌ |
| 54 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ✔️ | ❌ |
| 55 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ | ❌ |
| WAN | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| VPN-EXT | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ |
IP-Zuteilung der Geräte der Rafisa Standort Dietikon
| VLAN | Kürzel/Hostname | IP-Adresse | Funktion | Ort |
|---|---|---|---|---|
| VLAN Management | ||||
| VLAN01 | MGMT | 172.16.1.0/24 | Management | |
| fw-zh-ruga-01 | 172.16.1.1 | Firewall | ||
| prox-zh-ruga-01 | 172.16.1.21 | Proxmox VE Node | ||
| prox-zh-ruga-02 | 172.16.1.22 | Proxmox VE Node | ||
| uni-zh-ruga-01 | 172.16.1.30 | Unifi Controller | ||
| ap-zh-01 | 172.16.1.31 | Unifi Accesspoint | ||
| ap-zh-02 | 172.16.1.32 | Unifi Accesspoint | ||
| ap-zh-03 | 172.16.1.33 | Unifi Accesspoint | ||
| ap-zh-04 | 172.16.1.34 | Unifi Accesspoint | ||
| ap-zh-05 | 172.16.1.35 | Unifi Accesspoint | ||
| bkp-zh-r02b-01 | 172.16.1.100 | Backup-Server zh.rafisa.org | ||
| VLAN Authentifizierung | ||||
| VLAN10 | AUTH | 172.16.10.0/24 | ||
| dc-zh-ruga-02 | 172.16.10.22 | DC1 zh.rafisa.org | ||
| dc-zh-ruga-04 | 172.16.10.24 | DC2 zh.rafisa.org | ||
| VLAN Server Ausbildner | ||||
| VLAN14 | SRVEMPL | 172.16.14.0/24 | ||
| fs-zh-ruga-01 | 172.16.14.21 | Fileserver zh.rafisa.org | ||
| VLAN Server Lernende | ||||
| VLAN15 | SRVLEARN | 172.16.15.0/24 | ||
| fs-zh-ruga-01 | 172.16.15.21 | Fileserver zh.rafisa.org |
<HTML><ol start=„4“></HTML> <HTML><li></HTML>
Rafisa Namenskonzept
<HTML><ol></HTML> <HTML><li></HTML>
Benutzer
<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>
Benuternamen setzen sich zusammen aus dem ersten Buchstaben des Vornamens plus dem Nachnamen. Sollten sich bei neuen Nutzern gleichlautende Benutzernamen ergeben, wird die Anzahl Buchstaben des Vornamenkürzels um 1 erhöht.Bei identischen Vor- und Nachnamen wird das Benutzerkürzel um eine fortlaufende Nummer, beginnend bei 01 ergänzt.
Beispiele:
<HTML><ul></HTML> <HTML><li></HTML><HTML><p></HTML>h.muster Hans Muster<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>he.muster Hedwig Muster<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>her.muster Herta Muster<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>h.muster01 Hans Muster<HTML></p></HTML> <HTML><ol></HTML> <HTML><li></HTML>
Gruppen
Geräte
<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ul></HTML>
Der Gerätename setzt sich zusammen aus einem Kürzel für die Funktion, dem Kürzel für den physikalischen Standort sowie einer fortlaufenden Nummer, beginnend bei 01.
Beispiele:
<HTML><ul></HTML> <HTML><li></HTML><HTML><p></HTML>dc-zh-ruga-01<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>sw-zh-r02a-03<HTML></p></HTML> <HTML><ol></HTML> <HTML><li></HTML>
Kürzel für die Funktionsbezeichnungen
<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ul></HTML>
| Kürzel | Funktion |
|---|---|
| bkp | Backup Server |
| dc | Domain Controller |
| ds | Deployment Server |
| fw | Firewall |
| nb | Notebook |
| pc | PC |
| prox | Proxmox VE Server |
| sw | Switch |
Physikalische Standorte
Der physikalische Standort setzt sich zusammen aus dem Kürzel für den Standort sowie einer internen Raumangabe. Bei Geräten, welche in einem Rack stehen, werden anstelle der Raumangabe das Kürzel für das Rack angegeben.
Beispiele:
<HTML><ul></HTML> <HTML><li></HTML><HTML><p></HTML>zh-ruga<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>zh-201<HTML></p></HTML> <HTML><ol></HTML> <HTML><li></HTML>
Kürzel für die Standorte
<HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ul></HTML>
| Kürzel | Standortbezeichnung |
|---|---|
| be | Bern |
| fr | Fribourg |
| zg | Zug |
| zh | Zürich |
Kürzel für die internen Räume
| Zürich | |
|---|---|
| Kürzel | Ort |
| 200 | Raum 200 im 2. Stock |
| 201 | Raum 101 im 2. Stock |
Kürzel für Racks
| Zürich | |
|---|---|
| Kürzel | Racknummer |
| ruga | Rack A im Untergeschoss |
| rugb | Rack B im Untergeschoss |
| r02a | Rack A im 2. Stock |
| r02b | Rack B im 2. Stock |
| r03a | Rack A im 3. Stock |
| r03b | Rack B im 3. Stock |
| r03c | Rack C im 3. Stock |
| r03d | Rack D im 3. Stock |
| r04a | Rack A im 4. Stock |