Een Windows Autopilot Deployment Profile bepaalt een belangrijk deel van de eerste ervaring die een gebruiker krijgt wanneer een nieuw Windows-apparaat wordt ingericht.
Het profiel bepaalt niet welke complete werkplek de gebruiker uiteindelijk krijgt. Applicaties, security, Configuration Profiles, compliance en andere instellingen worden elders binnen Microsoft Intune beheerd.
Het Deployment Profile bepaalt vooral hoe het apparaat door de Windows Autopilot-provisioning begint te bewegen.
Daarom is het belangrijk om Deployment Profiles eenvoudig en doelgericht te ontwerpen.
Voor een standaard zakelijke Windows-laptop kan de keten bijvoorbeeld zijn:
Nieuw Windows-apparaat
↓
Autopilot herkent hardware
↓
Deployment Profile wordt toegewezen
↓
Out-of-Box Experience (OOBE)
↓
Gebruiker authenticeert
↓
Microsoft Entra Join
↓
Intune Enrollment
↓
Enrollment Status Page
↓
Policies + Security + Apps
↓
Productieve werkplek
Een verkeerde profieltoewijzing aan het begin van deze keten kan de rest van het provisioningproces beïnvloeden.
Het Deployment Profile verdient daarom meer aandacht dan alleen het aanvinken van enkele opties.
Wat is een Windows Autopilot Deployment Profile?
Een Deployment Profile bevat instellingen die bepalen hoe een Windows Autopilot-device wordt ingericht tijdens de Out-of-Box Experience.
Afhankelijk van het gebruikte Autopilot-scenario en de ondersteunde mogelijkheden bepaalt u hierin relevante aspecten van de provisioningervaring.
Denk conceptueel aan:
| Onderdeel | Ontwerpvraag |
|---|---|
| Deployment mode | Wie start en doorloopt provisioning? |
| Join-model | Hoe wordt het apparaat aan de organisatie gekoppeld? |
| User experience | Welke OOBE-stappen zijn relevant? |
| User account | Welke rechten krijgt de eindgebruiker? |
| Device naming | Hoe wordt het apparaat herkenbaar gemaakt? |
| Assignment | Welke apparaten krijgen dit profiel? |
Het profiel moet aansluiten op uw doelarchitectuur.
Niet andersom.
Begin niet met de instellingen
Voordat u het Deployment Profile configureert, moet u een aantal architectuurvragen beantwoorden.
Bijvoorbeeld:
Wie ontvangt het apparaat?
Is het apparaat persoonlijk toegewezen of shared?
Moet de gebruiker zelf provisioning uitvoeren?
Wordt pre-provisioning gebruikt?
Wordt het apparaat Microsoft Entra joined?
Bestaan er nog Active Directory-afhankelijkheden?
Moet de gebruiker local administrator worden?
Welke configuratie moet vóór de eerste desktop aanwezig zijn?
Hoe wordt het device geclassificeerd?
Hoe wordt het profiel toegewezen?
Pas daarna configureert u het profiel.
User-driven deployment als standaardscenario
Voor veel organisaties met individueel toegewezen zakelijke laptops is user-driven deployment een logisch uitgangspunt.
De gebruiker ontvangt een nieuw apparaat, maakt verbinding met internet en meldt zich tijdens de provisioning aan met de zakelijke identity.
Conceptueel:
Laptop aanzetten
↓
Internetverbinding
↓
Autopilot-service herkent apparaat
↓
Organisatieprofiel verschijnt
↓
Gebruiker meldt zich aan
↓
Microsoft Entra Join
↓
Intune Enrollment
↓
ESP
↓
Desktop
Het voordeel is dat IT het apparaat niet noodzakelijk volledig handmatig hoeft voor te bereiden.
Wanneer past user-driven deployment goed?
User-driven deployment past vooral bij situaties waarin:
- één medewerker de primaire gebruiker van het apparaat is;
- de gebruiker een zakelijke identity heeft;
- internettoegang tijdens provisioning beschikbaar is;
- cloudmanagement onderdeel is van de architectuur;
- applicaties en configuration centraal worden geleverd;
- de organisatie provisioning wil standaardiseren.
Een typische toepassing is de standaard Windows 11-laptop voor een kenniswerker.
Wanneer is user-driven niet automatisch de beste keuze?
Niet ieder Windows-device heeft een traditionele eindgebruiker.
Denk aan:
kiosks;
shared devices;
special-purpose endpoints;
apparaten die centraal door IT worden voorbereid;
bepaalde frontline-scenario’s.
Daarvoor kunnen andere deploymentmodellen of aanvullende configuraties nodig zijn.
Gebruik dus niet één Deployment Profile alleen omdat dat technisch eenvoudig is.
Gebruik één profiel wanneer het businessscenario hetzelfde is.
Microsoft Entra Join als cloud-native uitgangspunt
Een belangrijke keuze binnen de architectuur is het join-model.
Voor moderne cloud-managed Windows-werkplekken kan een architectuur gebaseerd zijn op:
Microsoft Entra Join
Microsoft Intune
Windows Autopilot
Het apparaat hoeft dan niet eerst traditioneel aan een on-premises Active Directory-domein te worden gekoppeld om centraal beheerd te worden.
Dit kan het provisioningmodel aanzienlijk vereenvoudigen.
Waarom Microsoft Entra Join aantrekkelijk is
Een cloud-native devicearchitectuur vermindert potentiële afhankelijkheden van:
- domain controllers;
- traditionele domain join;
- lokale netwerkconnectiviteit tijdens provisioning;
- Group Policy;
- bepaalde legacy provisioningprocessen;
- traditionele imaging.
Het betekent echter niet dat alle on-premises resources automatisch verdwijnen.
Een Microsoft Entra joined device kan nog steeds toegang nodig hebben tot bestaande bedrijfsresources.
Daarom moet de applicatie- en infrastructuurinventaris onderdeel zijn van de migratie.
Kies Hybrid Entra Join alleen met een concrete reden
Sommige organisaties hebben nog sterke Active Directory-afhankelijkheden.
Een hybride model kan dan tijdelijk of structureel noodzakelijk zijn.
Maar vermijd:
We hebben Active Directory, dus nieuwe laptops moeten Hybrid Entra joined zijn.
Dat is geen architectuurrequirement.
Onderzoek eerst:
Welke applicatie vereist domain join?
Welke authenticatieflow vereist het?
Welke GPO kan nog niet worden vervangen?
Welke netwerkresource veroorzaakt de afhankelijkheid?
Is de afhankelijkheid technisch of alleen historisch?
Pas wanneer u die antwoorden heeft, kunt u een bewuste keuze maken.
Cloud-native first
Voor nieuwe implementaties is een bruikbaar architectuurprincipe:
Cloud-native waar mogelijk, hybrid waar aantoonbaar noodzakelijk.
Dat betekent niet dat hybrid verkeerd is.
Het betekent dat iedere extra dependency een reden moet hebben.
Dit maakt toekomstige vereenvoudiging veel gemakkelijker.
OOBE: de eerste gebruikerservaring
OOBE staat voor Out-of-Box Experience.
Dit is de Windows-ervaring die de gebruiker ziet wanneer een nieuw of opnieuw ingericht apparaat voor het eerst wordt gestart.
Zonder een goed ontworpen provisioningproces kan de gebruiker allerlei vragen en configuratieschermen tegenkomen.
Autopilot kan delen van deze ervaring afstemmen op de organisatie.
Het doel moet niet zijn:
Verberg zoveel mogelijk schermen.
Het doel is:
Laat alleen interactie over die de gebruiker daadwerkelijk nodig heeft.
Maak de OOBE voorspelbaar
Een nieuwe medewerker moet geen technische keuzes hoeven maken die IT vooraf had kunnen bepalen.
Bijvoorbeeld:
Hoe moet dit device worden beheerd?
Welke organisatie-instellingen zijn nodig?
Welke securitystandaard geldt?
Dat zijn geen gebruikersbeslissingen.
Een goede provisioningflow neemt dergelijke beslissingen vooraf in het ontwerp.
Branding en herkenbaarheid
Wanneer een gebruiker een nieuwe laptop start, moet duidelijk zijn dat het apparaat onderdeel is van de zakelijke provisioningflow.
Organisatiebranding kan helpen bij herkenning en vertrouwen.
De gebruiker moet kunnen begrijpen:
Dit is inderdaad het apparaat van mijn organisatie en ik moet hier mijn zakelijke account gebruiken.
Branding is daarom niet alleen cosmetisch.
Het ondersteunt ook de onboardingervaring.
Houd gebruikersinstructies kort
De beste Autopilot-instructie is geen handleiding van twintig pagina’s.
Een medewerker zou bijvoorbeeld vooraf alleen hoeven te weten:
1. Zet de laptop aan.
2. Maak verbinding met internet.
3. Meld u aan met uw zakelijke account wanneer daarom wordt gevraagd.
4. Laat de installatie volledig afronden.
5. Start het apparaat niet onnodig opnieuw op.
6. Neem bij een foutmelding contact op met de servicedesk en vermeld de foutcode.
Wanneer de gebruiker veel meer technische stappen moet uitvoeren, is het proces mogelijk onvoldoende geautomatiseerd.
Gebruiker als Standard User of Administrator?
Een belangrijke keuze is welke lokale rechten de gebruiker na provisioning krijgt.
Voor standaard zakelijke werkplekken is het vanuit least-privilegeperspectief meestal verstandig om gebruikers niet structureel lokale administratorrechten te geven zonder duidelijke requirement.
Het uitgangspunt kan zijn:
Normale gebruiker
→ Standard User
Beheerder
→ aparte gecontroleerde beheerroute
Dit verkleint het risico dat gebruikers of malware ongecontroleerd systeemwijzigingen kunnen uitvoeren.
“De gebruiker heeft het soms nodig” is geen strategie
Wanneer gebruikers incidenteel elevated rechten nodig hebben, moet u onderzoeken waarom.
Bijvoorbeeld:
- legacy applicatie;
- development;
- driverinstallatie;
- specialistische software;
- troubleshooting.
Daarvoor kan een gerichte oplossing nodig zijn.
De eenvoudige oplossing:
Maak iedereen local admin.
verplaatst het probleem naar security.
Device naming: houd het eenvoudig
Organisaties besteden soms verrassend veel tijd aan computernaamconventies.
Bijvoorbeeld:
NL-AMS-FIN-LT-DELL-USER123-001
Daarmee probeert de computernaam allerlei informatie te bevatten:
- land;
- locatie;
- afdeling;
- type;
- fabrikant;
- gebruiker;
- volgnummer.
Maar veel van deze gegevens veranderen of zijn elders beschikbaar.
Een device kan bijvoorbeeld van gebruiker of afdeling veranderen.
Dan klopt de naam niet meer.
Wat moet een computernaam eigenlijk doen?
Een computernaam moet vooral:
technisch geldig zijn;
voldoende uniek zijn;
operationeel herkenbaar zijn wanneer nodig;
eenvoudig te genereren zijn;
niet onnodig vaak veranderen.
Asset management-informatie hoort in asset- en managementsystemen.
Niet noodzakelijk allemaal in de hostname.
Voorbeeld van eenvoudige device naming
Een organisatie kan bijvoorbeeld kiezen voor een compact model:
WIN-%SERIAL%
of een andere technisch ondersteunde conventie die aansluit op het eigen beheerproces.
Het exacte model is minder belangrijk dan het principe:
Gebruik de computernaam niet als volledige assetdatabase.
Vermijd persoonsgegevens in device names
Gebruik bij voorkeur geen onnodige persoonsgegevens in computernamen.
Bijvoorbeeld:
BEN-KEMP-LAPTOP
kan operationeel eenvoudig lijken, maar koppelt de device identity direct aan een persoon.
Bovendien ontstaat een probleem wanneer de laptop wordt hergebruikt.
Een neutraler device-identificatiemodel is doorgaans beter beheersbaar.
Device naming en bestaande systemen
Controleer vóór invoering of andere systemen afhankelijk zijn van computernaamgeving.
Bijvoorbeeld:
- monitoring;
- inventory;
- software licensing;
- scripts;
- netwerktoegang;
- certificaten;
- remote support;
- assetprocessen.
Een cloud-native namingstrategie moet rekening houden met echte dependencies.
Niet met aannames.
Assignment bepaalt welk profiel een device krijgt
Een Deployment Profile heeft pas effect wanneer het aan de juiste apparaten wordt toegewezen.
Daarom is assignmentarchitectuur essentieel.
Conceptueel:
Autopilot Device
↓
Device-eigenschap / Group Tag
↓
Dynamische groep
↓
Deployment Profile
↓
Provisioning
Wanneer de classificatie verkeerd is, kan het verkeerde profiel worden toegepast.
Voorbeeld van eenvoudige assignmentarchitectuur
Stel dat vrijwel alle laptops hetzelfde user-driven provisioningmodel gebruiken.
Dan kan de architectuur bijvoorbeeld zijn:
Group Tag: CORP
↓
Dynamic Group: GRP-AP-CORP-DEVICES
↓
Deployment Profile: WIN-AP-CORP-USERDRIVEN
Dat is eenvoudig te begrijpen.
Een nieuwe beheerder kan snel achterhalen waarom een apparaat het profiel krijgt.
Wanneer een Group Tag nuttig is
Group Tags zijn vooral waardevol wanneer u apparaten vroeg in de lifecycle wilt classificeren.
Bijvoorbeeld:
| Group Tag | Scenario |
|---|---|
| CORP | Standard corporate device |
| SHARED | Shared workstation |
| KIOSK | Kiosk |
| PREPROV | Specifieke pre-provisioningflow |
Dit zijn verschillende device-/provisioningscenario’s.
Dat is een sterke reden voor classificatie.
Wanneer een Group Tag minder geschikt is
Stel dat u tags maakt voor:
FINANCE
HR
SALES
MARKETING
alleen omdat die gebruikers verschillende applicaties nodig hebben.
Dan koppelt u provisioningarchitectuur aan businessapplicaties.
Dat is vaak onnodig.
Dezelfde laptop kan hetzelfde Deployment Profile gebruiken terwijl applicaties via usergroepen worden toegewezen.
Scheid provisioning van persona
Een zeer nuttig ontwerpprincipe is:
Device provisioning
bepaalt hoe het apparaat technisch wordt ingericht.
User persona
bepaalt welke zakelijke resources en applicaties de gebruiker nodig heeft.
Bijvoorbeeld:
CORP laptop
↓
standaard Autopilot
maar:
Finance user
→ Finance apps
Sales user
→ CRM apps
Developer
→ development tools
Zo voorkomt u tientallen Deployment Profiles.
Gebruik zo weinig mogelijk Deployment Profiles
Voor een kleine of middelgrote organisatie kan één standaardprofiel vaak voldoende zijn.
Bijvoorbeeld:
WIN-AP-CORP-USERDRIVEN
Een grotere organisatie kan bijvoorbeeld nodig hebben:
WIN-AP-CORP-USERDRIVEN
WIN-AP-CORP-PREPROV
WIN-AP-SHARED
WIN-AP-KIOSK
Maar iedere extra variant moet een duidelijke use case hebben.
Maak een Deployment Profile-register
Documenteer ieder profiel.
Bijvoorbeeld:
| Veld | Waarde |
|---|---|
| Profile | WIN-AP-CORP-USERDRIVEN |
| Doel | Standard corporate laptops |
| Deployment | User-driven |
| Join | Microsoft Entra Join |
| User type | Standard User |
| Group Tag | CORP |
| Assignment | GRP-AP-CORP-DEVICES |
| Owner | Endpoint Team |
| Status | Production |
Hierdoor wordt het ontwerp overdraagbaar.
Test profieltoewijzing vóór provisioning
Controleer voordat een pilotgebruiker een apparaat ontvangt:
Is het apparaat correct geregistreerd?
Heeft het de juiste classificatie?
Komt het in de juiste groep?
Is het juiste Deployment Profile toegewezen?
Is de gewenste provisioningstatus beschikbaar?
Pas daarna start u de end-to-end test.
Dit voorkomt tijdverlies tijdens OOBE.
Dynamische groepen hebben verwerkingstijd
Wanneer assignment afhankelijk is van dynamische groepsmembership, moet u rekening houden met verwerking en evaluatie.
Ontwerp daarom geen logistiek proces waarin een device:
nu wordt geregistreerd
en:
30 seconden later gegarandeerd klaar moet zijn voor verzending.
De provisioningketen heeft operationele verwerking nodig.
Bouw controles in voordat een device naar de eindgebruiker gaat.
Maak een “ready for shipment”-controle
Voor organisaties die laptops direct naar medewerkers sturen kan een eenvoudige logistieke status zeer waardevol zijn.
Bijvoorbeeld:
Device besteld
↓
Autopilot registration bevestigd
↓
Group Tag bevestigd
↓
Deployment Profile bevestigd
↓
Asset geregistreerd
↓
Ready for shipment
↓
Verzonden naar gebruiker
Zo wordt Autopilot onderdeel van het supply-chainproces.
Nieuwe medewerker: voorbeeldflow
Stel dat een nieuwe medewerker maandag begint.
Een goed ontworpen proces kan zijn:
T-10 dagen
HR bevestigt onboarding.
↓
T-9 dagen
IT-proces wordt gestart.
↓
T-8 dagen
Laptop besteld.
↓
T-5 dagen
Leverancier registreert apparaat voor Autopilot.
↓
T-4 dagen
IT controleert registratie en profiel.
↓
T-3 dagen
Device wordt verzonden.
↓
T-1 dag
Gebruiker ontvangt laptop.
↓
Dag 1
Gebruiker start apparaat en doorloopt Autopilot.
↓
Daarna
Policies, security en apps worden toegepast.
Het precieze tijdschema verschilt per organisatie, maar de belangrijke les is:
Autopilot begint vóórdat de gebruiker de laptop aanzet.
Replacement device: voorbeeldflow
Bij vervanging kan het proces zijn:
Defect device
↓
Replacement order
↓
Nieuw device correct geregistreerd
↓
Standaard corporate profiel
↓
Verzending
↓
Gebruiker meldt zich aan
↓
Intune bouwt werkplek opnieuw op
↓
Bedrijfsdata synchroniseert vanuit goedgekeurde cloudservices
Hier wordt zichtbaar waarom standaardisatie zoveel waarde heeft.
User data moet niet afhankelijk zijn van de oude laptop
Een modern provisioningmodel werkt het beste wanneer belangrijke gebruikersdata niet uitsluitend lokaal op één apparaat staat.
Denk aan een goed ontworpen combinatie van bijvoorbeeld:
- OneDrive;
- SharePoint;
- cloudapplicaties;
- enterprise storage.
Dan wordt een replacement device veel eenvoudiger.
Het device wordt vervangbaar.
De identity en data blijven centraal beschikbaar volgens het organisatiemodel.
Autopilot en Enrollment Status Page
Na het Deployment Profile komt de Enrollment Status Page als volgende kritieke fase.
Het Deployment Profile zegt conceptueel:
Zo start dit device.
ESP zegt vervolgens:
Welke noodzakelijke provisioning moet worden afgerond voordat de gebruiker verder kan?
Daarom moeten deze twee componenten samen worden getest.
Maak niet alles blocking
Het feit dat een applicatie belangrijk is, betekent niet automatisch dat deze tijdens ESP blocking moet zijn.
Vraag voor iedere applicatie:
Kan de gebruiker veilig en zinvol beginnen zonder deze app?
Als het antwoord ja is, kan installatie mogelijk na de eerste desktop plaatsvinden.
Dit verkort het kritieke provisioningpad.
Voorbeeld Minimum Productive Device
Voor een standaard medewerker kan een minimale werkplek bijvoorbeeld bestaan uit:
| Component | Vóór eerste productieve sessie? |
|---|---|
| Intune enrollment | Ja |
| Securitybaseline | Ja |
| Microsoft 365 Apps | Vaak |
| OneDrive-configuratie | Relevant |
| VPN | Alleen indien direct nodig |
| Kern-LOB-app | Indien bedrijfskritiek |
| Visio | Nee |
| Project | Nee |
| Optionele utilities | Nee |
| Afdelingsspecifieke tools | Alleen indien direct noodzakelijk |
Het doel is niet zo weinig mogelijk installeren.
Het doel is het kritieke pad bewust bepalen.
Account Setup en gebruikerspolicies
Niet alle configuratie is device-based.
Na de devicefase kunnen user-targeted policies en applicaties onderdeel worden van de provisioningervaring.
Daarom moet u vooraf weten:
Welke settings zijn user-targeted?
Welke apps zijn user-targeted?
Welke dependencies bestaan?
Welke moeten werkelijk vóór productiviteit gereed zijn?
Dit wordt belangrijk wanneer we de Enrollment Status Page verder uitwerken.
Windows Hello tijdens de eerste ervaring
Wanneer Windows Hello for Business onderdeel is van uw identitystrategie, kan de gebruiker tijdens of rond de eerste setup aanvullende registratie ervaren.
Communiceer dit vooraf.
Een gebruiker die verwacht:
Ik hoef alleen mijn wachtwoord in te voeren.
maar vervolgens verschillende identity- en securitystappen ziet, kan denken dat provisioning is mislukt.
Gebruikerscommunicatie is onderdeel van technische kwaliteit.
Test met een nieuwe gebruiker
Endpointteams testen Autopilot vaak met hun eigen bestaande beheeraccount.
Dat is niet representatief.
Test ook met:
een nieuwe standaardgebruiker;
zonder bestaande devicehistorie;
met normale licenties;
met normale groepsmembership;
zonder administratorrechten.
Dat benadert een echte onboarding veel beter.
Test met een bestaande gebruiker
Daarna test u ook:
replacement device
tweede device
bestaande Microsoft 365-gebruiker
gebruiker met bestaande Windows Hello-configuratie
gebruiker met bestaande applicatieassignments
Nieuwe en bestaande medewerkers kunnen verschillende provisioninggedragingen tonen.
Test foutscenario’s
Een Deployment Profile-test is niet compleet wanneer alleen het ideale scenario wordt getest.
Test bijvoorbeeld:
verkeerde Group Tag
device niet geregistreerd
verkeerd profiel
geen netwerk
gebruiker zonder juiste entitlement
enrollmentprobleem
blocking app failure
Conditional Access-impact
reset en opnieuw proberen
De servicedesk moet weten hoe deze situaties eruitzien.
Maak foutmeldingen onderdeel van het runbook
Documenteer niet alleen oplossingen.
Documenteer ook herkenning.
Bijvoorbeeld:
| Symptoom | Eerste controle |
|---|---|
| Organisatiebranding ontbreekt | Autopilot registration/profile |
| Verkeerde provisioningervaring | Deployment Profile |
| Enrollment faalt | Enrollment/identity |
| ESP blijft hangen | Apps/policies/status |
| Gebruiker wordt admin | Profile/account configuration |
| Verkeerde computernaam | Naming/profile |
| Geen M365-toegang na setup | Compliance/Conditional Access |
Hierdoor kan support sneller naar de juiste laag navigeren.
Verander productieprofielen gecontroleerd
Een Deployment Profile kan honderden of duizenden toekomstige provisioningprocessen beïnvloeden.
Behandel wijzigingen daarom als productiechanges.
Gebruik:
Change request
↓
Technische review
↓
Testprofile/testscope
↓
Autopilot testdevice
↓
Pilot
↓
Approval
↓
Production
↓
Monitoring
Een wijziging lijkt misschien klein in de portal, maar de operationele impact kan groot zijn.
Gebruik een dedicated testdevice
Voor Autopilot is een fysiek testapparaat zeer waardevol.
Het moet herhaaldelijk kunnen worden:
reset
↓
opnieuw provisioned
↓
gevalideerd
Gebruik daarnaast waar nodig meerdere hardwaremodellen om representativiteit te krijgen.
Een Autopilot-platform zonder herhaalbare end-to-end testmogelijkheid is moeilijk veilig te wijzigen.
Versiebeheer voor het ontwerp
Intune geeft u niet automatisch hetzelfde configuratiebeheer als een traditionele software repository.
Documenteer daarom belangrijke wijzigingen.
Bijvoorbeeld:
| Versie | Wijziging | Datum | Reden |
|---|---|---|---|
| 1.0 | Initial profile | Datum | Implementatie |
| 1.1 | OOBE aangepast | Datum | UX verbetering |
| 1.2 | Naming aangepast | Datum | Asset requirement |
| 1.3 | Assignment aangepast | Datum | Nieuwe devicecategorie |
Dit helpt bij troubleshooting en audits.
Voorbeeld: 50 gebruikers
Een kleine organisatie kan een zeer eenvoudige architectuur gebruiken.
1 Deployment Profile
WIN-AP-CORP-USERDRIVEN
1 primaire Autopilot devicegroep
GRP-AP-CORP-DEVICES
1 standaard Group Tag
CORP
Join
Microsoft Entra Join
User
Standard User
ESP
Alleen noodzakelijke security en kernapps.
Apps
Overige software na provisioning.
Voor 50 sterk gestandaardiseerde gebruikers kan dit voldoende zijn.
Voorbeeld: 500 gebruikers
Een organisatie met 500 medewerkers kan bijvoorbeeld hebben:
WIN-AP-CORP-USERDRIVEN
Standaard laptops.
WIN-AP-CORP-PREPROV
Alleen waar pre-provisioning operationeel waarde toevoegt.
WIN-AP-SHARED
Gedeelde apparaten.
Daaronder een beperkt aantal Group Tags:
CORP
PREPROV
SHARED
Businessapplicaties worden niet via extra Autopilot-profielen opgesplitst, maar via de relevante assignmentarchitectuur.
Zo blijft het provisioningmodel beheersbaar.
Voorbeeld: 5.000 gebruikers
Bij een grotere organisatie neemt governance toe, maar de basisprincipes veranderen niet.
U kunt te maken krijgen met:
- meerdere landen;
- meerdere hardwareleveranciers;
- verschillende devicecategorieën;
- internationale logistiek;
- meerdere IT-teams;
- privileged endpoints;
- shared devices;
- verschillende supportmodellen.
De verleiding is dan om tientallen Deployment Profiles te maken.
Doe dat alleen wanneer provisioning werkelijk verschilt.
Schaal door standaardisatie, niet door onbeperkte variatie.
Deployment Profile KPI’s
Meet bijvoorbeeld:
| KPI | Betekenis |
|---|---|
| Correct profile assignment | Krijgen devices het juiste profiel? |
| Autopilot recognition success | Worden devices correct herkend? |
| Provisioning success | Rondt provisioning succesvol af? |
| Wrong-profile incidents | Classificatiefouten |
| Manual interventions | Hoeveel IT-handelingen zijn nodig? |
| Average provisioning time | Gebruikerservaring |
| First-day support tickets | Operationele kwaliteit |
Hiermee maakt u Autopilot meetbaar.
Veelgemaakte fouten met Deployment Profiles
Te veel profielen
Iedere afdeling krijgt een eigen Deployment Profile.
User persona en provisioning vermengen
Finance-applicaties worden reden voor een Finance Autopilot-profiel.
Hybrid automatisch kiezen
Bestaande Active Directory wordt zonder dependencyanalyse leidend.
Gebruikers standaard local admin maken
Gemak krijgt voorrang op least privilege.
Te complexe device naming
De hostname wordt een assetdatabase.
Persoonsnamen gebruiken
Device lifecycle wordt gekoppeld aan één gebruiker.
Group Tags zonder governance
Nieuwe tags worden willekeurig toegevoegd.
Assignment niet vooraf controleren
De gebruiker ontdekt tijdens OOBE dat het verkeerde profiel actief is.
Alleen ideale scenario testen
Failure handling ontbreekt.
Geen change management
Een profielwijziging gaat direct naar productie.
Deployment Profile checklist
Controleer voordat u het profiel breed gebruikt:
✓ het businessscenario is gedefinieerd;
✓ user-driven deployment is bewust gekozen;
✓ Microsoft Entra Join versus Hybrid is beoordeeld;
✓ cloud-native mogelijkheden zijn onderzocht;
✓ OOBE is ontworpen vanuit gebruikerservaring;
✓ organisatiebranding is gecontroleerd;
✓ gebruikersinstructies zijn beschikbaar;
✓ Standard User versus Administrator is bepaald;
✓ device naming is eenvoudig en toekomstbestendig;
✓ persoonsgegevens worden niet onnodig in namen gebruikt;
✓ Group Tags hebben een duidelijke functie;
✓ dynamische groepen zijn getest;
✓ assignment is gevalideerd;
✓ profielnaam volgt naming convention;
✓ profiel is gedocumenteerd;
✓ Autopilotregistratie is gecontroleerd;
✓ nieuwe gebruikers zijn getest;
✓ bestaande gebruikers zijn getest;
✓ replacement devices zijn getest;
✓ foutscenario’s zijn getest;
✓ servicedesk-runbook is beschikbaar;
✓ ESP is end-to-end getest;
✓ compliance is getest;
✓ Conditional Access is getest;
✓ wijzigingen verlopen via change management;
✓ een permanente Autopilot-testmogelijkheid bestaat;
✓ KPI’s worden gemonitord.
Het belangrijkste ontwerpprincipe
Het Deployment Profile moet zo weinig mogelijk businesscomplexiteit bevatten.
Het moet vooral antwoord geven op:
Hoe wordt dit type Windows-apparaat op een voorspelbare manier onderdeel van onze beheerde omgeving?
Applicaties horen bij applicatiebeheer.
Security hoort bij Endpoint Security.
Compliance hoort bij Compliance Policies.
Access hoort bij Conditional Access.
Businessrollen horen bij de assignmentarchitectuur.
Het Deployment Profile heeft zijn eigen verantwoordelijkheid.
Dat leidt tot:
minder profielen
minder uitzonderingen
eenvoudigere troubleshooting
betere overdraagbaarheid
betrouwbaardere provisioning
Van Deployment Profile naar Enrollment Status Page
Wanneer het apparaat het juiste Deployment Profile heeft ontvangen en enrollment begint, ontstaat de volgende belangrijke vraag:
Waar moet Windows Autopilot op wachten voordat de gebruiker naar de desktop mag?
Dat is precies de rol van de Enrollment Status Page.
Een te lichte ESP kan een gebruiker te vroeg op een onvolledig apparaat laten werken.
Een te zware ESP kan provisioning extreem langzaam en kwetsbaar maken.
Daarom is de volgende ontwerpstap het vinden van de juiste balans:
Wat moet blocking zijn en wat kan na de eerste desktop worden geïnstalleerd?
Verder lezen
Lees ook:
Microsoft Intune: complete gids voor modern endpointbeheer
Microsoft Intune implementeren: stappenplan van voorbereiding tot productie
Microsoft Intune groepen en assignments ontwerpen: gebruikersgroepen, apparaatgroepen, filters en deployment rings
Microsoft Intune Endpoint Security baseline ontwerpen: BitLocker, Defender, Firewall, ASR en Account Protection
Microsoft Intune Compliance Policies ontwerpen: wanneer is een apparaat compliant of non-compliant?
Microsoft Intune compliance koppelen aan Conditional Access: veilig invoeren zonder gebruikers buiten te sluiten
Windows Autopilot architectuur ontwerpen: deployment profiles, group tags, Enrollment Status Page en provisioningflow
Hulp nodig met Windows Autopilot Deployment Profiles?
Krijgen apparaten het verkeerde Autopilot-profiel?
Twijfelt u tussen Microsoft Entra Join en een hybride inrichting?
Wilt u uw bestaande Deployment Profiles vereenvoudigen?
Of wilt u Windows Autopilot professioneel implementeren voordat nieuwe laptops rechtstreeks naar medewerkers worden verzonden?
Stel uw Intune-vraag — uw eerste vraag is gratis.
Beschrijf kort uw huidige situatie, het aantal Windows-apparaten en hoe nieuwe laptops momenteel worden ingericht. Wij geven u een eerste praktisch advies over de mogelijke architectuur of het probleem.
Stel gratis uw Intune-vraag →