I have encountered many scenarios in which people still lack clarity on what Windows Autopilot is and its purposes.
This post is my effort to clarify the general misconceptions regarding Windows Autopilot (Windows Autopilot FAQ) and help people understand the underlying blocks and concepts.
I have designed this post as a question-and-answer session to help address the Windows Autopilot doubts.
Related Posts
- Part 1 Windows Autopilot FAQ Clarifying the General Misconceptions (This Post)
- Part 2 Windows Autopilot from the perspective of IT Admin setup (Coming Soon)
- Part 3 Windows Autopilot In-Depth Processes from Device Side (Coming Soon)
- Part 4 Coming Soon
Is Autopilot an alternate for OSD?
The answer is NO. Autopilot is not an alternative to OSD; 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.
MDT alone can handle LTI (Lite Touch Installation). 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?
What is Windows Autopilot?
Windows Autopilot is a provisioning method that streamlines device setup (first boot) and provides a customized user experience while 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 is mostly the case, as organizations rarely purchase blank systems nowadays), Autopilot can jumpstart the device provisioning.
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, initially reflecting your organization’s brand.
- You don’t want your users to go through each of the OOBE screens
- Do 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 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 the device setup until all the required policies and applications are implemented on the system.
Windows Autopilot helps you provision devices without an on-premise investment or the local IT team’s involvement in device setup. You can provision this 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 deployment.
Autopilot allows Organizations embracing the cloud movement to reduce their on-premise IT footprint by utilizing Windows’s modern management. This is Windows Autopilot for you.
What is the Windows Autopilot Schema?
A high-level schematic representation of Windows Autopilot is given below.
The Windows Autopilot process, as shown schematically above:
- Procure devices from OEM Vendors/Partners.
- Register the devices to Autopilot service.
- OEM vendors and device partners can register devices on behalf of your organization. In such a case, you must sync the devices to Intune and claim 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 get stuck at the ESP page, resulting in a timeout causing the error?
Yes, this is true and happens not only with Autopilot but also for normal Azure AD join/Hybrid Azure AD join scenarios. This generally happens if you have configured ESP to track all the required applications.
Provisioning depends on network bandwidth and the size of app packages that need to be downloaded, 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.
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.
With Windows 1903, Microsoft introduced Autopilot for the white-glove deployment process. This 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 about – Windows 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 toYes.
NOTE 1—The devices must be registered to DDS within 48 hours of being reset. The machine will then start with Autopilot provisioning.
NOTE 2 – Microsoft has already declared the End of Support for Windows 7.
For organizations that still have a large number of devices running Windows 7 (yes, there are), there is Autopilot for Existing Devices, which is Microsoft’s answer to having 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.
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 cover the concepts and working blocks of Windows Autopilot setup from the IT Admin’s perspective. Until then, read something every day and learn something every day!
Resources
- Step-by-Step Guide Windows AutoPilot Process with Intune
- Beginners Guide Setup Windows AutoPilot Deployment
- Windows Autopilot Video Starter Kit
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com
Thanks for this
Is it possible to request Dell to ship LTSC with their laptops?
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.