Een van de meest frustrerende Windows Autopilot-problemen is een apparaat dat tijdens de Enrollment Status Page (ESP) blijft hangen.
De gebruiker ziet bijvoorbeeld dat:
- Device Preparation niet verdergaat;
- Device Setup blijft hangen;
- Account Setup niet voltooit;
- een required app blijft installeren;
- een policy niet wordt verwerkt;
- de ESP uiteindelijk een foutmelding toont;
- provisioning extreem lang duurt zonder duidelijke oorzaak.
De reflex is vaak:
Autopilot werkt niet.
Maar de Enrollment Status Page is meestal slechts de plek waar een onderliggend probleem zichtbaar wordt.
De echte oorzaak kan liggen bij:
- Win32-applicaties;
- detection rules;
- dependencies;
- install context;
- Configuration Profiles;
- security policies;
- netwerk;
- compliance;
- Conditional Access;
- device assignment;
- timing;
- Intune Management Extension;
- een verkeerd ontworpen blocking app-set.
Een goede troubleshootingaanpak begint daarom met deze vraag:
Welke specifieke dependency voorkomt dat ESP de provisioning als voltooid beschouwt?
Wat doet de Enrollment Status Page?
De Enrollment Status Page laat tijdens Windows Autopilot zien hoe ver een apparaat is met de benodigde configuratie voordat de gebruiker volledig kan doorgaan.
Conceptueel:
Autopilot
↓
Microsoft Entra Join
↓
Intune Enrollment
↓
ESP
↓
Policies
↓
Security
↓
Applications
↓
User
↓
Productive Device
ESP functioneert daarmee als een zichtbare controlelaag tijdens provisioning.
ESP is niet de oorzaak, maar de boodschapper
Dit is een belangrijk troubleshootingprincipe.
Wanneer ESP blijft hangen, betekent dit vaak:
een required dependency is nog niet succesvol verwerkt.
Dus niet:
ESP zelf is kapot.
Daarom moet u eerst bepalen welk onderdeel blocking is.
De drie ESP-fasen
Conceptueel wordt vaak onderscheid gemaakt tussen:
Device Preparation
Device Setup
Account Setup
De precieze zichtbaarheid en verwerking kan per scenario verschillen, maar deze indeling helpt bij troubleshooting.
Fase 1 — Device Preparation blijft hangen
Wanneer het probleem heel vroeg ontstaat, controleer dan eerst:
- Autopilot profile;
- device registration;
- Entra Join;
- Intune enrollment;
- netwerkconnectiviteit;
- servicebereikbaarheid;
- basisidentiteit van het apparaat.
Een fout in deze fase wijst vaak op een probleem vóórdat de meeste applicaties en policies überhaupt aan bod komen.
Fase 2 — Device Setup blijft hangen
Dit is vaak de interessantste fase.
Hier kunnen onder andere spelen:
- device-targeted policies;
- securityconfiguratie;
- required apps;
- Win32-apps;
- Intune Management Extension;
- dependencies;
- detection;
- reboots.
Bij veel Autopilotproblemen ligt de root cause hier.
Fase 3 — Account Setup blijft hangen
Dan verschuift de aandacht vaker naar:
- user-targeted configuration;
- user-targeted apps;
- identity;
- profieltoepassing;
- per-user settings;
- timing van gebruikersgerichte policies.
Ook hier geldt: eerst bepalen wat werkelijk blocking is.
EndpointPilot troubleshootingprincipe
Gebruik bij ESP-problemen:
Phase first, dependency second, logs third.
Dus:
1. In welke ESP-fase stopt het?
↓
2. Welke dependency hoort daar verwerkt te worden?
↓
3. Welke logs bevestigen waar het faalt?
Dat is veel efficiënter dan willekeurig policies uitschakelen.
Begin met een tijdlijn
Leg vast:
- wanneer device start;
- wanneer OOBE begint;
- wanneer Entra Join plaatsvindt;
- wanneer Intune enrollment start;
- wanneer ESP zichtbaar wordt;
- welke fase blijft hangen;
- wanneer eventuele foutmelding verschijnt.
Bijvoorbeeld:
| Tijd | Event |
|---|---|
| 09:00 | Device start |
| 09:03 | User sign-in |
| 09:05 | Entra Join |
| 09:07 | Intune Enrollment |
| 09:09 | ESP Device Setup |
| 09:11 | Win32 apps starten |
| 09:37 | Nog steeds Device Setup |
Dan weet u waar u moet zoeken.
Symptoom 1 — ESP blijft hangen op een required Win32-app
Dit is een zeer veelvoorkomend scenario.
De volledige keten is dan:
Assignment
↓
Requirements
↓
Download
↓
Install Context
↓
Install Command
↓
Dependencies
↓
Installer
↓
Return Code
↓
Detection
↓
ESP Status
Iedere stap kan de provisioning blokkeren.
Controleer eerst welke app blocking is
Ga niet af op de veronderstelling:
Het is waarschijnlijk Office.
Bepaal exact:
- welke app required is;
- welke app blocking is;
- welke status wordt gerapporteerd;
- welke app als laatste actief was;
- welk tijdstip relevant is.
Blocking app versus required app
Niet iedere required app hoeft de gebruiker tijdens ESP tegen te houden.
Dat onderscheid is cruciaal.
Een app kan:
required
zijn
maar:
niet noodzakelijk blocking voor first productive use.
EndpointPilot-aanbeveling
Gebruik blocking alleen voor software die aantoonbaar noodzakelijk is voor:
- veilige eerste start;
- fundamentele productiviteit;
- verplichte infrastructuur.
Niet voor iedere zakelijke applicatie.
Symptoom 2 — Installatie is gelukt maar ESP blijft wachten
Dit wijst vaak op detection.
Bijvoorbeeld:
Installer draait succesvol.
App staat zichtbaar op het apparaat.
Maar de detection rule bevestigt niet dat de app aanwezig is.
Resultaat:
installatie technisch gelukt
maar:
Intune ziet app als niet geïnstalleerd
en dus:
ESP blijft wachten of faalt.
Detection rules zijn kritisch
Controleer:
- bestandspad;
- bestandsnaam;
- registry path;
- registry value;
- MSI productcode;
- versiecontrole;
- 32-bit versus 64-bit context;
- custom detection script.
De detection rule moet overeenkomen met de werkelijke post-install state.
Detection moet ook upgrades overleven
Een rule die alleen versie 1.0 detecteert kan falen zodra versie 1.1 wordt geïnstalleerd.
Bijvoorbeeld:
C:\Program Files\App\app-1.0.exe
is fragieler dan een stabiele indicator.
Ontwerp detection dus ook voor lifecycle.
Symptoom 3 — Win32-app installeert lokaal maar niet tijdens Autopilot
Dit is klassiek.
Handmatig getest:
werkt
Tijdens ESP:
faalt
Vaak komt dat door contextverschillen.
SYSTEM is niet hetzelfde als Administrator
Een installatie die werkt als lokale administrator hoeft niet te werken in SYSTEM-context.
Controleer:
- install context;
- userprofile-afhankelijkheden;
- network access;
- mapped drives;
- environment variables;
- registry hive;
- certificate access;
- interactive prompts.
Silent installation is verplicht
Een installer die wacht op:
Next
Accept
Install
zal tijdens Autopilot niet betrouwbaar werken.
Gebruik volledig stille installatieparameters.
Symptoom 4 — Dependency chain faalt
Bijvoorbeeld:
App A
heeft:
App B
nodig.
App B heeft:
App C
nodig.
App C faalt.
Resultaat:
App A installeert nooit.
ESP toont mogelijk alleen het zichtbare eindprobleem.
Houd dependencies beperkt
Hoe dieper de dependencyketen, hoe meer foutpunten.
Voorkom indien mogelijk:
A → B → C → D → E
Maak packaging zo zelfstandig mogelijk.
Symptoom 5 — Return code wordt verkeerd geïnterpreteerd
Een installer kan technisch slagen maar een code teruggeven die Intune anders interpreteert.
Controleer daarom:
- installer exit code;
- Intune return code mapping;
- rebootrequired;
- retrygedrag.
Een code die lokaal als “succes met reboot” wordt gezien, kan anders in uw packaging worden geïnterpreteerd.
Rebootgedrag
Reboots tijdens Autopilot kunnen complexiteit introduceren.
Controleer:
- installer reboot;
- forced reboot;
- soft reboot;
- pending reboot;
- Intune return code;
- ESP response.
Vermijd installers die onverwacht zelf rebooten.
Symptoom 6 — Eén app duurt extreem lang
Maak een app-timeline.
Bijvoorbeeld:
| App | Start | Einde | Duur |
|---|---|---|---|
| Security Agent | 09:11 | 09:13 | 2 min |
| M365 | 09:13 | 09:21 | 8 min |
| VPN | 09:21 | 09:23 | 2 min |
| LOB App | 09:23 | 09:49 | 26 min |
Nu is de bottleneck zichtbaar.
Package size
Grote Win32-packages kunnen provisioning vertragen door:
- downloadtijd;
- content processing;
- installatietijd;
- retries.
Vraag:
Moet deze app werkelijk blocking zijn?
Web installers zijn extra riskant
Installers die tijdens setup zelf internetcontent downloaden voegen extra afhankelijkheden toe.
Bijvoorbeeld:
Intune download
↓
installer start
↓
installer downloadt externe content
↓
vendor CDN
↓
installatie
Dat vergroot het aantal mogelijke failure points.
Waar mogelijk zijn voorspelbare, self-contained packages beter.
Symptoom 7 — ESP faalt alleen thuis, niet op kantoor
Dit is een belangrijke aanwijzing.
Onderzoek:
- DNS;
- proxy;
- firewall;
- captive portal;
- wifi;
- bandwidth;
- content delivery;
- externe installer-URLs;
- TLS inspection.
Autopilot moet worden getest op het netwerk waar gebruikers het werkelijk gaan gebruiken.
Test buiten corporate LAN
Een volledig succesvolle labtest op:
1 Gbit ethernet
is niet voldoende wanneer medewerkers thuis via wifi provisionen.
Test ook:
- gewone thuisverbinding;
- tragere verbinding;
- mobiele hotspot;
- hoge latency.
Symptoom 8 — ESP faalt alleen op één apparaat
Dan is een globale configuratiefout minder waarschijnlijk.
Vergelijk met een known-good device.
Controleer:
- model;
- Windows build;
- hardware;
- registration;
- Group Tag;
- profile;
- assignment;
- disk space;
- repair history.
Symptoom 9 — ESP faalt op alle apparaten sinds een change
Dan moet u recent gewijzigde onderdelen onderzoeken.
Bijvoorbeeld:
- nieuwe blocking app;
- nieuwe detection rule;
- nieuwe dependency;
- security policy;
- ESP-configuratie;
- profile assignment.
Gebruik:
last known good
als referentie.
Symptoom 10 — ESP faalt alleen bij één hardwaremodel
Onderzoek:
- drivers;
- OEM software;
- firmware;
- hardware-specific requirements;
- architecture;
- TPM;
- security capability.
Een modelgebonden patroon is waardevolle informatie.
Symptoom 11 — Security policy blokkeert installer
Sommige securitycontrols kunnen legitieme installaties blokkeren.
Bijvoorbeeld:
- Attack Surface Reduction;
- Defender;
- SmartScreen;
- application control;
- Firewall.
Verzwak security niet onmiddellijk.
Verzamel eerst bewijs dat de control daadwerkelijk de installatie blokkeert.
Security versus deployment
De juiste aanpak is niet:
ASR uitzetten zodat Autopilot werkt.
Maar:
waarom is deze installer niet compatibel met de securitybaseline?
Mogelijke structurele oplossing:
- package aanpassen;
- trusted source;
- signing;
- installer update;
- beperkte uitzondering;
- vendor fix.
Symptoom 12 — Antivirus scant groot installatiepakket
Dit kan installatietijd beïnvloeden.
Maar ook hier geldt:
Meet eerst.
Ga niet op gevoel security uitschakelen.
Symptoom 13 — Device Setup klaar, Account Setup blijft hangen
Dan verschuift de aandacht naar user-context.
Controleer:
- user-targeted apps;
- user policies;
- profileconfiguratie;
- identity;
- first sign-in processing.
Splits device- en userproblemen.
Device-targeted versus user-targeted apps
Voor Autopilot is deze scheiding belangrijk.
Device-targeted apps kunnen eerder in provisioning relevant worden.
User-targeted apps zijn afhankelijk van usercontext.
Bepaal daarom per app:
is dit onderdeel van device baseline of user persona?
Minimaliseer user blocking
Niet iedere gebruikersapp hoeft eerste login te blokkeren.
Dat vermindert de kans dat Account Setup lang duurt.
Symptoom 14 — ESP toont fout, maar device lijkt uiteindelijk bruikbaar
Dit kan betekenen dat een blocking component volgens Intune niet succesvol is, terwijl een deel van Windows wel werkt.
Behandel dit niet als:
gebruiker kan werken, dus klaar.
Onderzoek de ontbrekende component.
Misschien ontbreekt:
- securitysoftware;
- management agent;
- required app;
- policy.
“Desktop zichtbaar” is geen acceptatiecriterium
De echte vraag is:
Is het device veilig en voldoende productief?
Dat vraagt controle van:
- management;
- security;
- apps;
- compliance.
Intune Management Extension logs
Bij Win32-app troubleshooting is de Intune Management Extension een belangrijke bron.
Een veelgebruikte loglocatie is:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
Belangrijke logbestanden kunnen inzicht geven in:
- app assignment;
- download;
- install;
- detection;
- retry;
- exit codes.
Begin bij de juiste timestamp
Open logs niet en lees willekeurig honderden regels.
Bepaal eerst:
wanneer begon de betreffende app?
Zoek vervolgens rond dat tijdstip.
Gebruik app identity
Noteer:
- app name;
- Intune app identity indien beschikbaar;
- install command;
- detection logic.
Zo kunt u gerichter logregels koppelen aan de juiste app.
Combineer Intune- en installerlogs
IME-log vertelt mogelijk:
installer returned code X.
Maar waarom?
Dat staat vaak in het eigen installerlog.
Dus:
Intune log
vendor installer log
=
veel sterkere analyse.
Forceer installerlogging waar mogelijk
Bij eigen packaging kunt u vaak verbose logging inschakelen.
Bijvoorbeeld:
install.log
of MSI logging.
Dan hoeft u bij een ESP-failure niet te raden.
Maak één troubleshootingpakket
Voor een failing app:
- app name;
- package version;
- install command;
- context;
- requirements;
- dependencies;
- return code;
- detection;
- IME log;
- installer log;
- timestamp.
Dit is bijna altijd voldoende voor een veel betere analyse.
Intune Management Extension opnieuw starten?
Soms wordt dit als troubleshootingstap gebruikt.
Maar doe dit niet automatisch.
Bepaal eerst of IME werkelijk vastgelopen is of dat een app/dependency het probleem veroorzaakt.
Sync lost slechte configuratie niet op
Evenzo:
Sync nog een keer.
kan helpen bij verwerking.
Maar het repareert geen:
- verkeerde detection;
- fout install command;
- ontbrekende dependency;
- onjuiste requirement.
Gebruik sync bewust.
Symptoom 15 — App blijft op Downloading
Onderzoek:
- content availability;
- netwerk;
- disk space;
- connectivity;
- package size;
- servicebereikbaarheid.
Vergelijk eventueel met andere apps op hetzelfde device.
Symptoom 16 — App blijft op Installing
Onderzoek:
- installerproces;
- child process;
- silent parameters;
- timeout;
- interactive dialog;
- pending reboot;
- installer log.
Een installer kan blijven wachten op een verborgen prompt.
Symptoom 17 — App blijft op Detection
Controleer detection logic.
Dit is vaak het scenario:
Install successful
↓
Detection false
↓
Intune retries
↓
ESP blijft hangen
Symptoom 18 — App installeert steeds opnieuw
Dit wijst sterk op een detectionprobleem.
Installatie:
✓
Detection:
✗
Daarom denkt Intune:
app ontbreekt.
En probeert opnieuw.
Symptoom 19 — App werkt na reboot
Dan kan rebootstate onderdeel zijn van de oorzaak.
Onderzoek:
- return code;
- restart requirement;
- detection timing;
- pending files;
- services die pas na reboot actief zijn.
Ontwerp package zo dat Intune dit gedrag correct begrijpt.
Symptoom 20 — App faalt door dependency op gebruiker
Bijvoorbeeld installer verwacht:
- userprofile;
- logged-on user;
- mapped drive;
- HKCU;
- user certificate.
Dat past mogelijk slecht bij device-context pre-login provisioning.
Herontwerp assignment of installer.
ESP en Configuration Profiles
Niet alleen apps kunnen problemen veroorzaken.
Ook configuration kan provisioning beïnvloeden.
Controleer bijvoorbeeld:
- policyconflicten;
- settings die reboot vereisen;
- securityconfiguraties;
- certificates;
- netwerkprofielen.
ESP en certificaten
Wanneer een kritieke app of netwerktoegang een certificaat vereist, kan sequencing belangrijk worden.
Bijvoorbeeld:
certificate profile
moet landen vóór:
VPN connectivity
of andere dependencies.
Ontwerp deze keten bewust.
ESP en Wi-Fi
Voor corporate network scenarios:
- profiel beschikbaar?
- certificaat aanwezig?
- authenticatie mogelijk?
- device/user context correct?
Maar voor remote Autopilot moet internettoegang al bestaan vóór corporate Wi-Fi relevant is.
ESP en VPN
VPN is niet automatisch noodzakelijk voor moderne cloud provisioning.
Als uw Autopilot-proces alleen kan slagen wanneer traditionele on-premise connectiviteit beschikbaar is, moet u beoordelen of de architectuur werkelijk cloud-native is.
Hybrid dependencies
Hoe meer provisioning afhankelijk is van:
- domain controllers;
- on-prem fileshares;
- legacy scripts;
- VPN;
- internal PKI;
hoe complexer remote Autopilot wordt.
Cloud-native designs zijn vaak voorspelbaarder.
Symptoom 21 — ESP faalt door te veel blocking apps
Dit is geen incident.
Het is een ontwerpissue.
Stel:
25 blocking apps
Iedere app heeft 98% kans op succes.
De kans dat alle 25 zonder probleem werken daalt al merkbaar.
Meer dependencies betekent meer failure opportunities.
Reliability multiplication
Conceptueel:
Als iedere dependency 99% betrouwbaar is:
10 dependencies:
ongeveer 90% kans dat alles zonder fout doorloopt.
20 dependencies:
ongeveer 82%.
Dit is vereenvoudigd, maar het principe is belangrijk:
Meer blocking dependencies verminderen de totale ketenbetrouwbaarheid.
Minimum Productive Device
Gebruik daarom opnieuw dit concept.
Een device moet vóór eerste desktop alleen bevatten wat noodzakelijk is voor:
veiligheid
basisproductiviteit
De rest kan daarna landen.
EndpointPilot blocking-app test
Vraag bij iedere app:
1. Is deze app noodzakelijk vóór eerste werkmoment?
2. Is hij zeer betrouwbaar?
3. Heeft hij weinig dependencies?
4. Werkt hij in SYSTEM-context?
5. Is detection robuust?
6. Is installatietijd acceptabel?
Als meerdere antwoorden nee zijn:
maak hem waarschijnlijk niet blocking.
Gebruik Company Portal voor optionele software
Applicaties zoals:
- Visio;
- Project;
- specialistische tools;
- utilities;
- afdelingssoftware
hoeven vaak geen Autopilot-blocker te zijn.
Gebruik required-after-provisioning
Een app kan automatisch worden geïnstalleerd nadat de gebruiker de desktop bereikt.
Dat behoudt automation zonder de kritieke ESP-keten onnodig groot te maken.
Troubleshooting door vergelijking
Gebruik een werkend en falend device.
Vergelijk:
| Factor | Werkt | Faalt |
|---|---|---|
| Profile | Standard | Standard |
| ESP | Standard | Standard |
| Network | Home Wi-Fi | Home Wi-Fi |
| App Set | Same | Same |
| LOB App version | 4.1 | 4.2 |
Nu heeft u een sterke aanwijzing.
Vergelijk last known good package
Als versie 4.1 werkte en 4.2 niet:
focus op:
- install command;
- package contents;
- detection;
- dependencies;
- vendor changes.
Niet op de hele Autopilotarchitectuur.
Verander één variabele
Een goed experiment:
V4.2 fails
↓
rollback naar V4.1 op testdevice
↓
V4.1 works
Sterk bewijs.
Een slecht experiment:
tegelijk package, ESP, Group Tag en profile wijzigen.
Troubleshooting met test-rings
Gebruik bijvoorbeeld:
Ring 0 — Lab
Ring 1 — IT
Ring 2 — Pilot users
Ring 3 — Production
Nieuwe blocking apps gaan nooit direct naar alle Autopilotdevices.
Autopilot als productieplatform
Wanneer een nieuwe blocking app de provisioning van alle nieuwe laptops kan stoppen, is die app een productiecomponent.
Behandel changes dus met dezelfde discipline als andere kritieke infrastructuur.
Change record
Leg minimaal vast:
- wat gewijzigd is;
- welke app/policy;
- oude versie;
- nieuwe versie;
- deployment ring;
- testresultaat;
- rollback.
Dan kunt u incidenten koppelen aan changes.
KPI: ESP Success Rate
Bijvoorbeeld:
500 provisionings
475 success
25 failures
ESP Success Rate:
95%
Categoriseer daarna de 25 failures.
KPI: Median Provisioning Time
Gemiddelde tijd kan worden verstoord door enkele extreme outliers.
Gebruik daarom ook:
median
en:
95th percentile
als u voldoende data heeft.
KPI: Failure by App
Bijvoorbeeld:
| App | Failures |
|---|---|
| Security Agent | 2 |
| M365 | 3 |
| VPN | 4 |
| Legacy LOB | 16 |
Nu weet u waar verbetering de meeste waarde heeft.
KPI: Rework Rate
Hoeveel devices moeten:
- retry;
- reset;
- opnieuw provisionen;
- handmatig behandeld worden?
Een hoge rework rate wijst op onvoldoende reliability.
KPI: First Productive Time
Meet:
Wanneer kan de gebruiker daadwerkelijk werken?
Dat is belangrijker dan alleen:
Wanneer verdwijnt ESP?
KPI: Support Tickets per 100 Autopilot Deployments
Bijvoorbeeld:
8 tickets / 100 devices
Na optimalisatie:
2 tickets / 100
Dat toont echte operationele verbetering.
Root Cause categorieën
Gebruik vaste categorieën:
Registration
Profile
Network
Win32 Packaging
Detection
Dependency
Policy
Security
Identity
Service
Hardware
Unknown
Na verloop van tijd ontstaat trenddata.
Een voorbeeldincident
Symptoom:
ESP blijft 40 minuten op Device Setup.
Onderzoek:
- registration: OK;
- profile: OK;
- network: OK;
- 4 blocking apps;
- Security Agent: OK;
- M365: OK;
- VPN: OK;
- LOB App: repeatedly retrying.
IME-log:
installer returns success.
Detection:
false.
Root cause:
detection path verwees naar oude installatiefolder.
Fix:
detection rule corrigeren.
Preventie:
package regression test toevoegen.
Tweede voorbeeldincident
Symptoom:
Alle nieuwe laptops blijven sinds dinsdag hangen.
Onderzoek:
Laatste change maandagavond:
nieuwe VPN package.
Resultaat:
installer opent verborgen interactieve dialog onder SYSTEM.
Root cause:
incorrect silent parameters.
Fix:
silent install aanpassen.
Preventie:
clean-device SYSTEM-context test verplicht.
Derde voorbeeldincident
Symptoom:
Alleen thuisgebruikers falen.
Kantoor werkt.
Onderzoek:
LOB installer downloadt extra component vanaf intern-only endpoint.
Root cause:
verborgen netwerkdependency.
Fix:
package self-contained maken of architectuur aanpassen.
Preventie:
remote-network test onderdeel van acceptance criteria.
Vierde voorbeeldincident
Symptoom:
ESP faalt alleen na securitybaseline-update.
Onderzoek:
ASR blokkeert een legacy installer.
Root cause:
installer gedrag conflicteert met securitycontrol.
Oplossing:
vendor/update/package aanpassen of een gecontroleerde uitzondering beoordelen.
Niet:
ASR tenantbreed uitschakelen.
Vijfde voorbeeldincident
Symptoom:
Account Setup duurt twintig minuten langer dan Device Setup.
Onderzoek:
twaalf user-targeted apps zijn blocking/relevant tijdens eerste login.
Root cause:
te brede user provisioning scope.
Oplossing:
Minimum Productive User bepalen en overige apps later installeren.
EndpointPilot 15-minuten ESP triage
Minuut 1–3
Bepaal exacte ESP-fase.
Minuut 4–5
Bepaal welke app/policy actief is.
Minuut 6–8
Controleer assignment en status.
Minuut 9–11
Bekijk relevante IME-/installerlogs.
Minuut 12
Controleer detection/return code.
Minuut 13
Vergelijk known-good device.
Minuut 14
Controleer recente changes.
Minuut 15
Formuleer één root-causehypothese.
Dat is veel effectiever dan meteen resetten.
Wanneer moet u resetten?
Reset kan logisch zijn wanneer:
- centrale oorzaak is opgelost;
- device state niet meer bruikbaar is;
- clean reprovisioning nodig is;
- validatietest opnieuw moet worden uitgevoerd.
Maar:
Fix the cause before repeating the process.
Anders reproduceert u dezelfde fout.
Wanneer moet u ESP niet uitschakelen?
Een verleidelijke reactie:
ESP veroorzaakt problemen, dus we zetten hem uit.
Daarmee verwijdert u mogelijk alleen de zichtbaarheid van het probleem.
Als een kritieke securityapp niet installeert, is de provisioning niet automatisch goed omdat de gebruiker eerder een desktop ziet.
ESP is een gate
Gebruik hem bewust.
Niet te streng.
Niet betekenisloos.
De ideale ESP controleert een kleine, betrouwbare set van essentiële componenten.
Wanneer moet u een blocking app verwijderen?
Wanneer analyse laat zien dat de app:
- niet noodzakelijk is vóór eerste gebruik;
- te vaak faalt;
- te lang duurt;
- slechte dependencies heeft;
- beter na provisioning kan landen.
Dan kan removal uit de blocking set de juiste architectuurverbetering zijn.
Wanneer moet u package opnieuw bouwen?
Bij:
- fragiele detection;
- interactieve installer;
- web dependency;
- verkeerde context;
- inconsistent exit codes;
- slechte uninstall;
- onvoorspelbare reboot.
Dan is package quality de root cause.
EndpointPilot ESP troubleshooting checklist
✓ exacte ESP-fase vastgesteld;
✓ timestamp genoteerd;
✓ registration gecontroleerd;
✓ Deployment Profile gecontroleerd;
✓ network gecontroleerd;
✓ blocking apps geïnventariseerd;
✓ failing app geïdentificeerd;
✓ assignment gecontroleerd;
✓ requirements gecontroleerd;
✓ install context gecontroleerd;
✓ command line gecontroleerd;
✓ dependencies gecontroleerd;
✓ package size gecontroleerd;
✓ return code gecontroleerd;
✓ detection gecontroleerd;
✓ rebootgedrag gecontroleerd;
✓ IME logs bekeken;
✓ installerlogs bekeken;
✓ securityblocking gecontroleerd;
✓ known-good device vergeleken;
✓ laatste change gecontroleerd;
✓ slechts één wijziging tegelijk uitgevoerd;
✓ root cause gedocumenteerd;
✓ preventieve actie vastgelegd.
EndpointPilot aanbevolen ESP-architectuur
Autopilot Profile
↓
Intune Enrollment
↓
ESP
↓
kleine set:
Security
Management
Critical Apps
↓
Desktop
↓
Non-critical Required Apps
↓
Optional Apps via Company Portal
Dat houdt de kritieke provisioningketen kleiner.
Het belangrijkste principe
Een Autopilot-device dat op ESP blijft hangen heeft niet automatisch een ESP-probleem.
Het heeft meestal een dependencyprobleem dat via ESP zichtbaar wordt.
Daarom:
Zoek niet naar wat ESP blokkeert. Zoek naar welk onderdeel ESP terecht nog niet als succesvol kan beschouwen.
Wanneer u fase, dependency, logs en timeline systematisch combineert, verandert Autopilot troubleshooting van trial-and-error in een voorspelbaar diagnoseproces.
Veelgestelde vragen over een vastlopende Autopilot ESP
Waarom blijft Windows Autopilot hangen op Enrollment Status Page?
Meestal omdat een required policy, app of andere dependency nog niet succesvol is verwerkt. Bepaal eerst in welke ESP-fase het probleem optreedt en welke component daar actief is.
Welke app laat Autopilot ESP hangen?
Controleer de status van required en blocking apps en vergelijk deze met relevante Intune Management Extension-logs. Kijk vooral naar install command, dependencies, return code en detection.
Waarom is een app geïnstalleerd maar blijft ESP hangen?
Een veelvoorkomende oorzaak is een verkeerde detection rule. De software staat dan op het apparaat, maar Intune detecteert de installatie niet als succesvol.
Waar staan de Intune Management Extension logs?
Een belangrijke loglocatie voor Win32-app troubleshooting is C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Gebruik timestamps en app-identiteit om de relevante regels te vinden.
Moet ik het device resetten als ESP blijft hangen?
Niet als eerste stap. Bepaal en herstel eerst de centrale oorzaak; anders kan dezelfde failure na de reset opnieuw optreden.
Kan een security policy Autopilot blokkeren?
Securitycontrols kunnen invloed hebben op installers of provisioning. Verzamel bewijs voordat u securityinstellingen verzwakt en probeer de installer of package structureel compatibel te maken.
Hoeveel apps moeten blocking zijn tijdens ESP?
Zo weinig mogelijk en alleen apps die daadwerkelijk noodzakelijk zijn voor veilige of productieve eerste ingebruikname. Iedere extra blocker vergroot de afhankelijkheidsketen.
Waarom werkt Autopilot op kantoor maar niet thuis?
Onderzoek netwerkafhankelijkheden, externe downloads, proxy/firewallgedrag en installers die interne bronnen vereisen. Test Autopilot altijd ook buiten het corporate netwerk.
Blijft Windows Autopilot hangen tijdens ESP?
Blijft Device Setup minutenlang of urenlang staan?
Faalt steeds dezelfde Win32-app?
Komt een laptop alleen thuis niet door Autopilot?
Of ziet u een ESP-fout maar is niet duidelijk welke dependency het probleem veroorzaakt?
Stel uw Intune-vraag — uw eerste vraag is gratis.
Stuur bij voorkeur:
- welke ESP-fase blijft hangen;
- de exacte foutmelding;
- welke required apps zijn toegewezen;
- welk apparaat/model het betreft;
- relevante timestamps;
- wat u al heeft onderzocht.
Deel geen wachtwoorden, tokens, secrets, private keys of andere gevoelige authenticatiegegevens.
Wij geven u een eerste praktisch advies over de waarschijnlijke oorzaak en de volgende troubleshootingstappen.