In diesem Blogartikel wird die Zukunft des OS-Deployments beleuchtet, insbesondere im Hinblick auf Windows-Betriebssysteme. Für das Deployment über Netzwerke ist PXE derzeit der Standard. Dieses Protokoll weist jedoch Einschränkungen auf, insbesondere wenn es um das Deployment aus der Cloud geht. Hier setzt das Tool iPXE an.
Im Folgenden werden die verschiedenen Technologien näher betrachtet und erläutert, warum Microsoft Autopilot in diesem Fall keine Lösung bietet.

PXE: Der Klassiker für Windows-Installationen

PXE, besser bekannt als Pre-Boot Execution Environment, ist ein bewährter Standard aus den späten 90ern, entwickelt von Intel. Es ist fest in die Firmware von Netzwerkkarten oder Mainboards integriert – egal ob BIOS oder UEFI. Der Prozess ist simpel: Ein Gerät startet, sendet eine DHCP-Anfrage mit PXE-Informationen und erhält vom Server eine IP-Adresse sowie Details zu einem TFTP-Server und einem Bootloader. Dieser Bootloader – etwa PXELINUX oder ein Windows-kompatibles Äquivalent – wird über TFTP geladen und gestartet. Anschließend können Windows-Installationsdateien wie ein WinPE-Image heruntergeladen und das Deployment gestartet werden. PXE ist ideal für einfache Windows-Setups:

Es ist direkt verfügbar, erfordert wenig Konfiguration und harmoniert gut mit Tools wie Microsofts Windows Deployment Services (WDS).

Doch es hat Schwächen:

TFTP ist langsam und unsicher, da es auf UDP ohne Fehlerkorrektur basiert. Moderne Protokolle wie HTTP oder HTTPS fehlen, und Flexibilität für komplexere Windows-Deployments ist kaum vorhanden.

iPXE: Der moderne Ansatz für Windows

Ein Screenshot des iPXE Boot Menüs

iPXE stellt die weiterentwickelte Antwort auf PXE dar – Open Source und geeignet für anspruchsvollere Anforderungen. Es ist kein festes Firmware-Feature, sondern ein eigenständiger Bootloader, der entweder über PXE chainloaded – also von PXE gestartet und übergeben wird – oder direkt auf die Hardware geflasht werden kann. Sobald iPXE läuft, wird es interessant: Dateien werden über http oder HTTPS geladen, das schneller und zuverlässiger als TFTP ist. Für Windows-Deployments bedeutet dies, dass große Installations-Images oder WinPE-Dateien effizient über das Netzwerk übertragen werden können. Mit einer Skriptsprache können dynamische Abläufe gestaltet werden – etwa verschiedene Windows-Versionen (Windows 10, 11, Server) je nach Gerät ausgerollt werden. iPXE unterstützt zudem moderne Netzwerke wie IPv6, was in großen Windows-Umgebungen von Vorteil ist. Der Nachteil? Es erfordert mehr Vorbereitung als PXE – Chainloading oder Flashen ist nötig – und die Einrichtung ist komplexer.

Wo liegen die Unterschiede?

Die Unterschiede zwischen PXE und iPXE zeigen sich deutlich beim Windows-Deployment. PXE bleibt auf TFTP angewiesen, was bei großen Windows-Images – oft mehrere GB schwer – zu langen Wartezeiten führt. iPXE nutzt HTTP oder HTTPS, was den Prozess beschleunigt und stabiler macht. Während PXE direkt aus der Firmware läuft und ideal für schnelle, einfache Windows-Installationen mit WDS ist, erfordert iPXE mehr Vorbereitung, bietet jedoch mehr Möglichkeiten: Skripte können Treiber oder Updates für Windows dynamisch einbinden. PXE ist der unkomplizierte Helfer für Standard-Setups, während iPXE punktet, wenn Kontrolle und moderne Protokolle für das Windows-Deployment benötigt werden.

Warum nicht Intune Autopilot?

Es könnte der Eindruck entstehen, dass Microsoft Intune Autopilot eine Alternative zu PXE oder iPXE darstellt. Autopilot ist eine Cloud-basierte Lösung, um Windows-Geräte automatisch zu provisionieren – ideal für Unternehmen, die ihre Windows-10- oder 11-Flotte zentral verwalten möchten. Doch es ersetzt PXE und iPXE nicht.

Autopilot setzt voraus, dass Windows bereits auf dem Gerät läuft – es übernimmt die Konfiguration nach dem ersten Boot über die Cloud. PXE und iPXE hingegen starten von Grund auf: Sie installieren Windows auf Bare-Metal-Hardware, etwa bei neuen PCs oder Servern ohne Betriebssystem. Autopilot ist auf Windows fokussiert und benötigt eine Internetverbindung sowie Microsofts Cloud – PXE und iPXE laufen lokal im Netzwerk, unabhängig von der Cloud, und können auch andere Images wie WinPE für Diagnosen laden. Autopilot ist hervorragend für die Nachbearbeitung von Windows geeignet, aber für das initiale Deployment auf blanker Hardware bleiben PXE und iPXE unverzichtbar.

PXE in einer Cloud-First-Microsoft-Strategie

In einer Cloud-First-Strategie, wie Microsoft sie mit Azure und Intune vorantreibt, stößt PXE an seine Grenzen. Solche Strategien setzen auf Cloud-native Lösungen, minimale lokale Infrastruktur und maximale Flexibilität über das Internet. PXE passt hier nicht mehr ins Bild: Es ist auf lokale Netzwerke, DHCP-Server und TFTP angewiesen – alles Dinge, die in einer Cloud-First-Welt wegfallen sollen. TFTP ist nicht nur langsam, sondern auch nicht für den Zugriff über das Internet ausgelegt, das in einem Cloud-Szenario, in dem Geräte oft remote provisioniert werden, ein Problem darstellt. Zudem fehlt PXE die Unterstützung für HTTPS, was in einer sicherheitsbewussten Cloud-Strategie nicht akzeptabel ist. Während PXE früher mit WDS in lokalen Netzwerken überzeugte, passt es nicht zu einem Ansatz, der auf Cloud-Dienste wie Entra (Azure AD) und Intune setzt, die Geräte unabhängig von physischen Standorten verwalten. iPXE hingegen kann mit HTTP/HTTPS und IPv6 zumindest teilweise in solche Strategien integriert werden, bleibt jedoch auch eher ein Tool für spezifische Deployment-Szenarien als für die vollständige Cloud-First-Vision.

Microsoft Endpoint Configuration Manager: Nur ein Übergang für PXE

Microsoft Endpoint Configuration Manager (ConfigMgr, früher SCCM) wird oft mit PXE kombiniert, um Windows-Deployments zu steuern – etwa über integrierte PXE-Bootpunkte und WDS. Es handelt sich um eine mächtige Lösung, um Geräte lokal zu verwalten, Images bereitzustellen und Updates zu verteilen. Doch in einer modernen Microsoft-Strategie sollte ConfigMgr nur als Übergangslösung für PXE betrachtet werden. Der Grund: ConfigMgr ist stark auf On-Premises-Infrastruktur ausgelegt – genau wie PXE. Es erfordert lokale Server, Netzwerkkonfigurationen und Wartung, was in einer Cloud-First-Welt, die auf schlanke, Cloud-basierte Verwaltung setzt, immer weniger Sinn ergibt. Während ConfigMgr PXE um Features wie Task-Sequenzen oder Treiber-Management erweitert, bleibt es an die gleichen Schwächen gebunden: TFTP, lokale Abhängigkeiten und fehlende Cloud-Skalierbarkeit. Microsoft selbst fördert Intune und Azure AD als die Zukunft der Geräteverwaltung, und ConfigMgr wird zunehmend als Brücke gesehen – eine Übergangslösung, bis Unternehmen vollständig auf Cloud-Tools umsteigen. Für Unternehmen, die noch nicht Cloud-ready sind, ist ConfigMgr mit PXE ein solider Kompromiss, aber langfristig nicht die Antwort in einer Welt, die auf Intune und Autopilot setzt.

Microsoft Intune Logo

Fazit

PXE bleibt der verlässliche Klassiker für simples Windows-Deployment – stets verfügbar, wenn es benötigt wird, aber in einer Cloud-First-Welt zunehmend veraltet. iPXE bietet die moderne Leistung, die größere Windows-Umgebungen erfordern, auch wenn es mehr Aufwand bedeutet. Intune Autopilot ergänzt dies für Cloud-basierte Windows-Konfigurationen, ersetzt jedoch nicht das Bare-Metal-Deployment von PXE und iPXE. ConfigMgr mit PXE ist ein nützlicher Übergang, doch in einer Microsoft-Strategie, die auf die Cloud setzt, wird es zur Zwischenlösung – PXE selbst zum Relikt, während iPXE noch Chancen hat.

In einem unserer nächsten Blogartikel wird das Thema iPXE näher beleuchtet und erläutert, wie diese Technologie als eigenständige Lösung implementiert werden kann.

Haben Sie Interesse an weiteren Inhalten rund um den Arbeitsplatz? Dann teilen Sie Ihre Meinung in den Kommentaren mit! Folgen Sie uns außerdem, um zukünftige Beiträge nicht zu verpassen und stets auf dem Laufenden zu bleiben.