Windows Autopilot einrichten: Der komplette Leitfaden für Portal und PowerShell

Ein neuer Laptop kommt heute idealerweise gar nicht mehr in der IT-Abteilung an. Er geht direkt vom Händler an den Arbeitsplatz, der Mitarbeiter schaltet ihn ein, meldet sich mit seinem Firmenkonto an — und das Gerät richtet sich selbst ein: Entra-Beitritt, Intune-Verwaltung, Apps, Richtlinien, BitLocker. Kein Image, kein USB-Stick, kein Vor-Ort-Termin. Genau das ist Windows Autopilot. Dieser Leitfaden zeigt die komplette Einrichtung — erst im Portal, dann per PowerShell — auf dem Stand von August 2026, mit den Fallstricken, die in älteren Anleitungen fehlen.

Ein Hinweis vorab: Autopilot installiert kein Windows. Es konfiguriert das Betriebssystem, das ab Werk auf dem Gerät liegt. Die Qualität des Rollouts steht und fällt also mit dem, was Sie in Intune hinterlegen.

Welches Autopilot? Der Stand 2026

Seit 2024 gibt es zwei Verfahren nebeneinander — und beide werden von Microsoft aktiv weiterentwickelt:

	Klassisches Autopilot	Autopilot device preparation
Geräteidentität	Hardware-Hash, vorab registriert	kein Hash nötig (Policy greift beim Enrollment)
Szenarien	User-driven, Self-Deploying, Pre-Provisioning	nur User-driven (weitere angekündigt)
Join-Typ	Entra join, Hybrid möglich	nur Entra join
Windows	unterstützte Windows-11-Versionen	Windows 11 ab 22H2 (mit Update)
Fortschrittsanzeige	Enrollment Status Page (ESP)	Echtzeit-Monitoring, keine ESP

Das klassische Verfahren ist nicht abgekündigt — Microsoft schreibt ausdrücklich, dass beide Lösungen parallel weiterlaufen und keine Migration nötig ist. Für Self-Deploying (Kiosk- und Shared-Geräte), Pre-Provisioning und alles mit lokalem Active Directory bleibt es ohnehin der einzige Weg. Dieser Leitfaden behandelt deshalb das klassische Autopilot im User-driven-Modus mit Entra join — das mit Abstand häufigste Szenario im Mittelstand — und ordnet device preparation am Ende ein.

Zwei Einordnungen, die 2026 wichtig sind: Windows 10 ist raus. Der Support endete im Oktober 2025, und Autopilot unterstützt laut Microsoft keine Produkte jenseits ihres Lebenszyklus — eine ESU-Ausnahme ist nicht dokumentiert. Planen Sie Autopilot als Windows-11-Projekt; falls bei Ihnen noch Windows-10-Geräte laufen, ist der geordnete Umstieg das vorgelagerte Thema. Und: Hybrid Join wird nicht mehr empfohlen. Der Weg funktioniert weiterhin, aber Microsoft rät für neue Geräte klar zu Cloud-native mit Entra join — auch über Autopilot.

Voraussetzungen: weniger, als Sie denken

Lizenzen. Es braucht keine Enterprise-Lizenzierung: Microsoft 365 Business Premium genügt, ebenso E3/E5, F1/F3, die Education-Pläne oder Enterprise Mobility + Security. Alternativ reicht Microsoft Entra ID P1 plus ein Intune-Abo. Entscheidend: Die Lizenzen müssen den Benutzern zugewiesen sein. Welcher Plan zu Ihrer Größe passt, haben wir im Microsoft-365-Lizenzvergleich aufgeschlüsselt.

Hardware. Keine besonderen Anforderungen über die Windows-11-Mindestanforderungen hinaus. Einzige Ausnahme: Self-Deploying und Pre-Provisioning verlangen zwingend ein physisches TPM 2.0 — virtuelle Maschinen scheitern dort mit dem Timeout-Fehler 0x800705B4, auch mit virtuellem TPM.

Netzwerk. Das Gerät braucht beim ersten Start Internet: DNS-Auflösung sowie die Ports 80, 443 und 123 (NTP). Wer per Firewall filtert, gibt unter anderem ztd.dds.microsoft.com, login.live.com und time.windows.com frei — die vollständige Endpunktliste steht in der Microsoft-Dokumentation. Ein per Intune verteilter Proxy kommt für die OOBE-Phase zu spät; Proxy-Regeln gehören auf den Proxy selbst.

Zwei Einstellungen im Tenant sind Pflicht, bevor irgendetwas funktioniert:

1. Automatische MDM-Registrierung: Azure-Portal → Microsoft Entra ID → Mobility (MDM and WIP) → Microsoft Intune → „MDM user scope” auf All (oder auf eine Pilotgruppe).
2. Geräte-Beitritt erlauben: Microsoft Entra ID → Devices → Device Settings → „Users may join devices to Microsoft Entra” auf All oder Selected.

Rollen. Für die Geräteregistrierung genügt die Intune-Rolle „Policy and Profile Manager”; wer per PowerShell direkt hochladen will, braucht mindestens „Intune Administrator”. Global-Admin-Rechte sind für den Betrieb nicht nötig.

Der Weg im Portal: sechs Schritte

Alles Weitere passiert im Microsoft Intune admin center unter intune.microsoft.com.

1. Hardware-Hash beschaffen

Der Hash ist die Gerätekennung, über die Autopilot ein Gerät Ihrem Tenant zuordnet. Vier Wege führen zu ihm:

• Der beste: gar nicht selbst. Bei Neubestellungen registriert der Händler oder OEM die Geräte über das Partner Center direkt in Ihrem Tenant — Sie geben nur ein Group Tag vor (dazu gleich mehr). Genau deshalb gehört Autopilot bei uns fest zur IT-Beschaffung: Geräte kommen registriert an, nicht als Projektarbeit.
• PowerShell-Skript auf dem laufenden Gerät oder direkt in der OOBE — der komplette Weg steht im PowerShell-Teil unten.
• Windows 11, ohne Anmeldung: In der OOBE öffnet CTRL + SHIFT + D die Diagnoseseite; der Log-Export auf einen USB-Stick enthält eine CSV mit dem Hash.
• Configuration Manager sammelt die Hashes verwalteter Geräte automatisch.

2. Geräte importieren

Devices → Windows → Enrollment → Windows Autopilot: Devices → Import

Die CSV-Datei hat exakt diese Kopfzeile (Groß-/Kleinschreibung zählt):

Device Serial Number,Windows Product ID,Hardware Hash,Group Tag,Assigned User

Drei Regeln, deren Missachtung die häufigste Fehlerquelle ist: maximal 500 Zeilen pro Upload, keine Anführungszeichen und keine zusätzlichen Spalten — und niemals mit Excel öffnen. Excel verändert die Kodierung und zerstört den Base64-Hash; bearbeiten Sie die Datei nur im Texteditor. Vorsicht auch beim Feld „Assigned User”: Intune prüft beim Upload nur die Domain, nicht den Benutzernamen — ein Tippfehler macht das Gerät später unzugänglich.

Nach dem Import Sync und Refresh klicken; bis die Geräte erscheinen, können einige Minuten vergehen.

3. Gerätegruppe anlegen

Autopilot-Profile werden Gruppen zugewiesen. Praktisch ist eine dynamische Entra-Gruppe, die jedes Autopilot-Gerät automatisch aufnimmt:

Groups → New group → Typ Security, Membership type Dynamic Device → Regel:

(device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]"))

Wer nach Abteilungen oder Standorten trennen will, nutzt das Group Tag: ein frei wählbares Etikett pro Gerät (in Entra als „OrderID” gespeichert), nach dem sich Gruppen filtern lassen:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:Vertrieb"))

Wichtig: In diesen dynamischen Gruppen nur Autopilot-Attribute verwenden. Wer weitere Bedingungen hineinmischt, riskiert, dass die Mitgliedschaft beim Provisioning noch nicht ausgewertet ist — und das Gerät ohne Profil startet.

4. Deployment-Profil erstellen

Devices → Windows → Enrollment → Deployment Profiles → Create Profile → Windows PC

Die wichtigsten Entscheidungen:

• Deployment mode: „User-driven” — das Gerät gehört dem Nutzer, der sich anmeldet. („Self-deploying” ist für Kiosk- und Shared-Geräte ohne Nutzerbindung.)
• Join to Microsoft Entra ID as: Microsoft Entra joined.
• User account type: Standard — der Mitarbeiter wird kein lokaler Administrator. Das ist einer der stillen Sicherheitsgewinne von Autopilot gegenüber manueller Einrichtung.
• Apply device name template: z. B. FD-%SERIAL% — maximal 15 Zeichen, Buchstaben, Zahlen und Bindestriche.
• Dazu die OOBE-Kosmetik: Lizenzbedingungen und Datenschutzseiten ausblenden, Tastatur automatisch konfigurieren.

Eine Option verdient eine Warnung: „Convert all targeted devices to Autopilot” registriert alle firmeneigenen Geräte der Zielgruppe nachträglich als Autopilot-Geräte. Das ist eine Einbahnstraße — das spätere Deaktivieren macht die Registrierung nicht rückgängig, nur eine explizite Deregistrierung je Gerät.

Danach das Profil der Gruppe aus Schritt 3 zuweisen. Bei mehreren passenden Profilen gewinnt übrigens das älteste, nicht das neueste — ein klassischer Stolperstein bei Tests.

5. Enrollment Status Page konfigurieren

Die ESP ist der Fortschrittsbildschirm, den der Nutzer beim ersten Start sieht — und Ihr Hebel, damit niemand auf einem halbfertigen Gerät arbeitet:

Devices → Enrollment → Windows → Enrollment Status Page → Create

Bewährte Einstellungen: Fortschritt anzeigen, „Block device use until all apps and profiles are installed” aktivieren und nur die wirklich kritischen Apps als blockierend markieren (Virenschutz, VPN — nicht die komplette Softwareliste). Der Timeout-Standard von 60 Minuten ist knapp, wenn große Pakete installiert werden.

Zwei Fallen aus der Praxis: Neue ESP-Profile installieren seit 2025 standardmäßig Windows-Qualitätsupdates während der Einrichtung — sicherheitlich sinnvoll, verlängert das Provisioning aber um 20 bis 40 Minuten und kann Neustarts auslösen. Bewusst entscheiden statt wundern. Und: Klassische MSI-Apps (LOB) und Win32-Apps nicht mischen. Beide nutzen denselben Installationsmechanismus und blockieren sich gegenseitig („Another installation is in progress”) — die ESP läuft in den Fehler. Paketieren Sie einheitlich als Win32, auch die Microsoft 365 Apps.

6. Prüfen, dann versenden

Bevor ein Gerät zum Mitarbeiter geht, ein Blick in die Geräteliste: Die Spalte Profile Status muss auf „Assigned” stehen. Ein Gerät, das ohne zugewiesenes Profil startet, durchläuft das normale Windows-Setup — und der Mitarbeiter richtet sich einen Privatzustand ein, den Sie später mühsam einfangen.

Der Ablauf aus Nutzersicht: Gerät ans Netz (bei Ethernet überspringt die OOBE die Sprach- und Tastaturseiten, bei WLAN nicht), Firmen-Anmeldeseite — bei zugewiesenem Nutzer bereits mit vorbelegtem Namen —, gegebenenfalls MFA, dann die ESP mit ihren drei Phasen, danach der fertige Desktop. Den Verlauf sehen Sie serverseitig unter Devices → Monitor → Windows Autopilot deployment status.

Der Weg per PowerShell

Alles aus dem Portal-Teil geht auch skriptiert — schneller, wiederholbar und dokumentierbar. Zwei Dinge vorweg: Das offizielle Skript Get-WindowsAutopilotInfo (Version 3.9) nutzt seit 2023 die Microsoft-Graph-Module; Anleitungen mit Connect-AzureAD sind veraltet und funktionieren nicht mehr. Und es wird seit Juli 2023 nicht weiterentwickelt — es funktioniert, aber wenn es mit neuen Graph-SDK-Versionen hakt, gibt es den aktiv gepflegten Community-Fork Get-WindowsAutopilotInfoCommunity (kein Microsoft-Produkt, klar gekennzeichnet).

Hash lokal als CSV erfassen

Auf dem laufenden Gerät, in einer PowerShell mit Administratorrechten:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
New-Item -Type Directory -Path "C:\HWID"
Set-Location -Path "C:\HWID"
$env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Install-Script -Name Get-WindowsAutopilotInfo
Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv

Die entstandene AutopilotHWID.csv importieren Sie wie oben im Portal — oder gleich per Skript, siehe unten.

Direkt aus dem Karton: Upload in der OOBE

Der eleganteste Weg für einzelne Bestandsgeräte: Das fabrikneue Gerät einschalten, in der OOBE Shift + F10 drücken, im Kommandozeilenfenster powershell.exe starten:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -Online

Bei -Online öffnet sich ein Anmeldefenster: Es braucht ein Konto mit mindestens Intune-Administrator-Rechten, beim ersten Lauf zusätzlich die Zustimmung zu den Graph-Berechtigungen. Danach lädt das Skript den Hash direkt in den Tenant. Praktisch sind die Zusatzparameter — Group Tag setzen, auf die Profilzuweisung warten und direkt neu starten, damit das Gerät sofort in den Autopilot-Flow geht:

Get-WindowsAutopilotInfo -Online -GroupTag "Vertrieb" -Assign -Reboot

Für unbeaufsichtigte Massenläufe existieren -TenantId, -AppId und -AppSecret mit einer App-Registrierung — die nötige App-Konfiguration ist allerdings nur in Community-Blogs dokumentiert, nicht bei Microsoft. Secrets gehören dabei nie im Klartext ins Skript.

Übrigens, falls kein Skript-Download möglich ist: Der Hash liegt in der WMI-Klasse MDM_DevDetail_Ext01 und lässt sich auch direkt auslesen — genau daraus bedient sich das offizielle Skript.

Import, Sync und Pflege per Graph

Für die Verwaltung aus Skripten gibt es zwei Wege. Der komfortable ist das Modul WindowsAutopilotIntune (von Microsoft veröffentlicht, offiziell „Sample”-Status; mindestens Version 5.7 verwenden, ältere Versionen nutzen inzwischen umbenannte API-Felder):

Install-Module WindowsAutopilotIntune -MinimumVersion 5.7 -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"

Get-AutopilotDevice                                       # Geräte auflisten
Import-AutopilotCSV -csvFile C:\HWID\AutopilotHWID.csv    # CSV importieren
Invoke-AutopilotSync                                      # Sync anstoßen
Set-AutopilotDevice -id $d.id -groupTag "Vertrieb"        # Group Tag setzen
Remove-AutopilotDevice -id $d.id                          # Registrierung löschen

Der zweite Weg ist das offizielle Microsoft-Graph-SDK — sperriger, aber ohne Sample-Status. Geräte auflisten, Group Tag setzen und Registrierungen löschen laufen über die stabile v1.0-API:

Install-Module Microsoft.Graph.DeviceManagement.Enrollment -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"

Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All

Update-MgDeviceManagementWindowsAutopilotDeviceIdentityDeviceProperty `
    -WindowsAutopilotDeviceIdentityId $device.Id -GroupTag "Vertrieb"

Remove-MgDeviceManagementWindowsAutopilotDeviceIdentity `
    -WindowsAutopilotDeviceIdentityId $device.Id

Nur der Sync liegt noch in der Beta-API — und ist gedrosselt: höchstens alle 10 Minuten, ein parallel laufender Sync antwortet mit HTTP 409. Nicht in Schleifen aufrufen:

Install-Module Microsoft.Graph.Beta.DeviceManagement.Enrollment -Scope CurrentUser
Sync-MgBetaDeviceManagementWindowsAutopilotSetting

Auch Deployment-Profile lassen sich per Graph anlegen — die API dafür ist Beta, und seit Mai 2024 heißen mehrere Felder anders (hardwareHashExtractionEnabled statt extractHardwareHash, preprovisioningAllowed statt enableWhiteGlove). Wer Profile aus Code erzeugt, prüft seine Vorlagen gegen die aktuelle Referenz; für die Gruppen-Zuweisung ist das Portal oder das Modul-Cmdlet der verlässlich dokumentierte Weg.

Wenn es klemmt: die häufigsten Fehler

Fehler	Ursache und Lösung
ZtdDeviceAssignedToAnotherTenant	Hash gehört noch einem anderen Tenant — typisch bei Gebrauchtgeräten. Nur der Vorbesitzer, dessen Partner oder der OEM kann deregistrieren.
ZtdDeviceAlreadyAssigned	Gerät ist bereits im eigenen Tenant registriert — kein erneuter Import nötig.
InvalidZtdHardwareHash	Hash unvollständig, oft von Excel beschädigt — CSV neu erzeugen, nur im Texteditor anfassen.
0x80180014	Enrollment blockiert: entweder verbietet eine Enrollment Restriction „Windows (MDM)”, oder ein Self-Deploying-Gerät wird wiederverwendet — dann „Unblock device” im Autopilot-Geräteblade.
0x800705B4	Timeout bei Self-Deploying: kein physisches TPM 2.0. VMs funktionieren in diesem Modus nicht.
0x80180022	Windows Home Edition — von Autopilot nicht unterstützt, Edition anheben.
80180018	Fehlende Intune-Lizenz des Anmeldenden oder Gerätelimit erreicht.
Gerät startet normales Windows-Setup	Profil war beim Versand nicht zugewiesen („Profile Status” prüfen) — oder die dynamische Gruppe enthält Fremd-Attribute und war noch nicht ausgewertet.

Für alles Weitere sammelt Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\autopilot.cab die Diagnosedaten ein — auch direkt in der OOBE per Shift + F10.

Geräte ausmustern: Deregistrieren nicht vergessen

Ein Wipe löscht Daten — aber nicht die Autopilot-Registrierung. Verlässt ein Gerät das Unternehmen endgültig, gehört die Deregistrierung fest in den Prozess, in dieser Reihenfolge: erst das Gerät in Intune löschen, dann die Autopilot-Registrierung entfernen (Devices → Windows → Enrollment → Windows Autopilot → Devices). Das Entra-Geräteobjekt dabei nicht manuell löschen — darauf ist der Prozess angewiesen.

Wer das auslässt, produziert genau die ZtdDeviceAssignedToAnotherTenant-Fehler, über die sich der nächste Besitzer ärgert — und blockiert den Weiterverkauf. Beim IT-Ankauf gebrauchter Business-Hardware gehört die saubere Deregistrierung deshalb für uns zur Abwicklung dazu.

Und wann device preparation?

Die neuere Variante lohnt einen Blick, wenn Sie ausschließlich User-driven mit Entra join arbeiten und den Hardware-Hash-Prozess loswerden wollen: Statt Geräteregistrierung genügt eine Policy, die beim Enrollment greift; seit 2026 lassen sich Geräte zusätzlich vorab per „device association” an den Tenant binden. Die Grenzen: kein Self-Deploying, kein Pre-Provisioning, kein Hybrid, maximal 25 Apps und 10 Skripte pro Policy. Ein bereits klassisch registriertes Gerät führt die Device-preparation-Policy übrigens nie aus — das klassische Profil hat Vorrang. Wer beide Welten testet, sollte das wissen, bevor er sich über den „falschen” Bildschirm wundert.

Fazit

Windows Autopilot ist kein Hexenwerk, aber es ist Präzisionsarbeit: zwei Tenant-Einstellungen, saubere Geräteregistrierung, ein durchdachtes Profil und eine ESP, die blockiert, was blockieren muss — dann läuft der Geräterollout tatsächlich ohne IT-Anfassen. Die meisten Probleme entstehen nicht in der Technik, sondern in den Details davor: Excel in der CSV, Fremd-Attribute in der Gruppe, ein zu knapper Timeout, ein vergessener Profile-Status.

Lota Engineering richtet Autopilot für Unternehmen aus Düsseldorf und dem Rheinland ein — von der Cloud- und Microsoft-365-Umgebung über die Beschaffung ab Werk registrierter Geräte bis zum laufenden Betrieb als Managed Services. Wenn Ihr nächster Geräterollout ohne Turnschuh-IT laufen soll: Sprechen Sie uns an.