Windows Autopilot FAQ Clarifying the General Misconceptions Part 1

0
Windows Autopilot Architecture

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 Question & Answer session to help address the Windows Autopilot doubts.

Related Posts

TL;DR

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 which 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) requires MDT to be coupled with SCCM.

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

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. It is 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 as well as on-premises infrastructure – both of which adds 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 truly. 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 Ends?

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 a MDM solution configured in your tenant, the Azure AD/Hybrid Azure AD join can automatically trigger MDM enrollment (needs to be configured), which then provides the device with the configuration policies and applications.

What are the Scenarios Windows Autopilot can Cover

  • You need your device setup to be customized reflecting your organization 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 be rest assured, all the above scenarios are covered by Windows Autopilot. In addition to it

  • You want your device to be automatically enrolled into management – Autoenrollment helps to 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 to provision devices with no on-premise investment and no involvement required for the local IT team for the device setup. You can do this provisioning with just cloud subscription and devices with OEM image. 

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 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 it. (first boot)
  • Device queries Autopilot service to check if it is registered. (requires active internet connection)
  • Autopilot service checks the device for a match, and if found, the Autopilot deployment profile is sent down to the device.
  • The configuration as retrieved is used by the device 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 true for normal Azure AD join/Hybrid Azure AD join scenario as well. This generally happens if you have configured ESP to track all the required applications.

The provisioning depends on network bandwidth as well as the size of app packages that it requires to download, all of which can result in ESP to 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 either 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 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 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.
  • You have thousands of devices where collecting the device hash individually is not possible? 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 is 48 hours for the devices to be registered to DDS. Post that reset and the device and it will start with Autopilot provisioning.

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

Organizations which still has 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 to have a better understanding of 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

LEAVE A REPLY

Please enter your comment!
Please enter your name here

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