Microsoft Intune implementeren in een bestaande Microsoft 365-omgeving vraagt om een andere aanpak dan een volledig nieuwe greenfield-implementatie.

In een bestaande tenant zijn vaak al gebruikers, groepen, Microsoft Entra ID-instellingen, Conditional Access-regels, Microsoft 365 Apps, securityconfiguraties, mobiele apparaten en soms oudere beheeroplossingen aanwezig.

Daarom moet de implementatie beginnen met onderzoek.

Niet met het direct aanmaken van policies.

De centrale vraag is:

Welke bestaande configuraties, afhankelijkheden en risico’s moeten we begrijpen voordat Intune onderdeel wordt van de productieomgeving?

In dit artikel bespreken we welke onderdelen u eerst moet controleren en hoe u voorkomt dat een nieuwe Intune-configuratie conflicteert met bestaande Microsoft 365-instellingen.

Waarom een bestaande Microsoft 365-tenant extra aandacht vraagt

Een bestaande tenant bevat historie.

In de loop van de tijd kunnen bijvoorbeeld zijn ontstaan:

• oude securitygroepen;
• testaccounts;
• tijdelijke Conditional Access-policies;
• verschillende administratorrollen;
• bestaande device registrations;
• mobiele apparaten;
• MFA-configuraties;
• legacy authentication-afhankelijkheden;
• bestaande Microsoft 365 Apps-configuraties;
• oude uitzonderingen.

Sommige configuraties zijn bewust ontworpen.

Andere bestaan omdat niemand ze ooit heeft verwijderd.

Wanneer Intune zonder inventarisatie wordt toegevoegd, kunnen nieuwe instellingen onverwacht botsen met deze bestaande configuratie.

Daarom geldt:

eerst begrijpen, daarna ontwerpen, daarna wijzigen.

Begin met een tenant assessment

De eerste fase van een Intune-project in een bestaande omgeving zou een assessment moeten zijn.

Onderzoek minimaal:

Domein	Wat controleert u?
Identity	Gebruikers, accounts, authenticatie
Licensing	Beschikbare Intune- en securityrechten
Devices	Bestaande device registrations
Groups	Bestaande targetingstructuur
Conditional Access	Actieve toegangsregels
Applications	Microsoft 365 en bedrijfsapps
Security	Defender, MFA, encryption
Existing management	GPO, ConfigMgr, andere MDM
BYOD	Persoonlijke mobiele apparaten
Administration	Rollen en privileged accounts

Het doel is niet om alles meteen te wijzigen.

Het doel is om afhankelijkheden zichtbaar te maken.

Controleer eerst welke licenties aanwezig zijn

Voordat u Intune configureert, moet duidelijk zijn welke gebruikers daadwerkelijk de benodigde rechten hebben.

Controleer daarom welke Microsoft 365- en Intune-entitlements in de tenant aanwezig zijn en welke gebruikers deze toegewezen hebben gekregen.

Let niet alleen op Intune zelf.

Afhankelijk van het ontwerp kunnen ook functies rondom Microsoft Entra, Conditional Access, endpoint security en aanvullende Intune-capabilities relevant zijn.

Maak daarom een eenvoudige licentiematrix:

Gebruikersgroep	Huidige licentie	Intune beschikbaar	Extra requirement
Standard users	M365 plan X	Ja/Nee	Controleren
Managers	M365 plan Y	Ja/Nee	Controleren
Frontline	F-plan	Ja/Nee	Use case beoordelen
Contractors	Verschillend	Ja/Nee	Scope bepalen

Licensing moet vóór technische rollout duidelijk zijn.

Controleer Microsoft Entra ID

Intune is sterk afhankelijk van Microsoft Entra ID.

Analyseer daarom de bestaande identity-omgeving.

Controleer onder andere:

• user accounts;
• guest accounts;
• administrator accounts;
• Microsoft Entra joined devices;
• registered devices;
• hybrid joined devices;
• group memberships;
• dynamic groups;
• authentication methods.

Vraag daarbij:

Is de huidige identity-architectuur geschikt voor het toekomstige device management model?

Een endpointproject dat identity negeert, zal later vrijwel altijd problemen tegenkomen.

Breng administratorrollen in kaart

In oudere Microsoft 365-tenants hebben vaak meer mensen brede administratorrechten dan noodzakelijk.

Maak daarom een overzicht van:

• Global Administrators;
• Intune Administrators;
• Security Administrators;
• Conditional Access Administrators;
• Helpdeskrollen;
• overige privileged roles.

Controleer vervolgens:

Wie heeft deze rol?

Waarom?

Wordt deze nog gebruikt?

Kan deze beperkter?

Gebruik least privilege als uitgangspunt voor de toekomstige beheerorganisatie.

Controleer administratoraccounts apart

Een beheerder die zijn normale gebruikersaccount gebruikt voor alles creëert onnodig risico.

Controleer daarom of de organisatie een duidelijke privileged-accountstrategie heeft.

Denk aan:

• aparte beheeraccounts waar passend;
• sterke MFA;
• beperkte role assignment;
• geen onnodige mailbox of dagelijks gebruik;
• gecontroleerde toegang tot beheertools.

Intune geeft beheerders invloed op honderden of duizenden endpoints.

Beheeraccounts verdienen daarom extra bescherming.

Controleer bestaande groepen

Veel bestaande tenants hebben tientallen of honderden Microsoft Entra-groepen.

Voordat u nieuwe Intune-groepen maakt, moet duidelijk zijn welke bestaande groepen bruikbaar zijn.

Onderzoek:

• naamgeving;
• eigenaar;
• static versus dynamic;
• user versus device groups;
• doel;
• laatste gebruik;
• nested dependencies waar relevant.

Maak niet automatisch nieuwe groepen wanneer dezelfde doelgroep al betrouwbaar bestaat.

Maar hergebruik groepen ook niet blind.

Een groep die oorspronkelijk voor e-maildistributie is gemaakt, is niet automatisch geschikt voor securitytargeting.

Vermijd group sprawl

Een veel voorkomende fout is dat ieder Intune-object een eigen groep krijgt.

Bijvoorbeeld:

APP-Chrome

POLICY-Chrome

UPDATE-Chrome

SECURITY-Chrome

Zonder duidelijke architectuur wordt targeting snel ondoorzichtig.

Bepaal daarom eerst welke group types u nodig heeft.

Bijvoorbeeld:

Deployment rings

Platform groups

Application groups

Exception groups

Business groups

Gebruik groepen als onderdeel van architectuur, niet als tijdelijke oplossing voor iedere wijziging.

Controleer bestaande device registrations

Voordat Intune enrollment wordt geactiveerd, moet u weten welke devices al in Microsoft Entra aanwezig zijn.

U kunt bijvoorbeeld tegenkomen:

Microsoft Entra registered

Microsoft Entra joined

Hybrid Microsoft Entra joined

Onbekende oude deviceobjecten

Dubbele registrations

Analyseer:

• hoeveel devices bestaan;
• hoeveel actief zijn;
• welke ownership hebben;
• welke operating systems aanwezig zijn;
• wanneer zij voor het laatst actief waren.

Dit voorkomt verwarring tijdens onboarding naar Intune.

Zoek naar stale devices

Bestaande tenants bevatten vaak oude laptops en smartphones die niet meer in gebruik zijn.

Deze kunnen reporting en targeting vervuilen.

Maak daarom onderscheid tussen:

Active

Inactive

Unknown

Verwijder oude objecten niet zonder onderzoek, maar maak een cleanupplan.

Een schone device inventory helpt bij iedere volgende implementatiefase.

Bepaal het huidige join-model

Voor Windows moet u weten hoe devices vandaag zijn verbonden met identity.

Mogelijkheden zijn bijvoorbeeld:

Traditional Active Directory domain joined

Hybrid Microsoft Entra joined

Microsoft Entra joined

De toekomstige Intune-strategie hangt hier sterk van af.

Een cloud-native ontwerp heeft andere requirements dan een hybride omgeving met lokale Active Directory.

Controleer lokale Active Directory

Wanneer de organisatie nog Active Directory gebruikt, breng de afhankelijkheden in kaart.

Denk aan:

• computeraccounts;
• Group Policy;
• login scripts;
• printers;
• fileshares;
• certificates;
• legacy authentication;
• on-premises applications.

De vraag is niet alleen:

Kunnen we Intune gebruiken?

Maar:

Welke huidige Active Directory-functies moeten nog worden vervangen, behouden of opnieuw ontworpen?

Inventariseer Group Policy

Group Policy is een van de belangrijkste aandachtspunten bij migratie naar modern management.

Maak een overzicht van bestaande GPO’s.

Classificeer iedere relevante instelling bijvoorbeeld als:

Keep

Replace

Redesign

Remove

Kopieer GPO’s niet automatisch één-op-één naar Intune.

Een oude policy kan technisch migreerbaar zijn, maar functioneel niet meer nodig.

Controleer Configuration Manager

Gebruikt de organisatie Microsoft Configuration Manager?

Dan moet u bepalen welke rol deze omgeving blijft spelen.

Onderzoek bijvoorbeeld:

• device management;
• software deployment;
• patching;
• inventory;
• imaging;
• remote support.

Mogelijk is co-management relevant als overgangsstrategie.

Gebruik co-management echter bewust.

Niet omdat beide tools toevallig beschikbaar zijn.

Controleer andere MDM-oplossingen

Veel organisaties hebben al een andere MDM-oplossing.

Bijvoorbeeld voor:

• iOS;
• Android;
• macOS;
• Windows.

Breng in kaart:

• welke devices daar beheerd worden;
• welke policies actief zijn;
• welke apps worden uitgerold;
• hoe enrollment werkt;
• hoe unenrollment verloopt.

Een device mag niet zonder ontwerp tegelijk door conflicterende managementplatformen worden aangestuurd.

Controleer MDM authority

Een fundamenteel onderdeel is bepalen welk platform verantwoordelijk is voor device management.

Voor nieuwe of gemigreerde devices moet duidelijk zijn wanneer Intune de actieve managementautoriteit wordt.

Maak deze beslissing expliciet vóór massale enrollment.

Analyseer huidige mobiele apparaten

Controleer hoeveel iOS- en Android-devices toegang hebben tot Microsoft 365.

Classificeer deze bijvoorbeeld als:

Corporate

Personal

Unknown

Vraag daarna:

Welke devices willen we volledig beheren en welke alleen op appniveau beschermen?

Dit is de basis voor MDM versus MAM.

Controleer bestaand BYOD-gebruik

BYOD bestaat vaak al voordat er formeel beleid voor is.

Gebruikers hebben bijvoorbeeld Outlook en Teams op privételefoons geïnstalleerd.

Maak daarom eerst zichtbaar:

• hoeveel persoonlijke devices bestaan;
• welke apps gebruikt worden;
• welke bedrijfsdata toegankelijk is;
• welke bescherming nu actief is.

Pas daarna bepaalt u het toekomstige BYOD-model.

Controleer bestaande App Protection Policies

Sommige tenants gebruiken mogelijk al App Protection Policies.

Controleer dan:

• doelgroep;
• platforms;
• data transfer settings;
• PIN requirements;
• conditional launch;
• selective wipe;
• exclusions.

Maak geen tweede policy met vrijwel dezelfde instellingen zonder te begrijpen wat de bestaande policy doet.

Analyseer Conditional Access vóór Intune

Dit is een van de belangrijkste stappen.

Conditional Access kan bepalen wie toegang krijgt tot Microsoft 365.

Controleer iedere bestaande policy op:

• doelgroep;
• cloud apps;
• conditions;
• grant controls;
• session controls;
• exclusions;
• state;
• report-only status.

Maak vervolgens een overzicht.

Bijvoorbeeld:

Policy	Doelgroep	Control	Status
Require MFA	All users	MFA	On
Block legacy auth	All users	Block	On
Admin MFA	Admins	MFA	On
Device compliance	Pilot	Compliant device	Report-only

Zo ziet u welke nieuwe Intune-functionaliteit afhankelijk wordt van bestaande access policies.

Zoek naar oude Conditional Access-policies

Bestaande tenants bevatten soms:

CA-Test

CA-Test2

CA-Old

CA-Temporary

Dergelijke namen zijn een signaal dat cleanup en documentatie nodig kunnen zijn.

Verwijder echter niets alleen vanwege de naam.

Onderzoek eerst gebruik en impact.

Bescherm emergency access

Voordat strengere Conditional Access-maatregelen worden geïmplementeerd, moet de organisatie een getest emergency-accessmodel hebben.

Dit is vooral belangrijk wanneer compliant-device requirements later onderdeel worden van toegang.

Een verkeerd ingestelde combinatie van Intune compliance en Conditional Access kan anders beheerders blokkeren.

Controleer bestaande MFA-configuratie

Onderzoek hoe MFA vandaag wordt afgedwongen.

Mogelijk bestaan meerdere mechanismen naast elkaar.

Zorg dat de toekomstige architectuur een duidelijk en consistent authenticationmodel heeft.

Intune moet onderdeel worden van dat model, niet een los securityeiland.

Inventariseer Microsoft 365 Apps

Controleer hoe Microsoft 365 Apps momenteel op Windows-devices worden geïnstalleerd.

Mogelijkheden zijn bijvoorbeeld:

• handmatige installatie;
• imaging;
• Configuration Manager;
• scripts;
• andere deploymentsoftware.

Bepaal daarna of Intune deze taak gaat overnemen.

Maak een applicatie-inventaris

Naast Microsoft 365 Apps moet u weten welke bedrijfsapplicaties bestaan.

Leg bijvoorbeeld vast:

Applicatie	Owner	Criticality	Deployment nu	Toekomst
ERP Client	Operations	Critical	Manual	Intune
VPN	IT	Critical	GPO/script	Intune
PDF Tool	Business	Medium	Manual	Company Portal
Legacy App	Finance	Critical	SCCM	Analyse

Dit maakt de migratie beheersbaar.

Zoek naar legacyapplicaties

De grootste problemen tijdens moderne endpointmigratie komen vaak niet uit Intune zelf.

Ze komen uit oude applicaties.

Controleer bijvoorbeeld of software afhankelijk is van:

• local administrator;
• oude .NET-versies;
• login scripts;
• mapped drives;
• legacy browsers;
• hardcoded servernamen;
• lokale databases;
• oude drivers.

Deze dependencies moeten vóór de rollout zichtbaar zijn.

Controleer bestaande securitysoftware

Heeft de organisatie al antivirus, EDR, firewallmanagement of andere endpointsecuritysoftware?

Breng dit in kaart voordat Microsoft Defender- of Intune-securitypolicies worden geactiveerd.

Dubbele securitycontrols kunnen problemen veroorzaken.

Bepaal welke oplossing leidend wordt.

Controleer BitLocker-status

Windows-laptops kunnen al encrypted zijn.

Controleer:

• welke devices BitLocker gebruiken;
• waar recovery keys worden opgeslagen;
• hoe recovery nu werkt;
• welke encryptiepolicy geldt.

Activeer geen nieuwe BitLocker-configuratie zonder deze situatie te begrijpen.

Controleer bestaande Windows Update-strategie

Updates kunnen momenteel worden beheerd via:

• Windows Update for Business;
• Configuration Manager;
• WSUS;
• handmatige processen;
• externe patchsoftware.

Bepaal welke tool op welk moment leidend is.

Een device moet niet vanuit meerdere systemen tegenstrijdige update-instructies krijgen.

Controleer huidige Windows-versies

Maak inzichtelijk hoeveel devices nog oudere of afwijkende Windows-versies gebruiken.

Dit is relevant voor:

• compatibility;
• security;
• compliance;
• feature updates;
• application support.

Een Intune-project kan een geschikt moment zijn om OS-standardisatie te verbeteren.

Inventariseer certificaten

Controleer of endpoints afhankelijk zijn van certificaten voor bijvoorbeeld:

• Wi-Fi;
• VPN;
• authentication;
• websites;
• bedrijfsapplicaties.

Certificaatdistributie is vaak een verborgen dependency bij de overgang van traditionele managementmethoden naar Intune.

Controleer Wi-Fi-configuratie

Wordt corporate Wi-Fi momenteel uitgerold via Group Policy of scripts?

Leg vast:

• SSID;
• authentication;
• certificates;
• user/device authentication;
• network access requirements.

Test een moderne distributiemethode voordat bestaande configuratie wordt verwijderd.

Controleer VPN-afhankelijkheden

Voor remote workers kan VPN bedrijfskritisch zijn.

Analyseer:

• VPN-client;
• deployment;
• authentication;
• certificates;
• split tunneling;
• dependencies;
• updateproces.

Test deployment en connectivity via Intune vóór productie.

Controleer printers

Printers worden vaak pas laat ontdekt tijdens migratie.

Breng in kaart:

• printservers;
• lokale printers;
• cloud printing;
• drivers;
• speciale multifunctionals.

Een moderne endpointomgeving moet nog steeds praktische bedrijfsprocessen ondersteunen.

Controleer OneDrive en Known Folder Move

Veel organisaties willen lokale gebruikersdata verder cloudgericht beheren.

Controleer of OneDrive al wordt gebruikt en welke configuraties bestaan.

Onderzoek bijvoorbeeld:

• Known Folder Move;
• silent sign-in;
• sync restrictions;
• SharePoint dependencies.

Voorkom dat nieuwe Intune-policies bestaande gebruikersconfiguraties onverwacht wijzigen.

Controleer Windows Hello for Business

Windows Hello for Business kan al gedeeltelijk zijn ingericht.

Analyseer:

• huidige policies;
• gebruikerservaring;
• authenticationmodel;
• hybrid dependencies;
• enrollment.

Maak duidelijk of Windows Hello onderdeel wordt van de nieuwe baseline.

Bepaal corporate versus personal ownership

Voor ieder device moet ownership zo duidelijk mogelijk zijn.

Dit beïnvloedt onder andere:

• enrollment;
• policies;
• remote actions;
• privacy;
• support;
• offboarding.

Onjuiste ownership leidt later tot verkeerde managementbeslissingen.

Controleer enrollment restrictions

Voordat Intune breed wordt geactiveerd, bepaalt u welke devices zich überhaupt mogen aanmelden.

Denk aan:

• platforms;
• OS-versies;
• personal devices;
• device limits.

Dit voorkomt ongecontroleerde enrollment.

Controleer enrollment scope

Zorg dat niet automatisch iedere gebruiker in de tenant onderdeel wordt van een vroege Intune-test.

Gebruik gecontroleerde pilotgroepen.

Begin bijvoorbeeld met:

IT

↓

Business pilot

↓

Early production

↓

Broad production

Een bestaande tenant vraagt om gecontroleerde introductie.

Maak geen assignments direct naar iedereen

De verleiding is groot om policies naar All Users of All Devices te sturen.

Doe dit alleen wanneer de configuratie getest en daarvoor ontworpen is.

Begin bij nieuwe policies met kleine doelgroepen.

De blast radius van een fout wordt daarmee aanzienlijk kleiner.

Controleer bestaande scripts

Veel omgevingen gebruiken PowerShell-, logon- of startup-scripts.

Inventariseer:

• functie;
• eigenaar;
• trigger;
• dependencies;
• huidige noodzaak.

Sommige kunnen worden vervangen door Intune.

Andere moeten blijven bestaan.

Weer andere kunnen volledig verdwijnen.

Controleer oude serviceaccounts

Bestaande tenants bevatten soms accounts voor scripts, applicaties of beheer.

Onderzoek welke accounts nog actief nodig zijn.

Controleer:

• privileges;
• wachtwoordbeleid;
• authenticatie;
• owner.

Een Intune-project is een goed moment om oude technische schuld zichtbaar te maken.

Bepaal naming conventions vóór nieuwe objecten

Als de huidige tenant inconsistente naamgeving heeft, maak dan een nieuwe standaard voor Intune-objecten.

Bijvoorbeeld:

WIN-CORP-CONF-OneDrive

WIN-CORP-SEC-BitLocker

WIN-CORP-COMP-Standard

WIN-CORP-UPD-Pilot

Consistente naamgeving maakt toekomstige troubleshooting aanzienlijk eenvoudiger.

Bepaal een policy design standard

Spreek af hoe nieuwe policies worden gebouwd.

Een praktische standaard is:

één duidelijke functie per policy

in plaats van:

één enorme policy met alle Windows-instellingen.

Zo kunnen changes en problemen beter worden geïsoleerd.

Controleer policy-overlap

Voordat nieuwe settings worden toegevoegd, moet u weten of dezelfde instellingen al ergens worden beheerd.

Controleer mogelijke overlap tussen:

• Group Policy;
• Configuration Manager;
• Settings Catalog;
• Administrative Templates;
• Endpoint Security;
• security baselines;
• scripts.

Dubbel beheer is een veelvoorkomende bron van moeilijk te verklaren gedrag.

Maak een exception register

Bestaande omgevingen hebben vrijwel altijd uitzonderingen.

Bijvoorbeeld:

• gebruiker met legacyapp;
• device zonder TPM;
• managementaccount;
• speciale machine;
• oude Windows-versie.

Leg iedere uitzondering vast met minimaal:

Veld	Betekenis
Reason	Waarom nodig
Owner	Wie verantwoordelijk
Risk	Impact
Approval	Wie akkoord gaf
Review date	Wanneer opnieuw beoordelen
Exit plan	Hoe wordt uitzondering beëindigd

Zo wordt tijdelijke afwijking niet automatisch permanent.

Maak eerst een testgroep

Voordat u iets in productie verandert, maakt u een kleine testgroep.

Bijvoorbeeld:

INTUNE-RING0-ENGINEERING

Gebruik echte testdevices en indien nodig testaccounts.

Test hier eerst:

• enrollment;
• policies;
• apps;
• security;
• compliance.

Daarna kan een bredere pilot volgen.

Test de volledige lifecycle

Test niet alleen of een device succesvol enrolled.

Test:

Nieuw device

↓

Enrollment

↓

Configuration

↓

Applications

↓

Security

↓

Compliance

↓

Conditional Access

↓

Updates

↓

Support

↓

Retire/Wipe

Een bestaande tenant kan juist bij deze koppelingen onverwachte dependencies laten zien.

Maak een dependency map

Een nuttige oefening is om de belangrijkste afhankelijkheden visueel te documenteren.

Bijvoorbeeld:

Microsoft Entra ID

↓

Licensing

↓

Enrollment

↓

Intune

↓

Compliance

↓

Conditional Access

↓

Microsoft 365 Access

En daarnaast:

Intune

↓

Applications

↓

VPN

↓

On-premises ERP

Zo ziet u snel waar een wijziging gevolgen kan hebben.

Gebruik een risk register

Registreer vóór productie belangrijke risico’s.

Bijvoorbeeld:

Risico	Impact	Actie
Legacy VPN onbekend	Hoog	Pilot uitvoeren
Oude GPO overlap	Hoog	Analyse uitvoeren
BYOD ownership onbekend	Medium	Inventariseren
CA exclusions onduidelijk	Hoog	Review uitvoeren
App packaging ontbreekt	Medium	Packagingplan

Hiermee wordt implementatie risicogestuurd.

Controleer of documentatie bestaat

In bestaande tenants is de configuratie vaak beter bekend bij individuele beheerders dan in documentatie.

Zoek daarom bestaande documenten over:

• identity;
• Conditional Access;
• security;
• applications;
• network;
• endpointbeheer.

Controleer of deze nog overeenkomen met de werkelijke tenant.

Documentatie die drie jaar oud is, kan gevaarlijker zijn dan geen documentatie wanneer men ervan uitgaat dat ze nog klopt.

Interview beheerders

Niet alle kennis staat in portals of documenten.

Spreek daarom met:

• Microsoft 365-beheer;
• endpointbeheer;
• security;
• networking;
• servicedesk;
• application owners.

Vraag bijvoorbeeld:

Welke instelling durft niemand meer te wijzigen?

Dat soort antwoorden wijst vaak op verborgen technische schuld.

Betrek de servicedesk vóór rollout

De servicedesk weet vaak welke endpointproblemen gebruikers vandaag ervaren.

Gebruik die informatie bij het ontwerp.

Veel voorkomende bestaande tickets kunnen bijvoorbeeld gaan over:

• wachtwoorden;
• VPN;
• softwareinstallatie;
• printerproblemen;
• BitLocker;
• Windows Updates.

Een goede Intune-implementatie kan juist deze terugkerende supportlast verminderen.

Leg een baseline vast vóór verandering

Maak een nulmeting voordat u grote wijzigingen uitvoert.

Leg bijvoorbeeld vast:

• aantal devices;
• compliancebasis;
• supportvolume;
• update coverage;
• securitystatus;
• applicatieproblemen.

Na implementatie kunt u dan beoordelen of Intune daadwerkelijk verbetering heeft gebracht.

Maak een rollbackstrategie

Voor iedere significante wijziging moet vooraf duidelijk zijn hoe u kunt herstellen.

Bijvoorbeeld:

Nieuwe policy

→ probleem

→ assignment verwijderen

→ oude configuratie herstellen

→ devices synchroniseren

→ impact controleren

Rollback moet onderdeel zijn van change design, niet pas worden bedacht wanneer iets fout gaat.

Definieer production readiness

Een bestaande Microsoft 365-tenant is pas klaar voor brede Intune-uitrol wanneer minimaal duidelijk is:

• licensing;
• identity;
• device inventory;
• management ownership;
• group design;
• Conditional Access;
• application dependencies;
• security;
• enrollment;
• support;
• rollback;
• monitoring.

Technisch kunnen enrollen is niet hetzelfde als production ready zijn.

Praktisch implementatiemodel

Een bestaande Microsoft 365-omgeving kan bijvoorbeeld volgens deze volgorde naar Intune worden gebracht:

1. Discovery

Bestaande tenant begrijpen.

↓

2. Assessment

Risico’s en dependencies vaststellen.

↓

3. Target Design

Toekomstige architectuur bepalen.

↓

4. Remediation

Oude conflicten en blokkades oplossen.

↓

5. Build

Intune-configuratie maken.

↓

6. Technical Test

Kleine engineeringgroep.

↓

7. Business Pilot

Representatieve gebruikers.

↓

8. Controlled Rollout

Gefaseerde productie.

↓

9. Operational Handover

Support, monitoring en governance.

↓

10. Optimization

Oude configuraties verwijderen en verder standaardiseren.

Deze volgorde voorkomt dat Intune simpelweg bovenop bestaande technische schuld wordt geplaatst.

Wat moet u niet meteen verwijderen?

Een moderniseringsproject roept vaak de wens op om oude technologie snel uit te schakelen.

Wees voorzichtig met:

• GPO’s;
• Configuration Manager;
• VPN;
• oude deviceobjecten;
• securitysoftware;
• legacyapps;
• scripts.

Eerst migreren en testen.

Daarna verwijderen.

De juiste volgorde is:

Understand → Replace → Validate → Retire

Niet:

Delete → Discover what broke.

Checklist vóór Intune-implementatie in een bestaande tenant

• Huidige Microsoft 365-omgeving geïnventariseerd
• Licensing gecontroleerd
• Microsoft Entra ID beoordeeld
• Administratorrollen beoordeeld
• Privileged accounts beveiligd
• Bestaande groepen geïnventariseerd
• Device registrations onderzocht
• Stale devices geïdentificeerd
• Join-model bepaald
• Active Directory-dependencies geïnventariseerd
• Group Policies geïnventariseerd
• Configuration Manager onderzocht
• Andere MDM-oplossingen onderzocht
• Mobiele devices geïnventariseerd
• BYOD-gebruik onderzocht
• App Protection Policies beoordeeld
• Conditional Access volledig beoordeeld
• Emergency access gecontroleerd
• MFA-model beoordeeld
• Microsoft 365 Apps deployment onderzocht
• Applicatiecatalogus gemaakt
• Legacyapplicaties geïdentificeerd
• Securitysoftware geïnventariseerd
• BitLocker-status onderzocht
• Windows Update-model onderzocht
• Windows-versies geïnventariseerd
• Certificaatdependencies vastgelegd
• Wi-Fi en VPN onderzocht
• Printing onderzocht
• OneDrive-configuratie beoordeeld
• Windows Hello beoordeeld
• Device ownership vastgesteld
• Enrollment restrictions ontworpen
• Pilotgroepen ingericht
• Naming convention vastgelegd
• Policy design standard bepaald
• Policy overlap onderzocht
• Exception register gemaakt
• Dependency map gemaakt
• Risk register gemaakt
• Rollbackstrategie vastgelegd
• Service Desk betrokken
• Production-readiness criteria vastgesteld

Veelgemaakte fouten

Meteen policies bouwen

Zonder assessment weet u niet waarmee nieuwe instellingen kunnen conflicteren.

Bestaande Conditional Access negeren

Dit kan leiden tot onverwachte toegangsproblemen zodra compliance wordt gekoppeld.

Alle gebruikers direct enrollen

Hiermee wordt de pilotfase feitelijk overgeslagen.

GPO’s blind naar Intune kopiëren

Zo verplaatst u technische schuld.

Legacyapps onderschatten

Deze bepalen vaak het werkelijke migratierisico.

Securitysoftware dubbel configureren

Meerdere tools kunnen dezelfde Windows-component proberen te beheren.

Oude groepen zonder onderzoek hergebruiken

De doelgroep kan anders zijn dan de naam suggereert.

Geen rollback ontwerpen

Dan wordt iedere mislukte policy een incident.

Te snel oude infrastructuur verwijderen

Verwijder pas wanneer de vervangende oplossing aantoonbaar werkt.

Governance uitstellen tot na go-live

Dan ontstaat juist tijdens de rollout nieuwe technische schuld.

Wanneer is de tenant klaar om met Intune te starten?

Niet wanneer alles perfect is.

Wel wanneer u voldoende inzicht heeft om wijzigingen gecontroleerd te maken.

U moet minimaal weten:

wie u gaat beheren

welke devices u gaat beheren

welke bestaande tools actief zijn

welke apps belangrijk zijn

welke securitycontrols bestaan

welke dependencies aanwezig zijn

welke gebruikers eerst testen

hoe u terug kunt wanneer iets misgaat

Dat is een gezonde uitgangspositie voor implementatie.

Veelgestelde vragen

Kan Intune gewoon worden geactiveerd in een bestaande Microsoft 365-tenant?

Technisch kan veel snel worden geconfigureerd, maar voor productie is eerst een assessment verstandig. Bestaande identity-, security-, device- en accessconfiguraties kunnen invloed hebben op de nieuwe Intune-omgeving.

Moeten bestaande Group Policies eerst worden verwijderd?

Nee. Analyseer eerst welke settings nog nodig zijn en migreer gecontroleerd. Verwijder oude policies pas wanneer hun vervanging is gevalideerd.

Kan Intune naast Configuration Manager bestaan?

Ja, afhankelijk van het gekozen beheer- en migratiemodel. De verdeling van workloads moet wel bewust worden ontworpen.

Moeten bestaande devices opnieuw worden geïnstalleerd?

Niet noodzakelijk. Dat hangt af van de huidige joinstatus, managementmethode en gewenste eindarchitectuur.

Moeten alle bestaande groepen worden vervangen?

Nee. Hergebruik betrouwbare groepen wanneer dat logisch is, maar beoordeel doel, membership en ownership voordat u ze voor Intune-targeting inzet.

Waarom moet Conditional Access eerst worden onderzocht?

Omdat Intune compliance later direct onderdeel kan worden van toegangsbeslissingen. Een verkeerde combinatie kan gebruikers onbedoeld blokkeren.

Kunnen bestaande mobiele devices direct naar Intune?

Dat hangt af van het huidige managementmodel, ownership en platform. Maak eerst een migratie- en enrollmentstrategie.

Wat is de grootste fout bij een bestaande tenant?

Nieuwe Intune-configuratie toevoegen zonder eerst te begrijpen welke bestaande policies, managementtools en uitzonderingen al actief zijn.

Conclusie

Microsoft Intune implementeren in een bestaande Microsoft 365-omgeving begint niet in het Intune Admin Center.

Het begint met analyse.

Onderzoek eerst:

Identity

↓

Licensing

↓

Devices

↓

Groups

↓

Applications

↓

Conditional Access

↓

Security

↓

Existing Management

↓

Dependencies

↓

Support

Pas daarna bouwt u de nieuwe Intune-omgeving.

De belangrijkste ontwerpregel is:

voeg Intune niet simpelweg toe aan de bestaande complexiteit; gebruik de implementatie om die complexiteit gecontroleerd te verminderen.

Een goed assessment voorkomt dat oude technische schuld ongemerkt onderdeel wordt van het nieuwe endpointbeheer.

---

Wilt u Intune implementeren in een bestaande Microsoft 365-omgeving?

Heeft uw organisatie al Microsoft 365, Entra ID, Conditional Access, Group Policy, Configuration Manager of een andere MDM-oplossing en wilt u weten welke onderdelen u vóór Intune eerst moet controleren?

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

Beschrijf kort uw huidige omgeving, het aantal gebruikers en devices en welke beheertools momenteel actief zijn. Wij bekijken uw situatie en geven een eerste praktisch advies over de belangrijkste aandachtspunten voor uw Intune-implementatie.

Eerste inhoudelijke beoordeling gratis. Geen verplichting tot vervolgopdracht.

Stel gratis uw eerste Intune-vraag