In vielen Betrieben ist die IT über die Jahre Stück für Stück gewachsen, ohne ein durchgehendes Konzept dahinter. Geräte kommen dazu, andere werden ersetzt, und irgendwann hat man eine Vielzahl an Rechnern, die zwar funktionieren, aber sehr unterschiedlich aufgesetzt sind und sich kaum noch nachvollziehen lassen. Genau das war die Ausgangslage für mein Abschlussprojekt der Lehre. An der Benedict Schule Zürich existierte kein zentrales System, mit dem sich Windows-Installationen standardisiert erstellen und verteilen liessen. Neue oder zu ersetzende Geräte wurden teilweise von Hand aufgesetzt. Das kostete Zeit, führte zu unterschiedlichen Systemständen und machte es schwer, im Nachhinein zu sagen, warum ein bestimmter Rechner so eingerichtet war, wie er war.
Meine Aufgabe bestand darin, dafür eine saubere Lösung zu schaffen. Es sollte eine Plattform entstehen, mit der sich definierte Referenz-Images verwalten, testen und immer wieder identisch ausrollen lassen. Der Anspruch war ausdrücklich nicht ein produktiver Massenrollout für mehrere hundert Geräte, sondern eine technisch funktionsfähige und vollständig dokumentierte Grundlage, die eine Fachperson später übernehmen und weiterentwickeln kann.
Was Imaging überhaupt bedeutet
Bevor ich auf die konkrete Umsetzung eingehe, lohnt sich ein kurzer Blick darauf, wie ein Windows-Deployment grundsätzlich abläuft. Es geht dabei um mehr als nur darum, ein Betriebssystem zu installieren. Zuerst wird ein Referenzsystem erstellt. Dieses installiert man in einer virtuellen Maschine, konfiguriert es und stattet es mit der gewünschten Software aus. Wenn dieses System genau so aussieht, wie es soll, wird es über einen sogenannten Capture-Prozess erfasst und als standardisiertes Image gespeichert.
Dieses Image bindet man anschliessend in eine Task Sequence ein. Eine Task Sequence ist eine festgelegte Abfolge von Installations- und Konfigurationsschritten. Sie sorgt dafür, dass auf jedem Zielgerät dieselben Schritte in derselben Reihenfolge ablaufen, vom Aufspielen des Betriebssystems über die Treiberintegration bis zu den abschliessenden Systemeinstellungen. Am Ende steht ein Rechner, der reproduzierbar denselben Zustand hat wie der nächste. Genau diese Wiederholbarkeit ist der eigentliche Gewinn gegenüber einer Installation von Hand.
Die Architektur
Als technische Basis habe ich auf einem dedizierten Server die Virtualisierungsplattform Proxmox VE betrieben. Der Host verfügte über einen Intel Core i7 Prozessor, 32 GB Arbeitsspeicher und eine ein Terabyte grosse NVMe-SSD. Auf dieser Plattform lief eine virtuelle Maschine mit Windows Server 2022, die ich MDT-SRV01 genannt und mit der festen Adresse 192.168.50.10 versehen habe. Dieser Server übernahm alle für das Deployment relevanten Rollen.
Im Zentrum stand das Microsoft Deployment Toolkit, kurz MDT. Es verwaltet die Betriebssysteme, die Treiber, die Anwendungen und die Task Sequences. Damit MDT funktioniert, braucht es das Windows Assessment and Deployment Kit sowie das WinPE Add-on. Hinzu kamen die Windows Deployment Services für den Netzwerkstart über PXE sowie ein DHCP- und ein DNS-Dienst, damit die Clients im Testnetz eine Adresse erhalten und sich gegenseitig finden. Drei weitere virtuelle Maschinen dienten als Master-Systeme, aus denen später die Referenz-Images entstanden.
Diese drei Profile bilden den Kern der Lösung. Das Schulprofil ist für die Laptops im Unterricht gedacht und enthält ausschliesslich Software, die für den Schulbetrieb relevant ist. Das Mitarbeiterprofil richtet sich an Verwaltung und Administration und bringt zusätzlich eine betriebsrelevante Datenbankapplikation mit. Das dritte Profil ist technisch eng mit dem Mitarbeiterprofil verwandt, läuft aber vollständig auf Englisch, weil es für den Standort der Business and Hotel Management School in Luzern bestimmt ist. Die Bereitstellung sollte auf zwei Wegen möglich sein. Der eine ist die vollautomatische Installation über das Netzwerk per PXE, der andere ein bootfähiger USB-Stick für Situationen ohne Netzwerkverbindung.
Warum diese Werkzeuge
Eine reine Bauanleitung wäre wenig wert, wenn die Entscheidungen dahinter nicht begründet sind. Deshalb habe ich sowohl die Virtualisierungsplattform als auch die Deployment-Lösung anhand einer strukturierten Bewertung ausgewählt, mit klar definierten Kriterien und festen Gewichtungen, die ich vor der eigentlichen Bewertung festgelegt habe.
Bei der Virtualisierung standen Proxmox VE, Microsoft Hyper-V und VMware ESXi zur Auswahl. ESXi schied aus, weil im Rahmen des Projekts keine Lizenzkosten anfallen durften. Hyper-V scheiterte am Wunsch nach einer rein webbasierten Verwaltung, da es einen separaten Client voraussetzt. Proxmox erfüllte alle Ausschlusskriterien und überzeugte zusätzlich durch ein übersichtliches Webinterface, integrierte Backups und eine zuverlässige Snapshot-Funktion. Hinzu kam ein praktischer Vorteil, den ich nicht unterschätzen wollte. Ich arbeite privat wie auch im Betrieb bereits mit Proxmox und kenne die typischen Probleme, die dabei auftreten können. Dieses Vorwissen senkte das Risiko spürbar und liess mir innerhalb des engen Zeitrahmens mehr Luft für die anspruchsvollen Teile.
Bei der Deployment-Lösung verglich ich MDT in Kombination mit WDS gegen WDS allein, gegen die Open-Source-Lösung FOG und gegen Microsoft Intune mit Autopilot. WDS allein bietet keine Task Sequences und fiel deshalb durch. Intune ist cloudbasiert und passt schlecht zu einer Umgebung, die bewusst lokal und unter voller Kontrolle betrieben werden soll. FOG arbeitet vor allem klonbasiert und ist in der Konfiguration weniger strukturiert. MDT mit WDS blieb als einzige Lösung übrig, die alle Anforderungen erfüllte, und überzeugte gerade durch die flexible Steuerung über Task Sequences sowie durch die saubere Verwaltung mehrerer Profile.
Wo es interessant wurde
Ein Projekt, das ohne Hürden durchläuft, gibt es selten, und die spannendsten Lerneffekte stecken meistens genau in diesen Hürden. Bei mir gab es drei, die ich gerne genauer erzähle.
Die erste betraf den Capture-Prozess. Ich hatte die damals neueste Version des ADK installiert, die vom November 2025. Beim Versuch, das Referenzsystem zu erfassen, scheiterte die Verbindung zum Deployment Share, weil WinPE die virtuelle Netzwerkkarte nicht automatisch erkannte. Nach einer systematischen Fehleranalyse stellte sich die ADK-Version als Ursache heraus. Die Lösung bestand darin, gezielt auf das ältere und kompatible ADK 22H2 herabzustufen. Danach wurde die Netzwerkkarte korrekt erkannt und der Capture lief für alle drei Profile durch. Das war eine gute Erinnerung daran, dass die neueste Version nicht immer die beste ist.
Die zweite Hürde war Sysprep. Ursprünglich wollte ich auf jeder Master-VM vor dem Capture den klassischen Sysprep-Befehl ausführen, um Hardware-Informationen zu entfernen und die Sicherheitskennung zurückzusetzen. Dabei traten wiederholt Fehler auf. Nach einer Analyse zeigte sich, dass dieser manuelle Schritt für den Weg über MDT gar nicht zwingend nötig ist, weil MDT den Sysprep-Vorgang innerhalb der Task Sequence selbst übernimmt. Statt lange an der manuellen Variante hängenzubleiben, habe ich auf sie verzichtet und stattdessen mit Snapshots als Sicherungspunkten gearbeitet.
Die dritte Einschränkung betraf den PXE-Start. Auf einem physischen Laptop funktionierte der Netzwerkstart einwandfrei. Innerhalb der virtuellen Maschinen in Proxmox kam es dagegen zu Kompatibilitätsproblemen zwischen UEFI und SeaBIOS, und es fehlte ein passender Netzwerktreiber. Wichtig war hier die Einordnung. Das Deployment ist auf physische Arbeitsplatzrechner ausgerichtet, und genau dort lief PXE problemlos. Die Einschränkung in der virtuellen Umgebung war für den vorgesehenen Einsatz also nicht relevant. Ich habe sie trotzdem sauber dokumentiert, weil ein ehrlich beschriebenes Detail mehr wert ist als eine schöngeredete Erfolgsgeschichte.
Das Ergebnis
Am Ende stand eine funktionsfähige Imaging-Lösung, mit der sich standardisierte Windows-Installationen effizient bereitstellen lassen. Von vierzehn definierten Testfällen bestanden dreizehn. Der einzige nicht bestandene Test war der bereits erwähnte PXE-Start in der virtuellen Maschine, dessen Ergebnis so erwartet und begründet war.
Der praktische Gewinn lässt sich gut in Zahlen fassen. Eine manuelle Installation eines Arbeitsplatzes dauerte bisher erfahrungsgemäss zwei bis drei Stunden. Mit der neuen Lösung reduziert sich der eigentliche Deployment-Vorgang über PXE auf rund dreissig bis fünfundvierzig Minuten, zu denen noch eine kleine Nachkonfiguration kommt. Dazu kommen die einheitlichen Systemstände, die saubere Versionierung über ein Change-Log und ein Backup-Konzept mit Snapshots und mehrfacher Sicherung. Eine kurze Instruktion mit einem Praktikanten rundete das Projekt ab und zeigte, dass die Lösung auch tatsächlich übergeben werden kann.
Was ich mitnehme
Methodisch habe ich das Projekt nach IPERKA strukturiert, also entlang der Phasen Informieren, Planen, Entscheiden, Realisieren, Kontrollieren und Auswerten. Diese klare Trennung half mir, fokussiert zu bleiben und den Überblick zu behalten, auch wenn technisch viel gleichzeitig im Fluss war.
Fachlich war es das erste Mal, dass ich ein Projekt von der Analyse über die Planung bis zur vollständigen Umsetzung eigenständig durchgezogen und dokumentiert habe. Am meisten gelernt habe ich allerdings nicht an den Stellen, an denen alles glattlief, sondern an den Problemen. Eine ruhige und systematische Fehlersuche bringt einen weiter als hektisches Ausprobieren. Und eine Dokumentation, die parallel zur technischen Arbeit entsteht, kostet im Moment zwar Zeit, spart aber später deutlich mehr davon, als sie gekostet hat. Beides nehme ich aus diesem Projekt mit, und beides ist weit über das Thema Windows-Imaging hinaus nützlich.