Een Microsoft Intune-implementatie begint niet met het uitrollen van apparaten.

De kwaliteit van de uiteindelijke omgeving wordt voor een groot deel bepaald door de keuzes die u maakt voordat de eerste gebruiker wordt enrolled.

Een tenant die zonder duidelijke structuur wordt ingericht, kan al snel problemen krijgen met:

• onduidelijke assignments;
• verkeerde administratorrechten;
• conflicterende policies;
• te brede enrollmentmogelijkheden;
• onnodige BYOD-risico’s;
• slecht ingerichte groepen;
• onduidelijke ownership;
• moeilijk troubleshooting.

Daarom is tenantvoorbereiding een aparte projectfase.

In dit artikel behandelen we 20 instellingen en ontwerpkeuzes die u vóór de brede Intune-implementatie moet beoordelen.

Waarom tenantvoorbereiding belangrijk is

Intune is geen losstaand product.

De omgeving werkt samen met onder andere:

Microsoft Entra ID

↓

Licensing

↓

Device Enrollment

↓

Configuration

↓

Applications

↓

Compliance

↓

Conditional Access

↓

Endpoint Security

Een verkeerde ontwerpbeslissing vroeg in het traject kan dus later op meerdere plaatsen gevolgen hebben.

Een voorbeeld:

U maakt groepen zonder duidelijke naming convention.

In eerste instantie lijkt dat niet ernstig.

Na enkele maanden bestaan echter:

• tientallen groepen;
• honderden assignments;
• meerdere exclusions;
• applicaties;
• compliance policies.

Dan wordt een simpele vraag als:

Waarom krijgt deze gebruiker deze policy?

veel moeilijker te beantwoorden.

Een goed voorbereide tenant voorkomt daarom toekomstige complexiteit.

---

1. Controleer welke tenant u daadwerkelijk gaat gebruiken

Dit klinkt vanzelfsprekend, maar is belangrijk bij organisaties met:

• meerdere Microsoft 365-tenants;
• testtenants;
• acquisities;
• dochterbedrijven;
• internationale omgevingen.

Bepaal vooraf:

• welke tenant productie wordt;
• wie eigenaar is;
• welke gebruikers erin staan;
• welke domeinen gekoppeld zijn;
• welke bestaande configuratie aanwezig is.

Begin niet met implementeren voordat duidelijk is wat de bron van waarheid wordt.

---

2. Inventariseer bestaande Microsoft 365-configuratie

Een bestaande tenant is vrijwel nooit leeg.

Er kunnen al configuraties bestaan voor:

• Microsoft Entra ID;
• Conditional Access;
• Microsoft Defender;
• Microsoft 365 Apps;
• security groups;
• administrators;
• mobiele apparaten;
• compliance;
• oude pilots.

Documenteer wat er al bestaat.

Anders kunt u tijdens de Intune-implementatie onbewust nieuwe configuratie bovenop oude configuratie bouwen.

---

3. Controleer licensing

Voordat technische keuzes worden gemaakt, moet duidelijk zijn welke functionaliteit beschikbaar is.

Controleer bijvoorbeeld:

• Intune Plan 1;
• aanvullende Intune-capabilities;
• Microsoft Entra licensing;
• Microsoft Defender;
• Conditional Access;
• advanced Intune-capabilities.

De architectuur moet aansluiten op de entitlement.

Niet andersom.

Een veelgemaakte fout is eerst een technisch ontwerp maken en pas later ontdekken dat aanvullende licensing nodig is.

---

4. Bepaal wie Intune Platform Owner wordt

Iedere production tenant heeft een duidelijke eigenaar nodig.

Dat kan bijvoorbeeld zijn:

Endpoint Management Team

of:

Modern Workplace Team

De Platform Owner is verantwoordelijk voor zaken zoals:

• architectuur;
• standards;
• lifecycle;
• governance;
• documentation;
• change control;
• health checks.

Zonder ownership wordt Intune al snel een gedeelde omgeving waarin iedereen configuraties toevoegt, maar niemand verantwoordelijk is voor het geheel.

---

5. Ontwerp administratorrollen

Niet iedere IT-medewerker heeft dezelfde rechten nodig.

Definieer vooraf rollen.

Bijvoorbeeld:

Rol	Mogelijke verantwoordelijkheid
Intune Platform Administrator	Platformconfiguratie
Endpoint Engineer	Devices en policies
Application Administrator	Applicatiebeheer
Service Desk	Operationele support
Security Administrator	Security policies
Auditor	Read-only
Platform Owner	Governance

Gebruik het principe:

least privilege.

Geef beheerders alleen de rechten die ze voor hun taak nodig hebben.

---

6. Gebruik niet standaard Global Administrator

Global Administrator wordt in veel organisaties te breed gebruikt.

Dat is onnodig risicovol.

Voor dagelijkse Intune-werkzaamheden zijn meestal specifiekere rollen beschikbaar.

Gebruik Global Administrator alleen wanneer werkelijk noodzakelijk.

De basisregel is:

privileged access moet uitzonderlijk zijn, niet normaal.

---

7. Bescherm administratoraccounts

Een Intune Administrator kan mogelijk configuratie aanpassen voor duizenden endpoints.

Bescherm deze accounts daarom zorgvuldig.

Denk aan:

• MFA;
• sterke Conditional Access;
• aparte beheeraccounts;
• beperkte sessies;
• least privilege;
• monitoring;
• gecontroleerde role assignment.

Adminsecurity is onderdeel van endpointsecurity.

---

8. Ontwerp RBAC voordat het beheerteam groeit

Role-Based Access Control wordt vaak pas ingericht wanneer er al veel beheerders zijn.

Dat is te laat.

Bepaal vooraf:

• wie policies mag wijzigen;
• wie apps mag publiceren;
• wie devices mag beheren;
• wie rapportages mag bekijken;
• wie remote acties mag uitvoeren.

Bij grotere organisaties kunnen ook scope tags en delegated administration relevant zijn.

Het doel is dat beheerders alleen toegang hebben tot wat ze nodig hebben.

---

9. Ontwerp een naming convention

Naming conventions zijn een van de eenvoudigste manieren om toekomstige chaos te voorkomen.

Gebruik bijvoorbeeld een structuur zoals:

Platform – Ownership – Category – Purpose

Voorbeelden:

WIN-CORP-CONF-OneDrive

WIN-CORP-SEC-BitLocker

WIN-CORP-COMP-Standard

IOS-BYOD-MAM-Standard

WIN-CORP-APP-Microsoft365

De exacte syntax is minder belangrijk dan consistentie.

---

10. Gebruik dezelfde naminglogica voor meerdere objecttypen

Een veelgemaakte fout is verschillende naamgevingssystemen gebruiken voor:

• policies;
• apps;
• groups;
• compliance;
• update rings.

Ontwerp één overkoepelende standaard.

Bijvoorbeeld:

Platform

Ownership

Function

Target

Version indien nodig

Hierdoor wordt de tenant veel gemakkelijker te begrijpen.

---

11. Ontwerp uw groepsarchitectuur

Groups zijn essentieel voor assignments.

Gebruik daarom geen ad-hocmodel waarin voor iedere nieuwe policy een nieuwe groep ontstaat.

Bepaal welke soorten groepen nodig zijn.

Bijvoorbeeld:

• pilot groups;
• production groups;
• application groups;
• device groups;
• security rings;
• exception groups.

Iedere groep moet een duidelijk doel hebben.

---

12. Beperk exclusions

Exclusions lijken handig.

Bijvoorbeeld:

Deze gebruiker hoeft deze policy niet te krijgen.

Maar iedere exclusion verhoogt beheercomplexiteit.

Na verloop van tijd kan een organisatie honderden uitzonderingen hebben waarvan niemand meer weet waarom ze bestaan.

Gebruik daarom voor iedere exclusion:

• businessreason;
• owner;
• approval;
• datum;
• reviewdatum.

Een exclusion zonder lifecycle moet als technische schuld worden gezien.

---

13. Bepaal user-based versus device-based targeting

Niet iedere policy moet naar hetzelfde objecttype worden toegewezen.

Sommige instellingen passen logisch bij:

users

andere bij:

devices.

Denk vooraf na over targeting.

Bijvoorbeeld:

Een gebruikersspecifieke applicatie kan logisch user-based zijn.

Een securityconfiguratie voor alle corporate Windows-devices kan device-based logischer zijn.

Consistente targeting maakt troubleshooting gemakkelijker.

---

14. Ontwerp enrollment restrictions

Bepaal welke apparaten überhaupt in Intune mogen worden enrolled.

Controleer bijvoorbeeld:

• platforms;
• ownership;
• OS-versies;
• personal devices;
• maximale deviceaantallen.

Het doel is te voorkomen dat iedere medewerker ieder willekeurig apparaat kan registreren zonder dat dit past binnen het securitybeleid.

---

15. Bepaal corporate versus personal ownership

Deze keuze heeft impact op:

• privacy;
• enrollment;
• policies;
• wipe;
• app management;
• reporting.

Maak daarom vooraf een duidelijke definitie.

Bijvoorbeeld:

Corporate

Device is eigendom van de organisatie.

Personal

Device is eigendom van de gebruiker.

Een BYOD-strategie moet aansluiten op deze classificatie.

---

16. Ontwerp het BYOD-model

Bepaal vooraf wat u met privédevices wilt doen.

Mogelijke modellen:

Geen BYOD

Alleen corporate devices.

BYOD met MDM

Privédevice wordt volledig enrolled.

BYOD met MAM

Alleen zakelijke apps en data worden beschermd.

Voor veel organisaties kan MAM een interessante balans bieden tussen security en privacy.

Maar dit moet bewust worden gekozen.

Niet toevallig ontstaan.

---

17. Ontwerp enrollment per platform

Windows, Apple en Android hebben verschillende enrollmentmodellen.

Maak daarom per platform een afzonderlijk ontwerp.

Bijvoorbeeld:

Platform	Mogelijk model
Windows corporate	Autopilot
Windows existing	Existing device enrollment
iPhone corporate	Automated Device Enrollment
iPhone BYOD	MAM of user enrollment
Android corporate	Android Enterprise
Android BYOD	Work Profile

Niet iedere organisatie heeft alle scenario’s nodig.

Houd de scope beperkt.

---

18. Ontwerp pilot- en deploymentgroepen

Maak vóór productie al test- en rolloutgroepen.

Bijvoorbeeld:

Ring 0 — Endpoint Team

↓

Ring 1 — IT Pilot

↓

Ring 2 — Business Pilot

↓

Ring 3 — Early Production

↓

Ring 4 — Broad Production

Gebruik dezelfde filosofie voor:

• policies;
• apps;
• updates;
• securitywijzigingen.

Zo kunt u veranderingen gecontroleerd uitrollen.

---

19. Bepaal de standaard voor policy design

Maak vóór het aanmaken van tientallen policies regels voor hoe policies worden opgebouwd.

Een bruikbaar principe:

één duidelijke verantwoordelijkheid per policy.

Bijvoorbeeld:

Niet:

WIN-All-Settings

met 150 instellingen.

Maar:

WIN-CORP-SEC-BitLocker

WIN-CORP-CONF-OneDrive

WIN-CORP-CONF-Browser

WIN-CORP-SEC-Firewall

Dat maakt impactanalyse en troubleshooting eenvoudiger.

---

20. Leg governance en change control vast

De laatste voorbereiding is misschien de belangrijkste.

Bepaal:

• wie nieuwe policies mag maken;
• wie wijzigingen goedkeurt;
• hoe wordt getest;
• hoe wordt gedocumenteerd;
• hoe wordt uitgerold;
• hoe rollback werkt;
• hoe periodieke reviews plaatsvinden.

Een eenvoudig model kan zijn:

Requirement

↓

Design

↓

Test

↓

Pilot

↓

Approval

↓

Production

↓

Monitor

Intune is krachtig omdat één wijziging snel naar duizenden endpoints kan worden uitgerold.

Precies daarom moet change control vóór productie bestaan.

---

Een aanbevolen tenantstructuur

Een overzichtelijke Intune-tenant zou conceptueel bijvoorbeeld kunnen bestaan uit:

Governance

• Platform ownership
• RBAC
• Naming conventions
• Change management

↓

Identity

• Entra ID
• Administrator security
• Conditional Access

↓

Enrollment

• Windows
• Apple
• Android
• BYOD

↓

Configuration

• Settings Catalog
• Configuration Profiles
• Security Policies

↓

Applications

• Required
• Available
• Critical
• Legacy

↓

Compliance

• Device requirements
• Compliance reporting

↓

Operations

• Monitoring
• Troubleshooting
• Support
• Health Check

Deze structuur hoeft niet letterlijk in het portal zichtbaar te zijn.

Het is een logisch beheermodel.

---

Tenantvoorbereiding voor een kleine organisatie

Een organisatie met bijvoorbeeld 30 tot 100 medewerkers hoeft geen zware enterprise-governance te bouwen.

Maar enkele basisprincipes blijven belangrijk.

Een eenvoudige tenant kan starten met:

• één Platform Owner;
• twee of drie adminrollen;
• duidelijke naming convention;
• kleine pilotgroep;
• corporate Windows devices;
• Autopilot;
• basis security;
• compliance;
• MAM voor BYOD;
• standaard changeprocedure.

Eenvoud is hier een voordeel.

---

Tenantvoorbereiding voor enterpriseomgevingen

Bij grotere organisaties worden extra onderwerpen belangrijk.

Bijvoorbeeld:

• delegated administration;
• scope tags;
• meerdere IT-teams;
• internationale ownership;
• platform standards;
• security governance;
• auditrequirements;
• lifecycle management;
• exception management;
• reporting.

Daar moet Intune worden behandeld als enterpriseplatform.

Niet als losse beheertool.

---

Maak een tenant design document

Leg de ontwerpbeslissingen vast voordat de productieconfiguratie groeit.

Een goed document bevat minimaal:

Onderwerp	Vastleggen
Ownership	Wie beheert Intune?
Licensing	Welke licenties worden gebruikt?
Identity	Entra-architectuur
Enrollment	Methoden per platform
Naming	Naamgevingsstandaard
Groups	Groepsstrategie
RBAC	Administratorrollen
Policies	Policy design
Applications	Deploymentmodel
BYOD	MDM/MAM-strategie
Security	Securitybaselines
Compliance	Requirements
Rollout	Deployment rings
Operations	Support en monitoring
Governance	Change management

Dit document wordt later de basis voor beheer en audits.

---

Controleer afhankelijkheden vóórdat u Intune activeert

Een technische setting kan gevolgen hebben buiten Intune.

Bijvoorbeeld:

Compliance

kan Conditional Access beïnvloeden.

Conditional Access

kan toegang tot Microsoft 365 blokkeren.

Device configuration

kan legacy applications beïnvloeden.

BitLocker

kan recoveryprocessen raken.

Kijk daarom bij iedere belangrijke instelling naar:

Wat kan hierdoor elders veranderen?

---

Maak eerst een baseline, daarna uitzonderingen

Ontwerp een standaardwerkplek.

Bijvoorbeeld:

Corporate Windows Baseline

met:

• security;
• OneDrive;
• browser;
• Microsoft 365 Apps;
• updates;
• compliance.

Daarna mogen uitzonderingen ontstaan.

Niet andersom.

Wanneer iedere afdeling vanaf dag één een eigen configuratie krijgt, ontstaat direct fragmentatie.

---

Standaardisatie is belangrijker dan maximale flexibiliteit

Veel organisaties willen iedere gebruiker exact de gewenste configuratie geven.

Technisch kan dat vaak.

Operationeel is het duur.

Iedere extra variant betekent:

• extra policy;
• extra assignment;
• extra testing;
• extra support;
• extra troubleshooting.

Gebruik daarom als ontwerpprincipe:

standaardiseer waar mogelijk en maak uitzonderingen alleen waar noodzakelijk.

---

Test tenantdesign vóór productie

Een tenant design document is pas waardevol wanneer het wordt gevalideerd.

Maak enkele representatieve scenario’s.

Bijvoorbeeld:

Scenario 1 — Nieuwe medewerker

Nieuwe medewerker ontvangt laptop.

Kan deze volledig via Autopilot worden ingericht?

Scenario 2 — Privételefoon

Gebruiker wil Outlook gebruiken.

Wordt zakelijke data correct beschermd?

Scenario 3 — Non-compliant device

Device voldoet niet aan securityrequirements.

Wat gebeurt er?

Scenario 4 — Servicedesk

Gebruiker heeft probleem met applicatie.

Heeft servicedesk voldoende rechten om te helpen zonder volledige adminrechten?

Scenario 5 — Medewerker uit dienst

Wat gebeurt er met:

• account;
• device;
• zakelijke data;
• apps?

Door scenario’s te testen ontdekt u ontbrekende ontwerpbeslissingen.

---

Veelgemaakte fout 1: beginnen met policies

Dit is waarschijnlijk de meest voorkomende fout.

Een beheerder opent Intune en denkt:

Laten we BitLocker, OneDrive en Defender configureren.

Maar zonder ontwerp ontstaan vervolgens vragen over:

• targeting;
• exclusions;
• naming;
• ownership;
• testing.

Ontwerp eerst.

Configureer daarna.

---

Veelgemaakte fout 2: iedereen Intune Administrator maken

Dit lijkt gemakkelijk.

Maar het creëert:

• securityrisico;
• onduidelijke accountability;
• ongecontroleerde wijzigingen.

Gebruik RBAC.

---

Veelgemaakte fout 3: iedere behoefte oplossen met een nieuwe groep

Groepen stapelen snel op.

Maak daarom eerst een groepsstrategie.

---

Veelgemaakte fout 4: geen verschil maken tussen corporate en personal

Dat veroorzaakt problemen met:

• privacy;
• enrollment;
• wipe;
• policy scope.

Definieer ownership vooraf.

---

Veelgemaakte fout 5: geen pilotstructuur maken

Wanneer alle assignments direct naar “All Users” of “All Devices” gaan, is controlled rollout moeilijk.

Maak pilotgroepen voordat de eerste policies worden gebouwd.

---

Veelgemaakte fout 6: alles naar All Users sturen

All Users en All Devices kunnen nuttig zijn.

Maar gebruik ze bewust.

Vraag:

Moet werkelijk iedere gebruiker of ieder device deze configuratie krijgen?

Bij securitybaselines kan brede targeting logisch zijn.

Bij gespecialiseerde settings vaak niet.

---

Veelgemaakte fout 7: geen changeproces

Een Intune-admin kan snel iets aanpassen.

Maar snelheid zonder governance verhoogt risico.

Gebruik minimaal:

test → pilot → productie.

---

Veelgemaakte fout 8: testtenant en productietenant laten verschillen

Een testomgeving die totaal anders is ingericht dan productie levert beperkte zekerheid.

Test vooral dezelfde architectuur en deploymentlogica die later productief wordt gebruikt.

---

Veelgemaakte fout 9: geen documentatie

Een tenant kan er na zes maanden totaal anders uitzien dan bij go-live.

Zonder documentatie weet niemand meer waarom policies of exclusions bestaan.

---

Veelgemaakte fout 10: tenantvoorbereiding behandelen als eenmalige activiteit

Governance blijft nodig.

Nieuwe:

• capabilities;
• administrators;
• apps;
• securityrequirements;
• devices;

komen erbij.

Tenantdesign moet daarom periodiek worden herzien.

---

Intune tenant preparation checklist

Voor productie moet u minimaal kunnen bevestigen dat:

• productietenant is bepaald;
• bestaande configuratie is geïnventariseerd;
• licensing is gecontroleerd;
• Platform Owner is aangewezen;
• administratorrollen zijn ontworpen;
• privileged accounts zijn beschermd;
• RBAC is ingericht;
• naming convention is vastgelegd;
• groepsstrategie is ontworpen;
• exclusions worden beheerd;
• targetingprincipes zijn bepaald;
• enrollment restrictions zijn beoordeeld;
• corporate/personal ownership is bepaald;
• BYOD-strategie is vastgelegd;
• enrollment per platform is ontworpen;
• deployment rings zijn aangemaakt;
• policy design rules zijn vastgelegd;
• application model is bepaald;
• governance is ingericht;
• change management is gedocumenteerd.

---

Wanneer is een Intune tenant klaar voor de implementatie?

Niet wanneer alle configuraties al bestaan.

Een tenant is voorbereid wanneer u voordat u gaat bouwen antwoord kunt geven op vragen zoals:

Wie beheert het platform?

Wie mag wijzigingen maken?

Welke apparaten gaan we beheren?

Hoe worden ze enrolled?

Welke gebruikers krijgen welke policies?

Hoe testen we wijzigingen?

Hoe beheren we uitzonderingen?

Wat gebeurt er wanneer iets fout gaat?

Als deze antwoorden ontbreken, is de tenant nog niet echt implementatieklaar.

---

Veelgestelde vragen

Wat moet u configureren voordat u Intune implementeert?

Begin met tenantinventarisatie, licensing, administratorrollen, RBAC, groups, naming conventions, enrollmentstrategie, BYOD, deployment rings en governance.

Moet u eerst alle policies ontwerpen?

Niet noodzakelijk tot op iedere individuele setting, maar de policyarchitectuur en verantwoordelijkheden moeten wel duidelijk zijn voordat grootschalige configuratie begint.

Heeft u een testtenant nodig?

Dat hangt af van de organisatie en complexiteit. Minimaal moeten gecontroleerde test- en pilotgroepen beschikbaar zijn voordat productieassignments worden gemaakt.

Wat is de belangrijkste Intune-voorbereiding?

Een combinatie van heldere ownership, goede targeting, least privilege en een gecontroleerd rolloutproces.

Moet een kleine organisatie RBAC gebruiken?

Ja, maar het model kan eenvoudig zijn. Het principe blijft dat medewerkers niet meer privileges krijgen dan noodzakelijk.

Kunnen we direct All Users gebruiken?

Dat kan voor specifieke breed geldende configuraties, maar brede assignments moeten bewust en gecontroleerd worden gebruikt.

Hoe lang duurt tenantvoorbereiding?

Dat hangt vooral af van bestaande complexiteit. Een kleine cloudomgeving kan relatief snel worden voorbereid, terwijl een enterpriseomgeving met legacy, meerdere teams en complexe securityrequirements aanzienlijk meer ontwerpwerk vraagt.

---

Conclusie

Een professionele Microsoft Intune-implementatie begint met een professioneel voorbereide tenant.

De beste volgorde is:

Inventory

↓

Licensing

↓

Ownership

↓

RBAC

↓

Naming

↓

Groups

↓

Enrollment

↓

Targeting

↓

Policy Design

↓

Pilot

↓

Governance

Pas daarna begint de grootschalige technische configuratie.

De belangrijkste ontwerpregel blijft:

bouw eerst het beheermodel en daarna de policies.

Daarmee voorkomt u dat Intune verandert in een verzameling losse configuration profiles, applicaties, groups en uitzonderingen.

Een goed voorbereide tenant is:

duidelijk, veilig, voorspelbaar, testbaar en schaalbaar.

---

Wilt u uw Intune tenant laten beoordelen vóór de implementatie?

Heeft uw organisatie Microsoft 365 al ingericht en wilt u bepalen of de tenant klaar is voor Microsoft Intune?

Of twijfelt u over RBAC, groups, enrollment, BYOD, naming conventions, Conditional Access of de beste tenantstructuur?

Stel uw Intune-vraag. Uw eerste vraag is gratis.

Beschrijf kort uw huidige Microsoft 365-omgeving, hoeveel gebruikers en apparaten u beheert en waarover u twijfelt. Wij bekijken uw vraag en geven een eerste praktisch advies over mogelijke risico’s en vervolgstappen.

Eerste inhoudelijke beoordeling gratis. Geen verplichting tot vervolgopdracht.

Stel gratis uw eerste Intune-vraag →

---

SEO-informatie

SEO title: Microsoft Intune tenant voorbereiden: 20 belangrijke stappen

Slug: /intune-tenant-voorbereiden/

Meta description: Microsoft Intune implementeren? Bereid uw tenant goed voor met deze 20 stappen voor licensing, RBAC, groups, enrollment, BYOD, policies en governance.

Primair keyword: Intune tenant voorbereiden

Secundaire keywords: Microsoft Intune tenant voorbereiden, Intune tenant inrichting, Intune voorbereiding, Intune implementatie, Intune RBAC, Intune groepen, Intune enrollment, Intune governance