Microsoft Intune ervaringentopic

[Blokker_1999]

Mijn laatste laptops zijn ondertussen in orde voor de secure boot cert renewal. 1 reeks die allemaal nog een BIOS update moesten hebben. Voor alles wat VM is of in het datacenter staat maak ik me minder zorgen. Secure Boot staat daar veelal zelfs gewoon uit.

[HKLM_]

Iemand hier nog veel last gehad van het Microsoft Intune MDM Device CA wat 5 mei is verlopen? Alle devices netjes automatisch het certificaat vernieuwd?

[ Voor 36% gewijzigd door HKLM_ op 21-05-2026 09:30 ]

[nextware]

HKLM_ schreef op donderdag 21 mei 2026 @ 09:27:
Iemand hier nog veel last gehad van het Microsoft Intune MDM Device CA wat 5 mei is verlopen? Alle devices netjes automatisch het certificaat vernieuwd?

Hier er geen meldingen over gekregen. Even wat devices bekeken en het certificaat wat ik zie loopt tot 2027.

[Blokker_1999]

Ik was op vakantie, maar heb niets vernomen. Dus dat lijkt ook goed gegaan te zijn.

[HKLM_]

Blokker_1999 schreef op donderdag 21 mei 2026 @ 12:03:
Ik was op vakantie, maar heb niets vernomen. Dus dat lijkt ook goed gegaan te zijn.

Het device blijft ook wel "werken" voor de gebruiker alleen je connectie met MDM gaat naar de .... leuke is dat het device nog wel de checkin date blijft rapporteren.

Als je onder all devices de colom Management Certificate Expire Date toevoegt kan je filteren op devices en wanneer hun Management Certificaat expire. Alles voor 05-05-2026 is de spreekwoordelijke sjaak.

[ Voor 5% gewijzigd door HKLM_ op 21-05-2026 14:17 ]

[Blokker_1999]

HKLM_ schreef op donderdag 21 mei 2026 @ 14:16:
[...]

Het device blijft ook wel "werken" voor de gebruiker alleen je connectie met MDM gaat naar de .... leuke is dat het device nog wel de checkin date blijft rapporteren.

Als je onder all devices de colom Management Certificate Expire Date toevoegt kan je filteren op devices en wanneer hun Management Certificaat expire. Alles voor 05-05-2026 is de spreekwoordelijke sjaak.

Toont vooral aan dat er iemand nog wat opkuiswerk heeft . Komen enkele apparaten naar boven, maar die zijn het laatst gezien vorig jaar. Zie ook 1 device dat voor het laatst in Januari gezien is en een cert heeft dat tot November goed blijft.

[DDX]

Klinkt alsof er bij jou wat mis gaat @HKLM_
Als ik bij ons kijk heb ik 3 devices (met last check in today) met expire 11/20/2026, daarna alles in verschillende data in 2027

[ Voor 7% gewijzigd door DDX op 21-05-2026 16:01 ]

[HKLM_]

DDX schreef op donderdag 21 mei 2026 @ 16:00:
Klinkt alsof er bij jou wat mis gaat @HKLM_
Als ik bij ons kijk heb ik 3 devices (met last check in today) met expire 11/20/2026, daarna alles in verschillende data in 2027

Nee hoor gaat niks mis, ik heb zelf allemaal netjes devices welke geupdate zijn. Bij een klant wel gezien dat er een aantal devices niet optijd het certificaat vernieuwd hebben maar deze stonden ook al langere tijd uit.

[Hero of Time]

Wij hebben wel een aantal apparaten met verloopdatum van afgelopen april. Die hebben als laatste een check-in gedaan in november 2025. Dat was denk ik toen ze werden opgestart en doorgeklikt door de servicedesk, sindsdien liggen ze op de plank als voorraad.

Met Secure Boot trouwens wel vervelend. Eerst was het overzicht volledig groen en een paar systemen met 'unknown' of 'not applicable'. Vandaag zag ik er 1 met 'not up to date'. Die heeft waarschijnlijk langere tijd uit gestaan en eerst als 'unknown' hebben gestaan. Hopelijk heeft 't in de relatief korte tijd dat 't aan stond toch de boel bijgewerkt.

Ook heel gek, sorteer ik op 'Status', dan zie ik een of meerdere systemen niet meer in de lijst, die ik bij sortering op naam wel zie. Verschil: op naam staat die ik mis bovenaan, bij status zou 'ie onderaan moeten staan omdat SB niet aan staat.

[ralpje]

Heeft iemand in dit topic al eens getest met een Copilot agent die (een export van) de Intune config gebruikt als basis?

Ik bedoel, er is Security Copilot maar die is vrij prijzig en ik wil eigenlijk alleen maar een agent die MS Learn met Intune documentatie én mijn huidige Intune config (die gewoon als JSON geëxporteerd is en ergens op Sharepoint of in Azure DevOps staat) om antwoorden op mijn vragen te genereren.
Maar ik heb geen zin om zelf het wiel opnieuw te vinden.

[DDX]

HKLM_ schreef op donderdag 21 mei 2026 @ 16:06:
[...]

Nee hoor gaat niks mis, ik heb zelf allemaal netjes devices welke geupdate zijn. Bij een klant wel gezien dat er een aantal devices niet optijd het certificaat vernieuwd hebben maar deze stonden ook al langere tijd uit.

Wel benieuwd wat de oorzaak dan is, je zou verwachten dat dit gewoon vanzelf moet syncen ? (zoals het bij ons ook doet)

[HKLM_]

DDX schreef op donderdag 21 mei 2026 @ 20:19:
[...]


Wel benieuwd wat de oorzaak dan is, je zou verwachten dat dit gewoon vanzelf moet syncen ? (zoals het bij ons ook doet)

Dat zeg ik het het Microsoft Intune MDM Device Certification Authority had een expire date van 5 mei 2026 en als je device hebt welke niet in staat zijn geweest het certificaat te updaten dan heb je in die lijst dus devices staan waarbij je initele sync is gebroken. Dat deze nog wel check-in doet zegt eigenlijk niet zo veel.

[DDX]

Maar waarom zou een device dat certificaat niet op tijd opgehaald kunnen hebben ?
Klinkt als een sync die niet lukt/iets wat blocked is oid.

Met mac devices heb ik gewoon 'alerting' dat we gebruikers seintje geven let op als je 2 maanden niet inlogt risico dat je reinstall moet doen.
Hebben we eerder gehad iemand die te lang niet ingelogd was en daardoor het mdm push certificaat van apple/intune niet op tijd binnen gekregen had....
Paar devices die amper gebruikt worden omdat persoon op laptop van klant werkt.
Dat zijn certificaten die jaarlijk geupdate moeten worden vanuit appel/microsoft combi. (2 stuks) en als je verlopen is heb je een reinstall nodig.

[ Voor 69% gewijzigd door DDX op 21-05-2026 21:04 ]

[HKLM_]

DDX schreef op donderdag 21 mei 2026 @ 20:59:
Maar waarom zou een device dat certificaat niet op tijd opgehaald kunnen hebben ?
Klinkt als een sync die niet lukt/iets wat blocked is oid.

Devices die te lang op de plank hebben gelegen of devices die om wat voor reden dan ook inderdaad sync issues hebben / een brakke windows installatie hebben. Of devices van medewerkers welke bijvoorbeeld langdurig met verlof zijn of ziek zijn en hun device langer als drie maanden niet aan hebben gehad.

Zijn lego opties waarom een device het intune certificaat niet tijdig kan verlengen.

[ Voor 22% gewijzigd door HKLM_ op 21-05-2026 21:03 ]

[Hero of Time]

Daar kan ik m'n servicedesk collega mooi mee om de oren slaan wanneer die een systeem dat 'ie meer dan een half jaar geleden had 'geprepped' moet resetten. Vond 't al een slecht idee om die dingen allemaal uit de doos in te richten en dan op de plank te gooien. Met een enkel on-prem AD joined apparaat heb je daar al problemen mee als het wachtwoord van het computeraccount verloopt en niet tijdig ververst. Moet je 'm ook opnieuw bij het domein aanmelden. Dit is net zo.

[HKLM_]

Waren er hier nu mensen die CIPP gebruikte?

[DDX]

Als een laptop nog niet in gebruik is, is er toch niet echt een groot probleem om te resetten ?
Als ik hier een laptop retour krijg reset ik hem maar doe verder nog geen enrollment.

[ Voor 31% gewijzigd door DDX op 21-05-2026 21:57 ]

[Quad]

HKLM_ schreef op donderdag 21 mei 2026 @ 21:47:
Waren er hier nu mensen die CIPP gebruikte?

Yes.

[HKLM_]

Quad schreef op donderdag 21 mei 2026 @ 22:44:
[...]

Yes.

Gebruik je ook de Template Library en zo ja maak je wel eens gebruik van de community versies?

[Quad]

HKLM_ schreef op vrijdag 22 mei 2026 @ 06:14:
[...]

Gebruik je ook de Template Library en zo ja maak je wel eens gebruik van de community versies?

Ja maar alleen voor onze eigen template-tenant. Community repos niet naar gekeken.

[Hero of Time]

DDX schreef op donderdag 21 mei 2026 @ 21:56:
Als een laptop nog niet in gebruik is, is er toch niet echt een groot probleem om te resetten ?
Als ik hier een laptop retour krijg reset ik hem maar doe verder nog geen enrollment.

Gaat in dit geval om een stapeltje (stuk of 10-15?) mini desktops. Volledig ingericht met basic config (zeg maar alsnog opstarten na seal, updates, drivers en firmware bijwerken) en dan weer op de plank. We hebben denk iets van 2-3 laptops klaar liggen voor gebruik, maar nog niet zo lang uit.

Wanneer iemand de laptop inlevert, schonen we het profiel op en dat is het vaak wel, omdat de opvolger relatief vlot komt en alle programmatuur er alvast op staat. We hebben tevens nog een hybrid join, dus bij een reset moet ik ook het object uit AD verwijderen, anders faalt de domain join stap want het heeft niet de rechten om een bestaand object te overschrijven.

[grimson]

Ik probeer BitLocker via Intune af te dwingen met XTS‑AES 256 + full disk encryptie, maar tijdens OOBE start Windows automatisch met BitLocker op de standaard 128‑bit used‑space‑only instellingen. Zodra de schijf encrypted is, kun je de encryptiemethode niet meer wijzigen zonder volledig te decrypten en opnieuw te encrypten. Intune meldt wel dat BitLocker actief is, maar niet met de gewenste parameters.

Dit gedrag is bekend: Encryptie start al tijdens start OOBE, maar BitLocker wordt pas volledig actief zodra de recovery key is opgeslagen. (bijv. een Entra‑ID login om Microsoft Account). Op dat moment zijn Intune‑policies nog niet binnen, waardoor Windows altijd de defaults gebruikt. Intune kan de encryptiemethode niet aanpassen op een al‑geëncrypteerde schijf.

De enige manier om dit te voorkomen lijkt te zijn dat de BitLocker‑policy vóór OOBE wordt toegepast, zodat de automatische BitLocker‑start direct de juiste waarden gebruikt. Voor zover ik kan vinden lukt dat alleen via ESP blocking mode, zodat Device Configuration policies eerst worden verwerkt. Ik ben benieuwd of iemand dit stabiel werkend heeft gekregen of andere manieren heeft om BitLocker tijdens OOBE te vertragen.

Daarnaast zoek ik argumenten om niet naar 256‑bit/full‑disk encryptie te gaan “omdat het kan”. Het levert praktisch geen extra security op, kost performance, en maakt het beheer onnodig complex. Zeker bestaande devices die al netjes met de standaard 128‑bit encrypted zijn, vereisen een decrypt‑reencrypt‑actie om compliant te worden, misschien te doen maar onnodige gezever omdat er op andere gebieden meer te halen valt dan hierover te vallen. Maargoed dat is mijn korte rant zelfs als engineer die voor het beste zou willen gaan zou ik hier pragmatisch te werk gaan. goed is goedgenoeg.

Maar met name vraag ik om ervaring, of iemand dus dit heeft toegepast en structureel dit goed zien gaan. Het blijft tenslotte Intune

[ Voor 15% gewijzigd door grimson op 23-05-2026 08:19 ]

[Hero of Time]

Bitlocker instellingen blijven raar. Wij hadden eerst full disk ipv used space. Dat kreeg in Intune een aantekening dat het niet aangeraden was, used space zou beter zijn. Setting aangepast, nieuw enrollde apparaten hadden nog steeds die aantekening dat de instelling niet de MS best-practise volgt. Wat het dan wil en hoe dat te regelen wordt natuurlijk niet gezegd bij die aantekening, dat moet je apart gaan opzoeken. Als Windows zelf al wat anders doet dan wat je hebt ingesteld en wat dan zelfs niet volgens de best practise zou zijn van MS zelf, geef ik het op en doe ik de moeite niet meer om daar aan te voldoen. Bitlocker staat aan, key is in Entra, zoek het dan ook maar uit met je advies e.d. Want waarom dagen/weken besteden aan iets dat niet gegarandeerd wordt toegepast omdat er wat anders net voor gebeurt en niet verandert kan worden?

[grimson]

Hero of Time schreef op zaterdag 23 mei 2026 @ 12:17:
Bitlocker instellingen blijven raar.... Want waarom dagen/weken besteden aan iets dat niet gegarandeerd wordt toegepast omdat er wat anders net voor gebeurt en niet verandert kan worden?

Precies dit. Ik werk sinds kort bij een MSP waar 256‑bit/full‑disk nu de standaard is, maar ik zie vooral hoe hard je jezelf daarmee in de voet schiet als je een vaste onboarding fee hanteert (of onboarding zelfs “gratis” aanbiedt bij een securitydienst).

Zodra BitLocker tijdens/na OOBE al met de Windows‑defaults begint, zit je bij 256/full‑disk meteen vast aan decrypt/reencrypt‑trajecten om compliant te worden. Dat kost bakken met tijd. Verspilde tijd is bij een MSP gewoon geld, zeker als het bij een dienst in zit.

Daarom zou ik standaard gewoon 128‑bit XTS + used‑space‑only doen, tenzij een klant expliciet 256‑bit eist en dat vooraf is meegenomen in de offerte. Eens kijken of ik dat voorzichtig kan aankaarten zonder meteen al kritisch over te komen.

[Hero of Time]

@grimson, je zou als onderdeel van de uitrol kunnen meenemen dat voordat de OOBE überhaupt kán starten, je Secure Boot uitschakelt. Dit voorkomt dat Bitlocker ingeschakeld kan worden, want het is onderdeel van de vereiste. De OOBE en enrollment loopt dan door, krijgt z'n policies met je 256 bit regel. SB daarna aan zou in theorie het juiste moeten doen voor Bitlocker.

Maar goed, ik heb 1,5 jaar geleden met een XPS 16" de standaard aanwezige SB certificaten moeten verwijderen om Bitlocker af te laten gaan, terwijl elk ander systeem dit niet nodig had om zonder tussenkomst of handmatige handelingen het aan te zetten. In Event VIewer stond er namelijk ook dat er een conflict was, met meerdere certificaten beschikbaar om mee te werken en het daardoor niets ging doen.

[grimson]

Hero of Time schreef op zaterdag 23 mei 2026 @ 14:18:
@grimson, je zou als onderdeel van de uitrol kunnen meenemen dat voordat de OOBE überhaupt kán starten, je Secure Boot uitschakelt. Dit voorkomt dat Bitlocker ingeschakeld kan worden, want het is onderdeel van de vereiste. De OOBE en enrollment loopt dan door, krijgt z'n policies met je 256 bit regel. SB daarna aan zou in theorie het juiste moeten doen voor Bitlocker.

Maar goed, ik heb 1,5 jaar geleden met een XPS 16" de standaard aanwezige SB certificaten moeten verwijderen om Bitlocker af te laten gaan, terwijl elk ander systeem dit niet nodig had om zonder tussenkomst of handmatige handelingen het aan te zetten. In Event VIewer stond er namelijk ook dat er een conflict was, met meerdere certificaten beschikbaar om mee te werken en het daardoor niets ging doen.

Dank voor het meedenken. Als je bedoelt om Secure Boot via Intune uit te schakelen: ook die policy moet dan vóór OOBE actief zijn, net als de 256‑bit/full‑disk‑instelling. Dat blijft dus hetzelfde probleem misschien?

Ik heb het net getest met een verse install van Windows 11 25H2 en het lijkt te werken, 256 wordt gebruikt als encryptie. De truc is sowieso denk ik om Autopilot‑devicegroepen te gebruiken, omdat die volgens mij al actief zijn vóórdat normale device groepen iets doen.

Wat ik heb gedaan:

• Intune‑policy aangemaakt met alleen encryption method en full disk.
• Een (All Devices) ESP‑blocking policy gemaakt: “Block device use until all apps and profiles are installed: Yes”.
• Intune policy toegewezen aan de Autopilot‑devicegroep.

Bij mijn eerste test werkt dit direct:
ESP pauzeert OOBE, en via Shift‑F10 zie ik dat manage-bde C: -status laat zien dat de schijf nog niet encrypted is.
Pas nadat de ESP‑device policies zijn toegepast, start Automatic Disk Encryption en dan meteen met XTS‑AES 256 in plaats van 128.

In theorie werkt het dus zo:

• Windows 11 wacht met ADE tot OOBE start (standaard gedrag).
• ESP in blocking‑mode houdt OOBE tegen totdat de configuratie‑policies binnen zijn.
• Daardoor gebruikt ADE bij de (door)start van OOBE meteen de juiste parameters.

Ik ga dit nog verder testen, maar de eerste resultaten zien er goed uit.

In theorie zou dus een Autopilot uitrol van een vers geïnstalleerde Windows computer (dus niet bestaande met al encrypted shizz) de juiste 256/full disk methode moeten gebruiken.

TL-DR; met een verse windows installatie zonder encryptie lijkt het mogelijk te zijn via Intune ESP/Blocking een policy toe te passen zodat ADE de juiste encryptie parameters gebruikt.

[Hero of Time]

Ik heb vandaag eens de nieuwe weergave aangezet voor systemen. Ik dacht dat het voor de lijst met apparaten zou zijn, maar het is als je een apparaat opent. Het ziet er op het eerste oog netjes uit, destructieve acties zijn wat minder toegankelijk waardoor het per ongeluk aanklikken verkleind, dat is een mooie verbetering.

Wat ik wel jammer en minder vind, is dat wanneer je naar de werkelijke staat van zaken wilt, dus config of apps, dit een compleet nieuwe weergave opent en je het kruisje aan moet klikken om terug te gaan. Bij de oude weergave kon je zo van config naar apps naar compliance gaan. Nu niet meer. Hopelijk wordt dat nog aangepast wanneer het niet meer in preview is.

grimson schreef op dinsdag 26 mei 2026 @ 15:26:
[...]

Dank voor het meedenken. Als je bedoelt om Secure Boot via Intune uit te schakelen: ook die policy moet dan vóór OOBE actief zijn, net als de 256‑bit/full‑disk‑instelling. Dat blijft dus hetzelfde probleem misschien?

Ik bedoelde om SB in het UEFI uit te zetten, dus helemaal niks met config of wat dan ook en volledig buiten het OS/installatie om. Maar je hebt al een oplossing, dus dat is mooi.

[Blokker_1999]

En ineens realiseer ik mij waarom het gedrag van de achtergrond caching in Windows is aangepast, iets waar ik goed een maand geleden over schreef hier.

De policy maakt gebruik van een URL, met andere woorden: plaats je achtergrond in een storage account en je clients kunnen er altijd en van overal aan. Door de achtergrond alleen maar te veranderen wanneer de policy zelf veranderd voorkom je dat clients regelmatig gaan checken of het bestand niet veranderd is en zo bespaar je natuurlijk een hoop bandbreedte op je storage account.

[HKLM_]

Blokker_1999 schreef op vrijdag 29 mei 2026 @ 15:34:
En ineens realiseer ik mij waarom het gedrag van de achtergrond caching in Windows is aangepast, iets waar ik goed een maand geleden over schreef hier.

De policy maakt gebruik van een URL, met andere woorden: plaats je achtergrond in een storage account en je clients kunnen er altijd en van overal aan. Door de achtergrond alleen maar te veranderen wanneer de policy zelf veranderd voorkom je dat clients regelmatig gaan checken of het bestand niet veranderd is en zo bespaar je natuurlijk een hoop bandbreedte op je storage account.

Dat is zeker een interessante! Is er van deze caching ook een microsoft docs dat je weet?

[Blokker_1999]

Tot op heden alleen maar mijn eigen ervaring. En ik dacht dat ik er destijds ook vragen over had gesteld aan Copilot, maar kan dat gesprek niet onmiddelijk terugvinden. Iemand zou Copilot eens een betere zoekfunctie moeten geven .

Maar waar in 24H2 de afbeelding regelmatig ververst werd vanuit de opgegeven URL, en dat weten we omdat ik het bestand simpelweg overschreef en na een reboot of een logoff de nieuwe afbeelding verscheen, is dat gedrag verdwenen in 25H2. Als ik het bestand overschrijf, dan blijft de gecachte afbeelding gewoon staan. De URL in de policy vandaag verwijst simpelweg naar een file://C:/... URL omdat we die afbeelding dus lokaal hadden staan in het verleden.

Met dit huidige gedrag denk ik er dus over na om rechtstreeks naar een storage account te gaan verwijzen.

[HKLM_]

Blokker_1999 schreef op vrijdag 29 mei 2026 @ 16:30:
Tot op heden alleen maar mijn eigen ervaring. En ik dacht dat ik er destijds ook vragen over had gesteld aan Copilot, maar kan dat gesprek niet onmiddelijk terugvinden. Iemand zou Copilot eens een betere zoekfunctie moeten geven .

Maar waar in 24H2 de afbeelding regelmatig ververst werd vanuit de opgegeven URL, en dat weten we omdat ik het bestand simpelweg overschreef en na een reboot of een logoff de nieuwe afbeelding verscheen, is dat gedrag verdwenen in 25H2. Als ik het bestand overschrijf, dan blijft de gecachte afbeelding gewoon staan. De URL in de policy vandaag verwijst simpelweg naar een file://C:/... URL omdat we die afbeelding dus lokaal hadden staan in het verleden.

Met dit huidige gedrag denk ik er dus over na om rechtstreeks naar een storage account te gaan verwijzen.

Ik ga het ook eens uitzoeken, ik host mijn plaatje trouwens in een private github repo maar een storage blob gebruik ik ook wel eens

[Stuupje]

Interessante vragen op kantoor vandaag;

In hoeverre heb je wel eens te maken gehad met een externe vraag om een oud-device uit 'Intune' te knallen, die op een of andere reden nog gekoppeld staat maar al tijden afgeschreven is en op de tweede hands markt wordt verhandeld?

En als ik de vraag omdraai en als particulier een device koop die nog gekoppeld staat bij een bedrijf via 'Intune', in hoeverre kun je de stoute schoenen aantrekken (en hoeveel risico loop je) om het bedrijf aan te schrijven om het device te laten verwijderen?

[Hero of Time]

Stuupje schreef op zaterdag 30 mei 2026 @ 00:13:
En als ik de vraag omdraai en als particulier een device koop die nog gekoppeld staat bij een bedrijf via 'Intune', in hoeverre kun je de stoute schoenen aantrekken (en hoeveel risico loop je) om het bedrijf aan te schrijven om het device te laten verwijderen?

Wie niet waagt, wie niet wint. Gewoon proberen, bij 'nee' verandert er toch niks in principe, dus je kan er alleen maar op voorruit gaan. En anders gooi je er Linux op, gaat de hardware ook langer mee (want wie weet dat de eisen nog voldoen over een paar maanden ).

[Blokker_1999]

Bij ons mogen onze gebruikers hun afgeschreven laptop houden nadat we deze vervangen hebben. We wissen deze wel. Als gebruikers de laptop niet wensen of wanneer gebruikers vertrekken en wij de laptop niet meer kunnen hergebruiken voor iets anders dan gaan ze naar een goed doel.

Soms gebeurt het dan inderdaad dat het device nog in Autopilot staat geregistreerd en als we daar melding van krijgen verwijderen we het gewoon.

Mocht je zelf ooit een tweedehands apparaat kopen dat nog gekoppeld zit op een MDM platform dan zou ik, als je de juiste contactgegevens kunt vinden, de firma gewoon aanschrijven. Je hebt zelf niets verkeerd gedaan uiteindelijk. Mocht het apparaat gestolen zijn dan kan het zijn dat men wel wat vragen terug stelt in de hoop van meer te weten te komen over wie het apparaat gestolen heeft, maar het is niet alsof men jouw snel van diefstal zal gaan beschuldigen.

Maar het kan nog erger dan gewoon een MDM lock. Ik heb hier thuis een Thinkpad liggen waar vanuit de UEFI een locking systeem op zit. Werkt wel alleen in combinatie met Windows, maar als het systeem actief is, en Windows wordt geinstalleerd, dat wordt er, wanneer de laptop online is, automatisch een applicatie gedownload die gaat opvragen wat de status is van de laptop in het platform. En als deze dan opgegeven is als gestolen/verloren dan zal de UEFI heel het systeem vergrendellen en kan je geen enkel OS meer opstarten. Dat was een leuk experiment om Windows te herinstalleren en te zien wat er ging gebeuren met die laptop 😅. Uiteindelijk bleek de firma deze gewoon vrijgegeven te hebben, want na heel de installatie gedaan te hebben had ik ineens een UEFI die volledig unlocked was.

[Gr4mpyC3t]

Blokker_1999 schreef op zaterdag 30 mei 2026 @ 07:32:
Soms gebeurt het dan inderdaad dat het device nog in Autopilot staat geregistreerd en als we daar melding van krijgen verwijderen we het gewoon.

Mocht je zelf ooit een tweedehands apparaat kopen dat nog gekoppeld zit op een MDM platform dan zou ik, als je de juiste contactgegevens kunt vinden, de firma gewoon aanschrijven. Je hebt zelf niets verkeerd gedaan uiteindelijk. Mocht het apparaat gestolen zijn dan kan het zijn dat men wel wat vragen terug stelt in de hoop van meer te weten te komen over wie het apparaat gestolen heeft, maar het is niet alsof men jouw snel van diefstal zal gaan beschuldigen.

Krijg je deze verzoeken van particulieren die via dat goede doel een laptop hebben? Of vanuit het goede doel zelf?

Mijn vorige werkgever deed nooit iets met deze verzoeken. Hoe vervelend ook, maar er valt op geen enkele wijze te controleren of je met de koper van die laptop praat, of de dief zelf.

Men wilde er geen tijd (en dus geld) aan besteden en extra risico lopen. Voelde altijd wat zuur en star, maar stiekem ook wel te begrijpen.

[Blokker_1999]

Vanuit het goede doel zelf. Zij refurbishen de laptops en kijken alles na.

[Hero of Time]

Sowieso is het verstandig om je eigen AP op te ruimen door reeds afgeschreven/verkochte systemen eruit te gooien, zeker als je oude hardware verkoopt/doneert aan goede doelen. Je weet welke hardware dat is, hoeveel moeite is het om die in AP op te zoeken en verwijderen? Valt en staat ook wel een beetje met fatsoenlijk asset management en registratie.

[grimson]

Stuupje schreef op zaterdag 30 mei 2026 @ 00:13:
Interessante vragen op kantoor vandaag;

In hoeverre heb je wel eens te maken gehad met een externe vraag om een oud-device uit 'Intune' te knallen, die op een of andere reden nog gekoppeld staat maar al tijden afgeschreven is en op de tweede hands markt wordt verhandeld?

En als ik de vraag omdraai en als particulier een device koop die nog gekoppeld staat bij een bedrijf via 'Intune', in hoeverre kun je de stoute schoenen aantrekken (en hoeveel risico loop je) om het bedrijf aan te schrijven om het device te laten verwijderen?

Toevallig hier 'thuis' mee te maken gehad en inderdaad ook daarbij 'what if'.

Voorbeeld:
Ik heb enkele MS Business Premium trial (30 dagen) tenants opgezet voor homelab. Daarin enkele machines geregistreerd in Autopilot. Daarbij is één van die tenants verlopen en dus ook de licentie / toegang tot Intune. EntraID free blijft over dus verloopt volgens mij je tenant nooit op dat gebied.
Nu wilde ik een device opnieuw registereren in mijn gekoesterde per 90 dagende verlengde developers tenant maar uiteraard nog geregistreerd in de verlopen tenant.
Maar na aanmelden op de tenant kon ik Intune niet openen via het Admin center en dus op deze manier niet het device verwijderen. Ik dacht wel via een directe Intune link maar uiteindelijk 'geen machtigingen').
Het lukte wel om het device uit EntraID te verwijderen via MgGraph (niet via de gui) maar dit verwijdert niet het Autopilot device. Uiteindelijk heb ik nog een Intune trial kunnen afsluiten op deze tenant om zo alsnog Intune te benaderen en het device uit Autopilot te verwijderen. Copilot gaf ook nog aan misschien in Admin center dit te kunnen of via MgGraph maar beide niet geprobeerd.

Onderzoek:
Tot nu toe wat ik heb kunnen onderzoeken is:
Autopilot is een aparte service/database binnen het MS ecosysteem waar je je apparaat in registreerd. Vandaar ook dat je niet bij het alleen verwijderen (als je dit al kan via de GUI) uit EntraID de Autopilot registratie blijft bestaan.

Bestaande tenant zonder Intune licentie:
Bij het verlopen van mijn trial is dus de Autopiliot registratie blijven bestaan in Autopilot terwijl ik het niet meer kon managen. Ik 'moest' dus een omweg vinden om alsnog deze te verwijderen uit Autopilot. Ik weet niet wat er na 30 dagen gebeurt als je grace period over is en dan alles echt gewist wordt en dus ook het Autopilot record. Ik vermoed van niet.

Compleet verwijderde tenant:
Zover ik theoretisch heb kunnen onderzoeken lijkt het erop dat ook bij het verwijderen van een tenant de Autopilot registratie blijft bestaan. Dus SOL hier helemaal.

CSP:
Zover ik heb begrepen kunnen sommigen namens een tenant een device registreren. Deze kunnen dus ook weer het device weghalen, ook als de tenant gewist is. Maar dit geldt alleen voor devices die zij hebben geregistreerd.

Microsoft:
Ook in theorie zou je kunnen aankloppen bij MS om een registratie te laten verwijderen maar dan moet je aankoopbewijzen etc kunnen aantonen. Maar welke 2e hands verkrijger zou dit lukken .

Conclusie:
Zover ik kan achterhalen:
Je bent SOL als een voorgaande eigenaar de Autopilot registratie niet heeft verwijderd. Het Autopilot record lijkt voor altijd te bestaan ondanks wel of niet bestaande tenants. Er is geen automatische cleanup in deze aparte database.
De enige mogelijkheid lijkt een support case aan te maken bij MS (als je dit al lukt) met dan argumenten die misschien ontoereikend zijn, de vorige eigenaar te benaderen en of de CSP.

Let dus goed op dat je (je eigen lab) devices op tijd de-registreert uit Autopilot!

[Hero of Time]

@grimson, in jouw geval, is het echt nodig dat je apparaat al vanuit OOBE config gaat doen, of wil je eigenlijk alleen de configuratie, policies en andere zaken van Intune regelen als je al in Windows bent ingelogd? Want het klinkt beter om in jouw geval met je vele trials direct in te loggen met je MS account uit je tenant, zo het apparaat voor Intune te registeren en zo niet de rompslomp van AutoPilot registraties te hebben die je dan weer vergeet te verwijderen.

[grimson]

Hero of Time schreef op zaterdag 30 mei 2026 @ 11:17:
@grimson, in jouw geval, is het echt nodig dat je apparaat al vanuit OOBE config gaat doen, of wil je eigenlijk alleen de configuratie, policies en andere zaken van Intune regelen als je al in Windows bent ingelogd? Want het klinkt beter om in jouw geval met je vele trials direct in te loggen met je MS account uit je tenant, zo het apparaat voor Intune te registeren en zo niet de rompslomp van AutoPilot registraties te hebben die je dan weer vergeet te verwijderen.

Dank voor je reactie.
Zover mogelijk probeer ik de hele keten te simuleren in een homelab en eigenlijk ook dus Autopilot. Zie ook mijn eerdere post over Bitlocker en het verkrijgen van 256/full disk encryptie in ADE (automatic drive encryption) 'moet' ik dit via Autopilot testen om remote voor OOBE een setting in te stellen. Doorgaans heb ik (nog steeds) het geluk een 'perpetual' E5 25 licentie developerstenant te mogen behouden en gebruik ik deze eigenlijk altijd. Enige verschil is dat deze bijv. geen Defender for Endpoint heeft om te testen. Daarbij af en toe dus een echte trial te gebruiken. Maar ik moet gewoon zorgvuldig zijn met waar ik de apparaten registreer .

[Blokker_1999]

Hero of Time schreef op zaterdag 30 mei 2026 @ 09:58:
Sowieso is het verstandig om je eigen AP op te ruimen door reeds afgeschreven/verkochte systemen eruit te gooien, zeker als je oude hardware verkoopt/doneert aan goede doelen. Je weet welke hardware dat is, hoeveel moeite is het om die in AP op te zoeken en verwijderen? Valt en staat ook wel een beetje met fatsoenlijk asset management en registratie.

We hebben de afgelopen jaren grote vorderingen gemaakt in asset management. Toen ik zelf bij de firma kwam was het een echte puinhoop waar niemand echt naar omkeek. Maar zelfs vandaag blijft het mislopen. Er is geen echte eindverantwoordelijke en daarnaast heb je te veel mensen met te veel toegang. Recent nog iemand die dacht dat die gewoon laptops mocht verwijderen uit onze asset management tool, iets wat je nooit mag doen omdat je dan de geschiedenis van dat asset verliest, maar omdat we dan ook niet meer weten dat dat asset bestaat waardoor we het ook niet meenemen op onze lijsten voor o.a. de verzekering en dergelijke.

Ik hoop dat we volgend jaar eindelijk de laatste puzzelstukjes kunnen leggen om heel dat process te automatiseren. Verdwijnt een laptop uit ons systeem, dan geef je dat op 1 locatie in, en de automatisatie gaat dan overal alles weghalen. Het apparaat uit AD als het er in staat, de AP registratie als die bestaat, uit Intune als het er in staat en uit Entra als het er in staat. En als we dat dan ook nog eens voor onze iPhones kunnen doen, dan kunnen we weer een hoop rechten afnemen bij mensen en alles toevertrouwen aan automatisatie. Minder kans op fouten.

Want ook bij iPhones loopt het spijtig genoeg wel eens mis. En daar heb je dan weer geen auditing. Een jaar of twee terug hadden we een gebruiker die na enkele weken alweer vertrok bij ons in de firma. Zijn splinternieuwe, zo goed als niet gebruikte iPhone ging de stock in als reserve apparaat (iedereen die start bij ons krijgt splinternieuw materiaal) en enkele maanden later hadden we een gebruiker die zijn nieuwe iPhone beschadigd had en niet meer te redden was. Geen enkel probleem, we hebben 1 spare. Dat dachten we. Het toestel had namelijk pootjes gekregen. Niemand wist waar het toestel naartoe was. Het stond ook niet meer in Apple Business Manager. Nooit kunnen hard maken wie het toestel ontvreemd heeft spijtig genoeg.

Maar ondanks dat gebruikers dus hun oude toestellen, wanneer wij deze mogen vervangen, terugkrijgen nadat wij deze gewist hebben, zien we dus regelmatig dat ze toch nog in AP of ABM staan en zie je een ticket voorbijkomen van "Ik heb dit toestel aan mijn vrouw/kind gegeven en nu zitten zij vast, kan je dit toestel vrijgeven?" Zoiets simpels, maar onze first line blijft er maar in slagen om dat te vergeten.

Al heb je natuurlijk ook mensen die de andere kant opgaan recent iemand gehad die bij het vernieuwen van zijn company iPhone ervoor koos om te upgraden (daar betaal je zelf voor) naar een Ultra en dan kregen we ineens een ticketje omdat deze persoon er niet beter op gevonden had dan de telefoon, nieuw in de doos, cadeau te geven aan zijn vrouw/vriendin. Natuurlijk helemaal niet stilgestaan bij het feit dat dat apparaat in essentie eigendom is van onze firma en dus MDM enrolled is. Of we dat even konden verwijderen. Daar hebben we toch wel even gezegd dat hij toch echt 3 jaar zal moeten wachten voordat we deze uit MDM halen. Dus die had dan weer geld weggegooid, want zelf had hij geen Ultra nodig.

[akimosan]

@grimson : verwijderen kan via Graph api. Voor het offboarden van devices gebruik ik

Device offboarding manager

Hiermee kun je ook (in bulk) devices offboarden in EntraID en Intune zonder ze te verwijderen uit Autopilot of gewoon in alle 3 de omgevingen in 1x.

[grimson]

akimosan schreef op zaterdag 30 mei 2026 @ 22:09:
@grimson : verwijderen kan via Graph api. Voor het offboarden van devices gebruik ik

Device offboarding manager

Hiermee kun je ook (in bulk) devices offboarden in EntraID en Intune zonder ze te verwijderen uit Autopilot of gewoon in alle 3 de omgevingen in 1x.

Dank voor de tip! Dus via Microsoft Graph (en dus via tools zoals DeviceOffboardingManager) kun je theoretisch nog steeds Autopilot‑devices verwijderen in een tenant zonder Intune‑licenties. Volgens mijn herinnering werd dat in de Intune Admin site meteen onmogelijk gemaakt zodra de licenties verlopen waren. Je kunt de portal nog wel openen, maar volgens mij alleen in een soort “read‑only” staat. Maar de 'GUI' is wel meer beperkend dan via MgGraph.

Het belangrijkste punt blijft denk ik dat de Intune/Autopilot‑backend nog aanwezig moet zijn in de tenant, ook al zijn de licenties verlopen. Zolang die backend nog bestaat, werkt Graph dan blijkbaar nog 'gewoon' en kun je Autopilot‑objecten verwijderen anders dan de GUI blokkade.

Die backend verdwijnt zover ik weet (deprovisoning Intune services) niet direct na licentieverloop, maar wordt pas later door Microsoft opgeruimd als in tenant opheffen na ~30 dagen(?). Zodra dat gebeurt, is verwijderen volgens mij niet meer mogelijk, ook al bestaat de tenant zelf nog. Ik ben ook benieuwd of je met het opnieuw activeren van een Intune‑licentie die dan inmiddels “wees geworden” Autopilot‑objecten überhaupt nog terug kunt halen. Maar dit is allemaal een theorie. Maar nogmaals ik laat mijzelf graag verbeteren, leer en verbeter!

[YaYo86]

Via Microsoft AI Skills Fest kun je een voucher voor 100% korting op een Microsoft Certification exam verdienen. Het enige wat je hoeft te doen:

1. Registreer je voor AI Skills Fest
2. Voltooi een eligible playlist (volledig, ongewijzigd)
3. Ontvang je voucher

Microsoft Certification exams (incl. beta) én GitHub exams tellen mee. Certiport- en MOS-exams helaas niet.

Meer info vind je hier.

[ Voor 29% gewijzigd door YaYo86 op 03-06-2026 14:20 ]

[Drardollan]

Ben aan het stoeien met Intune en Microsoft Defender. Heeft er iemand toevallig een goede best-practice voor de AV en Firewall policies? Ik heb voor nu de Baseline gepakt en daar Bitlocker uitgehaald (die heb ik in een andere policy zitten), maar ik weet niet zo goed of dat een goed startpunt is.

[YaYo86]

Drardollan schreef op woensdag 3 juni 2026 @ 17:10:
Ben aan het stoeien met Intune en Microsoft Defender. Heeft er iemand toevallig een goede best-practice voor de AV en Firewall policies? Ik heb voor nu de Baseline gepakt en daar Bitlocker uitgehaald (die heb ik in een andere policy zitten), maar ik weet niet zo goed of dat een goed startpunt is.

Ja die hebben wij samen met MS en Inspark ingeregeld, zal morgen ff kijken voor je.

[Drardollan]

YaYo86 schreef op woensdag 3 juni 2026 @ 17:18:
[...]

Ja die hebben wij samen met MS en Inspark ingeregeld, zal morgen ff kijken voor je.

Dank!

[HKLM_]

Drardollan schreef op woensdag 3 juni 2026 @ 17:10:
Ben aan het stoeien met Intune en Microsoft Defender. Heeft er iemand toevallig een goede best-practice voor de AV en Firewall policies? Ik heb voor nu de Baseline gepakt en daar Bitlocker uitgehaald (die heb ik in een andere policy zitten), maar ik weet niet zo goed of dat een goed startpunt is.

Als je met defender aan de gang gaat en er “nieuw” mee bent kijk naar de blogs van Jeffrey Appel. https://jeffreyappel.nl/2025-microsoft-defender-optimization-configuration-cheat-sheet/

[Drardollan]

HKLM_ schreef op donderdag 4 juni 2026 @ 06:40:
[...]

Als je met defender aan de gang gaat en er “nieuw” mee bent kijk naar de blogs van Jeffrey Appel. https://jeffreyappel.nl/2025-microsoft-defender-optimization-configuration-cheat-sheet/

Ik heb toevallig zijn andere blogs in deze serie gelezen en gevolgd, meeste zit er dus ook in zoals daar verteld.

Het is inderdaad dat ik nieuw ben, heb enkel ervaring met Sophos en Bitdefender tot nu toe in een gemanaged omgeving (laat ik mijn McAfee ePolicy Orchistrator uit 2002 maar niet meer als parate kennis opvoeren ). Ik worstel er nu vooral mee dat ik het lastig vind om te zien dat alles goed geconfigureerd is, bij Sophos en Bitdefender doe je dat logischerwijs in de agent die geinstalleerd is, nu moet ik op Windows Security gebruiken. Zoals velen heb ik die altijd genegeerd verder omdat het niet ter zake deed, maar dat moet nu veranderen. En daar moet ik even mijn weg in vinden.

[YaYo86]

YaYo86 schreef op woensdag 3 juni 2026 @ 17:18:
[...]

Ja die hebben wij samen met MS en Inspark ingeregeld, zal morgen ff kijken voor je.

Iemand een idee hoe dit te exporteren is? Ik heb wel een haast onleesbare JSON met allerhande GUIDs maar die wil ik niet zomaar delen met iedereen. Screenshot is ook geen optie, want past niet op 1 pagina.

[Drardollan]

YaYo86 schreef op donderdag 4 juni 2026 @ 14:06:
[...]

Iemand een idee hoe dit te exporteren is? Ik heb wel een haast onleesbare JSON met allerhande GUIDs maar die wil ik niet zomaar delen met iedereen. Screenshot is ook geen optie, want past niet op 1 pagina.

Volgens mij enkel via intune en dan de 3 puntjes en export. Of je moet iets als CIPP hebben, daar kan je meer mee meestal.

[YaYo86]

Ik zie alleen Duplicate en Delete.

CIPP hebben wij niet, ik werk niet voor een MSP namelijk.

[Drardollan]

YaYo86 schreef op donderdag 4 juni 2026 @ 14:33:
Ik zie alleen Duplicate en Delete.

CIPP hebben wij niet, ik werk niet voor een MSP namelijk.

Als je via Devices -> Configuration kijkt, heb je dan ook geen Export?
Kan wel goed dat het voor een bepaalde policy niet kan, niet alles is exporteerbaar helaas

[HKLM_]

Drardollan schreef op donderdag 4 juni 2026 @ 15:04:
[...]

Als je via Devices -> Configuration kijkt, heb je dan ook geen Export?
Kan wel goed dat het voor een bepaalde policy niet kan, niet alles is exporteerbaar helaas

Gebruik: Micke-K/IntuneManagement: Copy, export, import, delete, document and compare policies and profiles in Intune and Azure with PowerShell script and WPF UI. Import ADMX files and registry settings with ADMX ingestion. View and edit PowerShell script.

[YaYo86]

Drardollan schreef op donderdag 4 juni 2026 @ 15:04:
[...]

Als je via Devices -> Configuration kijkt, heb je dan ook geen Export?
Kan wel goed dat het voor een bepaalde policy niet kan, niet alles is exporteerbaar helaas

Aah ja, daar zie ik wel een export, maar ook daar zitten allerlei privacy gevoelige policy namen, IDs en GUIDs die ik niet wil en mag delen. Ik kan een screenshot maken van de settings maar die pagina is scrolbaar..

HKLM_ schreef op donderdag 4 juni 2026 @ 15:09:
[...]

Gebruik: Micke-K/IntuneManagement: Copy, export, import, delete, document and compare policies and profiles in Intune and Azure with PowerShell script and WPF UI. Import ADMX files and registry settings with ADMX ingestion. View and edit PowerShell script.

Die heb ik geprobeerd, ook daar zie ik in de JSON allerlei IDs en GUIDs die ik niet wil en mag delen.

[akimosan]

Zo lang het een XML is kun je met een klein beetje moeite de GUID's en ID's vervangen door generieke namen , al dan niet met zoek en vervang functies. Bijvoorbeeld bedrijfsnaam vervangen met Contoso of zoiets.

Met iets als Copilot of een andere AI LLM is zou je det wel generiek moeten kunnen maken

Maar snap het wel dat je daar voorzichtig mee bent.

[Drardollan]

Heel logisch en goed dat je daar voorzichtig in bent @YaYo86 , ik zou het ook niet delen. Hoewel een ander er waarschijnlijk weinig mee kan is het goed om dit bij je te houden.

Een paar screenshots zou zeker al helpen, als je die moeite wil nemen ben ik al erg dankbaar!

[akimosan]

@Drardollan : Qua Intune zijn een hoop defaults in de security baselines, inclusief firewall settings, goed bruikbaar in de meeste standaard kantoorsituaties. ASR rules in audit mode draaien en langzaam aan migreren naar WARN/BLOCK. Altijd even op een testgroep afvuren en monitoren wat er gebeurt...

Verwacht mogelijke issues met:

• Developers als die veel prutsen op hun eigen laptops en verwachten dat ze nog testsites/apps kunnen draaien op [url="http://localhost"]http://localhost[/url] , zelf apps maken die geblokeerd worden door ASR rules als check op age/prevalence/unsigned code, out of date Python versies/code, unsigned scripts, llm's..
• Gebruikers met Office documenten en unsigned VBA code/macro's
• Field engineers die lokaal aanpassingen moeten maken aan netwerk instellingen of EOL tools/software proberen te draaien waarbij ze soms verbinding moeten maken met end-points die geen TLS 1.1 of hoger snappen, self-signed certificaten hebben, of self-signed MAAR ze moeten de interface benaderen op een fixed ip adres dus hostname/url komt never nooit overeen.

[YaYo86]

Ik ben even met Copilot bezig geweest om eea generiek te maken! Windows FW hebben we nooit ingeregeld, doen we allemaal op netwerkniveau. Hopelijk hebben jullie er wat aan.

JSON: Defender-Windows Security Experience

{
  "name": "Defender - Windows Security Experience",
  "description": "Generic Windows Security Experience policy",
  "platforms": "windows10",
  "technologies": "mdm,microsoftSense",
  "templateReference": {
    "templateFamily": "endpointSecurityAntivirus"
  },
  "settings": {
    "tamperProtection": false,
    "disableFamilyUI": true,
    "disableTPMWarning": false
  }
}

JSON: Defender - Custom Exclusions

{
  "name": "Defender - Custom Exclusions",
  "description": "Generic, readable Defender exclusions policy",
  "platforms": "windows10",
  "technologies": "mdm,microsoftSense",

  "settings": {
    "excludedExtensions": [
      "*.avhd",
      "*.avhdx",
      "*.iso",
      "*.rct",
      "*.vhd",
      "*.vhdpmem",
      "*.vhds",
      "*.vhdx",
      "*.vmcx",
      "*.vmgs",
      "*.vmrs",
      "*.vsv"
    ],

    "excludedPaths": {
      "hyperV": [
        "%SystemDrive%\\ProgramData\\Microsoft\\Windows\\Hyper-V\\Snapshots"
      ],
      "groupPolicy": [
        "%SystemRoot%\\System32\\GroupPolicy\\Machine\\",
        "%SystemRoot%\\System32\\GroupPolicy\\User\\"
     ],
      "windowsSecurityDB": [
        "%windir%\\Security\\Database\\*.chk",
        "%windir%\\Security\\Database\\*.log",
        "%windir%\\Security\\Database\\*.edb",
        "%windir%\\Security\\Database\\*.sdb",
        "%windir%\\Security\\Database\\*.xml"
      ],
      "other": [
        "%windir%\\IMECache",
        "%Windir%\\System32\\omadmclient.exe",
        "%userprofile%\\ntuser.dat*"
      ]
    },

    "excludedProcesses": [
      "%systemroot%\\System32\\Vmsp.exe",
      "%systemroot%\\System32\\Vmwp.exe"
    ]
  }
}

JSON: Defender - Exploit Protection

{
  "name": "Defender - Exploit Protection",
  "description": "Generic Exploit Protection policy",
  "platforms": "windows10",
  "technologies": "mdm",
  "templateReference": {
    "templateFamily": "endpointSecurityAttackSurfaceReduction"
  },
  "settings": [
    {
      "settingDefinitionId": "exploitProtectionSettings",
      "value": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<MitigationPolicy>\n  <AppConfig Executable=\"ExtExport.exe\">\n    <ASLR ForceRelocateImages=\"true\" RequireInfo=\"false\" />\n  </AppConfig>\n  <AppConfig Executable=\"ie4uinit.exe\">\n    <ASLR ForceRelocateImages=\"true\" RequireInfo=\"false\" />\n  </AppConfig>\n  <AppConfig Executable=\"iexplore.exe\">\n    <ASLR ForceRelocateImages=\"true\" RequireInfo=\"false\" />\n  </AppConfig>\n  <AppConfig Executable=\"MsSense.exe\">\n    <StrictHandle Enable=\"true\" />\n    <SEHOP Enable=\"true\" TelemetryOnly=\"false\" />\n  </AppConfig>\n</MitigationPolicy>"
    },
    {
      "settingDefinitionId": "disallowExploitProtectionOverride",
      "value": true
    }
  ]
}

JSON: Defender-Settings

{
  "name": "Windows Defender - Base Settings",
  "description": "Generic Defender Antivirus policy",
  "platforms": "windows10",
  "technologies": "mdm,microsoftSense",
  "templateReference": {
    "templateFamily": "endpointSecurityAntivirus"
  },
  "settings": {
    "threatActions": {
      "high": "remove",
      "severe": "quarantine",
      "moderate": "quarantine",
      "low": "remove"
    },
    "realtimeMonitoring": true,
    "cloudProtection": true,
    "behaviorMonitoring": true,
    "emailScanning": true,
    "archiveScanning": true,
    "networkFilesScanning": true,
    "scriptScanning": true,
    "ioavProtection": true,
    "puaProtection": true,
    "networkProtection": true,
    "scanParameters": "quickScan",
    "scanDirection": "incoming",
    "avgCpuLoadFactor": 25,
    "signatureUpdateInterval": 4,
    "quickScanTime": 840,
    "cloudBlockLevel": "high",
    "cloudExtendedTimeout": 50,
    "retainCleanedMalwareDays": 14,
    "lowCpuPriority": true,
    "submitSamplesConsent": "sendSafeSamples",
    "disableLocalAdminMerge": true,
    "onAccessProtection": true
  }
}

[Drardollan]

Thx @YaYo86 !

[YaYo86]

No worries.

Verder hebben wij alle ASR's aan staan. Wel eerst een tijdje in Audit gerunt uiteraard. Met name de Office rules gaven wat problemen bleek toen.

[ Voor 3% gewijzigd door YaYo86 op 04-06-2026 16:21 ]

[HKLM_]

akimosan schreef op donderdag 4 juni 2026 @ 15:52:
@Drardollan : Qua Intune zijn een hoop defaults in de security baselines, inclusief firewall settings, goed bruikbaar in de meeste standaard kantoorsituaties. ASR rules in audit mode draaien en langzaam aan migreren naar WARN/BLOCK. Altijd even op een testgroep afvuren en monitoren wat er gebeurt...

Verwacht mogelijke issues met:

• Developers als die veel prutsen op hun eigen laptops en verwachten dat ze nog testsites/apps kunnen draaien op [url="http://localhost"]http://localhost[/url] , zelf apps maken die geblokeerd worden door ASR rules als check op age/prevalence/unsigned code, out of date Python versies/code, unsigned scripts, llm's..
• Gebruikers met Office documenten en unsigned VBA code/macro's
• Field engineers die lokaal aanpassingen moeten maken aan netwerk instellingen of EOL tools/software proberen te draaien waarbij ze soms verbinding moeten maken met end-points die geen TLS 1.1 of hoger snappen, self-signed certificaten hebben, of self-signed MAAR ze moeten de interface benaderen op een fixed ip adres dus hostname/url komt never nooit overeen.

Goed advies vanuit het security center -> Reports -> Endpoint -> Attack Surface Reduction rules heb je een goed overzicht in wat er gebeurt op de devices met ASR en kan je keuzes maken of het ready is om naar Block mode te gaan.

[grimson]

HP Connect en Intune Remediations: zie ik hier een mogelijk licentieprobleem?

Tijdens het testen van HP Connect ben ik iets tegengekomen waar ik nog geen duidelijk antwoord op heb kunnen vinden.

Wanneer je HP Connect koppelt aan een Intune-tenant, worden BIOS-updates en BIOS-configuraties vanuit HP centraal uitgerold naar beheerde devices. Tijdens het bekijken van wat er precies in de tenant gebeurt, viel mij op dat HP Connect hiervoor onder water gebruikmaakt van Intune Remediations.

De configuraties verschijnen daadwerkelijk als Remediations in Intune en worden vervolgens uitgevoerd door de Intune Management Extension op de endpoints.

Wat mij vervolgens opviel is dat dit ook lijkt te werken in tenants waar Remediations in de Intune-portal nog achter een licentiemelding zitten. Normaal gesproken moet je bij het eerste gebruik van Remediations bevestigen dat je over de juiste licenties beschikt. Omdat HP Connect de configuratie rechtstreeks via Microsoft Graph aanmaakt, lijkt deze controle in de GUI volledig te worden omzeild.

Mijn gedachtegang is daarom als volgt.

Voor zover ik begrijp gelden voor het gebruik van Intune Remediations aanvullende licentievereisten. In de Microsoft-documentatie worden onder andere Windows Enterprise E3/E5 en Microsoft 365 E3/E5/F3 genoemd als licenties waarmee deze functionaliteit gebruikt mag worden.

Als een organisatie bijvoorbeeld uitsluitend Microsoft 365 Business Premium gebruikt, dan lijkt HP Connect technisch gezien nog steeds probleemloos te werken. Onder water wordt echter nog steeds gebruikgemaakt van dezelfde Remediations-functionaliteit van Microsoft.

Daardoor vraag ik mij af of dit niet simpelweg een geval is van:

"Technisch werkt het, maar licentietechnisch heb je nog steeds recht op Remediations nodig."

Mijn vragen:

• Zie ik dit correct, of mis ik iets in de licentievoorwaarden?
• Heeft iemand dit specifieke scenario al eens besproken met Microsoft of een accountteam?
• Is dit ooit tijdens een audit ter sprake gekomen?
• Zijn er beheerders die om deze reden HP BIOS-beheer liever via HPCMSL en Win32-applicaties uitvoeren?
• Of bestaat er documentatie van Microsoft of HP waaruit blijkt dat HP Connect hier een uitzondering vormt?

De reden dat ik het vraag is dat HP Connect op het eerste gezicht een erg nette oplossing lijkt voor BIOS-beheer vanuit Intune. Als de oplossing onder water echter volledig leunt op Remediations, dan vraag ik mij af of organisaties zonder de daarvoor vereiste licenties ongemerkt een compliance-risico introduceren.

3 minuten later gewoon de documentatie lezen geeft dit:

The following is necessary to use HP Connect for Microsoft Endpoint Manager (HP Connect):
• Administrative access to a Microsoft Azure tenant
• An appropriate Microsoft Endpoint Manager (MEM) subscription
o Including support for Proactive Remediations
HP Connect requires an appropriate subscription level to Microsoft Azure (example, E3/A3 and E5/A5, Virtual Desktop/user). The license must allow the use of Proactive Remediations.

[ Voor 14% gewijzigd door grimson op 04-06-2026 19:39 ]

[Hero of Time]

YaYo86 schreef op donderdag 4 juni 2026 @ 14:06:
Screenshot is ook geen optie, want past niet op 1 pagina.

Misschien geen vernieuwde IE gebruiken dan. Bij Firefox kan je met rechts klikken en dan 'Take Screenshot' kiezen. Begin dan bij het web element waar de boel begint en pak het bolletje in het midden onderin de selectie en scroll omlaag. Voila, screenshot van meer dan op je scherm zichtbaar is.

[Drardollan]

Meest voor Defender ondertussen, mede door de hulp hier, werkend. Het is even wennen, maar het meeste is wel te doen. Eigenlijk valt er maar 1 ding op, de security recommendations zijn eerder vervelend dan nuttig. Hij komt met meldingen dat software bijgewerkt moet worden (wat prima is), maar dat heb ik 24 uur geleden al gedaan. Nog niet opgepikt door Defender, dat stelt een beetje teleur eigenlijk.

[akimosan]

Ook: zoveel meldingen in Defender zijn puur AI generated.

Vaak kijkt hij enkel naar een application name en niet altijd te gedetailleerd naar versies of dat je überhaupt kwetsbaar bent.

Wat ik ook heb gedaan en wel helpt om updates van apps bij te houden, hoewel het een beetje fire and forget is, maar je kunt het eens uit testen:

• Deploy WingetAutoupdate
• Importeer de ADMX templates voor WingetAutoUpdate
• Maak een configuration profile aan met imported administrative template, om de gewenste settings voor WingetAutoUpdate te beheren
• Zelf hanteer ik een blacklist voor apps die we zelf vanuit Intune managen (met Robopack) en om software/versie conflicten te vermijden met de apps die Robopack beheert, plaats ik die in de blacklist. Verder nog wat apps die hun eigen update mechanisme hebben of waarvan known issues bekend zijn met de winget packages.
• WingetAutoUpdate werkt automatisch packages bij vanuit Winget en MS Store middels scheduled task die standaard na elke nieuwe logon draait.

[Davidas]

Heb de tool IntuneGet sinds kort ontdekt, ga binnenkort een Proof of Concept opstarten in onze acceptatieomgeving om te kijken of het wat is, volledig open source, alleen app registratie nodig voor paar API permissies.

[Nogne]

Davidas schreef op vrijdag 5 juni 2026 @ 11:18:
Heb de tool IntuneGet sinds kort ontdekt, ga binnenkort een Proof of Concept opstarten in onze acceptatieomgeving om te kijken of het wat is, volledig open source, alleen app registratie nodig voor paar API permissies.

Er is ook een versie voor Mac devices: https://www.intunebrew.com

[Blokker_1999]

Wat ik me daarbij afvraag: hoe zit het met app updates? Dat de intune package altijd de meest recente versie installeert lijkt me normaal, maar apps moeten ook bijgewerkt worden als er updates zijn. Hoe gebeurt dat dan hier?

[HKLM_]

Blokker_1999 schreef op vrijdag 5 juni 2026 @ 13:20:
Wat ik me daarbij afvraag: hoe zit het met app updates? Dat de intune package altijd de meest recente versie installeert lijkt me normaal, maar apps moeten ook bijgewerkt worden als er updates zijn. Hoe gebeurt dat dan hier?

Er zit een update optie in: https://www.intuneget.com/docs/updates-policies

[Blokker_1999]

Wat ik me af vraag is hoe dit werkt in de achtergrond, want je gaat geen nieuwe .intunewin bestanden maken omdat er een update is. Wordt er dan een proactive remediation gezet om regelmatig te gaan kijken? En hoe zou dat werken wanneer de app bijvoorbeeld open staat maar dicht moet zijn om de update te kunnen installeren?

[DDX]

Nogne schreef op vrijdag 5 juni 2026 @ 12:39:
[...]

Er is ook een versie voor Mac devices: https://www.intunebrew.com

Dit is dan wel weer grappig :

For teams that need a fully supported, enterprise-ready macOS app management platform, we recommend RoboPack.

Wij hebben robopack en dat werkt op windows prima, maar macos ondersteuning zit ik nogsteeds op te wachten (stond eerst op zomer 2025 roadmap....)
https://roadmap.robopack.com/post/macos-app-support-9yg

[HKLM_]

DDX schreef op zaterdag 6 juni 2026 @ 15:45:
[...]


Dit is dan wel weer grappig :

[...]


Wij hebben robopack en dat werkt op windows prima, maar macos ondersteuning zit ik nogsteeds op te wachten (stond eerst op zomer 2025 roadmap....)
https://roadmap.robopack.com/post/macos-app-support-9yg

Het is ook gewoon gemaakt met AI die zal het wel fout hebben , bijna al zijn tools hebben een hoog AI gehalte, zijn wel cool maar ik vindt persoonlijk als die AI tools voor o.a Intune die als paddestoelen uit de grond schieten een ding en zou mijn business 1,2,3 mee afhankelijk maken.

Winget voor applicaties is nog zo iets, er zijn legio beheerders die gewoon winget gebruiken zonder te veriferen wat de source is waarvanaf de downloaden

[ Voor 27% gewijzigd door HKLM_ op 06-06-2026 16:11 ]

[Drardollan]

akimosan schreef op vrijdag 5 juni 2026 @ 11:07:
Ook: zoveel meldingen in Defender zijn puur AI generated.

Vaak kijkt hij enkel naar een application name en niet altijd te gedetailleerd naar versies of dat je überhaupt kwetsbaar bent.

Wat ik ook heb gedaan en wel helpt om updates van apps bij te houden, hoewel het een beetje fire and forget is, maar je kunt het eens uit testen:

• Deploy WingetAutoupdate
• Importeer de ADMX templates voor WingetAutoUpdate
• Maak een configuration profile aan met imported administrative template, om de gewenste settings voor WingetAutoUpdate te beheren
• Zelf hanteer ik een blacklist voor apps die we zelf vanuit Intune managen (met Robopack) en om software/versie conflicten te vermijden met de apps die Robopack beheert, plaats ik die in de blacklist. Verder nog wat apps die hun eigen update mechanisme hebben of waarvan known issues bekend zijn met de winget packages.
• WingetAutoUpdate werkt automatisch packages bij vanuit Winget en MS Store middels scheduled task die standaard na elke nieuwe logon draait.

Ziet er uit als een toffe tool (de open source), maar moet er nog wel even over nadenken. De laatste tijd is er veel gerommel in dit soort packages door supply-chain attacks. Weet niet of ik dat zomaar los wil laten. Ook vind ik het lastig om te beoordelen welke apps er bijgewerkt kunnen worden, ik zou dat liever meer onder controle willen hebben.

Maar dat betekent niet dat het niet het testen waard is in een test tenant, eens zien wat het allemaal doet.

Die Robopack is wel een gouden tip, gratis tot 100 devices. Precies de markt waarin ik mij bevind met mijn bedrijf, heb geen klant met die aantallen. Dat zou nog wel eens een leuke toevoeging kunnen zijn!

[ Voor 6% gewijzigd door Drardollan op 06-06-2026 16:25 ]

[DDX]

Robopack werkt hier prima, wel betaalde licentie genomen zodat je ook support hebt. (maar in principe kan je ook zonder support draaien)

[Drardollan]

DDX schreef op zaterdag 6 juni 2026 @ 16:57:
Robopack werkt hier prima, wel betaalde licentie genomen zodat je ook support hebt. (maar in principe kan je ook zonder support draaien)

Vind het extra interessant omdat ik gratis kan starten én dat het MSP ready is. Ben met mijn eigen bedrijf druk in ontwikkeling om een totaal pakket aan te gaan bieden en dit past daar heel mooi in.

[Blokker_1999]

Omdat we volgende week een kick-off hebben voor Azure Virtual Desktops en de komende maanden honderden van die desktops gaan deployen, waarbij ze ook in Intune gaan komen ben ik deze week begonnen met door alle config in Intune te gaan, en ik vroeg me daarbij af hoe anderen hun omgeving organiseren. Splitsen jullie policies op per type van endpoint en maak je daarmee bepaalde policies meervoudig aan, of is de primaire bepaling wat een policy doet en passen jullie gewoon de assignments aan?

Die vraag kwam ineens bij mij op toen ik de lijst trok van policies die simpelweg op "All Devices" is geplaatst terwijl ik weet dat een deel van die policies niet meer overal van toepassing zullen mogen zijn. Geen BitLocker op AVD bijvoorbeeld, maar ook een powerplan is niet van toepassing op een virtuele machine.

Mischien ben ik gewoon te ver aan het gaan met hierover na te denken, maar aangezien ik nu toch weer alles moet vastnemen, is het het goede moment om eens grote kuis te houden.

[YaYo86]

Blokker_1999 schreef op maandag 8 juni 2026 @ 20:18:
Omdat we volgende week een kick-off hebben voor Azure Virtual Desktops en de komende maanden honderden van die desktops gaan deployen, waarbij ze ook in Intune gaan komen ben ik deze week begonnen met door alle config in Intune te gaan, en ik vroeg me daarbij af hoe anderen hun omgeving organiseren. Splitsen jullie policies op per type van endpoint en maak je daarmee bepaalde policies meervoudig aan, of is de primaire bepaling wat een policy doet en passen jullie gewoon de assignments aan?

Die vraag kwam ineens bij mij op toen ik de lijst trok van policies die simpelweg op "All Devices" is geplaatst terwijl ik weet dat een deel van die policies niet meer overal van toepassing zullen mogen zijn. Geen BitLocker op AVD bijvoorbeeld, maar ook een powerplan is niet van toepassing op een virtuele machine.

Mischien ben ik gewoon te ver aan het gaan met hierover na te denken, maar aangezien ik nu toch weer alles moet vastnemen, is het het goede moment om eens grote kuis te houden.

Wij gebruiken beide methoden. In de basis wijzen we alles toe aan All Devices, maar voor specifieke scenario’s passen we de assignment aan met Filters.

Zoals je aangeeft is BitLocker bijvoorbeeld niet relevant voor AVD, waardoor filtering daar logischer is. Tegelijkertijd zijn er ook policies waarbij bepaalde instellingen niet van toepassing zijn op een specifiek endpointtype. In die gevallen maken we aparte policies die grotendeels hetzelfde zijn, maar op enkele punten afwijken zodat ze beter aansluiten bij het betreffende platform of endpoint.

[HKLM_]

Blokker_1999 schreef op maandag 8 juni 2026 @ 20:18:
Omdat we volgende week een kick-off hebben voor Azure Virtual Desktops en de komende maanden honderden van die desktops gaan deployen, waarbij ze ook in Intune gaan komen ben ik deze week begonnen met door alle config in Intune te gaan, en ik vroeg me daarbij af hoe anderen hun omgeving organiseren. Splitsen jullie policies op per type van endpoint en maak je daarmee bepaalde policies meervoudig aan, of is de primaire bepaling wat een policy doet en passen jullie gewoon de assignments aan?

Die vraag kwam ineens bij mij op toen ik de lijst trok van policies die simpelweg op "All Devices" is geplaatst terwijl ik weet dat een deel van die policies niet meer overal van toepassing zullen mogen zijn. Geen BitLocker op AVD bijvoorbeeld, maar ook een powerplan is niet van toepassing op een virtuele machine.

Mischien ben ik gewoon te ver aan het gaan met hierover na te denken, maar aangezien ik nu toch weer alles moet vastnemen, is het het goede moment om eens grote kuis te houden.

Ik gebruik geen all devices en all users, ik maak policies aan per profile type waarbij ik de groep koppel welke ook aan het autopilot profiel is gekoppeld.

Voor bijvoorbeeld Shared devices of Windows 365 doe ik hetzelfe met copy policies en de entra id group.

Filters kan ook maar op deze manier met policies per type kan ik makkelijk device type specifieke aanpassingen maken.

[Dirtyrockers]

Blokker_1999 schreef op maandag 8 juni 2026 @ 20:18:
Omdat we volgende week een kick-off hebben voor Azure Virtual Desktops en de komende maanden honderden van die desktops gaan deployen, waarbij ze ook in Intune gaan komen ben ik deze week begonnen met door alle config in Intune te gaan, en ik vroeg me daarbij af hoe anderen hun omgeving organiseren. Splitsen jullie policies op per type van endpoint en maak je daarmee bepaalde policies meervoudig aan, of is de primaire bepaling wat een policy doet en passen jullie gewoon de assignments aan?

Die vraag kwam ineens bij mij op toen ik de lijst trok van policies die simpelweg op "All Devices" is geplaatst terwijl ik weet dat een deel van die policies niet meer overal van toepassing zullen mogen zijn. Geen BitLocker op AVD bijvoorbeeld, maar ook een powerplan is niet van toepassing op een virtuele machine.

Mischien ben ik gewoon te ver aan het gaan met hierover na te denken, maar aangezien ik nu toch weer alles moet vastnemen, is het het goede moment om eens grote kuis te houden.

gaat het om multi session devices?
Als dat zo is dan kan je daar een dynamische groep maken met bijv de query: (device.operatingSystemSKU -eq "Enterprise multi-session")

en met single zou ik een groep maken met: (device.operatingSystem -eq "Windows") and (device.deviceName -startsWith "AVD-")

[Drardollan]

Blokker_1999 schreef op maandag 8 juni 2026 @ 20:18:
Omdat we volgende week een kick-off hebben voor Azure Virtual Desktops en de komende maanden honderden van die desktops gaan deployen, waarbij ze ook in Intune gaan komen ben ik deze week begonnen met door alle config in Intune te gaan, en ik vroeg me daarbij af hoe anderen hun omgeving organiseren. Splitsen jullie policies op per type van endpoint en maak je daarmee bepaalde policies meervoudig aan, of is de primaire bepaling wat een policy doet en passen jullie gewoon de assignments aan?

Die vraag kwam ineens bij mij op toen ik de lijst trok van policies die simpelweg op "All Devices" is geplaatst terwijl ik weet dat een deel van die policies niet meer overal van toepassing zullen mogen zijn. Geen BitLocker op AVD bijvoorbeeld, maar ook een powerplan is niet van toepassing op een virtuele machine.

Mischien ben ik gewoon te ver aan het gaan met hierover na te denken, maar aangezien ik nu toch weer alles moet vastnemen, is het het goede moment om eens grote kuis te houden.

Ik splits policies per type en per OS. Dus bijvoorbeeld:

Device - Windows - PolicyX
User - Windows - PolicyX
Device - iOS- PolicyX
User - iOS- PolicyX

En dan heb ik daar weer groepen aan hangen.

Zoals ik al jaren gewend ben vanuit traditionele GPO's houd ik de policies zo klein mogelijk. Een policy voor Bitlocker bevat enkel settings voor Bitlocker. Een policy om New Outlook uit te schakelen bevat alleen die optie. Hoe minder erin zit, hoe minder er fout kan gaan is mijn les uit het verleden. Liever kleine hapklare brokjes dan 1 massa.

[Blokker_1999]

Dirtyrockers schreef op dinsdag 9 juni 2026 @ 14:53:
[...]

gaat het om multi session devices?
Als dat zo is dan kan je daar een dynamische groep maken met bijv de query: (device.operatingSystemSKU -eq "Enterprise multi-session")

en met single zou ik een groep maken met: (device.operatingSystem -eq "Windows") and (device.deviceName -startsWith "AVD-")

Dynamische groepen kan nog beter. Ik ga groepen maken gebasseerd op de Azure Resourcegroup dat de VMs inzitten. Dat maakt het relatief eenvoudig om specifieke groepen van VMs als target te nemen.

[Dirtyrockers]

Blokker_1999 schreef op dinsdag 9 juni 2026 @ 16:29:
[...]

Dynamische groepen kan nog beter. Ik ga groepen maken gebasseerd op de Azure Resourcegroup dat de VMs inzitten. Dat maakt het relatief eenvoudig om specifieke groepen van VMs als target te nemen.

Dat is ook een optie inderdaad:

(device.devicePhysicalIds -any (_ -startsWith "[AzureResourceId]:/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-avd-prod-weu/providers/Microsoft.Compute/virtualMachines/"))

[nextware]

Is er iets veranderd bij het gebruik van Scripts & Remediations ? Plotseling geven de scripts die we hierin draaien een melding over "issue has reoccured".. Terwijl ze voorheen wel zonder problemen hebben gefunctioneerd.

[Blokker_1999]

Maar is het niet mogelijk dat het probleem gewoon is teruggekeerd? Want de proactive remediations zijn nu ook weer niet bedoeld voor het eenmalig uitvoeren van een script, daar heb je dan weer Platform Scripts voor.

[nextware]

Blokker_1999 schreef op woensdag 10 juni 2026 @ 11:08:
Maar is het niet mogelijk dat het probleem gewoon is teruggekeerd? Want de proactive remediations zijn nu ook weer niet bedoeld voor het eenmalig uitvoeren van een script, daar heb je dan weer Platform Scripts voor.

Dit zijn wel scripts die regelmatig (moeten) draaien. De platformscripts gebruiken we voor enkele losse zaken mbt AutoPilot deployment.

Maar ik heb gemerkt dat als we een kleine wijziging in de "description" aanpassen de taken wel weer goed worden weergegeven qua resultaat. Wellicht hik op de backend..

[Tha_T]

Toch mooi dat InTune, kan nog eens wat worden .

Klant van ons had de vraag hoe we ervoor konden zorgen dat een aantal formulieren offline beschikbaar zijn op een set Windows-tablets. Via PowerShell en een beetje GitHub magie een "app" gemaakt. Gekoppeld aan de groep tablets. En het doet het ook nog.

Jammer alleen dat de uitrol van de "app" onmogelijk te beheren is als je de installation deadline op ASAP zet.
_{Ja ik weet dat iedere device bij check-in gaat installeren maar daar kan dus 8 uur in zitten}

[Dronium]

Tha_T schreef op donderdag 11 juni 2026 @ 15:56:
Toch mooi dat InTune, kan nog eens wat worden .

Klant van ons had de vraag hoe we ervoor konden zorgen dat een aantal formulieren offline beschikbaar zijn op een set Windows-tablets. Via PowerShell en een beetje GitHub magie een "app" gemaakt. Gekoppeld aan de groep tablets. En het doet het ook nog.

Jammer alleen dat de uitrol van de "app" onmogelijk te beheren is als je de installation deadline op ASAP zet.
_{Ja ik weet dat iedere device bij check-in gaat installeren maar daar kan dus 8 uur in zitten}

Die 8 uurs periode is ook via een Device configuration profile aan te passen, met 30 minuten als ondergrens:

[Drardollan]

Dronium schreef op donderdag 11 juni 2026 @ 16:14:
[...]

Die 8 uurs periode is ook via een Device configuration profile aan te passen, met 30 minuten als ondergrens:
[Afbeelding]

Zonder die instelling (al heb ik hem iets ruimer staan meestal) is Intune vrij waardeloos om mee te werken. Dan kan het inderdaad zomaar 8 uur duren voor alles er doorheen komt. Het is de eerste instelling die ik binnen elke nieuwe Intune configureer eigenlijk.

[HKLM_]

Ik zie wat post over de 8-Hour Myth en dit is iets wat al jaren rond gaat en in het begin misschien zeker zo wat maar momenteel echt niet meer geroepen kan worden omdat het niet waar is.

• Myth: App and policy changes take 8-hours to apply
• Reality: Intune processes 90% of device changes in less than an hour
• How: The commonly cited “8‑hour” timing reflects a routine maintenance check‑in — not how Intune delivers meaningful changes today. Most high-impact app deployments, policy updates, and device actions are delivered through prioritized, change‑based delivery paths that typically reach online devices much faster. By distinguishing these time-sensitive changes from routine maintenance activity and handling them differently, Intune helps reduce the likelihood that important changes aren’t unnecessarily delayed.

Als je verder wilt weten hoe het echt zit dan zijn onderstaande blog posts zeker de moeite waard.
Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions | Microsoft Community Hub

Intune Sync and Policy Delivery: Debunking the 8 Hour Myth

Deze 18 minuten video van Microsoft: Intune 'fast lane' - Let's talk about all things latency – Microsoft Technical Takeoff is ook zeker de moeite waard als je niet goed begrijpt hoe Intune aan de achterkant werkt i.c.m de verschillende check-ins en hoe zaken vanuit de cloud naar je device komen.

[ Voor 10% gewijzigd door HKLM_ op 12-06-2026 09:48 ]

[HKLM_]

Dronium schreef op donderdag 11 juni 2026 @ 16:14:
[...]

Die 8 uurs periode is ook via een Device configuration profile aan te passen, met 30 minuten als ondergrens:
[Afbeelding]

Dit is niet hoe het werkt, Config refresh zorgt niet voor een intune sync, config refresh doet een check-in om te controlleren of de door intune beheerde instellingen op het device nog overeenkomen met de intune configuratie en past deze aan als het niet zo is. Het is een soort drift-control herstel mechanisme maar staat verder los van de Intune-sync voor nieuwe configuratie.

Deze setting werkt ook samen met de Device action: pause Config Refresh waarbij het mogelijk is om tijdelijk de enforcement van policy's / profielen op te schorten om te kunnen troubleshooten bijvoorbeeld. Na het verlopen van de time via pause config refresh zal config refresh het beleid weer terugzetten vanuit de drift-controlls.

[Blokker_1999]

Even een vraagje of het volgende scenario naar jullie mening technisch ondersteund wordt door Microsoft. Dit komt voort uit een interessante discussie die we hebben met de externe consultants die helpen bij het project.

We zijn met een pilot bezig voor het opzetten van Azure Virtual Desktops die Entra (non-hybrid) en Intune joined zijn. De AVDs zullen individueel zijn (geen multi-sessie, persoonlijke machines) en hoewel de personen die zullen aanmelden allen een E5 licentie hebben, zal het account waarmee zij gaan aanmelden, wat een privileged account is, geen licentie hebben. Dat is toch het doel.

Technisch lijkt dit te werken in mijn eerste test setup die ik aan het gebruiken ben om Intune een beetje op te kuisen, maar nu ging de discussie vandaag over het feit of dit technisch ondersteund wordt door Micorosft. De consultant zegt namelijk dat hij in het verleden gezien heeft dat de VM kan stoppen met in te checken op Intune omdat er geen gelicensieerde gebruiker op aanmeld. Hierdoor zou de AVD uit compliance vallen en ook geen nieuwe policies meer ophalen. Tot op heden zie ik evenwel gewoon netjes check-ins in het Intune portaal.

Als ik dan op die machine de Company Portal opstart, en aanmeld met mijn primair account, die dus wel een licentie heeft, wordt in de CP de machine ook netjes aangemerkt als een shared device. Dat zie je ook in Intune terug, geen primaire gebruiker geregistreerd. En het lijkt mij daarnaast ook dat als je bijv. een kiosk hebt die je beheert via MDM, dat daar ook nooit een gebruiker op gaat aanmelden die een licentiecheck in leven zou moeten houden.

De laatste opmerking van de consultant was dat het technisch mogelijks wel zou werken, maar als we ooit ondersteuning van MS zouden nodig hebben, dat zij dan zouden zeggen dat onze setup niet ondersteund is. En het is daar dat ik dus even voor wil vragen of iemand daar opheldering in kan brengen.

[Quad]

Als het als shared device vermeld staat, zou ik Intune device licenses in Je portaal hangen voor het aantal devices die je hebt. Ben je hoe dan ook compliant.

Als de gebruikers, zoals je zegt, ook een E5 licentie hebben, dan ben je ook compliant.

[ Voor 22% gewijzigd door Quad op 19-06-2026 22:21 ]

[grimson]

Autopilot, Locale settings, Timezone, en-us installatie media ('ISO') met autounattended.xml en Nederland .

Situatie:
Als voorstander van een kale windows installatie pak ik altijd de laatste maandelijkse (nl-nl) ISO en plaats deze op een USB stick en gebruik daarbij een autounattend.xml om de gehele installatie geautomatiseerd door te lopen. Incl. drivers en partitioneringen tot OOBE waarna Autopilot de rest oppakt maar nu de en-us ISO.

Daarbij staat in deze autounattend.xml o.a. bij OOBE (nu voor en-us):

<InputLocale>0409:00020409</InputLocale>
<SystemLocale>nl-NL</SystemLocale>
<UserLocale>nl-NL</UserLocale>
<UILanguage>en-US</UILanguage>

Dit geeft bij een installatie buiten autopilot om een mooie vernederlandste en-us installatie met de juiste locale settings als datumnotatie etc. en de juiste timezone én alleen maar één keyboardlayout; US Internationaal.

Maar ik heb gemerkt dat een deployment profile deze OOBE keuze overschrijft met de daarin gestelde instellingen met als standaard 'operating system default'. Dit betekend dat de locale settings dus eigenlijk terugvallen naar en-us en je moet klooijen om dit weer goed te zetten inclusief de timezone.

Nu kan je in een deployment profile ook 'Dutch' opgeven maar zover ik heb getest krijg je dan wel de NL locale settings maar weer het dubbele keyboard. 'US en US Internationaal oid.'
Tevens dacht ik alsnog de verkeerde timezone. Tevens zet je dan de locale 'vast' wat minder flexibel is lijkt mij.

Maar als je in het deployment profile bij OOBE opgeeft 'user select' dan betekend dit dat de vraag bij de gebruiker komt tijdens de OOBE fase. Alleen het mooie is dat deze vraag dus al is afgevangen door die autounattended.xml met de opgegeven locale settings. Nog steeds volledig silent dus . Omdat je dus dit bij de installatie neerlegt dus ook weer een pré dan het vast in te stellen in de deployment profile.
De locale settings in de autounattended niet overruled maar gehonoreerd! profit!

Resteert alleen nog de juiste timezone;
Mijn oplossing is om dit ook toe te voegen in de autounattend bij OOBE stap:

<TimeZone>W. Europe Standard Time</TimeZone>

Alhoewel dit ook mogelijk is met een CSP instelling is deze optie een voorkeursoptie, je zet het dus niet hard vast als een gebruiker alsnog de timezone wilt aanpassen. Ook het freubelen met de privacy en locatiesensor is dan niet nodig wat standaard uit staat.

Concreet om een beetje netjes zonder al te veel te hobbyen met regkeys en correctie scripts lijkt mij dit een prima oplossing?!?!


Copilot TL-DR:
TL;DR voor techneuten — Autopilot + Autounattend + Locale/Timezone gedrag

- Autopilot Deployment Profile OVERRULET Autounattend OOBE‑taalinstellingen, behalve wanneer je User Select kiest.

- User Select + Autounattend werkt wél samen → Autounattend bepaalt locale/keyboard, Autopilot stelt geen taal meer in.

- Autopilot “Dutch (Netherlands)” injecteert altijd NL‑keyboard → dubbele layouts (US + NL) maar past niet de juiste timezone toe.

- Autounattend + <TimeZone>W. Europe Standard Time</TimeZone> fixeert timezone zonder CSP, zonder privacy‑sensor gedoe.

- Resultaat:
- UI = en‑US
- Locale = nl‑NL
- Keyboard = US‑International
- Timezone = NL
- Geen dubbele layouts, geen scripts, geen reg‑hacks.

- Conclusie: User Select in Autopilot + correcte Autounattend.xml + TimeZone in OOBE = de cleanste, stabielste enterprise‑oplossing?

[ Voor 3% gewijzigd door grimson op 20-06-2026 08:21 ]

[Quad]

OSDCloud gebruiken met postinstallatiescript of een Intune remediationscript die een tag wegschrijft na een gelukte aanpassing.

[grimson]

Quad schreef op zaterdag 20 juni 2026 @ 08:28:
OSDCloud gebruiken met postinstallatiescript of een Intune remediationscript die een tag wegschrijft na een gelukte aanpassing.

Remediation is helaas een extra betaalde optie als je het netjes wilt doen (en MS Business Prem vind men al duur, MSP hier hè ). En die andere opties lijken dus de scripts post installatie hacks die met deze 'officiele/native' manier niet nodig lijkt te zijn. Ik prefereer het liefst zo min mogelijk 'hacks' of 'corrigerende scripts'. Maar dank voor de suggestie hoor!

[ Voor 5% gewijzigd door grimson op 20-06-2026 08:38 ]

[Quad]

grimson schreef op zaterdag 20 juni 2026 @ 08:36:
[...]

Remediation is helaas een extra betaalde optie als je het netjes wilt doen (en MS Business Prem vind men al duur, MSP hier hè ). En die andere opties lijken dus de scripts post installatie hacks die met deze 'officiele/native' manier niet nodig lijkt te zijn. Ik prefereer het liefst zo min mogelijk 'hacks'.

Ik heb deze week ipv remediation, Intunewin met powershellscripts gebruikt. Doet hetzelfde als een remediationscripts.

Maar goed, dat doet in OOBE nog niets. En dan zou ik OSDCloud gebruiken. Bij ons gebruiken we het nu een jaartje, gaat perfect. Nieuwe installaties zijn in elk geval in de OOBE al bij met de laatste W11 versie en CU. Zonder elke keer nieuwe USB sticks te maken.

[ Voor 18% gewijzigd door Quad op 20-06-2026 08:41 ]

[grimson]

Quad schreef op zaterdag 20 juni 2026 @ 08:39:
[...]

Ik heb deze week ipv remediation, Intunewin met powershellscripts gebruikt. Doet hetzelfde als een remediationscripts.

Wat ik mij nog bedenk is dat 'mijn' methode alleen voor de initiële installatie geld. Stel dat je een autopilot reset doet van het device naar weer een verse OOBE, dan zal vermoedelijk wel een script nodig zijn want nu geen unattended.xml oid, of nee, wacht .. 'ask user'.. achja .. dan wel vermoedelijk een popup maar wel de juiste instellingen dan.
Maar ieder zijn eigen oplossing, als het resultaat maar naar wens is. Alleen als MSP'er is het soms ad-hoc werken en is er geen gehele inspoelstraat bij klanten aanwezig. Dan het liefst een universele USB stick die na ~10 minuten ook een verse install heeft uitgevoerd.

[ Voor 20% gewijzigd door grimson op 20-06-2026 09:22 ]

[Blokker_1999]

Quad schreef op vrijdag 19 juni 2026 @ 22:20:
Als het als shared device vermeld staat, zou ik Intune device licenses in Je portaal hangen voor het aantal devices die je hebt. Ben je hoe dan ook compliant.

Als de gebruikers, zoals je zegt, ook een E5 licentie hebben, dan ben je ook compliant.

De licentievraag is het probleem niet, vooral benieuwd of iemand aan de technische kant ervaring heeft en potentieel problemen ziet.

[HKLM_]

Blokker_1999 schreef op zaterdag 20 juni 2026 @ 18:07:
[...]

De licentievraag is het probleem niet, vooral benieuwd of iemand aan de technische kant ervaring heeft en potentieel problemen ziet.

Ik heb je vraag gelezen, moet er even over na denken / verifiëren. BRB 😛