Microsoft Intune ervaringentopic

[makooy]

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

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

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

Vervolgens wat Modified attributes, New value

Target / PropertyName / Old Value / New Value

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

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

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

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

[akimosan]

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

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

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

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

Phew..

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

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

[HKLM_]

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

[repmeer]

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

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

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

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

Phew..

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

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

[nextware]

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

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

[DDX]

Macos 27 released.
Nu hebben we in intune netjes ingesteld staan Major Period In Days: 14
Leek soort van goed te werken, mijn (test)mac kwam gisteren met melding dat macos 27 klaar stond maar klikte ik daarop werd enkel 26.7 aangeboden (die tegelijk released was met security updates)
Alleen vandaag toch weer 27 aangeboden en die installeerde ook gewoon...

Na installatie popup van company portal met sign-in request op entra. (voor sso)
Alleen accept die niet mijn wachtwoord. (zoiezo username lijkt daar zonder domein te zijn...)

[HKLM_]

DDX schreef op woensdag 16 september 2026 @ 10:48:
Macos 27 released.
Nu hebben we in intune netjes ingesteld staan Major Period In Days: 14
Leek soort van goed te werken, mijn (test)mac kwam gisteren met melding dat macos 27 klaar stond maar klikte ik daarop werd enkel 26.7 aangeboden (die tegelijk released was met security updates)
Alleen vandaag toch weer 27 aangeboden en die installeerde ook gewoon...

Na installatie popup van company portal met sign-in request op entra. (voor sso)
Alleen accept die niet mijn wachtwoord. (zoiezo username lijkt daar zonder domein te zijn...)

Dat van OS27 aanklikken en dat dan 26.7 geinstalleerd wordt is een bug naar mijn weten, op X en volgens mij ook op de FB onder het artikel heb ik dit zien terug komen bij mensen die gingen up-daten.

[Blokker_1999]

Even een lekker ouderwetse vraag: hoe doen jullie het met fileshares? Gewoon aan de user overlaten? Scripten gebruiken? Registry settings? ADMX ingestion?

[TheVMaster]

Blokker_1999 schreef op woensdag 16 september 2026 @ 11:48:
Even een lekker ouderwetse vraag: hoe doen jullie het met fileshares? Gewoon aan de user overlaten? Scripten gebruiken? Registry settings? ADMX ingestion?

Die zijn er niet meer. Althans bij de projecten waar ik Intune kom doen, daar is het device stuk maar een deel van. Vaak is het een combi van Microsoft 365, en dan gaat alles naar OneDrive/SharePoint.

[ Voor 18% gewijzigd door TheVMaster op 16-09-2026 12:00 ]

[Davidas]

Blokker_1999 schreef op woensdag 16 september 2026 @ 11:48:
Even een lekker ouderwetse vraag: hoe doen jullie het met fileshares? Gewoon aan de user overlaten? Scripten gebruiken? Registry settings? ADMX ingestion?

Als ik het nog tegenkom en we ontkomen er niet aan dan via ADMX.

[HKLM_]

Poe tijd geleden, de laatste keer heb ik ADMX gebruikt met die aangepaste van rudy en wel met cloud kerberos ivm whfb.

@Blokker_1999 Deze: Intune Drive Mappings | Managing Drive letters with an ADMX

[ Voor 40% gewijzigd door HKLM_ op 16-09-2026 12:29 ]

[ZeRoC00L]

Blokker_1999 schreef op woensdag 16 september 2026 @ 11:48:
Even een lekker ouderwetse vraag: hoe doen jullie het met fileshares? Gewoon aan de user overlaten? Scripten gebruiken? Registry settings? ADMX ingestion?

Deze gebruik ik meestal:

https://intunedrivemapping.azurewebsites.net/

ICM Cloud Kerberos ivm Entra Only devices.

[Davidas]

ZeRoC00L schreef op woensdag 16 september 2026 @ 12:16:
[...]

Deze gebruik ik meestal:

https://intunedrivemapping.azurewebsites.net/

ICM Cloud Kerberos ivm Entra Only devices.

Heb het via deze weg nooit goed kunnen instellen, ook al had ik Cloud Kerberos ingericht.

[ Voor 3% gewijzigd door Davidas op 16-09-2026 12:25 ]

[HKLM_]

ZeRoC00L schreef op woensdag 16 september 2026 @ 12:16:
[...]

Deze gebruik ik meestal:

https://intunedrivemapping.azurewebsites.net/

ICM Cloud Kerberos ivm Entra Only devices.

Dat Script wat gebruikt wordt is echt belachelijk groot voor wat het moet doen

[ralpje]

HKLM_ schreef op woensdag 16 september 2026 @ 12:28:
[...]

Dat Script wat gebruikt wordt is echt belachelijk groot voor wat het moet doen

Mwa. Het houdt rekening met wat edge cases, het checkt groupmemberships voor de mapping, verwijderd drives als je uit een groep gehaald bent, doet een stukje logging.... Ik snap de complexiteit wel. Kun je het minder? Vast. Maar omdat dit een script is wat publiek aangeboden wordt wil je dat alle mogelijke situaties hier ook gelijk in meegenomen zijn en dat maakt het gelijk een stuk compleser.

[DDX]

HKLM_ schreef op woensdag 16 september 2026 @ 11:38:
[...]

Dat van OS27 aanklikken en dat dan 26.7 geinstalleerd wordt is een bug naar mijn weten, op X en volgens mij ook op de FB onder het artikel heb ik dit zien terug komen bij mensen die gingen up-daten.

Zal in dezelfde bug wel iets zitten dat 27 niet als major gezien wordt en zich dus niets aantrekt van de intune/mdm setting om de major pas later aan te bieden.

[grimson]

'Hier' onlangs ook de ADMX drive mappings template geïmporteerd en gebruikt.
In combinatie met Cloud Kerberos trust werkt het ook goed via een VPN, de mappings blijven 'persistent' aanwezig. Ook als je een mapping weghaalt en weer aanmeld (op de computer) komt hij terug.

Het is niet echt fraai maar het werkt

Oja de mappings zijn niet in NetBIOS style als \\fileserver\share maar in FQDN style als \\fileserver.domain.dit\share.

Volgens mij doet Kerberos het beter met FQDN namen zegmaar.

[ Voor 24% gewijzigd door grimson op 16-09-2026 16:20 ]

[Blokker_1999]

TheVMaster schreef op woensdag 16 september 2026 @ 11:58:
[...]

Die zijn er niet meer. Althans bij de projecten waar ik Intune kom doen, daar is het device stuk maar een deel van. Vaak is het een combi van Microsoft 365, en dan gaat alles naar OneDrive/SharePoint.

Te veel legacy in de omgeving op dit moment. We zijn sinds deze zomer bezig met een verhuis naar Azure, waarbij we ook voor het eerst non-domain joined AVDs gaan opzetten maar aan de andere kant moeten onze file shares ook over naar storage accounts waarbij vele shares nu al gaan aanlopen tegen de beperkingen van de Azure backup policies (max 10TB en max 10 miljoen bestanden) waardoor we DFS shares verder gaan moeten uitsplitsen. En we lopen ook verder aan tegen data die we vandaag ontsluiten met access based enumeration, wat ook niet meer werkt en we ook weer oplossingen voor moeten zoeken.

En SharePoint is voor veel van deze data geen oplossing, want het zijn geen office documenten, het is niet echt data die gebruikers verwerken. We hebben shares van tientallen terabytes vol met builds en dus binaire data, terabytes aan database en memory dumps, ... . Dat zet je niet op SP .

[TheVMaster]

Blokker_1999 schreef op woensdag 16 september 2026 @ 19:53:
[...]

Te veel legacy in de omgeving op dit moment. We zijn sinds deze zomer bezig met een verhuis naar Azure, waarbij we ook voor het eerst non-domain joined AVDs gaan opzetten maar aan de andere kant moeten onze file shares ook over naar storage accounts waarbij vele shares nu al gaan aanlopen tegen de beperkingen van de Azure backup policies (max 10TB en max 10 miljoen bestanden) waardoor we DFS shares verder gaan moeten uitsplitsen. En we lopen ook verder aan tegen data die we vandaag ontsluiten met access based enumeration, wat ook niet meer werkt en we ook weer oplossingen voor moeten zoeken.

En SharePoint is voor veel van deze data geen oplossing, want het zijn geen office documenten, het is niet echt data die gebruikers verwerken. We hebben shares van tientallen terabytes vol met builds en dus binaire data, terabytes aan database en memory dumps, ... . Dat zet je niet op SP .

AVD's...? Waarom niet naar Windows 365? Hmm...geen idee hoe developers dat doen, heb wel met veel developers te maken. Zij gebruiken allemaal DevBoxes (en/of Windows 365). Hun data staat niet op fileshares weet ik....

[HKLM_]

TheVMaster schreef op donderdag 17 september 2026 @ 01:31:
[...]

AVD's...? Waarom niet naar Windows 365? Hmm...geen idee hoe developers dat doen, heb wel met veel developers te maken. Zij gebruiken allemaal DevBoxes (en/of Windows 365). Hun data staat niet op fileshares weet ik....

Omdat AVD soms de betere keuze is ten opzichte van Windows 365. Als je het rekensommetje gaat maken AVD/W365 dan komt daar regelmatig nog steeds AVD uit (wel afhankelijk van de case natuurlijk)

Zeker als je een beetje performance wilt is W365 knetter duur, en anders is het niet vooruit te branden.

[HKLM_]

DDX schreef op woensdag 16 september 2026 @ 15:59:
[...]


Zal in dezelfde bug wel iets zitten dat 27 niet als major gezien wordt en zich dus niets aantrekt van de intune/mdm setting om de major pas later aan te bieden.

Zag deze voorbij komen om 27 aan te bieden vanuit Intune ipv 26.7

[Davidas]

Met de RBAC rol Intune Administrator moet ik toch Windows 365 Cloud PC kunnen beheren?

bijvoorbeeld een provisioning policy aanmaken. Krijg nu namelijk een foutmelding dat ik niet genoeg rechten heb, zal dat komen omdat we nog geen enkele Windows 365 subscriptie actief hebben in de betreffende tenant?

[HKLM_]

Davidas schreef op donderdag 17 september 2026 @ 08:33:
Met de RBAC rol Intune Administrator moet ik toch Windows 365 Cloud PC kunnen beheren?

bijvoorbeeld een provisioning policy aanmaken. Krijg nu namelijk een foutmelding dat ik niet genoeg rechten heb, zal dat komen omdat we nog geen enkele Windows 365 subscriptie actief hebben in de betreffende tenant?

Daar zit die inderdaad, je moet wel een W365 licentie hebben wil je zaken kunnen configureren, de Intune Administrator rol kan dat dan doen ja

[DennusF]

Er is wel wat gewijzigd binnen intune, eerder kon onze servicedesk gewoon devices wipen en zonder wijziging in de rechten kunnen ze alleen nog maar compliant devices wipen.

[Blokker_1999]

TheVMaster schreef op donderdag 17 september 2026 @ 01:31:
[...]

AVD's...? Waarom niet naar Windows 365? Hmm...geen idee hoe developers dat doen, heb wel met veel developers te maken. Zij gebruiken allemaal DevBoxes (en/of Windows 365). Hun data staat niet op fileshares weet ik....

Omdat er redelijk wat dingen zijn die niet mogelijk zijn met W365. Zo kan je geen multisessie systemen maken, eenvoudig op- en afschalen. Wanneer je mensen 8u per werkdag werken moet je bij W365 nog altijd voor 24/7 uptime betalen, de netwerkmogelijkheden zijn beperkter, met AVD kunnen we ook gebruik maken van onze E3/E5 licenties voor de windows licentie kost af te dekken.

* Blokker_1999 had hier nog veel uitleg getypt, maar toch maar weer verwijderd, want teveel interne info delen wordt ook niet echt gewaardeerd

[HKLM_]

Blokker_1999 schreef op donderdag 17 september 2026 @ 09:09:
[...]

Omdat er redelijk wat dingen zijn die niet mogelijk zijn met W365. Zo kan je geen multisessie systemen maken, eenvoudig op- en afschalen. Wanneer je mensen 8u per werkdag werken moet je bij W365 nog altijd voor 24/7 uptime betalen, de netwerkmogelijkheden zijn beperkter, met AVD kunnen we ook gebruik maken van onze E3/E5 licenties voor de windows licentie kost af te dekken.

* Blokker_1999 had hier nog veel uitleg getypt, maar toch maar weer verwijderd, want teveel interne info delen wordt ook niet echt gewaardeerd

Kan je deze eens toelichten? "de netwerkmogelijkheden zijn beperkter" Ik ben benieuwd wat je al beperkter ziet? W365 kan je namelijk volledig over Azure Network Connection laten routeren, je kan dan extreem ver gaan net zoals bij AVD.

[Blokker_1999]

Het is al weer even geleden dat we de sessies daaromtrend gehad hebben, maar van wat ik mij daarvan herinner en wat AI ook snel onderschrijft heeft (of had) W365 minder mogelijkheden rondom NSGs alsook peering met VPN/Expressroute.

Kan uiteraard zijn dat daar ondertussen ook alweer werk van is gemaakt, maar dan nog blijven er andere nadelen staan voor ons.

Neemt niet weg dat W365 in vele gevallen uiteraard gewoon wel een goed alternatief kan zijn.

[ralpje]

Zoals ik het meestal breng (en ik mag mezelf sinds de laatste renewal Windows 365 MVP noemen, yay!) zit het verschil met name op de beheerslaag. Wil je wel gevirtualiseerde desktops kunnen aanbieden, maar je niet druk maken om de achterlaag aan sessie-hosts, images, gateways, en dat soort meuk? Dan ga je voor W365.

Ja, door de multi-sessie opties in AVD kán dat goedkoper zijn (als zijn er met de Flex Shared en Flex Dedicated ook prima alternatieven in W365) - maar als je 'verborgen' kosten van die achterkant meerekent kan die rekensom wel eens alsnog uitvallen in het voordeel van W365.

Maar goed, consultancy antwoord: it depends

[Quad]

Mijn klanten worden vooral blij van: het kost je 80 euro per maand dan: het kan 50 euro kosten, maar misschien ook wel 120 euro..

[HKLM_]

ralpje schreef op donderdag 17 september 2026 @ 22:24:
Zoals ik het meestal breng (en ik mag mezelf sinds de laatste renewal Windows 365 MVP noemen, yay!) zit het verschil met name op de beheerslaag. Wil je wel gevirtualiseerde desktops kunnen aanbieden, maar je niet druk maken om de achterlaag aan sessie-hosts, images, gateways, en dat soort meuk? Dan ga je voor W365.

Ja, door de multi-sessie opties in AVD kán dat goedkoper zijn (als zijn er met de Flex Shared en Flex Dedicated ook prima alternatieven in W365) - maar als je 'verborgen' kosten van die achterkant meerekent kan die rekensom wel eens alsnog uitvallen in het voordeel van W365.

Maar goed, consultancy antwoord: it depends

Die beheerslaag is wel een heel interesant item binnen W365 inderdaad, Hoe ga jij om met Windows updates op de Windows 365 Cloud PC machines? Onboard je ze in Windows Autopatch?

Bij AVD update je de sessie host en merkt de gebruiker er helemaal niets van, mijn ervaring is bij Windows 365 dat het meer een "normal" device is welke toch met updates komt soms maar dat kan ook een config dingetje zijn. (Voor flex weet ik dat ze iets speciaals hebben gemaakt bij een inactieve CPC)

[DDX]

HKLM_ schreef op donderdag 17 september 2026 @ 06:57:
[...]

Zag deze voorbij komen om 27 aan te bieden vanuit Intune ipv 26.7

[Afbeelding]

Ik kom die hele setting niet tegen in intune bij Declarative Device Management (DDM)
Lijkt een iOS setting te zijn.

[ Voor 3% gewijzigd door DDX op 18-09-2026 11:13 ]

[Blokker_1999]

ralpje schreef op donderdag 17 september 2026 @ 22:24:
...

Maar goed, consultancy antwoord: it depends

Tsjah, dat is natuurlijk altijd het antwoord. Elke situatie is uniek en als je eenmaal een goed beelt hebt op de benodigheden kan je een goed advies uitbrengen met wat vandaag beschikbaar is.

[ralpje]

HKLM_ schreef op vrijdag 18 september 2026 @ 10:16:
[...]

Die beheerslaag is wel een heel interesant item binnen W365 inderdaad, Hoe ga jij om met Windows updates op de Windows 365 Cloud PC machines? Onboard je ze in Windows Autopatch?

Ja, ik onboard ze in Autopatch. Eigenlijk is dat ook een beetje in de lijn met wat in aan eindgebruikers uitleg: je krijgt een laptop van bedrijf X, maar het is geen laptop maar een computer ergens in een datacenter. Alle settings, software, updatebeleid, etc. is dan ook gewoon vergelijkbaar met een reguliere laptop.

Nou heb ik ook best wat Flex en Flex Shared machines draaien (voor het publishen van een app of een desktop) en daar is dat natuurlijk weer net ff wat anders en doen we periodiek een reprovisioning om de updates in de basis mee te laten komen. Dus ook hier: it depends

[Hero of Time]

Het is jammer dat er niet een optie is om vanuit Intune bij een device direct een applicatie te verwijderen die gevonden is. We hebben nieuwe kiosken waar de monitoring piept over Intel License Manager service. Geen flauw idee waarom die troep erop staat, want het is bedoelt voor developers. Er staat wel wat Intel software op, maar dat is voor de videokaart. Kan nou niet echt iets vinden over 'license' in de lijst van gedetecteerde software.

Heb nu maar de service op de ignore lijst gegooid van m'n monitoring, maar had liever de software er helemaal niet op.

[Quad]

@Hero of Time Uitzoeken hoe te verwijderen en dan de 'installatie' als win32app uploaden naar Intune met devices op verwijderen?

[Hero of Time]

@Quad, ja, dat zag ik ook zo'n beetje als antwoord. Probleem is, ik heb geen flauw idee welk pakket die Intune heeft gevonden de license manager bevat. En online vind ik info van Intel met dit:

Login to the Intel Registration Center. Find the Intel Software License Manager in your product list and click the Version link.

Dat gaat er dus van uit dat je een account hebt waar je de licentie manager mee wilt downloaden zodat je de license server kan opzetten. Andere resultaten gaan weer over welke services uit te schakelen zijn. Dat zie ik ook niet in Intune om services te beheren.

Sowieso nogal ruk om die service mee te leveren, die dus niet start, met een driver. Het is opeens aanwezig bij twee kiosks die het eerder niet hadden.

[akimosan]

Hoe komt het op de kiosken?

• Windows update policy die automatisch driver updates goedkeurt (komt dan mee met een Windows driver update
• Software die anderszins drivers en apps up-to-date houdt (denk aan iets als Dell Command Update of vergelijkbare vendor software)

Zoiets?

Zie bijvoorbeeld:

Driver voor Intel Management Engine Interface | Details driver | Dell Nederland

Daarin komt Intel Platform License Manager Service ook mee.

Het is waarschijnlijk NIET de Intel Software License Manager (dat is inderdaad een door Intel "branded" FlexLM license service voor floating licenses)

[ Voor 46% gewijzigd door akimosan op 21-09-2026 21:10 ]

[Hero of Time]

Er staat idd een redelijk basic en standaard WU policy in onze Intune voor alle apparaten. Dit bevat ook drivers en de kiosken hebben een Intel iGPU. We hebben twee merken kiosken in Intune, maar alleen 1 van de twee typen heeft deze service. Morgen kijk ik ook iets verder, toen ik de mails erover zag konden ze al gebruikt worden en was het niet zo makkelijk meer om wat te proberen (voor zover dat mogelijk is in kiosk mode).

[HKLM_]

Intune deployment plans is naar de public preview state gegaan: https://learn.microsoft.com/en-us/intune/device-management/deployments/overview

Zeker even de moeite waard om te bekijken, ik heb hem vanuit de private preview mogen testen en het is een mooie optie om applicaties of configuration profiles ring based te deployen. Vragen ask!

[Hero of Time]

Vanochtend naar die kiosk gekeken. De melding in m'n monitoring was op dezelfde dag als de Intel video driver update. En uiteraard omdat het kiosk is, kan er niks interactief verwijdert worden. Ding staat nu in de exclude bij m'n monitoring.

[Blokker_1999]

Drivers ... gruwel ... gruwel. Direct een reden dat ik nooit automatisch drivers goedkeur in Intune en softwarecomponenten ook niet snel handmatig zal goedkeuren.

[akimosan]

Blijft natuurlijk ook een kat en muis spel.

Regelmatig kwetsbaarheden die nog in drivers en bijkomende software geleverd worden. Dus ook drivers en biossen en microcontrollers moeten gepatched worden.

En kiosk systemen zijn in principe vaak ook juist fysiek bereikbaar en daarmee kwetsbaar.

[Blokker_1999]

Klopt, maar ook daarom is selectief zijn niet slecht, want wat er niet op staat kan ook niet kapot . Maar wat er op staat moet je uiteraard wel bijwerken.

Maar een andere reden dat ik geen automatische goedkeuring geef is net om wat ik vorige week weer op mijn eigen laptop gezien heb, 1 van de weinige test toestellen in productie. Intel brengt over enkele dagen verspreid een hoop driver updates uit, die installeren verspreid over meerdere dagen en het aantal reboots dat ik heb gehad waarbij je binnen het kwartier moet herstarten, zonder pardon, was niet op 1 hand te tellen.

[HKLM_]

Windows 11 26H2 is GA An IT pro’s guide to Windows 11, version 26H2 - Windows IT Pro Blog

[Quad]

Eens zien wanneer deze voor OSD beschikbaar is.

[HKLM_]

Er is ook een nieuwe security baseline: https://techcommunity.microsoft.com/blog/microsoft-security-baselines/windows-11-version-26h2-security-baseline/4560382

[willempjuh]

Anderen problemen met preprovisioning vandaag? Apparaat lijkt geen verbinding te maken met de Intune tennant.

[YaYo86]

Ja er zijn problemen, wij kunnen geen hashes uploaden en met de tenant verbinden in de OOBE.

https://www.reddit.com/r/Intune/comments/1wtty57/autopilot_device_upload_not_working/

https://www.reddit.com/r/Intune/comments/1wtxx9t/intune_problems_staging/

[ Voor 22% gewijzigd door YaYo86 op 30-09-2026 10:19 ]

[Quad]

Ik zie voorlopig nog niets hierover in de adminportal bij MS.

[Misterxbee]

ja hier ook problemen

[DennusF]

Gister hadden we hier ook al last van..

[Dirtyrockers]

ook wij lopen ertegenaan dat devices niet willen registreren in autopilot.

[willempjuh]

Quad schreef op woensdag 30 september 2026 @ 12:33:
Ik zie voorlopig nog niets hierover in de adminportal bij MS.

Ik lees net ergens dat ze hebben toegegeven dat er een probleem is, maar ik zie nog niks op de diverse Health portals. Hier wel: Microsoft Intune Status. Check if Microsoft Intune is down or having an outage. | StatusGator

[Blokker_1999]

Wat ben ik blij met deze groep mensen. Men rapporteert hier vanuit 1st line een probleem en ik kom gewoon hier kijken om bevestigd te zien wat ik al vermoed .

[willempjuh]

Microsoft durft het aan om iets te zeggen: Some admins may be unable to register new Windows Autopilot devices or update Autopilot group tags in Microsoft Intune. User impact: Admins may be unable to register new Windows Autopilot devices or update Autopilot group tags in Microsoft Intune. More info: Affected admins may observe that Windows Autopilot group tag updates don't persist after saving, and hardware hash imports remain in an incomplete or processing state indefinitely. As a result, profile assignments that rely on Autopilot group tags may not apply as expected, and registration of new Windows Autopilot devices may fail. Current status: We've identified that requests to update Autopilot group tags are returning successful responses but aren't being applied as expected. We're analyzing service telemetry and recent platform activity to identify the root cause and next steps required to mitigate impact. Scope of impact: Some admins attempting to register new Windows Autopilot devices or update Autopilot group tags in Microsoft Intune may be impacted. Next update by: Wednesday, September 30, 2026, at 3:30 PM UTC

[mentaloscar]

willempjuh schreef op woensdag 30 september 2026 @ 16:03:
Microsoft durft het aan om iets te zeggen: Some admins may be unable to register new Windows Autopilot devices or update Autopilot group tags in Microsoft Intune. User impact: Admins may be unable to register new Windows Autopilot devices or update Autopilot group tags in Microsoft Intune. More info: Affected admins may observe that Windows Autopilot group tag updates don't persist after saving, and hardware hash imports remain in an incomplete or processing state indefinitely. As a result, profile assignments that rely on Autopilot group tags may not apply as expected, and registration of new Windows Autopilot devices may fail. Current status: We've identified that requests to update Autopilot group tags are returning successful responses but aren't being applied as expected. We're analyzing service telemetry and recent platform activity to identify the root cause and next steps required to mitigate impact. Scope of impact: Some admins attempting to register new Windows Autopilot devices or update Autopilot group tags in Microsoft Intune may be impacted. Next update by: Wednesday, September 30, 2026, at 3:30 PM UTC

Heb je toevallig een link? Zou graag een bevestiging zien van MS.

EDIT: al gevonden

in je service health

[willempjuh]

Ik zie net dat het bij sommigen weer werkt.

[Davidas]

Final status: We’ve identified and reverted a change in the Intune service, and telemetry confirms that the service has returned to normal functionality and that customer impact has resolved.

[Blokker_1999]

Ook weer een leuke gehad vandaag. Ben aan het experimenteren met Cloud PKI. Netjes een CA opgezet, policy aangemaakt en aan mezelf gehangen om mee te testen. Ik krijg maar geen certificaat. Terwijl ik wat anders aan het testen ben, en voor het eerst in jaren een non-hybrid machine uitrol, zie ik daar het certificaat onmiddelijk verschijnen 🤦.

We mogen weer gaan zoeken naar de verschillen dus.

[HKLM_]

Blokker_1999 schreef op donderdag 1 oktober 2026 @ 19:33:
Ook weer een leuke gehad vandaag. Ben aan het experimenteren met Cloud PKI. Netjes een CA opgezet, policy aangemaakt en aan mezelf gehangen om mee te testen. Ik krijg maar geen certificaat. Terwijl ik wat anders aan het testen ben, en voor het eerst in jaren een non-hybrid machine uitrol, zie ik daar het certificaat onmiddelijk verschijnen 🤦.

We mogen weer gaan zoeken naar de verschillen dus.

Staat je AzureAdPrt state op yes?

[-ChRiZz-]

Administrator Protection werkte via het configuration profile eindelijk in 25H2, maar werkt niet meer in versie 26H2. Iemand dezelfde ervaring? Wederom geduld hebben?

[Davidas]

-ChRiZz- schreef op donderdag 1 oktober 2026 @ 23:45:
Administrator Protection werkte via het configuration profile eindelijk in 25H2, maar werkt niet meer in versie 26H2. Iemand dezelfde ervaring? Wederom geduld hebben?

Waarom draai je nu al 26H2, mijn advies is om altijd een paar weken te wachten zodat alle kinderziektes eruit zijn.

[Blokker_1999]

Mogelijks een test setup, ik ga ook mijn eerste test machines upgraden deze week om te zien wat er gebeurdt.

[Blokker_1999]

HKLM_ schreef op donderdag 1 oktober 2026 @ 21:15:
[...]

Staat je AzureAdPrt state op yes?

yes

En nu ook geleerd dat hybrid/non-hybrid geen verschil maakt. Heb namelijk 1 actieve non-hybrid die ik al lang thuis gebruik, en die haalt het cert ook niet binnen . There goes that theory.

[HKLM_]

-ChRiZz- schreef op donderdag 1 oktober 2026 @ 23:45:
Administrator Protection werkte via het configuration profile eindelijk in 25H2, maar werkt niet meer in versie 26H2. Iemand dezelfde ervaring? Wederom geduld hebben?

Ik zie heel die optie nog niet eens 😅

[HKLM_]

Blokker_1999 schreef op vrijdag 2 oktober 2026 @ 07:11:
[...]

yes

En nu ook geleerd dat hybrid/non-hybrid geen verschil maakt. Heb namelijk 1 actieve non-hybrid die ik al lang thuis gebruik, en die haalt het cert ook niet binnen . There goes that theory.

Ik heb er een aantal maanden geleden ook mee zitten stoeien en had ook wisselende ervaringen om het werkend te krijgen. Uiteindelijk zat het in het SCEP profiel met de Key storage provider (KSP) settings. Het device of de devices waar je op uitrolt moet de instellingen die je daar mee geeft goed kunnen handelen.

[Davidas]

Blokker_1999 schreef op vrijdag 2 oktober 2026 @ 07:09:
Mogelijks een test setup, ik ga ook mijn eerste test machines upgraden deze week om te zien wat er gebeurdt.

Ja, die snap ik. Mag hopen dat je het nog niet deployed naar al je endpoints in productie. Volgende week ga ik de configuratie binnen Autopatch maken, ergens november eerste uitrol naar fase 1 devices.

[-ChRiZz-]

Ik zag de optie op 25h2 ook niet bij account protection maar moest wel mijn pincode of gezicht scan doen. Ook zie ik nog netjes in c:\users\ADMIN_chris en c:\users\chris van voordat ik de 26h2 upgrade heb uitgevoerd. Idd als test, niet productie. Volledige restart was helaas nog geen : Reboot immer gut ervaring.

[HKLM_]

Voor de hybride users onder ons! Er is een nieuwe CSP: https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#ignorewindowsupdategrouppolicies

“IgnoreWindowsUpdateGroupPolicies”

When enabled, Group Policy settings for Windows Update are ignored and only MDM policy values are applied. This allows MDM-managed devices to bypass conflicting Group Policy configurations.

Er is natuurlijk ook mdmwinsovergpo maar deze is specifiek voor windows updates.

[ Voor 7% gewijzigd door HKLM_ op 02-10-2026 17:23 ]

[-ChRiZz-]

Admin protection werkt (weer) na de de updates van vandaag op 25h2 en 26h2

[HKLM_]

-ChRiZz- schreef op woensdag 14 oktober 2026 @ 15:20:
Admin protection werkt (weer) na de de updates van vandaag op 25h2 en 26h2

https://www.bleepingcomputer.com/news/security/microsoft-recent-windows-updates-may-trigger-remote-desktop-failures/

Microsoft has confirmed that non-admin users may be unable to connect to devices via Remote Desktop after installing recent Windows updates if the "Administrator protection" security feature is enabled.

Ja maar sloopt RDP, dat administrator protection is al defect by design.

[ Voor 22% gewijzigd door HKLM_ op 14-10-2026 16:34 ]

[Hero of Time]

Vandaag eens de moeite genomen om te kijken naar een issue dat een gebruiker sinds augustus heeft. We hadden nog eenzelfde Surface in de kast liggen die de gebruiker heeft. Daar op ingelogd, apparaat op m'n naam gezet in Intune en had net als de gebruiker geen toegang tot Windows Hello opties. Nou had het systeem zelf nog een berg driver/firmware updates en 25H2 om te installeren. Gisteren was het merendeel gedaan, vandaag heeft 't er 3 uur over gedaan om 25H2 te downloaden en installeren, maar dat 'ie nu weer compliant is veranderde er niks aan.

Heb al m'n instellingen langs gelopen, gekeken of er vanuit het domein zelf toch niet stiekem een GPO roet in 't eten gooit, maar niks. De registersleutels die genoemd worden dat mogelijk in de weg kunnen zitten zijn er niet.

Met al het zoekwerk kwam ik nog een blog tegen waar de registersleutel 'AllowDomainPINLogon' wordt genoemd. Die aanmaken geeft direct de opties voor PIN en gezichtsherkenning vrij.

Iemand enig idee waarom dit nodig zou moeten zijn en wat hebben jullie specifiek in Intune ingesteld voor WHfB? Want het enige wat ik kan vinden in de documentatie en Intune zelf is dat als de boel op 'not configured' staat, de gebruiker vrij staat om het wel of niet te gebruiken. Ik wil niet dat gebruikers het direct in hun neus gedrukt krijgen bij het inloggen dat ze het moéten instellen zoals ik bij m'n eerste Entra-only joined test systeem kreeg.

[HKLM_]

Hero of Time schreef op woensdag 14 oktober 2026 @ 19:40:
Vandaag eens de moeite genomen om te kijken naar een issue dat een gebruiker sinds augustus heeft. We hadden nog eenzelfde Surface in de kast liggen die de gebruiker heeft. Daar op ingelogd, apparaat op m'n naam gezet in Intune en had net als de gebruiker geen toegang tot Windows Hello opties. Nou had het systeem zelf nog een berg driver/firmware updates en 25H2 om te installeren. Gisteren was het merendeel gedaan, vandaag heeft 't er 3 uur over gedaan om 25H2 te downloaden en installeren, maar dat 'ie nu weer compliant is veranderde er niks aan.

Heb al m'n instellingen langs gelopen, gekeken of er vanuit het domein zelf toch niet stiekem een GPO roet in 't eten gooit, maar niks. De registersleutels die genoemd worden dat mogelijk in de weg kunnen zitten zijn er niet.

Met al het zoekwerk kwam ik nog een blog tegen waar de registersleutel 'AllowDomainPINLogon' wordt genoemd. Die aanmaken geeft direct de opties voor PIN en gezichtsherkenning vrij.

Iemand enig idee waarom dit nodig zou moeten zijn en wat hebben jullie specifiek in Intune ingesteld voor WHfB? Want het enige wat ik kan vinden in de documentatie en Intune zelf is dat als de boel op 'not configured' staat, de gebruiker vrij staat om het wel of niet te gebruiken. Ik wil niet dat gebruikers het direct in hun neus gedrukt krijgen bij het inloggen dat ze het moéten instellen zoals ik bij m'n eerste Entra-only joined test systeem kreeg.

Ik heb het vorig jaar voor hybride aangemaakt en dat was Cloud Kerberos configureren op de DC, In Intune de CSP en vervolgens de WHFB policy. Getest en uitgerold in de organisatie.

[Hero of Time]

HKLM_ schreef op woensdag 14 oktober 2026 @ 19:48:
[...]

Ik heb het vorig jaar voor hybride aangemaakt en dat was Cloud Kerberos configureren op de DC, In Intune de CSP en vervolgens de WHFB policy. Getest en uitgerold in de organisatie.

Wat bedoel je precies met 'WHfB policy'? Is dat bij Account Protection onder Endpoint Security in Intune of wat anders? Want ik ken ook de Windows Hello optie onder Enrollment, maar dat heeft in principe 3 opties: Uit, in je gezicht geduwd krijgen en ongeconfigureert de gebruiker zelf laten beslissen.

Maar de CSP is dus hoe dan ook nodig als ik je goed begrijp? Ik kon overigens nergens iets vinden over een gewijzigde default, want de gebruiker kon het begin dit jaar nog prima gebruiken, pas in augustus ging het 'stuk' en ik heb niks aangepast in de tussentijd.

[Davidas]

Hero of Time schreef op woensdag 14 oktober 2026 @ 20:25:
[...]

Wat bedoel je precies met 'WHfB policy'? Is dat bij Account Protection onder Endpoint Security in Intune of wat anders? Want ik ken ook de Windows Hello optie onder Enrollment, maar dat heeft in principe 3 opties: Uit, in je gezicht geduwd krijgen en ongeconfigureert de gebruiker zelf laten beslissen.

Maar de CSP is dus hoe dan ook nodig als ik je goed begrijp? Ik kon overigens nergens iets vinden over een gewijzigde default, want de gebruiker kon het begin dit jaar nog prima gebruiken, pas in augustus ging het 'stuk' en ik heb niks aangepast in de tussentijd.

Ja, je configureert het onder Account Protection en laat de configuratie onder Enrollment op not configured staan.

[HKLM_]

Davidas schreef op woensdag 14 oktober 2026 @ 21:03:
[...]

Ja, je configureert het onder Account Protection en laat de configuratie onder Enrollment op not configured staan.

@Hero of Time Dit inderdaad, onder enrollment is een tenant brede setting met eigenlijk on of off, via een CSP heb je a meer settings en b zelf in beheer welke groepen je op de include zet of exclude.

Ik gebruik trouwens niet de Account Protection template voor WHfB maar de settings vanuit de setting catalog met een eigen policy heb ik meer keuze vrijheid en meer opties naar mijn idee.

[ Voor 6% gewijzigd door HKLM_ op 14-10-2026 21:26 ]

[Hero of Time]

Tnx, morgen even kijken dan. Wil zo min mogelijk hoeven te configureren om gebruikers in dit geval de maximale vrijheid/mogelijkheden te geven.

[ Voor 22% gewijzigd door Hero of Time op 14-10-2026 21:48 ]

[Hero of Time]

Vandaag getest. Settings Catalog optie aangezet met eerst 'allow biometrics' en 'require security device' voor TPM2 vereiste. Dat leek niks te doen. Die security device er weer uitgehaald, niks. Daarna 'enable WHfB (device)' aangezet en dit gaf vervolgens het punt wat ik juist niet wil. Bij inloggen kreeg ik gelijk de vraag of gezichtsherkenning te gebruiken (is over te slaan) en daarna was er geen enkele keus meer voor 'Nee, ik wil geen pin of wat dan ook'. Enige optie was 'doorgaan' en dan het venster dat op komt gelijk sluiten, om daarmee 'er ging iets fout' te triggeren waarna je het voor die ene keer kon overslaan (maar alsnog melding op m'n telefoon van de Authenticator).

Dit in je face geforceerd door je strot duwen wil ik helemaal niet. Ik wil alleen maar de gebruikers de mogelijkheid geven het in te stellen. Er is al genoeg shit dat je het gevoel geeft een geweer op je hoofd te hebben en wat er op je scherm staat maar moet accepteren.

Als Intune echt geen mogelijkheid heeft dit vriendelijker aan te bieden, maak ik desnoods maar uit narigheid een GPO aan waar ik de registry key 'AllowDomainPINLogon' aanmaak in HKLM:\Software\Policies\Windows\System. Het dreigende "je organisatie eist..." gaat gegarandeerd weerstand geven of op z'n minst vragen.

[HKLM_]

Hero of Time schreef op donderdag 15 oktober 2026 @ 20:25:
Vandaag getest. Settings Catalog optie aangezet met eerst 'allow biometrics' en 'require security device' voor TPM2 vereiste. Dat leek niks te doen. Die security device er weer uitgehaald, niks. Daarna 'enable WHfB (device)' aangezet en dit gaf vervolgens het punt wat ik juist niet wil. Bij inloggen kreeg ik gelijk de vraag of gezichtsherkenning te gebruiken (is over te slaan) en daarna was er geen enkele keus meer voor 'Nee, ik wil geen pin of wat dan ook'. Enige optie was 'doorgaan' en dan het venster dat op komt gelijk sluiten, om daarmee 'er ging iets fout' te triggeren waarna je het voor die ene keer kon overslaan (maar alsnog melding op m'n telefoon van de Authenticator).

Dit in je face geforceerd door je strot duwen wil ik helemaal niet. Ik wil alleen maar de gebruikers de mogelijkheid geven het in te stellen. Er is al genoeg shit dat je het gevoel geeft een geweer op je hoofd te hebben en wat er op je scherm staat maar moet accepteren.

Als Intune echt geen mogelijkheid heeft dit vriendelijker aan te bieden, maak ik desnoods maar uit narigheid een GPO aan waar ik de registry key 'AllowDomainPINLogon' aanmaak in HKLM:\Software\Policies\Windows\System. Het dreigende "je organisatie eist..." gaat gegarandeerd weerstand geven of op z'n minst vragen.

Begrijp ik uit je verhaal dat je in de sign-in het WHfB setup scherm niet weer wilt geven? Maar dat het alleen kan via de settings in Windows?

zo ja? Dan zoek ik de policy even voor je op 🙂

[Hero of Time]

HKLM_ schreef op donderdag 15 oktober 2026 @ 20:29:
[...]

Begrijp ik uit je verhaal dat je in de sign-in het WHfB setup scherm niet weer wilt geven? Maar dat het alleen kan via de settings in Windows?

zo ja? Dan zoek ik de policy even voor je op 🙂

Graag. Het moet voor de gebruiker vriendelijk en optioneel zijn. Men kon dat blijkbaar ooit, maar iets weerhoud dat nu en ik heb geen flauw idee wat. Maar met de reg key die ik net noemde wordt het weer beschikbaar zonder te forceren.

[HKLM_]

Hero of Time schreef op donderdag 15 oktober 2026 @ 20:31:
[...]

Graag. Het moet voor de gebruiker vriendelijk en optioneel zijn. Men kon dat blijkbaar ooit, maar iets weerhoud dat nu en ik heb geen flauw idee wat. Maar met de reg key die ik net noemde wordt het weer beschikbaar zonder te forceren.

Je kan dat doen met de Disable Post Logon Provisioning CSP via een OMA-URI

Name: DisablePostLogonProvisioning

OMA-URI ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning

Type: Boolean en dan waarde op true.

ik zit op mijn mobiel sorry voor de opmaak, maar met deze custom oma-uri zet je de post logon provision screens van whfb uit en blijft het beschikbaar in de settings van windows.

Wel even je eigen tenant id invullen!

[ Voor 3% gewijzigd door HKLM_ op 15-10-2026 20:37 ]

[Hero of Time]

Die OMA-URI staat ook in de MS documentatie. Net als iets voor het aanzetten er van dacht ik (pagina's heb ik op m'n werklaptop ergens open).

Ben nog steeds wel benieuwd wat de reden is waarom het opeens niet beschikbaar is. Een specifieke update voor Windows is het niet, want de test Surface had al geen updates sinds begin dit jaar en pas halverwege ging het stuk. Dus moet iets bij online zijn. Wat dus ook zo frustrerend is, opeens verandert er gedrag en er is niks dat aangeeft waarom. Eventlog moet ik nog wel raadplegen, maar 'policyenabled: NO' staat er iig bij 'dsregcmd /status', wat mij dus doet vermoeden dat het online beleid is verandert zonder ook maar een woord erover.

[HKLM_]

Hero of Time schreef op donderdag 15 oktober 2026 @ 20:45:
Die OMA-URI staat ook in de MS documentatie. Net als iets voor het aanzetten er van dacht ik (pagina's heb ik op m'n werklaptop ergens open).

Ben nog steeds wel benieuwd wat de reden is waarom het opeens niet beschikbaar is. Een specifieke update voor Windows is het niet, want de test Surface had al geen updates sinds begin dit jaar en pas halverwege ging het stuk. Dus moet iets bij online zijn. Wat dus ook zo frustrerend is, opeens verandert er gedrag en er is niks dat aangeeft waarom. Eventlog moet ik nog wel raadplegen, maar 'policyenabled: NO' staat er iig bij 'dsregcmd /status', wat mij dus doet vermoeden dat het online beleid is verandert zonder ook maar een woord erover.

Wat je beschrijft heb ik ook gezien bedenk ik me nu bij mijn implementatie bij een paar laptops. Dat policyenabled op no stond… moet even heel heel diep graven haha

[grimson]

Wat betreft Windows Hello for Business (via Intune);

Devices | Enrollment | Windows Hello for Business
Deze instellingen worden alleen toegepast tijdens het onboarden.

• WHfB - enabled -> 'tattoo' in registry met Intune instellingen en 'UsePassportForWork' aan.
• WHfB - disabled -> 'tattoo' in registry ook met Intune instellingen maar 'UsePassportForWork' uit. WHfB instellingen worden dus wel toegepast maar WHfB zelf blijft dus uit.
• WHfB - not configured -> Windows defaults wat betekend WHfB aan zonder WHfB instellingen/settings aanpassingen vanuit deze onboarding settings.

Dus als je deze WHfB instellingen hier aanpast als 'tenant wide' zal op een een bestaand device deze niet worden gewijzigd. Nogmaals gelden deze instellingen alleen tijdens het onboarden en worden al dan niet naar keuze in het register (zichtbaar) 'getattoeerd' onder HKLM\SOFTWARE\Microsoft\Policies\PassportForWork. Ook al kies je dus hier voor disabled zullen de instellingen bij disabled alnog worden toegepast op het device. Vandaar dat je ook de WHfB instellingen hier ziet bij de keuze disabled, die worden dus alsnog toegepast.

Dus staat eenmaal WHfB op 'disabled' via bijvoorbeeld dus deviceenrollment dan staat deze instelling 'getattoeerd' in Windows en moet je zelf weer activeren. Hierdoor kan je dus WHfB niet handmatig aanzetten op deze devices omdat de getattoeerde policy dit verhinderd.

WHfB inschakelen via Device config policies;

Maar als je WHfB weer inschakeld dan komt er dus weer een verplichte prompt die misschien ongewenst is tijdens het selectief mogelijk maken van WHfB.
Welnu is er inderdaad daarvoor deze eerder aangegeven instelling 'DisablePostLogonProvisioning' welke voorkomt de automatische WHfB registratie als je WHfB inschakeld op een device. Let wel dat je ook 'UsePassportForWork' moet aanzetten en 'DisablePostLogonProvisioning' alleen niet voldoende is. Zoue je alleen 'DisablePostLogonProvisioning' activeren dan kan je alsnog WHfB niet aanzetten op het device. 'DisablePostLogonProvisioning' onderdrukt zegmaar de verplichte registratie bij 'UsePassportForWork' en beide moet je dus aanzetten :)

Heb je beide policies actief op een device dan kan je handmatig WHfB aanzetten zonder verplichte WHfB registratieprompt, yay!

Ik heb wel gezien bij devices die geschikt zijn voor WHfB faceid die dan een éénmalig niet verplichte 'toast melding' rechtsonderin krijgen om misschien dit te activeren. Maar niet op andere devices die bijv. geschikt zijn voor vingerafruk en of alleen pin.

Zover ik kan nagaan kan je WHfB instellen via Device config policies of misschieb bij voorkeur Endpoint security | Account protection maar beide opties hebben geen GUI schuifje voor 'DisablePostLogonProvisioning' wat weer jammer is dat je dan eigenlijk op 3 plaatsen een WHfB policy kan/moet aanmaken dus, device config, Custom OMA-URI en bij Endpoint security.

Zelf heb ik dan gekozen om WHfB via een Custom OMA-URI aan te zetten:

• ./Device/Vendor/MSFT/PassportForWork/TENANTID/Policies/DisablePostLogonProvisioning
• ./Device/Vendor/MSFT/PassportForWork/TENANTID/Policies/UsePassportForWork
• ./Device/Vendor/MSFT/PassportForWork/TENANTID/Policies/UseCloudTrustForOnPremAuth

In een andere policy dan zichtbaar via een GUI de WHfB instellingen zelf zoals pinlengte enzo.
Dit om een beetje zichtbaarheid van de instellingen te tonen, maar het activeren zelf kan dan 'onzichtbaar' :)

Dit kostte mij wat tijd om helder te krijgen en zover ik begrijp is dit de werking van Intune en WHfB.
Ik hoor graag correcties en of eventueel vragen, misschien kan ik wat beantwoorden.

oja, ik werk voor een MSP en zie het liefst overal Windows Hello for Business inclusief de tenant passkey in deze container actief maar helaas .... niet overal wil men er nog aan maar ik blijf pushen

[ Voor 25% gewijzigd door grimson op 17-10-2026 11:03 ]

[Hero of Time]

Dank. Het 'grappige' is dat "HKLM\SOFTWARE\Microsoft\Policies\PassportForWork" bij ons niet eens bestaat met onze huidige config. Pas als ik ook maar iets aanzet in de Settings Catalog voor WHfB, zoals 'use biometrics' wordt de sleutel gemaakt.

Ik ga die drie OMA-URI dingen van je gebruiken. Dat het op 3 plekken kan met verschillende opties en resultaten is weer typisch MS. Te veel fragmentatie en geen fatsoenlijke communicatie tussen de teams. En voor beheerders is het overzicht compleet naar de klote.

[grimson]

Hero of Time schreef op zaterdag 17 oktober 2026 @ 12:09:
Dank. Het 'grappige' is dat "HKLM\SOFTWARE\Microsoft\Policies\PassportForWork" bij ons niet eens bestaat met onze huidige config. Pas als ik ook maar iets aanzet in de Settings Catalog voor WHfB, zoals 'use biometrics' wordt de sleutel gemaakt.

Interessant, ik ben benieuwd of deze machines via Autopilot/IntuneMDM zijn onboarded?
Geen policy hier op het device zou in principe betekenen dat WHfB by default aan staat (op het Windows device) en men een verplichte WHfB registratie krijgt (EntraID join iig).

In principe had ik iets verwacht want AutoPilot/MDM onboarding hier altijd wat plaatsen mits expliciet gekozen voor bij onboarden:

Intune | Devices | Enrollment | Windows Hello for Business

• Configure Windows Hello for Business: Disabled
• Use security keys for sign-in: Disabled

Ik heb nog wat testjes gedaan, betreft dus het initiële onboarden van,elke keer, een verse Windows 26H2 en-US installatie via AutoPilot -> EntraID joined (Windows Autopilot device preparation met Device Association). Hiervoor gebruik ik een autounattended.xml op een usb stick die vanaf boot opstart naar OOBE welke ik met een FIDO2 sleutel laat aanmelden.

Daarbij de instellingen van WHfB ingesteld bij Intune | Devices | Enrollment | Windows Hello for Business;

Test 1:

Intune | Devices | Enrollment | Windows Hello:
- Configure Windows Hello for Business: Not configured
- Use security keys for sign-in: Not configured

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies]

Resultaat is dat tijdens het onboarden geen WHfB instellingen vanuit Intune worden toegepast tijdens het onboarden. Aangezien Windows zelf WHfB als default aan heeft staan dan is het resutlaat dat WHfB actief is.

Test2:

Intune | Devices | Enrollment | Windows Hello:
- Configure Windows Hello for Business: Not configured
- Use security keys for sign-in: Enabled

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey]
"UseSecurityKeyForSignin"=dword:00000001

Alleen het aanmelden bij Windows met een FIDO2 security key wordt nu mogelijk gemaakt alleen lijkt dit een instelling gezien ik dan bij het aanmeld scherm kan kiezen voor een FIDO2 sleutel naast user/password maar dit lijkt niet te werken. Vermoedelijk is het een aanvulling op als je WHfB geconfigureerd hebt als user dat deze optie dan ook mogelijk wordt maar niet getest. Alleen voor de test is het mooi zichtbaar welke policy waar terecht komt. WHfB zelf is nog steeds, zoals verwacht, not configured.

Test3:

Intune | Devices | Enrollment | Windows Hello:
- Configure Windows Hello for Business: Disabled
- Use security keys for sign-in: Enabled

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\Biometrics]
"UseBiometrics"=dword:00000001
"FacialFeaturesUseEnhancedAntiSpoofing"=dword:00000001
"EnableESSwithSupportedPeripherals"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\JOUWTENANTID>\Device\Policies]
"UsePassportForWork"=dword:00000000
"RequireSecurityDevice"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\JOUWTENANTID>\Device\Policies\PINComplexity]
"MinimumPINLength"=dword:00000006
"MaximumPINLength"=dword:0000007f
"UppercaseLetters"=dword:00000002
"LowercaseLetters"=dword:00000002
"SpecialCharacters"=dword:00000002
"History"=dword:00000000
"Expiration"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\JOUWTENANTID>\Device\Policies\Remote]
"UseRemotePassport"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey]
"UseSecurityKeyForSignin"=dword:00000001

Interessant is dus dat als je 'disabled' kies wat resulteert in 'UsePassportForWork"=dword:00000000' als policy maar ook de complete instellingen die opgegeven zijn meekomen!. En ook al staat WHfB uit de instellingen zijn getattoeerd in het register .

Test4:

Intune | Devices | Enrollment | Windows Hello:
- Configure Windows Hello for Business: Enabled
- Use security keys for sign-in: Enabled

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\Biometrics]
"UseBiometrics"=dword:00000001
"FacialFeaturesUseEnhancedAntiSpoofing"=dword:00000001
"EnableESSwithSupportedPeripherals"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\JOUWTENANTID>\Device\Policies]
"UsePassportForWork"=dword:00000001
"RequireSecurityDevice"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\JOUWTENANTID>\Device\Policies\PINComplexity]
"MinimumPINLength"=dword:00000006
"MaximumPINLength"=dword:0000007f
"UppercaseLetters"=dword:00000002
"LowercaseLetters"=dword:00000002
"SpecialCharacters"=dword:00000002
"History"=dword:00000000
"Expiration"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\JOUWTENANTID>\Device\Policies\Remote]
"UseRemotePassport"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey]
"UseSecurityKeyForSignin"=dword:00000001

'Enabled' resulteert in 'UsePassportForWork"=dword:00000001' als policy maar ook de verwachte opgegeven instellingen.
Met deze instellingen wordt WHfB eigenlijk expliciet aangezet bij het onboarden (eenmalig) maar blijft dus behouden omdat het 'getattood' is als een policy.

Kortom:
- WHfB instellingen bij Intune | Devices | Enrollment | Windows Hello for Business worden altijd toegepast indien 'enabled maar ook met name 'disabled'. 'Not configured' is de enige instelling die daadwerkelijk niets plaats.

Misschien als tip laat bovenstaande dus zien; omdat dus vaak instellingen al via de onboarding worden toegepast zou ik een device config policy aanmaken die alle WHfB instellingen expliciet instelt om zo eventuele instellingen die bij het onboarden er al staan ondanks 'disabled' te overschrijven met de gewenste instellingen. Zo lijkt mij dat er dan consistente WHfB instellingen behaald worden.

En uit mijn hoofd, alle instellingen zijn <device> WHfB instellingen. indien per user komt er volgens mij de SID (net als de tenant id zegmaar) van de user(s) ook hier te staan in deze policy tree / op deze plaats met een user WHfB policy. Maar persoonlijk houd ik het bij per device voor WHFB.

[Hero of Time]

@grimson, ik heb bij onboarding niks ingesteld staan, zoals jouw test met 'not configured'. Dat is ook het beste IMO, tenzij je echt dingen wilt afdwingen ipv aan de gebruiker over wilt laten. Een hoop systemen zijn later onboard, maar deze Surface zijn via OOBE uitgerold door handmatig de hash te uploaden.

Onze systemen zijn overigens hybrid joined. Ik heb 1x een systeem entra-only gedaan en kreeg zonder ook maar enige instelling van Intune of anders de WHfB setup voor m'n neus bij de eerste login. Kon niks anders doen dan de stappen doorlopen. Zeer slechte gebruikerservaring voor de meeste situaties.
Mochten we ooit naar Entra only gaan, is dit iets wat ik direct uitzet op elke mogelijke plek beschikbaar.

In de MS documentatie staat trouwens ook wat het exact doet bij de instellingen 'enabled', 'disabled' en 'not configured', precies wat jij hier toont.

[grimson]

Hero of Time schreef op zondag 18 oktober 2026 @ 17:22:
Ik heb 1x een systeem entra-only gedaan en kreeg zonder ook maar enige instelling van Intune of anders de WHfB setup voor m'n neus bij de eerste login. Kon niks anders doen dan de stappen doorlopen. Zeer slechte gebruikerservaring voor de meeste situaties.

Ja dit is, zoals bekend neem ik aan, inderdaad de standaard voor een Windows endpoint. Indien niets geconfigureerd dan hoppa WHfB prompt in je gezicht.

Mochten we ooit naar Entra only gaan, is dit iets wat ik direct uitzet op elke mogelijke plek beschikbaar.

Ja, ik zou dus inderdaad goed kijken wat je bij de onboarding dus activeert. Disabled betekend dus uit bij onboarding via AutoPilot/MDM maar ook dat je tevens al die instellingen dus al plaatst. Not configured activeert ook WHfB .
Het is ook mogelijk misschien met een device config policy maar ik dacht dat deze 'te laat' actief wordt op het device waardoor dus deze instellingen niet worden toegepast bij aanmelden en dus je alsnog een WHfB prompt krijgt als user. Als je het buiten/voor de onboarding misschien wilt instellen is dan een handmatige registry entry (UsePassportForWork=0) voor nodig te plaatsen in je Windows installatie. Hopelijk snel naar EntraID only?

[grimson]

Eigenlijk op /r/intune geplaatst maar misschien hier iemand dit dit ook eventueel heeft gezien?
Ik vermoed dat het 'by design' is maar helaas kan dus een ZDP patch tijdens OOBE, zover naar mijn testen, een passwordless onboarding verstoren omdat er een extra reboot plaatsvind.

--

KB5128942: Out of Box Experience cumulatieve update voor Windows ‘breekt’ passwordless onboarding (?) Autopilot

Ik hoop dat iemand mijn bevindingen kan bevestigen.

Normaal gesproken kan ik een passwordless onboarding uitvoeren met:

• OOBE
• Inloggen met TAP
• WHfB‑registratie met TAP
• =Passwordless onboarded

Maar het lijkt erop dat deze (gedocumenteerde) ZDP‑patch een verplichte installatie is na OOBE, en dat er een herstart nodig is voordat de gebruiker zich kan registreren voor WHfB. Deze herstart toont echter nu een gebruikersnaam‑ en wachtwoordprompt voordat de gebruiker verder kan gaan met de WHfB‑registratie.

Ik gebruik de september Windows 26H2 en‑US ISO als basisinstallatie. Tijdens het inloggen zie ik al dat ‘KB5128942’ geïnstalleerd is, wat bevestigt dat deze ZDP‑patch inderdaad is toegepast.

Kort gezegd: deze verplichte update lijkt de passwordless onboarding te ‘breken’, omdat de extra herstart voorkomt dat de gebruiker zich direct kan registreren voor WHfB — waardoor een gebruikersnaam en wachtwoord moeten worden ingevoerd na de herstart, voordat WHfB kan worden geregistreerd.

[Quad]

Voor passwordless stel ik altijd websign-in in.

[grimson]

Quad schreef op zondag 18 oktober 2026 @ 18:49:
Voor passwordless stel ik altijd websign-in in.

Goed idee, misschien hier eens naar kijken. Als deze ZDP patch weer geintegreerd is in de installatie media en of installatie dan is het weer 'opgelost' maar bij een volgende ZDP OOBE patch kan het weer 'raak' zijn.

[Blokker_1999]

Omdat het mijn laatste weken zijn in mijn huidige team bij de huidige werkgever wil ik een project afwerken waar het ooit allemaal mee begonnen is. Non-hybrid joined Windows 11 in de organisatie.

Maar man, wat is het een feest. De radius voor onze wifi is NPS en die filterde om legacy redenen op domain computers. Dus dat ging al niet. Die heb ik nu aangepast dat ook user certificaten aanvaard worden. Dat betekend dan wel weer dat je voor je eerste log-in met een andere wifi moet verbinden want je computer, die niet in het domein zit, zal nooit vertrouwd geraken. Maar die verdomde captive portal op ons guest netwerk zit in de weg. Netwerk mannen zullen dus alsnog een oplossing moeten zoeken.

Ga je door heel de setup, besluit je op een gegeven moment WHfB eens uit te proberen. Die roll-out begint company wide over een week of 2 dus dat zou vlot moeten gaan. Niet dus. Vergeten dat ik die policy op een usergroep gescoped had ipv device group. Vraagt die ineens om een 15 karakter PIN omdat het user scoped profiel nog niet goed staat. Los je dat ook weer even op -> scoping op devices ipv users aub.

Na een zoveelste redeploy begin je met het aanpassen van de documentatie die we hebben. Ah wacht, nu moet ik beginnen met documenteren hoe een nieuwe gebruiker in de firma gaat onboarden. Even test account afstoffen, MFA verwijderen, vinkje aanzetten voor wachtwoordreset en ... zucht. In de OOBE een vraag voor wachtwoordreset waarna het Entra token automatisch vervalt en de OOBE komt vastzitten .

Documentatie nalezen: ah ja, best een TAP gebruiken. Maar dat gaat niet zomaar. Onze TAPs zijn specifiek opgezet voor eenmalig gebruik, en dan hebben we er ineens tijdens de onboarding 2 nodig, want anders komen onze nieuwe collega's vast te zitten wanneer ze hun smartphone opzetten. Want daar gaan ze anders in een catch-22 terechtkomen. Aanmelden op MDM vereist MFA, maar MFA is nog niet opgezet want ze moeten eerst hun smartphone opgezet krijgen. En dan heb ik inderdaad nog niet aan de WHfB setup gedacht die ook nog eens een bijkomende authenticatie vereist.

Dus zullen we al maar weer aan het identity team vragen of we het gebruik van TAP mogen aanpassen. Oh ... wacht ... dat is mijn nieuwe functie ... .

[bramassendorp]

Blokker_1999 schreef op dinsdag 20 oktober 2026 @ 19:20:
Omdat het mijn laatste weken zijn in mijn huidige team bij de huidige werkgever wil ik een project afwerken waar het ooit allemaal mee begonnen is. Non-hybrid joined Windows 11 in de organisatie.

Maar man, wat is het een feest. De radius voor onze wifi is NPS en die filterde om legacy redenen op domain computers. Dus dat ging al niet. Die heb ik nu aangepast dat ook user certificaten aanvaard worden. Dat betekend dan wel weer dat je voor je eerste log-in met een andere wifi moet verbinden want je computer, die niet in het domein zit, zal nooit vertrouwd geraken. Maar die verdomde captive portal op ons guest netwerk zit in de weg. Netwerk mannen zullen dus alsnog een oplossing moeten zoeken.

Ga je door heel de setup, besluit je op een gegeven moment WHfB eens uit te proberen. Die roll-out begint company wide over een week of 2 dus dat zou vlot moeten gaan. Niet dus. Vergeten dat ik die policy op een usergroep gescoped had ipv device group. Vraagt die ineens om een 15 karakter PIN omdat het user scoped profiel nog niet goed staat. Los je dat ook weer even op -> scoping op devices ipv users aub.

Na een zoveelste redeploy begin je met het aanpassen van de documentatie die we hebben. Ah wacht, nu moet ik beginnen met documenteren hoe een nieuwe gebruiker in de firma gaat onboarden. Even test account afstoffen, MFA verwijderen, vinkje aanzetten voor wachtwoordreset en ... zucht. In de OOBE een vraag voor wachtwoordreset waarna het Entra token automatisch vervalt en de OOBE komt vastzitten .

Documentatie nalezen: ah ja, best een TAP gebruiken. Maar dat gaat niet zomaar. Onze TAPs zijn specifiek opgezet voor eenmalig gebruik, en dan hebben we er ineens tijdens de onboarding 2 nodig, want anders komen onze nieuwe collega's vast te zitten wanneer ze hun smartphone opzetten. Want daar gaan ze anders in een catch-22 terechtkomen. Aanmelden op MDM vereist MFA, maar MFA is nog niet opgezet want ze moeten eerst hun smartphone opgezet krijgen. En dan heb ik inderdaad nog niet aan de WHfB setup gedacht die ook nog eens een bijkomende authenticatie vereist.

Dus zullen we al maar weer aan het identity team vragen of we het gebruik van TAP mogen aanpassen. Oh ... wacht ... dat is mijn nieuwe functie ... .

En ipv radius reject een internet only vlan of een internet only acl droppen?

[Hero of Time]

bramassendorp schreef op dinsdag 20 oktober 2026 @ 20:23:
[...]

En ipv radius reject een internet only vlan of een internet only acl droppen?

Dat is wat lastig, want authenticatie op wifi mislukt door ontbreken geldig certificaat (die is er immers nog niet). Je kan pas naar een VLAN gegooid worden als de handshake/authenticatie met het access-point slaagt.

[Blokker_1999]

bramassendorp schreef op dinsdag 20 oktober 2026 @ 20:23:
[...]

En ipv radius reject een internet only vlan of een internet only acl droppen?

Als we die optie hadden, dan hadden we dat ook al lang gedaan. Het probleem met de radius heb ik in 2022, toen ik heel het endpoint management werd ingegooid en begon aan het avontuur om Win10 naar Win11 om te zetten, met een focus op Intune management en Autopilot, reeds aangekaard. Dit probleem is sinds die periode al gekend en uiteindelijk naar de achtergrond verhuisd omdat er ineens maanden later beslist werd om toch hybrid join te doen en het cert dus gewoon via een GPO kon binnenkomen voor het apparaat.

Vandaag, jaren later, staat dat nog altijd geparkeerd. We hebben daarnaast ook nog eens andere wifi problemen. Het management platform is verouderd en zou vervangen moeten worden, maar niemand durft knopen doorhakken. Laat staan dat iemand om budget durft vragen om alles te moderniseren, ondanks dat we in de budgeteringsperiode zitten.

Moedeloos wordt een mens er van. En dan krijg je als antwoord: ja, dan moet je het maar mis laten gaan. Laat het maar blokkeren, dan luisteren ze misschien eens.



Maar wat is dat nu voor oplossing? Dat gaat toch niemand aanvaarden? Dus ik zal maar weer zelf de nodige oplossingen verzinnen en voordragen. Stelde de vraag of ons platform in staat was om op onze guest wifi, voor de authenticatie op de captive portal alsnog de nodige URLs toe te staan. Zelfs daar kon geen antwoord op gegeven worden of dat dit kon met het huidige systeem.

Enige voordeel, het netwerk met verborgen SSID zullen we kunnen aanpassen van VLAN. Moet niet langer kunnen communiceren met de domain controllers als we eenmaal begonnen zijn, maar enkel nog met het internet.

[Blokker_1999]

Hero of Time schreef op dinsdag 20 oktober 2026 @ 20:42:
[...]

Dat is wat lastig, want authenticatie op wifi mislukt door ontbreken geldig certificaat (die is er immers nog niet). Je kan pas naar een VLAN gegooid worden als de handshake/authenticatie met het access-point slaagt.

Van wat ik begrijp zouden beide mogelijk moeten zijn: geldige authenticatie ga je naar de ene VLAN, ongeldige wordt je op een andere VLAN gezet. De meeste platformen zouden dit moeten ondersteunen. Deden we meer dan 10 jaar terug al bij een oude werkgever, maar dan wel op het wired netwerk daar.

[Hero of Time]

Blokker_1999 schreef op dinsdag 20 oktober 2026 @ 20:49:
[...]

Van wat ik begrijp zouden beide mogelijk moeten zijn: geldige authenticatie ga je naar de ene VLAN, ongeldige wordt je op een andere VLAN gezet. De meeste platformen zouden dit moeten ondersteunen. Deden we meer dan 10 jaar terug al bij een oude werkgever, maar dan wel op het wired netwerk daar.

Dat is bedraad, dan heb je al een link. Voor wifi moet je authenticeren met de methode die het AP voor het SSID heeft. Lukt dat niet, dan heb je geen link. Geen link == geen mogelijkheid voor VLAN toewijzen. Want hoe ga je het verschil maken tussen een apparaat dat nog niet het juiste certificaat/PSK heeft voor het SSID vs een rogue client die narigheid wil uitvoeren? Je kan niet zomaar alles accepteren op je SSID, dan zet je in feite de beveiliging op 'open', aka, geen controle. Daar heb je in principe je netwerk met captive portal voor.

[HKLM_]

Blokker_1999 schreef op dinsdag 20 oktober 2026 @ 19:20:
Omdat het mijn laatste weken zijn in mijn huidige team bij de huidige werkgever wil ik een project afwerken waar het ooit allemaal mee begonnen is. Non-hybrid joined Windows 11 in de organisatie.

Maar man, wat is het een feest. De radius voor onze wifi is NPS en die filterde om legacy redenen op domain computers. Dus dat ging al niet. Die heb ik nu aangepast dat ook user certificaten aanvaard worden. Dat betekend dan wel weer dat je voor je eerste log-in met een andere wifi moet verbinden want je computer, die niet in het domein zit, zal nooit vertrouwd geraken. Maar die verdomde captive portal op ons guest netwerk zit in de weg. Netwerk mannen zullen dus alsnog een oplossing moeten zoeken.

Ga je door heel de setup, besluit je op een gegeven moment WHfB eens uit te proberen. Die roll-out begint company wide over een week of 2 dus dat zou vlot moeten gaan. Niet dus. Vergeten dat ik die policy op een usergroep gescoped had ipv device group. Vraagt die ineens om een 15 karakter PIN omdat het user scoped profiel nog niet goed staat. Los je dat ook weer even op -> scoping op devices ipv users aub.

Na een zoveelste redeploy begin je met het aanpassen van de documentatie die we hebben. Ah wacht, nu moet ik beginnen met documenteren hoe een nieuwe gebruiker in de firma gaat onboarden. Even test account afstoffen, MFA verwijderen, vinkje aanzetten voor wachtwoordreset en ... zucht. In de OOBE een vraag voor wachtwoordreset waarna het Entra token automatisch vervalt en de OOBE komt vastzitten .

Documentatie nalezen: ah ja, best een TAP gebruiken. Maar dat gaat niet zomaar. Onze TAPs zijn specifiek opgezet voor eenmalig gebruik, en dan hebben we er ineens tijdens de onboarding 2 nodig, want anders komen onze nieuwe collega's vast te zitten wanneer ze hun smartphone opzetten. Want daar gaan ze anders in een catch-22 terechtkomen. Aanmelden op MDM vereist MFA, maar MFA is nog niet opgezet want ze moeten eerst hun smartphone opgezet krijgen. En dan heb ik inderdaad nog niet aan de WHfB setup gedacht die ook nog eens een bijkomende authenticatie vereist.

Dus zullen we al maar weer aan het identity team vragen of we het gebruik van TAP mogen aanpassen. Oh ... wacht ... dat is mijn nieuwe functie ... .

Klinkt als een normale werkdag voor mij 😜

[Blokker_1999]

Quad schreef op zondag 18 oktober 2026 @ 18:49:
Voor passwordless stel ik altijd websign-in in.

Die is wel mooi, deze week voor de eerste keer gebruikt. Zelfs in een omgeving die niet passwordless is. Combineer dat met de aankomende manier om wachtwoorden te resetten in het online portaal (zou voor eind November overal actief moeten zijn), en je helpdesk moet eigenlijk nooit nog een wachtwoord kennen of resetten. Ook niet voor de onboarding van nieuwe gebruikers. TAP all the way.

[ Voor 4% gewijzigd door Blokker_1999 op 22-10-2026 11:01 ]

[grimson]

Ik had hier laatst een ervarings post gemaakt over een onverwachte reboot na OOBE waardoor je met username en password moet aanmelden omdat deze reboot voor het registreren van WHfB zat. Ik dacht aan de OOBE zero patch van MS maar dit is niet geheel juist.

Autopilot Monitor deze tool van een bekende MVP (lees betrouwbaar) liet dit mooi zien en laat eigenlijk enorm veel zien wat er tijdens het onboarden gebeurt. Ja je kan dit misschien allemaal zelf uit de logs halen uiteraard maar mocht je durven (hier in een test omgeving) ziet het er echt goed uit. Ik doel dan op ook dat je een mooi inzicht krijgt in eventuele verbeteringen of anderzijds dus wat een reboot veroorzaakt.

Stukje van het monitoring gedeelte:

This session rebooted during enrollment, and Windows flagged one or more device-assigned MDM policies as reboot-required — the classic cause of the coalesced mid-ESP restart and the unexpected second sign-in screen before AccountSetup.

First reboot-forcing policy URI: ./Device/Vendor/MSFT/Policy/Config/DmaGuard/DeviceEnumerationPolicy

The complete URI list is in the mdm_policy_reboot_required timeline event (rebootUris). Policies applied DURING ESP DeviceSetup are coalesced into one forced restart at the end of DeviceSetup; the same flags raised later (e.g. user-policy sync in AccountSetup) have no immediate effect — this advisory only fires when a reboot was actually observed.

This is expected OS behavior, not a failure — but it degrades the enrollment experience, confuses users, and is invisible in the Intune console.

Een van de community tools die ik de moeite waard vind om hier te delen.