Een Microsoft Intune-policy configureren is meestal niet het moeilijkste onderdeel van endpointbeheer.
De moeilijkere vraag is:
Aan wie moet deze policy worden toegewezen?
Een verkeerd ontworpen assignmentstructuur kan ervoor zorgen dat applicaties bij de verkeerde gebruikers terechtkomen, configuraties elkaar overlappen, uitzonderingen onduidelijk worden en nieuwe policies direct duizenden apparaten beïnvloeden.
Daarom zijn groepen, assignments, filters en deployment rings geen administratief detail. Ze vormen een belangrijk onderdeel van de Intune-architectuur.
In deze gids bekijken we hoe u een schaalbaar assignmentmodel voor Microsoft Intune ontwerpt zonder tientallen onnodige groepen en uitzonderingen te creëren.
Waarom zijn Intune-assignments zo belangrijk?
Vrijwel alles wat u binnen Microsoft Intune configureert, moet uiteindelijk ergens worden toegepast.
Denk aan:
- Configuration Profiles;
- Settings Catalog policies;
- compliance policies;
- Endpoint Security policies;
- applicaties;
- PowerShell-scripts;
- remediation-functionaliteit;
- Windows Update policies;
- Windows Autopilot-profielen;
- App Protection Policies.
De technische configuratie vertelt Intune wat er moet gebeuren.
De assignment bepaalt waar het moet gebeuren.
Conceptueel:
Policy
Target
Applicability
=
Effectieve configuratie
Een uitstekende security policy die aan de verkeerde apparaten wordt toegewezen, blijft een slechte implementatie.
1. Begin niet met groepen, maar met requirements
Een veelgemaakte fout is om direct tientallen Microsoft Entra-groepen aan te maken.
Begin eerst met de vraag waarom apparaten of gebruikers verschillend behandeld moeten worden.
Voorbeelden:
| Requirement | Mogelijke segmentatie |
|---|---|
| Alle Windows-gebruikers krijgen Microsoft 365 Apps | Gebruikers |
| Alle corporate Windows-laptops krijgen BitLocker | Apparaten/platform |
| Finance krijgt een financiële applicatie | Gebruikersgroep |
| Developers krijgen ontwikkeltools | Gebruikersgroep |
| Kiosk-apparaten krijgen specifieke configuratie | Apparaatgroep |
| Pilotgebruikers ontvangen beleid eerst | Deployment ring |
| Persoonlijke apparaten krijgen ander beleid | Filter/device-eigenschap |
| Specifieke hardware krijgt uitzondering | Filter of gerichte devicegroep |
Het uitgangspunt moet dus zijn:
Requirement → doelgroep → assignment
en niet:
groep → bedenken wat we ermee kunnen doen.
2. Begrijp het verschil tussen gebruikers- en apparaatgroepen
Binnen Intune kunnen veel configuraties worden toegewezen aan gebruikers of apparaten.
Die keuze heeft belangrijke gevolgen.
User targeting
Bij user targeting volgt de configuratie in principe de gebruiker.
Dit is logisch wanneer de requirement betrekking heeft op:
- gebruikersrechten;
- gebruikersapplicaties;
- persoonlijke instellingen;
- afdelingsspecifieke software;
- gebruikerservaring;
- bepaalde security- of accessscenario’s.
Voorbeeld:
Een medewerker van Finance moet de financiële applicatie krijgen ongeacht welke beheerde laptop hij gebruikt.
Dan is een gebruikersgerichte assignment logisch.
Device targeting
Bij device targeting volgt de configuratie het apparaat.
Dit is logischer voor:
- kioskdevices;
- shared devices;
- specifieke hardware;
- apparaatconfiguratie;
- device security;
- bepaalde Autopilot-scenario’s;
- infrastructuurgebonden configuraties.
Voorbeeld:
Een receptiecomputer moet altijd in kioskmodus functioneren, ongeacht welke medewerker zich aanmeldt.
Dan ligt device targeting voor de hand.
3. Gebruik een eenvoudige beslisregel
Een praktische vraag bij iedere assignment is:
Hoort deze requirement bij de persoon of bij het apparaat?
Bijvoorbeeld:
| Requirement | Waarschijnlijk target |
|---|---|
| Finance-applicatie | User |
| Marketing-applicatie | User |
| BitLocker | Device |
| Kioskconfiguratie | Device |
| Shared PC-configuratie | Device |
| Persoonlijke gebruikersinstelling | User |
| Hardware-specifieke instelling | Device |
| Algemene bedrijfsapplicatie | User of Device, afhankelijk van lifecycle |
| Windows securitybaseline | Vaak Device |
| BYOD App Protection | User |
Er bestaat geen universele regel die voor iedere Intune-setting geldt. Kijk altijd naar het gedrag van de specifieke policy en het gewenste resultaat.
4. Maak niet voor iedere policy een aparte groep
Dit is een van de belangrijkste ontwerpprincipes.
Stel dat een organisatie 100 policies heeft.
Als iedere policy een eigen groep krijgt, ontstaat al snel:
GRP-INTUNE-POLICY-001
GRP-INTUNE-POLICY-002
GRP-INTUNE-POLICY-003
enzovoort.
Dat is technisch mogelijk, maar operationeel onhandig.
Groepen moeten bij voorkeur een herkenbare business- of deploymentfunctie vertegenwoordigen.
Bijvoorbeeld:
GRP-INTUNE-PILOT-USERS
GRP-INTUNE-FINANCE-USERS
GRP-INTUNE-DEVELOPERS
GRP-INTUNE-KIOSK-DEVICES
GRP-INTUNE-SHARED-DEVICES
GRP-INTUNE-EARLY-PRODUCTION
Dezelfde relevante groep kan vervolgens voor meerdere samenhangende assignments worden gebruikt.
5. Ontwerp een groepsmodel
Een praktische Intune-omgeving kan groepen in verschillende functionele categorieën verdelen.
| Categorie | Voorbeeld |
|---|---|
| Pilot | GRP-INTUNE-PILOT-USERS |
| Productie | GRP-INTUNE-PRODUCTION-USERS |
| Afdeling | GRP-INTUNE-FINANCE-USERS |
| Applicatie | GRP-INTUNE-APP-SAP-USERS |
| Device type | GRP-INTUNE-KIOSK-DEVICES |
| Platform | GRP-INTUNE-WINDOWS-DEVICES |
| Uitzondering | GRP-INTUNE-EXC-SPECIFIC-CONTROL |
| Rollout | GRP-INTUNE-EARLY-PRODUCTION |
Niet iedere organisatie heeft al deze categorieën nodig.
Een omgeving met 50 gebruikers kan aanzienlijk eenvoudiger zijn dan een organisatie met 20.000 endpoints.
6. Gebruik duidelijke naamgeving
Wanneer groepen alleen namen hebben zoals:
Pilot
Windows
Apps
Test
wordt na verloop van tijd onduidelijk waarvoor ze bedoeld zijn.
Gebruik een consistente conventie.
Bijvoorbeeld:
GRP-[PLATFORM]-[FUNCTION]-[TARGET]
Daarmee krijgt u bijvoorbeeld:
GRP-INTUNE-PILOT-USERS
GRP-INTUNE-APP-FINANCE-USERS
GRP-INTUNE-KIOSK-DEVICES
GRP-INTUNE-EXC-BITLOCKER-DEVICES
De exacte conventie is minder belangrijk dan consistent gebruik.
7. Gebruik statische groepen waar dat logisch is
Een statische groep heeft expliciet beheerde leden.
Dit is zeer bruikbaar voor bijvoorbeeld een kleine pilotgroep.
Stel:
GRP-INTUNE-PILOT-USERS
bevat acht medewerkers uit verschillende afdelingen.
Het endpointteam bepaalt bewust wie deelneemt.
Dat geeft maximale controle.
Statische groepen zijn vooral praktisch wanneer membership een bewuste organisatorische beslissing is.
8. Gebruik dynamische groepen voor objectieve kenmerken
Dynamische groepen kunnen membership automatisch bepalen op basis van eigenschappen.
Dat kan zeer krachtig zijn.
Denk bijvoorbeeld aan apparaten die op basis van een relevant kenmerk automatisch in een bepaalde groep terechtkomen.
Hiermee kan een beheerproces worden geautomatiseerd.
Maar dynamische groepen moeten zorgvuldig worden ontworpen.
Een verkeerde regel kan immers automatisch veel meer objecten selecteren dan bedoeld.
Daarom geldt:
Test de membershipregel voordat u kritieke policies aan de groep koppelt.
9. Gebruik filters om assignments verder te verfijnen
Intune assignment filters kunnen zeer waardevol zijn wanneer u een brede doelgroep wilt gebruiken, maar de applicability verder wilt beperken.
Conceptueel:
Assignment
→ brede doelgroep
Filter
→ welke apparaten binnen die context daadwerkelijk van toepassing zijn
Stel bijvoorbeeld dat een policy aan een brede groep gebruikers wordt toegewezen, maar alleen op corporate Windows-apparaten moet worden toegepast.
Een passend filter kan helpen om de doelgroep te verfijnen zonder voor iedere technische variatie een nieuwe Entra-groep te creëren.
Dit kan het aantal groepen aanzienlijk verminderen.
10. Groepen en filters zijn niet hetzelfde
Gebruik groepen voor:
wie of welke beheerde populatie
Gebruik filters voor:
op welke relevante apparaten binnen die assignmentcontext
Een conceptueel voorbeeld:
Alle medewerkers
↓
Assignment
↓
Filter: corporate Windows-apparaten
↓
Policy wordt alleen daar toegepast waar bedoeld
Dit is vaak efficiënter dan meerdere bijna identieke groepen onderhouden.
11. Wanneer gebruikt u een groep en wanneer een filter?
Een eenvoudige beslismatrix:
| Situatie | Groep | Filter |
|---|---|---|
| Finance-medewerkers | ✓ | |
| Pilotgebruikers | ✓ | |
| Developers | ✓ | |
| Kioskpopulatie | ✓ | Mogelijk |
| Alleen corporate devices | ✓ | |
| Specifieke device-eigenschap | Mogelijk | ✓ |
| OS-/devicekenmerk | Mogelijk | ✓ |
| Businessrol | ✓ | |
| Applicatietoegang | ✓ | |
| Technische verfijning binnen brede assignment | ✓ |
Denk hierbij aan groepen als populaties en filters als applicability-logica.
12. Gebruik All Users en All Devices bewust
Intune maakt brede targeting mogelijk.
Dat is nuttig voor policies die daadwerkelijk universeel moeten gelden.
Maar brede targeting vergroot ook de impact van fouten.
Een verkeerde instelling die aan een testgroep van vijf apparaten is toegewezen, heeft een beperkte impact.
Dezelfde fout op vrijwel de volledige devicepopulatie kan een serieus incident veroorzaken.
Gebruik brede assignments daarom alleen wanneer:
- de policy daarvoor bedoeld is;
- de policy getest is;
- uitzonderingen bekend zijn;
- de impact begrepen wordt;
- rollback mogelijk is.
Breed targeten is een productiestap, geen teststrategie.
13. Bouw deployment rings
Deployment rings behoren tot de belangrijkste veiligheidsmechanismen binnen een professionele Intune-omgeving.
Een praktisch model:
| Ring | Doelgroep | Doel |
|---|---|---|
| Ring 0 | Endpointteam | Technische validatie |
| Ring 1 | IT Pilot | Eerste operationele test |
| Ring 2 | Business Pilot | Representatieve gebruikers |
| Ring 3 | Early Production | Beperkte productie |
| Ring 4 | Broad Production | Algemene uitrol |
Hiermee ontstaat:
Ring 0
↓
Ring 1
↓
Ring 2
↓
Ring 3
↓
Ring 4
Een wijziging beweegt gecontroleerd door de organisatie.
14. Waarom alleen een IT-pilot niet voldoende is
IT-medewerkers zijn zelden representatief voor de volledige organisatie.
Zij gebruiken vaak andere:
- applicaties;
- rechten;
- hardware;
- workflows;
- peripherals;
- netwerkverbindingen.
Daarom moet een business pilot verschillende gebruiksscenario’s bevatten.
Bijvoorbeeld:
Finance
HR
Sales
Operations
Management
Remote workers
Power users
De kwaliteit van de pilot wordt bepaald door representativiteit, niet alleen door het aantal deelnemers.
15. Gebruik dezelfde ringfilosofie voor verschillende Intune-componenten
Deployment rings zijn niet alleen relevant voor Windows Updates.
U kunt dezelfde methodiek gebruiken voor:
- Configuration Profiles;
- security policies;
- applicaties;
- scripts;
- remediation;
- compliancewijzigingen;
- Autopilot;
- belangrijke configuratiewijzigingen.
Een standaard changeflow kan bijvoorbeeld zijn:
Development
↓
Technical Test
↓
IT Pilot
↓
Business Pilot
↓
Early Production
↓
Broad Production
Hiermee wordt gefaseerde deployment onderdeel van de operationele werkwijze.
16. Ontwerp exclusions uiterst zorgvuldig
Exclusions zijn soms noodzakelijk.
Maar iedere exclusion creëert een afwijking van de standaard.
Bijvoorbeeld:
Security Policy
→ alle Windows-apparaten
Exclude
→ GRP-INTUNE-EXC-SECURITY-CONTROL
Dat kan technisch noodzakelijk zijn.
Maar documenteer minimaal:
| Veld | Voorbeeld |
|---|---|
| Exclusion | Legacy application devices |
| Reden | Applicatie incompatibel |
| Owner | Application Owner |
| Goedgekeurd door | Security |
| Startdatum | Datum |
| Reviewdatum | Datum |
| Compensating control | Indien relevant |
| Einddoel | Exclusion verwijderen |
Een exclusion zonder owner of reviewdatum wordt gemakkelijk permanent.
17. Voorkom een exclusion-cultuur
Wanneer iedere uitzondering wordt opgelost door nóg een exclusiongroep te maken, ontstaat langzaam een omgeving waarin niemand meer weet welk beleid werkelijk geldt.
Bijvoorbeeld:
Base Policy
minus
Exception Group A
minus
Exception Group B
minus
Legacy Group
minus
VIP Group
minus
Temporary Group
minus
Test Exclusion
Dit wordt snel onbeheersbaar.
Gebruik daarom het principe:
Uitzonderingen moeten uitzonderlijk blijven.
18. Vermijd VIP-groepen zonder technische reden
Een veelvoorkomend anti-pattern is:
VIP USERS
waarbij senior management minder security controls krijgt omdat bepaalde maatregelen als lastig worden ervaren.
Dat is riskant.
Juist accounts met toegang tot gevoelige informatie kunnen aantrekkelijke doelwitten zijn.
Een functietitel is daarom op zichzelf geen goede technische reden voor minder beveiliging.
Als een uitzondering noodzakelijk is, behandel deze als een formele risk exception.
19. Denk goed na over applicatie-assignments
Applicaties hebben vaak andere assignmentrequirements dan configuratiepolicies.
Maak bijvoorbeeld onderscheid tussen:
Required
Applicatie wordt automatisch geïnstalleerd.
Available
Gebruiker kan applicatie via Company Portal installeren.
Uninstall
Applicatie moet worden verwijderd.
Voorbeeld:
| Applicatie | Target | Intent |
|---|---|---|
| Microsoft 365 Apps | Medewerkers | Required |
| Finance-app | Finance | Required |
| Visio | Gelicentieerde gebruikers | Available/Required volgens beleid |
| Developer Tool | Developers | Available |
| Legacy App | Migratiegroep | Required |
| Oude VPN-client | Migratiegroep | Uninstall |
Assignmentdesign wordt hiermee onderdeel van application lifecycle management.
20. Pas op met conflicterende assignments
Een gebruiker of apparaat kan lid zijn van meerdere groepen.
Daarmee kunnen verschillende policies hetzelfde endpoint bereiken.
Bijvoorbeeld:
Windows Baseline
Finance Configuration
Remote Worker Configuration
Security Policy
Pilot Policy
Wanneer deze allemaal verschillende settings configureren, kan overlap ontstaan.
Daarom is een goede policyarchitectuur net zo belangrijk als de groepsarchitectuur.
Gebruik bij voorkeur:
Eén policy = één duidelijke verantwoordelijkheid.
Zo wordt sneller zichtbaar waar een bepaalde instelling vandaan komt.
21. Bouw een assignmentmatrix
Voor grotere omgevingen is een assignmentmatrix bijzonder nuttig.
Bijvoorbeeld:
| Policy | Target | Filter | Exclusion | Ring | Owner |
|---|---|---|---|---|---|
| WIN-Security-BitLocker | Windows Production | Corporate | Exception Group | Production | Endpoint |
| WIN-Edge-Base | All Users | Windows | Geen | Production | Endpoint |
| WIN-Pilot-Security | Pilot Users | Windows | Geen | Pilot | Security |
| APP-Finance | Finance Users | Windows | Geen | Production | App Owner |
| WIN-Kiosk | Kiosk Devices | Kiosk | Geen | Production | Endpoint |
Hiermee wordt onmiddellijk zichtbaar hoe policies door de omgeving worden verspreid.
22. Documenteer het doel van iedere groep
Een groepsnaam alleen is niet voldoende.
Documenteer:
Naam
Doel
Owner
Membershiptype
Membershiplogica
Gebruikte assignments
Securityimpact
Reviewfrequentie
Bijvoorbeeld:
| Eigenschap | Waarde |
|---|---|
| Naam | GRP-INTUNE-PILOT-USERS |
| Doel | Representatieve Intune-pilot |
| Type | Static |
| Owner | Endpoint Team |
| Leden | 15 |
| Gebruik | Config, apps, security |
| Review | Maandelijks |
Dit voorkomt zogenaamde orphaned groups waarvan niemand meer weet waarom ze bestaan.
23. Maak ownership expliciet
Iedere belangrijke groep moet een eigenaar hebben.
Dat geldt vooral voor:
- applicatiegroepen;
- security exceptions;
- pilotgroepen;
- privileged populations;
- speciale devicegroepen.
Voor een Finance-applicatie kan bijvoorbeeld Finance of de applicatie-eigenaar bepalen wie toegang nodig heeft, terwijl IT verantwoordelijk blijft voor de technische deployment.
Dat is governance.
24. Ontwerp voor joiners, movers en leavers
Een goede groepsarchitectuur moet ook werken wanneer medewerkers:
in dienst komen
van functie veranderen
van afdeling veranderen
tijdelijk een andere rol krijgen
uit dienst gaan
Stel dat iemand van Sales naar Finance verhuist.
Idealiter leidt een wijziging in identity- of groepsmembership ertoe dat:
Sales-applicaties verdwijnen
↓
Finance-applicaties beschikbaar komen
↓
relevante policies veranderen
↓
toegang wordt aangepast
Hoe minder handmatige uitzonderingen daarvoor nodig zijn, hoe schaalbaarder het model.
25. Gebruik businessrollen waar mogelijk
Een volwassen architectuur koppelt technische configuratie zoveel mogelijk aan begrijpelijke bedrijfsrollen.
Bijvoorbeeld:
Finance User
→ Finance apps
→ relevante toegang
→ relevante configuration
Developer
→ Development tools
→ aanvullende technische configuratie
Standard User
→ standaardapplicaties
→ standaardsecurity
→ standaardconfiguration
Zo wordt endpointbeheer onderdeel van identity- en lifecyclemanagement.
26. Scheid productie en test logisch
Testobjecten mogen niet willekeurig tussen productieobjecten staan.
Gebruik bijvoorbeeld duidelijke namen:
GRP-INTUNE-TEST-WINDOWS
GRP-INTUNE-PILOT-USERS
GRP-INTUNE-EARLY-PRODUCTION
GRP-INTUNE-PRODUCTION-USERS
Hetzelfde geldt voor policies:
TEST – WIN – Edge – Configuration
PILOT – WIN – Edge – Configuration
of werk met een changeproces waarbij dezelfde gecontroleerde configuratie door deploymentfasen beweegt.
Welke aanpak u kiest is minder belangrijk dan duidelijke governance.
27. Maak rollout meetbaar
Een deployment ring moet niet alleen een groep zijn.
Definieer succescriteria.
Bijvoorbeeld:
| Metric | Doel |
|---|---|
| Policy deployment success | ≥ 98% |
| Applicatie-installaties | ≥ 97% |
| Kritieke incidenten | 0 |
| Complianceverlies | Geen onverwachte daling |
| Supporttickets | Binnen afgesproken grens |
| Gebruikersimpact | Geen blocker |
| Security exceptions | Beoordeeld |
Pas wanneer de vorige ring stabiel is, gaat de wijziging naar de volgende.
28. Gebruik deployment rings ook als rollbackmechanisme
Gefaseerde uitrol beperkt niet alleen risico.
Het maakt stoppen eenvoudiger.
Stel:
Ring 0 → goed
Ring 1 → goed
Ring 2 → probleem
Dan hoeft Ring 3 en Ring 4 nog niets te ontvangen.
U kunt:
deployment stoppen
↓
oorzaak onderzoeken
↓
configuratie aanpassen
↓
Ring 2 opnieuw testen
↓
pas daarna verder uitrollen
Dit is aanzienlijk veiliger dan organisatiebrede wijzigingen.
29. Kleine organisatie? Houd het klein
Een organisatie met 50 gebruikers heeft meestal geen ingewikkelde assignmentarchitectuur nodig.
Bijvoorbeeld:
GRP-INTUNE-PILOT-USERS
5 gebruikers.
GRP-INTUNE-USERS
Overige medewerkers.
GRP-INTUNE-BYOD-USERS
Alleen indien relevant.
GRP-INTUNE-APP-SPECIAL-USERS
Alleen voor specifieke software.
Dat kan voldoende zijn.
Voeg geen enterprisecomplexiteit toe wanneer daar geen requirement voor bestaat.
30. Grote organisatie? Ontwerp governance vóór schaal
Bij duizenden endpoints verandert de situatie.
Dan kunnen bijvoorbeeld relevant worden:
- meerdere regio’s;
- verschillende businessunits;
- device ownership;
- platformverschillen;
- shared devices;
- kiosks;
- frontline workers;
- verschillende applicatieportfolio’s;
- lokale IT-teams;
- meerdere deploymentrings;
- security exceptions;
- gespecialiseerde hardware.
Maar ook hier geldt:
standaardiseer eerst, segmenteer alleen waar noodzakelijk.
Een organisatie met 20.000 apparaten hoeft niet automatisch honderden verschillende endpointconfiguraties te hebben.
Voorbeeldarchitectuur voor Intune-assignments
Een schaalbaar model kan conceptueel zo worden opgebouwd:
Microsoft Entra ID
↓
Business Identity
- Standard Users
- Finance
- HR
- Developers
- Frontline
↓
Intune Deployment
- Pilot
- Early Production
- Broad Production
↓
Device Context
- Corporate
- Personal
- Windows
- Mobile
- Shared
- Kiosk
↓
Filters
↓
Configuration / Apps / Security / Compliance
↓
Exceptions
↓
Monitoring
Hiermee worden businesscontext, rollout en technische devicekenmerken van elkaar gescheiden.
Voorbeeld: organisatie met 500 gebruikers
Stel dat een organisatie 500 medewerkers heeft.
De organisatie gebruikt voornamelijk Windows 11-laptops en Microsoft 365.
Er zijn daarnaast Finance-, HR- en Developer-applicaties.
Een mogelijke structuur:
| Groep | Gebruik |
|---|---|
| GRP-INTUNE-RING0-ENDPOINT | Endpointteam |
| GRP-INTUNE-RING1-IT | IT-pilot |
| GRP-INTUNE-RING2-BUSINESS | Businesspilot |
| GRP-INTUNE-RING3-EARLY | Early Production |
| GRP-INTUNE-FINANCE | Finance-apps |
| GRP-INTUNE-HR | HR-apps |
| GRP-INTUNE-DEVELOPERS | Developmenttools |
| GRP-INTUNE-KIOSK-DEVICES | Kioskbeleid |
| GRP-INTUNE-EXC-APP01 | Tijdelijke uitzondering |
Algemene Windows-security hoeft daarbij niet per afdeling verschillend te zijn.
Alle afdelingen kunnen dezelfde standaardbaseline gebruiken.
Dat is standaardisatie.
Wat is een slecht assignmentmodel?
Een omgeving wordt moeilijk beheersbaar wanneer u patronen ziet zoals:
één groep per policy
één groep per instelling
veel handmatig beheerde devicegroepen
onduidelijke testgroepen
permanente tijdelijke groepen
veel exclusions
geen group owners
geen documentatie
geen deployment rings
directe brede productieassignments
overlappende policies
namen zoals Test1, Test2, NewTest en FinalTest
Dit zijn signalen dat de omgeving organisch groeit zonder architectuur.
Assignment governance
Maak assignments onderdeel van change management.
Een nieuwe productieassignment moet minimaal antwoord geven op:
| Vraag | Vereist |
|---|---|
| Wat verandert er? | Ja |
| Waarom is dit nodig? | Ja |
| Welke doelgroep? | Ja |
| User of Device target? | Ja |
| Filter nodig? | Indien relevant |
| Exclusions? | Indien relevant |
| Pilot uitgevoerd? | Ja |
| Impact beoordeeld? | Ja |
| Rollback mogelijk? | Ja |
| Owner bekend? | Ja |
| Documentatie bijgewerkt? | Ja |
Zo voorkomt u dat assignments ongecontroleerd ontstaan.
Periodieke opschoning
Een Intune-omgeving verandert voortdurend.
Applicaties verdwijnen.
Projecten eindigen.
Pilotgroepen worden vervangen.
Uitzonderingen zijn niet meer nodig.
Voer daarom periodiek een review uit van:
groepen
filters
assignments
exclusions
testobjecten
ongebruikte policies
oude applicaties
owners
dynamische membershipregels
Vraag bij ieder object:
Heeft dit nog een actuele business- of technische functie?
Zo niet, verwijder het gecontroleerd.
Praktische checklist voor Intune-groepen en assignments
Controleer voordat u het assignmentmodel breed gebruikt:
✓ requirements zijn bekend;
✓ user- en device-targeting bewust worden gekozen;
✓ groepsnamen consistent zijn;
✓ groepen een duidelijke functie hebben;
✓ groepsowners zijn vastgelegd;
✓ statische en dynamische groepen bewust worden gebruikt;
✓ dynamische regels zijn getest;
✓ filters worden gebruikt waar ze groepen kunnen vereenvoudigen;
✓ All Users en All Devices alleen bewust worden gebruikt;
✓ pilotgroepen aanwezig zijn;
✓ deployment rings zijn gedefinieerd;
✓ businessgebruikers onderdeel zijn van de pilot;
✓ exclusions worden gedocumenteerd;
✓ uitzonderingen een owner en reviewdatum hebben;
✓ applicatie-assignments logisch zijn ingericht;
✓ conflicterende assignments worden voorkomen;
✓ assignmentmatrix beschikbaar is;
✓ joiner/mover/leaver-processen zijn meegenomen;
✓ rolloutcriteria meetbaar zijn;
✓ periodieke cleanup is gepland.
De belangrijkste ontwerpregel
Een professionele Intune-omgeving heeft niet zoveel mogelijk groepen nodig.
Het doel is juist het tegenovergestelde:
Zo weinig mogelijk groepen en uitzonderingen, maar zoveel als noodzakelijk om duidelijke requirements veilig uit te voeren.
Een goed assignmentmodel is begrijpelijk.
Een beheerder moet kunnen kijken naar een policy en snel kunnen beantwoorden:
Wat doet deze policy?
Voor wie geldt deze policy?
Waarom geldt deze policy daar?
Welke uitzonderingen bestaan?
Wie is eigenaar?
Hoe is deze policy getest?
Als die vragen moeilijk te beantwoorden zijn, is de assignmentarchitectuur waarschijnlijk te complex geworden.
Van groepen naar Configuration Profiles
Zodra de targetingarchitectuur staat, kan de volgende laag worden ontworpen:
Configuration Profiles.
Daarbij ontstaan nieuwe vragen:
Welke instellingen horen bij elkaar?
Wanneer gebruikt u Settings Catalog?
Hoe voorkomt u policy overlap?
Hoe maakt u een Windows-baseline?
Hoe gaat u om met oude Group Policies?
En hoeveel Configuration Profiles heeft een organisatie werkelijk nodig?
Dat is de volgende stap in een gestructureerde Microsoft Intune-implementatie.
Verder lezen over Microsoft Intune
Lees ook:
Microsoft Intune: complete gids voor modern endpointbeheer
Microsoft Intune implementeren: stappenplan van voorbereiding tot productie
Microsoft Intune implementatie checklist: 50 punten die u vóór de uitrol moet controleren
Microsoft Intune tenant voorbereiden: 20 instellingen en ontwerpkeuzes vóór de implementatie
Microsoft Intune pilot opzetten: hoe test u Intune vóór de productie-uitrol?
Microsoft Intune basisconfiguratie: welke instellingen moet u als eerste configureren?
Hulp nodig met uw Intune-groepen en assignments?
Is uw Intune-omgeving inmiddels gevuld met groepen, policies, filters en uitzonderingen en wordt het steeds moeilijker om te bepalen welke configuratie op welke apparaten terechtkomt?
Of wilt u vóór een nieuwe Intune-implementatie een schaalbare assignmentarchitectuur ontwerpen?
Stel uw Intune-vraag — uw eerste vraag is gratis.
Beschrijf kort hoeveel gebruikers en apparaten u beheert, welke platformen u gebruikt en hoe uw huidige groepen en assignments zijn ingericht. Wij geven u een eerste praktisch advies over mogelijke verbeteringen.