Windows Autopilot FAQ Clarifying the General Misconceptions Part 1

I have come across many scenarios where people still do not have excellent clarity on what Windows Autopilot is and its purposes.

This post is my effort to help clear the general misconceptions regarding Windows Autopilot (Windows Autopilot FAQ) and help people with the underlying blocks and concepts.

NOTE! – I have designed this post as a Question & Answer session to help address the Windows Autopilot doubts.

Related Posts

Patch My PC

Is Autopilot an alternate for OSD?

The answer is NO. Autopilot is not an alternate for OSD, and it was never meant to be. Autopilot does not deploy OS to the end device but is just a means to provide end-users with a customized, streamlined device setup process. 

If you would require to deploy OS images to systems that do not come with an OEM Win 10 image (which we usually refer to as “bare-metal” systems), you would still need to have Microsoft Deployment Toolkit for the appropriate deployment type.

LTI (Lite Touch Installation) can be handled by MDT alone. However, ZTI (Zero Touch Installation) and UDI (User Driven Installation) require MDT coupled with SCCM.

NOTE! – More reading options about Repurpose Existing Devices to Windows Autopilot – MDT/SCCM?

Adaptiva
Repurpose Existing Devices to Windows Autopilot - indows Autopilot FAQ
Windows Autopilot FAQ

What is Windows Autopilot?

Windows Autopilot is a provisioning method to streamline device setup (first boot) and provide a customized experience to the user minimizing IT overhead in the setup process.

Microsoft’s approach to modern Windows provisioning and a way to move towards modern management for organizations adopting cloud and looking to cut down their on-premise footprints.

NOTE! – With OSD, what is achieved is a custom OS image captured from a system manually configured to meet the requirements, which is then deployed to the rest of the machines. This requires IT involvement and on-premises infrastructure – both of which add up to cost.

Autopilot essentially gives you the same ability without the hassles of preparing and maintaining your custom images.

If your device comes with an OEM image (which mostly is the case as organizations rarely purchase blank systems nowadays), Autopilot can jumpstart the device provisioning.

Windows Autopilot FAQ - WhiteGlove process
Windows Autopilot FAQ – WhiteGlove process

What are the Scopes of Windows Autopilot?

It is essential to understand the purpose and scope of Autopilot to appreciate its benefits and potential. Autopilot helps to

  • Customize the first boot setup which is termed as the Out-Of-Box-Experience (OOBE) by Microsoft
  • Provide the end user with a customized Sign-In page rather than the default Microsoft one (should be already configured in Azure)
  • Provision the device as an Azure AD join or Hybrid Azure AD join (as configured in the Autopilot profile)
  • Show/Hide OOBE screens (like EULA and others)

When does the Scope of Windows Autopilot End?

The scope of Windows Autopilot ends as soon as the device starts the Azure AD join or Hybrid Azure AD join process. If you have an MDM solution configured in your tenant, the Azure

AD/Hybrid Azure AD join can automatically trigger MDM enrollment (needs to be configured), providing the device with the configuration policies and applications.

What are the Scenarios Windows Autopilot can Cover

  • It would help if you had your device set up to be customized, reflecting your organization’s brand at the beginning.
  • You don’t want your users to go through each of the OOBE screens
  • You want your device to be Azure AD joined or Hybrid Azure AD joined
  • You don’t want to allow the end-user doing the setup to get local admin privileges

You can rest assured that Windows Autopilot covers all the above scenarios. In addition to it

  • You want your device to be automatically enrolled into management – Autoenrollment helps enroll devices to Intune during the Azure AD/Hybrid Azure AD join process.
  • You want your device to be fully configured before the end-user is presented with the Desktop – ESP locks the device to a blue screen showing the end user the current status of device setup till all the required policies and applications get implemented on the system.
Windows Autopilot - Enrollment Status Page
Windows Autopilot FAQ – Enrollment Status Page

Windows Autopilot helps you provision devices with no on-premise investment and no involvement required by the local IT team for the device setup. You can do this provisioning with just a cloud subscription and devices with OEM images. 

You can have your devices ready to be provided to your workforce directly (from the manufacturer or the local IT, as it is in most organizations) without worrying about the deployment.

Autopilot gives the ability to an Organization embracing the cloud movement to reduce their on-premise IT footprint by utilizing the modern management of Windows. This is Windows Autopilot for you.

What is the Windows Autopilot Schema?

A high-level schematic representation of Windows Autopilot is given below.

Windows Autopilot FAQ - Schema -
Windows Autopilot FAQ – Schema

The Windows Autopilot process, as shown schematically above:

  • Procure devices from OEM Vendors/Partners.
  • Register the devices to Autopilot service.
    • The OEM vendors and device partners can register devices on behalf of your organization. In such a case, you would require to sync the devices to Intune, claiming ownership.
    • You can retrieve device hash from devices to manually register them to autopilot service.
  • Create a dynamic device group collection in Azure to contain the Autopilot registered devices.
  • Create an Autopilot deployment profile and assign it to the dynamic device group for Autopilot devices.
  • The unboxed devices can be shipped to the users directly from Vendors or can be provided by the local IT team.
  • Users unbox the devices and start them. (first boot)
  • The device queries the Autopilot service to check if it is registered. (requires active internet connection)
  • Autopilot service contains the device for a match, and if found, the Autopilot deployment profile is sent down to the device.
  • The device uses the configuration as retrieved to drive the OOBE setup phase.

Why does device provisioning gets stuck at the ESP page resulting in a timeout causing the error?

Yes, this is true and happens not only with Autopilot but also true for normal Azure AD join/Hybrid Azure AD join scenarios. This generally happens if you have configured ESP to track all the required applications.

The provisioning depends on network bandwidth and the size of app packages that it requires to download, all of which can result in ESP timeout.

As an admin, you can increase the ESP timeout duration. However, the user will still have to spend quite a reasonable amount of time with the ESP screen.

Intune Enrollment Status Screen - Windows Autopilot FAQ - ESP Stuck Issues
Windows Autopilot FAQ – ESP Stuck Issues

To overcome this, you can select a few particular applications to be tracked during ESP while the rest can continue to be affected post-ESP phase.

Or better, with Windows 1903, Microsoft introduced the Autopilot for the white glove deployment process, which allows the IT staff to pre-provision the device for a faster setup experience for the end-user.

Doing Autopilot with Hybrid AAD join, there is a good chance you will end up with an ESP error failing the account setup. Vimal Das has an excellent post on this.

More details aboutWindows Enrollment Status Page Troubleshooting tips

What about the existing devices which may not be running Windows 10?

For existing devices running Windows 10,

  • An existing device can be added to the Autopilot service by simply uploading the device hash.
  • Do you have thousands of devices where collecting the device soup individually is impossible? Do not worry, as you can create a device group in Azure and assign the Autopilot profile to that group with the setting Convert all targeted device to Autopilot set to Yes.

NOTE 1 – It takes 48 hours to register the devices to DDS. Post that reset, the machine will start with Autopilot provisioning.

NOTE 2 – Microsoft has already declared the End of Support for Windows 7.

For organizations that still have a large chunk of devices running Windows 7 (yes, there are), there is Autopilot for Existing devices which is Microsoft’s answer to have your Windows 7 devices re-imaged to Windows 10 (utilizing your on-prem infrastructure) and embrace the modern management for which Windows 10 is built for.

NOTE! – More reading options about Repurpose Existing Devices to Windows Autopilot – MDT/SCCM?

Conclusion – Windows Autopilot FAQ – To be Continued

I hope this helps you better understand Windows Autopilot and what purpose it serves in the days of modern cloud management.

In my next post on Windows Autopilot, I’ll be covering the concepts and working blocks of Windows Autopilot setup from the IT Admin end perspective. Till then, read something every day, learn something every day!

Resources

2 thoughts on “Windows Autopilot FAQ Clarifying the General Misconceptions Part 1”

  1. I cannot Thank you enough for spending time and providing information about Intune. I am sure its helping a lot of engineers who works on Intune, SCCM. Thanks to all of the Authors on this blog.

    Reply

Leave a Comment

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