Windows Autopilot white glove service

This week is about Windows Autopilot. More specifically, the Windows Autopilot white glove service. The Windows Autopilot white glove service will enable organizations to pre-provision Windows 10 devices to make sure that end-users get their device faster to a fully provisioned state. In this post I’ll start with a short introduction about the Windows Autopilot white glove service, followed by the steps to enable the white glove service in Windows Autopilot. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Windows Autopilot white glove service (also known as Windows Autopilot for white glove deployment). This process is designed to get the user faster up-and-running. That is achieved by splitting the provisioning process (as shown below). The starting point of the Windows Autopilot for white glove deployment is the same as any other Windows Autopilot deployment, it starts with a device that is provided by the OEM (imaged and accommodated with drivers). The second step is what makes this the Windows Autopilot for white glove deployment, it enables an organization to pre-provision device apps, device settings, device policies and user apps (of the assigned user) on the device. This can be achieved by an OEM, partner or the IT organization itself. That also enables the faster user experience, as, once the user logs on, only user settings and user policies are still required.

WhiteGlove-Process

Before looking at the configuration, let’s go through a few important requirements and limitations of the Windows Autopilot for white glove deployment:

  • The device must run Windows 10, version 1903 or later;
  • Only user-driven scenarios, supporting both, Azure AD join and hybrid Azure AD join;
  • Must be a physical devices that support TPM 2.0 and device attestation (virtual machines are not supported);
  • The device must have a ethernet connectivity (Wi-Fi connectivity is not supported).

Configuration

Let’s continue by looking at the actual configuration. As the configuration of a Windows Autopilot deployment profile now contains a new look-and-feel, I thought it would be good to show screenshots of that new experience. The following 4 steps walk through the creation of a Windows Autopilot deployment profile that allows white glove.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a

On the Create profile blade, on the Basics section, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;

WA-WG-CreateProfile-Basics

4b

On the Create profile blade, on the Out-of-box experience (OOBE) section, provide the following information and click Next.

  • Deployment mode: Select User-Driven, as that deployment mode provides the functionality that is
    needed for this post;

  • Join to Azure AD as: Select Azure AD joined to join the device to Azure AD during the Windows Autopilot user-driven experience;
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot user-driven experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot user-driven experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot user-driven experience;
  • User account type: Select Administrator to only make any user on the device an administrative user;
  • Allow White Glove OOBE: Select Yes, as that enables the functionality that is needed for this post;
  • Apply computer name template: Create a computer name, according to the configured template, for devices at initial startup;
WA-WG-CreateProfile-OOBE
4c On the Create profile blade, on the Scope tags section, click Next;
WA-WG-CreateProfile-Scope
4d On the Create profile blade, on the Assignments section, add an assignment and click Next;
WA-WG-CreateProfile-Assignment
4e On the Create profile blade, on the Review + create section, click Create;
WA-WG-CreateProfile-Review

Administrator experience

Now let’s end this post by having a look at the administrator experience. More specifically the experience of the IT person performing the Windows Autopilot white glove deployment. Below on the first row is are the screens that the administrator has to go through, after pressing the Windows key 5 times on the initial OOBE screen. First the administrator has to select the Windows Autopilot provisioning option and click Continue, followed by confirming the device information and clicking Provision. The QR-code contains the identifier of the device and can be used to make some configuration changes.

After starting the process, it will either fail or succeed. Like with everything else. The reason I specifically mention it, is because the result is clearly shown by the background color. Below on the second row, are screenshots of a failed and succeeded Windows Autopilot white glove deployment. To make creating screenshots easy, I simulated both scenarios on a VM (see the error on the red screenshot and the no found messages in the green screenshot). Simulated, because a VM is not supported and will not work. On a physical device those screenshots will also provide a QR-code. As shown below, after a failure the administrator can choose to Retry, Reset and View diagnostics and after a success the administrator can Reseal the device. Resealing the device will make sure that the end-user will receive the expected OOBE.

WA-WG-01 WA-WG-02
WA-WG-Error WA-WG-Success

More information

For more information about enrolling Windows devices by using the Windows Autopilot white glove service, please refer to the documentation named Windows Autopilot for white glove deployment.

24 thoughts on “Windows Autopilot white glove service”

  1. Thanks for this, Peter-

    Any advice for troubleshooting whiteglove failures? Which logs should I be looking at?

    Reply
    • Hi Steve,
      Have a look at the Event Viewer, at the following locations:
      – Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
      – Microsoft-Windows-Provisioning-Diagnostics-Provider
      – Microsoft-Windows-User Device Registration
      Regards, Peter

      Reply
  2. Hi Peter – Great article!

    Question: I typically do not make users local administrators. Could you shed some light on why this is selected in your tutorial?

    BTW White Glove works great. It has me going through all the various device compliance policies, device configuration profiles, powershell scripts, client apps, etc. to check for assignments that can change to device versus user based.

    Thanks again!

    Reply
    • Hi John,
      It really depends on the scenario. For this example I choose to go for local administrators.
      Also, keep in mind that you don’t need to change everything to device assignments, as white glove should also install user assigned apps of the assigned user.
      Regards, Peter

      Reply
  3. Great post!
    Definitely a great improvement to Intune. Quite similar to what happens on SCCM with OSD.

    Thanks for sharing!

    Cheers,
    Pedro

    Reply
  4. Hello,

    I follow your blog and improvements on Autopilot that I begin to propose in my company for real users.
    I succeeded to do the standard Scenario but with Whiteglove I have an error (red screen) … and I do not find any log available neither how to access to the event viewer (only retry or reset option on the red screen).

    DO you have an advice for my situation ?

    Thank you a lot,

    Julien

    Reply
  5. Nice write up!
    Been also busy with it past 2 weeks.

    Been getting the Red screen in step 1, Wich was relatable to the lack of TPM2.0 Device Attestation.
    (I find it hard to find out which type has the function and which not).
    After trying it on a Prodesk 400g4 it got past the first step and halted during the second.

    Only deploying the profiles and Office to the device.

    I noticed that after I implemented KB4497727 in my Task Sequence and reinstalled the pc, it got trough and installed all fine.
    Is this for now also a prerequisite?

    Reply
  6. Has anyone noticed ESP hangs for an extremely long time on prepare your device for mobile management. When it’s done on a 1809 device it’s much quicker. Could it be a known issue with 1903??

    Reply
  7. Must apps be assigned to users? I did a test and most of the apps i want to install during the whiteglove process didn’t get installed. Those apps are assigned to a device group

    Reply
    • Hi Ronald,
      It should install all device assigned apps and any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user that has been pre-assigned to the Autopilot device will also be installed.
      Regards, Peter

      Reply
  8. Hello Peter,

    Have you ever experienced a UAC prompt during White Glove process ? Mine is as follow :
    1) Device Preparation : ok
    2) Device Setup : ok (2 apps : Office / Chrome)
    3) Reboot triggered (Don’t really know why)
    4) UAC prompt : if I click YES then process finish with green screen
    5) Reseal then reboot
    6) 10 minutes of “we are preparing blablaba” then OOBE with local account

    User driven scenario with the same profile is working properly this is why I don’t understand..

    Thank you,

    Reply
  9. Hi Peter,

    Thanks for the Blog.

    I want to know the process for Hybrid scenario how to start?

    How to get the Windows Key 5 times for domain-joined PC?

    Regards
    Kumar Sadaram

    Reply
  10. we target app deployment (regulary) via nested dynamic groups. could this be a problem for app deployment via autopilot pre provisioning?

    Reply

Leave a Reply to Mathieu Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.