Willkommen zurück zum zweiten Teil unserer Serie über die neue Windows Autopilot Device Preparation (oft als APv2 bezeichnet).
In Teil 1 haben wir die Voraussetzungen geschaffen, die notwendigen Entra ID (ehemals Azure AD) Gruppen angelegt und die eigentliche „Device preparation policy“ im Intune Portal konfiguriert. Die Infrastruktur steht.
Doch wie weiß ein brandneues Notebook, dass es diese neue Richtlinie verwenden soll? Und wie sieht der Prozess für den Mitarbeiter aus, der das Gerät zum ersten Mal einschaltet? Genau das schauen wir uns heute an.
1. Der Abschied vom Hardware-Hash (Corporate Identifiers)
Eine der größten und besten Änderungen in der neuen Autopilot-Version ist der Wegfall des zwingenden Hardware-Hash-Uploads vorab. Zumindest fast.
Damit Autopilot Device Preparation weiß, dass ein Gerät dem Unternehmen gehört und die entsprechende Richtlinie anwenden soll, müssen wir es als „Corporate Owned“ kennzeichnen, bevor sich der User anmeldet. Tun wir das nicht, wird das Gerät standardmäßig als „Personal“ (BYOD) behandelt, was oft nicht gewünscht ist.
Wir nutzen dafür die sogenannten Corporate Device Identifiers. Wir können Geräte nun anhand ihrer Seriennummer (und optional Hersteller/Modell) vorab importieren, ohne den komplexen Hash auslesen zu müssen.
So fügst du Unternehmenskennungen hinzu:
Gehe im Intune Portal zu Geräte -> Geräte-Onboarding -> Registrierung.
Klicke auf den Reiter Unternehmensgeräte-IDs.
Hier kannst du nun einzelne Geräte hinzufügen (+ Hinzufügen) oder eine CSV-Datei hochladen (CSV importieren).
Für den Upload benötigst du lediglich die Seriennummer und, wenn gewünscht, Hersteller und Modell, um es eindeutiger zu machen.
Wichtig: Dieser Schritt ist entscheidend, damit die dynamische Gruppe, die wir in Teil 1 für die Geräte erstellt haben, korrekt befüllt wird.
2. Die Magie der dynamischen Zuweisung
Erinnerst du dich an die Gerätegruppe aus Teil 1, der wir die Device Preparation Policy zugewiesen haben? Damit die neuen Geräte dort automatisch landen, benötigen wir eine dynamische Mitgliedschaftsregel in Entra ID.
Da wir die Geräte nun über ihre Seriennummer als „Corporate“ identifiziert haben, können wir eine Regel erstellen, die genau darauf greift.
Eine typische dynamische Regel für diese Geräte könnte so aussehen:
Plaintext
(device.devicePhysicalIds -any _ -contains „[ZTDId]“)
Oder spezifischer, wenn du bestimmte Bestellungen filtern möchtest, kann man auch auf OrderIDs filtern, sofern diese beim Import der Identifier angegeben wurden.
Die [ZTDId] ist der Indikator dafür, dass ein Gerät über die oben genannten Corporate Identifiers importiert wurde. Sobald das Gerät das erste Mal Kontakt zu Microsoft aufnimmt (beim OOBE), wird es dieser Gruppe hinzugefügt und erhält die Richtlinie.
3. Die User Experience (OOBE)
Jetzt wird es spannend. Wie fühlt sich das neue Autopilot für den Endanwender an?
Wir nehmen ein frisches Windows 11 Gerät (oder eine VM), das nicht im alten Autopilot registriert ist, aber dessen Seriennummer wir in Schritt 1 hinterlegt haben.
Der Ablauf:
Start & Netzwerk: Der Nutzer schaltet das Gerät ein, wählt Region und Tastaturlayout und verbindet sich mit dem Netzwerk (WLAN/LAN).
Die Anmeldung: Das Gerät erkennt, dass es verwaltet werden soll, und präsentiert den modernen Anmeldebildschirm deiner Organisation (mit Logo und Branding, sofern konfiguriert). Der Nutzer gibt seine M365-Zugangsdaten ein.
Der neue „Status Screen“: Hier liegt der größte visuelle Unterschied zum klassischen Autopilot. Anstatt des bekannten blauen „Enrollment Status Page“ (ESP) Bildschirms mit den drei Phasen (Gerät, Setup, Konto), sehen wir nun einen schlichteren, moderneren Bildschirm.
Es erscheint meist ein schwarzer Hintergrund mit weißem Text, der den Fortschritt anzeigt:
„Setting up your device…“
„Installing required apps…“
„Finishing up…“
Dieser Prozess wirkt insgesamt schlanker und weniger technisch als die alte ESP.
Nach Abschluss der Installationen landet der Nutzer direkt auf dem Desktop. Im Idealfall sind die notwendigen Anwendungen (wie das Company Portal oder Office) bereits installiert oder werden kurz darauf fertiggestellt.
4. Monitoring und Reporting
Woher wissen wir als Admins, ob alles funktioniert hat, ohne neben dem User zu stehen?
Das Reporting für die Device Preparation wurde ebenfalls überarbeitet und hat einen eigenen Bereich im Intune Portal bekommen.
So prüfst du den Status:
Gehe im Intune Portal zu Geräte -> Überwachen.
Scrolle nach unten zum Bereich „Registrierung“. Dort findest du den neuen Bericht Autopilot device preparation deployments.
Dieser Bericht ist sehr detailliert. Er zeigt dir nicht nur an, ob ein Deployment „Success“ oder „Failed“ war, sondern du kannst auf einzelne Geräte klicken, um genau zu sehen, welche Apps oder Skripte während der Einrichtung installiert wurden und wie lange jeder Schritt gedauert hat.
Wenn du auf ein einzelnes Gerät in diesem Bericht klickst, erhältst du eine granulare Ansicht der ausgeführten Schritte. Das ist Gold wert für das Troubleshooting, wenn doch mal etwas hakt.
Fazit zu Teil 2
Mit dem Wegfall des Hardware-Hash-Zwangs und der vereinfachten User Experience ist „Autopilot Device Preparation“ ein großer Schritt in die richtige Richtung für ein modernes Client Management. Die Einrichtung fühlt sich robuster und schneller an als beim klassischen Autopilot.
Natürlich ist es noch eine neue Technologie. In zukünftigen Beiträgen werden wir uns sicher noch genauer mit fortgeschrittenen Szenarien und dem Troubleshooting beschäftigen, wenn es mal nicht so glatt läuft.
Habt ihr die neue Methode schon getestet? Schreibt eure Erfahrungen gerne in die Kommentare!