Windows Autopilot is a collection of technologies that allows organizations to simplify deployment and setup of Windows 10. First introduced in the Windows 10 Fall Creators Update, Autopilot lets organizations ship devices directly to users and have all the necessary security policies, networking profiles, and applications installed without IT needing to touch the hardware. Additionally, Autopilot can reprovision devices should they need to be reset or passed on to other users.
Since its initial launch, Autopilot has seen some improvements like the enrollment status page, which shows device status so users can understand whether it’s ready to use. Organizations can also prevent users logging in until a device has been fully provisioned. Integration with Azure Active Directory dynamic groups, self-deploying mode, and white-glove provisioning are all features added to provide more flexibility and value.
For more information on Windows Autopilot, see New Windows Autopilot Deployment Options in Windows 10 1803 and Redstone 5 and Get Users Working Faster with Windows 10 Autopilot White Glove Provisioning on Petri.
Let me start by saying that Microsoft doesn’t want you to manually onboard your Windows 10 devices. That’s not how Autopilot is supposed to work. If you buy devices directly from an OEM, you provide consent for them to directly register devices in your Azure AD tenant. You can find a list of OEMs that support Windows Autopilot on Microsoft’s website here.
If you buy devices from a reseller, distributor, or Microsoft Partner that is part of the Cloud Solution Partners (CSP) program, they are also able to register devices for Windows Autopilot. And as with OEMs, an Azure AD Global Administrator needs to provide consent before partners can register devices with Windows Autopilot.
For organizations that have already purchased devices and that would still like to use Windows Autopilot, it is possible to automatically onboard PCs running Windows 10 version 1703 or later and that are already enrolled in a Mobile Device Management (MDM) service like Microsoft Intune.
Windows Autopilot needs a device’s hardware ID, or hash as it’s sometimes referred, before it can be onboarded. The hash is generated using information about the hardware, like manufacturer, model, device serial number etc. If the hardware changes substantially, the hardware hash also changes. MDM services can retrieve the hash from Windows and then automatically onboard devices to Autopilot if a deployment profile exists.
If Microsoft doesn’t want you to manually onboard devices to Autopilot, in what scenarios might you need to go the manual route? If you have existing devices that aren’t enrolled in an MDM service, then manual onboarding is an option. Or if you are buying devices from OEMs or partners that don’t support Autopilot, then you will need to harvest the hardware hashes and onboard the devices yourself.
For the purposes of this demonstration, I will use Microsoft 365 Business, which includes Intune and Windows Autopilot; and I will onboard a device running Windows 10 version 1909.
The first step is to retrieve the device hardware hash. Microsoft advises that devices shouldn’t be connected to the Internet until you have successfully captured hardware IDs, uploaded the IDs to Autopilot, and assigned a profile. If a device is connected to the Internet before onboarding, a blank profile is downloaded and will remain until it is removed by resetting the device using OOBE setup.
To get a hardware ID from a device, Microsoft provides a PowerShell script which can be run locally or against remote machines. Let’s run the script to get the hardware ID.
.\Get-WindowsAutoPilotInfo.ps1 -OutputFile c:\temp\autopilot.csv
That’s most of the hard work done. In the second and final part of this article, I will show you how to upload the CSV file to Microsoft, create and assign an Autopilot profile to the device, connect Windows 10 to Azure Active Directory, and confirm Intune enrolment.