Microsoft Intune implementeren in een bestaande Microsoft 365-omgeving lijkt op het eerste gezicht relatief eenvoudig.
De tenant bestaat al.
Gebruikers hebben al Microsoft 365-accounts.
Microsoft Entra ID is al in gebruik.
Exchange Online, Teams, SharePoint en OneDrive zijn mogelijk al actief.
Toch betekent dit niet dat Intune zonder voorbereiding kan worden toegevoegd.
Juist in bestaande omgevingen zijn er vaak historische instellingen, bestaande security policies, oude apparaten, legacy-applicaties, verschillende licenties en uitzonderingen die invloed hebben op de implementatie.
De belangrijkste vraag is daarom niet:
Kunnen we Intune technisch activeren?
Maar:
Is onze bestaande Microsoft 365-omgeving klaar voor modern endpointbeheer?
In dit artikel bespreken we welke onderdelen u eerst moet controleren voordat u Microsoft Intune in een bestaande Microsoft 365-tenant implementeert.
Waarom bestaande Microsoft 365-omgevingen extra aandacht vragen
Een nieuwe tenant heeft weinig historie.
Een bestaande tenant heeft dat wel.
Er kunnen al jaren wijzigingen zijn doorgevoerd door verschillende beheerders, leveranciers en projecten.
Daardoor kunnen bijvoorbeeld de volgende situaties bestaan:
- oude groepen;
- ongebruikte administratoraccounts;
- verschillende licentietypen;
- bestaande Conditional Access policies;
- MFA-configuraties;
- legacy authentication;
- synchronisatie met lokale Active Directory;
- bestaande mobiele device policies;
- handmatige uitzonderingen;
- securityinstellingen zonder duidelijke eigenaar.
Intune wordt onderdeel van dit bestaande landschap.
Daarom moet u eerst begrijpen wat er al is.
Begin met een Microsoft 365 tenant assessment
Voordat u Intune configureert, is een compacte tenant assessment verstandig.
Onderzoek minimaal deze domeinen:
| Domein | Wat controleren? |
|---|---|
| Identity | Entra ID, users, groups, authentication |
| Licensing | Intune en security-entitlements |
| Devices | Bestaande Windows, macOS, iOS en Android |
| Enrollment | Bestaand MDM/MAM-beheer |
| Applications | Microsoft 365 en business apps |
| Security | MFA, Conditional Access, Defender |
| Administration | Rollen en privileged accounts |
| On-premises | Active Directory, GPO, ConfigMgr |
| Network | VPN, proxy, internettoegang |
| Governance | Ownership, change en exceptions |
Deze inventarisatie vormt de basis van het implementatieontwerp.
Controle 1 — Welke Microsoft 365-licenties zijn aanwezig?
Controleer eerst welke licenties gebruikers daadwerkelijk hebben.
Niet iedere gebruiker hoeft automatisch dezelfde licentie te hebben.
Een omgeving kan bijvoorbeeld bestaan uit meerdere combinaties van:
- Microsoft 365 Business-licenties;
- Microsoft 365 Enterprise-licenties;
- Office 365-licenties;
- standalone Intune;
- aanvullende securitylicenties.
Daarom moet u per gebruikersgroep controleren of de benodigde endpoint-, identity- en securityfunctionaliteit aanwezig is.
De vraag is niet alleen:
Hebben we Intune?
Maar ook:
Hebben de juiste gebruikers de juiste licenties voor het ontwerp dat we willen implementeren?
Controle 2 — Wie heeft welke administratorrechten?
Een bestaande tenant kan door de jaren heen veel administratoraccounts hebben verzameld.
Controleer daarom:
- Global Administrators;
- Intune Administrators;
- Security Administrators;
- Conditional Access Administrators;
- Helpdeskrollen;
- externe leverancieraccounts;
- oude beheeraccounts.
Verwijder of beperk rechten die niet langer nodig zijn.
Gebruik least privilege als uitgangspunt.
Een Intune-project is een goed moment om privileged access opnieuw te beoordelen.
Controle 3 — Zijn er oude beheeraccounts?
Oude accounts vormen een onnodig risico.
Controleer bijvoorbeeld:
- accounts van voormalige medewerkers;
- leverancieraccounts;
- tijdelijke projectaccounts;
- testadministrators;
- accounts zonder duidelijke eigenaar.
Vraag per account:
Is dit account nog nodig?
Wie is eigenaar?
Welke rol heeft het?
Wanneer is het voor het laatst gebruikt?
Een beheeraccount zonder duidelijke functie hoort niet onbeperkt actief te blijven.
Controle 4 — Hoe is Microsoft Entra ID ingericht?
Intune is sterk afhankelijk van identity.
Controleer daarom hoe Entra ID momenteel wordt gebruikt.
Denk aan:
- cloud-only users;
- gesynchroniseerde gebruikers;
- dynamic groups;
- security groups;
- Microsoft 365 groups;
- administrative units;
- device identities.
Een onduidelijke identityarchitectuur maakt Intune-targeting en access control later ingewikkelder.
Controle 5 — Is er nog lokale Active Directory?
Veel bestaande Microsoft 365-omgevingen gebruiken nog Active Directory Domain Services.
Controleer:
- hoeveel gebruikers worden gesynchroniseerd;
- welke devices domain joined zijn;
- welke applicaties afhankelijk zijn van AD;
- welke GPO’s actief zijn;
- welke authenticatie nog on-premises plaatsvindt.
Dit bepaalt of een cloud-native Intune-model direct mogelijk is.
Controle 6 — Hoe verloopt identity synchronisatie?
Controleer hoe gebruikers en objecten vanuit on-premises naar Microsoft Entra ID worden gesynchroniseerd.
Belangrijk is dat u weet welke directory de authoritative source is.
Als u bijvoorbeeld gebruikersattributes of groepen wilt gebruiken voor Intune assignments, moet duidelijk zijn waar deze worden beheerd.
Een onduidelijke synchronisatiestructuur kan later leiden tot onverwacht gedrag.
Controle 7 — Welke devices bestaan al in Entra ID?
Bekijk de bestaande deviceobjecten.
U kunt onder andere tegenkomen:
- Microsoft Entra joined;
- Microsoft Entra registered;
- Hybrid Microsoft Entra joined;
- oude of dubbele objects;
- devices die al lang niet meer actief zijn.
Maak duidelijk welke device states nog gewenst zijn.
Controle 8 — Zijn er stale devices?
Bestaande tenants bevatten vaak oude deviceobjecten.
Bijvoorbeeld laptops die:
- vervangen zijn;
- opnieuw geïnstalleerd zijn;
- van voormalige medewerkers waren;
- jaren niet zijn gebruikt.
Stale devices vervuilen reporting, targeting en troubleshooting.
Maak daarom een cleanupstrategie.
Verwijder niet blind.
Controleer eerst impact, ownership en eventuele afhankelijkheden.
Controle 9 — Wordt er al een andere MDM-oplossing gebruikt?
Intune wordt soms geïmplementeerd terwijl een andere MDM-tool nog actief is.
Denk aan:
- VMware Workspace ONE;
- MobileIron/Ivanti;
- Jamf;
- andere endpointmanagementsoftware.
Bepaal dan:
Welke devices zitten waar?
Wanneer vindt migratie plaats?
Kunnen systemen tijdelijk naast elkaar bestaan?
Welke tool is leidend tijdens overgang?
Zonder migratieplan kan dubbel beheer ontstaan.
Controle 10 — Is Microsoft Intune al gedeeltelijk gebruikt?
Soms is Intune technisch al actief zonder formeel ontwerp.
Er kunnen bijvoorbeeld al bestaan:
- een paar configuration profiles;
- oude compliance policies;
- testgroepen;
- enkele mobiele devices;
- Company Portal deployments;
- testapps.
Beoordeel deze configuratie voordat u verder bouwt.
Vraag per object:
Gebruiken?
Aanpassen?
Migreren?
Verwijderen?
Controle 11 — Welke enrollmentinstellingen bestaan al?
Controleer of enrollment reeds is ingericht.
Denk aan:
- MDM user scope;
- enrollment restrictions;
- platform restrictions;
- device limits;
- corporate device identifiers;
- enrollment device platform policies.
Een oude testconfiguratie kan een nieuwe rollout onverwacht blokkeren.
Controle 12 — Zijn persoonlijke devices toegestaan?
Controleer het huidige beleid rond BYOD.
Worden privételefoons momenteel gebruikt voor:
- Outlook;
- Teams;
- OneDrive;
- SharePoint;
- bedrijfsapps?
Bepaal vervolgens welk toekomstmodel past.
Bijvoorbeeld:
Corporate devices → MDM
Personal devices → MAM
Of:
Geen personal device access
De keuze moet expliciet worden gemaakt.
Controle 13 — Welke Conditional Access policies bestaan?
Dit is één van de belangrijkste controles.
Bestaande Conditional Access policies kunnen directe invloed hebben op:
- enrollment;
- Company Portal;
- device registration;
- Microsoft 365 access;
- MFA;
- compliant device requirements.
Documenteer daarom alle bestaande policies.
Leg vast:
- doelgroep;
- cloud apps;
- conditions;
- grant controls;
- exclusions;
- status.
Controle 14 — Bestaan er overlappingen in Conditional Access?
In oudere tenants kunnen meerdere policies hetzelfde proberen af te dwingen.
Bijvoorbeeld:
Policy A vereist MFA.
Policy B vereist MFA en compliant device.
Policy C geldt alleen buiten kantoor.
Individueel kunnen deze logisch lijken.
Samen kunnen ze onverwacht gedrag veroorzaken.
Analyseer daarom de gecombineerde werking.
Controle 15 — Zijn emergency access accounts ingericht?
Voordat u strengere access policies implementeert, moet u weten hoe de organisatie handelt wanneer normale administratoraccess wordt geblokkeerd.
Een emergency-accessproces moet:
- bewust zijn ingericht;
- beperkt worden gebruikt;
- gecontroleerd worden;
- getest worden.
Activeer geen brede Conditional Access-handhaving zonder recoveryscenario.
Controle 16 — Hoe wordt MFA momenteel gebruikt?
Controleer:
- welke gebruikers MFA gebruiken;
- welke methoden zijn toegestaan;
- hoe administratoraccounts zijn beschermd;
- of legacy MFA-configuraties bestaan;
- of uitzonderingen actief zijn.
Een Intune-implementatie en Conditional Access-project raken identity security vrijwel altijd.
Controle 17 — Bestaat legacy authentication nog?
Legacy authentication kan niet passen bij een modern securitymodel.
Controleer daarom of oude protocollen of applicaties nog afhankelijk zijn van verouderde authentication methods.
Wanneer legacy afhankelijkheden bestaan, moet u deze eerst begrijpen voordat access policies worden aangescherpt.
Controle 18 — Welke Microsoft Defender-functionaliteit wordt al gebruikt?
Controleer welke securitycomponenten al actief zijn.
Denk aan:
- Defender Antivirus;
- Defender for Endpoint;
- firewall policies;
- attack surface reduction;
- web protection;
- endpoint detection.
Voorkom dat dezelfde instellingen straks onafhankelijk door meerdere teams worden geconfigureerd.
Controle 19 — Wie is eigenaar van endpoint security?
Securityinstellingen kunnen worden beheerd door:
- Security Team;
- Endpoint Team;
- externe MSP;
- Microsoft 365 Administrator.
Wanneer ownership onduidelijk is, ontstaat overlap.
Leg daarom vast wie verantwoordelijk is voor iedere securitydomein.
Controle 20 — Welke Group Policies bestaan?
Wanneer Windows devices nog domain joined zijn, inventariseer Group Policy.
Maak geen plan om alle GPO’s één-op-één naar Intune te migreren.
Classificeer ze bijvoorbeeld als:
| Categorie | Actie |
|---|---|
| Keep | Requirement blijft |
| Replace | Via Intune vervangen |
| Redesign | Moderne oplossing nodig |
| Remove | Niet meer relevant |
Dit voorkomt dat historische configuratiekluwen naar de cloud wordt gekopieerd.
Controle 21 — Wordt Configuration Manager gebruikt?
Als Microsoft Configuration Manager aanwezig is, bepaal welke workloads daar nog worden beheerd.
Denk aan:
- applications;
- compliance;
- Windows Updates;
- endpoint protection;
- device configuration.
Bepaal vervolgens of co-management of een gefaseerde migratie nodig is.
Controle 22 — Hoe worden Windows devices nu geïnstalleerd?
Inventariseer het huidige provisioningproces.
Bijvoorbeeld:
Image
↓
Domain Join
↓
GPO
↓
Software installation
↓
VPN
↓
User handover
Vergelijk dit met de gewenste toekomstige keten:
Windows Autopilot
↓
Entra Join
↓
Intune
↓
Apps
↓
Security
↓
User productive
Dit verschil bepaalt een belangrijk deel van het migratiewerk.
Controle 23 — Zijn hardwareleveranciers geschikt voor Autopilot?
Wanneer u Windows Autopilot wilt inzetten, controleer dan het procurementproces.
Vraag onder andere:
- kan de leverancier devices registreren;
- worden juiste identifiers aangeleverd;
- kunnen devices rechtstreeks naar gebruikers;
- is het hardwareportfolio voldoende gestandaardiseerd?
Autopilot is niet alleen een technische configuratie.
Ook procurement maakt deel uit van de keten.
Controle 24 — Welke applicaties zijn bedrijfskritiek?
Maak een volledige applicatie-inventaris.
Classificeer minimaal:
Critical
Required
Optional
Legacy
Retire
Identificeer ook:
- Win32-apps;
- Office add-ins;
- VPN clients;
- printersoftware;
- securitytools;
- businesssoftware.
Applicaties bepalen vaak een groot deel van de implementatiecomplexiteit.
Controle 25 — Welke applicaties vereisen local admin?
Legacysoftware kan local administrator rights nodig hebben.
Breng dit vooraf in kaart.
Een Intune-implementatie is een kans om permanent local admingebruik kritisch te beoordelen.
Vraag:
Is local admin werkelijk technisch noodzakelijk, of bestaat deze configuratie alleen uit historische gewoonte?
Controle 26 — Hoe worden Microsoft 365 Apps beheerd?
Controleer hoe Office momenteel wordt geïnstalleerd en bijgewerkt.
Bijvoorbeeld via:
- handmatige installatie;
- Configuration Manager;
- bestaande deployment tooling;
- Microsoft 365 Apps deployment;
- andere managementsoftware.
Bepaal welk model voortaan leidend wordt.
Controle 27 — Hoe is OneDrive ingericht?
OneDrive is vaak een belangrijk onderdeel van de moderne werkplek.
Controleer bijvoorbeeld:
- Known Folder Move;
- Files On-Demand;
- syncinstellingen;
- tenant restrictions;
- huidige gebruikersadoptie.
Een goede OneDrive-configuratie kan lokale afhankelijkheid verminderen.
Controle 28 — Hoe worden browsers beheerd?
Chrome en Edge bevatten vaak veel bestaande policies.
Controleer:
- homepage;
- extensions;
- security;
- downloads;
- sign-in;
- bookmarks;
- password management.
Voorkom dat oude GPO’s en nieuwe Intune policies tegelijk dezelfde browserinstellingen configureren.
Controle 29 — Hoe worden Windows Updates beheerd?
Mogelijke bestaande modellen zijn:
- WSUS;
- Configuration Manager;
- handmatig;
- Windows Update for Business;
- externe patchtool.
Bepaal welke component leidend moet worden.
Maak ook onderscheid tussen:
- quality updates;
- feature updates;
- drivers.
Controle 30 — Hoe worden third-party applicaties bijgewerkt?
Windows Update lost niet het volledige patchprobleem op.
Controleer hoe applicaties zoals browsers, PDF-tools, VPN clients en businesssoftware worden bijgewerkt.
Dit moet onderdeel zijn van application lifecycle management.
Controle 31 — Hoe is VPN ingericht?
Cloudmanagement vermindert afhankelijkheid van VPN, maar veel organisaties hebben VPN nog nodig.
Controleer welke toepassingen afhankelijk zijn van:
- fileservers;
- databases;
- intranet;
- legacyapplicaties;
- beheerinterfaces.
Test Intune in combinatie met het bestaande VPN-model.
Controle 32 — Bestaan er proxy- of firewallbeperkingen?
Intune en andere Microsoft cloudservices vereisen betrouwbare internetconnectiviteit.
Controleer of:
- proxyinstellingen invloed hebben;
- SSL inspection problemen veroorzaakt;
- firewallregels cloudconnectiviteit beperken;
- remote users anders worden behandeld.
Een technisch correcte Intune-configuratie kan falen wanneer netwerktoegang niet goed is ingericht.
Controle 33 — Hoe worden printers beheerd?
Printing wordt vaak laat ontdekt.
Inventariseer:
- printservers;
- lokale printers;
- labelprinters;
- multifunctionals;
- specialistische drivers.
Bepaal hoe printing past in het toekomstige werkplekmodel.
Controle 34 — Zijn er speciale peripherals?
Denk aan:
- smartcards;
- scanners;
- barcodelezers;
- USB-apparatuur;
- docks;
- certificaatlezers.
Neem deze mee in de pilot.
Controle 35 — Welke macOS-, iOS- en Android-devices bestaan?
Intune is niet alleen Windows-management.
Controleer ook:
- Apple devices;
- Android devices;
- ownership;
- bestaande managementtools;
- enrollmentmethode;
- apps.
Dit bepaalt of de eerste implementatiefase Windows-only kan zijn of dat meerdere platforms tegelijk nodig zijn.
Controle 36 — Is Apple Business Manager al ingericht?
Wanneer corporate Apple devices worden beheerd, controleer dan de bestaande Apple-integratie.
Bepaal ook wie verantwoordelijk is voor:
- Apple Business Manager;
- tokens;
- apps;
- device assignments;
- lifecycle.
Controle 37 — Is Android Enterprise al in gebruik?
Controleer welk Android-managementmodel wordt gebruikt of gewenst is.
Verschillende device ownership-scenario’s kunnen verschillende enrollmentmodellen vereisen.
Leg daarom eerst de businessrequirements vast.
Controle 38 — Hoe verloopt onboarding?
Documenteer het huidige proces van nieuwe medewerkers.
Bijvoorbeeld:
HR meldt medewerker aan
↓
Account aangemaakt
↓
Laptop besteld
↓
IT installeert
↓
Apps handmatig toegevoegd
↓
Medewerker begint
Maak vervolgens het gewenste proces.
Bijvoorbeeld:
HR-trigger
↓
Account + groups
↓
Autopilot device
↓
Automatic apps/policies
↓
User productive
Dit is vaak één van de grootste businessvoordelen van Intune.
Controle 39 — Hoe verloopt offboarding?
Offboarding is minstens zo belangrijk als onboarding.
Controleer wat gebeurt met:
- account;
- devices;
- sessions;
- corporate data;
- mobiele apps;
- BYOD;
- BitLocker recovery;
- hardware.
Intune moet onderdeel worden van het joiner-mover-leaverproces.
Controle 40 — Welke servicedeskprocessen bestaan?
Intune verandert troubleshooting.
Controleer of de servicedesk weet hoe men werkt met:
- Company Portal;
- sync;
- app status;
- compliance;
- device actions;
- enrollment;
- Autopilot;
- BitLocker.
Plan training voordat productie-uitrol begint.
Controle 41 — Welke monitoring bestaat al?
Sommige organisaties hebben uitgebreide monitoring, andere vrijwel niets.
Bepaal welke endpointinformatie operationeel belangrijk wordt.
Bijvoorbeeld:
- enrollment failures;
- app deployment failures;
- non-compliance;
- stale devices;
- update failures;
- securityproblemen.
Controle 42 — Welke naming conventions bestaan?
Gebruik bestaande standaarden waar die bruikbaar zijn.
Als er geen standaard is, introduceer er één vóór de build.
Denk aan namen voor:
- groups;
- policies;
- applications;
- profiles;
- update rings.
Consistente naamgeving maakt een bestaande tenant veel beter beheersbaar.
Controle 43 — Welke testgroepen bestaan?
Controleer of bestaande testgroepen bruikbaar zijn.
Wanneer deze groepen oude of onbekende memberships hebben, maak dan liever bewust nieuwe groepen.
Bijvoorbeeld:
INTUNE-RING0-IT
INTUNE-RING1-PILOT
INTUNE-RING2-EARLY
INTUNE-PRODUCTION
Controle 44 — Welke uitzonderingen bestaan?
Bestaande tenants hebben vaak allerlei uitzonderingen.
Bijvoorbeeld:
- MFA exclusions;
- Conditional Access exclusions;
- oude devices;
- privileged users;
- speciale apps;
- BYOD uitzonderingen.
Maak hiervan een centraal exception register.
Iedere uitzondering moet een:
reden
eigenaar
reviewdatum
hebben.
Controle 45 — Welke securitystandaarden gelden?
Controleer of de organisatie werkt met bijvoorbeeld:
- interne securitybaseline;
- ISO 27001;
- NIS2-gerelateerde requirements;
- sectorale normen;
- klantvereisten;
- cyberverzekeringsvoorwaarden.
Vertaal deze naar technische requirements.
Begin niet vanuit instellingen.
Begin vanuit risico en beleid.
Controle 46 — Is documentatie actueel?
Veel bestaande tenants zijn deels ongedocumenteerd.
Controleer of documentatie bestaat voor:
- tenantarchitectuur;
- administrators;
- identity;
- Conditional Access;
- security;
- applications;
- devices;
- netwerk;
- lifecycle.
Waar documentatie ontbreekt, maakt de assessmentfase deze opnieuw.
Controle 47 — Is ownership duidelijk?
Iedere Intune-component moet uiteindelijk een eigenaar hebben.
Bijvoorbeeld:
| Onderdeel | Owner |
|---|---|
| Platform | Modern Workplace |
| Identity | Identity Team |
| Endpoint Security | Security |
| Applications | App Management |
| Support | Service Desk |
| Licensing | IT/Procurement |
| Governance | Platform Owner |
Onduidelijke ownership leidt vrijwel altijd tot configuration drift.
Controle 48 — Bestaat change management?
Vraag hoe wijzigingen momenteel in Microsoft 365 worden uitgevoerd.
Worden ze:
- direct in productie gezet;
- eerst getest;
- formeel goedgekeurd;
- gedocumenteerd?
Voor Intune is minimaal een eenvoudig model verstandig:
Build
↓
Test
↓
Pilot
↓
Approve
↓
Production
↓
Monitor
Controle 49 — Is er een rollbackstrategie?
Niet iedere Intunewijziging kan met één knop volledig worden teruggedraaid.
Denk vooraf na over:
- policy rollback;
- app rollback;
- assignment removal;
- Conditional Access recovery;
- updateproblemen;
- emergency access.
Rollback moet onderdeel zijn van change design.
Controle 50 — Maak een production-readiness baseline
Na de assessment moet duidelijk zijn welke blokkades vóór implementatie worden opgelost.
Gebruik bijvoorbeeld:
| Status | Betekenis |
|---|---|
| Green | Klaar |
| Orange | Risico, maar beheersbaar |
| Red | Eerst oplossen |
Een red item kan bijvoorbeeld zijn:
- onbekende Conditional Access-configuratie;
- geen emergency access;
- kritieke legacyapp niet getest;
- licensing niet op orde;
- geen pilotgroep;
- ownership onduidelijk.
Zo wordt de tenant assessment een besluitvormingsinstrument.
Welke onderdelen hoeven niet eerst perfect te zijn?
Een bestaande omgeving hoeft niet volledig opgeschoond te zijn voordat de eerste Intune-test kan beginnen.
Dat zou projecten onnodig vertragen.
Maak onderscheid tussen:
Must fix before pilot
en
Can improve later
Voorbeeld:
Een onbekende Conditional Access-policy kan een directe pilotblocker zijn.
Een oude ongebruikte Microsoft 365 group hoeft misschien niet vóór de pilot te worden opgeschoond.
Prioriteer op risico.
Voorbeeld van een assessment-resultaat
Een organisatie kan bijvoorbeeld ontdekken:
| Bevinding | Risico | Actie |
|---|---|---|
| 8 Global Admins | Hoog | Rollen verminderen |
| Geen pilotgroep | Medium | Nieuwe pilotgroep maken |
| 4 oude CA policies | Hoog | Review uitvoeren |
| 70 stale devices | Medium | Cleanup plannen |
| Geen app inventory | Hoog | Inventarisatie |
| Geen Autopilot | Laag | Implementeren |
| GPO’s niet gedocumenteerd | Hoog | Analyse |
| BYOD onduidelijk | Medium | Policy bepalen |
Zo wordt de implementatie veel gerichter.
Welke volgorde is praktisch?
Een goede volgorde kan zijn:
Tenant Assessment
↓
Risk Remediation
↓
Target Architecture
↓
Licensing Validation
↓
Identity & Access Foundation
↓
Enrollment Foundation
↓
Configuration
↓
Applications
↓
Security
↓
Compliance
↓
Conditional Access
↓
Pilot
↓
Production
Deze volgorde voorkomt dat u later fundamenten moet herstellen.
Moet u eerst alle oude configuratie verwijderen?
Nee.
Dat kan zelfs gevaarlijk zijn.
Gebruik een gecontroleerde methode:
Discover
↓
Understand
↓
Classify
↓
Replace
↓
Validate
↓
Retire
Verwijder oude configuratie pas wanneer duidelijk is dat zij niet meer nodig is.
Wanneer is een bestaande tenant klaar voor de Intune-pilot?
Minimaal wanneer:
- licensing is gecontroleerd;
- administratorrollen duidelijk zijn;
- identitystructuur is begrepen;
- bestaande CA policies zijn beoordeeld;
- emergency access is geregeld;
- enrollmentinstellingen zijn gecontroleerd;
- applicaties zijn geïnventariseerd;
- kritieke GPO’s zijn beoordeeld;
- pilotgebruikers zijn gekozen;
- testdevices beschikbaar zijn;
- support bekend is met de pilot.
Dan kan een gecontroleerde pilot beginnen.
Veelgemaakte fouten
Intune activeren zonder tenant assessment
Hierdoor worden historische problemen pas tijdens de rollout zichtbaar.
Bestaande Conditional Access negeren
Dit kan enrollment of gebruikersaccess blokkeren.
Oude administratorrechten laten staan
Dit vergroot securityrisico.
Alle GPO’s automatisch migreren
Zo wordt legacycomplexiteit gekopieerd.
Geen applicatie-inventaris maken
Applicaties worden daardoor pas laat als blocker ontdekt.
BYOD pas tijdens productie bespreken
Dan ontstaat onduidelijkheid over privacy en security.
Geen ownership vastleggen
Niemand voelt zich dan verantwoordelijk voor lifecycle en cleanup.
Intune bovenop bestaande tools zetten zonder migratieplan
Dit leidt tot dubbel beheer.
Veelgestelde vragen
Kunnen we Intune toevoegen aan een bestaande Microsoft 365-tenant?
Ja. Dat is een zeer gebruikelijk scenario. Controleer wel eerst identity, licensing, access, devices, apps en bestaande policies.
Moeten we onze tenant eerst volledig opschonen?
Nee. Los vooral risico’s op die de implementatie of pilot kunnen blokkeren. Andere cleanup kan gefaseerd plaatsvinden.
Kunnen we Intune gebruiken terwijl Active Directory blijft bestaan?
Ja. Afhankelijk van requirements kan een hybride of overgangsmodel worden gebruikt. De gewenste eindarchitectuur moet wel bewust worden gekozen.
Moeten we bestaande Group Policies direct verwijderen?
Nee. Analyseer eerst iedere requirement en valideer de vervanging voordat u een bestaande policy retireert.
Kunnen bestaande Conditional Access policies blijven bestaan?
Ja, wanneer ze nog correct en noodzakelijk zijn. Ze moeten wel worden beoordeeld in combinatie met nieuwe Intune- en compliance-scenario’s.
Moet BYOD onderdeel zijn van de eerste fase?
Niet noodzakelijk. U kunt Windows corporate management eerst implementeren en BYOD als aparte fase behandelen.
Is een pilot noodzakelijk?
Een pilot is sterk aan te raden. Bestaande tenants hebben vaak onverwachte afhankelijkheden die alleen in realistische gebruikersscenario’s zichtbaar worden.
Conclusie
Microsoft Intune implementeren in een bestaande Microsoft 365-omgeving begint niet met het maken van policies.
Het begint met begrijpen wat er al bestaat.
Onderzoek:
Identity
Licensing
Administrators
Devices
Applications
Conditional Access
Security
Active Directory
Group Policy
Existing Management
BYOD
Operations
Maak daarna een target architecture en bepaal welke bestaande componenten moeten worden:
behouden
aangepast
vervangen
verwijderd
De belangrijkste ontwerpregel is:
bouw Intune niet bovenop onbekende bestaande complexiteit.
Maak de bestaande tenant eerst begrijpelijk.
Daarna kunt u Intune gecontroleerd toevoegen en modern endpointbeheer stap voor stap invoeren.
Wilt u weten of uw bestaande Microsoft 365-omgeving klaar is voor Intune?
Gebruikt uw organisatie Microsoft 365 al en wilt u Microsoft Intune toevoegen zonder bestaande gebruikers, devices of security policies te verstoren?
Of twijfelt u over Active Directory, Group Policy, Conditional Access, licensing, bestaande MDM-software of de juiste migratievolgorde?
Stel uw Intune-vraag. Uw eerste vraag is gratis.
Beschrijf kort uw huidige Microsoft 365-omgeving, het aantal gebruikers en devices en welke beheeroplossingen momenteel worden gebruikt. Wij geven u een eerste praktisch advies over welke onderdelen u vóór een Intune-implementatie zou moeten controleren.