In een eerdere blog keken we naar wat er nodig is om een Intune-policy goed te ontwerpen. Een duidelijke naamgeving, de juiste assignments en een gecontroleerde rollout vormen de basis. Maar daarmee is het verhaal nog niet klaar.
Want wat gebeurt er eigenlijk tussen die configuratie in de Intune-portal en het moment waarop Windows zich er daadwerkelijk naar gedraagt? Daar zit meer techniek achter dan je vanuit de portal zou verwachten.
Een policy staat in Intune. Maar staat hij ook op het device?
Stel dat je ’s ochtends een instelling aanpast. De assignment staat goed en Intune laat zien dat de policy succesvol is uitgerold. Na de lunch controleer je een laptop, maar de instelling lijkt nog niet te zijn toegepast. Is de policy fout? Waarschijnlijk niet.
“Een policy is pas goed ontworpen als je zes maanden later nog steeds begrijpt waarom hij bestaat, voor wie hij geldt en wat je ermee kunt veranderen.”
Joost Gelijsteen – Microsoft MVP Intune & Windows
Veel beheerders kennen nog het beeld dat een device ongeveer eens per acht uur contact zoekt met Intune en dan pas nieuwe instellingen ophaalt. Dat vaste moment bestaat nog steeds, maar is eigenlijk een vangnet. Bij een wijziging stuurt Intune het device tegenwoordig een pushnotificatie, vergelijkbaar met een melding op je telefoon: “kom even kijken, er is iets nieuws.”
Die pushnotificatie bevat zelf geen instellingen of apps. Hij zorgt er alleen voor dat het device eerder een sync start en ophaalt wat klaarstaat. Vaak gebeurt dat binnen een paar minuten. Het is alleen geen garantie. Het device moet online zijn, kan nog met iets anders bezig zijn, en niet elke omgeving krijgt nieuwe verbeteringen tegelijk.
Dat tijdsverschil tussen ’toegewezen’ en ‘daadwerkelijk toegepast’ blijft dus belangrijk. Niet alleen omdat je anders te snel concludeert dat een policy niet werkt, maar vooral omdat er tussen Intune en Windows nog een hele keten zit.
De weg van Intune naar Windows is niet één rechte lijn
Daar komt nog iets bij. Intune is geen simpele, razendsnelle afstandsbediening waarmee je rechtstreeks een instelling op Windows omzet. Windows gebruikt onderliggende mechanismen om configuratie te verwerken, waaronder Configuration Service Providers, oftewel CSP’s. De manier waarop een instelling uiteindelijk door Windows wordt verwerkt, is daarmee onderdeel van het verhaal. Dat wordt steeds relevanter omdat Intune inmiddels veel meer doet dan klassieke MDM-configuratie. Denk bijvoorbeeld aan Endpoint Privilege Management, Device Inventory, Device Query en real-time actions. Deze functies communiceren niet allemaal op dezelfde manier met een Windows-device. De ene functie verzamelt informatie, de andere voert een actie uit of vraagt actuele informatie op. Dat betekent ook dat je niet iedere functie op dezelfde manier kunt troubleshooten. Kortom, als iets niet werkt,
betekent dat ook dat je niet bij iedere Intune-functie op dezelfde plek naar de oorzaak zoekt. Je moet eerst begrijpen hoe de betreffende functie met het device communiceert.
Waar kijk je als iets niet werkt?
Dat is precies waar device management interessant wordt. Je kunt in de portal zien dat iets is geconfigureerd en toegewezen. Maar als een gebruiker meldt dat het device zich anders gedraagt, moet je verder kijken. Is de policy daadwerkelijk aangekomen? Is de juiste configuratie verwerkt? Wat heeft Windows ermee gedaan? Wanneer heeft het device voor het laatst contact gehad? En welk mechanisme gebruikt de betreffende Intune-functie eigenlijk om met het device te communiceren? Zonder dat technische inzicht is troubleshooting al snel een kwestie van proberen, wachten en opnieuw proberen. Met meer inzicht in de Intune-architectuur kun je veel gerichter bepalen waar je moet zoeken.
Aanvullende inhoudelijke Intune kennis nodig?
Intune wordt steeds krachtiger, maar daarmee ook complexer. Begrijpen wat er achter de schermen gebeurt, wordt daarom steeds belangrijker. De mogelijkheden zijn groot, de uitdagingen soms ook. Wil je weten wat er technisch achter jouw Intune-omgeving gebeurt en hoe je daar beter grip op krijgt? Daar gaan we bij Secure at Work graag over in gesprek.
Terug naar Blogs
