Event banner
Event details
Autopilot Pre-prov and Web Sign-in not working
Has anyone else encountered a problem or have success with setting up Web Sign-in with Autopilot Pre-provision where it doesn't appear as an option on the first Windows logon? I'm trying to get this to work on the initial Windows sign-on, but only see two "Key" icons instead of an additional "Globe" icon indicating Web Sign-in is an available option. I've followed the instructions, and there's no mention of this being out of scope or unsupported. System requirements which I am using - e.g., Windows 11 Enterprise 23h2 ( Feb 2025), Entra Joined device.
After logging into Windows for the first time, logging out or restarting makes the Web Sign-in option appear on subsequent logons. I confirmed that the device configuration to enable Web Sign-in is deployed during OOBE and checked the registry to ensure the value is present before the first Windows logon.
When setting up the device normally (without pre-provisioning), the Web Sign-in "Globe" icon appears on the initial Windows logon. I've searched other team channels and found references related to Windows 365 but nothing specific to Autopilot and pre-provisioning issues with Web Sign-in.
Has anyone else noticed this or had success configuring Web Sign-in with Autopilot pre-provisioning?
- Maggie_Dakeva
Microsoft
Please take a look at this troubleshooting tip and see if this helps resolve your issue: https://learn.microsoft.com/en-us/autopilot/troubleshooting-faq#why-is-the-web-sign-in-option-missing-at-the-windows-sign-in-screen-after-windows-autopilot-pre-provisioning-completes-
Could we get one single place to provide things like:
1. Privacy Policies
2. Branding
3. Use terms
etc.
right now, it seems that is scattered all over the place, making it really hard to keep it consistent across a tenant, much less across many tenants.
Example: Company Portal seems to use its own branding scheme, which is separate from Entra branding, which is separate from M365 branding and again separate from Edge branding. 🤪Can you please implement export and import functions to ALL Intune policies and areas?
It seems odd that some areas let you only export settings, others only let you import and yet other support none of that.
It'd be very helpful to quickly deploy some test settings to preview tenants before scaling out broadly.Is M365 Lighthouse going get more functionality? From our perspective it is way too rudimentary for actual use as an MSP. It covers barely 20-25% of the policies and controls we deploy (there are over 800 to each new tenant we provision).
Specifically: Teams configuration, Defender (in depth), Edge Policies, etc.
We'd really love to use it, but right now we have no choice but to resort to M365DSC. Works ok, but it's hard core technical making it hard to bring in new folks to the admin team.- Joe_Lurie
Dom_Cote This is great feedback. Can you post it here? This will go directly to the Lighthouse team.
Reference: Microsoft 365 Lighthouse · Community
One of our biggest issues with Windows 11 upgrades has been with Audio issues that occur after upgrading. We have a list of reported instances where many are reporting audio and headset issues. Our solution has been to remove the audio drivers and allow the system to add it back after successful scanning. This seems to be a big issue and wonder whom else is seeing this.
Nope - None of our customers report this.
Hi,
I don't know if it's Windows 11 specifically, I recall same thing was on W10.
But for our users the need to turn the headset off and on or re-connect to teams has become so frequent it has become second nature and a running gag.
Not a good user experience.Yes, we experience the same issues here. It's so problematic that we often prefer using Zoom over Teams, as Zoom offers better options for handling audio troubles and recovery-related issues. I believe these audio issues and Windows 11 updates are becoming significant obstacles that need to be addressed. Meanwhile, it seems Microsoft isn't providing much clarity on these issues, unlike other less pressing matters.
Hey,
We have migrated to use Autopatch a while ago and we see that over longer period of time number of devices that are "not up to date" is slowly growing.
There is nothing in Windows update reports that would indicate any installation errors it just says unknown while other updates (like drivers) install and report without any problems.
I was wondering if someone had some similar experience and maybe can share some info.We have the same problem. After lots of inhouse troubleshooting with the help of the community, we decided to create a support call for extra help. Still waiting for a solution
- EricMoe
Thanks for the question Macie. There's a couple of things you can check out before opening an Autopatch support case. If you see devices not up to date growing over time, navigate to Devices | Windows Updates. Then click Monitor and then click on Autopatch Devices. That report should show you total devices, ready devices and not ready devices. If your not ready devices is growing (or is bigger than you would expect) you should be able to see why they are in a not ready state. Usually devices that fall into this state will remain not up to date because they aren't ready to do so.
The second thing to check is the Quality UPdate status report which has all of your devices and their status. Click on the Columns option and add in Client State, Client Substate, Hex Error code, Intune last check in time, Quality Update installed time, service state and service substate. See if the devices that aren't getting up to date aren't checking into Intune, aren't checking into the update service, or are in some sort of error state.
If these don't help you get to an answer, open an Autopatch support request to have one of our engineers assist.
Thanks,
did all of those already, but good to have confirmation I checked the right things. Will continue investigating and if necessary open a support case.
Joining an existing device to Entra/Intune through settings - accounts - access work or school works fine using a FIDO2 key such as a Yubikey.
However, after attempting to sign in to Windows 11 (24H2) using that same key - Windows skips the Enrollment Status Page and goes straight to desktop. This also causes Windows to skip automatic Windows Hello deployment.
ESP only works if you sign in with a password first and then subsequent FIDO2 key (enforced by Conditional Access).
OR... If you enroll via OOBE using a FIDO2 key. Strangely, this works great and ESP runs as expected.
Is this expected? A bug? Our use case of enrolling existing devices is the most frequent for us, as we're an MSP for small businesses.
(And yes, I asked this here a while ago, but I didn't see any change yet)We already did a while ago - and the response was pretty much: "we've never seen this before" and don't know how to deal with it. 🤣 This, after it was already escalated.
To clarify: We don't use Autopilot. Our customers almost always have existing devices with existing user profiles that we don't touch. So wipe and load is not an option for us. (A great way to enable work and personal use on the same PC, btw)
To clarify some more: Both going through OoBE and Autopilot V1 and V2 work fine.
The issue is when folks join an EXISTING device to Entra/Intune and then sign in to the device with their new Entra account for the first time. ESP only runs when the very first sign-in to the new Entra account is done by password. If you sign in straight with a Yubikey, ESP is skipped. To me, it looks like Windows connects different endpoints and/or receives different tokens, depending on whether initial sign in is by FIDO2 or Password. But ONLY on existing devices.
Is ESP owned by the Autopilot team? Would they even be the folks to ask? Based on the different sign-in behavior, could this be somehow rooted in Windows itself and how it gets its tokens or signs in to Entra/Intune?
Bear in mind that during OoBE / Autopilot, we're signing in to Entra with FIDO2 via Web. But on the Windows lockscreen, we're not, we're signing in locally. It's only after the password sign in fails due to conditional access and Entra butts in to prompt an MFA challenge is when ESP starts working. These are very different authentication flows - with one working as expected (ESP was designed to work with web sign in during OoBE and AP), and the other local authentication flow not working.
Presumably, neither the Windows nor the ESP teams had this on their radar when they built their programs.
And I get it - since most of your large enterprise customer will ALWAYS wipe and load. So no one probably ever noticed this. But our main use case is onboarding existing devices.
Mind you, we currently cludge it by providing customers with an Entra password that they'll never use again after onboarding. But it's not elegant - as we'd like to be 100% passwordless. And I'm sure MSFT too. 😁
Good Day! Did anyone get this in their environment?
Any automated way to flag suspicious sign-ins beyond Identity Protection?
A key difference between interactive and non-interactive sign-ins and how to monitor them?
How does Azure AD calculate a “High” risk rating for users?
Best actions for handling high-risk users apart from MFA/password resets?
Also, I often see log entries like:
Update system, refresh token validation, DeleteDataFromBackend, DeleteDataFromCosmosDb, Group life cycle policy_get, synchronization rule action, Disable Strong Authentication, update StsRefreshTokenValidFrom Timestamp, Post user authentication method security info registration callback.
- Joe_Lurie
Thanks for the question. Unfortunately, we don't have any Identity SMEs on this call. This would be better posted to the Microsoft Entra forums here: Category: Microsoft Entra | Microsoft Community Hub
Best practices for correlating sign-in and audit logs to detect anomalies?
- Joe_Lurie
Thanks for the question. Unfortunately, we don't have any Identity SMEs on this call. This would be better posted to the Microsoft Entra forums here: Category: Microsoft Entra | Microsoft Community Hub
