De Windows Autopilot Enrollment Status Page, meestal afgekort tot ESP, is een van de meest zichtbare onderdelen van het provisioningproces.
Tijdens de eerste inrichting van een Windows-apparaat toont ESP de voortgang terwijl Intune noodzakelijke configuraties, policies en applicaties verwerkt.
Dat klinkt eenvoudig.
Maar in de praktijk is ESP ook een van de onderdelen waar Autopilot-provisioning vaak traag wordt of volledig blijft hangen.
De oorzaak is meestal niet ESP zelf.
De oorzaak is vaak dat organisaties te veel afhankelijkheden in het kritieke provisioningpad plaatsen.
De belangrijkste ontwerpvraag is daarom:
Welke onderdelen moeten absoluut gereed zijn vóórdat de gebruiker de desktop bereikt — en welke kunnen daarna worden geïnstalleerd?
Een goede ESP-configuratie zoekt de juiste balans tussen:
security
beheerbaarheid
gebruikerservaring
provisioningsnelheid
betrouwbaarheid
Wat is de Enrollment Status Page?
De Enrollment Status Page laat tijdens Windows provisioning zien welke noodzakelijke stappen nog worden uitgevoerd voordat het apparaat volledig beschikbaar wordt.
Conceptueel:
Windows Autopilot
↓
Microsoft Entra Join
↓
Intune Enrollment
↓
Enrollment Status Page
↓
Device configuration
↓
Security
↓
Required applications
↓
Account configuration
↓
Desktop
ESP is daarmee een controlepunt tussen enrollment en eerste productieve gebruikerservaring.
Waarom bestaat ESP?
Zonder gecontroleerde provisioning kan een gebruiker de desktop bereiken terwijl belangrijke onderdelen nog ontbreken.
Bijvoorbeeld:
- securitysoftware;
- BitLockerconfiguratie;
- kritieke applicaties;
- relevante device policies;
- netwerkconfiguratie.
Dat kan leiden tot een apparaat dat technisch beschikbaar is, maar nog niet klaar is voor veilig zakelijk gebruik.
ESP geeft organisaties daarom de mogelijkheid om bepaalde onderdelen eerst te laten afronden.
ESP moet niet betekenen: alles moet klaar zijn
Dit is het belangrijkste ontwerpprincipe van dit artikel.
Een verkeerde interpretatie is:
We willen een perfect afgewerkte laptop voordat de gebruiker de desktop ziet.
Daarom worden bijvoorbeeld twintig, dertig of veertig applicaties als verplicht onderdeel van provisioning opgenomen.
Dat vergroot de kans op:
- lange provisioning;
- time-outs;
- app failures;
- dependencyproblemen;
- netwerkproblemen;
- restarts;
- frustratie bij gebruikers;
- extra servicedesktickets.
Een betere vraag is:
Wat heeft deze medewerker minimaal nodig om veilig en productief te kunnen beginnen?
Dat noemen we het Minimum Productive Device.
Definieer het Minimum Productive Device
Een Minimum Productive Device bevat alleen de componenten die noodzakelijk zijn voordat de gebruiker veilig kan starten.
Voor een standaard kenniswerker kan dat bijvoorbeeld zijn:
| Component | Blocking? |
|---|---|
| Intune enrollment | Ja |
| Basis device configuration | Ja |
| Endpoint Security | Ja |
| BitLocker | Afhankelijk van flow, maar securitykritiek |
| Microsoft 365 Apps | Vaak |
| VPN | Alleen wanneer direct noodzakelijk |
| Kritieke line-of-business app | Alleen indien noodzakelijk |
| OneDrive-configuratie | Relevant |
| Visio | Nee |
| Project | Nee |
| Optionele tools | Nee |
| Printersoftware | Meestal nee |
| Afdelingsapps | Alleen indien direct vereist |
De exacte set verschilt per organisatie.
Het ontwerpprincipe blijft hetzelfde:
houd de blocking set klein.
Waarom iedere extra blocking app risico toevoegt
Stel dat één blocking applicatie 99% betrouwbaar installeert.
Dat klinkt uitstekend.
Maar wanneer u tien onafhankelijke blocking apps heeft, vergroot u het aantal punten waarop provisioning kan falen.
Bij twintig apps wordt het kritieke pad nog groter.
Daarom is niet alleen de kwaliteit van iedere app belangrijk.
Ook het aantal dependencies is belangrijk.
Conceptueel:
Meer blocking components
↓
Meer afhankelijkheden
↓
Meer potentiële failures
↓
Lagere provisioningbetrouwbaarheid
Dit is een fundamenteel schaalbaarheidsprincipe.
Gebruik ESP als gate, niet als volledige buildstraat
ESP moet vooral bewaken dat het apparaat:
beheerd
voldoende beveiligd
voldoende geconfigureerd
voldoende productief
is.
Daarna kan Intune verdergaan met:
- extra applicaties;
- optionele software;
- minder kritieke configuration;
- afdelingstools;
- aanvullende updates.
Het apparaat hoeft niet volledig “af” te zijn om veilig bruikbaar te zijn.
De belangrijkste ESP-fasen
De provisioningervaring kan conceptueel uit meerdere onderdelen bestaan.
Een eenvoudige weergave:
Device Preparation
↓
Device Setup
↓
Account Setup
↓
Productieve desktop
De exacte verwerking hangt af van deploymentmodel, targeting en configuratie.
Voor troubleshooting is het belangrijk te weten in welke fase het proces stopt.
Device Preparation
In deze fase wordt het apparaat voorbereid voor beheer.
Hier kunnen bijvoorbeeld relevante processen plaatsvinden rondom:
- device identity;
- enrollmentvoorbereiding;
- benodigde managementcomponenten.
Wanneer het proces al hier faalt, ligt de oorzaak meestal niet bij een gewone gebruikersapp.
Onderzoek dan eerst:
Autopilot registration
Deployment Profile
identity
enrollment
netwerk
Device Setup
In deze fase worden device-targeted configuraties en applicaties belangrijk.
Denk aan:
- device policies;
- security;
- device-targeted required apps;
- relevante configuratie.
Dit is vaak een kritieke fase voor Autopilot.
Wanneer een required device-app faalt, kan provisioning stoppen.
Account Setup
Na deviceconfiguratie kunnen user-targeted settings en apps relevant worden.
Daarmee ontstaat een andere set dependencies.
Dit betekent dat troubleshooting altijd moet vragen:
Faalt de devicecontext of de usercontext?
Dat verschil kan veel tijd besparen.
Wat moet blocking zijn?
Gebruik een eenvoudige beslisregel.
Maak een component alleen blocking wanneer alle drie onderstaande uitspraken waar zijn:
1. De gebruiker kan zonder deze component niet veilig beginnen.
2. De gebruiker kan zonder deze component niet zinvol beginnen.
3. De component is voldoende betrouwbaar om onderdeel te zijn van het kritieke provisioningpad.
Wanneer één van deze drie niet klopt, is post-provisioning mogelijk verstandiger.
Voorbeeld: Microsoft 365 Apps
Voor veel kantoororganisaties zijn Microsoft 365 Apps kernsoftware.
Het kan daarom logisch zijn om deze vroeg beschikbaar te maken.
Maar test:
- installatietijd;
- netwerkbelasting;
- failure rate;
- updategedrag;
- restartgedrag;
- eventuele dependencies.
Wanneer de installatie structureel lang duurt, kan de businessvraag zijn:
Moet de volledige suite klaar zijn vóór de eerste desktop, of kan een deel daarna afronden?
Het antwoord hangt af van de gewenste gebruikerservaring.
Voorbeeld: VPN-client
VPN is alleen blocking wanneer de gebruiker direct na provisioning resources nodig heeft die uitsluitend via VPN bereikbaar zijn.
In een cloud-native omgeving kan dat minder relevant zijn.
Wanneer de belangrijkste resources Microsoft 365 en andere SaaS-diensten zijn, kan VPN mogelijk na de eerste desktop worden geïnstalleerd.
Daarmee verwijdert u een dependency uit het kritieke pad.
Voorbeeld: line-of-business applicatie
Stel dat iedere medewerker direct een ERP-client nodig heeft.
Dan kan deze applicatie blocking zijn.
Maar stel dat alleen Finance deze nodig heeft.
Dan is een organisatiebrede blocking assignment niet logisch.
Gebruik dan:
user-/businessgroep
↓
gerichte application assignment
en beoordeel of die app werkelijk vóór de eerste desktop nodig is.
Voorbeeld: printers
Printersoftware is bijna nooit een goede reden om een volledige Autopilot-provisioning te blokkeren.
Een medewerker kan meestal beginnen zonder dat alle printerdrivers aanwezig zijn.
Installeer printing daarom waar mogelijk later.
Hetzelfde geldt vaak voor:
- scanners;
- utilities;
- optionele add-ons;
- specialistische tools.
Security moet wel vroeg aanwezig zijn
Een apparaat moet niet urenlang productief worden gebruikt terwijl basisbeveiliging nog ontbreekt.
Daarom moet de provisioningarchitectuur ervoor zorgen dat relevante controls vroeg beschikbaar zijn.
Denk bijvoorbeeld aan:
- Defender;
- Firewall;
- BitLocker;
- device restrictions;
- identity protection.
De precieze technische timing verschilt per control, maar security moet onderdeel zijn van het minimum.
Maak security niet afhankelijk van onbetrouwbare packages
Een belangrijk onderscheid:
native Intune security policy
is vaak iets anders dan:
third-party security agent als Win32-app
Als een externe securityagent blocking is, wordt provisioning afhankelijk van:
- packagekwaliteit;
- installer;
- cloudservice;
- netwerk;
- dependencies;
- vendorstatus.
Dat kan legitiem zijn, maar test dit bijzonder zorgvuldig.
Win32-apps zijn de grootste ESP-risicocategorie
Veel ESP-problemen ontstaan rond Win32-applicaties.
Controleer per blocking Win32-app minimaal:
| Onderdeel | Test |
|---|---|
| Install command | Werkt silent? |
| Detection | Betrouwbaar? |
| Requirements | Correct? |
| Dependencies | Nodig en stabiel? |
| Return codes | Juist geïnterpreteerd? |
| Restart | Beheerst? |
| System/User context | Correct? |
| Downloadgrootte | Acceptabel? |
| Timeout | Realistisch? |
| Offline/slow network | Getest? |
Een Win32-app die niet volledig is gevalideerd hoort niet zomaar in het kritieke provisioningpad.
Detection rules kunnen provisioning laten falen
Stel:
De applicatie installeert succesvol.
Maar de detection rule kijkt naar:
C:\Program Files\App\app.exe
terwijl de applicatie op:
C:\Program Files (x86)\App\app.exe
terechtkomt.
Dan rapporteert Intune de installatie als niet gedetecteerd.
ESP kan daardoor blijven wachten of een failure tonen.
De werkelijke applicatie is aanwezig.
De detectie is fout.
Daarom is detection minstens zo belangrijk als installatie.
Test upgrade-scenario’s
Sommige devices worden niet vanuit volledig kale softwarestatus ingericht.
Een applicatie kan al aanwezig zijn via:
- OEM;
- eerdere installatie;
- recoveryimage;
- andere provisioning.
Test daarom ook:
app ontbreekt
app bestaat al
oude versie aanwezig
nieuwere versie aanwezig
app gedeeltelijk geïnstalleerd
Een betrouwbare detection rule moet deze situaties correct verwerken.
Let op dependencies
Een blocking app kan afhankelijk zijn van andere apps.
Bijvoorbeeld:
LOB App
↓
vereist
Runtime
↓
vereist
Framework
Dan is de daadwerkelijke blocking chain drie applicaties groot.
Documenteer dependencyketens.
Wanneer ze te complex worden, overweeg of de hoofdapp later kan worden geïnstalleerd.
Vermijd dependency chains van vijf of zes niveaus
Iedere extra laag betekent extra:
- download;
- installatie;
- detection;
- return codes;
- mogelijke failure.
Een eenvoudig package is vrijwel altijd beter voor provisioning.
Consolideer waar mogelijk, zonder packaging onnodig monolithisch te maken.
Restart behavior kan provisioning verstoren
Een applicatie kan tijdens installatie aangeven dat een restart nodig is.
Wanneer meerdere apps verschillende restartverwachtingen hebben, kan Autopilotgedrag onvoorspelbaar worden.
Leg daarom per blocking app vast:
vereist reboot?
welke return code?
mag Intune reboot initiëren?
wat gebeurt tijdens ESP?
kan reboot worden uitgesteld?
Test het volledige scenario.
Grote installers vertragen ESP
Een applicatie van 5 GB op een snelle kantoorverbinding lijkt misschien geen probleem.
Voor een remote gebruiker met beperkte internetverbinding kan dat heel anders zijn.
Daarom moet u kijken naar:
downloadgrootte
installatietijd
bandbreedte
failuregevoeligheid
Misschien hoeft die applicatie helemaal niet blocking te zijn.
Test via thuisinternet
Een Autopilot-provisioning die alleen via het bedrijfsnetwerk is getest, is niet representatief wanneer medewerkers thuis starten.
Test minimaal:
kantoor
thuisinternet
mobiele hotspot
tragere verbinding
Hiermee ontdekt u welke apps het kritieke pad onnodig zwaar maken.
Meet elke blocking app
Maak een eenvoudige meettabel:
| Applicatie | Gem. installatie | Failure rate | Blocking nodig? |
|---|---|---|---|
| Microsoft 365 Apps | 10 min | 1% | Ja/mogelijk |
| Security Agent | 3 min | 0,5% | Ja |
| VPN Client | 2 min | 0,5% | Alleen indien nodig |
| PDF Tool | 1 min | 0,2% | Nee |
| ERP Client | 8 min | 4% | Herbeoordelen |
| Visio | 7 min | 1% | Nee |
Hiermee wordt de ESP-configuratie datagedreven.
Stel een provisioningtijddoel
Bepaal vooraf wat acceptabel is.
Bijvoorbeeld:
Een standaard corporate laptop moet onder normale netwerkcondities binnen circa 30–45 minuten voldoende productief zijn.
Dat is slechts een voorbeeld.
Uw eigen doel kan anders zijn.
Maar zonder doel weet u niet of 90 minuten provisioning problematisch is.
Productief is belangrijker dan volledig
Er is een belangrijk onderscheid:
Provisioned
versus:
Productive
versus:
Fully configured
Een gebruiker kan misschien na 25 minuten productief zijn.
De laatste optionele apps kunnen daarna nog 30 minuten installeren.
Dat kan een betere ervaring zijn dan 55 minuten naar een progress screen kijken.
Device-targeted versus user-targeted apps
Maak voor iedere blocking app duidelijk of deze:
device-targeted
of:
user-targeted
is.
Dit beïnvloedt waar in de provisioningketen de app wordt verwerkt.
Een eenvoudige matrix:
| App | Target | Blocking |
|---|---|---|
| Security Agent | Device | Ja |
| Microsoft 365 Apps | Device/User volgens ontwerp | Mogelijk |
| Finance App | User | Alleen indien noodzakelijk |
| VPN | Device/User | Scenarioafhankelijk |
| Company Portal | Volgens ontwerp | Relevant |
| Visio | User | Nee |
Begrijp targeting voordat u troubleshooting start.
Vermijd dubbele appassignments
Een app kan per ongeluk via meerdere groepen worden toegewezen.
Bijvoorbeeld:
Required voor All Devices
én:
Required voor Finance Users
Dat kan geen probleem veroorzaken wanneer intent identiek is, maar het maakt het assignmentmodel onnodig moeilijker te begrijpen.
Houd iedere appassignment zo eenvoudig mogelijk.
Application supersedence en ESP
Wanneer u application supersedence gebruikt, test wat dit betekent voor nieuwe devices.
Een nieuwe laptop moet idealiter direct de juiste actuele versie krijgen.
Voorkom dat provisioning eerst:
oude versie installeert
↓
nieuwe versie downloadt
↓
oude versie verwijdert/upgradet
Dat maakt het kritieke pad onnodig lang.
Updates tijdens provisioning
Applicaties kunnen direct na installatie zelf updates downloaden.
Bijvoorbeeld browsers of securitytools.
Dat kan leiden tot extra netwerkbelasting.
Test daarom niet alleen de oorspronkelijke package-installatie.
Test de eerste complete runtime na installatie.
Company Portal hoeft niet alles automatisch te installeren
Company Portal maakt selfservice mogelijk.
Daarmee kunt u veel optionele applicaties uit het blocking pad verwijderen.
Bijvoorbeeld:
Visio
Project
developer tools
specialistische utilities
afdelingssoftware
Wanneer een gebruiker de software later zelf kan installeren, hoeft Autopilot daar niet op te wachten.
ESP en Configuration Profiles
Niet alleen apps beïnvloeden provisioning.
Ook configuration policies kunnen relevant zijn.
Bijvoorbeeld:
- device restrictions;
- certificates;
- Wi-Fi;
- VPN;
- security;
- identity configuration.
Controleer of onnodig complexe of conflicterende policies tijdens provisioning worden toegepast.
Een policy conflict kan een signaal zijn dat de architecturele basis moet worden opgeschoond.
Policies die elkaar overlappen
Stel dat dezelfde securitysetting wordt geconfigureerd via:
Security Baseline
Endpoint Security
Settings Catalog
Dat kan conflicts veroorzaken.
Een Autopilottest kan hierdoor een bestaand architectural probleem blootleggen.
Los de overlap op.
Probeer ESP niet te repareren met nóg een extra policy.
ESP en certificaten
Wanneer provisioning afhankelijk is van certificaten, kan extra complexiteit ontstaan.
Bijvoorbeeld voor:
- Wi-Fi;
- VPN;
- authentication;
- bedrijfsapplicaties.
Test de volledige certificate chain:
certificate delivery
↓
trust
↓
authentication
↓
resource access
Een certificaatprobleem kan zich presenteren als netwerk- of applicatieprobleem.
ESP en netwerkconfiguratie
Als een device tijdens provisioning extra netwerkconfiguratie nodig heeft, moet die vroeg genoeg beschikbaar zijn.
Maar vermijd afhankelijkheden die alleen binnen het bedrijfsnetwerk werken als remote provisioning onderdeel is van uw strategie.
Autopilot moet passen bij het gewenste werkmodel.
ESP en Windows Hello for Business
Windows Hello-registratie kan onderdeel zijn van de eerste gebruikerservaring.
Test:
- timing;
- MFA;
- gebruikersprompts;
- recovery;
- bestaande gebruiker versus nieuwe gebruiker.
De gebruiker moet weten welke stappen normaal zijn.
Wat gebeurt er wanneer een blocking app faalt?
Maak vooraf een failure strategy.
Mogelijke stappen:
ESP toont failure
↓
Gebruiker ziet instructie
↓
Retry indien zinvol
↓
Servicedesk analyse
↓
Root cause
↓
Reset / remediation / nieuwe provisioning
De gebruiker moet niet zelf gaan experimenteren met technische oplossingen.
Geef de gebruiker duidelijke foutinstructies
Een goede instructie kan zijn:
Maak een foto van de foutcode, noteer op welk scherm de installatie stopt en neem contact op met de servicedesk.
Dat is beter dan:
Probeer de laptop nog een paar keer opnieuw op te starten.
Random retries kunnen troubleshooting juist moeilijker maken.
Maak een ESP troubleshooting-runbook
Neem minimaal op:
| Symptoom | Eerste controle |
|---|---|
| Device Preparation faalt | Registration / identity / enrollment |
| Device Setup blijft hangen | Device apps/policies |
| Account Setup blijft hangen | User policies/apps |
| App X failed | Detection/install/logs |
| Time-out | Welke component is nog actief? |
| Device niet verder | ESP configuration |
| Desktop bereikt maar apps ontbreken | Assignment/post-provisioning |
Dit verkort supporttijd aanzienlijk.
Gebruik logs en statusinformatie gericht
Een foutmelding als:
Something went wrong.
is alleen het begin.
Troubleshooting moet vervolgens kijken naar:
welke fase
welke app
welke policy
welke foutcode
welke context
welk tijdstip
welke dependency
Probeer niet direct allerlei policies te verwijderen.
Bepaal eerst de failing component.
Bouw een bekende goede testbaseline
Gebruik één standaard testscenario waarvan u weet dat het werkt.
Bijvoorbeeld:
Microsoft Entra joined
standaard corporate profile
standaard hardwaremodel
testuser
normaal thuisnetwerk
beperkte blocking apps
Wanneer dit scenario faalt na een change, heeft u een duidelijke vergelijking met de vorige werkende toestand.
Test ESP na iedere kritieke appwijziging
Een applicatiepackage kan veranderen terwijl ESP-configuratie hetzelfde blijft.
Bijvoorbeeld:
- nieuwe Microsoft 365 installer;
- nieuwe VPN-client;
- nieuwe security agent;
- nieuwe ERP-versie.
Als die app blocking is, verandert daarmee feitelijk de Autopilot-provisioning.
Voer daarom opnieuw een end-to-end test uit.
Gebruik deployment rings
Maak changes niet direct breed actief.
Bijvoorbeeld:
Ring 0 — Endpoint Test
↓
Ring 1 — IT
↓
Ring 2 — Business Pilot
↓
Ring 3 — Early Production
↓
Ring 4 — Broad Production
Test een nieuwe blocking app eerst in een kleine populatie.
Verander één blocking component tegelijk
Wanneer u tegelijkertijd:
- ESP-configuratie wijzigt;
- drie apps vervangt;
- securitybaseline aanpast;
- Conditional Access uitbreidt;
en provisioning faalt, wordt troubleshooting lastig.
Gebruik kleine changes.
Bijvoorbeeld:
Deze release verandert alleen de VPN-client.
Dan weet u veel beter waar u moet kijken.
Maak ESP onderdeel van change management
Behandel ESP als bedrijfskritieke provisioningconfiguratie.
Een wijziging moet bijvoorbeeld bevatten:
Change description
Reason
Impact
Blocking components
Pilot
Rollback
Owner
Approval
Dat klinkt formeel, maar voorkomt onverwachte problemen bij honderden toekomstige devices.
Rollback van een problematische blocking app
Stel dat een nieuwe VPN-versie provisioning laat falen.
Dan moet u vooraf weten:
oude package beschikbaar?
assignment terug te zetten?
detection aangepast?
nieuwe devices veilig te provisionen zonder VPN?
Een rollback hoeft niet altijd technisch één klik te zijn.
Daarom moet het plan vooraf bestaan.
Monitor Autopilot-failure rates
Maak ESP operationeel meetbaar.
Bijvoorbeeld:
| KPI | Doel |
|---|---|
| Provisioning success | ≥ afgesproken target |
| ESP failure rate | Zo laag mogelijk |
| Gemiddelde ESP-duur | Binnen norm |
| Blocking app failure | Per app monitoren |
| Handmatige interventions | Trend omlaag |
| Retry rate | Monitoren |
| Supporttickets per 100 deployments | Monitoren |
Dit helpt om structurele problemen te vinden.
Meet per hardwaremodel
Wanneer één laptopmodel structureel langere provisioning heeft, kan dat wijzen op:
- drivers;
- firmware;
- netwerkadapter;
- OEM-software;
- hardwareverschillen.
Analyseer daarom niet alleen totaalpercentages.
Segmentatie kan verborgen oorzaken zichtbaar maken.
Meet per netwerkcontext
Een provisioningduur van:
25 minuten op kantoor
maar:
70 minuten thuis
kan wijzen op:
- grote downloads;
- bandwidth;
- proxy/CDN;
- VPN-dependency;
- externe service.
Dat is zeer relevante informatie voor optimalisatie.
Meet per applicatie
Voor blocking apps wilt u weten:
success rate
install duration
failure codes
retry behavior
version
Hierdoor wordt zichtbaar welke app het meeste risico introduceert.
Wanneer moet een app uit ESP?
Overweeg verwijderen uit het kritieke pad wanneer de app:
- niet noodzakelijk is voor eerste productiviteit;
- regelmatig faalt;
- zeer groot is;
- afhankelijk is van complexe external services;
- veel restarts veroorzaakt;
- slechts voor een kleine gebruikersgroep nodig is;
- goed via Company Portal kan worden aangeboden.
Het verwijderen van één problematische app kan Autopilot aanzienlijk betrouwbaarder maken.
Wanneer moet een app juist blocking blijven?
Wanneer zonder die app:
security onvoldoende is;
de gebruiker zijn primaire taak niet kan uitvoeren;
de netwerk-/identityketen niet functioneert;
de business expliciet vereist dat deze vooraf aanwezig is.
Maar documenteer waarom.
Voorbeeld: kleine organisatie
Een organisatie met 50 gebruikers kan bijvoorbeeld kiezen voor:
Blocking
- security;
- Microsoft 365 Apps;
- één bedrijfskritieke app.
Post-provisioning
- PDF-tool;
- Visio;
- printersoftware;
- optionele utilities.
Dit houdt de provisioningketen compact.
Voorbeeld: 500 gebruikers
Een organisatie met 500 gebruikers kan bijvoorbeeld werken met:
Device blocking
- security agent;
- kernsecurityconfiguratie;
- Microsoft 365 Apps.
User-specific
- Finance ERP;
- CRM;
- HR-software.
Available
- Visio;
- Project;
- developer tools;
- utilities.
Hierdoor hoeft niet iedere laptop op elke businessapp te wachten.
Voorbeeld: developers
Developers kunnen tientallen tools nodig hebben.
Maar dat betekent niet dat Autopilot op al die tools moet wachten.
Maak bijvoorbeeld:
blocking
security + basisproductiviteit.
Daarna:
developer group
→ development tools required/available.
Zo kan de developer de desktop bereiken terwijl aanvullende tools worden geïnstalleerd.
Voorbeeld: remote sales
Een salesmedewerker heeft misschien direct nodig:
Microsoft 365
CRM
security
maar niet:
lokale printers
reporting tools
specialistische backoffice software
Ontwerp vanuit de eerste productieve werkdag.
Wat doet u met Office add-ins?
Add-ins kunnen bedrijfskritiek zijn.
Maar zij kunnen ook extra installercomplexiteit veroorzaken.
Test daarom:
Office installatie
↓
Add-in installatie
↓
Detection
↓
eerste Office start
↓
functionaliteit
Wanneer de add-in alleen voor een specifieke afdeling nodig is, houd deze uit de algemene blocking set.
Maak een ESP-appregister
Documenteer alle blocking apps.
Bijvoorbeeld:
| App | Owner | Target | Blocking reden | Gem. duur | Failure rate |
|---|---|---|---|---|---|
| Security Agent | Security | Devices | Vereiste bescherming | 3 min | 0,5% |
| M365 Apps | Workplace | Corporate | Kernproductiviteit | 10 min | 1% |
| VPN | Network | Remote group | Legacy access | 2 min | 0,8% |
| ERP | Finance | Finance | Kritieke businessapp | 7 min | 2% |
Hiermee kunt u periodiek beoordelen of de blocking status nog terecht is.
Review blocking apps periodiek
Een app die twee jaar geleden noodzakelijk was, kan inmiddels:
- vervangen zijn;
- SaaS geworden zijn;
- niet meer gebruikt worden;
- beschikbaar zijn via een modernere oplossing.
Review daarom bijvoorbeeld per kwartaal of halfjaar.
Vraag:
Moet Autopilot hier nog steeds op wachten?
Vaak is het antwoord na verloop van tijd nee.
Veelgemaakte ESP-fouten
Alles blocking maken
Provisioning wordt kwetsbaar en langzaam.
Geen Minimum Productive Device definiëren
Iedere afdeling voegt apps toe aan het kritieke pad.
Detection rules onvoldoende testen
Werkende installaties worden als failure gezien.
Dependency chains negeren
Eén blocking app blijkt vijf andere packages nodig te hebben.
Alleen snelle netwerken testen
Remote users ervaren veel langere doorlooptijd.
Geen restarttest uitvoeren
Provisioning wordt onverwacht onderbroken.
Apps via verkeerde context targeten
User/device behavior wordt verkeerd begrepen.
Geen meetgegevens verzamelen
Optimalisatie gebeurt op gevoel.
Iedere fout oplossen met retry
Root cause blijft bestaan.
Geen runbook maken
Servicedesk kan problemen niet consistent afhandelen.
ESP production-readiness checklist
Controleer vóór brede rollout:
✓ Minimum Productive Device is gedefinieerd;
✓ iedere blocking app heeft een concrete reden;
✓ aantal blocking apps is zo klein mogelijk;
✓ device- en user-targeting zijn bekend;
✓ Win32 install commands zijn getest;
✓ detection rules zijn getest;
✓ requirements zijn getest;
✓ dependencies zijn gedocumenteerd;
✓ restart behavior is getest;
✓ grote downloads zijn beoordeeld;
✓ thuisinternet is getest;
✓ trage verbinding is getest;
✓ security is vroeg genoeg actief;
✓ Configuration Profiles zijn op conflicts gecontroleerd;
✓ certificaatdependencies zijn getest;
✓ VPN-dependencies zijn getest;
✓ nieuwe users zijn getest;
✓ bestaande users zijn getest;
✓ meerdere hardwaremodellen zijn getest;
✓ failure scenario is getest;
✓ servicedesk-runbook bestaat;
✓ gebruikersinstructies zijn beschikbaar;
✓ deployment rings worden gebruikt;
✓ rollback bestaat;
✓ KPI’s worden gemonitord;
✓ blocking app register is gedocumenteerd;
✓ periodieke review is gepland.
Een praktisch optimalisatieproces
Wanneer uw ESP momenteel traag of instabiel is, gebruik dan:
1. Meet huidige provisioningtijd
↓
2. Identificeer alle blocking components
↓
3. Meet duur per component
↓
4. Analyseer failures
↓
5. Verwijder niet-kritieke apps uit het pad
↓
6. Repareer detection en dependencies
↓
7. Test via verschillende netwerken
↓
8. Pilot
↓
9. Meet opnieuw
↓
10. Gefaseerd naar productie
Hiermee optimaliseert u op basis van data.
Het belangrijkste ESP-principe
De Enrollment Status Page moet niet bewijzen dat IT alles vóór de eerste desktop kan installeren.
De ESP moet bewijzen dat het apparaat:
voldoende beheerd
voldoende beveiligd
voldoende geconfigureerd
voldoende productief
is om de gebruiker verantwoord te laten beginnen.
Daarom is de belangrijkste ontwerpregel:
Maak alleen blocking wat écht blocking moet zijn.
Iedere component die u uit het kritieke pad kunt verwijderen zonder security of eerste productiviteit te verliezen, maakt Windows Autopilot potentieel sneller en betrouwbaarder.
Van ESP naar Autopilot-app troubleshooting
Wanneer de ESP-architectuur staat, blijft één van de meest voorkomende praktische problemen over:
Waarom installeert een Win32-app niet tijdens Windows Autopilot?
Daarbij moeten we dieper ingaan op:
- detection rules;
- requirement rules;
- install context;
- return codes;
- dependencies;
- supersedence;
- IME;
- logs;
- retrygedrag.
Dat is daarom de logische volgende stap.
Verder lezen
Lees ook:
Hulp nodig met een vastlopende Enrollment Status Page?
Blijft Windows Autopilot hangen tijdens ESP?
Faalt één van uw required apps?
Duurt provisioning te lang?
Of wilt u bepalen welke applicaties werkelijk blocking moeten zijn?
Stel uw Intune-vraag — uw eerste vraag is gratis.
Beschrijf kort waar ESP stopt, welke apps blocking zijn en welke foutmelding u ziet. Wij geven u een eerste praktisch advies over mogelijke oorzaken en vervolgstappen.