Mit Windows Autopilot Updates ins Setup einbinden

Wie funktioniert das OOBE-Patching?

Der Mechanismus arbeitet innerhalb der Enrollment Status Page, die während der Autopilot-Einrichtung aktiv ist. Dort steht eine neue Einstellung mit der Bezeichnung Install Windows updates (might restart the device). Wenn diese Option aktiv ist, sucht Windows während des letzten Abschnitts der Einrichtung nach verfügbaren Qualitätsupdates. Wird ein passendes Update gefunden, startet der Prozess New Device Update Promotion. Das System lädt die aktuelle kumulative Version, installiert sie und führt bei Bedarf einen Neustart aus, bevor der Benutzer den Desktop erreicht. Die Steuerung erfolgt über einen Registrierungseintrag im Pfad:

HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\Setup\Policy\InstallQualityUpdates

Ein Wert von 1 aktiviert die Installation, 0 schaltet sie ab. Dieser Schlüssel wird von der Windows-Management-Enrollment-Komponente erzeugt und während der gesamten Einrichtung überwacht.

Abhängigkeiten und Voraussetzungen

Die Funktion steht für Windows 11 ab Version 22H2 zur Verfügung und erfordert den Patch-Stand Juni oder besser August 2025. Erst ab diesen Builds enthält das System die nötigen Komponenten für den OOBE-Patch-Vorgang. Geräte, die mit älteren Images ausgeliefert werden, legen den Registry-Zweig nicht an und überspringen den Update-Schritt. In solchen Fällen meldet das Diagnose-Tool Enable patch download = no.

Die Steuerung der OOBE-Updates hängt eng mit den in Intune konfigurierten Update-Rings zusammen. Während der Enrollment Status Page synchronisiert das Gerät sämtliche Richtlinien, die einem Windows-Update-Ring zugeordnet sind. Dadurch gelten bereits in der Setup-Phase alle Parameter für Pausen, Deferrals und Freigaben von Qualitätsupdates. Diese Synchronisation erfolgt, bevor die ESP abgeschlossen ist, um sicherzustellen, dass das Update-Verhalten während des NDUP-Prozesses konsistent bleibt. Wenn diese Zuweisung fehlt oder nicht rechtzeitig angewendet wird, verwendet das System Standardwerte und lädt die Updates unmittelbar.

Geräte, die keiner spezifischen Gerätegruppe oder keinem Update-Ring zugewiesen sind, benötigen eine All-Devices-Zuordnung, damit die Policy greift. Ohne diese Zuweisung wird das Gerät zwar registriert, aber das Qualitätsupdate wird nicht ausgeführt. Diese Abhängigkeit spielt auch für die Einhaltung von Compliance-Richtlinien eine Rolle. Intune prüft die Patch-Stände direkt nach Abschluss der OOBE erneut. Geräte, die während des OOBE-Updates erfolgreich gepatcht wurden, erscheinen sofort als konform, Systeme mit deaktiviertem oder fehlerhaftem NDUP-Schritt müssen eine Nachprüfung durchlaufen.

Die Einbindung der OOBE-Updates in das Compliance-Modell wirkt sich außerdem auf den Lebenszyklus von Hybrid-Geräten aus. In Microsoft Entra hybrid verbundenen Szenarien wird die Bewertung der Gerätekonformität nach Abschluss der OOBE vorübergehend zurückgesetzt, weil die Domänen-Authentifizierung erst nach der ersten Benutzeranmeldung erfolgt. Dadurch kann ein Gerät kurzzeitig als nicht konform erscheinen, obwohl alle Qualitätsupdates installiert sind. Erst nach der erneuten Synchronisation von Intune und Entra ID wird der Status korrigiert. Dieses Verhalten ist systembedingt und unterscheidet sich von Cloud-nativen Entra-Join-Deployments, bei denen die Compliance sofort übernommen wird.

Verhalten innerhalb von Intune

In Intune ist die Steuerung über die Enrollment Status Page möglich. Neue Profile aktivieren die Option standardmäßig, bestehende Profile behalten den bisherigen Zustand. Während des Gerätesetups synchronisiert die ESP die Richtlinien der zugewiesenen Update-Ringe. Dadurch greifen auch Pausen oder Aufschübe, die in Windows Update for Business definiert sind. Fehlt eine ESP-Zuweisung, entfällt der gesamte Patchvorgang. Ist sie aktiv, prüft die CloudExperienceHost-Komponente, ob die Einstellung EnableExpeditedUpdate gesetzt ist. Wird sie erkannt, ruft das System den Microsoft-Endpunkt sdx.microsoft.com auf und lädt mehrere JSON-Dateien, die den Ablauf des Updatebildschirms steuern.

Während des Patch-Vorgangs bleibt das Gerät auf der finalen OOBE-Seite und zeigt den Hinweis, dass Windows-Updates installiert werden. Die Installation verlängert das Setup je nach Netzwerkverbindung um zwanzig bis vierzig Minuten. Danach startet das Gerät neu und kehrt zur Benutzeranmeldung zurück. Dieser Schritt findet unmittelbar vor Abschluss der Autopilot-Registrierung statt, wodurch das System bereits beim ersten Start vollständig gepatcht ist. Die ESP beendet den Prozess erst, wenn alle Einstellungen und Anwendungen verarbeitet sind. Dadurch entsteht eine konsistente Basis, die sowohl Compliance-Richtlinien als auch Update-Policies berücksichtigt.

Technische Architektur des Patch-Vorgangs

Die Implementierung basiert auf dem Konzept der Tracked Resources. Autopilot überwacht die Policy InstallQualityUpdates über den EnrollmentStatusTracking-Dienst. Der Wert wird früh im Setup erstellt und während der Laufzeit mehrfach geprüft. Sobald er aktiv ist, initialisiert der CloudExperienceHost den Updatecheck. Über die Schnittstelle zur Windows Update Engine werden die aktuellen kumulativen Pakete abgefragt. Der Host lädt anschließend Konfigurationsdateien von "sdx.microsoft.com". Diese JSON-Dateien bestimmen das Verhalten der grafischen Anzeige und enthalten Statusdefinitionen für den Update-Fortschritt. Während der Installation zeigt das System eine Fortschrittsanzeige, in der die einzelnen Phasen des Downloads und der Patch-Installation sichtbar sind.

Pre-Provisioning, NDUP-Mechanismen und Fehlverhalten älterer Builds

Die Integration von Windows-Updates in die OOBE betrifft ausschließlich den benutzergesteuerten Autopilot-Prozess. Während der Pre-Provisioning-Phase, oft als White-Glove-Bereitstellung bezeichnet, bleibt die Funktion inaktiv. In dieser Phase installiert das Gerät ausschließlich richtlinienbasierte und gerätezugewiesene Anwendungen, bevor es resealed wird. Qualitätsupdates werden erst beim ersten Benutzerlogin eingespielt. Diese Trennung basiert auf der Architektur der Enrollment Status Page, die nur während der User-Phase aktiv ist. Der Techniker-Modus verwendet zwar denselben Provisionierungsmechanismus wie die Self-Deploying-Methode, überprüft jedoch keine ESP-Policies und erstellt daher keinen Registrierungspfad für InstallQualityUpdates.

Ein weiteres zentrales Element der neuen Update-Routine ist der Mechanismus OobeNdupOngoingUpdateStatus. Er gehört zur erweiterten NDUP-Struktur und wird durch die CloudExperienceHost-Komponente gesteuert. New Device Update Promotion (NDUP) ist ein Bestandteil des neuen Windows-Update-Mechanismus, der während der Out-of-Box-Experience aktiv wird. Der Prozess startet automatisch, sobald ein Gerät im Rahmen von Autopilot die letzte Seite der Einrichtung erreicht und die Enrollment Status Page das Installationsflag für Qualitätsupdates enthält. NDUP prüft über Windows Update, ob für die aktuelle Build-Version ein kumulatives Update verfügbar ist. Wird eines gefunden, lädt das System die Pakete, installiert sie und führt bei Bedarf einen Neustart aus. Ziel ist ein vollständig gepatchtes System, bevor der Benutzer den Desktop sieht. Der Ablauf ersetzt keine Update-Ringe oder WSUS-Steuerung, sondern verschiebt den Zeitpunkt der ersten Aktualisierung. NDUP läuft einmalig während der Gerätebereitstellung und berücksichtigt alle Richtlinien, die über Intune definiert sind. Dazu gehören Pausen, Deferrals und Bandbreitenbegrenzungen.

Technisch wird der Prozess durch den Dienst CloudExperienceHost gesteuert. Dieser ruft während des Setups Konfigurationsdaten von "sdx.microsoft.com" ab und zeigt den Fortschritt über eine spezielle OOBE-Oberfläche an. Sobald der Vorgang abgeschlossen ist, verlässt das Gerät die OOBE-Phase und gilt als vollständig bereitgestellt. Das System prüft zunächst, ob die Funktion ExpediteUpdatePILess aktiv ist, und kontaktiert anschließend sdx.microsoft.com, um mehrere JSON-Dateien zu laden, die das Verhalten des OOBE-Updatebildschirms festlegen. Diese Dateien enthalten Anweisungen für Fortschrittsanimationen und Statusmeldungen und werden im Profil des Standardbenutzers zwischengespeichert. Hier kann es passieren, dass der Prozess nur funktioniert, wenn die JSON-Dateien erreichbar sind. Wird der Hostname in der lokalen hosts-Datei blockiert, bricht die Sequenz ab und der Update-Bildschirm erscheint nicht.

Probleme können auch bei Systemen mit veralteten kumulativen Updates auftreten. Einige Builds, die vor Juni 2025 erstellt wurden, aktivieren NDUP fehlerhaft unabhängig von der ESP-Einstellung. Diese Versionen führten den Update-Dialog selbst dann aus, wenn die Policy deaktiviert ist. In Unternehmensumgebungen kann das zu unerwarteten Installationen während des Rollouts führen.

Bekannte Einschränkungen

ie neue Möglichkeit zur Aktualisierung von Windows 11 im laufenden Betrieb ist nur für usergetriebene Autopilot-Bereitstellungen verfügbar. Autopilot Device Preparation und Pre-Provisioning nutzen die Enrollment Status Page nicht und führen die Updates daher erst beim ersten Benutzerlogin aus. Während der Techniker-Phase wird die Policy nicht ausgewertet, auch wenn sie im Profil aktiviert ist. Ein Problem betrifft veraltete Buildstände. Systeme mit einem früheren kumulativen Update führen den Prozess entweder gar nicht aus oder zeigen kurz den Hinweis auf die Update-Suche, ohne tatsächlich etwas zu installieren. Nach der ersten Anmeldung erscheinen dann mehrere ausstehende Patches. Ursache ist der fehlende Registry-Zweig Policy, der erst in neueren Builds erstellt wird.

Microsoft hat die Einführung der OOBE-Updatefunktion mehrfach angepasst. Ursprünglich sollte sie mit dem Juni-Release 2025 produktiv bereitstehen, verschob sich dann auf August und wurde schließlich im September 2025 erneut ausgesetzt. Laut interner Ankündigung dient die Verzögerung der Stabilisierung des Provisioning-Prozesses, da unerwartete Update-Schleifen und fehlende Benutzeranmeldungen in frühen Testumgebungen beobachtet wurden.

Die wiederholten Rücknahmen zeigen, dass die Integration von Windows Update in die Out-of-Box-Experience komplexer ist als erwartet. NDUP erfordert eine funktionierende Kombination aus aktuellem Build, stabiler Internetverbindung und intakter Policy-Anwendung. Microsoft hat das Ziel bekräftigt, die Funktion mit einem überarbeiteten ZDP wieder freizuschalten, sobald die Zuverlässigkeit gewährleistet ist. Das Zero Day Package (ZDP), ist ein Mechanismus, mit dem Microsoft Funktionsänderungen oder Fehlerbehebungen unmittelbar nach der Imageerstellung in den Installationsprozess integriert.

Beim OOBE-Patching sorgt ZDP dafür, dass auch Geräte mit älteren Installationsmedien die aktuelle Unterstützung für NDUP erhalten. Noch bevor die Enrollment Status Page angezeigt wird, lädt Windows das ZDP-Paket über den Windows Update-Dienst und fügt damit die benötigten Komponenten hinzu, zum Beispiel die neuen Richtlinienknoten und Registrierungseinträge für InstallQualityUpdates. Auf diese Weise bleibt die OOBE-Patch-Funktion auch bei nicht aktualisierten Installationsquellen lauffähig und kann die Qualitätsupdates korrekt ausführen. Für größere Rollouts bedeutet das, dass der Planungszeitraum erweitert werden muss, um die Funktion erst nach der endgültigen Freigabe produktiv zu nutzen. Bis dahin bleibt die manuelle Integration der kumulativen Updates in das Installationsabbild die stabilste Methode.

Auswirkungen auf den Administrationsalltag

Für Administratoren bringt die Aktualisierung über den OOBE-Prozess mit Autopilot einen klaren Vorteil. Systeme starten bereits mit aktuellem Patch-Stand, was Nacharbeiten über WSUS oder Windows Update reduziert. Der zusätzliche Zeitbedarf während der Einrichtung erhöht jedoch die Komplexität der Rollouts, vor allem bei großen Stückzahlen. Eine stabile Netzwerkanbindung ist Voraussetzung, damit der Prozess zuverlässig abläuft. In Szenarien mit schwankender Bandbreite oder eingeschränkten Proxy-Umgebungen empfiehlt sich die klassische Integration der Updates in das Image über DISM. In Cloud- und Intune-Umgebungen mit schneller Internetanbindung kann das OOBE-Patching dagegen eine sinnvolle Vereinfachung darstellen.

Das Feature verändert den Zeitpunkt, an dem Systeme den ersten Compliance-Check bestehen. Ein frisch ausgeliefertes Gerät erfüllt unmittelbar nach Abschluss der OOBE bereits die Vorgaben der Update-Ringe. Für sicherheitskritische Umgebungen ist dieser Ablauf vorteilhaft. In Testumgebungen zeigt sich, dass das Verfahren stabil arbeitet, sobald die Build-Voraussetzungen erfüllt sind. Für die Praxis bleibt entscheidend, dass die Option nur in Kombination mit einer aktiven ESP und einer gültigen Intune-Zuweisung funktioniert. Ohne diese Struktur bleibt das Verhalten unverändert. In hybriden Umgebungen mit WSUS lässt sich der Mechanismus derzeit nicht steuern. Die OOBE-Update-Funktion stellt damit keinen Ersatz für klassische Patch-Mechanismen dar, sondern eine zusätzliche Automatisierung im Rahmen der Erstbereitstellung. Sie verschiebt den Zeitpunkt der Aktualisierung und bringt Geräte auf einen einheitlichen Stand, bevor der erste Benutzer Zugriff erhält.