Whether you are evaluating Windows Autopilot for the first time, testing out new features and capabilities, or demoing it to new customers, you’re typically going through the same basic steps:
Let’s dig in a little deeper to make sure you understand the intricacies, first with harvesting the hardware hash. I typically do this with these steps:
It’s important to understand the Windows Autopilot behavior for different Windows 10 releases, as those behaviors can cause frustration if you don’t understand them:
OK, so why does that matter? It’s a matter of timing: If the device talks to the Autopilot deployment service *before* it has been defined to Autopilot (before you’ve uploaded the CSV), it will download settings that say “this is not an Autopilot device” – after it’s done that, it will always go through the standard consumer OOBE flow, not the Autopilot process.
Think about what would happen on Windows 10 1803 if you had a VM with an Ethernet connection, and you booted it up to harvest the hash. Even before you grabbed the CSV, the OS would already have received the “this is not an Autopilot device” setting. And if you had a wireless device and continued forward to establish a Wi-fi connection (e.g. so that you could install the Get-WindowsAutopilotInfo script from the internet), the same thing would happen.
So how do you get Windows to “forget” this “not an Autopilot device” setting? As the documentation indicates, you can reimage the device, run “sysprep /generalize /oobe” (generalize is a requirement), or boot all the way into the OS and then initiate a reset (from the Windows Update recovery page). Those work great, but take a while. So we enabled another way in Windows 10 1809: If you reboot the device, it will re-download the Autopilot settings when it boots back up. So this process will now work on Windows 10 1809 or above:
I do typically take a slightly different approach with virtual machines because I like to reuse them without rebuilding, reimaging, or resetting them, leveraging checkpoints. Here are the steps I typically use:
Once you’ve gone through those steps, you can revert back to the original “Start of OOBE” checkpoint, knowing that it will remember nothing (never connected to the network at that point). So what happens if you click through OOBE and don’t remember to again connect the network adapter? No problem, it will prompt you to insert the (virtual) Ethernet cable to continue. (That’s a good point to mention that a device with a wireless adapter would ask you to make a Wi-fi connection at that point.) After you do that, the OS will download the Autopilot profile, and the process should continue from there.
You shouldn’t assign Autopilot profiles to individual devices – that’s not a particularly scalable solution. So it’s best to get in the practice of doing this via Azure AD groups, assigning the Autopilot profile to the group so that Intune takes care of assigning the Autopilot profile to all the members of the group. You can do this with Azure AD dynamic groups, static Azure AD device groups, or a combination of the two. My preferred mechanism:
Since your environment may differ, adjust accordingly.
Generally it’s fine to use the same enrollment status page configuration for all scenarios, so it’s easy to stick with assigning those settings to the All Devices virtual group. Note that you can now specify what apps you want to wait on .
Provisioning a Windows device using Autopilot isn’t particularly interesting if you don’t also deliver settings and apps to the device. I would suggest a few Win32 apps , Office 365 ProPlus, and the ConfigMgr client (if you want co-management). It’s also useful to target some settings, like custom BitLocker settings (configuring XTS-AES-256 should work well with Windows 10 1809, even for non-admins), and automatically configuring OneDrive for Business (coming soon via ADMX-backed policies, but until then check out this blog for how to do it with custom OMA-URIs).
It’s one thing to talk about it, it’s another to see it. Once things are working reliably, have someone who has never done it before walk through the experience, ideally with a physical device. Hand them a box with the device in it, along with a simple set of step-by-step instructions (no more than half a page):
They can then watch the deployment progress (ideally projected for everyone else in the room to see) while discussing the scenario and asking questions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.