Microsoft Intune ervaringentopic

[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 😛

[grimson]

Autopilot device hash met of zonder TPM‑informatie -> gevolgen voor User‑Driven vs Self‑Deploying

Ik ben bezig met het bekijken om via WinPE een autopilot device hash te verkrijgen.
Dit is mogelijk maar het blijkt dat de hash ook specifieke TPM informatie moet bevatten om naast 'user driven' ook 'self deployment' mogelijk te maken.

User driven deployment kan al snel met een eenvoudigere device hash maar dus voor self deployment situaties moet er iets van een TPM aanvulling aan de hash toegevoegd worden.

Deze informatie is voor mij interessant genoeg om hierop te verdiepen en heb een Reddit post gemaakt hierover. Tevens de vraag of de hash ooit bijgewerkt wordt maar dat vermoedde ik al van niet.

Concreet is het dus belangrijk om te weten dat een device hash soms geen TPM informatie kan hebben en zo dus niet voldoende is voor een self deploying situatie en de hash niet vanzelf wordt bijgewerkt in Autopilot (zover ik nu begrijp).

Heeft iemand dit hier meegemaakt en of informatie hierover of dit allemaal klopt?

[HKLM_]

Blokker_1999 schreef op vrijdag 19 juni 2026 @ 13:14:
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.

Ik denk dat dit belangrijk voor je is:

Intune treats Azure Virtual Desktop personal VMs the same as Windows Enterprise physical desktops. This treatment lets you use some of your existing configurations and secure the VMs with compliance policy and Conditional Access. Intune management doesn't depend on or interfere with Azure Virtual Desktop management of the same virtual machine. (Using Azure Virtual Desktop single-session with Microsoft Intune - Microsoft Intune | Microsoft Learn)

Als je de AVD netjes inschrijft via de Enroll the VM with Intune optie dan blijft het check-in meganisme bestaan zonder issues tussen AVD en de VM.

Licentie technisch zeg je ze hebben een E5 licentie maar als ik je goed begrijp zullen de users welke op de AVD aanmelden met een privileged account zonder licentie. De AVD is dan dus een PAW workstation? Begrijp ik dat goed?

Vanuit AVD wordt het device met "Device Credentials" aangemeld binnen Intune, als er dan vervolgens een gebruikter op aanmeld welke geen "User Credentials" licentie heeft dan heb je dus Intune Plan 1 Device-licenties nodig voor deze AVD machines om een supported / licentie supported omgeving te hebben.

Dan de E5 licentie, de Users welke een E5 licentie hebben kunnen inderdaad in de company portal en dan aanmelden etc maar Microsoft kijkt supported / licentie technisch naar de primaire gebruiker. De AVD heeft geen primaire gebruiker maar wel een E5 licentie en dit bijt elkaar een beetje. Als het er op aankomt dan zit je denk wel goed maar dit staat nergens echt duidelijk. Ik zou adviseren om de de Intune Plan 1 Device-licenties aanschaffen voor deze machines om zeker te zijn dat je goed zit mocht je ooit een audit krijgen of support nodig hebben.

[Blokker_1999]

@HKLM_, dankjewel hiervoor. Daar kunnen we weer mee verder en dat zal ik meenemen in mijn advies naar hogerop toe.

Technisch zouden we nog in Intune de primary user op de gebruiker kunnen zetten, maar een primary user in Intune wat een ander gebruikersaccount is dan wat er dagdagelijks op zal aanmelden wringt bij mij dan ook weer, en vermoedelijk ook bij MS . Het zal vermoedelijk weer wat extra geld worden dat naar MS zal vloeien, maar al tevreden dat er technisch geen beperkingen zijn.

[Blokker_1999]

Oh Microsoft, how I love to hate you.

Is er een eenvoudige manier om na te gaan in welke device configuration profiles een bepaalde setting is geplaatst?

Ik heb een conflict dat opgelost moet worden, want het is ridicuul. Er staat ergens in een policy gescoped dat na 5 minuten inactiviteit je Windows op slot moet, en voor laptops is dat super, maar niet voor AVDs, want die disconnecten. En ik krijg niet meer teruggevonden in welke policy dat ooit gezet is.

Oud worden, nergens goed voor

[Hero of Time]

Dat had je moeten oplossen met documentatie en goede omschrijving van je policies.

Zonder grappen verder, klik in Intune op het apparaat dat je wilt nakijken en klik dan op 'Configuration'. Je zal helaas elk item daar in moeten gaan om te zien welke je screen timeout heeft. Een andere oplossing ken ik niet.

[HKLM_]

Blokker_1999 schreef op maandag 6 juli 2026 @ 19:59:
Oh Microsoft, how I love to hate you.

Is er een eenvoudige manier om na te gaan in welke device configuration profiles een bepaalde setting is geplaatst?

Ik heb een conflict dat opgelost moet worden, want het is ridicuul. Er staat ergens in een policy gescoped dat na 5 minuten inactiviteit je Windows op slot moet, en voor laptops is dat super, maar niet voor AVDs, want die disconnecten. En ik krijg niet meer teruggevonden in welke policy dat ooit gezet is.

Oud worden, nergens goed voor

Zou je onder het AVD device object in Intune wel terug moeten vinden toch, daar zie je welke profiles er assigned zijn en ik doe de voorzichtige aanname dat ze een goede naam hebben

Als het veel werk is security copilot aanslingeren voor een half uurtje of alle policies even openen

[ Voor 6% gewijzigd door HKLM_ op 06-07-2026 20:26 ]

[FREAKJAM]

Blokker_1999 schreef op maandag 6 juli 2026 @ 19:59:
Oh Microsoft, how I love to hate you.

Is er een eenvoudige manier om na te gaan in welke device configuration profiles een bepaalde setting is geplaatst?

Ik heb een conflict dat opgelost moet worden, want het is ridicuul. Er staat ergens in een policy gescoped dat na 5 minuten inactiviteit je Windows op slot moet, en voor laptops is dat super, maar niet voor AVDs, want die disconnecten. En ik krijg niet meer teruggevonden in welke policy dat ooit gezet is.

Oud worden, nergens goed voor

Kijk eens in het troubleshooter dashboard. Daar wil je nog wel eens een conflict snel vinden. Is mijns inziens net wat beter ipv het overzicht van alle policies in je omgeving en daar downdrillen. Echt nagaan welke specifieke setting is toegepast via welke policy is een lastige

[ Voor 10% gewijzigd door FREAKJAM op 06-07-2026 20:33 ]

[Blokker_1999]

HKLM_ schreef op maandag 6 juli 2026 @ 20:26:
[...]

Zou je onder het AVD device object in Intune wel terug moeten vinden toch, daar zie je welke profiles er assigned zijn en ik doe de voorzichtige aanname dat ze een goede naam hebben

Als het veel werk is security copilot aanslingeren voor een half uurtje of alle policies even openen

Je zou dat verwachten, maar ook daar, slechts 1 conflict . Wel 3 errors die ik ook nog moet onderzoeken.



En waar blijft mijn security copilot als onderdeel van E5? Wel de Intune suite ondertussen, maar nog geen Copilot.

[ Voor 8% gewijzigd door Blokker_1999 op 06-07-2026 20:31 ]

[FREAKJAM]

Blokker_1999 schreef op maandag 6 juli 2026 @ 20:30:
[...]

Je zou dat verwachten, maar ook daar, slechts 1 conflict . Wel 3 errors die ik ook nog moet onderzoeken.

[Afbeelding]

En waar blijft mijn security copilot als onderdeel van E5? Wel de Intune suite ondertussen, maar nog geen Copilot.

Hier ook nog niet actief. Deadline was 30 juni. Hebben vorige week toch 1 SCU zelf aangezet, maar dan ga je echt direct (dus zonder benefit) 4$ per uur betalen ongeacht je gebruik.

[HKLM_]

Blokker_1999 schreef op maandag 6 juli 2026 @ 20:30:
[...]

Je zou dat verwachten, maar ook daar, slechts 1 conflict . Wel 3 errors die ik ook nog moet onderzoeken.

[Afbeelding]

En waar blijft mijn security copilot als onderdeel van E5? Wel de Intune suite ondertussen, maar nog geen Copilot.

Kan je het niet uit de naam van de policy halen waar het in zit?


Wat betreft security copilot, uhmm ja slowwwwww

[HKLM_]

FREAKJAM schreef op maandag 6 juli 2026 @ 20:36:
[...]

Hier ook nog niet actief. Deadline was 30 juni. Hebben vorige week toch 1 SCU zelf aangezet, maar dan ga je echt direct (dus zonder benefit) 4$ per uur betalen ongeacht je gebruik.

Wel je optimalisatie geconfigureerd in defender? Als je daar uitzet dat defender iedere keer een summary aanmaakt dan gaan je kosten omlaag

Je kan ook je SCU op 0 zetten en je overheat SCU op 1 dan verbruikt je alleen bij query’s Er zijn ondertussen wat tweaks

[ Voor 13% gewijzigd door HKLM_ op 06-07-2026 20:39 ]

[Blokker_1999]

HKLM_ schreef op maandag 6 juli 2026 @ 20:37:
[...]

Kan je het niet uit de naam van de policy halen waar het in zit?


Wat betreft security copilot, uhmm ja slowwwwww

Als ik het eenmaal vind gaat het weer zo een gevalletje zijn van : ah ja, natuurlijk dat die daar in zit . Morgen alle policies eens dumpen en snel doorzoeken op die manier. Dan vinden we hem wel.

[HKLM_]

Blokker_1999 schreef op maandag 6 juli 2026 @ 20:41:
[...]

Als ik het eenmaal vind gaat het weer zo een gevalletje zijn van : ah ja, natuurlijk dat die daar in zit . Morgen alle policies eens dumpen en snel doorzoeken op die manier. Dan vinden we hem wel.

Wat je zou kunnen doen bedenk ik mij net, connect met Microsoft graph via bijvoorbeeld de graph explorer en roep de policies aan. En doe dan een F5 + search.

via graph staat alles dan als json output en heb je wel alles bij elkaar.

[FREAKJAM]

HKLM_ schreef op maandag 6 juli 2026 @ 20:38:
[...]

Wel je optimalisatie geconfigureerd in defender? Als je daar uitzet dat defender iedere keer een summary aanmaakt dan gaan je kosten omlaag

Je kan ook je SCU op 0 zetten en je overheat SCU op 1 dan verbruikt je alleen bij query’s Er zijn ondertussen wat tweaks

Yep! Auto-summary hebben we inderdaad uitgezet. Die 2de tip is nog wel een slimme, iets om naar te kijken. Thanks!

[Blokker_1999]

Zonet even een dump gemaakt van alle policies, en dan op zoek naar de settings:

[Davidas]

Voor degene die op dit moment Enterprise State Roaming gebruiken:

ESR management is moving to Windows Backup for Organizations.

[Blokker_1999]

Ik heb em gevonden. Alweer een reden waarom ik AI haat. Zoveel rondjes gelopen, zoveel nagekeken en geen enkel antwoord te vinden. Ik gooi het uiteindelijk in Google, klik op de eerste reddit link die ik tegenkom en daar staat het.

Een compliance policy gaat niet alleen nakijken of een bepaalde setting geplaatst is, deze gaat ook afdwingen dat het er staat. En ik heb dus een compliance policy voor alle Windows systemen die zegt dat na 5 minuten inactiviteit het apparaat vergrendeld moet worden.

En dat is mijn conflict.

Intune mag hier wel eens duidelijker in zijn, of zelfs gewoon de compliance policy een lagere prioriteit geven. Zet je een policy die conlficteert, laat je device uit compliance gaan.

@Davidas, was het inderdaad deze week ook al ergens tegengekomen. Gelukkig lees ik nu dat eigenlijk enkel de plaats waar je iets beheerd veranderd, maar voor de rest alle settings wel behouden blijven. Als dat het is, dan wordt het weer zoeken de volgende keer we iets willen aanpassen.

Beetje zoals ze nu ook alles van Office weer naar config.office.com hebben getrokken nadat ze dat eerder ook in Intune beschikbaar hebben gemaakt terwijl ze Edge stilaan naar admin.cloud.microsoft proberen te brengen waar je niet alleen je configuratie van Edge kunt doen, maar ook rapportering kunt bekijken.

[HKLM_]

Davidas schreef op dinsdag 7 juli 2026 @ 12:14:
Voor degene die op dit moment Enterprise State Roaming gebruiken:

ESR management is moving to Windows Backup for Organizations.

Welke vanaf vandaag Windows settings backup and restore als naam heeft

https://techcommunity.microsoft.com/blog/Windows-ITPro-blog/windows-settings-backup-becoming-a-new-resilience-baseline/4530757

wel een goede van je met ESR dat die moved, mocht je feedback hebben op windows settings and restore let me know dan geef ik het door aan het product team 🙂

[ Voor 12% gewijzigd door HKLM_ op 07-07-2026 20:56 ]

[TheVMaster]

Blokker_1999 schreef op maandag 6 juli 2026 @ 20:30:
[...]

Je zou dat verwachten, maar ook daar, slechts 1 conflict . Wel 3 errors die ik ook nog moet onderzoeken.

[Afbeelding]

En waar blijft mijn security copilot als onderdeel van E5? Wel de Intune suite ondertussen, maar nog geen Copilot.

Je kunt natuurlijk ook gewoon zelf een skill bouwen die gebruik maakt van een LLM die vervolgens helpt met het troubleshooteN?

[Blokker_1999]

Je zou mijn history met M365 Copilot eens moeten zien rondom dit probleem

[HKLM_]

Blokker_1999 schreef op woensdag 8 juli 2026 @ 07:37:
Je zou mijn history met M365 Copilot eens moeten zien rondom dit probleem

Dan noem je er ook gelijk één 🤡

Ik had nog wel een andere vraag voor je, heb je voor je AVD setup de policies niet netjes gescheiden like -> “ AVD - Config refresh” ten opzichte van je andere policies? Bijvoorbeeld “ MWP - Config refresh”

als je wilt weten waarom ik prefixes like AVD, MWP etc let me know.

[ Voor 39% gewijzigd door HKLM_ op 08-07-2026 08:27 ]

[Blokker_1999]

De enige die is goedgekeurd in de organisatie

[ThinkPad]

Zien anderen die via een Intune policy een aangepaste NTP-server pushen, in het W11 control panel via de knop om de tijdserver aan te passen ook nog steeds 'time.windows.com' staan, of wel hun custom NTP server?

De 'Windows Time' service wordt ook niet gestart wat ik ook vreemd vind. (sc query w32time).

[ Voor 44% gewijzigd door ThinkPad op 09-07-2026 10:39 ]

[Davidas]

ThinkPad schreef op donderdag 9 juli 2026 @ 10:13:
Zien anderen die via een Intune policy een aangepaste NTP-server pushen, in het W11 control panel via de knop om de tijdserver aan te passen ook nog steeds 'time.windows.com' staan, of wel hun custom NTP server?

De 'Windows Time' service wordt ook niet gestart wat ik ook vreemd vind. (sc query w32time).

Ja, vanuit settings zie ik die ook maar als ik w32tm /query /configuration uitvoer dan krijg ik wel mijn custom NTP servers te zien.

[Blokker_1999]

En ineens zie je deze in het berichtencentrum MC1441767

Follow up to IT1431577: Recommended update KB5101684 Preview for Windows devices

 Action required by Jul 29, 2026

We wanted to provide a follow up on our previous communication IT1431577. While the impact was mitigated through an Intune service update, full remediation requires a client fix that is now available in the latest Windows cumulative update (KB5101684) Preview. We recommend installing this cumulative update broadly to ensure devices in your organization benefit from this platform-level improvement.

Men gaat dus ineens aanbevelen dat je als bedrijf een preview update gaat installeren in heel de firma

[HKLM_]

Het nieuwe Windows device sync status scherm komt met de 2607 release welke een deze dagen start een goede stap in de richting -> Check de blog voor info en plaatje als je het nog niet gezien hebt. What’s new in Microsoft Intune – July

[Davidas]

Wat gebruiken jullie om Autopilot hashes in bulk te verwijderen?

Moet namelijk een populatie hashes (zelfde group tag) gaan verwijderen in verband met overstap managed -> BYOD. Intune object moet ongemoeid blijven.

[Quad]

Davidas schreef op woensdag 12 augustus 2026 @ 11:07:
Wat gebruiken jullie om Autopilot hashes in bulk te verwijderen?

Moet namelijk een populatier hashes (zelfde group tag) gaan verwijderen in verband met overstap managed -> BYOD. Intune object moet ongemoeid blijven.

Werkt bulkselect niet voor je in het Autopilotscherm? Filter op grouptag en je bent er, denk ik.

[Davidas]

Quad schreef op woensdag 12 augustus 2026 @ 11:25:
[...]

Werkt bulkselect niet voor je in het Autopilotscherm? Filter op grouptag en je bent er, denk ik.

Gaat om zo'n 2500 entries, trekt het portal dit in één keer? Misschien dat ik het dan beter in batches van 100 ofzo kan doen.

[Dirtyrockers]

Davidas schreef op woensdag 12 augustus 2026 @ 11:37:
[...]

Gaat om zo'n 2500 entries, trekt het portal dit in één keer? Misschien dat ik het dan beter in batches van 100 ofzo kan doen.

Of misschien met powershell anders.

[YaYo86]

Quad schreef op woensdag 12 augustus 2026 @ 11:25:
[...]

Werkt bulkselect niet voor je in het Autopilotscherm? Filter op grouptag en je bent er, denk ik.

Dat scherm laat maar een subset zien, 25 per pagina ofzo.

Wij gebruiken een script, kan alleen de Github pagina niet meer vinden

[Davidas]

YaYo86 schreef op woensdag 12 augustus 2026 @ 13:16:
[...]

Dat scherm laat maar een subset zien, 25 per pagina ofzo.

Wij gebruiken een script, kan alleen de Github pagina niet meer vinden

Deze?

[akimosan]

Al eerder genoemd:

Ik gebruik daarvoor DeviceOffboardingManager sowieso een handige tool om in bulk devices uit Intune/EntraID/Autopilot te verwijderen

[Davidas]

akimosan schreef op woensdag 12 augustus 2026 @ 16:09:
Al eerder genoemd:

Ik gebruik daarvoor DeviceOffboardingManager sowieso een handige tool om in bulk devices uit Intune/EntraID/Autopilot te verwijderen

Maar in mijn casus mogen ze alleen uit Autopilot worden verwijderd, Intune object moet absoluut intact blijven totdat er een Windows reset wordt uitgevoerd.

[LopendeVogel]

Davidas schreef op woensdag 12 augustus 2026 @ 16:18:
[...]

Maar in mijn casus mogen ze alleen uit Autopilot worden verwijderd, Intune object moet absoluut intact blijven totdat er een Windows reset wordt uitgevoerd.

Via powershell de grouptag aanpassen?

[akimosan]

Davidas schreef op woensdag 12 augustus 2026 @ 16:18:
[...]

Maar in mijn casus mogen ze alleen uit Autopilot worden verwijderd, Intune object moet absoluut intact blijven totdat er een Windows reset wordt uitgevoerd.

Dat kan ook, je kunt in DeviceOffBoardingManager kiezen uit welke omgeving je devices wilt wissen. EntraID, Intune en Autopilot of slechts een selectie daarvan.

En nieuw is dat je optioneel ook nog kunt offboarden uit Defender for Endpoint.

[grimson]

TPM chip resetten?

Ik zie leven hier dus ik stel meteen een vraag die nu te boven schiet Sorry dat ik de meeste praat niet meedoet, eenvoudig omdat ik daar ook vaak niets aan kan bijdragen ..

Ik lees dat het resetten van de TPM chip een goed iets is eigenlijk om tijdens elke installatie uit te voeren. Dit kan geen kwaad (als je zeker weet dat de computer inderdaad opnieuw geïnstalleerd mag worden) en eigenlijk lees ik meer en meer dat het bijna een best practice gaat worden.

Alhoewel nog wat vraagjes alhoewel ik ook lees dat dit best practices is maar ikzelf heb dit nog niet toegepast, mede omdat het helaas misschien niet vaak voorkomt;

Anders dan in een corporate omgeving met goed beheerde systemen werk ik voor een MSP waarbij systemen eigenlijk worden doorgeschoven zonder de mijn voorkeur hebbende volledige wipe en reinstall en dan weer vers Autopilot in. In die keren dat ik dat wel heb gedaan heb ik opgemerkt dat hierbij een poging werd gedaan om de TPM chip te clearen en de zogenoemde Physical Presence Interface (PPI) tegenkwam wat dan tijdens een reboot aan de user vraagt om op een toets te drukken om daadwerkelijk de TPM te wissen. Maar bij nu weer aandacht gevend hieraan merk ik dat het niet erg is om deze PPI in de firmware uit te zetten zodat dus een TPM clear zonder user ACK mogelijk wordt. Ik kan begrijpen dat dit risico's met zich meebrengt als dat bijv. een gebruiker onverwacht de TPM chip kan resetten maar hiervoor moet je admin zijn om dit via het OS te initieren. Dus opnieuw goed gemanagde locked down computers kunnen het uitschakelen van deze PPI prima hebben.

Nu hier mijn vraag:
Schakelen jullie de PPI uit in de firmware zodat bij een TPM clear verzoek deze melding niet komt vanuit de firmware tijdens een intune wipe 'n reload?

Daarbij trek ik het verder:
Waarom niet bij elke verse herinstallatie meteen ook de TPM clearen (specialize fase van de setup via autounattended.xml)? Zover ik lees is het proces dat bij een Windows installatie de TPM ownership op zich neemt maar niet echt een reset of totale wipe van de TPM keys uitvoert. Dus waarom niet preventief. Ook lees ik dat er 'achterblijfsels' van TPM resten ook autopilot soms kan beinvloeden buiten de normal user driven enrollment scenarios.

Benieuwd hoe jullie het doen, met name de corporate admins?

[HKLM_]

Voor de mensen die Windows settings backup gebruiken, Microsoft heeft MC1458268 in het message center gezet met een link naar o.a de github pagina met scripts https://github.com/microsoft/windows-backup-admin-scripts om backup's in te zien en te verwijderen van gebruikers (als deze bijvoorbeeld uit dienst gaan)

Wel even goed de requirements lezen: Met GA kom je er niet, Microsoft 365 Backup Administrator is een verplichte rol, als je backups van users wilt managen.

[ Voor 3% gewijzigd door HKLM_ op 24-08-2026 20:31 ]

[Blokker_1999]

Maar waarom zou je van een gebruiker die uit dienst gaat de backup verwijderen? Voor zover mij bekend wordt alle data in de OneDrive van de gebruiker opgeslagen en verdwijnt deze dus automatisch met de OneDrive van die gebruiker.

[Dirtyrockers]

Blokker_1999 schreef op dinsdag 25 augustus 2026 @ 08:46:
Maar waarom zou je van een gebruiker die uit dienst gaat de backup verwijderen? Voor zover mij bekend wordt alle data in de OneDrive van de gebruiker opgeslagen en verdwijnt deze dus automatisch met de OneDrive van die gebruiker.

zie dat het in moscone center en chase center gehouden wordt.

wel cool, ik was daar afgelopen november met Microsoft Ignite.

[HKLM_]

Blokker_1999 schreef op dinsdag 25 augustus 2026 @ 08:46:
Maar waarom zou je van een gebruiker die uit dienst gaat de backup verwijderen? Voor zover mij bekend wordt alle data in de OneDrive van de gebruiker opgeslagen en verdwijnt deze dus automatisch met de OneDrive van die gebruiker.

Goedevraag, je ziet regelmatig dat OneDrive data van medewerkers voorzien is van governance, retention policies om data te bewaren. Als je daar he devices settings uit kan halen dan is dat mogelijk wel wenselijk want deze data hoeft bijvoorbeeld geen 7 jaar bewaard te blijven.

[Hero of Time]

Soms is Intune ook wel fucky met apps en supersedence. Om geen enorme wildgroei te krijgen met tig versies van een app die toch nooit meer geïnstalleerd kunnen worden was ik er een paar aan het opruimen. Ik package Notepad++ en alle installs zat op de meest recente tot m'n nieuwe versie. De andere versies wilde ik verwijderen, maar dan kon niet door supersedence. Het weghalen bij de versie die men heeft gaf mij niet de mogelijkheid om de versie ervoor te verwijderen. Ik moest daar eerst de supersedence van de versie daar weer voor weghalen.

Ik had ergens wel verwacht dat die link eerst verwijdert zou worden en daarna de app. Zeg maar 'delete on cascade' bij SQL. Maar nee, je moet eerst alle verwijzingen verwijderen voordat je het record zelf kan verwijderen.

Dus 1.0 > 1.1 > 1.4 > 2.0 > 2.2, als je alleen 2.2 wilt houden, moet je alle versies behalve 1.0 bijwerken om de supersedence te verwijderen. En 1.0 is pas te verwijderen als je 1.1 hebt aangepast.

[Quad]

@Hero of Time voor zulke apps gebruik ik nooit supersedence eigenlijk. Bestaande W32 app vervangen, en ik zet dan op detectie een detectionscript van bijv versie => 2.2.

[Hero of Time]

Dat is ook een optie. De eerste versie die ik ooit gepackaged had, had ik geen versie detectie op staan, alleen 'file exists'. Toen ik dat ging vervangen werd het dus niet bijgewerkt. En om een of andere reden ging het ook niet goed toen ik de detectie alsnog aanpaste naar versie.

We hebben ook Chrome en Firefox in de Company Portal staan. Firefox is de Store versie en zal dus altijd recent zijn, maar Chrome is de losse installer. Die update zichzelf (Firefox kan dat ook), waardoor ik ook niet de versie kan checken. Ergens had ik ook liever de losse installer voor Firefox aangeboden, maar daar is het nu ondertussen te laat voor.

Gelukkig hebben we niet zo heel veel packages met aparte versies, het is nu 7-zip, Notepad++ en UltraVNC zo even uit m'n hoofd.

[nextware]

Hero of Time schreef op dinsdag 25 augustus 2026 @ 20:05:
Dat is ook een optie. De eerste versie die ik ooit gepackaged had, had ik geen versie detectie op staan, alleen 'file exists'. Toen ik dat ging vervangen werd het dus niet bijgewerkt. En om een of andere reden ging het ook niet goed toen ik de detectie alsnog aanpaste naar versie.

Aanpassen van een detectie van een bestaande app binnen Intune werkt inderdaad niet. Als je "file exists" aanpast naar "file version" zal het niet werken. Als je detectie aanpast, altijd een nieuwe app aanmaken. Of je moet met scripts gaan werken die de GRS registeritems van het Intune package van je devices weggooit.. Maar dan ben je vele malen sneller door een nieuwe applicatie aan te maken binnen Intune.

[Hero of Time]

nextware schreef op dinsdag 25 augustus 2026 @ 20:34:
[...]

Aanpassen van een detectie van een bestaande app binnen Intune werkt inderdaad niet. Als je "file exists" aanpast naar "file version" zal het niet werken. Als je detectie aanpast, altijd een nieuwe app aanmaken. Of je moet met scripts gaan werken die de GRS registeritems van het Intune package van je devices weggooit.. Maar dan ben je vele malen sneller door een nieuwe applicatie aan te maken binnen Intune.

Dat is dus wat ik doe met N++ e.d. Nieuwe versie, supersedence voor auto-update en later de oude verwijderen. Maar door die supersedence kan je dus zo'n idiote reeks krijgen dat je eerst 5 apps moet bijwerken voordat je ze kan verwijderen. Dat moet toch eenvoudiger kunnen? Als app B is ingesteld om app A te vervangen, zou die link tegelijk met app B zelf weg moeten gaan, ipv dat je eerst die link moet breken om B te kunnen verwijderen. Want A kan je ook niet zomaar verwijderen zonder de link bij B weg te halen.

[akimosan]

@Hero of Time In plaats van complete apps aan te maken kun je ook een Win32 app aanmaken die bijvoorbeeld Chrome Enterprise via winget installeert.

App bevat dan 3 scripts: een detection script welke controleert of Chrome is geïnstalleerd, een install script en een uninstall script. Hele package is dan maar een paar KB groot. Je kunt me een DM sturen en dan wil ik de scripts die ik hiervoor zelf gebruik wel met je delen.

Voordeel is dat nieuwe installs altijd de meest recente versie van de browser krijgen en de Google Updater werkt dan de versies bij. Je hebt er dan verder geen onderhoud aan.

je kunt de scripts ook als basis gebruiken voor een remediation script.

Stel dat je Notepad++ installeert via winget. Het eerste gedeelte is simpel, scripts zonder aanpassing die in de basis dit doen:

winget install --exact --id Notepad++.Notepad++ --silent --accept-package-agreements --accept-source-agreements --scope=machine

Updates kunnen met een remediation script, kleine aanpassing in de detection die controleert of versie nummer overeenkomt met de meest recente versie in winget: true? doe niets, false? run

winget update --exact --id Notepad++.Notepad++ --silent

Beter maak je een remediation script wat een lijst aan apps checked en bijwerkt, dan ben je in 1x klaar.

Maar in de basis is dat het, grotendeels self-maintaining

[ Voor 38% gewijzigd door akimosan op 25-08-2026 21:23 ]

[Hero of Time]

@akimosan, Chrome is het probleem niet. Die update zichzelf en als ik 't niet vergeet vervang ik 'm eens met een meer recente installer. Het ging mij om apps die niet zelf kunnen updaten of admin machtigingen nodig heeft daarvoor (N++ heeft een updater, maar roept in principe gewoon de installer aan met admin rechten bij de gebruiker).

Zaken als winget klinken aardig, maar is alsnog weer een dienst van derden die je maar net moet vertrouwen, hopen dat het de juiste bron pakt, etc.

Edit:
Je komt nu met remediation. Vergeet die zut aub, we hebben geen licenties met de 1001 opties van MS waar je €150 per gebruiker voor neer mag leggen. We doen het met BP.

[ Voor 15% gewijzigd door Hero of Time op 25-08-2026 21:27 ]

[Gr4mpyC3t]

Hero of Time schreef op dinsdag 25 augustus 2026 @ 21:26:

Zaken als winget klinken aardig, maar is alsnog weer een dienst van derden die je maar net moet vertrouwen, hopen dat het de juiste bron pakt, etc.

https://github.com/microsoft/winget-cli

En die bron kies je zelf natuurlijk.

[akimosan]

Dat valt wel te controleren zo lang je de apps en repos vantevoren zelf even checked.

De manifests van apps kun je immers vantevoren checken of de source wel betrouwbaar is.

Voor Chrome en Notepad++ :

winget-pkgs/manifests/g/Google/Chrome/151.0.7922.174/Google.Chrome.installer.yaml at master · microsoft/winget-pkgs · GitHub

winget-pkgs/manifests/n/Notepad++/Notepad++/8.9.8/Notepad++.Notepad++.installer.yaml at master · microsoft/winget-pkgs · GitHub

Daarin staan de hashes en de download sources ook vermeld. Winget controleert ook de hash aan de hand van de manifest en als dat niet klopt gaat hij niet installeren.

Met de exactID check installeer je natuurlijk enkel de app die je kiest en als je nog meer controle wilt, kun je gebruikmaken van een private repo (maar dan zijn er ook andere 3rd party en ik vind praktischer alternatieven.)

En natuurlijk kan een Github account van een opensource app gehacked worden of gekaapt, maar dat risico loop je met handmatig downloaden ook. Met je Firefox app uit de Microsoft Store loop je min of meer hetzelfde risico.

In jouw situatie installeer je dus eerst een verouderde versie van Chrome en laat je die daarna pas updaten? Is dat veiliger?

[Hero of Time]

An sich mooie oplossingen. Maar het beantwoord nog niet echt m'n vraag of er een minder omslachtige manier is om oude apps in Intune te verwijderen als er supersedence is gebruikt. Nee is m'n eigen antwoord, maar misschien dat jullie een andere hadden. Gezien de alternatieven, is dat dus niet het geval.

[Blokker_1999]

Voor zover mij bekend niet. Ik neem aan dat mensen die een externe tool gebruiken daar weer een voordeel hebben, want supersedence heeft natuurlijk ook een voordeel, namelijk dat de oude versie verborgen wordt in de CP en dat je gebruik kunt maken van de auto update functionaliteit voor apps die gebruikers handmatig uit de CP installeren.

[Blokker_1999]

akimosan schreef op dinsdag 25 augustus 2026 @ 21:12:
@Hero of Time In plaats van complete apps aan te maken kun je ook een Win32 app aanmaken die bijvoorbeeld Chrome Enterprise via winget installeert.

App bevat dan 3 scripts: een detection script welke controleert of Chrome is geïnstalleerd, een install script en een uninstall script. Hele package is dan maar een paar KB groot. Je kunt me een DM sturen en dan wil ik de scripts die ik hiervoor zelf gebruik wel met je delen.

Voordeel is dat nieuwe installs altijd de meest recente versie van de browser krijgen en de Google Updater werkt dan de versies bij. Je hebt er dan verder geen onderhoud aan.

je kunt de scripts ook als basis gebruiken voor een remediation script.

Stel dat je Notepad++ installeert via winget. Het eerste gedeelte is simpel, scripts zonder aanpassing die in de basis dit doen:

winget install --exact --id Notepad++.Notepad++ --silent --accept-package-agreements --accept-source-agreements --scope=machine

Updates kunnen met een remediation script, kleine aanpassing in de detection die controleert of versie nummer overeenkomt met de meest recente versie in winget: true? doe niets, false? run

winget update --exact --id Notepad++.Notepad++ --silent

Beter maak je een remediation script wat een lijst aan apps checked en bijwerkt, dan ben je in 1x klaar.

Maar in de basis is dat het, grotendeels self-maintaining

Met je remediation heb je dan wel nog 1 moeilijkheid, apps zoals NPP mogen niet draaien wanneer ze geupdate worden. Dat kan soms ook wel eens een moeilijke zijn.

[ralpje]

* ralpje lacht in PatchMyPC.

Die houdt voor ons van al dat soort apps netjes de updates bij, regelt de supersedence en zorgt dat 3 oude versies in Intune beschikbaar blijven en oudere automatisch worden opgeruimd.

Ja, het kost geld. Maar onder de streep scheelt het ons zoveel werk bij het bijhouden en repackagen van al die apps (en de updates) dat we dat lachend terugverdienen.

[nextware]

Of je Intune app pushen mbv een Powershell die eerst oude versies detecteert, die verwijderd en daarna de installatie uitvoert ?

Of kijken naar andere applicatie push systemen, zoals bijvoorbeeld een PDQ Connect waar de door PDQ Connect gepubliceerde applicaties (zoals Chrome en Notepad++) automatisch worden bijgewerkt als deze via een Automation zijn gepushed op de devices.

[ Voor 49% gewijzigd door nextware op 26-08-2026 10:16 ]

[Blokker_1999]

@ralpje , probleem voor ons is te veel software die je niet snel gaat vinden in dat soort oplossingen.

[akimosan]

@Blokker_1999 :
Robopack ondersteunt in ieder geval het gebruik van custom packaging met QA testing, dus je kunt in principe je eigen installers ook toevoegen aan een patchflow (en Robopack vervolgens de rest in Intune afhandelt, inclusief aanmaken van de apps en opruimen van supersedence)

offtopic:
Daar ga ik zelf ook nog eens naar kijken want ik heb ook nog een paar installers die ik nu handmatig bijhoud en zelf package. Ik zal mijn ervaringen delen.

De bibliotheek van ondersteunde apps in Robopack/PatchMyPC/PDQ Connect en vergelijkbare diensten is ook best groot. Sowieso vaak alles wat in winget/MS store zit en meer.

En zie het zo: als een grasmaai robot 90% van het grasveld maait en je nog maar 10% nog met de hand moet doen, kan het toch een nuttige investering zijn

[akimosan]

Iemand die ook problemen ervaart met devices die plots verwijderd worden uit Intune?

We zien vandaag het aantal Windows devices teruglopen in onze tenant. Auditlog laat het volgende zien:

Activity
Date: 8/31/2026, 9:33 AM
Activity Type: Update device
Correlation ID: <id>
Category: Device
Status: success
Status reason
User Agent
Initiated by (actor)
Type: Application
Display Name: Device Registration Service
App ID
Service principal ID: <id>
Service principal name
Additional Details
DeviceId: <id>
DeviceOSType: Windows
DeviceTrustType: AzureAd

Vervolgens wat Modified attributes, New value

Target / PropertyName / Old Value / New Value

<devicename> / TargetId.DeviceId / / <id>

<devicename> / TargetId.DeviceOSType / / "Windows"

<devicename> / TargetId.DeviceTrustType / / "AzureAd"

[GrasshopperNL]

akimosan schreef op maandag 31 augustus 2026 @ 09:55:
Iemand die ook problemen ervaart met devices die plots verwijderd worden uit Intune?

We zien vandaag het aantal Windows devices teruglopen in onze tenant. Auditlog laat het volgende zien:

Activity
Date: 8/31/2026, 9:33 AM
Activity Type: Update device
Correlation ID: <id>
Category: Device
Status: success
Status reason
User Agent
Initiated by (actor)
Type: Application
Display Name: Device Registration Service
App ID
Service principal ID: <id>
Service principal name
Additional Details
DeviceId: <id>
DeviceOSType: Windows
DeviceTrustType: AzureAd

Vervolgens wat Modified attributes, New value

Target / PropertyName / Old Value / New Value

<devicename> / TargetId.DeviceId / / <id>

<devicename> / TargetId.DeviceOSType / / "Windows"

<devicename> / TargetId.DeviceTrustType / / "AzureAd"

Mogelijk heb je een device cleanup rule staan.

[akimosan]

Sorry, dat was ik vergeten te vermelden. Nee geen device cleanup rule voor Windows devices (enkel voor Android)

[Blokker_1999]

De vraag wordt dan al snel: zijn ze ook effectief verwijderd en hebben je gebruikers er last van of is het een probleem met het portaal?

[akimosan]

Ik denk dat het wel iets van weergave is, want een sync/policy refresh via de Company Portal app op een device laat geen fouten zien.
Ook een dynamic device group in EntraID met daarin een query voor MDM+Windows laat het normale aantal devices zien. Maar uit de Portal "verdwijnen" ze dus.
De impact is beperkt tot gebruikers met een incompliant device. Normaliter lost onze servicedesk dat op met een device sync triggered vanuit de Intune portal, maar dat werkt nu dus niet meer.
En rapportages gaan ook over de zeik, uiteraard.

Ook de view https://admin.cloud.microsoft/#/IntuneDevices is bij ons compleet leeg.

[makooy]

akimosan schreef op maandag 31 augustus 2026 @ 09:55:
Iemand die ook problemen ervaart met devices die plots verwijderd worden uit Intune?

We zien vandaag het aantal Windows devices teruglopen in onze tenant. Auditlog laat het volgende zien:

Activity
Date: 8/31/2026, 9:33 AM
Activity Type: Update device
Correlation ID: <id>
Category: Device
Status: success
Status reason
User Agent
Initiated by (actor)
Type: Application
Display Name: Device Registration Service
App ID
Service principal ID: <id>
Service principal name
Additional Details
DeviceId: <id>
DeviceOSType: Windows
DeviceTrustType: AzureAd

Vervolgens wat Modified attributes, New value

Target / PropertyName / Old Value / New Value

<devicename> / TargetId.DeviceId / / <id>

<devicename> / TargetId.DeviceOSType / / "Windows"

<devicename> / TargetId.DeviceTrustType / / "AzureAd"

Is de "Primary user UPN" ook leeg in het "All devices" overzicht?
daar hebben wij last van, zie ook https://www.reddit.com/r/..._devices_by_primary_user/

[akimosan]

Ja, daar heeft het wel mee te maken, lijkt het.

Ik heb net de rol Intune Administrator geactiveerd (hebben we middels PIM ingeregeld) en dan floept mijn weergave terug naar +1000 devices.

Andere workaround (voor users zonder de Intune Admin role maar met een beperkte rol):

1. Vanuit de weergave van Windows Autopilot devices, zoek device op.
2. Klik serial number aan en vervolgens kun je klikken op Associated Intune device. Daar ziet ie hem dan weer wel en kun je de reguliere acties uitvoeren.

Phew..

Primary User UPN is wel leeg in de weergave Windows Devices, maar niet via de weergave die getoond wordt als je via Autopilot devices navigeert.

[ Voor 12% gewijzigd door akimosan op 31-08-2026 15:12 ]

[HKLM_]

Dat de Primary User UPN leeg was was mij al opgevallen vanmiddag, goed om te zien dat meer mensen er last van hebben. Wij hebben vanaf donderdag eigenlijk wat last van Intune welke met autopilot soms het device naam niet goed meegeeft vanuit het profiel... en het is traaaaaaaag

[repmeer]

akimosan schreef op maandag 31 augustus 2026 @ 14:53:
Ja, daar heeft het wel mee te maken, lijkt het.

Ik heb net de rol Intune Administrator geactiveerd (hebben we middels PIM ingeregeld) en dan floept mijn weergave terug naar +1000 devices.

Andere workaround (voor users zonder de Intune Admin role maar met een beperkte rol):

1. Vanuit de weergave van Windows Autopilot devices, zoek device op.
2. Klik serial number aan en vervolgens kun je klikken op Associated Intune device. Daar ziet ie hem dan weer wel en kun je de reguliere acties uitvoeren.

Phew..

Primary User UPN is wel leeg in de weergave Windows Devices, maar niet via de weergave die getoond wordt als je via Autopilot devices navigeert.

Er wordt een issue gemeldt op in de intune Portal dat hier mee te maken heeft

[nextware]

HKLM_ schreef op maandag 31 augustus 2026 @ 19:19:
Dat de Primary User UPN leeg was was mij al opgevallen vanmiddag, goed om te zien dat meer mensen er last van hebben. Wij hebben vanaf donderdag eigenlijk wat last van Intune welke met autopilot soms het device naam niet goed meegeeft vanuit het profiel... en het is traaaaaaaag

Ik zie vooral veel devices die in het deployment report een naam hebben "serial not listed"... Maar als ik zoek binnen de Windows Devices zie ik wel netjes het device met de correcte naam staan.. Wellicht update niet helemaal goed gegaan / getest / doorgevoerd ?