WDS-Alternative: Windows per PXE mit iPXE und Unattend – Grams IT

Wer Windows-Rechner bisher per Netzwerkboot und Antwortdatei installiert hat, sucht seit April 2026 eine WDS-Alternative. Microsoft hat die Hands-free-Installation über Windows Deployment Services standardmäßig abgeschaltet, das Microsoft Deployment Toolkit ist eingestellt, und im September 2026 kam die Ankündigung, dass die WDS-Serverrolle mit dem nächsten Windows Server abgekündigt wird. Was bleibt, ist PXE als Standard und die Frage, welches Werkzeug den Teil übernimmt, den WDS bisher erledigt hat.

Dieser Artikel stellt die freien Kandidaten vor, von iVentoy über netboot.xyz und OSDCloud bis zu FOG und Clonezilla, und sagt, welche davon halten, was sie versprechen. Meine Empfehlung ist eine Kombination, die vollständig aus Open-Source-Bausteinen und Microsoft-Bordmitteln besteht: iPXE mit dem inzwischen von Microsoft signierten Shim, wimboot, ein selbst gebautes WinPE, eine Samba-Freigabe und eine autounattend.xml. Der zweite Teil ist eine vollständige Anleitung mit allen Konsolenbefehlen, vom leeren Linux-Server bis zum unbeaufsichtigt installierten Windows 11.

Vorweg: Das ist mehr Handarbeit als „WDS-Rolle hinzufügen”. Dafür verstehen Sie danach jedes Glied der Bootkette, und keine Lizenzbedingung, kein geschlossener Binärblob und keine Abkündigung kann sie Ihnen wegnehmen.

Was mit WDS passiert ist: der Stand im November 2026

Die Abkündigung kam in Etappen. Microsoft fasst sie selbst in einem Support-Artikel vom 21. September 2026 zusammen:

2021: Setup-Abläufe, die die boot.wim vom Installationsmedium im WDS-Modus verwenden, gelten für Windows 11 und neuer als veraltet. Laut der Microsoft-Seite zur boot.wim-Unterstützung lässt sich Windows 11 damit nicht mehr Ende-zu-Ende nur mit WDS installieren. Eigene Bootimages per PXE blieben möglich.
1. Januar 2026: Microsoft stellt das Microsoft Deployment Toolkit (MDT) mit sofortiger Wirkung ein. Keine Updates, keine Fehlerbehebungen, kein Support mehr; als Ersatz nennt Microsoft nur Autopilot und Configuration Manager.
1. April 2026: Mit den Sicherheitsupdates ab diesem Tag ist die Hands-free-Installation mit WDS standardmäßig deaktiviert und wird nicht mehr unterstützt.
Nächstes Windows Server: Die WDS-Rolle samt PXE-Funktion, Multicast und den WinPE-WDS-Tools wird abgekündigt. Wann sie ganz verschwindet, lässt Microsoft offen, möglicherweise mit dem nächsten LTSC-Release, vielleicht auch erst einige Versionen später.

Auf Windows Server 2025 und älter läuft WDS also weiter, nur eben ohne Zukunft und ohne den Teil, für den viele es eingesetzt haben. Der Petri-Artikel „Windows Deployment Services Alternatives: 5 Options to Consider” beschreibt diesen Umbruch eher gelassen und empfiehlt Autopilot, Configuration Manager oder USB-Sticks. Das ist aus Microsoft-Sicht konsequent, hilft aber wenig, wenn Sie weder Intune-Lizenzen noch eine Configuration-Manager-Infrastruktur haben und trotzdem Geräte frisch aufsetzen müssen. Erwähnenswert aus dem KB-Artikel: Der PXE-Responder von Configuration Manager ohne WDS beherrscht nur Unicast, Multicast-Szenarien müssen neu geplant werden.

Eine Sache stellt Microsoft selbst klar, und sie ist der Ausgangspunkt dieses Artikels: Unabhängige PXE-Lösungen, die nicht auf die eingebaute WDS-Rolle angewiesen sind, sind von der Abkündigung ausdrücklich nicht betroffen. Und laut der boot.wim-Seite lässt sich Windows Setup weiterhin von einer Netzwerkfreigabe starten.

CVE-2026-0386: Warum Hands-free abgeschaltet wurde

Die Hands-free-Installation in WDS lieferte die Unattend.xml an den Client aus, um die Setup-Bildschirme zu automatisieren, einschließlich Anmeldedaten. Das Problem: Die Datei lief über einen nicht authentifizierten RPC-Kanal. Wer im selben Netz mitlesen konnte, konnte die Antwortdatei abfangen, und damit alles, was darin stand. Microsoft hat die Lücke als CVE-2026-0386 geführt und in zwei Phasen reagiert: Ab Januar 2026 ließ sich die Funktion per Registry abschalten, seit April 2026 ist sie standardmäßig aus.

Zurückholen lässt sie sich mit dem DWORD AllowHandsFreeFunctionality = 1 unter HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend. Microsoft nennt das ausdrücklich unsicher und protokolliert es im Ereignisprotokoll als Fehler. Ich würde das nicht tun.

Wichtiger ist die Lehre daraus, und die gilt für jede der folgenden Alternativen: Eine Antwortdatei, die unverschlüsselt über das Netz geht, ist öffentlich. Egal ob sie per RPC, per HTTP vom iPXE-Server oder von einer Gast-Freigabe kommt. Wer CVE-2026-0386 ernst nimmt, schreibt keine Geheimnisse in die autounattend.xml oder akzeptiert bewusst, welche drinstehen. Dazu unten mehr.

Die freien WDS-Alternativen im Überblick

Die Werkzeuge lassen sich in zwei Gruppen teilen, und die Unterscheidung ist wichtiger als jede Feature-Liste. Die erste Gruppe installiert Windows aus dem Original-ISO mit Windows Setup und Antwortdatei, das ist der Ablauf, den WDS mit Hands-free abgebildet hat. Die zweite Gruppe verteilt Images: Sie bereiten einen Referenzrechner vor, ziehen ein Abbild und spielen es auf andere Rechner. Beides hat seinen Platz, löst aber unterschiedliche Probleme.

Werkzeug	Lizenz	Ansatz	Unattend	Secure Boot	Kommerzielle Nutzung
iVentoy Free	proprietär, Server-Code geschlossen	ISO direkt per PXE	ja, Vorlage pro ISO	laut Anleitungen aus	nein (Pro: 49 $)
Serva Community	proprietär	PXE/BINL-Server für Windows	ja	nein	nein (Pro: 92 $/Jahr)
netboot.xyz	Open Source	iPXE-Menü, Windows über WinPE + SMB	selbst bauen	ja, signierte Images	ja
iPXE + wimboot + WinPE	Open Source + ADK	WinPE per HTTP, Setup von SMB	ja, autounattend.xml	ja, signierter Shim	ja
OSDCloud	GPL-3.0	PowerShell-Framework in WinPE	eigene Automatik (Parameter)	über WinPE	ja
FOG Project	Open Source	Imaging per PXE und Web-GUI	über Sysprep im Image	eingeschränkt	ja
Clonezilla SE	Open Source	Imaging, Multicast über DRBL	über Sysprep im Image	–	ja

iVentoy: schnell, aber mit Fragezeichen

iVentoy stammt vom Entwickler des bekannten USB-Werkzeugs Ventoy und ist die bequemste Lösung in dieser Liste. Sie legen ISO-Dateien in einen Ordner, starten den Server, und die Clients booten per PXE in ein Menü, aus dem sie das ISO auswählen. Nichts wird entpackt, keine Bootimages vorbereitet. Für die Automatisierung hinterlegen Sie laut iVentoy-Dokumentation im Web-GUI pro ISO eine oder mehrere Unattend-Vorlagen; das Original-ISO bleibt unverändert. Variablen wie $$VT_WINDOWS_DISK_1ST_NONUSB$$ für die erste Nicht-USB-Platte oder die MAC-Adresse des Clients machen die Vorlagen flexibel. Neben dem eingebauten DHCP-Server gibt es die Modi External und ExternalNet für ein vorhandenes DHCP, und seit Version 1.0.23 einen Proxy-DHCP-Modus.

Die Fragezeichen: Die Free-Edition ist auf 20 Clients begrenzt und nicht für kommerzielle Umgebungen gedacht, die Pro-Edition kostet 49 $. Der Server-Teil ist anders als bei Ventoy nicht quelloffen. Im Mai 2025 fiel auf, dass Version 1.0.20 ein selbstsigniertes Root-Zertifikat namens „JemmyLoveJenny EV Root CA0″ und einen Kernel-Treiber mitbrachte; Born City berichtete, VirusTotal stufe das Zertifikat als schädlich ein. Der Entwickler erklärte, Treiber und Zertifikat liefen nur im WinPE-RAM, und entfernte das Zertifikat ab Version 1.0.21. Das spricht eher für schlampige Entwicklungspraxis als für böse Absicht. Für ein Werkzeug, das in die Installation jedes neuen Rechners eingreift, ist es trotzdem ein Argument. Und: Secure Boot muss laut Anleitung von Windows OS Hub für iVentoy abgeschaltet sein.

Für das Testlabor zu Hause ist iVentoy großartig. Für den produktiven Betrieb in einer Organisation brauchen Sie die Pro-Lizenz und müssen mit dem geschlossenen Code leben.

Serva: für den Einzelfall

Serva ist ein Windows-Programm, das DHCP, TFTP, HTTP und einen BINL-Dienst nach WDS-Vorbild in einer portablen Anwendung bündelt. Die Community-Edition ist nur für private, nicht-kommerzielle Nutzung, zeigt unter UEFI maximal zwei Menüeinträge und beherrscht den Modus für Secure Boot nicht. Die Pro-Version kostet 92 $ im Jahr. Wer einmal schnell einen Rechner ohne USB-Stick aufsetzen muss, ist damit gut bedient, als WDS-Ersatz taugt die kostenlose Fassung nicht.

netboot.xyz: das Menü obendrauf

netboot.xyz ist eine Sammlung von iPXE-Menüs, mit denen sich Dutzende Linux-Distributionen und Werkzeuge direkt aus dem Netz booten lassen, auf Wunsch lokal als Docker-Container. Windows ist dabei ein Sonderfall: Sie bauen ein WinPE, tragen dessen Pfad in die boot.cfg ein (win_base_url) und starten nach dem Boot das Setup von einer SMB-Freigabe, wie es Techno Tim in seinem Tutorial Schritt für Schritt zeigt. Inzwischen liefert netboot.xyz auch Secure-Boot-fähige Images, signiert vom iPXE-Projekt.

Technisch ist das dieselbe Kette, die ich unten empfehle, nur mit einem großen Menü davor. Wer ohnehin Linux-Installationen per Netz anbieten will, fährt damit gut. Wer nur Windows verteilt, braucht den Überbau nicht.

OSDCloud: Treiberpakete automatisch

OSDCloud ist ein PowerShell-Modul von David Segura (GPL-3.0), das Windows komplett aus WinPE heraus installiert. Es partitioniert die Platte und lädt das gewünschte Windows wahlweise aus dem Internet oder aus einem lokalen Cache. Admins berichten, dass es das Gerätemodell erkennt und das passende Treiberpaket nachlädt. Gestartet wird per Start-OSDCloudGUI oder nicht-interaktiv mit Start-OSDCloud -OSName ... -OSEdition Pro. Offiziell ist der Weg ein bootfähiger USB-Stick, praktisch lässt sich das OSDCloud-WinPE aber genauso per iPXE und wimboot booten. Mehrere Anbieter bauen darauf auf, etwa Deployment Live mit einem eigenen iPXE oder XOAP mit PXE-Boot.

OSDCloud ist keine Alternative zur empfohlenen Kette, sondern eine Erweiterung für Umgebungen mit vielen unterschiedlichen Gerätemodellen. Der Haken: Standardmäßig lädt es aus dem Internet. In Netzen mit restriktivem Proxy sollten Sie das vorher prüfen.

FOG Project und Clonezilla: wenn Sie Images verteilen

FOG ist eine freie Imaging-Suite mit Web-GUI, Inventarisierung und PXE-Boot, die Windows 10 und 11 per Partclone klont. Seit Version 1.5.10.41 gibt es einen stable-Branch mit monatlichen Patch-Releases, auch wegen mehrerer behobener CVEs. Clonezilla Server Edition setzt auf DRBL und kann per Multicast viele Rechner gleichzeitig bespielen, das ist seine Stärke.

Beide sind gute Werkzeuge, aber für einen anderen Zweck. Sie verteilen ein mit Sysprep vorbereitetes Referenzabbild, kein Original-ISO mit Antwortdatei. Das Image müssen Sie pflegen, jedes Feature-Update heißt: neu aufbauen, neu ziehen. Und bei Secure Boot war FOG bisher schwierig; ein Moderator schrieb im FOG-Forum, mit ausschließlich Microsoft-Schlüsseln in der Firmware gehe mit FOG nichts. Ob der signierte iPXE-Shim das ändert, habe ich nicht getestet.

Die Empfehlung: iPXE mit signiertem Shim, wimboot und WinPE

Für die Aufgabe „Windows aus dem ISO, unbeaufsichtigt, per PXE über DHCP” empfehle ich die Kette aus iPXE, wimboot, WinPE und einer SMB-Freigabe. Drei Gründe:

Erstens Secure Boot. Am 12. November 2025 hat iPXE-Maintainer Michael Brown gemeldet, dass Microsoft den iPXE-Shim signiert hat. Inzwischen stellt das Projekt signierte Binärdateien zum Download bereit. Laut der iPXE-Dokumentation bootet wimboot Windows damit bei aktivem Secure Boot ganz normal; Windows und wimboot sind bereits signiert, an den iPXE-Skripten ändert sich nichts. Bis Ende 2025 war Secure Boot das stärkste Argument gegen iPXE, das ist erledigt.

Zweitens die Bauteile. iPXE und wimboot sind Open Source, dnsmasq, nginx und Samba ebenfalls. WinPE und Windows Setup kommen direkt von Microsoft und sind genau die Komponenten, die Microsoft weiter unterstützt. Nichts davon hängt an der WDS-Rolle.

Drittens die Kontrolle. Die Antwortdatei liegt auf einer authentifizierten, schreibgeschützten Freigabe, nicht auf einem anonymen Kanal. Jede Stufe ist eine Textdatei, die Sie lesen, versionieren und debuggen können.

Der Preis: Sie bauen die Kette selbst zusammen, und ein paar Fallstricke gibt es. Die stehen weiter unten bei der Fehlersuche.

So funktioniert die Bootkette

Bevor es an die Befehle geht, der Ablauf im Ganzen. Er hat sieben Stufen, und wenn später etwas hakt, wissen Sie damit, an welcher Stelle Sie suchen müssen.

Schaubild der Bootkette in sieben Stufen: UEFI-Firmware, Proxy-DHCP mit dnsmasq, shim und snponly.efi per TFTP, iPXE-Skript per HTTP, wimboot, WinPE mit install.bat, sources\setup.exe /unattend von der Samba-Freigabe

Die UEFI-Firmware des Clients startet per PXE und fragt per DHCP nach einer Adresse. Ihr vorhandener DHCP-Server, ob Windows Server, OPNsense oder Router, vergibt die IP wie immer. Parallel antwortet dnsmasq als Proxy-DHCP und nennt nur die Bootdatei, ohne selbst Adressen zu verteilen. Die Firmware lädt per TFTP den Microsoft-signierten Shim, der Shim lädt das vom iPXE-Projekt signierte snponly.efi.

iPXE fragt erneut per DHCP, diesmal mit der User-Class iPXE. Daran erkennt dnsmasq den zweiten Durchlauf und liefert statt der Bootdatei die URL des iPXE-Skripts. Ohne diese Unterscheidung würde iPXE sich selbst endlos nachladen. Das Skript lädt per HTTP wimboot, die boot.wim und zwei kleine Textdateien. wimboot legt die Textdateien beim Start in X:\Windows\System32 des WinPE ab, wo winpeshl.ini sie als Startbefehl ausführt. Das Skript install.bat initialisiert das Netz, verbindet die Samba-Freigabe und startet Windows Setup mit der Antwortdatei.

Voraussetzungen

Für die Anleitung brauchen Sie:

Einen Linux-Server im selben Netzsegment wie die Clients, physisch oder als VM, mit fester IP-Adresse. Die Befehle sind für Debian und Ubuntu geschrieben. Im Beispiel hat der Server die IP 192.168.10.5 im Netz 192.168.10.0/24, die Netzwerkkarte heißt ens18. Passen Sie beides an.
Einen Windows-Rechner als Technikerplatz mit dem Windows ADK und dem WinPE-Add-on. Laut Microsoft unterstützt das ADK 10.1.26100.9457 (September 2026) Windows 11 24H2, 25H2 und 26H2. Das neuere ADK 10.1.28000.3481 ist nur für Windows 11 26H1 gedacht. Spielen Sie den aktuellen ADK-Servicing-Patch ein, Microsoft empfiehlt ihn wegen der WSIM-Lücke CVE-2026-25166.
Ein Windows-11-ISO von Microsoft und die Lizenzierung dazu.
Zugriff auf den DHCP-Server oder zumindest die Möglichkeit, im Netz einen Proxy-DHCP zu betreiben. Prüfen Sie, ob Switches mit DHCP-Snooping Antworten von nicht autorisierten Servern verwerfen.
Clients mit UEFI. Legacy-BIOS lasse ich außen vor, für aktuelle Windows-11-Geräte spielt es praktisch keine Rolle mehr.
Firmware, die der Microsoft-UEFI-CA für Drittanbieter vertraut. Das ist der wichtigste Punkt der Liste. Der Shim ist laut netboot.xyz-Dokumentation mit der Drittanbieter-CA von Microsoft signiert, nicht mit der Windows-CA. Seit 2022 ist es laut Lenovo eine Microsoft-Vorgabe für Secured-core PCs, diese CA standardmäßig zu deaktivieren. Die Einstellung heißt bei Lenovo „Allow Microsoft 3rd Party UEFI CA”, bei HP „Enable MS UEFI CA key”, bei Dell „Enable Microsoft UEFI CA” und bei Surface „Microsoft & 3rd party CA”, wie Matrix42 dokumentiert. Prüfen Sie das an einem Testgerät, bevor Sie die ganze Kette aufbauen.

Benötigte Ports auf dem Server: UDP 67 und 4011 für Proxy-DHCP, UDP 69 für TFTP, TCP 80 für HTTP und TCP 445 für SMB.

Anleitung: Windows per PXE installieren mit iPXE und wimboot

Schritt 1: Pakete auf dem Linux-Server installieren

sudo apt update
sudo apt install dnsmasq nginx samba wimtools wget
sudo mkdir -p /srv/tftp /srv/http/winpe /srv/install

wimtools brauchen Sie nur für wiminfo, um später die Editionsnamen im ISO nachzusehen.

Schritt 2: Signierte iPXE-Binärdateien und wimboot holen

Das iPXE-Projekt stellt die signierten Dateien als Archiv bereit. Für x86_64 enthält es im Ordner x86_64-sb/ die Dateien ipxe.efi, ipxe-shim.efi, shimx64.efi, snponly.efi und snponly-shim.efi.

cd /tmp
wget https://github.com/ipxe/ipxe/releases/latest/download/ipxeboot.tar.gz
sudo tar -xzf ipxeboot.tar.gz -C /srv/tftp
find /srv/tftp -name '*-shim.efi'

Der find-Befehl zeigt Ihnen, wo die Dateien gelandet sind. Ich gehe im Folgenden von /srv/tftp/ipxeboot/x86_64-sb/ aus, so wie im DHCP-Beispiel der iPXE-Dokumentation. Liegt der Ordner bei Ihnen anders, passen Sie den Pfad in Schritt 6 an.

Ich nehme snponly-shim.efi. Die snponly-Variante nutzt den Netzwerktreiber der Firmware statt eigener Treiber und läuft dadurch auf mehr Hardware. Der Shim lädt automatisch die gleichnamige iPXE-Datei, also snponly.efi. Eigene iPXE-Builds mit eingebettetem Skript sind mit Secure Boot nicht möglich; die signierten Builds lassen außerdem einige Funktionen weg, die in einem Secure-Boot-Build verboten sind. Für diesen Zweck fehlt nichts.

Dann wimboot:

sudo wget -O /srv/http/winpe/wimboot https://github.com/ipxe/wimboot/releases/latest/download/wimboot

Schritt 3: WinPE auf dem Technikerplatz bauen

Öffnen Sie auf dem Windows-Rechner die Umgebung für Bereitstellungs- und Imageerstellungstools (englisch „Deployment and Imaging Tools Environment”) als Administrator. Dann:

copype amd64 C:\WinPE_amd64
if not exist C:\WinPE_amd64\mount md C:\WinPE_amd64\mount
Dism /Mount-Image /ImageFile:"C:\WinPE_amd64\media\sources\boot.wim" /index:1 /MountDir:"C:\WinPE_amd64\mount"

Jetzt die deutsche Sprache und ein paar optionale Komponenten. Für net use und Windows Setup brauchen Sie streng genommen keine davon. PowerShell lohnt sich aber, sobald Sie später OSDCloud oder eigene Skripte einsetzen wollen. Die Reihenfolge ist vorgegeben: WinPE-WMI, dann WinPE-NetFx, dann WinPE-Scripting, dann WinPE-PowerShell, jeweils das sprachneutrale Paket vor dem Sprachpaket.

set OC=C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs
set MNT=C:\WinPE_amd64\mount

Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\de-de\lp.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\WinPE-WMI.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\de-de\WinPE-WMI_de-de.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\WinPE-NetFx.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\de-de\WinPE-NetFx_de-de.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\WinPE-Scripting.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\de-de\WinPE-Scripting_de-de.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\WinPE-PowerShell.cab"
Dism /Add-Package /Image:"%MNT%" /PackagePath:"%OC%\de-de\WinPE-PowerShell_de-de.cab"
Dism /Set-AllIntl:de-DE /Image:"%MNT%"

Prüfen Sie vorher, ob das ADK bei Ihnen unter C:\Program Files (x86)\ liegt. Die Microsoft-Dokumentation verwendet in verschiedenen Artikeln beide Pfade.

Der wichtigste Teil sind die Netzwerktreiber. WinPE bringt längst nicht für jede Netzwerkkarte einen Treiber mit, und ohne Netz bleibt die Kette nach dem Boot stehen. Die Treiber holen Sie beim Gerätehersteller. Microsoft empfiehlt, jedes Treiberpaket einzeln hinzuzufügen, weil das die Fehlersuche erleichtert:

REM Beispielpfad, ersetzen Sie ihn durch Ihre .inf-Datei
Dism /Add-Driver /Image:"%MNT%" /Driver:"C:\Treiber\WinPE\netzwerk\treiber.inf"

Danach übernehmen und aushängen:

Dism /Unmount-Image /MountDir:"%MNT%" /commit

Kopieren Sie C:\WinPE_amd64\media\sources\boot.wim auf den Server nach /srv/http/winpe/boot.wim, etwa per scp:

scp C:\WinPE_amd64\media\sources\boot.wim admin@192.168.10.5:/tmp/

sudo mv /tmp/boot.wim /srv/http/winpe/boot.wim

Laut wimboot-Dokumentation holt wimboot den Bootmanager und die BCD selbst aus der WIM-Datei, eigene Kopien von BCD und boot.sdi brauchen Sie nicht.

Schritt 4: Windows-Dateien auf die Samba-Freigabe legen

Kopieren Sie das ISO auf den Server und entpacken Sie es in die Freigabe:

sudo mkdir -p /mnt/iso /srv/install/win11
sudo mount -o loop,ro /pfad/zu/Win11_25H2_German_x64.iso /mnt/iso
sudo cp -r /mnt/iso/. /srv/install/win11/
sudo umount /mnt/iso
ls /srv/install/win11/sources/install.*
wiminfo /srv/install/win11/sources/install.wim | grep -E '^(Index|Name)'

Die letzte Zeile zeigt die Editionen mit ihren Namen. Den exakten Namen der gewünschten Edition brauchen Sie gleich für die Antwortdatei. Liegt statt install.wim eine install.esd vor, setzen Sie deren Pfad ein.

Jetzt ein eigener Benutzer nur für die Installation, ohne Login und ohne Schreibrechte:

sudo useradd -M -s /usr/sbin/nologin deploy
sudo smbpasswd -a deploy

Ans Ende von /etc/samba/smb.conf kommt die Freigabe:

[install]
   path = /srv/install
   read only = yes
   browseable = no
   valid users = deploy
   guest ok = no

testparm -s
sudo systemctl restart smbd

Warum kein Gastzugriff? Seit Windows 11 24H2 verlangt der SMB-Client standardmäßig Signierung, worauf etwa ASUS unter Verweis auf Microsoft hinweist, und laut Microsoft lehnt der Client bei aktiver Signierung unsichere Gastanmeldungen ab. Ob sich das WinPE aus dem aktuellen ADK in jedem Detail gleich verhält, habe ich nicht belastbar dokumentiert gefunden. Ein authentifizierter Benutzer umgeht die Frage, und er ist ohnehin der sauberere Weg.

Schritt 5: Die autounattend.xml erstellen

Am bequemsten erstellen Sie die Antwortdatei mit dem Generator von Christoph Schneegans, der laut eigener Angabe Windows 11 bis 26H2 unterstützt. Für ein erstes Testsystem reicht aber auch eine knappe Datei. Testen Sie sie in einer VM, bevor sie auf echte Geräte losgelassen wird. Die folgende löscht Datenträger 0 ohne Rückfrage, legt die üblichen drei UEFI-Partitionen an und installiert Windows 11 Pro:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend"
          xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
  <settings pass="windowsPE">
    <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <SetupUILanguage><UILanguage>de-DE</UILanguage></SetupUILanguage>
      <InputLocale>0407:00000407</InputLocale>
      <SystemLocale>de-DE</SystemLocale>
      <UILanguage>de-DE</UILanguage>
      <UserLocale>de-DE</UserLocale>
    </component>
    <component name="Microsoft-Windows-Setup" processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <DiskConfiguration>
        <Disk wcm:action="add">
          <DiskID>0</DiskID>
          <WillWipeDisk>true</WillWipeDisk>
          <CreatePartitions>
            <CreatePartition wcm:action="add"><Order>1</Order><Type>EFI</Type><Size>300</Size></CreatePartition>
            <CreatePartition wcm:action="add"><Order>2</Order><Type>MSR</Type><Size>16</Size></CreatePartition>
            <CreatePartition wcm:action="add"><Order>3</Order><Type>Primary</Type><Extend>true</Extend></CreatePartition>
          </CreatePartitions>
          <ModifyPartitions>
            <ModifyPartition wcm:action="add"><Order>1</Order><PartitionID>1</PartitionID><Format>FAT32</Format><Label>System</Label></ModifyPartition>
            <ModifyPartition wcm:action="add"><Order>2</Order><PartitionID>2</PartitionID></ModifyPartition>
            <ModifyPartition wcm:action="add"><Order>3</Order><PartitionID>3</PartitionID><Format>NTFS</Format><Label>Windows</Label><Letter>C</Letter></ModifyPartition>
          </ModifyPartitions>
        </Disk>
      </DiskConfiguration>
      <ImageInstall>
        <OSImage>
          <InstallFrom>
            <MetaData wcm:action="add"><Key>/IMAGE/NAME</Key><Value>Windows 11 Pro</Value></MetaData>
          </InstallFrom>
          <InstallTo><DiskID>0</DiskID><PartitionID>3</PartitionID></InstallTo>
        </OSImage>
      </ImageInstall>
      <UserData>
        <AcceptEula>true</AcceptEula>
        <!-- KMS-Client-Schlüssel (GVLK) für Windows 11 Pro, nur mit KMS-Host/Volumenlizenz sinnvoll -->
        <ProductKey><Key>W269N-WFGWX-YVC9B-4J6C9-T83GX</Key></ProductKey>
      </UserData>
    </component>
  </settings>
  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <TimeZone>W. Europe Standard Time</TimeZone>
      <OOBE>
        <HideEULAPage>true</HideEULAPage>
        <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
        <ProtectYourPC>3</ProtectYourPC>
      </OOBE>
      <UserAccounts>
        <LocalAccounts>
          <LocalAccount wcm:action="add">
            <Name>setup</Name>
            <Group>Administrators</Group>
            <Password><Value>BITTE-AENDERN</Value><PlainText>true</PlainText></Password>
          </LocalAccount>
        </LocalAccounts>
      </UserAccounts>
    </component>
  </settings>
</unattend>

Drei Hinweise dazu. Der Produktschlüssel ist der KMS-Client-Schlüssel, den Microsoft öffentlich dokumentiert. Er aktiviert nur gegen einen KMS-Host und nicht als Einzelhandelslizenz. Ohne Volumenlizenz nehmen Sie im Generator die Option, den Schlüssel aus der Firmware zu übernehmen. Der Editionsname in /IMAGE/NAME muss exakt dem entsprechen, was wiminfo in Schritt 4 ausgegeben hat. Und das lokale Konto mit Klartextkennwort ist das einzige Geheimnis in der Datei. Dazu gleich mehr.

sudo cp autounattend.xml /srv/install/autounattend.xml

Schritt 6: dnsmasq als Proxy-DHCP und TFTP-Server

Der Proxy-Modus ist der Grund, warum diese Lösung neben jedem vorhandenen DHCP-Server läuft. dnsmasq vergibt keine Adressen, sondern liefert nur die Bootinformationen nach. Legen Sie /etc/dnsmasq.d/pxe.conf an:

# Kein DNS-Dienst, nur Proxy-DHCP und TFTP
port=0
interface=ens18
bind-interfaces
log-dhcp

# Proxy-Modus: IP-Adressen vergibt der vorhandene DHCP-Server
dhcp-range=192.168.10.0,proxy

# TFTP für shim und iPXE
enable-tftp
tftp-root=/srv/tftp

# Zweiter Durchlauf: iPXE meldet sich mit der User-Class "iPXE"
dhcp-userclass=set:ipxe,iPXE

# Erster Durchlauf: UEFI-Firmware bekommt den signierten Shim
pxe-service=tag:!ipxe,x86-64_EFI,"iPXE Secure Boot",ipxeboot/x86_64-sb/snponly-shim.efi
pxe-service=tag:!ipxe,BC_EFI,"iPXE Secure Boot",ipxeboot/x86_64-sb/snponly-shim.efi

# Zweiter Durchlauf: iPXE bekommt die Skript-URL
dhcp-boot=tag:ipxe,http://192.168.10.5/boot.ipxe

Weil der Dateiname komplett mit Endung angegeben ist, hängt dnsmasq laut Handbuch kein .0 an. Die BC_EFI-Zeile steht da, weil manche x64-Firmware sich mit Architekturkennung 9 statt 7 meldet; das iPXE-Beispiel für Proxy-DHCP macht es genauso.

sudo systemctl restart dnsmasq
sudo journalctl -u dnsmasq -f

Lassen Sie das Log beim ersten Test offen. Sie sehen darin für jeden Client die Vendor-Class (PXEClient:Arch:00007...) und beim zweiten Durchlauf user class: iPXE. Wenn die zweite Zeile fehlt, kommt der Client nicht bis iPXE.

Alternative: Windows-DHCP ohne Proxy

Wenn Sie lieber den vorhandenen Windows-DHCP-Server konfigurieren, bleibt dnsmasq nur TFTP-Server: Lassen Sie die Zeilen dhcp-range, dhcp-userclass, pxe-service und dhcp-boot weg. Auf dem DHCP-Server legen Sie laut iPXE-Anleitung für Microsoft DHCP eine Benutzerklasse mit der ID iPXE an und eine Richtlinie mit der Bedingung „User Class gleich iPXE”, die als Option 067 die URL http://192.168.10.5/boot.ipxe setzt. Für die erste Stufe setzen Sie Option 066 auf die Server-IP und Option 067 auf ipxeboot/x86_64-sb/snponly-shim.efi, sinnvollerweise in einer eigenen Richtlinie für die Vendor-Class PXEClient:Arch:00007 und PXEClient:Arch:00009. Die iPXE-Richtlinie muss vor der UEFI-Richtlinie greifen, sonst lädt iPXE wieder den Shim.

Schritt 7: nginx, iPXE-Skript und Startdateien

nginx liefert nur statische Dateien aus /srv/http aus. Ersetzen Sie die Standardseite durch /etc/nginx/sites-available/pxe:

server {
    listen 80 default_server;
    root /srv/http;
    autoindex off;
}

sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/pxe /etc/nginx/sites-enabled/pxe
sudo nginx -t && sudo systemctl reload nginx

Das iPXE-Skript /srv/http/boot.ipxe zeigt ein kleines Menü mit zehn Sekunden Timeout:

#!ipxe
set server 192.168.10.5

menu Windows-Installation über das Netzwerk
item win11  Windows 11 Pro unbeaufsichtigt installieren (Datenträger 0 wird gelöscht)
item shell  iPXE-Shell
item exit   Abbrechen und lokal starten
choose --default exit --timeout 10000 target && goto ${target}

:win11
kernel http://${server}/winpe/wimboot
initrd http://${server}/winpe/install.bat   install.bat
initrd http://${server}/winpe/winpeshl.ini  winpeshl.ini
initrd http://${server}/winpe/boot.wim      boot.wim
boot

:shell
shell

:exit
exit

Beachten Sie den Standard: Nach Ablauf des Timeouts startet der Rechner lokal, nicht in die Installation. Ein Rechner, der versehentlich per PXE bootet, soll sich nicht selbst löschen. Wer das anders will, setzt --default win11, aber bitte nur in einem eigenen Installations-VLAN.

/srv/http/winpe/winpeshl.ini sagt WinPE, welches Programm es statt der Eingabeaufforderung starten soll:

[LaunchApps]
"install.bat"

Weil winpeshl.ini den normalen Start ersetzt, muss install.bat das Netzwerk selbst initialisieren. /srv/http/winpe/install.bat:

@echo off
wpeinit
wpeutil WaitForNetwork
net use Z: \\192.168.10.5\install /user:deploy *
if errorlevel 1 goto fehler
Z:\win11\sources\setup.exe /unattend:Z:\autounattend.xml
goto :eof

:fehler
echo Verbindung zur Freigabe fehlgeschlagen.
cmd.exe

Der Stern hinter /user:deploy lässt net use nach dem Kennwort fragen. Das ist eine bewusste Entscheidung: Der Techniker tippt einmal das Kennwort des Installationskontos ein, und es steht nirgends im Klartext auf dem HTTP-Server. Wer es vollautomatisch will, schreibt das Kennwort direkt in die Zeile (net use Z: \\192.168.10.5\install GEHEIM /user:deploy). Dann kann es jeder lesen, der install.bat über HTTP abruft. Weil das Konto nur lesend auf die Installationsdateien zugreift, ist das vertretbar, solange Sie es so behandeln: kein weiteres Recht, kein wiederverwendetes Kennwort.

Und warum sources\setup.exe statt setup.exe im Hauptverzeichnis? Laut einem Knowledge-Base-Artikel von Broadcom bricht das Setup aus Windows-11-ISOs ab November 2025 in WinPE mit dem Fehler 0x80070035 ab, wenn es über den Starter im Hauptverzeichnis aufgerufen wird. Der ist für Upgrades aus einem laufenden Windows gedacht; sources\setup.exe ist die Variante für WinPE.

Schritt 8: Testen, zuerst in einer VM

Bevor Sie echte Hardware anfassen, testen Sie in einer VM mit UEFI. Bei Hyper-V gibt es dabei eine Besonderheit, die viel Zeit kosten kann: Die Secure-Boot-Vorlage vertraut entweder der Windows-CA („Microsoft Windows”) oder der Drittanbieter-CA („Microsoft UEFI Certificate Authority”), nie beiden gleichzeitig. Mit der Drittanbieter-Vorlage starten Shim, iPXE und wimboot, aber der Windows-Bootmanager nicht; im wimboot-Repository wird genau das beschrieben, das Problem liegt bei Hyper-V. Testen Sie in Hyper-V deshalb mit abgeschaltetem Secure Boot und prüfen Sie Secure Boot an einem physischen Gerät.

Der Ablauf beim Test:

Client per Boot-Menü (meist F12) aus dem Netz starten.
Im dnsmasq-Log den ersten Durchlauf (Vendor-Class) und den zweiten (User-Class iPXE) beobachten.
Im iPXE-Menü „Windows 11 Pro” wählen. wimboot zeigt kurz die geladenen Dateien.
WinPE startet, install.bat fragt nach dem Kennwort für deploy.
Windows Setup läuft ohne weitere Eingaben durch und startet neu.

Wenn das in der VM klappt, kommt das erste echte Gerät. Rechnen Sie damit, dass Sie dort noch einen Netzwerktreiber nachrüsten.

Fehlersuche: Die typischen Stolpersteine

Der Client bekommt keine Bootdatei

Prüfen Sie mit journalctl -u dnsmasq, ob die Anfrage überhaupt ankommt. Läuft zwischen Client und Server ein Router, kommt Proxy-DHCP nicht über die Netzgrenze; dann brauchen Sie einen DHCP-Relay oder die Windows-DHCP-Variante. Es gibt Berichte, dass manche UEFI-Firmware mit den Option-43-Antworten des Proxy-Modus nicht zurechtkommt. Auch dann ist der Weg über Optionen am regulären DHCP-Server die Lösung.

Secure-Boot-Verletzung direkt nach dem Laden des Shims

Fast immer ist die Drittanbieter-CA in der Firmware deaktiviert, siehe Voraussetzungen. Dazu kommt ein Thema, das 2026 alle Shims betrifft: Die Microsoft Corporation UEFI CA 2011 ist am 27. Juni 2026 abgelaufen. Bereits signierte Dateien starten weiter, weil die Firmware das Ablaufdatum beim Booten nicht prüft, wie AlmaLinux zusammenfasst. Neue Shim-Versionen werden aber nur noch mit der Microsoft UEFI CA 2023 signiert und starten nur auf Firmware, die diese CA kennt. Halten Sie das UEFI Ihrer Geräte aktuell, bevor Sie einen neueren iPXE-Shim einspielen.

iPXE lädt sich in einer Schleife selbst

Die User-Class-Unterscheidung greift nicht. Bei dnsmasq prüfen Sie dhcp-userclass und die Tags, beim Windows-DHCP die Reihenfolge der Richtlinien.

WinPE startet, aber `net use` schlägt fehl

In der Eingabeaufforderung aus dem Fehlerzweig prüfen Sie zuerst ipconfig. Keine Adresse heißt: Der Netzwerktreiber fehlt im WinPE, zurück zu Schritt 3. Mit Adresse, aber einer Meldung zu Zugriff oder Kennwort, stimmen Benutzer oder Kennwort nicht; versuchen Sie /user:NAME-DES-SERVERS\deploy. Ist der Netzwerkpfad nicht erreichbar, prüfen Sie die Firewall vor TCP 445 und smbd auf dem Server.

Setup findet keinen Datenträger

Dann fehlt meist der Treiber für den Speichercontroller. Den Treiber packen Sie wie den Netzwerktreiber per Dism /Add-Driver ins WinPE.

Setup bricht mit 0x80070035 ab

Sie rufen setup.exe im Hauptverzeichnis auf statt sources\setup.exe, siehe Schritt 7.

Die Antwortdatei wird teilweise ignoriert

Meist stimmt der Editionsname in /IMAGE/NAME nicht, oder eine Komponente steht im falschen Durchlauf. Die Setup-Protokolle im Ordner Panther zeigen, welche Einstellung Setup übernommen oder verworfen hat.

Sicherheit im Betrieb: Was Sie aus CVE-2026-0386 mitnehmen sollten

Diese Kette ist sicherer als WDS-Hands-free, aber sie ist kein Tresor. iPXE lädt das Skript und die Startdateien per HTTP, unverschlüsselt und unsigniert. Wer im Netz mitlesen kann, sieht install.bat; wer Pakete manipulieren kann, könnte dem Client ein anderes WinPE unterschieben. Daraus folgen ein paar Regeln, die ich für nicht verhandelbar halte.

Keine Domänenbeitritts-Konten in die autounattend.xml. Den Beitritt erledigen Sie nach der Installation, per Skript mit einem eng berechtigten Konto, per Offline-Domänenbeitritt mit djoin oder über Ihr Gerätemanagement. Das lokale Konto aus dem Beispiel ist ein temporäres Einrichtungskonto. Ändern Sie dessen Kennwort nach der Installation oder übergeben Sie die Verwaltung an Windows LAPS. Der Schneegans-Generator bietet an, Kennwörter mit Base64 zu verschleiern. Base64 ist eine Kodierung, keine Verschlüsselung; das hält niemanden auf.

Installieren Sie in einem eigenen VLAN. Ein Netzsegment nur für Neuinstallationen, in das Geräte gezielt gesteckt oder per Port-Konfiguration geschaltet werden, verhindert versehentliche Installationen und begrenzt, wer mitlesen kann. Der Proxy-DHCP läuft dann nur dort.

Halten Sie die Freigabe schreibgeschützt und das Konto eng. deploy liest nur /srv/install, sonst nichts. Wenn Sie dieselbe Samba-Instanz für andere Zwecke nutzen, trennen Sie das sauber.

Pflegen Sie die Bausteine. iPXE-Shim, wimboot und das WinPE aus dem ADK bekommen Updates, und ein veraltetes WinPE ist auch ein Sicherheitsrisiko. Wer das ADK ohnehin für WSIM nutzt, sollte den Servicing-Patch für CVE-2026-25166 eingespielt haben.

Wann iVentoy oder FOG doch die bessere Wahl ist

Ich will nicht so tun, als passe die Empfehlung für alle. Wenn Sie ein paar Rechner im Jahr aufsetzen, Secure Boot für die Installation abschalten können und die 49 $ für die Pro-Lizenz keine Hürde sind, ist iVentoy in einer halben Stunde einsatzbereit. Ehrlicherweise ist das ein Vielfaches schneller als die Kette oben. Sie müssen dann entscheiden, ob Ihnen der geschlossene Server-Code und die Geschichte mit dem Zertifikat egal sind. Mir wären sie es nicht.

Wenn Sie dagegen Hunderte identische Geräte mit fertig eingerichteter Software brauchen, etwa für Schulungsräume, ist Imaging schneller als Windows Setup. Dann sind FOG oder Clonezilla SE mit Multicast die bessere Wahl, und das Pflegen des Referenzabbilds gehört zum Job.

Und wenn Ihre Geräte ohnehin mit vorinstalliertem Windows kommen und Sie Intune lizenziert haben, ist Autopilot schlicht der Weg mit dem wenigsten Aufwand. Die PXE-Kette braucht es dann nur noch für Neuinstallationen nach Plattentausch oder Schadsoftware-Befall.

Fazit

WDS stirbt in Raten, und der Teil, für den die meisten es genutzt haben, ist seit April 2026 schon weg. Microsofts eigene Antwort heißt Autopilot oder Configuration Manager. Wer keines von beiden hat, steht nicht mit leeren Händen da: Mit dem seit November 2025 signierten iPXE-Shim, wimboot, einem WinPE aus dem ADK und einer Samba-Freigabe bauen Sie eine Netzwerkinstallation, die Secure Boot beherrscht, neben jedem DHCP-Server läuft und vollständig aus Open-Source-Bausteinen und von Microsoft weiter unterstützten Komponenten besteht. iVentoy ist bequemer, aber geschlossen und für den Einsatz in Organisationen kostenpflichtig. FOG und Clonezilla lösen ein anderes Problem.

Mein Vorschlag: Prüfen Sie diese Woche an einem einzigen Testgerät, ob dessen Firmware der Drittanbieter-CA von Microsoft vertraut, und bauen Sie die Kette in einer VM auf. Wenn das Testgerät per PXE bis in iPXE kommt, ist der Rest Fleißarbeit. Und falls Sie noch eine WDS-Installation mit AllowHandsFreeFunctionality = 1 betreiben: Schalten Sie das heute ab.

Wichtiger Hinweis: Erst testen, dann produktiv einsetzen

Die Anleitung, die Konfigurationsdateien und die Beispiel-Antwortdatei in diesem Artikel sind Vorlagen, keine geprüfte Lösung für Ihre Umgebung. Bauen Sie die komplette Kette zwingend zuerst in einem vom Produktivnetz getrennten Testnetz auf, mit eigener Netzkarte, eigenem VLAN oder isoliertem Lab, und testen Sie sie dort mit virtuellen und mindestens einem echten Gerät jedes Modells, das Sie später installieren wollen. Ein Proxy-DHCP im falschen Netzsegment beantwortet Bootanfragen fremder Rechner, und die Antwortdatei löscht Datenträger 0 ohne Rückfrage. Ein Fehler kann deshalb Daten unwiederbringlich vernichten oder den Betrieb anderer Systeme stören.

Gehen Sie erst in den Produktivbetrieb, wenn Bootkette, Treiber, Antwortdatei, Lizenzierung und Sicherheitsmaßnahmen im Test fehlerfrei durchgelaufen sind und Sie mit den Verantwortlichen für Netz und Sicherheit abgestimmt haben, in welchem Segment der PXE-Dienst laufen darf. Die Umsetzung erfolgt auf eigene Verantwortung; für Schäden aus der Anwendung dieser Anleitung übernehme ich keine Haftung.

Quellen: