I’m happy to share some field notes and experiences with the Windows Autopilot White Glove feature which is available with the Windows 10 1903 release. I’ve done a lot of testing and engineering for a recent project which also included this brand new feature.
First things first (Requirements)
This is probably the most important information of this post. Really make sure to verify the following prerequisites for Autopilot White Glove. Because there are additional requirements compared to Autopilot enrollments.
Basic Autopilot
Make sure that a “classical” Autopilot Deployment is working properly without any issues.
Hardware and OS
- Hardware with support for device Attestation (“Physical devices that support TPM 2.0 and device attestation; virtual machines are not supported.”)
- Physical devices with Ethernet connectivity (WiFi connectivity is not supported!)
- Windows 10, version 1903 with KB4505903 injected (equals OS Build 18362.267)
Starting the white glove adventure
Preparing Windows 10 1903
As mentioned by Michael Niehaus Windows multiple Autopilot issues were fixed by KB4505903. So we need to inject this cumulative update to the downloaded source. This was already the first hurdle to overcome because I’ve missed the fact that the Windows Setup (install.wim) actually contained multiple image indexes (yeah it’s kinda embarrassing). We achieve this by using dism offline servicing with PowerShell cmdlets.
- Prepare a folder structure like:
- C:\Temp\W10-1903-DE-AUG
- mount
- patch
- source
- C:\Temp\W10-1903-DE-AUG
- Download the Windows 10 1903 business editions image from VLSC or MSDN, extract the *.iso to your created “source” folder
- Download the cumulative update to your created “patch” folder
- Find the right Image index to mount (depending on the edition you want to install enterprise edition is usually index 3)
Get-WindowsImage -ImagePath "C:\Temp\W10-1903-DE-AUG\source\sources\install.wim" - Mount the image to the “mount” folder
Mount-WindowsImage -Path C:\temp\W10-1903-DE-AUG\mount\ -ImagePath "C:\Temp\W10-1903-DE-AUG\source\sources\install.wim" -Index 3 - Inject cumulative update:
Add-WindowsPackage -PackagePath "C:\Temp\W10-1903-DE-AUG\patch\windows10.0-kb4505903-x64_af8c6ab868423055a750797b6d52c1bd67e15a95.msu" -Path "C:\temp\W10-1903-DE-AUG\mount\" - Dismount the image and save changes:
Dismount-WindowsImage -Path C:\temp\W10-1903-DE-AUG\mount\ -Save - Dism cleanup:
dism /Cleanup-Wim - Split the image to fit efi bootable usb-stick (optional):
Split-WindowsImage -ImagePath "C:\Temp\W10-1903-EN\sources\install.wim" -SplitImagePath "C:\Temp\W10-1903-EN\sources\install.swm" -FileSize 3000Remove-Item -Path "C:\Temp\W10-1903-EN\sources\install.wim"
Installing the operating system
For the OS installation I used Roger Zander’s mOSD solution. It’s a little set of source files which enable you a fast and simple zero touch Windows installation from a USB stick making use of an Autounattend file.
Intune Autopilot Profile
This one is rather simple, just enable white glove for the autopilot profile in the Intune pane and make sure the profile is assigned to your device. Don’t forget to assign a user account to your device.
It’s all about the hardware
For testing I’ve been using a HP EliteBook x360 1030 G3 and a HP EliteBook 850 G5 (fresh out of the box).
Hint: during all following steps i opened a command shell by pressing [shift] + [F10] to investigate things like the event viewer and logs within the file system.
After booting up my first test device (EliteBook 850 G5) and pressing the Windows key five times Autopilot White Glove started with the provisioning but was hanging within the “Registering your device for mobile device management” step until it ran into a timeout.
I was very surprised because this was working all fine for “normal” autopilot deployments. But as already mentioned Autopilot White Glove uses different capabilities (device attestation) in order to pre provision the device. On the HP EliteBook 850G TPM attestation was initially not available (although specified in the product information). This one was actually a bummer because the UEFI and TPM Firmware were outdated. But after the TPM firmware upgrade it was working.
You can check support for TPM attestation within the Windows Security center :
In the event viewer you can also track the behavior when a client requests a TPM attestation certificate. Check the following event log for details: “Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot“.
Screen still stuck
Despite TPM, device attestation was now working fine the Autopilot White Glove screen still got stuck in the “Registering your device for mobile device management” step. I covered this in a separate post, read it here.
One step further but still not there
After overcoming all the “Device preparation” hurdles the device setup finally started. The user had assigned 25 apps (Win32, Windows Store for Business and LOB MSI’s). But the provisioning was always hanging on the last app installation (24/25) and then ran into the timeout which came from the Enrollment Status Page (ESP).
So I dived into the Intune Management Extension (IME) log located under: “C:\Programdata\Microsoft\IntuneManagementExtension\Logs\“.
While investigating the entries all the way up I found this line:
[LOG[[Win32App] ESP CheckDeviceAndAccountSetupStateWithWmi all apps completed for device]LOG]!
So this was rather strange because the ESP said it was still waiting for an app installation. When I had a closer look on each individual app installation I discovered the following entries:
<![LOG[[Win32App] Exitcode is defined as success but it actually failed according to detection result]LOG]!>
<![LOG[[Win32App] Set EnforcementStateMessage EnforcementState: Error, ErrorCode: -2016345060]LOG]!>
This explains why the ESP was waiting for the app installation, because one Win32 installation failed. In my case the installer was having issues because the app was doing some detection stuff in the user context which was actually “defaultuser0” and not a “real” account.
Which means that the issue was related to a Win32 app installation error but the ESP did somehow not notice the returned error. I’ll try to address this (miss)behavior in a support case and the Microsoft Intune team. Michael Niehaus confirmed this behaviour with a blogpost on the 15.08.2019.
In the meantime I was able to reproduce the issue also on non autopilot devices with Azure AD join and auto MDM enrollment configured. So this seems to be a general ESP related thing.
Mind the Enrollment Status Page (ESP)
During the testing always the Default ESP was shown. Nevertheless if I assigned the group containing my autopilot device or user account to my custom ESP. So if you want to use the ESP with Blocking-mode which is probably what you want for a white glove provisioning you have to adjust your default ESP.
What is behind that QR code?
The QR code displayed in the Autopilot White Glove screens contains device information for processing and workflows (e.g. for a CMDB integration). Furthermore to the data stored within the QR code the “Windows Autopilot Companion App” allows you to gather more details by joining device data with information stored in the autopilot service. Thus the app accesses the Microsoft Graph API with the Microsoft’s default PowerShell Azure AD App ID: d1ddf0e4-d672-4dae-b554-9d5bdfd93547 which comes also with the Intune PowerShell samples.
The app is published as sample app on GitHub to be further customized by your own needs and device life cycle process.
To install the app on my Windows 10 device I needed to enable side loading and install the trusted root certificate which comes together with the appxbundle.
Reference
I recommend you to have a read on the following articles to get some interesting details and behind-the-edge-knowledge about autopilot white glove: