is there any way to solve automatically ?

Thanks for joining today. Save the date for next month's Office Hours session on April 16th! 📅 Windows Office Hours: April 2026

Intermittent auto logon issue in Kiosk mode configured via Microsoft Intune

A Kiosk profile has been configured on Windows devices through Microsoft Intune. Within the configuration, the "User logon type" is set to "Auto logon" to ensure the device automatically signs in with the kiosk user.

However, the behavior is inconsistent:

On some devices, auto logon works as expected.

On other devices, although the kioskUser account is successfully created, the automatic sign-in does not occur, and the device remains on the login screen.

Expected Behavior

The device should automatically sign in using the configured kiosk account (kioskUser) after boot, without requiring any user interaction.

Actual Behavior

Although the kioskUser account is created successfully, the auto logon:

Does not execute consistently.

Requires manual user interaction on some devices.

Several hardware vendors (OEMs) we work with recommend not installing drivers delivered via Windows Update, claiming that in some scenarios they may cause performance regressions or instability, and instead ask us to deploy OEM‑validated drivers only.

From an enterprise perspective, we would like Microsoft‑supported guidance on this topic.

Specifically:

• What is the recommended approach when OEMs advise against Windows Update drivers?
• Should organizations block all driver updates via Windows Update, or use a controlled approval model instead?
• How do Intune Driver Update policies or Windows Autopatch fit into this scenario?
• Is the expectation that drivers from Windows Update are production‑safe, or should they be treated as optional / staged updates?

Our goal is to balance stability, performance, and security without relying on unsupported workarounds.

Hello, thanks for this and answering our questions!

I’m the primary Intune administrator for a healthcare non‑profit operating on a GCC tenant. We are currently transitioning our devices from AD/Entra hybrid‑joined to Entra‑joined. We are a remote‑first organization with very few users working onsite.

Today, our prior hybrid‑joined devices (connected to a domain through VPN) authenticate using RSA and our more recent Entra-joined devices use the Windows Hello for Business passwordless experience with Intune, as we are working toward moving to adopting the Cloud Kerberos Trust model.

Our challenge is administrative access and account management during this transition. Specifically:

• We still need to manage hybrid‑joined accounts via AD DS.

• We need to audit administrative escalations on devices, typically for single installations of software vs. full-blown Intune deployment or running Command Prompt/PowerShell as admin.

Because the Windows Hello for Business passwordless experience is enabled on our Entra‑joined devices, our IT users cannot sign in with a domain admin account to administrate anything. As an example, this prevents us from running say, Active Directory Users & Computers with elevated privileges as AD DS can't be used without logging in as an account with domain admin rights, which seems to make AD DS administration from Entra-joined devices impossible at this time.

Is there a supported way to enable these administrative tools locally or administrator credentials for other than just the local admin, while still using Windows Hello for Business passwordless authentication? At the moment, our current workaround for AD DS is to log into an on‑premises VM for AD DS management and we've just been using the local admin password for standard escalations for now, which is not ideal.

Thank you for the guidance!

Trying to better understand the different reports for Windows Updates for business in Intune. The new reports do not see to match each other. They are difficulty to navigate and often time have unknown devices on them when all diagnostic data is on.

Hot do the autopatch reports work? I see data in them but we are not using the service. Why am i seeing data, can i use these reports, how do i get all devices to populate, we have over 9000 devices

We manage a large number of Windows 10/11 devices via Microsoft Intune / Windows Update for Business.

We frequently encounter recurring Windows Update failures (feature updates, cumulative updates, servicing stack issues) that require manual troubleshooting:

• log analysis
• reset Windows Update components
• running Windows Update Assistant

This is not scalable for us.

Is there a Microsoft‑supported way to automatically detect and remediate common Windows Update failures at scale?

Specifically, we are looking for guidance on:

• Proactive Remediations or built‑in auto‑healing
• Windows Autopatch or Update Health / Update Compliance auto‑correction capabilities
• Any official remediation scripts, policies, or services that can replace manual fixes

Our goal is to self‑heal update issues automatically, without human intervention whenever possible.

We are starting to the Bitlocker recovery prompts due to expiring UEFI certificates, what is MSFT approach to addressing this before the expiration date of June.

Hi all,

We are working to deploy Windows Hello for Business with the Cloud Kerberos trust model to our hybrid joined workstations. Unfortunately, we have discovered that if a user does not have line of sight to a domain controller when they attempt to sign in to their workstation for the first time with WHfB, they are blocked from signing in and receive a cryptic and misleading error message. Apparently this is "working as designed" per Windows Hello for Business Frequently Asked Questions (FAQ) | Microsoft Learn.

Practically speaking, how does one roll this out if they have mobile users and do not have an always-on VPN?

Welcome to the March edition of Windows Office Hours! In the "office" today, we have Joe_Lurie​, EricMoe​, Jason_Sandys​, Maggie_Dakeva​, and Christian_Montoya​. We're getting started on the early questions. Keep them coming if you have them. :)