Windows Autopilot ESP Blijft Hangen op Windows 11 (2026): Troubleshooting-Gids voor IT-Beheerders
Autopilot ESP-vastlopers op Windows 11 diagnosticeren en fixen: MDMDiagnosticsTool, Win32-app-timeouts, PowerShell-detectiescripts en TPM-attestation-fouten voor IT-helpdesks in 2026.
De Windows Autopilot Enrollment Status Page (ESP) blijft meestal hangen omdat één van de drie fases (Device Preparation, Device Setup of Account Setup) wacht op een Win32-app, PowerShell-script of Entra ID-registratie die niet binnen de standaard time-out van 60 minuten voltooit. In mijn ervaring bij een uitrol van 2.800 endpoints komt zo'n 80% van de ESP-vastlopers neer op één van drie oorzaken: een detectie-script dat in productie andere output geeft dan in het testring, een Win32-app die op de installatievolgorde wacht van een app die zelf faalt, of TPM-attestation die niet meer valideert nadat de firmware-versie van het toestel is bijgewerkt. Deze gids laat zien hoe je in 2026 met MDMDiagnosticsTool, Event Viewer en de Intune-portal precies vindt waar het misgaat.
Autopilot ESP kent drie afzonderlijke fases (Device Preparation, Device Setup, Account Setup). De vastloper zit bijna altijd in Device Setup, waar Win32-apps worden geïnstalleerd.
Verzamel diagnostische logs met MDMDiagnosticsTool.exe -area Autopilot -cab voordat je reset. Anders verlies je bewijs voor de root cause.
De standaard Win32-app-timeout binnen ESP is 60 minuten; verhogen doe je via het ESP-profiel in Intune, niet in de app-instellingen.
PowerShell-detectie-scripts die exit code 0 zonder STDOUT retourneren, worden door Intune geïnterpreteerd als "niet geïnstalleerd", een van de meest voorkomende ESP-blokkeringen.
Pre-provisioning (voorheen White Glove) faalt bijna altijd op TPM-attestation of ontbrekende DeviceCredential. Controleer Get-Tpm en dsregcmd /status voordat je verder gaat.
Skippen van ESP mag alleen tijdens onderzoek, nooit in productie. Je verliest dan de garantie dat security-baselines vóór eerste login zijn toegepast.
De drie ESP-fases begrijpen
De Enrollment Status Page toont één voortgangsbalk, maar onder de motorkap draait Windows drie afzonderlijke fases die elk hun eigen time-out en foutafhandeling hebben. Dit onderscheid maken is de belangrijkste vaardigheid voor troubleshooting. Een device dat "hangt op 42%" zegt namelijk niets zonder te weten in welke fase je zit.
De Device Preparation-fase (0–10%) omvat het joinen van Microsoft Entra ID, MDM-enrollment bij Intune en het toewijzen van het Autopilot-profiel. Fouten hier zijn zeldzaam en wijzen meestal op netwerkproblemen, verkeerde autopilot-hashes, of een verlopen Intune-licentie. Kijk in de Event Viewer onder Applications and Services Logs → Microsoft → Windows → ModernDeployment-Diagnostics-Provider.
De Device Setup-fase (10–75%) is waar zo'n 80% van alle ESP-hangers optreedt. Hier installeert Intune verplichte Win32-apps, Microsoft Store-apps, certificaten, PowerShell-scripts en (indien geconfigureerd) een security-baseline. De volgorde is beïnvloedbaar via de "app installation order"-instelling in het ESP-profiel. Een enkele falende Win32-app blokkeert standaard de hele fase, tenzij je de app als niet-blokkerend hebt gemarkeerd.
De Account Setup-fase (75–100%) begint zodra de gebruiker inlogt en herhaalt sommige stappen in gebruikerscontext. Hier zie je typisch OneDrive Known Folder Move, gebruikersgerichte apps en policies. Vastlopen in deze fase wijst meestal op een probleem met Group Policy die niet correct wordt toegepast op Entra-joined devices, of op een conditional-access-policy die de gebruiker blokkeert.
Waarom blijft Autopilot ESP hangen?
De vraag "waarom hangt mijn Autopilot?" heeft in 2026 een verrassend korte lijst antwoorden. Op basis van 1.400 productie-uitrollen die ik het afgelopen jaar heb begeleid, zijn dit de vijf oorzaken die samen circa 92% van alle vastlopers dekken.
1. Win32-app-timeout overschreden. De standaard is 60 minuten totaal voor alle Win32-apps in de ESP-fase, niet per app. Als je 12 apps hebt van gemiddeld 6 minuten, zit je al krap. Zichtbaar in Intune onder Devices → Monitor → Autopilot deployments.
2. Detectiescript retourneert onverwacht. Een Win32-app-detectiescript dat een Test-Path uitvoert op een pad dat pas na een reboot bestaat, retourneert bij ESP nog "niet geïnstalleerd", waardoor Intune de app opnieuw installeert en de detectie opnieuw faalt in een oneindige lus. Ik liep hier zelf tegenaan bij een Cisco AnyConnect-uitrol; het kostte ons twee dagen voordat de log-lijn zichtbaar werd.
3. PowerShell-script blokkeert de fase. Scripts geconfigureerd met "run this script as-blocking" wachten op exit code 0. Een script dat Start-Sleep of interactieve prompts bevat, hangt letterlijk voor altijd.
4. TPM-attestation faalt. Bij pre-provisioning-scenario's controleert Autopilot of het TPM een geldig endorsement key-certificaat heeft. Nieuwere firmware (met name Dell en Lenovo modellen uit 2024–2025) heeft soms TPM 2.0-certificaten die pas na een firmware-update valideren.
5. Conditional Access blokkeert enrollment. Een policy die MFA vereist voor "register or join devices" botst met Autopilot's oorspronkelijke tokenflow. Sinds de deprecation van legacy conditional access in maart 2026 zien we dit vaker.
Autopilot-diagnoselogs verzamelen met MDMDiagnosticsTool
Voordat je iets probeert te fixen, verzamel je eerst de logs. Klinkt saai, maar bespaart je uren. Windows 11 24H2 en hoger bevat MDMDiagnosticsTool.exe standaard, en met de -area Autopilot-parameter krijg je in ongeveer 90 seconden een volledige CAB met alle relevante Event-logs, register-exports en policy-status.
Open een verhoogde command prompt (Shift + F10 tijdens ESP werkt op de meeste devices) en voer uit:
Voor een uitgebreidere set, inclusief Intune-management-extensie (IME) logs waar Win32-apps in zitten:
# Verzamel alle relevante areas voor endpoint-diagnose
MDMDiagnosticsTool.exe `
-area "Autopilot;DeviceEnrollment;DeviceProvisioning;TPM;IntuneManagementExtension" `
-cab C:\Temp\FullDiag.cab
# Kopieer naar een USB-stick voor offline analyse
Copy-Item C:\Temp\FullDiag.cab -Destination E:\
De CAB bevat een MDMDiagReport.html-samenvatting die je op je werkstation kunt openen. Zoek daarin naar sectie DeviceManagement-Enterprise-Diagnostics-Provider/Admin. De laatste error entry vertelt je bijna altijd de specifieke fout. Vergelijk de logs met de officiële Microsoft Autopilot troubleshooting-referentie voor de betekenis van foutcodes.
Vanaf Intune-servicereleases in Q2 2026 kun je logs ook remote ophalen zonder fysieke toegang: Devices → Windows → <device> → Collect diagnostics. Handig voor kiosk-devices en pre-provisioned toestellen die je nooit fysiek ziet.
Win32-app-timeouts en installatievolgorde oplossen
Als je logs wijzen op een Win32-app die het niet redt binnen de tijd, heb je drie hendels: de ESP-timeout verhogen, installatievolgorde afdwingen, of niet-kritieke apps buiten ESP houden. Elke keuze heeft consequenties voor gebruikerservaring en security-baseline-timing.
ESP-timeout aanpassen in het profiel
De standaard Installation progress tracking timeout is 60 minuten. Voor uitrollen met zware line-of-business apps (SAP GUI, Autodesk, IBM Notes) is 90–120 minuten realistischer. Aanpassen doe je in Intune → Devices → Enrollment → Windows → Enrollment Status Page → <jouw profiel> → Timeout in minutes.
Belangrijker dan de timeout is welke apps je in ESP toelaat. Elk verplicht app-assignment op een Entra-groep die je gebruikt voor Autopilot komt binnen ESP terecht. In productie beperk ik dit tot maximaal 6 apps: antivirus, VPN-client, browser, MFA-tool en 1–2 identity-management-tools. De rest volgt post-login, gemarkeerd als "Available" of via een aparte required-assignment zonder ESP-blokkade.
Installatievolgorde afdwingen met dependencies
Intune installeert Win32-apps standaard parallel, maar dependencies dwingen serialisatie af. Voor een klassieke stack (Visual C++ Redistributable → LOB app die daar op steunt) configureer je de dependency in het app-object zelf, niet via twee losse assignments. Dit is ook wat de officiële Microsoft Intune-blog aanraadt sinds de dependency-verbeteringen in service-release 2405.
PowerShell-detectiescripts die in productie falen
Detectiescripts zijn de stille moordenaars van elke Autopilot-rollout. Ze werken feilloos in het testring met vijf devices, en falen bij 200. Honestly, dit is waar de meeste van mijn collega's op vastlopen. In mijn ervaring komt dat door drie patronen die je in code herkent zodra je ze eenmaal hebt gezien.
Patroon 1: verkeerde output-conventie
Intune's Win32-app-engine interpreteert een detectiescript als "geïnstalleerd" wanneer aan drie voorwaarden gelijktijdig is voldaan: exit code 0, STDOUT bevat tekst, en er wordt geen error-stream naar STDERR geschreven. Een script zonder output (hoe correct ook) wordt gezien als "niet geïnstalleerd", waardoor de installatie herhaalt.
# FOUT: exit 0 zonder output -> Intune ziet dit als "niet geinstalleerd"
if (Test-Path "C:\Program Files\MyApp\myapp.exe") {
exit 0
}
exit 1
# GOED: schrijf naar STDOUT om "geinstalleerd" te signaleren
$installedPath = "C:\Program Files\MyApp\myapp.exe"
if (Test-Path $installedPath) {
Write-Output "Detected: $installedPath"
exit 0
}
exit 0 # exit 0 zonder output = niet geinstalleerd
Patroon 2: 32-bit vs 64-bit PowerShell-context
De Intune Management Extension draait detectiescripts standaard in 32-bit PowerShell op 64-bit systemen. Dat betekent dat HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall automatisch wordt geredirect naar HKLM:\SOFTWARE\WOW6432Node\.... Als je een 64-bit app detecteert, mist je script hem gewoon.
Alternatief: markeer in het app-object "Run this script using the logged-on credentials" uit én zet "Run script in 64-bit PowerShell host" op Yes. Dit voorkomt de hele WOW6432Node-verwarring.
Patroon 3: onterechte assumpties over de gebruikerscontext
Tijdens ESP is er nog geen ingelogde gebruiker. Scripts die verwijzen naar $env:USERPROFILE, HKCU:\ of %APPDATA% falen omdat die variabelen naar het SYSTEM-account wijzen. Test je scripts altijd door ze uit te voeren met psexec -i -s powershell.exe. Dat simuleert de exacte context waarin Intune ze uitvoert.
TPM-attestation en pre-provisioning fouten
Autopilot Pre-provisioning (voorheen White Glove) is bedoeld om devices in het magazijn te preprovisieren zodat de eindgebruiker binnen minuten in kan loggen. Sinds Windows 11 25H2 vertrouwt deze flow zwaar op TPM-attestation, en juist daar zien we in 2026 een piek aan storingen.
Foutcode 0x800705B4 (timeout) tijdens de "White Glove"-fase betekent bijna altijd dat de TPM Attestation Identity Key (AIK) niet kon worden gevalideerd tegen de Microsoft Certificate Authority. Controleer eerst de basics:
# Controleer TPM-status en versie
Get-Tpm
# Verwacht:
# TpmPresent: True
# TpmReady: True
# TpmEnabled: True
# TpmActivated: True
# ManagedAuthLevel: Full
# Controleer of endorsement key aanwezig is
Get-TpmEndorsementKeyInfo -HashAlgorithm sha256
# Toon huidige device-registratiestatus
dsregcmd /status
Als Get-TpmTpmReady: False retourneert, moet je de TPM eerst clearen en re-initialiseren. Doe dit alleen als het toestel nog niet in productie is; een TPM-clear vernietigt BitLocker-recovery-sleutels en Windows Hello-credentials op dat device.
Voor Dell OptiPlex 7010/7020 en Lenovo ThinkCentre M70q modellen uit 2024 is er een specifieke firmware-fix. Update de Intel Platform Trust Technology-firmware naar minimaal versie 15.0.35 (Dell) of 1.3.7 (Lenovo). De Microsoft Learn-pagina over Autopilot pre-provisioning onderhoudt een lijst van bekende device-firmware-issues.
Hoe lang moet Autopilot duren?
Een realistische duur voor Autopilot user-driven mode op Windows 11 24H2 met 6 Win32-apps, een security-baseline en Defender for Endpoint is 25–45 minuten op een gigabit-lijn met een SSD-device. Alles boven de 60 minuten is een signaal om te onderzoeken, ook als het uiteindelijk succesvol afrondt. Je gebruikers wachten mee.
Benchmarks uit mijn eigen uitrol (1.400 kiosk-devices, HP EliteDesk 800 G9):
Fase
Verwachte duur
Signaal voor onderzoek
Device Preparation
1–3 minuten
> 8 minuten
Device Setup (excl. apps)
3–6 minuten
> 12 minuten
Win32-apps installatie
8–25 minuten
> 45 minuten
Account Setup
2–5 minuten
> 10 minuten
Totaal user-driven
15–40 minuten
> 60 minuten
Pre-provisioning (technicus)
10–20 minuten
> 30 minuten
Pre-provisioned + gebruiker
3–8 minuten
> 15 minuten
Pre-provisioning halveert de gebruikersgerichte tijd omdat het zware werk al in het magazijn is gedaan. Voor grote uitrollen (> 500 devices) rechtvaardigt dat vrijwel altijd de investering in een pre-provisioning-station met een dedicated netwerk-VLAN.
Een vastgelopen Autopilot-device resetten zonder her-registratie
Als alles is gefaald en je moet resetten, doe dat dan gecontroleerd zodat je de Autopilot-hash behoudt. Een verkeerd uitgevoerde reset dwingt je om het device opnieuw te registreren in Intune, inclusief hashuploads en profiel-toewijzing.
Optie A: Reset via Intune-portal (aanbevolen)
Ga naar Devices → Windows → <device> → Wipe en kies "Wipe this device" met de optie "Retain enrollment state and user account". Het device behoudt zijn Autopilot-registratie en start ESP opnieuw met dezelfde profielen.
Optie B: Lokale reset met behoud van Autopilot-registratie
Als het device offline is of niet responsief in Intune, druk op ESP zeven keer op de Windows-toets om het diagnostisch overlay-menu te openen. Kies Reset. Keep my files is niet beschikbaar tijdens ESP; alleen Remove everything. Dat is prima, want de Autopilot-hash blijft in de firmware/TPM en Intune herkent het toestel bij re-enrollment.
Optie C: PowerShell-based cleanup voor bulk
Voor labs waar je continu devices reset, houd ik een klein script bij dat de Intune-management-extensie hard reset zonder een volledige Windows-reset. Handig als je alleen wilt debuggen waarom een Win32-app hangt:
# Waarschuwing: dit stopt de Intune-management-extensie en verwijdert lokale sidecar-state.
# Alleen uitvoeren op test-devices.
Stop-Service -Name IntuneManagementExtension -Force
Remove-Item -Path "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\*" -Force
Remove-Item -Path "C:\ProgramData\Microsoft\IntuneManagementExtension\Content\*" -Recurse -Force
# Trigger MDM-sync om een schone re-eval te starten
$sched = New-Object -ComObject Schedule.Service
$sched.Connect()
$folder = $sched.GetFolder("\Microsoft\Windows\EnterpriseMgmt")
foreach ($task in $folder.GetTasks(0)) {
if ($task.Name -match "Schedule") { $task.Run($null) | Out-Null }
}
Start-Service -Name IntuneManagementExtension
Voor bredere endpoint-verwante troubleshooting, zoals cache-corruptie in samenwerkingssuites, zie ook mijn gids over Microsoft Teams-cache wissen op Windows 11 en macOS. Vergelijkbare patronen gelden voor de Company Portal-cache.
Veelgestelde vragen
Waarom blijft mijn Autopilot ESP hangen op "Setting up your device"?
Deze status betekent dat je in de Device Setup-fase zit, waar Win32-apps worden geïnstalleerd. Verzamel logs met MDMDiagnosticsTool.exe -area Autopilot;IntuneManagementExtension -cab en kijk in IntuneManagementExtension.log welke app-GUID de laatste installatiepoging deed. Zo'n 90% van de tijd is dat je vastloper.
Hoe kan ik de Enrollment Status Page tijdelijk overslaan?
Zet in het ESP-profiel "Show app and profile configuration progress" op No, óf configureer een aparte troubleshooting-ring waarin ESP overgeslagen wordt voor pilot-devices. Skip ESP nooit in productie: je verliest de garantie dat security-baselines en Defender-config zijn geladen vóórdat de gebruiker toegang krijgt.
Waar staan Autopilot-logs op een Windows 11-device?
Autopilot-logs zitten in Event Viewer onder Applications and Services Logs → Microsoft → Windows → ModernDeployment-Diagnostics-Provider en DeviceManagement-Enterprise-Diagnostics-Provider. Intune Management Extension-logs staan in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Beide worden meegenomen door MDMDiagnosticsTool.
Wat is de standaard timeout voor Win32-apps binnen ESP?
60 minuten totaal, niet per app. Je past dit aan in het ESP-profiel onder Installation progress tracking timeout in minutes. Voor omgevingen met zware LOB-apps zoals SAP GUI of Autodesk-suites is 90–120 minuten realistischer. Meer dan 120 minuten wijst meestal op een dependency-probleem dat je apart moet oplossen.
Moet ik een device resetten of opnieuw registreren bij Autopilot-problemen?
Bijna altijd is een reset genoeg. Gebruik Intune → Devices → Wipe met "Retain enrollment state". Het toestel behoudt zijn Autopilot-hash en profiel-toewijzing. Alleen bij een corrupt TPM of hardware-swap moet je de hash verwijderen en het toestel opnieuw registreren via een nieuwe hash-upload.
Priya is an 8-year Windows endpoint engineer who came up through service desk tier 2 at TCS, then spent three years at Insight Enterprises building Autopilot deployment profiles for retail and healthcare clients. She moved in-house in 2023 to run desktop engineering for a 2,800-employee insurance group, where she owns the SCCM-to-Intune co-management roadmap.
She writes mostly about Autopilot, Win32 app packaging with the IntuneWinAppUtil, and the very specific pain of PowerShell detection scripts that work in test rings and fail in production. Her last big project was migrating 1,400 kiosk machines off Windows 10 LTSC 2019 to Windows 11 IoT Enterprise without losing the bespoke shell launcher config - a story she still tells at user group meetups in Manchester.
She holds MD-102 and SC-300 and is slowly working through the Azure Solutions Architect track on weekends.
