Je beheert endpoints, je rolt software uit, je houdt collecties bij — maar intussen groeit de hoeveelheid data in je omgeving elke maand. Wat doe je daarmee? Steeds meer organisaties ontdekken dat de data die hun beheertooling al verzamelt, veel meer waard is dan alleen een rapportje voor de maandelijkse vergadering.
Wat SCCM eigenlijk al weet over je omgeving
Microsoft Endpoint Configuration Manager verzamelt continu gegevens. Hardware-inventaris, software-inventaris, compliance-status, deployment-resultaten, heartbeat-discovery — het staat er allemaal in. De meeste beheerders gebruiken een fractie van wat er beschikbaar is.
Dat is niet erg, want in de dagelijkse hectiek van patches uitrollen en incidenten afhandelen kom je er gewoon niet aan toe. Maar het is wel zonde. De data in je SCCM-database is een directe weerspiegeling van wat er in je infrastructuur gebeurt, tot op apparaatniveau nauwkeurig.
Neem hardware-inventaris: standaard weet SCCM welke processor in een machine zit, hoeveel RAM er is, welke schijven er draaien en wanneer de laatste keer een gebruiker inlogde. Combineer dat met deployment-data en je hebt een vrij compleet beeld van welke machines klaar zijn voor een Windows-upgrade en welke dat absoluut niet zijn.
Van ruwe data naar bruikbare inzichten
Het probleem is niet dat de data ontbreekt. Het probleem is dat ruwe SQL-tabellen niet voor iedereen leesbaar zijn. De meeste beheerders werken met de ingebouwde rapporten of met een CMPivot-query als er iets mis is. Dat is reactief, en reactief is prima — tot het niet meer genoeg is.
Power BI is hier de voor de hand liggende stap. SCCM heeft een native connector voor Power BI, en als je die eenmaal hebt ingericht, kun je dashboards bouwen die je management snapt zonder dat jij er elke keer bij hoeft te zitten uitleggen. Welk percentage van je endpoints is compliant? Hoeveel machines draaien nog op een verouderde BIOS-versie? Dat soort vragen beantwoord je dan in één oogopslag.
Wat je ook kunt doen is de data exporteren naar een data warehouse, zodat je historische trends kunt analyseren. SCCM bewaart niet eeuwig alles, zeker niet als je de database-opschoning goed hebt ingesteld. Een apart analytisch platform geeft je de ruimte om te kijken wat er drie maanden geleden speelde, zonder dat je in de productiedatabase hoeft te wroeten.
AI en automatisering: wat is er al mogelijk?
Dit is het punt waar veel beheerders sceptisch worden, en eerlijk gezegd is dat begrijpelijk. ‘AI in IT-beheer’ klinkt als een marketingterm die consultants gebruiken om een hoog dagtarief te rechtvaardigen. Maar er zijn concrete toepassingen die nu al werken, zonder dat je er een heel datateam voor nodig hebt.
Anomaliedetectie is een goed voorbeeld. Als je deployment-succespercentages over tijd bijhoudt en een model traint op wat ‘normaal’ is, dan valt het op als er ineens een piek is in gefaalde installaties. Dat kan een kapotte package zijn, een netwerkkoppeling die hapert, of een conflict met een andere applicatie. Zonder geautomatiseerde detectie merk je dat pas als de helpdesk overloopt.
Een andere toepassing is predictive maintenance voor endpoints. Op basis van hardware-data — schijfgezondheid, temperatuurmetingen, uptime-patronen — kun je voorspellen welke machines waarschijnlijk binnen drie maanden problemen gaan geven. Dat klinkt futuristisch, maar de data daarvoor zit al in je SCCM-omgeving. Je hoeft alleen maar iets te bouwen dat ernaar kijkt.
Voor organisaties die serieus aan de slag willen met data-analyse en AI-toepassingen in hun IT-landschap zijn er ook externe specialisten die daarin ondersteunen, bijvoorbeeld via platforms als https://www.aspect-ict.nl/data-ai, maar de basis leg je altijd zelf.
Collecties slimmer inrichten met data
Terug naar de dagelijkse praktijk, want wie heeft er nou niet een keer een verkeerde collection getarget en een deployment uitgerold naar een groep machines die daar helemaal niet op zat te wachten. Dat overkomt de besten.
Dynamic collections op basis van inventarisdata zijn de oplossing, maar de kwaliteit van je collections hangt direct af van de kwaliteit van je inventarisdata. Als hardware-inventaris niet consistent wordt uitgelezen — omdat clients soms offline zijn, of omdat de inventariscyclus te lang is ingesteld — dan klopt je collection-lidmaatschap niet, en dan klopt je deployment-targeting niet.
Dit is een plek waar data-analyse je helpt. Door te kijken naar de consistentie van inventarisrapportages per device kun je snel zien welke clients structureel achterlopen. Misschien is er een groep laptops die altijd buiten kantoor is en de inventariscyclus mist. Misschien is er een locatie met een slechte WAN-verbinding. Die patronen zie je niet in één rapport, maar wel als je data over tijd analyseert.
Een stap verder is het gebruik van machine learning om collection-criteria te verfijnen. Als je weet dat bepaalde hardware-combinaties historisch gezien problemen geven met een specifieke applicatie, dan kun je dat meenemen in je targeting. Dat is geen sciencefiction — het is gewoon een beslisboom op basis van historische deployment-data.
Wat je nodig hebt om dit te realiseren
Laten we eerlijk zijn: dit bouw je niet in een middag. Er zijn een paar bouwstenen die je op orde moet hebben voordat je met data-analyse en AI serieus aan de slag kunt.
- Een schone SCCM-database: rommel erin, rommel eruit. Als je discovery-methodes niet goed zijn ingesteld of je hebt duizenden verouderde device-records, dan is je data onbetrouwbaar als basis voor analyse.
- Consistente inventariscycli: zorg dat clients regelmatig rapporteren. Stel de hardware- en software-inventariscyclus in op een interval dat past bij je omgeving, en monitor welke clients structureel missen.
- Een analytisch platform: dat kan Power BI zijn, maar ook Azure Log Analytics, een eigen SQL-rapportageomgeving, of een derde platform. Het gaat erom dat je de data buiten de SCCM-console kunt analyseren zonder de productieomgeving te belasten.
- Basiskennis van SQL of KQL: je hoeft geen datawetenschapper te zijn, maar als je niet weet hoe je een eenvoudige query schrijft, dan ben je afhankelijk van anderen voor elke vraag die je hebt.
- Versiebeheer op je rapporten en queries: klinkt als overkill, maar als je eenmaal een goede query hebt gebouwd die je wekelijks gebruikt, wil je niet dat iemand er per ongeluk iets in wijzigt.
- Afspraken over datakwaliteit: wie is verantwoordelijk voor het opschonen van verouderde records? Wie controleert of de inventariscategorieën kloppen? Zonder eigenaarschap degradeert je data langzaam.
Dit is geen perfecte lijst, en je hoeft niet alles tegelijk op orde te hebben. Begin met de database-hygiëne en de inventariscycli. De rest bouw je er stap voor stap omheen.
Veelgestelde vragen over data en AI in SCCM-omgevingen
Heeft SCCM een ingebouwde koppeling met AI-tools?
Niet direct, maar via Azure Monitor en Log Analytics kun je SCCM-data koppelen aan Azure-diensten die wel AI-functionaliteit bieden. Microsoft Intune heeft verder al wat ingebouwde analytische functies, en als je een hybride omgeving hebt met co-management, kun je daar gebruik van maken. Voor pure SCCM-omgevingen is de meest toegankelijke route nog altijd een Power BI-koppeling, eventueel aangevuld met een export naar een data warehouse.
Hoe zorg ik dat mijn SCCM-data betrouwbaar genoeg is voor analyse?
Begin met een data-audit: hoeveel device-records heb je, hoeveel daarvan zijn actief, en hoeveel hebben recent inventarisdata gerapporteerd? In de meeste omgevingen is tien tot twintig procent van de records verouderd of dubbel. Ruim dat op met discovery-regels en automatische verwijdering van inactieve clients. Daarna stel je monitoring in op inventarisconsistentie, zodat je een signaal krijgt als een groep clients structureel achterblijft.
Is het verstandig om AI-modellen te bouwen op SCCM-data als de omgeving nog niet volledig is gemigreerd naar Intune?
Ja, mits je rekening houdt met de beperkingen. SCCM-data is nog steeds rijk en bruikbaar, ook in een hybride omgeving. Wat je wel moet weten is dat de datakwaliteit en het type inventarisdata verschilt tussen SCCM-beheerde en Intune-beheerde devices. Als je modellen bouwt op historische SCCM-data en die vervolgens toepast op een omgeving die deels naar Intune is gemigreerd, dan kan dat scheefheden geven. Documenteer goed welke databron je gebruikt en voor welke populatie het model geldig is. Dat klinkt formeel, maar het voorkomt dat je straks deployment-beslissingen neemt op basis van een model dat eigenlijk alleen voor on-premise clients is getraind.