This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(172.8, 84%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EG%3C/text%3E%3C/svg%3E)
Okey, so I learned that a reboot triggered during the device section in ESP when enrolling a new Windows client in Intune, causes the need for the user to authenticate with their password to continue the process. ( https://learn.microsoft.com/en-us/answers/questions/960560/temporary-access-pass-hello-for-business-setup-sti.html?childToView=1095807#comment-1095807)
When testing Windows Autopatch, we get a reboot during ESP.
From the eventlog; microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin
The following URI has triggered a reboot: (./Device/Vendor/MSFT/Policy/Config/Update/ManagePreviewBuilds).
Lo and behold; removing the device from the group created by the Autopatch Update ring profile, remedies the issue. No reboot, no password needed to complete (Win10 v 22H2 used).
Is there something to be done with this? Since MS is promoting passwordless, are they aware of the conflict that arises when other stuff breaks this because of reboots that it can't handle?
@Jason Sandys This is related to the same issue you helped with in the link...If you want to pass it down the line. Don't know if there is workarounds for this yet, but our solution is to not use autopatch (as I understand it automagically adds devices to the groups that causes this)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 72%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBB%3C/text%3E%3C/svg%3E)
Ugh.. thanks for posting this, I just started running into the same issue and was beginning to pull my hair out. Can confirm removing the device from the Autopatch group allows ESP to complete without a reboot in the middle.
@Jason Sandys @Aria Carley do either of you have any insight into what's going on here? I feel like we should be able to have an existing device go through ESP without having to de-register it or take other drastic actions like @Rudy Ooms has had to document.
Autopatch brings lot of new config profiles to Intune. Can it be that there is WHFB enablement through it? That's why you didnt experience this behavior before.
we already got WhfB enabled (and it doesnt force a reboot during ESP) that's the whole point of going passwordless, to be able to get to the point where the user set up a PIN/Bio/Face ID.
Sounds like the WUFB issue targetted at devices when windows 11 saw the first light :)
[https://call4cloud.nl/2022/04/dont-be-a-menace-to-autopilot-while-configuring-your-wufb-in-the-hood/
As autopatch also uses wufb... I am not surprised this issue is back
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(32, 51%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESJ%3C/text%3E%3C/svg%3E)
As a workaround you can enable web sign-in as described by @Peter van der Woude
https://www.petervanderwoude.nl/post/enabling-web-sign-in-to-windows-for-usage-with-temporary-access-pass/
Like this you can sing in with TAP after the reboot to proceed with ESP user part.
yes, got this enabled. But then we have to outstead TAPs for every PC reset. Its is not a viable solution. I haven't tested if this is still a problem with autopatch, since it has been a while and using regular update model is working fine for us.