Thursday, July 15, 2021

Disable Misleading Windows Hello for Business Enrolment Toast Notification (20H2)

Disable Misleading Windows Hello for Business Enrolment Toast Notification (20H2)

Credit to Arend Dieperink for gathering these details

When Windows 10 20H2 was being deployed to Surface 3 laptop devices, we noticed that they received a Windows Hello toast notification popup after the update applied. When the user clicked on the notification, they were allowed to set-up Windows Hello (believing it was Windows Hello for Business, but it wasn't). It worked for the user, and they could log in with their camera or PIN. However, this couldn't be Windows Hello for Business.



These devices are set up as Hybrid Azure AD Joined/Hybrid AutoPilot and the supporting infrastructure to support WHFB in a Hybrid configuration is not yet in place. Therefore it clearly cannot be WHFB. The Azure AD Sign In logs confirms that's the case, as the sign-in events using Windows Hello actually show as a password sign-in instead of using WFHB.

How to disable?

So how do you stop users enrolling in this version of Windows Hello after the Windows feature update?... 

 In short, there is a registry value that controls whether this prompt shows. The toast notification will pop up 3 times and after that, will no longer appear.
The registry key/value is below. If you set this to 3 ahead of rolling out 20H2 (or maybe above) the prompt for Windows Hello shouldn't show to the user.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\FaceLogon]
"CreateEnrollmentPromptCount"=dword:00000003

How to remove Windows Hello from user's who enrolled


If you have users who have already enabled this flavour of Windows Hello, you can disable it by running the following from their device (needs to be run under the context of the user, as opposed to SYSTEM or an admin account)

certutil -deleteHelloContainer




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.


Monday, December 30, 2019