Autopilot Device Preparation wird Standard, Hybrid Join bleibt zurück

Microsoft hat Autopilot Device Preparation im September zum empfohlenen Verfahren für user-driven Windows-Deployments erklärt. Das neue Modell ist einfacher aufgebaut und läuft stabiler, unterstützt aber nur Entra Join. Wer neue Geräte heute noch hybrid joint, sollte genau hier hinschauen, denn diese Einschränkung wiegt schwerer als die Frage nach dem richtigen Provisioning-Werkzeug.

Das Wichtigste in Kürze

• Neue Empfehlung: Microsoft empfiehlt Autopilot Device Preparation seit September für user-driven Enrollments, weil Deployments damit schneller und zuverlässiger durchlaufen.
• Nur Entra Join: Device Preparation unterstützt ausschließlich Entra Join, Hybrid Join ist im neuen Modell nicht vorgesehen.
• Kein In-Place-Wechsel: Microsoft bietet keinen unterstützten Weg, ein hybrid gejointes Gerät ohne Reset auf Entra Join umzustellen. Wer heute neue Geräte hybrid ausrollt, provisioniert sie später neu oder bleibt einen weiteren Hardwarezyklus von On-Premises-Technik abhängig.
• Kein Abschaltdatum: Klassisches Autopilot und Device Preparation existieren auf absehbare Zeit nebeneinander.
• Unsere Empfehlung: Entscheidend ist der Join-Typ, nicht das Werkzeug. Für neue Geräte setzen wir weiter auf klassisches Autopilot mit Entra Join, weil Hersteller und Händler die Geräte dann schon vor der Auslieferung registrieren können. Diesen Zero-Touch-Weg bietet Device Preparation noch nicht.

Quelle: Microsoft Learn, Compare Windows Autopilot device preparation and Windows Autopilot

Was Microsoft angekündigt hat

Mitte September hat Microsoft im Intune Customer Success Blog beschrieben, wie der Umstieg von klassischem Windows Autopilot auf Device Preparation aussehen soll. Die Botschaft ist eindeutig: Für user-driven Deployments ist Device Preparation jetzt der empfohlene Weg.

Die Technik selbst ist nicht neu: Device Preparation gibt es seit 2024 als neu aufgebaute Variante von Autopilot, die einfacher und zuverlässiger arbeitet und Deployments nahezu in Echtzeit zeigt. Bis vor Kurzem hatte sie allerdings eine Lücke, denn vor der ersten Anmeldung wusste das Gerät nicht, zu welchem Tenant es gehört. Diese Lücke schließt seit Ende August die Device Association. Damit ordnet ihr ein Windows-Gerät schon vor dem Deployment eurem Tenant zu, und es wird automatisch als Firmengerät erkannt, bekommt einen festgelegten Namen und eine angepasste Out-of-Box-Experience, noch bevor der User die Einrichtung abschließt.

Umsteigen müsst ihr nicht sofort. Klassisches Autopilot und Device Preparation laufen im selben Tenant nebeneinander, jedes Gerät nutzt aber nur eines der beiden Modelle. Ist ein Gerät sowohl für Autopilot registriert als auch per Device Association zugeordnet, hat die Association Vorrang.

Eine Richtlinie statt vier Bausteinen

Klassisches Autopilot setzt sich aus Deployment-Profilen, Enrollment Status Page, Group Tags und dynamischen Gruppen zusammen. Device Preparation kommt mit einer einzigen Provisioning-Richtlinie aus, die festlegt, was während der Out-of-Box-Experience (OOBE) passiert, von Geräteeinstellungen über Apps und Skripte bis zum Gerätenamen. In der Praxis heißt das:

• Schnellere Zuweisungen: Beim Enrollment landen Geräte über Enrollment Time Grouping sofort in einer statischen Entra-Gruppe. Apps und Skripte, die dieser Gruppe zugewiesen sind, stehen während des Provisionings sofort bereit, ohne auf die Auswertung dynamischer Gruppen zu warten.
• Klare Trennung der Phasen: Während des Provisionings kommen nur gerätebezogene Einstellungen und die wirklich nötigen Apps aufs Gerät. Alles Benutzerbezogene folgt, sobald der Desktop da ist, und die Ersteinrichtung wird dadurch kürzer und weniger fehleranfällig.
• Besseres Reporting: Jedes Deployment ist nahezu in Echtzeit sichtbar, mit deutlich mehr Details als im klassischen Autopilot, und die Fehlersuche wird spürbar einfacher.

Device Preparation kennt nur Entra Join

Device Preparation unterstützt nur Entra Join. Hybrid Join ist in der neuen Architektur nicht vorgesehen, und nichts in Microsofts Ankündigungen deutet darauf hin, dass sich das ändert. Klassisches Autopilot kann Hybrid Join zwar weiterhin, Microsofts Entwicklung zielt aber erkennbar auf Deployments ohne Domain Controller. Auf Microsoft Learn steht das inzwischen auch ausdrücklich:

„Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended …“

Wer Hybrid Join mit Autopilot betrieben hat, kennt die Hürden: Während des Provisionings muss das Gerät einen Domain Controller erreichen, der Intune Connector for Active Directory muss verfügbar sein und funktionieren, und Gruppenrichtlinien laufen parallel zu Intune. Genau an diesen Abhängigkeiten scheitern oder stocken die meisten Deployments. Für uns war Hybrid Join deshalb immer eine Übergangslösung und nie das Ziel.

Ein Entra-gejointes Gerät braucht bei der Einrichtung nichts weiter als eine Internetverbindung. Konfiguration, Apps, Updates und Compliance-Richtlinien kommen vollständig über Intune, und den Zugriff auf Unternehmensressourcen regelt Conditional Access. Das passt zu einer Arbeitswelt, die sich zunehmend außerhalb des Firmennetzes abspielt, im Homeoffice, unterwegs oder irgendwo dazwischen.

Bei uns heißt dieses Prinzip seit Jahren „Starbucks Deployment“, und schon 2019 wurden wir dafür mit dem Microsoft Global Modern Desktop Partner of the Year Award ausgezeichnet.

Von Hybrid zu Entra Join führt der Weg über einen Reset

Für die Planung ist ein Punkt entscheidend: Ein hybrid gejointes Gerät lässt sich auf unterstütztem Weg nur mit einem Reset in ein Entra-gejointes umwandeln. Jedes Gerät, das ihr heute hybrid ausrollt, müsst ihr für den Wechsel zu Entra Join also irgendwann neu provisionieren.

Das klingt zunächst nach viel Aufwand, lässt sich in der Praxis aber geordnet planen. Am häufigsten läuft der Wechsel mit dem normalen Hardwarezyklus: Neue Geräte kommen direkt mit Entra Join, die hybrid gejointen scheiden nach und nach aus. Wer schneller in die Cloud will, setzt zusätzlich Bestandsgeräte in Wellen mit Entra Join neu auf.

Warum wir trotzdem klassisches Autopilot empfehlen

Zum Umstieg auf Device Preparation raten wir trotzdem noch nicht. Für neue Geräte empfehlen wir weiterhin klassisches Autopilot, dann aber konsequent mit Entra Join.

Der wichtigste Grund ist die Anbindung an Hersteller und Händler. Mit klassischem Autopilot registriert der OEM oder Reseller das Gerät schon vor dem Versand direkt in eurem Tenant. Es geht direkt an die Mitarbeitenden, zeigt beim ersten Start euer Branding und richtet sich selbst ein, ohne dass die IT eingreifen muss.

Für die Device Association müsst ihr die Geräteinformationen derzeit dagegen selbst lokal auslesen und in Intune hochladen. Für Staging im Lager, Rollouts mit Technikern oder interne Deployments funktioniert das gut, für den Direktversand an die User aber nicht. Dass OEMs und Partner Geräte künftig vorab zuordnen können, hat Microsoft angekündigt, allerdings ohne Zeitplan.

Dazu kommen Szenarien, die Device Preparation noch nicht vollständig abdeckt:

• Pre-Provisioning: Ein Partner installiert Apps und wendet Richtlinien schon vor der Auslieferung an, sodass Mitarbeitende mit einem nahezu fertig eingerichteten Gerät starten.
• Self-Deploying Mode: Kiosk- und Shared Devices, die ohne Benutzeranmeldung ausgerollt werden.
• Erweiterte Provisioning-Optionen: Mehr Apps während der Einrichtung und die Möglichkeit, den Desktop zu sperren, bis die nötige benutzerbezogene Konfiguration abgeschlossen ist.
• Spezielle Geräteszenarien: Teams Rooms und Firmware-Management über DFCI.

Sobald Hersteller und Händler Geräte für Device Preparation vorab zuordnen können, prüfen wir unsere Empfehlung neu. An der Strategie dahinter ändert das nichts: Wer heute ein neues Deployment plant, plant mit Entra Join. Ein späterer Wechsel von klassischem Autopilot zu Device Preparation betrifft dann nur noch den Provisioning-Weg für neue Geräte und nicht das Management-Modell, die Identitätsplattform oder die Gerätearchitektur.

„Ohne Domain Join funktionieren unsere Geräte nicht“

Diesen Satz hören wir ständig. Die Technik hinter Entra Join ist ausgereift und bewährt, und wenn es hakt, liegt es selten an Entra Join selbst, sondern an Abhängigkeiten, Prozessen und Annahmen, die sich über Jahre rund um das Active Directory angesammelt haben.

• Gruppenrichtlinien: Viele Unternehmen haben weit mehr GPOs, als sie brauchen, und nach unserer Erfahrung wirkt ein erheblicher Teil davon gar nicht mehr. Mit unserem Blueprint starten Entra-Clients in wenigen Minuten auf einer erprobten und flexiblen Baseline, die wir in Managed Intune vollständig als Infrastructure as Code betreiben und laufend aktuell halten.
• Zugriff auf On-Premises-Ressourcen: Fileserver, Drucker und interne Webanwendungen bleiben auch für Entra-gejointe Geräte erreichbar. Solange das Gerät einen Domain Controller erreicht, holt es sich Kerberos-Tickets und meldet sich per Single Sign-on an On-Premises-Ressourcen an, mit Windows Hello for Business über Cloud Kerberos Trust. Testen solltet ihr diese Szenarien trotzdem immer mit echten Usern und echten Fachanwendungen.
• Zertifikate und Netzwerkzugang: Netzwerk- und VPN-Authentifizierung hängen oft an Computerzertifikaten aus einer On-Premises-CA, die über einen Network Policy Server (NPS) geprüft werden. Bei Entra-gejointen Geräten verteilt Intune die Zertifikate, etwa über Microsoft Cloud PKI oder SCEPman, und die Netzwerkauthentifizierung übernimmt eine cloudfähige RADIUS-Lösung wie RADIUSaaS.
• Verlässliche App-Deployments: Wenn Autopilot-Deployments scheitern, liegt das meist nicht am Join-Typ, sondern an schlecht gebauten oder nicht gepflegten Softwarepaketen. Deshalb setzen wir RealmJoin ein, unseren Begleiter zu Intune mit mehr als 2.500 fertig paketierten Anwendungen. Unabhängig vom Werkzeug gilt: Bei der Ersteinrichtung gehören nur die Apps aufs Gerät, die User am ersten Tag wirklich brauchen. Alles andere kommt nach, sobald das Gerät produktiv läuft, oder liegt zum Selbstinstallieren im Intune Company Portal oder im RealmJoin App Catalog.

Hybrid Join wird zum Auslaufmodell

Device Preparation kann noch nicht alles, was klassisches Autopilot kann. Die Richtung ist trotzdem klar: Microsoft investiert in Entra Join, und Hybrid Join wird mehr und mehr zum Legacy-Modell.

Bestehende hybrid gejointe Geräte bis zum Ende ihres Lebenszyklus weiterzubetreiben, kann sinnvoll sein, auch wenn ihr dann ein modernes und ein klassisches Management-Modell parallel pflegt. Neue Geräte heute noch hybrid auszurollen, bindet euch dagegen für einen weiteren Hardwarezyklus an On-Premises-Abhängigkeiten, während Microsoft Provisioning und Management für Entra Join weiterentwickelt.

Wenn ihr den Wechsel von Hybrid Join zu Entra Join plant, mit euren Autopilot-Deployments kämpft oder eure Windows-Geräte komplett über Intune verwalten wollt, helfen wir gern.

Quellen

• Moving from Windows Autopilot to Windows Autopilot device preparation (Microsoft Tech Community, September 2026)
• Introducing device association for Windows Autopilot device preparation (Microsoft Tech Community, August 2026)
• Compare Windows Autopilot device preparation and Windows Autopilot (Microsoft Learn)
• Windows Autopilot device association FAQ (Microsoft Learn)
• Microsoft Entra joined vs. hybrid joined (Microsoft Learn)