Microsoft Intune ervaringentopic

[HKLM_]

Blokker_1999 schreef op zaterdag 27 december 2025 @ 18:59:
En ineens werkt de Intune ODJ niet meer.

Enkele dagen terug probeer ik een laptop te enrollen in onze omgeving, en die faalt meerdere keren op een rij. Ik draai get-autopilotdiagnostics, en die geeft aan dat de ODJ faalt. Ik parkeer het even omdat het niet direct mijn grootste zorg is op dat moment. Gisteren zie ik dat een collega ook problemen heeft met andere laptops die ook gewoon falen. Dus vandaag maar even verder gekeken. Om te beginnen een upgrade doorgevoerd van de connectoren zodat die zeker weer mee zijn. Maar als ik vandaag mijn test laptop probeer te enrollen, en ik ga daarna op de connectoren kijken, dan zie ik rond het tijdstip dat ik de enrollment doe niet eens in de logs dat de ODJ blob wordt aangevraagd.

What the ... ?

En ja, we hebben geprobeerd om de machines volledig uit Intune en Entra te verwijderen, de hash opnieuw te harvesten enzoverder. Ook allemaal zonder resultaat.

Wel die connector “migratie” van een paar maanden geleden uitgevoerd?

[Dirtyrockers]

Blokker_1999 schreef op zaterdag 27 december 2025 @ 18:59:
En ineens werkt de Intune ODJ niet meer.

Enkele dagen terug probeer ik een laptop te enrollen in onze omgeving, en die faalt meerdere keren op een rij. Ik draai get-autopilotdiagnostics, en die geeft aan dat de ODJ faalt. Ik parkeer het even omdat het niet direct mijn grootste zorg is op dat moment. Gisteren zie ik dat een collega ook problemen heeft met andere laptops die ook gewoon falen. Dus vandaag maar even verder gekeken. Om te beginnen een upgrade doorgevoerd van de connectoren zodat die zeker weer mee zijn. Maar als ik vandaag mijn test laptop probeer te enrollen, en ik ga daarna op de connectoren kijken, dan zie ik rond het tijdstip dat ik de enrollment doe niet eens in de logs dat de ODJ blob wordt aangevraagd.

What the ... ?

En ja, we hebben geprobeerd om de machines volledig uit Intune en Entra te verwijderen, de hash opnieuw te harvesten enzoverder. Ook allemaal zonder resultaat.

Maak je ondertussen wel gebruik van de nieuwe connector? De oude is hierdoor niet meer bruikbaar.

[Hero of Time]

Maandag hebben wij nog een systeem uit de doos uitgerold met hybrid join, geen problemen. Collega had de dagen ervoor wel issues met het apparaat, uitrol faalde, maar zoals 'ie is geen verdere informatie erover en omdat de stappen daarna prima liepen niet verder naar gekeken wat er mis ging.

Maar ja, check dus of je de connector met service account gebruikt, ipv een die onder user en system context kan draaien.

[Blokker_1999]

Uiteraard, ik was zelfs diegene die hem hier destijds gepost heeft

Blokker_1999 in "Microsoft Intune ervaringentopic"

Vandaag wel geupdate naar de allernieuwste versie, wat een stuk vlotter ging dan de installatie begin dit jaar.

[Blokker_1999]

En vandaag probeer ik het met een VM, en die gaat wel gewoon goed 😖Back to the drawing board.

[Hero of Time]

Zal niet de eerste keer zijn dat er wat bij MS op de rug ligt met pootjes omhoog. En dan 99% van de gebruikers niets merken maar jij (algemeen gesproken) uiteraard wel.

[Blokker_1999]

Nope, blijkt user error te zijn

Apparaten die ingeleverd worden door gebruikers omdat ze uit dienst gaan kunnen 1 van 2 paden op gaan. Heel recente apparaten worden hergebruikt voor externe mensen van een laptop te voorzien terwijl wat oudere laptops op de stapel van reserve laptops gaan voor wanneer mensen hun laptop vergeten zijn of er een te ernstig defect is en we moeten wisselen.

En die rol, in combinatie met jaar van aankoop, zit gecodeerd in de hostname van het apparaat. Dat betekend dan ook dat we in Intune de nodige policies moeten opzetten. En daar is het mis gegaan. Bij het opzetten van de config voor spare devices, aangekocht in 2024, heb ik de verkeerde groep aan de policy gekoppeld. En blijkbaar heeft het tot eind December '25 geduurd voordat we de grouptag en bijhorende config voor het eerst gebruikten.

Deze apparaten kregen dus geen correcte domain join configuratie. Ze wisten dus wel, aan de hand van het deployment profiel dat er een hybrid join moest gebeuren, maar er was geen configuratie profiel dat deze laptops vertelde welk domein ze moesten vervoegen. Dat resulteert er dus in dat de laptop blijft wachten op zijn ODJ blob die nooit komt.

Zucht, wat zal ik blij zijn als ik van die hybride BS vanaf ben. Heb aan de manager van het client support team ook al aangegeven dat wanneer we naar non hybrid joins gaan, de naamgeving van laptops beter moet. De hostname mag niet langer dienstdoen als een vorm van asset management systeem. Ze moeten hun rommel maar in orde krijgen. Dat zij geen goed asset mgmt kunnen doen moet mijn leven niet moeilijker maken.

[Hero of Time]

De nieuwe naamgeving kan toch prima met de asset management matchen? 100% op basis van serienummer/asset tag. Dat ze nu iets als <merk><type><jaar_aankoop><ordernummer> gebruiken is al een slechte standaard. Of wat ze ook maar hebben bedacht.

[Blokker_1999]

Vandaag hebben we land/regio van aankoop, zodat we weten waar de factuur en garantie zitten, gevolgd door 2 cijfers van het jaar van aankoop. En dan gewoon de rest opgevuld met random. Toen ik bijna 3 jaar terug begon met het ontwerp evenwel, en er van hybride helemaal geen sprake was, was het doel inderdaad gewoon regio en serienummer van het toestel.

Dus vandaag heb je iets als EU23-aZ7pL9xQ3t

En de naamgeving moet in de basis met assetmgmt matchen. Je moet je toestel uiteraard eenvoudig kunnen terug vinden. Maar de reden waarom we deze naamgeving hanteren is net om de naam als asset mgmt te gaan gebruiken, in de zin van: om te bepalen hoeveel laptops we in 2026 moeten vervangen nemen we een lijst van alle actieve laptops die geen reserve zijn en niet zijn toegewezen aan externen en dan kijken we naar waar er 22 staat als derde en vierde karakter. En met behulp van de eerste 2 karakters kunnen we daarna de lijst uitsplitsen ove de verschilende regios zodat we weten hoe we dat in onze budgetering moeten opnemen. Want we vertrouwen de data in onze asset mgmt tool niet.

Pas op, en vroeger, voordat we AP deden was het nog erger, want toen hadden we ook in de EU voor elk land een aparte prefix, ook al werden ze voor Europa allemaal via HQ aangekocht, en was de naamgeving simpelweg land-YYMM## met ## een volgnummer, en als er in 1 maand in 1 regio meer dan honderd laptops werdena aangekocht dan begonnen we met A0, A1, ... . Leuke tijden. En toen we naar AutoPilot gingen vroegen ze of we jaar en maand konden behouden . Ik dacht het niet.

Daar komt die naamgeving vandaan, en daarom heb ik vandaag een 50-tal configuratie policies in mijn Intune zitten enkel en alleen voor de domain join uit elkaar te houden want elke prefix heeft zijn eigen configuratie uiteraard. En ja, dan durft je bij het aanmaken al wel eens de verkeerde groep linken aan de verkeerde policie. En ja, dat betekend ook dat voor elk van die policies er ook een unieke dynamische device groep moet zijn.

Ondertussen hebben ze hun asset mgmt gelukkig een stuk beter op orde en zou ik het eigenlijk nu al kunnen forceren naar een eenvoudigere naamgeving, maar aangezien het doel is om in 2026 werk te maken van non-hybrid joined apparaten, ga ik de nieuwe, vereenvoudige naamgeving koppelen aan die omschakeling en heb ik vandaag de prefixen met 26 maar toegevoegd.

[Quad]

Hier druk aan het testen met de E5 security add-on voor Business Premium.
Biedt echt wel wat voordelen merk ik maar ik mis toch één cruciaal dingetje bij de sensitivity labels; auto-labeling werkt helaas niet. Het moet manueel voor mail/documenten worden ingeschakeld, hoewel het wel te configureren valt, heb je toch de volledige E5 (of Microsoft 365 E5 Information Protection & Governance
add-on) nodig voor het detecteren van informatie in je actieve document en daar een automatisch label op te plakken.

Dat vind ik dan wel weer jammer.

[Davidas]

Heeft iemand hier App Control for Business al in bedrijf? Ik ben vooronderzoek aan het doen en heb het geconfigureerd in een acceptatie omgeving, de policies zeggen dat ze zijn doorgevoerd op mijn test systeem maar ik kan nog altijd alle applicaties runnen. Kan het liggen aan het feit dat ik test op een VM?

[Hero of Time]

We gebruiken UltraVNC voor een aantal zaken. Kwam er deze week achter dat er een paar nieuwe versies uit zijn gekomen sinds ik het gepackaged had. Nu heb ik die dus als nieuwe versie met supersedence toegevoegd in twee configuraties: viewer en server. De viewer gaat op zich nog wel, zeker als men die handmatig een zetje geeft voor installatie. Maar server is een dingetje die ik in de toewijzing verplicht, want specifieke systemen moeten die hebben en hebben geen gebruikers met licentie in principe. Werkt prima, maar de upgrade echter niet.

Initieel had ik de detection rule staan op 'bestand winvnc.exe bestaat'. Maar als je het wilt updaten, heb je daar natuurlijk niks aan. De melding die ik in Intune heb is "application was not detected after installation finished successfully". Als het succesvol geïnstalleerd zou zijn, zou de nieuwe versie erop moeten staan. Maar dat gebeurt dus niet.

Iemand enig idee hoe ik dit kan corrigeren? De detection rule van de oude versie heb ik al aangepast om te kijken naar de versie string ipv 'bestand bestaat'.

[akimosan]

Maak je gebruik van de installer?
Want dan kun je kijken naar install vanuit Winget (winget download ultravnc)
Dan vindt je daarin de manifest YAML file die geeft je de product code: Ultravnc2_is

Dan kun je dus op basis van registry check de detection doen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Ultravnc2_is1\
DisplayVersion: 1.6.4.0

[Hero of Time]

Ik gebruik de .msi die op de site wordt aangeboden. Omdat het om server gaat, gooi ik deze door een dom powershell script zodat de parameters voor onderdelen en wachtwoord wordt meegenomen.

Staat UltraVNC Server er nog niet op, dan gaat het goed. Maar het lijkt moeite te hebben met reeds bestaande installaties, terwijl het handmatig uitvoeren geen issue is. Misschien toch maar aanzetten om vorige versie te verwijderen voordat deze wordt geïnstalleerd. Wat mij ook doet herinneren dat het om onverklaarbare reden niet bij geïnstalleerde apps in het Instellingen scherm staat.

[YaYo86]

Hero of Time schreef op vrijdag 9 januari 2026 @ 20:32:
We gebruiken UltraVNC voor een aantal zaken. Kwam er deze week achter dat er een paar nieuwe versies uit zijn gekomen sinds ik het gepackaged had. Nu heb ik die dus als nieuwe versie met supersedence toegevoegd in twee configuraties: viewer en server. De viewer gaat op zich nog wel, zeker als men die handmatig een zetje geeft voor installatie. Maar server is een dingetje die ik in de toewijzing verplicht, want specifieke systemen moeten die hebben en hebben geen gebruikers met licentie in principe. Werkt prima, maar de upgrade echter niet.

Initieel had ik de detection rule staan op 'bestand winvnc.exe bestaat'. Maar als je het wilt updaten, heb je daar natuurlijk niks aan. De melding die ik in Intune heb is "application was not detected after installation finished successfully". Als het succesvol geïnstalleerd zou zijn, zou de nieuwe versie erop moeten staan. Maar dat gebeurt dus niet.

Iemand enig idee hoe ik dit kan corrigeren? De detection rule van de oude versie heb ik al aangepast om te kijken naar de versie string ipv 'bestand bestaat'.

Probeer eens om zowel de oude als de nieuwe dezelfde detection rule obv File version is Greater than or equal to. In theorie zou de oude dit moeten herkennen en de nieuwe installatie moeten afvuren. En anders inderdaad eerst de oude versie verwijderen, al dan niet icm de Detection rule obv File version is Greater than or equal to.

akimosan schreef op zaterdag 10 januari 2026 @ 16:13:
Maak je gebruik van de installer?
Want dan kun je kijken naar install vanuit Winget (winget download ultravnc)
Dan vindt je daarin de manifest YAML file die geeft je de product code: Ultravnc2_is

Dan kun je dus op basis van registry check de detection doen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Ultravnc2_is1\
DisplayVersion: 1.6.4.0

Winget ben ik zelf niet zo'n fan van, zeer regelmatig krijg je niet de laatste versie dan die op website van de ontwikkelaar staat.

[ Voor 17% gewijzigd door YaYo86 op 10-01-2026 17:26 ]

[Hero of Time]

YaYo86 schreef op zaterdag 10 januari 2026 @ 17:24:
[...]

Probeer eens om zowel de oude als de nieuwe dezelfde detection rule obv File version is Greater than or equal to. In theorie zou de oude dit moeten herkennen en de nieuwe installatie moeten afvuren. En anders inderdaad eerst de oude versie verwijderen, al dan niet icm de Detection rule obv File version is Greater than or equal to.

Zoals je in m'n initiële vraag hierboven al kan lezen, had ik bij het eerste package de detectie regel al aangepast van 'file exist' naar 'string (version) equals'. Maar dat zorgt er natuurlijk niet voor dat het wordt ververst bij de client zelf.

Nou heb ik met UltraVNC sowieso al wat gekke dingen meegemaakt eerder, waarbij ik eerst de viewer had geïnstalleerd, daarna de server wilde en constant de viewer kreeg terwijl ik die had verwijdert, zelfs via Company Portal stond dat 'ie er niet meer was. En als ik het handmatig deed, ging het prima. Dus ergens zat Intune te kloten met andere package en uit te voeren commando, omdat de installer zelf hetzelfde is tussen de twee packages (maar het script dat het aanroept anders is).

[YaYo86]

Hero of Time schreef op zaterdag 10 januari 2026 @ 20:35:
[...]

Zoals je in m'n initiële vraag hierboven al kan lezen, had ik bij het eerste package de detectie regel al aangepast van 'file exist' naar 'string (version) equals'. Maar dat zorgt er natuurlijk niet voor dat het wordt ververst bij de client zelf.

Nou heb ik met UltraVNC sowieso al wat gekke dingen meegemaakt eerder, waarbij ik eerst de viewer had geïnstalleerd, daarna de server wilde en constant de viewer kreeg terwijl ik die had verwijdert, zelfs via Company Portal stond dat 'ie er niet meer was. En als ik het handmatig deed, ging het prima. Dus ergens zat Intune te kloten met andere package en uit te voeren commando, omdat de installer zelf hetzelfde is tussen de twee packages (maar het script dat het aanroept anders is).

Ja de eerste package heb je aangepaast, de tweede niet. De nieuwe detection rule moet ie gewoon verversen op de client zelf, zoals jij dat noemt. Wat dus resulteert in een supercedence.

[Hero of Time]

YaYo86 schreef op zondag 11 januari 2026 @ 12:06:
[...]

Ja de eerste package heb je aangepaast, de tweede niet. De nieuwe detection rule moet ie gewoon verversen op de client zelf, zoals jij dat noemt. Wat dus resulteert in een supercedence.

De eerste heb ik aangepast omdat die niet naar versie keek. De tweede had ik direct met versie gemaakt. En bij de tweede de supercedence gezet voor de eerste. Doe hetzelfde met Notepad++, dat gaat prima. Maar daar had ik het al langer goed staan met de detection rules.

[Hero of Time]

Vanochtend gekeken, afgelopen zaterdag heeft 1 systeem het succesvol weten te installeren. Ander systeem waar we nog mee bezig zijn heeft het wel geïnstalleerd, maar om een of andere reden ook de viewer maar niet de service.

Omdat de rest nog staat op 'not detected' en ik nog andere zaken te doen had, heb ik er nog niet verder naar gekeken voor hoe en wat. Gelukkig staat de app op 'verplicht', dus als ik de huidige 1.6.4.0 eruit gooi en een uur later een nieuwe maak, komt het vanzelf wel weer goed denk ik.

[wErudite]

Wellicht dat iemand mij kan helpen in dit topic: wat is de beste manier om Bluebeam Revu te updaten? Ik krijg het tot nu toe nog niet voor elkaar via hun deployment guide....

[HKLM_]

wErudite schreef op maandag 12 januari 2026 @ 21:44:
Wellicht dat iemand mij kan helpen in dit topic: wat is de beste manier om Bluebeam Revu te updaten? Ik krijg het tot nu toe nog niet voor elkaar via hun deployment guide....

Waar loop je tegenaan?

[Hero of Time]

Vanmiddag op een systeem gekeken hoe de upgrade was toegepast. Het heeft geen enkele parameter meegenomen die ik er achter mee geef. Nu maar een nieuwe package gemaakt waarbij ik niet de .msi maar de .exe gebruik. Handmatig werkt het prima. Via script echter.... PoSh vind het blijkbaar niet leuk als je een exe aanroept via $PSScriptRoot\installer.exe in een script. Idiote inconsistenties tussen script en shell.

[Quad]

Iemand deze opties in Win32apps al geprobeerd?

[Blokker_1999]

Nog niet, maar het doel is in essentie waar @Hero of Time tegenaan loopt te verbeteren. Dan kan je namelijk je script bewerken nadat een pakket is gemaakt en geupload. Op die manier kan je eenvoudiger aanpassingen maken als het niet werkt. Zag gisteren ook dat het in productie is gezet, maar toch maar snel even de ouderwetse manier genomen omdat ik weet dat dat werkt

[grimson]

Quad schreef op woensdag 28 januari 2026 @ 10:34:
Iemand deze opties in Win32apps al geprobeerd?

Interessant, ik zag dit inderdaad al in de release notes.
In 'mijn' Developers tenant helaas nog 'Service release 2511' en nog niet deze optie.
Maar het zou fijn zijn om bijvoorbeeld een PS script die nu als win32 app de MS365 apps installer aanroept een stuk meer eh, 'native' te maken op deze manier. Topper!

[Hero of Time]

Quad schreef op woensdag 28 januari 2026 @ 10:34:
Iemand deze opties in Win32apps al geprobeerd?

[Afbeelding]

Zag het een paar weken geleden al. En vandaag maar eens gebruik van gemaakt. Gelijk 2 "problemen" mee:
1) Je moet een script uploaden, het er simpelweg in typen kan niet, dus snel code fixen als je geen toegang hebt tot het oorspronkelijke script is lastig. Het code veld is inactief en je kan er niks van selecteren (plus heel beperkt in ruimte), dus daar kan je het ook niet uit halen.
2) Er is geen syntax checker of wat dan ook, dus als je er allerlei onveilige of anderszins ongewenste code gebruikt, wordt dat gewoon geaccepteerd.

Voor punt 2 had ik graag wel een check gezien, want dan had ik veel sneller door dat er een typo in m'n script stond en ik geen uur kwijt was met debuggen en lezen van logs waar ik geen kloot wijzer van werd omdat het probleem daar helemaal niet werd getoond. Want stel je voor dat de melding die je zelf in de shell zou krijgen in de logs terecht zou komen.

Nu was mijn script maar een paar regels en zat de fout in het feit dat ik 'variabel' gebruikte ipv '$variabel', maar stel je voor dat je installatiescript een heel stuk uitgebreider is met vele checks. Succes om dan de fout te vinden.

Het is iig wel honderd keer makkelijker om wijzigingen toe te passen, want ik kan lokaal het script schrijven, ipv constant naar een Windows machine gaan om de intunewin te maken, resultaat naar m'n lokale machine halen en dat uploaden.

[Blokker_1999]

Maar dan stel ik mij de vraag: waarom test je je script niet voordat je het upload? En waarom maakt je script geen transcript dat je ergens wegschrijft zodat je weet wat de output van het script was?

Sowieso is de manier waarop het hier geimplementeerd is niet veel anders dan op andere plaatsen in Intune. Ook bij de proactive remediations moet je op deze manier met je scripts werken. Uploaden en niet editeerbaar. En daar heb je bijkomend nog het probleem dat er geen enkele output mag zijn in je detectie script of het wordt aanzien als iets dat opgelost moet worden.

Waarom men zo met scripts omgaat is mij een raadsel, maar het heeft wel 1 voordeel. Het is onmogelijk om per ongeluk een wijziging te maken in het script. En dat zou wel eens de reden kunnen zijn van waarom men het zo doet.

[DDX]

We rollen hier Keynote uit via intune, 'aangeschaft' via de appstore connectie binnen intune.
Werkt prima, tot gisteren Apple nieuwe versie heeft uitgebracht.
Nu heb ik in Apps op intune 2 pakketten staan :
Keynote, die netjes assigned is aan al devices.
'Keynote: ontwerp presentaties', die niet assigned is.

En via appstore idd ook 'Keynote: Design Presentations' :
https://apps.apple.com/us...presentations/id361285480

Leuk ook dat ze ook een nederlandse naam hebben (omdat we onze apple sync in Nederland hebben geconnect vermoed ik)
https://apps.apple.com/nl...-presentaties/id361285480

En op testmac met de hand installed via appstore, in Apps nu :
Keynote
Keynote Design Presentations

De eerste is 14.5, vandaag automatisch geupdate via de intune connectie die we hebben.
De tweede is 15.1...

Lekker hoor apple, gok als ik nu de Intune versie assign er 3 apps op komen....

edit: en meer info (en gebruikers die helemaal los gaan) waarom het nieuwe app is :
https://www.reddit.com/r/...s_keynote_why_you_need_a/

[ Voor 32% gewijzigd door DDX op 29-01-2026 15:47 ]

[Blokker_1999]

Is dat niet eerder een beslissing van de maker van de app om het een nieuwe naam en nieuwe ID te geven in de app store?

edit:
whoops, wist niet dat dit een Apple app was. Inderdaad niet goed van zo een bedrijf als Apple.

[ Voor 32% gewijzigd door Blokker_1999 op 29-01-2026 16:31 ]

[Hero of Time]

Blokker_1999 schreef op donderdag 29 januari 2026 @ 07:27:
Maar dan stel ik mij de vraag: waarom test je je script niet voordat je het upload? En waarom maakt je script geen transcript dat je ergens wegschrijft zodat je weet wat de output van het script was?

De commando's op zichzelf deden het prima, dat had ik ook getest. Maar als je je variabele verkeerd aanroept, gaat een transcript ook geen kloot uitmaken want die doet geen zak door de syntax error. En juist dát is waar ik zo'n hekel aan heb met het gebrek aan loggen van de IME. Ik had namelijk ook een transscript gebruikt toen de eerste versie niet werkte. Maar er kwam geen bestand waar ik het heen stuurde. Dan houdt het al heel snel op. En de verschillende IME logs zwijgen in alle talen, nergens zie je 'syntax error on line x' met het stukje waar de fout zit, zoals je dat wel in een interactieve shell ziet.

Maar ja, iedereen zit met de Powershell IDE te werken en daar zal vast en zeker een rode X bij de regel staan met fout. Maar die heb ik dus niet. Daarom had het wel zo fijn geweest om een check te hebben bij het uploaden. En het wordt nog leuker als je zelf met Powershell 7 bezig bent, daar je script mee maakt en dan keihard op de bek gaan omdat het niet met 5.0 van het OS zelf werkt. MaAr Je TeSt ToCh?! Ja, in je PoSh 7 shell werkt het fantastisch. Via Intune niet. Mooi he, testen?

Sowieso is de manier waarop het hier geimplementeerd is niet veel anders dan op andere plaatsen in Intune. Ook bij de proactive remediations moet je op deze manier met je scripts werken. Uploaden en niet editeerbaar. En daar heb je bijkomend nog het probleem dat er geen enkele output mag zijn in je detectie script of het wordt aanzien als iets dat opgelost moet worden.

Waarom men zo met scripts omgaat is mij een raadsel, maar het heeft wel 1 voordeel. Het is onmogelijk om per ongeluk een wijziging te maken in het script. En dat zou wel eens de reden kunnen zijn van waarom men het zo doet.

Ik zei ook niet dat het deal breaking is dat je niet kan editen in Intune zelf. Ik zei alleen dat het handig zou zijn. En snap ook wel het voordeel van deze manier. Maar zoals je zelf ook aangeeft, de manier hoe Intune met script om gaat is ruk. Daar valt nog zo veel aan te verbeteren, maar zal er vast niet komen.

[nextware]

Over scripts gesproken.. Vandaag ook met Azure Automation bezig geweest om wat Exchange Online zaken te automatiseren. Script gemaakt, module in Azure geüpload met PS 7.2 omgeving. Script laten testen, allerlei foutmeldingen. Gezocht op internet; werken bepaalde commando's niet in PS7.2 via Azure Automation en moet ik dus de 5.1 module van ExchangeOnlineManagement gaan gebruiken..

En daar breekt mijn klomp dus een beetje.. Waarom worden bepaalde commando's in PS7.2 niet overgenomen vanuit 5.1, terwijl er dus in diverse Microsoft artikelen staat "gebruikt commando X, Y en Z, upload module versie 7.2 in Azure Automation" maar op het moment dat je het dus daadwerkelijk gaat gebruiken je toch weer wordt gedwongen om PS 5.1 te gebruiken..

[Quad]

@nextware ter interesse, wat wil je automatiseren?

[HKLM_]

nextware schreef op vrijdag 30 januari 2026 @ 20:46:
Over scripts gesproken.. Vandaag ook met Azure Automation bezig geweest om wat Exchange Online zaken te automatiseren. Script gemaakt, module in Azure geüpload met PS 7.2 omgeving. Script laten testen, allerlei foutmeldingen. Gezocht op internet; werken bepaalde commando's niet in PS7.2 via Azure Automation en moet ik dus de 5.1 module van ExchangeOnlineManagement gaan gebruiken..

En daar breekt mijn klomp dus een beetje.. Waarom worden bepaalde commando's in PS7.2 niet overgenomen vanuit 5.1, terwijl er dus in diverse Microsoft artikelen staat "gebruikt commando X, Y en Z, upload module versie 7.2 in Azure Automation" maar op het moment dat je het dus daadwerkelijk gaat gebruiken je toch weer wordt gedwongen om PS 5.1 te gebruiken..

De Exchange online module voor powershell heeft helaas wel meer gekke zaken

[nextware]

Quad schreef op vrijdag 30 januari 2026 @ 20:52:
@nextware ter interesse, wat wil je automatiseren?

Onder andere:
- mailbox visibility (free / busy, etc)
- timezone settings

Vooral de laatste is veel gevraagd. Vaak worden er al afspraken in agenda's gezet voor de medewerkers starten. Als een mailbox wordt opgemaakt staat deze standaard in UTC-8. (https://learn.microsoft.c...issing-time-zone-settings) Dit levert vreemde zaken op bij het plannen van afspraken.
Pas wanneer een collega voor de eerste keer inlogt wordt de timezone goed gezet voor de mailbox( W. Europe Standard Time).
Dit script zet de timezone dus goed voor een gebruiker de eerste keer inlogt. En om dat nu iedere keer niet handmatig te hoeven doen heb ik een Powershell script gemaakt die de timezone van een mailbox bekijkt en deze, indien nodig, op de goede timezone zet. En dat laat ik nu automatisch doen via Azure Automation.

[Hero of Time]

Die tijdzone is een probleem dat MS gewoon keihard weigert te fixen, want ze zijn zo hypocriet,dat ze niet kunnen indenken dat er mensen elders dan Redmond kunnen leven. Online vind je duizenden berichten over deze ergernis. Het is echt een kleine moeite voor ze om dit op tenant niveau te kunnen regelen, maar nee, het maakt niet uit of je tenant nou in de westkust, Europa of in Australië bevind, je tijdzone zal hoe dan ook Redmond zijn en dat is UTC-8.

Ik had dit onlangs ook, met een vergaderruimte. Men kon het wel boeken, maar de planningsweergave gaf altijd aan dat het onbeschikbaar was. Want de office hours waren dan wel opgegeven, de tijdzone had dit fijn verkloot voor de weergave.

Maar is het niet makkelijker om gebruikers via scripts te maken en zo de tijdzone direct mee te zetten? Kan je eventueel ook gelijk eventuele shared mailboxen toewijzen e.d.

[HKLM_]

Hero of Time schreef op vrijdag 30 januari 2026 @ 21:48:
Die tijdzone is een probleem dat MS gewoon keihard weigert te fixen, want ze zijn zo hypocriet,dat ze niet kunnen indenken dat er mensen elders dan Redmond kunnen leven. Online vind je duizenden berichten over deze ergernis. Het is echt een kleine moeite voor ze om dit op tenant niveau te kunnen regelen, maar nee, het maakt niet uit of je tenant nou in de westkust, Europa of in Australië bevind, je tijdzone zal hoe dan ook Redmond zijn en dat is UTC-8.

Beetje kort door de bocht niet, ze hebben UTC-8 als default gekozen ooit. Op tenant niveau gaat helemaal niet werken. Moet iemand die bij een bedrijf werkt en een tenant in de EU heeft maar op een vestiging in Australië werkt dan ook maar een w.europe mailbox want tenant niveau?

Ze zouden beter de timezone op de mailbox kunnen aanpassen op basis van de user location welke je netjes in entra id meegeeft bij het aanmaken van een gebruiker.

[Hero of Time]

HKLM_ schreef op vrijdag 30 januari 2026 @ 22:11:
[...]

Beetje kort door de bocht niet, ze hebben UTC-8 als default gekozen ooit. Op tenant niveau gaat helemaal niet werken. Moet iemand die bij een bedrijf werkt en een tenant in de EU heeft maar op een vestiging in Australië werkt dan ook maar een w.europe mailbox want tenant niveau?

Nee, je geeft bij je tenant aan welke tijdzone je zit. Gebruikers krijgen dan die als default totdat ze het opgeven bij het inloggen (of je definieert dat per gebruiker waar nodig). Wat MS nu doet is juist kort door de bocht, want meer dan 90% van hun klanten zitten niet in UTC-8. Dus om nou praktisch de hele wereld op te zadelen met een kut standaard dat alleen maar gezeik levert, ipv de standaard tijdzone op tenant niveau te hebben is gewoon veel te kortzichtig.

Ze zouden beter de timezone op de mailbox kunnen aanpassen op basis van de user location welke je netjes in entra id meegeeft bij het aanmaken.

Ja, maar dat gaat MS dus ook niet doen, dat kan ik je nu al vertellen. Als ze het al verdommen om een globale standaard voor waar je organisatie bevind mogelijk te maken, gaat dit er al helemaal niet komen. Er zijn meer zaken die met een eenvoudige toggle in de verschillende admin portals te regelen zouden moeten zijn, maar MS wijst je ook gewoon door naar Powershell.

[TheVMaster]

Hero of Time schreef op vrijdag 30 januari 2026 @ 22:20:
[...]

Nee, je geeft bij je tenant aan welke tijdzone je zit. Gebruikers krijgen dan die als default totdat ze het opgeven bij het inloggen (of je definieert dat per gebruiker waar nodig). Wat MS nu doet is juist kort door de bocht, want meer dan 90% van hun klanten zitten niet in UTC-8. Dus om nou praktisch de hele wereld op te zadelen met een kut standaard dat alleen maar gezeik levert, ipv de standaard tijdzone op tenant niveau te hebben is gewoon veel te kortzichtig.


[...]

Ja, maar dat gaat MS dus ook niet doen, dat kan ik je nu al vertellen. Als ze het al verdommen om een globale standaard voor waar je organisatie bevind mogelijk te maken, gaat dit er al helemaal niet komen. Er zijn meer zaken die met een eenvoudige toggle in de verschillende admin portals te regelen zouden moeten zijn, maar MS wijst je ook gewoon door naar Powershell.

Eh, je weet dat je de tijdzone gewoon via een Intune policy kunt regelen hè. Tuurlijk is het irritant dat het niet default naar de regio die je hebt ingesteld, etc. Maar zo’n enorm issue is het nu ook weer niet. Gewoon een policy maken in Intune en klaar ben je.

[nextware]

Hero of Time schreef op vrijdag 30 januari 2026 @ 21:48:

Maar is het niet makkelijker om gebruikers via scripts te maken en zo de tijdzone direct mee te zetten? Kan je eventueel ook gelijk eventuele shared mailboxen toewijzen e.d.

Op dit moment worden nieuwe gebruikers nog bij ons aangemaakt in de on-prem AD (via ons HR pakket) en daarna via een sync naar Entra ID. De bedoeling is om dat in de (nabije) toekomst direct in Entra ID aan te maken als we overstappen naar een fatsoenlijk en modern HR pakket. Dan is de tijdzone geen probleem meer, want dat is eenvoudig mee te geven via een attribuut tijdens provisioning. Maar dan moeten we dus ook eerst nog heel veel on-prem spul uitfaseren of zorgen dat authenticatie mogelijk is via Entra ID (Kerberos).. Nog genoeg werk te doen de komende jaren

TheVMaster schreef op zaterdag 31 januari 2026 @ 02:19:
[...]

Eh, je weet dat je de tijdzone gewoon via een Intune policy kunt regelen hè. Tuurlijk is het irritant dat het niet default naar de regio die je hebt ingesteld, etc. Maar zo’n enorm issue is het nu ook weer niet. Gewoon een policy maken in Intune en klaar ben je.

Dit gebeurd bij het deployen van onze cloud-managed devices. We geven de timezone mee via een CP maar de mailbox wordt dan pas goedgezet op het moment dat de gebruiker dus inlogt in M365. En daar zit bij ons de uitdaging omdat er dus al vaak eerder afspraken in agenda's worden gemaakt

[ Voor 7% gewijzigd door nextware op 31-01-2026 07:02 ]

[ralpje]

Blokker_1999 schreef op donderdag 29 januari 2026 @ 07:27:
Maar dan stel ik mij de vraag: waarom test je je script niet voordat je het upload? En waarom maakt je script geen transcript dat je ergens wegschrijft zodat je weet wat de output van het script was?

Bonuspunten als je die transcript laat wegschrijven naar (bijvoorbeeld) %ProgramData%\Microsoft\IntuneManagementExtension\Logs\ zodat je hij ook gelijk meekomt als een diagnostics log vanuit Intune opvraagt

[Blokker_1999]

nextware schreef op vrijdag 30 januari 2026 @ 21:22:
[...]


Onder andere:
- mailbox visibility (free / busy, etc)
- timezone settings

Geen idee wat je met die free/busy doet, maar opletten dat je niet zomaar iedereen forceert om meer dan free/busy te tonen by default. Dat kan al snel een schending van de AVG opleveren. En als je een default setting wenst, zorg dan dat de default voor het bedrijf goed staat. Als je individuele groepen of gebruikers gaat toevoegen, dan gaan die telkens een mail krijgen wanneer je de instelling aanpast.

Bijkomend lijkt het mij dat als je automagisch afspraken in een kalender gaat inplannen dat je rekening kunt houden met de tijdzone maar ook wanneer iemand handmatig iets inschiet dat ook dan de tijdzone van de ontvanger niet zou mogen uitmaken. Een kalenderitem staat niet on lokale tijd, maar geeft altijd een waarde mee ten opzichte van UTC.

[Hero of Time]

TheVMaster schreef op zaterdag 31 januari 2026 @ 02:19:
[...]

Eh, je weet dat je de tijdzone gewoon via een Intune policy kunt regelen hè. Tuurlijk is het irritant dat het niet default naar de regio die je hebt ingesteld, etc. Maar zo’n enorm issue is het nu ook weer niet. Gewoon een policy maken in Intune en klaar ben je.

Eh, je weet dat de tijdzone van je systeem geen klap invloed heeft op die in Exchange/Outlook hè? Dus leuk dat je je systeem zelf in A'dam kan zetten voor de tijd, de agenda van de gebruiker staat nog steeds op Redmond. En juist dát is het probleem. En MS is nog koppiger dan een ezel om hier ook maar iets aan te doen.

[TheVMaster]

nextware schreef op zaterdag 31 januari 2026 @ 07:00:
[...]


Op dit moment worden nieuwe gebruikers nog bij ons aangemaakt in de on-prem AD (via ons HR pakket) en daarna via een sync naar Entra ID. De bedoeling is om dat in de (nabije) toekomst direct in Entra ID aan te maken als we overstappen naar een fatsoenlijk en modern HR pakket. Dan is de tijdzone geen probleem meer, want dat is eenvoudig mee te geven via een attribuut tijdens provisioning. Maar dan moeten we dus ook eerst nog heel veel on-prem spul uitfaseren of zorgen dat authenticatie mogelijk is via Entra ID (Kerberos).. Nog genoeg werk te doen de komende jaren


[...]


Dit gebeurd bij het deployen van onze cloud-managed devices. We geven de timezone mee via een CP maar de mailbox wordt dan pas goedgezet op het moment dat de gebruiker dus inlogt in M365. En daar zit bij ons de uitdaging omdat er dus al vaak eerder afspraken in agenda's worden gemaakt

…maar de Windows timezone staat ook niet juist? Of gaat het nu juist om de tijdzone van Microsoft 365 en dan de website of de apps?

[TheVMaster]

Hero of Time schreef op zaterdag 31 januari 2026 @ 12:25:
[...]

Eh, je weet dat de tijdzone van je systeem geen klap invloed heeft op die in Exchange/Outlook hè? Dus leuk dat je je systeem zelf in A'dam kan zetten voor de tijd, de agenda van de gebruiker staat nog steeds op Redmond. En juist dát is het probleem. En MS is nog koppiger dan een ezel om hier ook maar iets aan te doen.

Eh, je hebt het ze gevraagd en toen vertelden ze je dat ze hier geen boodschap aan hadden of wat?

Maar er zijn toch manieren om dit (centraal) of per mailbox in te stellen dmv PowerShell scripts of automations? Die werken niet ofzo? En ja, eens dat het irritant is dat je dat niet gewoon in kunt stellen. Misschien klagen er niet genoeg mensen over, zodat het geen hoge prio krijgt.

[ Voor 20% gewijzigd door TheVMaster op 31-01-2026 13:17 ]

[Hero of Time]

TheVMaster schreef op zaterdag 31 januari 2026 @ 13:13:
[...]

Eh, je hebt het ze gevraagd en toen vertelden ze je dat ze hier geen boodschap aan hadden of wat?

Maar er zijn toch manieren om dit (centraal) of per mailbox in te stellen dmv PowerShell scripts of automations? Die werken niet ofzo? En ja, eens dat het irritant is dat je dat niet gewoon in kunt stellen. Misschien klagen er niet genoeg mensen over, zodat het geen hoge prio krijgt.

Als je gaat zoeken, kom je berichten van >10 jaar oud tegen hierover, dus 'te weinig mensen klagen' is onzin. En nee, het is niet centraal te regelen, je moet het elke keer, apart per mailbox regelen. Dat is ook onderdeel van het hele probleem.

En wat automation betreft, dat is dus waar @nextware tegenaan loopt met nextware in "Microsoft Intune ervaringentopic" De Exchange-online modules zijn voor Powershell 7, maar de Azure Automation zelf draait nog op 5. Geweldig he? Heb je automation, kan je er alsnog geen fuck mee omdat de cmdlets die je kan en moet gebruiken niet beschikbaar zijn of werken.

[Quad]

Ik zal volgende week eens kijken of CIPP hier een standard voor heeft.

[nextware]

TheVMaster schreef op zaterdag 31 januari 2026 @ 13:13:
[...]


…maar de Windows timezone staat ook niet juist? Of gaat het nu juist om de tijdzone van Microsoft 365 en dan de website of de apps?

De Windows timezone staat wel goed, maar heeft hierin geen invloed. Het gaat dus om de uitdaging dat, wanneer er een mailbox in ExO wordt aangemaakt, deze automatisch in UTC -8 wordt aangemaakt (standaard instelling binnen ExO, niet aan te passen op tenant niveau). En op het moment dat een gebruiker deze mailbox voor de eerste keer aanroept (lees: login via OWA of via Outlook app) dan wordt de timezone van de mailbox goed gezet binnen ExO aan de hand van de localisation van de gebruiker.
Dus als een gebruiker de mailbox nog niet heeft aangeroepen wordt de mailbox bij het plannen van een afspraak (via de afzender van de afspraak) getoond in UTC -8 tijd. En dat heb ik nu dus opgelost via dat Powershell script in Azure Automation

Enne.. het was niet mijn bedoeling om met het issue van Azure Automation icm PS5.2 / 7.1 zo'n discussie op te roepen

[ Voor 6% gewijzigd door nextware op 31-01-2026 14:11 ]

[feelthepower]

In Azure Automation kun je sinds ergens vorig jaar ook powershell v7.4 gebruiken.

[HKLM_]

feelthepower schreef op zaterdag 31 januari 2026 @ 18:19:
In Azure Automation kun je sinds ergens vorig jaar ook powershell v7.4 gebruiken.

Dat was het hele punt niet

[feelthepower]

Je hebt gelijk, ik had ergens een comment maar half gelezen. Maar aangezien veel comments hier over 7.2 gaan misschien niet volledig relevant doch wel informatief ;-)

[pjlgt]

Davidas schreef op vrijdag 9 januari 2026 @ 10:39:
Heeft iemand hier App Control for Business al in bedrijf? Ik ben vooronderzoek aan het doen en heb het geconfigureerd in een acceptatie omgeving, de policies zeggen dat ze zijn doorgevoerd op mijn test systeem maar ik kan nog altijd alle applicaties runnen. Kan het liggen aan het feit dat ik test op een VM?

Hier ook wat mee aan het stoeien en wanneer ik een xml aanmaak met de WDAC Wizard incl. managed installer aangevinkt werkt het zoals jij beschrijft. Alles werkt en er word niets geblokkeerd. Wanneer ik echter via AppControl Manager een base xml maak, met managed installer aan, dan worden de apps wel geblokkeerd. Maar ook de apps die uitgerold zijn via de Managed Installer Intune. Nu las ik ergens dat dit klopt en dat enkel apps die zijn geïnstalleerd nadat de App Control policy is toegekend de juiste attributen mee krijgen en dus ge-whitelist worden.

Applicatie op allow zetten via een supplemental policy werkt trouwens wel, maar wat heeft dan die Managed installer optie voor nut op 'oude' installaties?

[grimson]

Ha, 'toevallig' ook bezig met ACfB om het maar zo af te korten.


Wat ik ook instel als Disabled of Enabled, de 'built-in controls' lijken niet echt te werken of iets te blokkeren.
Ik heb onlangs ook die AppControl manager ontdekt en op de client kan je eventueel de policy inzien maar blijkbaar zijn deze 'built-in controls' van een nieuwere versie en de ontwikkelaar vriendelijk verzocht of support hiervoor mogelijk is.
Maar ook al is dus op de client zichtbaar dat deze built-in controls worden toegepast, kan ik niet het nut inzien van deze standaard waardes.

Wel ben ik van mening dat ACfB eigenlijk een must have is met betrekking tot de moderne layered beveiliging. Veel werk om het in te richten maar ik denk onontkoombaar. Het is 'radicaal' anders .. de blokkade begint al vooraf in plaats van achteraf bij traditionele AV of EDR applicaties.

Ook lees ik dat je het beste dus dit meteen bij de uitrol van devices kan inzetten omdat als je dan alles via een trusted managed installer installaties uitvoert deze installaties ook 'automatisch' vertrouwd worden. Scheelt weer het altijd penibele achteraf dichtzetten.

[HKLM_]

@pjlgt Code sign jij je xml ook? (zo ja wat zijn je ervaringen daarmee?)

https://learn.microsoft.c...er-control-and-protection

[ Voor 8% gewijzigd door HKLM_ op 03-02-2026 13:54 ]

[pjlgt]

HKLM_ schreef op dinsdag 3 februari 2026 @ 13:54:
@pjlgt Code sign jij je xml ook? (zo ja wat zijn je ervaringen daarmee?)

https://learn.microsoft.c...er-control-and-protection

Nee, zover zijn we nog niet. Vond het al heel wat dat er eindelijk iets geblokkeerd werd.

[Nopheros]

Sinds +/- een week hebben we na 6 jaar opeens een probleem met het uitrollen van Android enterprise toestellen. De security groep van het android enrollment profile was spontaan verdwenen, heb geprobeerd deze terug te zetten echter kreeg ik foutmeldingen dat de groepen niet bestonden terwijl deze uiteraard wel bestaan

Blijkt te maken te hebben met 'time grouping'. Heb zo'n security group aangemaakt met de juiste owner maar krijg het niet werkend.

Zijn wij de enige die hier opeens spontaan tegen aan lopen? Kan er vrijwel niets over vinden dus blijkbaar wel...?

[YaYo86]

Nope nog niet. Wij konden gister geen Fully mamaged Androids meer registreren tijdens de uitrol.

[nextware]

Hoe gaan jullie om met het SecureBoot verhaal ?
Ik heb nu wat settings in Intune aangemaakt die het updaten van de SecureBoot certificaten mogelijk maakt, maar die geeft op alle devices een 65000 error (al is dat voor nu nog "normaal" wat ik heb gelezen). Maar die secureboot certificaten komen binnen via firmware updates van de fabrikanten, toch ?

[HKLM_]

nextware schreef op vrijdag 6 februari 2026 @ 07:53:
Hoe gaan jullie om met het SecureBoot verhaal ?
Ik heb nu wat settings in Intune aangemaakt die het updaten van de SecureBoot certificaten mogelijk maakt, maar die geeft op alle devices een 65000 error (al is dat voor nu nog "normaal" wat ik heb gelezen). Maar die secureboot certificaten komen binnen via firmware updates van de fabrikanten, toch ?

Ik ben daar ook mee bezig en ondankts de blogs van Microsoft blijft het ingewikkeld. Vooral wat valt er om als je een device hebt wat niet is geupdate??

Certificates zitten ook in de firmware van de OEM inderdaad maar naast DELL heb ik er nog geen 1 gezien die ze aanbied in een update. Ze komen ook met Windows Update waarbij je die setting kan toepassen maar zoals je zelf aangeeft levert dat een 65000 error op momenteel omdat het botst met de Windows activation check oid. (Dacht ik gelezen te hebben)

[ Voor 4% gewijzigd door HKLM_ op 06-02-2026 07:59 ]

[pjlgt]

Staat onder Autopatch nu wel een Secure Boot rapport wat laat zien welke devices er nog niet bijgewerkt zijn, dus ga met die lijst alles bijlangs. Maar stonden ook apparaten op die ik vorige week nog volledig ge-update heb, dus hoe accuraat het allemaal is?

[YaYo86]

pjlgt schreef op vrijdag 6 februari 2026 @ 08:11:
Staat onder Autopatch nu wel een Secure Boot rapport wat laat zien welke devices er nog niet bijgewerkt zijn, dus ga met die lijst alles bijlangs. Maar stonden ook apparaten op die ik vorige week nog volledig ge-update heb, dus hoe accuraat het allemaal is?

En wat als een klant geen Autopatch gebruikt?

[HKLM_]

pjlgt schreef op vrijdag 6 februari 2026 @ 08:11:
Staat onder Autopatch nu wel een Secure Boot rapport wat laat zien welke devices er nog niet bijgewerkt zijn, dus ga met die lijst alles bijlangs. Maar stonden ook apparaten op die ik vorige week nog volledig ge-update heb, dus hoe accuraat het allemaal is?

Die lijst is wel half broken... als je hem exporteerd krijg je alleen de devices uit de eerste view te zien en niet alles...

[HKLM_]

YaYo86 schreef op vrijdag 6 februari 2026 @ 08:26:
[...]

En wat als een klant geen Autopatch gebruikt?

Autopatch is de generieke naam waar de Updates voor Client policies of de AutoPatch Groups invallen. Als je 1 van deze twee gebruikt en de telemetry voor Windows Update niet hebt gekillt dan moet het rapport zich gewoon vullen.

[Blokker_1999]

HKLM_ schreef op vrijdag 6 februari 2026 @ 08:30:
[...]


Die lijst is wel half broken... als je hem exporteerd krijg je alleen de devices uit de eerste view te zien en niet alles...

Net even een export gemaakt, en ik lijk toch al mijn Windows devices te hebben. Alleen staan ze in de export allemaal met "Not applicable"

[ Voor 8% gewijzigd door Blokker_1999 op 06-02-2026 10:10 ]

[Blokker_1999]

nextware schreef op vrijdag 6 februari 2026 @ 07:53:
Hoe gaan jullie om met het SecureBoot verhaal ?
Ik heb nu wat settings in Intune aangemaakt die het updaten van de SecureBoot certificaten mogelijk maakt, maar die geeft op alle devices een 65000 error (al is dat voor nu nog "normaal" wat ik heb gelezen). Maar die secureboot certificaten komen binnen via firmware updates van de fabrikanten, toch ?

Grappig, net zelf even naar de policy gekeken, en 5% van mijn devices staat als succesvol. Maar er is letterlijk geen lijn in te trekken van waarom die devices wel en de rest niet.

[nextware]

Blokker_1999 schreef op vrijdag 6 februari 2026 @ 10:15:
[...]

Grappig, net zelf even naar de policy gekeken, en 5% van mijn devices staat als succesvol. Maar er is letterlijk geen lijn in te trekken van waarom die devices wel en de rest niet.

Dit heb ik dus precies ook zo.. Ongeveer 5% staat als succesvol. De rest blijft error 65000 aangeven. Ondertussen maar even de diverse blogs in de gaten blijven houden.

[Quad]

YaYo86 schreef op donderdag 5 februari 2026 @ 18:18:
Nope nog niet. Wij konden gister geen Fully mamaged Androids meer registreren tijdens de uitrol.

Ik vandaag 1x zonder issue, een 2e tablet ging met veel 'retry's'...

[YaYo86]

Quad schreef op vrijdag 6 februari 2026 @ 13:39:
[...]

Ik vandaag 1x zonder issue, een 2e tablet ging met veel 'retry's'...

Kansloos. Ik had een sev A aangemeld bij MS maar ze kwamen niet verder dan wat logs bekijken, het was volgens hun in ieder geval geen wijdverspreid probleem.

[HKLM_]

YaYo86 schreef op vrijdag 6 februari 2026 @ 17:32:
[...]

Kansloos. Ik had een sev A aangemeld bij MS maar ze kwamen niet verder dan wat logs bekijken, het was volgens hun in ieder geval geen wijdverspreid probleem.

En sev A hiervoor? Ligt je organisatie plat door dit issue?

[Nopheros]

HKLM_ schreef op vrijdag 6 februari 2026 @ 19:08:
[...]


En sev A hiervoor? Ligt je organisatie plat door dit issue?

Hier kunnen we inmiddels al een volle week geen android telefoons uitgeven, heb alles meerdere malen nagelopen. Begint nu wel problematisch te worden.

[HKLM_]

Nopheros schreef op vrijdag 6 februari 2026 @ 20:07:
[...]


Hier kunnen we inmiddels al een volle week geen android telefoons uitgeven, heb alles meerdere malen nagelopen. Begint nu wel problematisch te worden.

Wat je kan doen is Intunesupport op X een berichtje sturen DM en gewoon taggen. Die reageren daar echt super goed en proactief op om intune issues te verhelpen.

[grimson]

Alle unsupported drivers al vervangen 🤓?

Starting in January 2026, Windows will no longer support V3 and V4 printer drivers. These older driver models were announced as deprecated in September 2023. Most customers use newer printer drivers or modern printing solutions, which continue to work and are recommended. If your printer depends on a V3 or V4 driver it may stop installing or working after support ends. To avoid interruptions, contact your printer manufacturer and update to a supported printer driver or another current printing solution.

Maar dit artikel lijkt weer niets hierover te zeggen, een harde unsupported melding zoals bovenstaand. Ik lees wel op Reddit meldingen met betrekking tot legacy drivers na installatie jaja de januari cu update.

Conclusie: lijkt mij tijd om als de wiedeweerga legacy drivers te vervangen. Zoals technisch (spontaan stuk na maandelijkse cu) als compliance (out of support) een rede dus.

Tevens ‘most customers’ … al gekeken bij de meeste smb bedrijfjes zonder knap IT beheer? 😇

[ Voor 34% gewijzigd door grimson op 07-02-2026 08:28 ]

[YaYo86]

HKLM_ schreef op vrijdag 6 februari 2026 @ 19:08:
[...]


En sev A hiervoor? Ligt je organisatie plat door dit issue?

Zeker, wij serveren 50k collega's, je wil niet weten hoeveel telefoons er doorheen gaan per dag en hoe hoog het wordt gespeeld als een telefoon niet kan worden geínstalleerd. We zijn ook met Lifecycle bezig momenteel, dus er gaan er echt een stuk of 500 doorheen per dag

HKLM_ schreef op vrijdag 6 februari 2026 @ 20:26:
[...]


Wat je kan doen is Intunesupport op X een berichtje sturen DM en gewoon taggen. Die reageren daar echt super goed en proactief op om intune issues te verhelpen.

Mwa, niet erg professioneel. Je wil je case kunnen tracken, dat doe je niet via X.

Nopheros schreef op vrijdag 6 februari 2026 @ 20:07:
[...]


Hier kunnen we inmiddels al een volle week geen android telefoons uitgeven, heb alles meerdere malen nagelopen. Begint nu wel problematisch te worden.

Same, onze case loopt ook gewoon nog. Bizar dat een oplossing zo lang moet duren.

[ Voor 54% gewijzigd door YaYo86 op 07-02-2026 13:11 ]

[Nopheros]

YaYo86 schreef op zaterdag 7 februari 2026 @ 13:07:
[...]

Zeker, wij serveren 50k collega's, je wil niet weten hoeveel telefoons er doorheen gaan per dag en hoe hoog het wordt gespeeld als een telefoon niet kan worden geínstalleerd.


[...]

Mwa, niet erg professioneel. Je wil je case kunnen tracken, dat doe je niet via X.


[...]

Same, onze case loopt ook gewoon nog. Bizar dat een oplossing zo lang moet duren.

Laat graag even weten als je meer info hebt vanuit je support ticket

[HKLM_]

YaYo86 schreef op zaterdag 7 februari 2026 @ 13:07:
[...]

Zeker, wij serveren 50k collega's, je wil niet weten hoeveel telefoons er doorheen gaan per dag en hoe hoog het wordt gespeeld als een telefoon niet kan worden geínstalleerd. We zijn ook met Lifecycle bezig momenteel, dus er gaan er echt een stuk of 500 doorheen per dag


[...]

Mwa, niet erg professioneel. Je wil je case kunnen tracken, dat doe je niet via X.


[...]

Same, onze case loopt ook gewoon nog. Bizar dat een oplossing zo lang moet duren.

Ik snap dat intune support niet professioneel is inderdaad maar het werkt wel, het stikt op hun account van intune gerelateerde zaken die ze snel oppakken. Waarbij je met support weken bezig bent

[TheVMaster]

YaYo86 schreef op zaterdag 7 februari 2026 @ 13:07:
[...]

Zeker, wij serveren 50k collega's, je wil niet weten hoeveel telefoons er doorheen gaan per dag en hoe hoog het wordt gespeeld als een telefoon niet kan worden geínstalleerd. We zijn ook met Lifecycle bezig momenteel, dus er gaan er echt een stuk of 500 doorheen per dag


[...]

Mwa, niet erg professioneel. Je wil je case kunnen tracken, dat doe je niet via X.


[...]

Same, onze case loopt ook gewoon nog. Bizar dat een oplossing zo lang moet duren.

Maar hebben jullie geen partner of account manager bij MS dan die voor jullie kan uitvogelen hoe het staat met jullie ticket?

[YaYo86]

TheVMaster schreef op zaterdag 7 februari 2026 @ 20:27:
[...]

Maar hebben jullie geen partner of account manager bij MS dan die voor jullie kan uitvogelen hoe het staat met jullie ticket?

Jawel, meerdere, maar ook die kunnen niks, ze doen hetzelfde als wat ik zelf kan doen: mailen met de status of de druk proberen op te voeren.

[HKLM_]

Aaaaaannnndddd its gone!

[nextware]

HKLM_ schreef op maandag 9 februari 2026 @ 13:24:
Aaaaaannnndddd its gone!

[Afbeelding]

Denk dat Microsoft het gewoon zelf nog niet goed weet hoe ze dit op moeten lossen

[Blokker_1999]

Wel grappig, in het berichtencentrum staat er nu ook een bericht over, vermoedelijk ook datgene wat de redactie getipt heeft, en als je de links daarin volgt, dan kom je weer bij documentatie uit die onder andere verwijst naar het nu verdwenen Intune rapport.

Al vind ik deze ook wel interessant, want daarin wordt de 65000 fout besproken: Microsoft Intune method of Secure Boot for Windows devices with IT-managed up...
al lijkt dat niet van toepassing bij ons want onze E3/E5 geeft onze Windows een enterprise licentie.

[Csotranme]

Iemand die eens kan testen of hij wel een .msi package in Intune kan schieten om uit te rollen?

Ik blijf maar de volgende error krijgen. Maakt niet uit wat voor .msi ik ook pak.... :
The RPC call 'IntuneApp.getLobAppContentFile' returned an error. No error message could be found. Check whether the error was signaled with an Error object. Try adding this app again.

[nextware]

Csotranme schreef op donderdag 19 februari 2026 @ 10:03:
Iemand die eens kan testen of hij wel een .msi package in Intune kan schieten om uit te rollen?

Ik blijf maar de volgende error krijgen. Maakt niet uit wat voor .msi ik ook pak.... :
The RPC call 'IntuneApp.getLobAppContentFile' returned an error. No error message could be found. Check whether the error was signaled with an Error object. Try adding this app again.

Wij zijn toevallig deze ochtend bezig om het twee packages via MSI uit te rollen maar die worden zonder problemen uitgerold.

[Csotranme]

nextware schreef op donderdag 19 februari 2026 @ 11:19:
[...]


Wij zijn toevallig deze ochtend bezig om het twee packages via MSI uit te rollen maar die worden zonder problemen uitgerold.

Ook in West EU of andere region?

[Hero of Time]

Csotranme schreef op donderdag 19 februari 2026 @ 10:03:
Iemand die eens kan testen of hij wel een .msi package in Intune kan schieten om uit te rollen?

Ik blijf maar de volgende error krijgen. Maakt niet uit wat voor .msi ik ook pak.... :
The RPC call 'IntuneApp.getLobAppContentFile' returned an error. No error message could be found. Check whether the error was signaled with an Error object. Try adding this app again.

Waarom wil je 'm als LOB uitvoeren en niet simpelweg in een .intunewin gieten dat ook gewoon direct herkend wordt als .msi? Bij een LOB kan je geen detectie doen en ik weet ook niet of supersedence werkt.

Wij hadden 1 programma dat als LOB was toegevoegd, maar die heb ik ondertussen vervangen voor .intunewin omdat het niet altijd lekker werkte.

[nextware]

Csotranme schreef op donderdag 19 februari 2026 @ 15:26:
[...]


Ook in West EU of andere region?

Tenant draair inderdaad in W-EU.
En ik repackage bijna alle apps naar een intunewin file. Dat werkt vaak toch het beste.

Al gaan we binnenkort ook PDQ bekijken om apps te deployen na een Autopilot deployment. Iemand hier toevallig ervaring mee ?

[ Voor 35% gewijzigd door nextware op 19-02-2026 20:40 ]

[Drardollan]

Al een paar dagen bezig met AutoPatch. Een mooi systeem hoor, maar wel lastig om 1-2-3 te doorgronden dankzij de groepen en vertragingen bij uitrol.

Had ik gistermorgen alles, zo nu blijkt, goed geconfigureerd. Maar geen device registration niks. Had gelezen dat de discovery elk uur loopt en het soms tot 24 uur kan duren voor een device zichtbaar is. Laptop dus bewust aan laten staan voor 24 uur, maar vanmorgen nog niks te zien. Grrrrr.

Uiteindelijk bij Autopatch group membership maar eens op Discover Devices geramd een uurtje terug en tot mijn verbazing staan de devices er enkele minuten later al in en zitten ze ook ineens netjes in de Windows Autopatch - Devices All groep.

Ik snap er geen barst van en hoop dat nieuwe devices wel vanzelf gevonden worden, want als ik elke keer op de knop moet drukken wordt je daar ook een beetje beroerd van natuurlijk.

Nu sowieso wachten op de eerste updates om te zien wat er gebeurd

[Blokker_1999]

Nieuwe devices komen hier zonder problemen in 1 van de groepen terecht. Enkel de test en last groep zijn handmatige groepen. First, fast en broad vullen automagisch. Mocht je zekerheid wensen kan je natuurlijk ook altijd een eigen, dynamische device groep toevoegen aan heel de configuratie. Ga hiervoor naar Devices > Windows > Windows Updates > Update rings en klik op de enige entry die er zou moeten staan genaamd "Windows Autopatch". Daar heb je een sectie genaamd "Deployment rings and distribution" waarin je de groepen kunt opgeven. Ga ze niet zelf over de ringen verdelen, tenzij dat dat noodzakelijk is, maar voeg ze erboven toe.

[Drardollan]

Zo te zien kan het allemaal alweer over boord. Mijn test machine deed net zonder enige notificatie een reboot

Dat is natuurlijk niet werkbaar en ik kan zover ik het kan vinden ook niet uitzetten of beïnvloeden. Kan het niet hebben dat computers van gebruikers maar gewoon willekeurig herstarten zonder melding, zit je net uren te werken op iets en dan gaat ie even rebooten

[HKLM_]

Drardollan schreef op vrijdag 20 februari 2026 @ 14:10:
Zo te zien kan het allemaal alweer over boord. Mijn test machine deed net zonder enige notificatie een reboot

Dat is natuurlijk niet werkbaar en ik kan zover ik het kan vinden ook niet uitzetten of beïnvloeden. Kan het niet hebben dat computers van gebruikers maar gewoon willekeurig herstarten zonder melding, zit je net uren te werken op iets en dan gaat ie even rebooten

Deel je config anders eens wat je kan prima instellen binen Autopatch / Autopatch groeps dat devices notificaties moeten geven en niet zomaar mogen rebooten

Heb je onder de release settings het Install and restart wel geconfigureerd? Deze staat standaard op Automatically install en restart...(helaas)

[ Voor 20% gewijzigd door HKLM_ op 20-02-2026 14:33 ]

[Blokker_1999]

@HKLM_ , kan me niet herinneren van dat ooit gezien te hebben . Dit is de view die ik zie als ik ga naar Devices > Windows > Windows updates > Update rings > Windows Autopatch > Update Policy - Default - Ring 3



Laat het maar weer aan MS om eenzelfde setting op verschillende plaatsen te configureren op verschillende manieren. Want hier is het "Automatic update behavior" dat bepaald wat er gebeurt:



Ring 3 komt met onze instellingen ten vroegste 9 dagen na patch tuesday binnen bij de gebruikers. Ik voorkom dat gebruikers zelf updates kunnen pauseren, laat de notificaties op hun standaard staan. Gebruikers kunnen de update tot 5 dagen uitstellen en na die 5 dagen zal de installatie automatisch gebeuren en krijgen ze nog 2 dagen uitstel tot reboot. Daarna volgt ook een automatische reboot.

En om eerlijk te zijn, geen klachten van gebruikers met deze instellingen. Toch niet over de Windows updates. Drivers daarentegen, dat is een heel ander probleem.

[Davidas]

Blokker_1999 schreef op vrijdag 20 februari 2026 @ 14:53:
@HKLM_ , kan me niet herinneren van dat ooit gezien te hebben . Dit is de view die ik zie als ik ga naar Devices > Windows > Windows updates > Update rings > Windows Autopatch > Update Policy - Default - Ring 3

[Afbeelding]

Laat het maar weer aan MS om eenzelfde setting op verschillende plaatsen te configureren op verschillende manieren. Want hier is het "Automatic update behavior" dat bepaald wat er gebeurt:

[Afbeelding]

Ring 3 komt met onze instellingen ten vroegste 9 dagen na patch tuesday binnen bij de gebruikers. Ik voorkom dat gebruikers zelf updates kunnen pauseren, laat de notificaties op hun standaard staan. Gebruikers kunnen de update tot 5 dagen uitstellen en na die 5 dagen zal de installatie automatisch gebeuren en krijgen ze nog 2 dagen uitstel tot reboot. Daarna volgt ook een automatische reboot.

En om eerlijk te zijn, geen klachten van gebruikers met deze instellingen. Toch niet over de Windows updates. Drivers daarentegen, dat is een heel ander probleem.

Dit is de Windows update for business policy, geen Autopatch.

[HKLM_]

Blokker_1999 schreef op vrijdag 20 februari 2026 @ 14:53:
@HKLM_ , kan me niet herinneren van dat ooit gezien te hebben . Dit is de view die ik zie als ik ga naar Devices > Windows > Windows updates > Update rings > Windows Autopatch > Update Policy - Default - Ring 3

[Afbeelding]

Laat het maar weer aan MS om eenzelfde setting op verschillende plaatsen te configureren op verschillende manieren. Want hier is het "Automatic update behavior" dat bepaald wat er gebeurt:

[Afbeelding]

Ring 3 komt met onze instellingen ten vroegste 9 dagen na patch tuesday binnen bij de gebruikers. Ik voorkom dat gebruikers zelf updates kunnen pauseren, laat de notificaties op hun standaard staan. Gebruikers kunnen de update tot 5 dagen uitstellen en na die 5 dagen zal de installatie automatisch gebeuren en krijgen ze nog 2 dagen uitstel tot reboot. Daarna volgt ook een automatische reboot.

En om eerlijk te zijn, geen klachten van gebruikers met deze instellingen. Toch niet over de Windows updates. Drivers daarentegen, dat is een heel ander probleem.

Dit is Windows Client Update policies mijn PS komt uit de Autopatch Groups selectie: Tenant Administration -> Windows Autopatch -> Autopatch Groups -> (En dan je profielen en de ringen die je hebt aangemaakt)

[Blokker_1999]

Had ik niet ergens gelezen dat WufB opging in AutoPatch? Sowieso blijf ik bij mijn statement dat MS te veel overlap op te veel verschillende plaatsen heeft

[HKLM_]

Blokker_1999 schreef op vrijdag 20 februari 2026 @ 14:56:
Had ik niet ergens gelezen dat WufB opging in AutoPatch? Sowieso blijf ik bij mijn statement dat MS te veel overlap op te veel verschillende plaatsen heeft

Windows Update for Business heeft inderdaad nu Windows Update Client policies en is onderdeel van de Windows Autopatch met de policies welke je zelf kan aanmaken of de Autopatch groups als je een automatic ring based model wilt.

Ja het is verwarrend ben ik met je eens

[Blokker_1999]

Heb de instellingen die je toont voor mijn tenant gevonden. En bij mij staat die ook op "Automatically install and restart". Ik vermoed dat het gedrag van @Drardollan's update dan ook komt uit het ontbreken van een deadline en grace period.

En bij notifications is geen van de 3 bolletjes gekleurd bij mij, maar onze gebruikers krijgen gewoon de standaard notificaties van Windows.

[Drardollan]

HKLM_ schreef op vrijdag 20 februari 2026 @ 14:25:
[...]


Deel je config anders eens wat je kan prima instellen binen Autopatch / Autopatch groeps dat devices notificaties moeten geven en niet zomaar mogen rebooten

Heb je onder de release settings het Install and restart wel geconfigureerd? Deze staat standaard op Automatically install en restart...(helaas)

[Afbeelding]

Dat is inderdaad hoe het ingesteld staat. En daar kan je geen opties aanzetten die voorkomen dat hij direct gaat rebooten als hij het nodig vind. Hooguit kan je de werkuren bepalen bij Scheduled Install and Restart. Maar aangezien hier net als bijna overal 24/7 gewerkt kan worden is dat geen optie.

Dit zijn de enige instellingen daar:


In de Windows Update policies heb je die instellingen wel (grace period na deadline). Maar aangezien Autopatch die policies aanmaakt bij gebruik van Autopatch lijkt het mij beter om niet in de policies te gaan zitten aanpassen. Ik verwacht dat die klakkeloos overschreven worden door Microsoft als ze dat nodig achten of als je de Autopatch instellingen opslaat.

[ Voor 7% gewijzigd door Drardollan op 20-02-2026 15:09 ]

[Drardollan]

Blokker_1999 schreef op vrijdag 20 februari 2026 @ 14:53:
@HKLM_ , kan me niet herinneren van dat ooit gezien te hebben . Dit is de view die ik zie als ik ga naar Devices > Windows > Windows updates > Update rings > Windows Autopatch > Update Policy - Default - Ring 3

[Afbeelding]

Laat het maar weer aan MS om eenzelfde setting op verschillende plaatsen te configureren op verschillende manieren. Want hier is het "Automatic update behavior" dat bepaald wat er gebeurt:

[Afbeelding]

Ring 3 komt met onze instellingen ten vroegste 9 dagen na patch tuesday binnen bij de gebruikers. Ik voorkom dat gebruikers zelf updates kunnen pauseren, laat de notificaties op hun standaard staan. Gebruikers kunnen de update tot 5 dagen uitstellen en na die 5 dagen zal de installatie automatisch gebeuren en krijgen ze nog 2 dagen uitstel tot reboot. Daarna volgt ook een automatische reboot.

En om eerlijk te zijn, geen klachten van gebruikers met deze instellingen. Toch niet over de Windows updates. Drivers daarentegen, dat is een heel ander probleem.

Die policies worden, als je Autopatch gebruikt, aangemaakt en beheerd door Autopatch. Je kan daar wijzigingen aanbrengen, maar ik denk dat als je iets in je Autopatch veranderd deze gewoon overschreven worden.

Update: heel snel en kort getest, de setting lijkt bewaard te worden op dit moment.

[Drardollan]

Maar los daarvan, ik zie nog weinig voordelen aan Autopatch? Het is allemaal precies hetzelfde als de reguliere Windows Updates instellingen binnen Intune volgens mij. De enige verschillen die ik zie is dat je het via een wizard kan configureren en er een stuk dynamische verdeling bij zit die bij grotere bedrijven ongetwijfeld erg handig is. Maar als je het hebt over 50 devices is het in de juiste groep plaatsen van de devices natuurlijk een peulenschil.

Niettemin was het een interessante test en les, het is goed om er eens mee gestoeid te hebben. Wie weet wanneer je het nodig hebt tenslotte.

[HKLM_]

Drardollan schreef op vrijdag 20 februari 2026 @ 15:14:
Maar los daarvan, ik zie nog weinig voordelen aan Autopatch? Het is allemaal precies hetzelfde als de reguliere Windows Updates instellingen binnen Intune volgens mij. De enige verschillen die ik zie is dat je het via een wizard kan configureren en er een stuk dynamische verdeling bij zit die bij grotere bedrijven ongetwijfeld erg handig is. Maar als je het hebt over 50 devices is het in de juiste groep plaatsen van de devices natuurlijk een peulenschil.

Niettemin was het een interessante test en les, het is goed om er eens mee gestoeid te hebben. Wie weet wanneer je het nodig hebt tenslotte.

Voor 50 devices kan je inderdaad ook Windows Client policies handmatig configureren, Voor je 24/7 issue is WIndows Hotpatch mogelijk wel een mooie toevoeging dan hoef je niet te rebooten met updates (3x per jaar wel) maar dat kan je met een policy denk wel fixen of regkey o.i.d

Ik zet Windows Autopatch groups in binnen grotere oranisaties waar we soms profielen aanmaken voor afdelingen met hun eigen ringen enzo en dan is het wel echt heel ideaal en overzichtelijk hoor. Maar ik snap je punt en ervaring goed.

[Drardollan]

HKLM_ schreef op vrijdag 20 februari 2026 @ 15:17:
[...]


Voor 50 devices kan je inderdaad ook Windows Client policies handmatig configureren, Voor je 24/7 issue is WIndows Hotpatch mogelijk wel een mooie toevoeging dan hoef je niet te rebooten met updates (3x per jaar wel) maar dat kan je met een policy denk wel fixen of regkey o.i.d

Dat hoeft niet eens, dat zit standaard in de WU (Quality Updates) policies in Intune tegenwoordig:

Ik zet Windows Autopatch groups in binnen grotere oranisaties waar we soms profielen aanmaken voor afdelingen met hun eigen ringen enzo en dan is het wel echt heel ideaal en overzichtelijk hoor. Maar ik snap je punt en ervaring goed.

Klinkt heel logisch, dat is ook wat ik zou doen. Het is duidelijk een onderdeel wat beter past bij grotere bedrijven met andere eisen. Maar doe je dan ook nog los de policy aanpassen om die spontane reboot voor aflopen van de deadline te voorkomen?

[Csotranme]

nextware schreef op donderdag 19 februari 2026 @ 20:37:
[...]


Tenant draair inderdaad in W-EU.
En ik repackage bijna alle apps naar een intunewin file. Dat werkt vaak toch het beste.

Al gaan we binnenkort ook PDQ bekijken om apps te deployen na een Autopilot deployment. Iemand hier toevallig ervaring mee ?

Hier werkte het paar uur later weer
In dit geval was het een agent die zichzelf update dus vond het niet zo boeiend om hem te repackagen.

PDQ ken ik en jaren mee gewerkt.
Ik vond het echt een fantastische tool en al helemaal voor het geld destijds.
Ik gebruikte ook PDQ Inventory erbij voor rapportages op outdated software etc.

Is wel al paar jaar geleden. Probleem wat ze destijds hadden is dat de server on-prem moest draaien. PDQ zag je devices dus niet als ze niet op kantoor waren of niet met VPN verbonden.
Resultaat: altijd devices die outdated waren...
Toen waren ze wel met een agent aan het klooien voor de standaard packages die ze zelf aanboden maar dat project is toen gecanceld omdat het niet werkte.

Geen idee hoe dat nu werkt bij hun.
De controle, flexibiliteit, mogelijkheden en uitgebreide rapportages waren wat mij betreft de beste in de markt paar jaar geleden.

Gebruik nu hier voornamelijk scappman (PatchMyPC) via de MSP. Daar klik je de package gewoon aan en importeert hij hem in Intune.
Werkt prima voor de standaard meuk maar lang niet zo flexibel als PDQ.