This blog will explore a common issue with Win32 app updates on Intune-managed kiosk devices. While these devices are designed for restricted access and often run without an Entra user session, this setup creates a challenge in which Win32 apps initially install fine but fail to update.
We’ll explain why this happens, what we found in the logs, and how Microsoft’s suggested workaround failed. Finally, we’ll show you an easy fix you could implement by configuring an Intune configuration profile. This policy will ensure that your kiosk devices stay up to date without having to log in with an Entra user on those KIOSK devices.
Intune Win32 App “Waiting on Install Status” Kiosk Devices
Microsoft recommends using the least privileged user account for kiosk devices, especially in public environments where users shouldn’t have system access. To achieve this, kiosk devices typically operate under local standard accounts rather than requiring Entra ID logins.
These devices are often deployed in shared-use environments using Assigned Access Mode or Multi-App Kiosk Mode. This ensures users can only interact with a predefined set of applications.
However, because kiosk devices rely on local standard user accounts, application deployments, and updates must function without an Entra user session. While Win32 apps install successfully during initial provisioning, subsequent updates often fail, getting stuck in a “Waiting for install status” state indefinitely.
Investigation: Following the Logs
To get to the root of the issue, we needed to determine why Win32 app updates were stuck and were waiting for the install status. Given that the updates were failing silently, our first step was to check Intune Management Extension (IME) logs, which handle app deployments.
Since IME is responsible for Win32 app execution, we expected to see clues related to installation attempts or authentication failures. From there, we could validate our findings with AAD and AppWorkload logs to understand whether the issue was device-based authentication or an Entra ID dependency preventing updates from being processed.
With this in mind, we started digging through the logs
IME Logs: Token Acquisition Failures
Since updates were failing, we started by checking the IME logs, suspecting a missing device token. Instead, we found repeated token acquisition failures:
“Failed to get AAD token. len = 34 using client id “
The error suggested that IME was unable to retrieve an Entra ID / AAD Authentication token, meaning it could not validate itself against Intune to process app updates. This initially led us to suspect an issue with device authentication when the Win32App Updates needed to come down to the Kiosk Devices. However, we needed more confirmation.
AAD Logs: Authentication Errors
To verify whether authentication was the root cause, we checked the AAD logs, where we found:
- “Error: 0x4A50081 at ClientCache.cpp, line 376, method: ClientCache::LoadPrimaryAccount.”
These logs confirmed that authentication was indeed failing, likely because no Entra ID user had ever logged into the device. At this point, we had a clear pattern:
- IME couldn’t retrieve an Entra ID token.
- AAD logs showed that no user authentication had occurred.
- Without a user log in, app updates were stalling indefinitely.
But one more piece was missing: what exactly was preventing Intune Management Extension (IME) from moving forward?
Kiosk Devices: Device Stuck in Account Setup
Next, we checked the AppWorkload logs, which provided another important piece of information. It seems that the device was still in the account setup phase, which explains why IME was stalling! The Intune Management Extension (IME) was waiting for a user login to complete the Enrollment Status Page (ESP), which was weird as the device was already provisioned.
This behavior means that even though the device itself is fully enrolled in Intune, IME does not move forward with app updates because it is still waiting for the user-specific (Account Setup) phase of ESP to complete.
Since kiosk devices do not typically have Entra users logging in, this phase remains incomplete indefinitely, preventing updates from being applied. With it, the Intune Portal will keep waiting for the install status.
At this stage, Microsoft recommends manually logging in with an Entra ID account on each device to trigger the update process. While this solution technically worked, it was completely impractical for large-scale kiosk deployments. This made it pretty clear that a more automated fix was needed.
This aligned with findings from our previous research on ESP-related issues, where devices could become stuck in an incomplete state when no Entra user logs in. Feel free to read all the details in our ESP Blog.
Fixing the Win32App Update on Kiosk Devices
We showed you in the Enrollment Status Page Blog some time ago that one of the first checks the ESP does is check if the Device and User Status Page is being skipped. If so, the device would return that it is NotInESP, and with it, the Win32App updates would be installed.
Once we understood the issue, we applied an easy fix to ensure that Win32 app updates could proceed without requiring an Entra user login.
Intune Configuration Profile (OMA-URI Policy)
To apply this fix across all affected devices, we deployed an Intune configuration profile with the following settings:
- OMA-URI Path: ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
- Data Type: Boolean
- Value: true
This policy ensured that devices skipped the ESP user phase, allowing Win32 app updates to be installed on Kiosk devices without manual intervention. Of course, we could do the same with a PowerShell command, but using an Intune Configuration Policy is the preferred way to go!
New-ItemProperty -Path “HKLM:\software\microsoft\enrollments\enrollmentid\FirstSync” -Name “SkipUserStatusPage” -PropertyType DWord -Value 1 -Force
Key Findings
Through this process, we confirmed:
- IME and AAD logs both showed token acquisition failures, suggesting authentication issues.
- AppWorkload logs revealed that the device was stuck in account setup (awaiting a user login).
- IME does not process app updates on kiosk devices when an Entra user has not logged in, causing updates to remain in “Waiting for install status.”
- Microsoft initially suggested logging into every device manually with an Entra account to resolve the issue, which was not a scalable solution.
- Skipping the ESP user phase using the SkipUserStatusPage CSP allows Win32 app updates to install without requiring an Entra user session.
Final Thoughts
This issue is particularly relevant for kiosk and shared-use devices where Entra logins are not feasible. Ensuring that Win32 apps update correctly without user authentication is critical for keeping devices secure and up to date.
By skipping the unnecessary ESP user status check and addressing token failures, we ensured that unattended devices could continue to receive updates as expected.
If you’re managing Intune-enrolled kiosk devices and experiencing similar issues, implementing this fix should allow Win32 app updates to function properly without requiring an Entra user login.