Windows AutoPilot Scenarios: Native Approach (Part 1)

Windows AutoPilot is a relatively new OS deployment scenario offered by Microsoft, typically used in conjunction with Intune. While it’s nice that Microsoft continues to come up with new ways to bridge the gaps between the cloud and on-premises environments, it nonetheless remains true that there’s no “one size fits all” model when it comes to device provisioning, imaging and deployment processes.

As such, it’s important to understand exactly what the AutoPilot scenario is, how it fits in relation to other deployment models, and when it’s a viable option. We’ll cover such topics herein so that you’ll be in a better position to leverage AutoPilot, Intune and/or other features of System Center Configuration Manager (SCCM) in the most effective ways – and at the right time.


Native AutoPilot

Let’s start off with a review of the AutoPilot service in its base form, without any supplements. It can be found by visiting the Microsoft Store for Business (under Manage, Devices) or in the Azure Intune Portal (Under Device Enrollment, Windows Enrollment). You need to sign-in with a Global Admin account for your Office 365/Azure tenant, or have been delegated the necessary access rights. Here is where you can import devices and define profiles for them.

Native autopilot screen.


Devices need to be registered with the AutoPilot service in advance of their first boot-up, using a unique identifier known as a hardware hash. OEMs can be engaged to do this on your behalf if ordering a batch of new devices in bulk. MSFT, Lenovo, HP, Dell, Panasonic, and Toshiba are all slated to begin offering the AutoPilot service throughout 2018.

The other option is to “do IT yourself” if you already have an existing set of machines which you want to re-provision. A script to put the necessary information into a CSV can be found here on the PowerShell Gallery repository. Upload this CSV using the Azure Portal or Store for Business.

#Gather a computer's AutoPilot info:
Set-Location -Path C:\Sources
Save-Script -Name Get-WindowsAutoPilotInfo -Path .\
Install-Script -Name Get-WindowsAutoPilotInfo
.\Get-WindowsAutoPilotInfo.ps1 -ComputerName 'LOCALHOST' -OutputFile .\MyComputer.csv -Append
Import-Csv -Path .\MyComputer.csv

If you already have the machine running on your network, you can simply run the script at any time to collect the data. Starting with SCCM build 1706, you now have the ability to create and run PowerShell scripts from the Configuration Manager console.

Scripts screen.
And if you have SCCM build 1802, there is a report which contains the same information in bulk, gathered from the devices in your site. The data could then be pre-staged into AutoPilot, ready for use the next time a given machine is reimaged or factory reset.

AutoPilot screen.


Or, if the machine is brand new, fresh out of the box, another trick you can do is to launch Windows into Audit Mode by pressing CTRL+SHIFT+F3 during OOBE – before you ever log in to the machine. The place to do this would be when you reach the screen below, where it asks, “Let’s start with region.” Also, be aware: the script can’t run in WinPE because it doesn’t include the needed WMI classes in a default boot image.

Let's start with a region screen.


Now that you’ve got your data all set, you’re ready to deploy! AutoPilot only engages during the Out-of-Box Experience (OOBE) on Windows 10 devices running build 1703 and later. This is the phase of setup that runs immediately after powering on a new computer for the first time – before the initial login. It is recommended to use the latest build of Windows 10, in order to leverage the newest AutoPilot features.

You must be online, either wired or wireless, for AutoPilot to engage. If you’re wired in with an Ethernet cable, OOBE may skip this page altogether; if you’re on Wi-Fi, it will prompt you to connect to an SSID and enter the passphrase. This “Network” step is the moment that Windows reaches out to the AutoPilot service to see if the device has already been registered to your cloud tenant. If it has been, the service silently takes over the rest of OOBE.

Let's connect to a network screen.


You’ll be brought to a page that reflects your company branding. Sign in with your corporate cloud account. You may also be taken to the company’s ADFS authentication page, or be prompted for MFA.

Sign in with Contosomn.onmicrosoft.com screen.


That’s it! Once you hit your desktop, you’ll be ready to work. That’s the baseline “native” AutoPilot experience. This scenario is a good fit for BYOD and for remote users who don’t come into the office often. Note that the device will be cloud-joined to Azure AD, but not to the corporate on-premises AD.


Intune Integration

AutoPilot’s primary function is to take a machine and enroll it into Azure AD and that’s about it. The real magic starts to happen when automatic Mobile Device Management (MDM) registration takes over to get the device enrolled into Intune. Without Intune, if you just take the device image as shipped to you by the OEM, it will have all the drivers it needs to function, but the rest of the software will be stock configuration, and therefore lacking some rather important things that we’ve come to rely upon in the world of IT management and Operating System Deployment (OSD). By itself, AutoPilot doesn’t have:

  • Ability to name the computer at provisioning time
  • Ability to push apps to the computer at provisioning time
  • Ability to run custom scripts or configurations

Which is why you’re really going to want to add an Intune subscription to accommodate things like this. For even more command & control, think about Enterprise Mobility + Security (EMS) while you’re at it. EMS/Intune and AutoPilot are truly better together. For example, Group Policy Objects (GPOs) have long been the staple for enforcing settings upon client computers in AD domains. The cloud-based transition from that in Intune is Device Configuration Profiles, which can be used in conjunction with other Azure/O365 features to compensate for (and eventually replace) GPOs. True, these mechanisms have not yet achieved parity, and IT staff may need to be re-trained on how to do things the “new way”, but many of the more prominent items are already in place, plus more are coming every quarter.


Upcoming Features in windows autopilot

While lesser-structured IT environments might not miss the above things, they can certainly be show stoppers for more complex organizations. Given that AutoPilot is still very much an early-stage product, there’s a lot of good things just over the horizon. Recent webcasts indicate at least some of these features are slated for release later this year. And since the product is undergoing rapid development, additional bells and whistles will doubtless continue to come online as it matures.

Other features (hopefully) coming down the line soon:

  • Ability to join an on-premises AD domain (it can already join Azure AD)
  • Ability to escrow BitLocker keys to Azure AD
  • Ability to apply Provisioning Packages over-the-air during OOBE
  • Ability to Plug & Forget (unattended setup profile for conference rooms or public spaces)

One nice cosmetic enhancement now available in the 1803 build of Windows 10 is the Enrollment Status page. Sometimes a device is not 100% ready to use at the first login; the user may have to wait a bit for software to come down from the cloud and install. Enrollment Status lets them know their stuff is on its way. Check out Windows Autopilot: What’s New and What’s Next for more upcoming goodies like this.

And stay tuned for Part 2, in which we’ll cover some other fancy ways by which one might further the use of AutoPilot and thereby increase its utility factor.