Microsoft 365

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.

Onboarding Devices to Windows Autopilot

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.

Hardware ID (Hash)

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.

Manual Onboarding of Devices to Autopilot

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.

Harvest Hardware IDs

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.

  • Log in to the device that you want to onboard to Autopilot.
  • Start a PowerShell prompt with administrator privileges.
  • Run Get-ExecutionPolicy and make a note of the current policy setting. The default setting is Restricted.
  • If the execution policy is anything other than Unrestricted, run the following PowerShell command to change the policy and confirm the change as prompted.

  • Create a directory c:\temp
  • Get the PowerShell script from Microsoft’s website here.
  • Expand FileList and click Get-WindowsAutoPilotInfo.ps1
  • Select the script contents and copy it to the clipboard.
  • Open Notepad and paste the contents of the clipboard.
  • Save the file in c:\temp as Get-WindowsAutoPilotInfo.ps1
  • In the PowerShell window, change the working directory to c:\temp

How to Manually Onboard Devices to Windows Autopilot (Image Credit: Russell Smith)
How to Manually Onboard Devices to Windows Autopilot (Image Credit: Russell Smith)

  • Now run the script and add the -OutputFile parameter as shown below.

  • Open autopilot.csv and you should see a comma-delimited file with three columns: Device Serial Number, Windows Product ID, and Hardware Hash. The latest version of the script doesn’t collect the Windows Product ID. Don’t worry, Autopilot doesn’t need it.
  • Below the headings, you should see your device’s serial number and hardware hash. Close the file.
  • Don’t forget to set the PowerShell execution policy back to Restricted, or to whatever the policy was previously configured on the device, using Set-ExecutionPolicy.
  • Close the PowerShell window.
How to Manually Onboard Devices to Windows Autopilot (Image Credit: Russell Smith)
How to Manually Onboard Devices to Windows Autopilot (Image Credit: Russell Smith)

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.

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register