Microsoft Intune ervaringentopic

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