Sunday, April 04, 2021

Win32 Apps Don't Deploy When User Enrollment Status Page Doesn't Complete

Autopilot Configuration Summary

  • Hybrid Autopilot
  • User Driven
  • VPN Deployed (user SAML connection at Win10 login screen)

The Issue

I recently came across an issue where applicable Win32 apps were not being deployed after an Autopilot build was completed. The 3 apps I set as required in the ESP profile were deployed correctly during the Device ESP stage but no further applications were deployed once the user had reached the desktop.

Rebooting several times, trying multiple syncs and waiting several hours made no difference. MS Store apps were being deployed to the devices fine, and Win32 application available for installs initiated from the Company Portal were deployed correctly.

In the Intune/MEM portal, the in scope applications would shows as 'Waiting for install status'.  That message could be for a multiple of reasons. The MEM portal isn't immediately up to date, so it's not the best reference to real-time behaviour. 

I had the necessary parts in place to make the HAADJ process as quick as possible via thanks to blogs from Michael Niehaus and script work from Steve Prentice. Because this was a user driven Autopilot deployment, using a user initiated VPN at the Windows 10 logon screen, I used the script provided by Steve Prentice to run as a scheduled task as Windows 10 login to complete the HAADJ process asap.

The Cause

On further investigation, I found that the user hadn't completed to the User ESP part of the Autopilot process which should complete the Hybrid Azure AD Join process. This didn't appear to be an issue at first, as the devices were showing as HAADJ and enrolled correctly in MEM.

As a side note, if the user doesn't complete the User ESP process, it's not a show stopper.  The device eventually becomes HAADJ.

I recreated the issue on several machines by bombing out at the User ESP part of the Autopilot process. In practice, there could be a few reasons why an end user encounters this:

  • The laptop dies due to low battery
  • The process times out due to the ESP period set
  • The user shuts down or restarts the device as they believe the process is stuck/hung

The the Intune Management Extension log was a hint to the problem:

![LOG[[Win32App] GetHasProvisioningCompleted failed with ex: System.Management.ManagementException: Access denied

<![LOG[[Win32App] ESP got userHasProvisioningCompletedValueString False]LOG]!><time="03:59:49.9492494" date="3-28-2021" component="IntuneManagementExtension" context="" type="1" thread="4" file="">

Because the User ESP process hadn't completed gracefully, it appears that further Win32 apps would not deploy. Because the User ESP screen doesn't appear for the users next login, I added the SkipUserESP registry key.  You can also deploy this via an OMA URI in MEM. This provided the means for the User ESP completion check to be skipped.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync\
SkipUserStatusPage = 1

Note, when doing it manually, there will be multiple GUID’s listed in the Enrolments registry key branch. You can determine the relevant registry key by checking the UPN registry value in the {EnrollmentGUID} keys relates to the end user e.g.

After making the change, I restarted the Intune Management Extension service and within 1 minute, the Win32 apps start to install.

Conclusion

One option is to set the User ESP screen to be skipped altogether, but I prefer to have the HAADJ process completed when the user hits the desktop for the first time. I would add the registry workaround as and when it's required.


0 comments:

Post a Comment