Microsoft Intune ervaringentopic

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

[grimson]

Autopatch vs Cloud Update: Who Is Actually Driving the Microsoft 365 Apps Update Engine
Ik lees wisselende ervaringen over Windows Autopatch voor Microsoft 365 Apps updates. Klopt het dat Autopatch minder geschikt is voor Office‑updates? Ik hoor dat je weinig controle hebt over rings, uitrol en versie‑pinnen. Wat is in de praktijk de beste aanpak: Autopatch gebruiken of toch Intune‑updatebeleid voor M365 Apps?

[nextware]

grimson schreef op zondag 1 maart 2026 @ 10:32:
Autopatch vs Cloud Update: Who Is Actually Driving the Microsoft 365 Apps Update Engine
Ik lees wisselende ervaringen over Windows Autopatch voor Microsoft 365 Apps updates. Klopt het dat Autopatch minder geschikt is voor Office‑updates? Ik hoor dat je weinig controle hebt over rings, uitrol en versie‑pinnen. Wat is in de praktijk de beste aanpak: Autopatch gebruiken of toch Intune‑updatebeleid voor M365 Apps?

Autopatch gebruik ik voor de OS updates. De M365 apps doen wij via twee aparte groepen:
- voor ICT en key-users: zitten op Current Channel
- rest van de organisatie: zitten op Monthly Enterprise Channel

[Hero of Time]

Kwam vandaag achter een 'bug' met Intune/auto-pilot waar ik het eigenlijk van de pot gerukt vind hoe incompetent MS is. Vrijdag had ik m'n configuratie voor een kiosk zo dat het werkt zoals we zouden willen, browser in kiosk modus, cookies blijven bewaard voor een instelling op de site die nodig is zodat de locatie onthouden blijft en het on-screen toetsenbord heeft geen onnodige opties of geeft de mogelijkheid om uit de kiosk te raken.

Omdat er al wat test zaken waren uitgevoerd en extra applicaties die niet nodig zijn, gaf ik bij Intune de opdracht 'Fresh Start'. Doet blijkbaar hetzelfde als Wipe, dus wat het verschil dan precies is weet ik niet. Maar dat is het issue niet. Het probleem was dat het daarna netjes naar de OOBE ging en alleen de vraag voor de toetsenbordindeling beantwoord hoefde te worden, zoals ook ingesteld. Om vervolgens te falen bij het MDM registratie oid, foutcode 0x800180014. Genoeg te vinden hierover online en het enige dat dit oplost, is het apparaat uit auto-pilot te gooien en opnieuw te registreren. Het is minder een issue als je een Dell, HP, Lenovo of MS Surface hebt en deze via de OEM in je tenant wordt geregistreerd.

Mis ik nou echt iets, of is MS echt zo idioot dat je niet eens een systeem dat een self-deploying profiel heeft toegewezen kan resetten zonder het opnieuw in AP te moeten registreren? Het is al erg genoeg dat een wipe/fresh start meer dan een half uur tot zelfs een uur duurt, maar daar is verders geen handmatige acties voor nodig.

[FREAKJAM]

Mogelijke deze bug waar je tegenaan liep?

[akimosan]

@Hero of Time : dat had ik in het verleden ook eens bij de hand gehad.
Wellicht hoef je hem niet uit Autopilot te gooien maar enkel uit EntraID.
Nadeel is dat je (tenminste via de portal) een device niet uit EntraID kunt verwijderen zonder hem ook (eerst) uit Autopilot te verwijderen

Maar via Graph kan dat wel!
Ik gebruik daarvoor DeviceOffboardingManager sowieso een handige tool om in bulk devices uit Intune/EntraID/Autopilot te verwijderen

[ Voor 8% gewijzigd door akimosan op 02-03-2026 20:55 ]

[Hero of Time]

FREAKJAM schreef op maandag 2 maart 2026 @ 20:50:
Mogelijke deze bug waar je tegenaan liep?

Niet echt. Bovendien:

This update only works for certain OEMs

Dat zijn de OEMs die ik noemde. Denk ik, want MS is weer kraakhelder hiermee natuurlijk.

Je moet bij de 'Known Issues' sectie kijken, daar staat het namelijk beschreven:

quote: https://learn.microsoft.c...-or-pre-provisioning-mode

Devices are enrolled using Windows Autopilot self-deployment mode or pre-provisioning mode. If a device is redeployed so that it reruns the Windows Autopilot deployment again, it fails with a 0x80180014 error code.

En dan staat er dat je het apparaat moet 'deregistreren'. Oftewel, uit je AP flikkeren en opnieuw toevoegen door op het apparaat weer 'get-autopilotinfo -online' uit te voeren. Of je moet toevallig de hash eerder naar CSV hebben opgeslagen, dan kan je die importeren (dat heb ik uiteindelijk maar gedaan).

akimosan schreef op maandag 2 maart 2026 @ 20:54:
@Hero of Time : dat had ik in het verleden ook eens bij de hand gehad.
Wellicht hoef je hem niet uit Autopilot te gooien maar enkel uit EntraID.
Nadeel is dat je (tenminste via de portal) een device niet uit EntraID kunt verwijderen zonder hem ook (eerst) uit Autopilot te verwijderen

Maar via Graph kan dat wel!
Ik gebruik daarvoor DeviceOffboardingManager sowieso een handige tool om in bulk devices uit Intune/EntraID/Autopilot te verwijderen

Ook dus weer zo'n houtje-touwtje oplossing dat nodig is om het falen van MS op te lossen. Zag eerder ook al dat apparaten die in AP geregistreerd waren en daarna in Intune aangemeld waren, dubbel in Entra staan. Voor AP met het serienummer en dan een tweede keer met de hostnaam van Intune. Je kan er verders praktisch niks mee, hooguit 'disablen'.

Ik zal eens naar die tool kijken morgen.

[Gr4mpyC3t]

Hero of Time schreef op maandag 2 maart 2026 @ 20:45:


Omdat er al wat test zaken waren uitgevoerd en extra applicaties die niet nodig zijn, gaf ik bij Intune de opdracht 'Fresh Start'. Doet blijkbaar hetzelfde als Wipe, dus wat het verschil dan precies is weet ik niet. Maar dat is het issue niet. Het probleem was dat het daarna netjes naar de OOBE ging en alleen de vraag voor de toetsenbordindeling beantwoord hoefde te worden, zoals ook ingesteld. Om vervolgens te falen bij het MDM registratie oid, foutcode 0x800180014. Genoeg te vinden hierover online en het enige dat dit oplost, is het apparaat uit auto-pilot te gooien en opnieuw te registreren. Het is minder een issue als je een Dell, HP, Lenovo of MS Surface hebt en deze via de OEM in je tenant wordt geregistreerd.

• Wipe: Terug naar fabrieksinstellingen (image van de OEM).
• Fresh Start: Alle bloat en apps eraf (weg met die troep van de OEM).
• Autopilot Reset: Gebruikersdata foetsie, maar wel behoud van taal, toetsenbord en eventuele packages.

En dan voor de eerste twee nog afhankelijk van het vinkje om gebruikersprofielen te behouden zodat het apparaat ook in Intune blijft staan.

[akimosan]

To resolve this error, use one of the following work around methods:

.....Remove the device enrollment restriction for Windows (MDM) personally owned devices. For more information, see Set enrollment restrictions in Microsoft Intune ......

Yeah, I don't think so, Bob!
Een beetje toestaan dat gebruikers hun personal device in Windows kunnen enrollen. Dat is het eerste wat ik uitschakel..

[Hero of Time]

Gr4mpyC3t schreef op maandag 2 maart 2026 @ 21:34:
[...]

• Wipe: Terug naar fabrieksinstellingen (image van de OEM).
• Fresh Start: Alle bloat en apps eraf (weg met die troep van de OEM).
• Autopilot Reset: Gebruikersdata foetsie, maar wel behoud van taal, toetsenbord en eventuele packages.

En dan voor de eerste twee nog afhankelijk van het vinkje om gebruikersprofielen te behouden zodat het apparaat ook in Intune blijft staan.

Ik zag met de 'fresh start' zonder behoud van gebruiker e.d. eigenlijk hetzelfde riedeltje als met 'wipe', praktisch herinstallatie van het OS. Vanuit het OS zelf kan je ook een reset uitvoeren, waardoor het effectief ook in Intune als apparaat wordt verwijdert. Maar voorkomt het eerder genoemde euvel met self-deploy niet.

akimosan schreef op maandag 2 maart 2026 @ 21:46:
[...]

Yeah, I don't think so, Bob!
Een beetje toestaan dat gebruikers hun personal device in Windows kunnen enrollen. Dat is het eerste wat ik uitschakel..

Dat is een beetje de grap bij ons. Ik zie die configuratie wel staan bij ons, die was aangemaakt door de MSP die we hadden ingeschakeld om te helpen met de inrichting, maar is niet actief. Er is in onze omgeving dus geen beperking. Het is dus geen oplossing.

[pjlgt]

Hero of Time schreef op maandag 2 maart 2026 @ 21:55:
[...]

Dat is een beetje de grap bij ons. Ik zie die configuratie wel staan bij ons, die was aangemaakt door de MSP die we hadden ingeschakeld om te helpen met de inrichting, maar is niet actief. Er is in onze omgeving dus geen beperking. Het is dus geen oplossing.

Je moet hem toch juist actief maken? En daardoor de beperking instellen?

[ Voor 4% gewijzigd door pjlgt op 03-03-2026 07:51 ]

[grimson]

Hero of Time schreef op maandag 2 maart 2026 @ 20:45:
Kwam vandaag achter een 'bug' met Intune/auto-pilot waar ik het eigenlijk van de pot gerukt vind hoe incompetent MS is. Vrijdag had ik m'n configuratie voor een kiosk zo dat het werkt zoals we zouden willen, browser in kiosk modus, cookies blijven bewaard voor een instelling op de site die nodig is zodat de locatie onthouden blijft en het on-screen toetsenbord heeft geen onnodige opties of geeft de mogelijkheid om uit de kiosk te raken.

Omdat er al wat test zaken waren uitgevoerd en extra applicaties die niet nodig zijn, gaf ik bij Intune de opdracht 'Fresh Start'. Doet blijkbaar hetzelfde als Wipe, dus wat het verschil dan precies is weet ik niet. Maar dat is het issue niet. Het probleem was dat het daarna netjes naar de OOBE ging en alleen de vraag voor de toetsenbordindeling beantwoord hoefde te worden, zoals ook ingesteld. Om vervolgens te falen bij het MDM registratie oid, foutcode 0x800180014.

Mis ik nou echt iets, of is MS echt zo idioot dat je niet eens een systeem dat een self-deploying profiel heeft toegewezen kan resetten zonder het opnieuw in AP te moeten registreren? Het is al erg genoeg dat een wipe/fresh start meer dan een half uur tot zelfs een uur duurt, maar daar is verders geen handmatige acties voor nodig.

Self deploying - Requirements

A device can't automatically re-enroll through Windows Autopilot after an initial deployment with self-deploying mode. Instead, delete the device record in the Microsoft Intune admin center. From the Microsoft Intune admin center, select Devices > All devices > select the devices to delete > Delete.

Updates to the Windows Autopilot sign-in and deployment experience

Why did the Windows Autopilot team make these changes?

This was the biggest question we’ve received so far from customers. You liked, for example, giving a teacher a set of computers and using the welcome screen so the teacher could know which student to assign each device to. It’s a cool user experience when you assign a device, ship the device, and then the user opens that PC, and it welcomes them.

We loved the experience too! However, we made the changes because the reuse of hardware components, such as motherboards, or the refurbishment of devices without deregistration could potentially cause an issue if the device identifier can still be linked to a previous company. Hardware is being reused at record levels, partly due to the pandemic’s effect on global supply chains. While this reuse helps meet corporate sustainability goals, we had to remove the could and ensure no issues were caused. To date, we have found no evidence that anyone has used this to their advantage.

Alhoewel helaas MS inderdaad met foutcodes komt waar je soms jeuk aan je r##t krijgt is het toch misschien te verklaren waarom. (Ja het kan zeker mooier zo'n 'foutmelding').

Zover ik begrijp is het met auto provisioning en kiosk devices dat de potentie is dat het apparaat onbewust hergebruikt wordt na verkoop. Als je dan een apparaat hebt wat nog steeds automatisch in je tenant aanmeldt dan is het opeens een minder leuke eigenschap. User driven registratie is altijd dat een user dus na een reset moet aanmelden maar een autoprovisioning doet dat al zelf en is dus onbewust meteen een onderdeel van je tenant, ook als je dus deze computer weggeeft.
Dat is denk ik de verklaring waarom dit zo 'werkt'.

[Blokker_1999]

Hero of Time schreef op maandag 2 maart 2026 @ 21:06:
[...]

Zag eerder ook al dat apparaten die in AP geregistreerd waren en daarna in Intune aangemeld waren, dubbel in Entra staan. Voor AP met het serienummer en dan een tweede keer met de hostnaam van Intune. Je kan er verders praktisch niks mee, hooguit 'disablen'.

Ik erger mij hier enorm aan. Krijg je de melding dat er duizenden apparaten extra in je omgeving zouden zitten die niet eens bestaan. Je kan ze ook niet weggooien, en als je dan een specifiek apparaat moet opzoeken, bijvoorbeeld om dit handmatig in een groep te gooien, krijg je altijd 2 apparaten met dezelfde naam terug en gooi je ze er maar alle twee in want nakijken welke van de twee je nodig hebt kost je nog meer tijd.

[Blokker_1999]

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

[Afbeelding]

Guess who's back ...

Cijfers zien er ineens een heel stuk realistischer uit. Ga wel eens moeten uitzoeken wat ze met de status "Not applicable" bedoelen. Want daar staan veel meer machines in dan ik gehoopt had. Ik hoop echt dat we niet zoveel apparaten hebben met Secure Boot uitgeschakeld.

[ralpje]

Voor wat betreft die dubbele apparaten: mijn ervaring is anders.
Op het moment dat je een device in AP importeert (op basis van de hash) komt hij in Entra terecht (dus nog voor je hem daadwerkelijk enrolled). Dat is dan een device met als naam het serienummer, en als disabled object.

Bij de daadwerkelijke autopilot enrollment wordt het disabled object enabled, wordt de naam aangepast op basis van wat je in je enrollment profile hebt gespecificeerd en wordt het device daadwerkelijk enrolled in Intune.

Je hebt dan dus één object in Entra (met een GUID, laten we voor het gemak zeggen dat dat EN01 is) en één object in Intune (met een device management GUID, IN01).
Stel dat we nu dat object in Intune gaan wipen. Het object EN01 blijft gewoon bestaan, maar wordt opnieuw enrolled als IN02. IN01 bestaat nog, maar wordt uiteindelijk verwijderd op basis van de clean up policy in Intune (of als je hem handmatig verwijderd).

Hoewel een device dus meerdere keren in Intune kan voorkomen (met elk z'n eigen unieke device management object ID), is dat in Entra steeds hetzelfde device - met maar 1 object ID.

[Blokker_1999]

Laat me raden, non-hybrid joins . Bij mijn non-hybrid test apparaten zie ik inderdaad ook slechts 1 enkel device in Intune en Entra. Maar van zodra ik zoek achter een apparaat dat hybrid joined is heb ik er 2. En 1 van de twee update nooit, maar ze zijn wel alle twee gemarkeerd als autopilot device.

[ralpje]

Oh ja, ik vergeet steeds dat er ook nog mensen zijn die hybrid doen. Mijn advies is altijd om er alles aan doen om dat te voorkomen, maar ik snap dat er situaties zijn waarin je daar niet aan ontkomt.
Anyway, bij een hybrid join is dat by design.

A device object is pre-created in Microsoft Entra ID once a device is registered in Windows Autopilot. If a device goes through a hybrid Microsoft Entra deployment, by design, another device object is created resulting in duplicate entries.

https://learn.microsoft.c...-entra-hybrid-deployments

[grimson]

ralpje schreef op dinsdag 3 maart 2026 @ 10:06:
Voor wat betreft die dubbele apparaten: mijn ervaring is anders.
Op het moment dat je een device in AP importeert (op basis van de hash) komt hij in Entra terecht (dus nog voor je hem daadwerkelijk enrolled). Dat is dan een device met als naam het serienummer, en als disabled object.

Bij de daadwerkelijke autopilot enrollment wordt het disabled object enabled, wordt de naam aangepast op basis van wat je in je enrollment profile hebt gespecificeerd en wordt het device daadwerkelijk enrolled in Intune.

Je hebt dan dus één object in Entra (met een GUID, laten we voor het gemak zeggen dat dat EN01 is) en één object in Intune (met een device management GUID, IN01).
Stel dat we nu dat object in Intune gaan wipen. Het object EN01 blijft gewoon bestaan, maar wordt opnieuw enrolled als IN02. IN01 bestaat nog, maar wordt uiteindelijk verwijderd op basis van de clean up policy in Intune (of als je hem handmatig verwijderd).

Hoewel een device dus meerdere keren in Intune kan voorkomen (met elk z'n eigen unieke device management object ID), is dat in Entra steeds hetzelfde device - met maar 1 object ID.

Interessant . dus als ik het uitschrijf is dit wat je bedoelt?

0. Voor enrollment (AP hash imported)

• AP → nieuw
• Entra → nieuw (disabled)
• Intune → geen

1. Eerste enrollment

• AP → hetzelfde
• Entra → enabled
• Intune → IN01

2. Wipe

• AP → hetzelfde
• Entra → hetzelfde
• Intune → IN02

3. Wipe

• AP → hetzelfde
• Entra → hetzelfde
• Intune → IN03

ralpje schreef op dinsdag 3 maart 2026 @ 12:00:
Oh ja, ik vergeet steeds dat er ook nog mensen zijn die hybrid doen. Mijn advies is altijd om er alles aan doen om dat te voorkomen, maar ik snap dat er situaties zijn waarin je daar niet aan ontkomt.
Anyway, bij een hybrid join is dat by design.

[...]

https://learn.microsoft.c...-entra-hybrid-deployments

Ik zat al te vergelijken bij 'mijn' eigen omgeving (full cloud). Ik zie alleen maar dat het Intune device steeds wordt hergebruikt (dus gelijk blijft). Dank voor de verduidelijking. (Ik lees en leer graag mee).

[ralpje]

Dat is correct Of het Intune device ID gelijk blijft hangt af van welke 'manier' van wipe je doet. Een autopilot reset, wipe of simpelweg herinstallatie hebben verschillende resultaten

[Hero of Time]

pjlgt schreef op dinsdag 3 maart 2026 @ 07:50:
[...]

Je moet hem toch juist actief maken? En daardoor de beperking instellen?

Zoals ik het MS artikel lees als 'oplossing' om de fout niet te krijgen, is juist de optie toestaan.

To resolve this error, use one of the following work around methods:
- Remove the device enrollment restriction for Windows (MDM) personally owned devices.

We hebben nu dus geen beperking. Toch die foutmelding bij self-deployment na wipe. Maar ja, eigenlijk moet ik 'm inschakelen zodat men niet per ongeluk hun thuiscomputer in onze tenant hangt. En ondertussen zijn alle systemen die nog niet in Intune stonden ook via de GPO en scheduled task daarvan aangemeld. Moet ze alleen nog wel in AP registreren.

grimson schreef op dinsdag 3 maart 2026 @ 09:00:
[...]

Self deploying - Requirements

[...]

Updates to the Windows Autopilot sign-in and deployment experience

[...]

Alhoewel helaas MS inderdaad met foutcodes komt waar je soms jeuk aan je r##t krijgt is het toch misschien te verklaren waarom. (Ja het kan zeker mooier zo'n 'foutmelding').

Zover ik begrijp is het met auto provisioning en kiosk devices dat de potentie is dat het apparaat onbewust hergebruikt wordt na verkoop. Als je dan een apparaat hebt wat nog steeds automatisch in je tenant aanmeldt dan is het opeens een minder leuke eigenschap. User driven registratie is altijd dat een user dus na een reset moet aanmelden maar een autoprovisioning doet dat al zelf en is dus onbewust meteen een onderdeel van je tenant, ook als je dus deze computer weggeeft.
Dat is denk ik de verklaring waarom dit zo 'werkt'.

Ja, aardig. Maar in dit geval zou je met een bricked apparaat zitten. Want het systeem staat nog in je tenant, wil weer de deployment gaan uitvoeren, krijgt deze foutmelding en dat is 't. Je kan hierna geen zak meer. Herstart? Komt 'ie gewoon weer terug op dit punt. Reset? Zodra het internet ruikt gaat 'ie weer de self-deployment uitvoeren en hoppa, staat weer op deze foutmelding. Zolang je Windows gebruikt, is het apparaat niks meer dan een boekensteun. Totdat je 'm idd uit AP verwijdert. Maar dat zou je sowieso moeten doen met apparaten die je weggeeft/verkoopt.


Heb wel een klein dingetje die ik nog niet heb kunnen oplossen. Deze self-deploy betreft een kiosk. Ik kan veel instellen, maar bij de MS Edge configuratie staat er alleen onder 'Kiosk Mode' de optie om navigatiebewegingen uit te schakelen. Dat zou de navigatie van terug/vooruit met een veeg beweging moeten uitzetten. Maar ondanks dat ik de Kiosk configuratie gebruik om Edge te starten, is dit geen werkelijke kiosk modus, want de bewegingen werken nog gewoon (en ik kan ctrl+w en ctrl+n doen). Nu is dit niet echt een groot probleem. Wat wel een issue is, is het kunnen inzoomen met touch gebaren pinch to zoom. Want wanneer er een foto groter wordt getoond via de image viewer van de site, is het niet meer mogelijk om uit te zoomen en het sluit knopje aan te tikken.

Hoe kan ik pinch to zoom uitschakelen? Het is niet direct een Edge instelling, maar iets wat met het touch screen gaat. Ik kan echter geen configuratie vinden hiervoor in Intune, iig niet in de Settings Catalog.

[Davidas]

Kennelijk wordt er nog gebruik gemaakt van RDP via VPN naar sommige PC's in het netwerk, maar zodra deze Intune managed (cloud only) zijn werkt dit niet meer omdat de computernaam dan niet meer via DNS resolved kan worden. Iemand hier een oplossing of alternatieve tool voor?

[grimson]

Hero of Time schreef op dinsdag 3 maart 2026 @ 19:26:
Ja, aardig. Maar in dit geval zou je met een bricked apparaat zitten. Want het systeem staat nog in je tenant, wil weer de deployment gaan uitvoeren, krijgt deze foutmelding en dat is 't. Je kan hierna geen zak meer. Herstart? Komt 'ie gewoon weer terug op dit punt. Reset? Zodra het internet ruikt gaat 'ie weer de self-deployment uitvoeren en hoppa, staat weer op deze foutmelding. Zolang je Windows gebruikt, is het apparaat niks meer dan een boekensteun. Totdat je 'm idd uit AP verwijdert. Maar dat zou je sowieso moeten doen met apparaten die je weggeeft/verkoopt.

Hmm .. nouja meteen bricked toch niet? De OOBE fase is de enige fase die tracht AP aan te roepen, daar kan je eenvoudig aan voorbijkomen dus bricked valt wel mee als ik eerlijk mag zijn. Verder met deze kennis weet je dan dat je een self-deploying device op een speciale manier moet herinrichten en inderdaad bij uitfasering netjes uit het systeem halen. Ik zie er niet zoveel problemen mee toch? geen kritiek hoor, maar ik zie het niet zo desastreus. Het is wel op zijn 'Microsoft's'

[Hero of Time]

@grimson, voor de wat meer bekwame gebruiker is het niet een heel grote horde om de OOBE offline door te komen, maar MS zit meer en meer te pushen op het gebruik van een online account. Dit is nog altijd tijdens de OOBE en zodra die ook maar iets van internet ruikt, gaat AP al af. Voor de random gebruiker is het dus wel degelijk een bricked apparaat, want die heeft geen flauw benul hoe de OOBE te omzeilen is.

Het is zoals je al zegt, op z'n 'Microsoft's' en die tonen gewoon weer aan dat ze aan dit soort situaties, die verre van zeldzaam zijn, niet eens denken.

Net zoals ik de hele dag bezig ben geweest om uit te zoeken hoe ik de pinch to zoom uit kan schakelen. Kan gewoon niet. Het touchscreen bied geen enkele optie voor multi-touch. Op laptops zie ik bij 'touchpad' de mogelijkheid om 3- en 4-vingergebaren uit te schakelen. Ook zoomen met twee vingers kan je bij touchpads uitschakelen. Maar dit touchscreen? Nope, geen optie voor. En in de instellingen van Edge is er wel edge-swipe uit te zetten voor terug/vooruit, maar is niet via een beleidsoptie uit te schakelen. Alleen in kiosk modus, maar dat is het niet 100% en wordt daarom niet toegepast (terwijl het opstartargument wel degelijk '--kiosk' bevat!).

Een post op het MS forum van 4 jaar geleden heeft het er al over dat dit te configureren moet zijn. Men wil het om geldige redenen uit kunnen zetten, maar dat is niet mogelijk.

[bramassendorp]

Davidas schreef op donderdag 5 maart 2026 @ 10:18:
Kennelijk wordt er nog gebruik gemaakt van RDP via VPN naar sommige PC's in het netwerk, maar zodra deze Intune managed (cloud only) zijn werkt dit niet meer omdat de computernaam dan niet meer via DNS resolved kan worden. Iemand hier een oplossing of alternatieve tool voor?

Ook niet op fqdn?

[Blokker_1999]

Davidas schreef op donderdag 5 maart 2026 @ 10:18:
Kennelijk wordt er nog gebruik gemaakt van RDP via VPN naar sommige PC's in het netwerk, maar zodra deze Intune managed (cloud only) zijn werkt dit niet meer omdat de computernaam dan niet meer via DNS resolved kan worden. Iemand hier een oplossing of alternatieve tool voor?

Ik neem aan dat deze via DHCP een adres krijgen? Zorgen dat je DHCP server de DNS entry kan aanmaken en dan ook dat je scavenging in orde is.

[Drardollan]

Leuk zo'n Secure Boot Report. Je hebt er alleen niks aan als het niet gevuld wordt....

Voor de tenant van mijn werkgever weet ik van een aantal machines dat ze 100% zeker de nieuwe certificaten hebben én de (een beetje verborgen) scheduled task meermaals uitgevoerd hebben. 0 informatie in het report. In mijn eigen tenant is de informatie om een of andere reden wél gevuld, ondanks dat die tenant qua configuratie / inrichting vrijwel gelijk is.

Gistermorgen een ticket geopend bij Microsoft met de vraag hoe ik de info erin zou moeten kunnen krijgen, verwachte oplostijd 8 uur. Maar nu meer dan 24 uur verder nog steeds niks gehoord. Nu weet ik dat het Secure Boot report sowieso een zorgenkindje was (en mogelijk dus: is), maar ik had toch op zijn minst wel een reactie verwacht eigenlijk.

Weet iemand hier hoe de info er zou moeten komen?

[HKLM_]

Drardollan schreef op vrijdag 6 maart 2026 @ 11:08:
Leuk zo'n Secure Boot Report. Je hebt er alleen niks aan als het niet gevuld wordt....

Voor de tenant van mijn werkgever weet ik van een aantal machines dat ze 100% zeker de nieuwe certificaten hebben én de (een beetje verborgen) scheduled task meermaals uitgevoerd hebben. 0 informatie in het report. In mijn eigen tenant is de informatie om een of andere reden wél gevuld, ondanks dat die tenant qua configuratie / inrichting vrijwel gelijk is.

Gistermorgen een ticket geopend bij Microsoft met de vraag hoe ik de info erin zou moeten kunnen krijgen, verwachte oplostijd 8 uur. Maar nu meer dan 24 uur verder nog steeds niks gehoord. Nu weet ik dat het Secure Boot report sowieso een zorgenkindje was (en mogelijk dus: is), maar ik had toch op zijn minst wel een reactie verwacht eigenlijk.

Weet iemand hier hoe de info er zou moeten komen?

De info komt er in via de telemetry data vanuit Windows Client Update policies. (WUFB)

[Drardollan]

HKLM_ schreef op vrijdag 6 maart 2026 @ 11:25:
[...]


De info komt er in via de telemetry data vanuit Windows Client Update policies. (WUFB)

De info lijkt mij dan aanwezig, anders weet WUFB ook niet welke updates er wel en niet geïnstalleerd zijn lijkt mij. En die informatie is behoorlijk goed up-to-date, vanmorgen de laatste machines van 24H2 naar 25H2 gezet en die info is gewoon netjes aangekomen en al verwerkt in de portal en reports.

Zal wel wachten op MS Support worden, het zou mij niets verbazen als er onder water ergens aan een boom geschud moet worden in de tenant.

[HKLM_]

Iemand hier die volgende maand naar de MEM Summit gaat? (https://www.endpointsummit.com/ModernEndpointManagement2026)

[ Voor 36% gewijzigd door HKLM_ op 06-03-2026 14:59 ]

[Blokker_1999]

Vakantie zit in de weg.

[ralpje]

Nee, ze wilden m'n sessie niet hebben

[pstalman]

Ik heb nu al een paar keer een Win32 app actief gemaakt en ipv de Command Line optie een Script geselecteerd om de installatie te starten. Nu is bij elke van deze apps al minimaal 1x de optie in het dropdown menu zo maar gewijzigd (van script terug naar commandline), hier mensen die hetzelfde mee maken?

[TheVMaster]

ralpje schreef op vrijdag 6 maart 2026 @ 15:26:
Nee, ze wilden m'n sessie niet hebben

Wauw, gemiste kans voor ze!

[TheVMaster]

HKLM_ schreef op vrijdag 6 maart 2026 @ 14:58:
Iemand hier die volgende maand naar de MEM Summit gaat? (https://www.endpointsummit.com/ModernEndpointManagement2026)

Nope....helaas. Want @ralpje z'n sessie is niet gekozen, dus voor mij geen reden om er heen te gaan dan.

[Hero of Time]

pstalman schreef op dinsdag 10 maart 2026 @ 08:40:
Ik heb nu al een paar keer een Win32 app actief gemaakt en ipv de Command Line optie een Script geselecteerd om de installatie te starten. Nu is bij elke van deze apps al minimaal 1x de optie in het dropdown menu zo maar gewijzigd (van script terug naar commandline), hier mensen die hetzelfde mee maken?

Dat niet, maar wel dat ik helemaal geen optie had voor script, alleen command line. Om dan na het doorlopen van alle stappen opeens wel script kan kiezen wanneer ik 'm bewerk.

---

Heb een vraag over het eenmalig uitvoeren van een script op toegewezen systemen. Ik heb al Platform Scripts gevonden en daar m'n script toegevoegd. Echter wil ik een argument mee kunnen geven, maar dat lijkt niet mogelijk te zijn. Mis ik iets?

Als het niet kan, maak ik maar aparte win32 intunewin apps. Beetje overkill voor iets dat 1x hoeft te draaien en niet op het systeem hoeft te blijven. Het is namelijk om het scherm te draaien. Alternatief is het argument hard in het script te zetten en daar 4 van toe te voegen in Platform Scripts.

[Drardollan]

Ondertussen weet ik waarom mijn SecureBoot niet gevuld wordt. Dit komt omdat de Diagnostic Data blijkbaar niet in mijn Intune aankomt.

Zover ik weet en kan zien staat alles goed, of op zijn minst gelijk aan een andere tenant waar het wel werkt. Dus nu maar eens zien hoe we dit fatsoenlijk kunnen troubleshooten. Dat wordt niet makkelijk ben ik bang.

[HKLM_]

Drardollan schreef op dinsdag 10 maart 2026 @ 20:15:
Ondertussen weet ik waarom mijn SecureBoot niet gevuld wordt. Dit komt omdat de Diagnostic Data blijkbaar niet in mijn Intune aankomt.

Zover ik weet en kan zien staat alles goed, of op zijn minst gelijk aan een andere tenant waar het wel werkt. Dus nu maar eens zien hoe we dit fatsoenlijk kunnen troubleshooten. Dat wordt niet makkelijk ben ik bang.

Doe je iets op firewall niveau met je verkeer (en dan richting MSFT) Vorig jaar hebben ze aan het netwerk zitten klussen aan die kant: https://techcommunity.mic...e-network-changes/4452738

Je zou de Azure Front Door Connectivity Diagnostics Tool for Intune eens kunnen runnen.

[ Voor 5% gewijzigd door HKLM_ op 10-03-2026 20:40 ]

[Drardollan]

HKLM_ schreef op dinsdag 10 maart 2026 @ 20:40:
[...]


Doe je iets op firewall niveau met je verkeer (en dan richting MSFT) Vorig jaar hebben ze aan het netwerk zitten klussen aan die kant: https://techcommunity.mic...e-network-changes/4452738

Je zou de Azure Front Door Connectivity Diagnostics Tool for Intune eens kunnen runnen.

Nope. Niks bijzonders qua firewall. De devices van de tenant die de info wel heeft gebruiken dezelfde verbinding.

Heb al wel wat met Fiddler gekeken van de week en zover ik kon zien werd de data netjes verstuurd en ook met een goede HTTP Status ontvangen.

[HKLM_]

Drardollan schreef op dinsdag 10 maart 2026 @ 20:56:
[...]

Nope. Niks bijzonders qua firewall. De devices van de tenant die de info wel heeft gebruiken dezelfde verbinding.

Heb al wel wat met Fiddler gekeken van de week en zover ik kon zien werd de data netjes verstuurd en ook met een goede HTTP Status ontvangen.

Waar staat je Diagnostic data settings op bij een device welke niet rapporteerd? Deze moet minimaal op Required of meer staan.

[Drardollan]

HKLM_ schreef op woensdag 11 maart 2026 @ 09:13:
[...]


Waar staat je Diagnostic data settings op bij een device welke niet rapporteerd? Deze moet minimaal op Required of meer staan.

[Afbeelding]

Yep, staat allemaal op Required / Basic. En alle registry keys op zowel werkende tenant devices als de niet werkende devices zijn gelijk. Ik weet ook zeker dat de data naar MS gestuurd wordt, dat heb ik nu meermaals zien gebeuren.

Maar ergens is een wonder aan het gebeuren. Ik heb in mijn Devices - Autopatch overzicht nu 1 machine die gestopt is met de alert "Device diagnostic data not received" en die is overgegaan naar "Automatic update settings misconfigured" (wat vast een nieuw probleem is, maar dat is voor later). Een ander device heeft zelfs de status "No alerts" gekregen.

Om het dan nog even wat complexer te maken, het Secure Boot report geeft nu óók data voor 2 devices. En voor wie verwacht dat het dan de devices zijn die hierboven van status veranderd zijn... Nee, dat dan weer niet. 2 totaal andere devices

Het enige wat ik kan bedenken is het feit dat ik pas vrijdag of maandagochtend (weet het niet meer exact) in deze tenant de setting "Enable features that require Windows diagnostic data in processor configuration" heb aangezet. Misschien dat die dagen nodig heeft om de boel bij MS op de achtergrond te verwerken? Stond geen melding of notificatie bij verder dat het langer zou duren dan een paar minuten.

We gaan het zien, het lijkt er wel op dat een en ander zich nu gaat vullen. Eens zien hoe dit gaat aflopen de komende dagen.

[pstalman]

Hero of Time schreef op dinsdag 10 maart 2026 @ 19:32:
[...]

Dat niet, maar wel dat ik helemaal geen optie had voor script, alleen command line. Om dan na het doorlopen van alle stappen opeens wel script kan kiezen wanneer ik 'm bewerk.

ah zou je het eens in de gaten kunnen houden dat het niet zomaar overspringt.
En ik kan ook pas het dropdown menu selecteren als er 1 teken in de command line geplaatst is.

[Drardollan]

@HKLM_ Dank voor het meedenken nog!

Langzaam druppelt er van alles binnen nu. Ineens 40% van de machines in het Secure Boot Report en in het Device overview ook steeds meer meldingen. Wel andere errors, maar dat is precies het idee van het overzicht. Laat het de komende dagen nog maar lekker binnendruppelen, kijken wat eruit komt.

Wel leuk om te zien dat mijn fixes voor de Secure Boot installatie op de devices goed werkt. Heb recent de Dell Command Update software uitgerold en er Intune policies achteraan gegooid om devices up to date te brengen. Dat lijkt goed te werken met de 40% die ik nu zie, op 1 na hebben alle devices recente versies van de BIOS en Secure Boot bijgewerkt. De ene die het niet gedaan heeft komt door missende Windows updates.

En dan te bedenken dat ik tot begin dit jaar 0 kennis en ervaring had met Intune. Nu kan ik er al behoorlijk mijn weg in vinden en voelt het elke dag comfortabeler om mee om te gaan.

[pjlgt]

Ivm certificering en wensen/eisen op het gebied van beveiliging zijn we aan het kijken wat te doen met toegang via unmanaged devices tot onze omgeving. Men begon al gelijk over het aanschaffen van een lading laptops voor die personen, maar denk dat we zeker gezien het werk wat men gaat doen het ook prima afkunnen met een Azure Virtual Desktop of Windows 365 oplossing. Gaat om het werken met een aantal SAAS oplossingen, dus eigenlijk enkel wat browser werk. Toegang hiervan gaat met een smartcard, dus dat moet wel ondersteund worden. Hier mensen ervaring met AVD of Windows 365? Laatste is kwa licenties en beheer eigenlijk prima betaalbaar. Zeker de Frontline optie. 1 licentie voor 3 gebruikers (niet concurrend uiteraard)

[nextware]

pjlgt schreef op woensdag 11 maart 2026 @ 14:39:
Ivm certificering en wensen/eisen op het gebied van beveiliging zijn we aan het kijken wat te doen met toegang via unmanaged toegang tot onze omgeving. Men begon al gelijk over het aanschaffen van een lading laptops voor die personen, maar denk dat we zeker gezien het werk wat men gaat doen het ook prima afkunnen met een Azure Virtual Desktop of Windows 365 oplossing. Gaat om het werken met een aantal SAAS oplossingen, dus eigenlijk enkel wat browser werk. Toegang hiervan gaat met een smartcard, dus dat moet wel ondersteund worden. Hier mensen ervaring met AVD of Windows 365? Laatste is kwa licenties en beheer eigenlijk prima betaalbaar. Zeker de Frontline optie. 1 licentie voor 3 gebruikers (niet concurrend uiteraard)

Unmanaged toegang ? Moet ik dan denken aan leveranciers die toegang moet krijgen tot jullie omgeving ?
Kijk anders naar een jump server die je met een goede Remote Access toegang beheert toegang geeft. Mooie tool die ik daarvoor ken is BeyondTrust PRA.

[ralpje]

Wat wil je weten over Win365? Hier zitten we midden in een grote uitrol van Win365 - onder andere voor de scenario's die jij omschrijft (externen die toegang nodig hebben tot welk deel van onze infra dan ook een managed workplace geven zonder een fysiek device).
We gebruiken hier een mix van Enterprise, Frontline en Frontline Shared / Cloud Apps - ook in combinatie met FIDO2 (in de vorm van card en USB-keys).

[pjlgt]

nextware schreef op woensdag 11 maart 2026 @ 15:44:
[...]


Unmanaged toegang ? Moet ik dan denken aan leveranciers die toegang moet krijgen tot jullie omgeving ?
Kijk anders naar een jump server die je met een goede Remote Access toegang beheert toegang geeft. Mooie tool die ik daarvoor ken is BeyondTrust PRA.

Bedoelde via unmanaged devices. Tekst aangepast.

[pjlgt]

ralpje schreef op woensdag 11 maart 2026 @ 16:00:
Wat wil je weten over Win365? Hier zitten we midden in een grote uitrol van Win365 - onder andere voor de scenario's die jij omschrijft (externen die toegang nodig hebben tot welk deel van onze infra dan ook een managed workplace geven zonder een fysiek device).
We gebruiken hier een mix van Enterprise, Frontline en Frontline Shared / Cloud Apps - ook in combinatie met FIDO2 (in de vorm van card en USB-keys).

Denk dat de dedicated Frontline optie goed bij ons doel past. Maar ben vooral benieuwd naar hoe de performance is. En hoe de smartcard redirection bevalt. Zonder dat laatste kan het hele idee wel in de prullenbak.

Denk dat ik morgen maar even de trail van Windows 365 ga activeren. Dan hebben we een maand om te testen.

[ Voor 6% gewijzigd door pjlgt op 11-03-2026 18:10 ]

[Hero of Time]

pstalman schreef op woensdag 11 maart 2026 @ 10:42:
[...]

ah zou je het eens in de gaten kunnen houden dat het niet zomaar overspringt.

Zolang je de app niet bewerkt, zou het niet zomaar moeten veranderen. Van de paar die ik heb met script is het nog gewoon zo, maar ik hoef die dan ook niet meer te bewerken, het script werkt en bij een nieuwe versie van de app wordt het ook een nieuwe deployment met supersedence.

En ik kan ook pas het dropdown menu selecteren als er 1 teken in de command line geplaatst is.

Daar kwam ik vandaag ook achter. Echt weer achterlijk gedrag van een MS product. Net zoals toen ik met een nieuwe app bezig was, een manual detection rule had gemaakt voor 'file exists', even keek wat de andere optie was met script en weer terug schakelde naar manual. Bovenin bij de stappen kwam er een rood kruis te staan en ik kon met geen mogelijkheid verder. Hele app wizard moeten annuleren en van voor af aan beginnen.

Die app heb ik ook sowieso opnieuw moeten maken, want ik heb m'n scherm draai script erin gegoten. Echter schrijft het niks weg. Dus toen ik bij de detection rule kwam, was het 'oh, shit, dat is waar ook' en kon ik weer van voor af aan beginnen.

Ik had dus gisteren het als platform script aangemaakt. Ik zag echter niks veranderen op het scherm, terwijl de status doodleuk veranderde naar 1x succes. Wissel van de kiosk gebruiker naar m'n admin, bekijk de logs, geen melding van m'n script naam, maar het ID was wel te vinden. Het leek idd netjes uitgevoerd te zijn. Maar omdat het onder het system context draaide, lijkt het geen toegang of effect te hebben op het scherm. Begrijpelijk in zekere zin, want system draait niet interactief of zichtbaar. In Linux zou hetzelfde zijn als je iets voor een GUI wilt doen terwijl je op een TTY zit, dat gaat ook niet.

Nu hopen dat de app wel werkt, maar die heb ik ook op system context staan. Draaien onder gebruiker context gaat niet werken denk ik, want de kiosk gebruiker die standaard door de config wordt aangemaakt is een domme, licentieloze lokale gebruiker en triggert verders niks qua user context config. Ik vraag mij nu echt af hoe ik in vredesnaam de oriëntatie van het scherm aanpas zonder de noodzaak om met een andere gebruiker in te loggen.

[Hero of Time]

Owja, heb voor onze omgeving ook maar even gekeken naar de secure boot reportage. De apparaten staan er in, maar allemaal op 'not applicable'. Geweldig. De config die onze MSP had geïmporteerde zette de diagnostics ook uit. In de test config staat dat via een OMA-URI, maar diezelfde config voor productie is niet toegewezen aan apparaten. Daar is de telemetry via device restrictions uitgeschakeld.

Dat dus daar weg gegooid, nieuwe config gemaakt met Settings Catalog en de 4 opties die ik op een blogpost vond toegepast. Dat is dus diagnostics op 1 (required), notificatie uit, optie voor gebruikers beperken en device name mee sturen. Nu is het wachten en anders moet ik de tenant optie aanzetten die @Drardollan ook heeft aangezet in zijn omgeving. Wij hebben voornamelijk Dell systemen en de desktops krijgen bij uitrol op dat moment de meest recente BIOS versie. Bij laptops net zo, maar hopelijk doen gebruikers daar iets eerder op 'install' klikken. Zal wel eens kijken naar een GPO voor Dell Command Update. Ik heb die al optioneel in de company portal staan (ook versie 5.6.0 die .NET 8 vereist, met die installer er bij).

[HKLM_]

Hero of Time schreef op woensdag 11 maart 2026 @ 19:25:
Owja, heb voor onze omgeving ook maar even gekeken naar de secure boot reportage. De apparaten staan er in, maar allemaal op 'not applicable'. Geweldig. De config die onze MSP had geïmporteerde zette de diagnostics ook uit. In de test config staat dat via een OMA-URI, maar diezelfde config voor productie is niet toegewezen aan apparaten. Daar is de telemetry via device restrictions uitgeschakeld.

Dat dus daar weg gegooid, nieuwe config gemaakt met Settings Catalog en de 4 opties die ik op een blogpost vond toegepast. Dat is dus diagnostics op 1 (required), notificatie uit, optie voor gebruikers beperken en device name mee sturen. Nu is het wachten en anders moet ik de tenant optie aanzetten die @Drardollan ook heeft aangezet in zijn omgeving. Wij hebben voornamelijk Dell systemen en de desktops krijgen bij uitrol op dat moment de meest recente BIOS versie. Bij laptops net zo, maar hopelijk doen gebruikers daar iets eerder op 'install' klikken. Zal wel eens kijken naar een GPO voor Dell Command Update. Ik heb die al optioneel in de company portal staan (ook versie 5.6.0 die .NET 8 vereist, met die installer er bij).

Maak je al gebruik van Dell Command | DCECMI (Endpoint Configure for Microsoft Intune) vanuit Microsoft Intune? Via de setting catalog kan je als profile kiezen voor templates en dan Bios Configurations and other settings en dan kom je uit op een setting catalog pagina om een configuration profile van de dell command te uploaden welke op je devices wordt toegepast.

Ik heb ooit toen dit net nieuw was de bios wachtwoorden ingesteld voor de devices en deze worden netjes in het Entra ID object van het device opgeslagen

[Hero of Time]

@HKLM_, nee, maar dat is dus iets waar ik wel naar ga kijken in de toekomst. Ben nog een beetje van de oude stempel, met GPO bedoelde ik dus Intune config dinges.

BIOS is ook iets wat ik voor onze kiosk naar moet kijken. Geen idee of er een standaard voor is dat Elo ook snapt. Want het kan wel eens gebeuren dat onze servicedesker vergeet de RTC wake alarm in te stellen. En in de aparte situatie dat de CMOS batterij leeg is, is het ook wel handig. Daar hebben een paar oudere kiosken last van en het gebeurt wel eens dat die stroom verliezen met daarbij dus die instelling.

[Drardollan]

HKLM_ schreef op woensdag 11 maart 2026 @ 19:39:
[...]


Maak je al gebruik van Dell Command | DCECMI (Endpoint Configure for Microsoft Intune) vanuit Microsoft Intune? Via de setting catalog kan je als profile kiezen voor templates en dan Bios Configurations and other settings en dan kom je uit op een setting catalog pagina om een configuration profile van de dell command te uploaden welke op je devices wordt toegepast.

Ik heb ooit toen dit net nieuw was de bios wachtwoorden ingesteld voor de devices en deze worden netjes in het Entra ID object van het device opgeslagen

Als BIOS wachtwoorden niet nodig zijn is er een simpelere manier. In de “oude” Dell Command Update (dus niet de Universal variant) zitten ADMX files. Deze kan je in Intune importeren. Uit de Universal variant kan je een MSI plukken.

En dan is de combinatie wel duidelijk

Voor mij is dat voldoende, heb mij nog nooit druk gemaakt over BIOS wachtwoorden om eerlijk te zijn. Als je die goed wil beveiligen moet je ook de reset optie uitschakelen (de vroegere jumper), maar dan kan je de boel compleet bricken. Heb de laatste 20 jaar geen gebruiker ooit betrapt op de BIOS openen. Maar kan mij goed voorstellen dat andere omgevingen andere eisen hebben

[Drardollan]

Na gisteren weinig veranderingen helaas. Geen extra machines waarvan de Diagnostic Data ontvangen is en ook het Secure Boot rapport staat stil. Nu was het wel woensdag en traditioneel is dat hier een dag waarop er weinig gewerkt wordt, maar toch wel jammer.

[pstalman]

Hero of Time schreef op woensdag 11 maart 2026 @ 19:50:
@HKLM_, nee, maar dat is dus iets waar ik wel naar ga kijken in de toekomst. Ben nog een beetje van de oude stempel, met GPO bedoelde ik dus Intune config dinges.

BIOS is ook iets wat ik voor onze kiosk naar moet kijken. Geen idee of er een standaard voor is dat Elo ook snapt. Want het kan wel eens gebeuren dat onze servicedesker vergeet de RTC wake alarm in te stellen. En in de aparte situatie dat de CMOS batterij leeg is, is het ook wel handig. Daar hebben een paar oudere kiosken last van en het gebeurt wel eens dat die stroom verliezen met daarbij dus die instelling.

Misschien handig om dat te automatiseren, want dan vergeet een ander het ook niet.
Wij laten zo alle Kiosk en andere machines het weekend aangaan voor de default onderhoudstaken.
Het werkt best goed ipv WoL vroeger.

[Hero of Time]

pstalman schreef op donderdag 12 maart 2026 @ 13:20:
[...]

Misschien handig om dat te automatiseren, want dan vergeet een ander het ook niet.
Wij laten zo alle Kiosk en andere machines het weekend aangaan voor de default onderhoudstaken.
Het werkt best goed ipv WoL vroeger.

Helaas geen tool of interface kunnen vinden voor Elo Touch all-in-one systemen. De UEFI firmware settings ding van Intune doet geen RTC alarm optie, dus dat is ook geen oplossing helaas. Dus dat stukje automatiseren gaat helaas niet. Nou scheelt het wel dat bij deze dingen het BIOS zonder toetsenbord is te bereiken. We hebben al vaker mensen hier doorheen begeleid.

En het draaien van het scherm heb ik maar opgegeven. Platform Script, app, zelfs een scheduled task maken gaf niet het gewenste effect. Bij het laatste zie ik de taak wel, staat op een tijd in het verleden met de optie om het alsnog direct uit te voeren als 't gemist is, maar zelfs met herstarten wordt het niet getriggered. Er is geen 'once at logon', alleen 'once at x uur'.

Maar ik kwam erachter dat via VNC winkey+i sturen het instellingen scherm opent waardoor je alsnog naar de scherm instellingen kan. Via een fysiek toetsenbord eraan werkt dit niet en het onscreen keyboard dat verschijnt heeft geen windows toets. Dus dat is afgevangen. Enige kleine nadeel is dat het instellingen scherm niet te sluiten is, het kruisje ontbreekt en alt+F4 doet het ook niet. Dan maar herstarten of ctrl+alt+del er heen sturen en opnieuw inloggen. Wat trouwens ook grappig is, want c-a-d via VNC geeft het scherm met opties, terwijl dat met een fysiek toetsenbord zorgt dat het scherm vergrendeld wordt.

Ik ben zo wel tevreden over de config. De pinch zoom is dan maar aan de devs van de site die getoond wordt om te fixen.