Partager via

Evaluating/Testing/Demoing modern deployment with Windows Autopilot

  • Article

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:

Harvesting and Registering

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:

  • Boot up the device to the beginning of OOBE.
  • Press Shift-F10 to open a command prompt.
  • Run the Get-WindowsAutopilotInfo script (start PowerShell, set the execution policy to bypass, install the script or get it from somewhere [USB, network]) and copy off the resulting CSV file.
  • Exit from the command prompt.
  • Register the device with Windows Autopilot via Intune.

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:

  • With Windows 10 1703 and 1709, you can boot a machine up and be assured that it won’t try to talk to the Autopilot deployment service until you get further into OOBE, to the network connection screen (if wireless – if you have a wired Ethernet connection, you won’t see that screen, but rest assured Autopilot won’t talk until you get past where the screen would have been).
  • With Windows 10 1803 and above, the OS will try to talk to the Autopilot deployment service as soon as it can.  If you have a wired connection, that means within seconds of OOBE starting (as soon as it has an IP address).  If you are using wireless, then the behavior will be the same as the earlier Windows 10 releases.

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:

  • Boot up the device to the beginning of OOBE.
  • Press Shift-F10 to open a command prompt.
  • Run the Get-WindowsAutopilotInfo script to get the CSV file.
  • Register the device through Intune, make sure it is in a group with a profile assigned (if using a dynamic group, wait for AAD to update the membership), and that the profile is assigned (done automatically by Intune in the background).
  • Back at the command prompt, run “shutdown.exe /r /t0” to reboot the computer, knowing that it will now download the Autopilot profile again when booting up.  (Make sure that there is a profile assigned before rebooting, looking at the Autopilot devices list in Intune to confirm.)

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:

  • Create a new VM using a Windows 10 VHD (you can create a VHD/VHDX using the Convert-WindowsImage script on the PowerShell gallery.
  • Configure it for standard (not production) checkpoints.
  • Do not connect any network to the Ethernet adapter (purposely leave it “not connected”).
  • Boot the device to the beginning of OOBE.
  • Create a checkpoint, e.g. “Start of OOBE.”  This is a convenient point to revert back to later.
  • Connect the Ethernet adapter.
  • Complete the hardware hash harvesting steps above (Shift-F10, Get-WindowsAutopilotInfo, upload to Intune, make sure it is in a group and an Autopilot profile is assigned).

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.

Azure AD groups and Autopilot profiles

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:

  • Create an “All Autopilot Devices” group that selects all Autopilot devices (see the blog I wrote on that topic), using a dynamic query like “(device.devicePhysicalIDs -any _ -contains "[ZTDId]").
  • Create groups for any “exceptions” where you would want devices to have a different Autopilot profile.  For example, I typically use a “User-Driven Azure AD admin” profile for most demos, but I also demo self-deploying devices and Hybrid Azure AD Join, so I end up with three groups:
    • All Autopilot Devices (dynamic, with the query above)
    • Self Deploying Devices (static, devices are added manually through Azure AD after adding them to Autopilot – remember, importing a device into Autopilot causes an Azure AD object to be automatically be created for the device)
    • Hybrid Azure AD Join Devices (static group, like above)
  • Assign the three profiles to the appropriate groups, excluding the other groups as needed:
    • “User Driven Azure AD admin” profile, assigned to the “All Autopilot Devices” group with “Self Deploying Devices” and “Hybrid Azure AD Join Devices” excluded
    • “Self Deploying AAD admin” profile, assigned to the “Self Deploying Devices” group
    • “User Driven Hybrid Azure AD Join admin” profile, assigned to the “Hybrid Azure AD Join Devices” group

Since your environment may differ, adjust accordingly.

Enrollment status page

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.

Make it do something useful

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).

Have your IT manager or customer walk through it themselves

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):

  • Open the box
  • Plug the device in and turn it on
  • Choose a language, locale, and keyboard, then connect to a Wi-fi network
  • Type in your e-mail address and password (provided in the instructions if it’s not their own account)

They can then watch the deployment progress (ideally projected for everyone else in the room to see) while discussing the scenario and asking questions.

Comments

  • Anonymous
    December 19, 2018
    The comment has been removed
  • Anonymous
    December 20, 2018
    If we have existing VM's where we did not create the checkpoint as you describe can we disconnect the network, run reset in windows and then take the snapshot or would it be more wise to just create new VM's and start over?
    • Anonymous
      December 30, 2018
      It's probably quicker to create a new VM, but either method should work.
  • Anonymous
    December 23, 2018
    I don't understand, the device is member of the All Autopilot (ztdid) group and member of Self Deploy group. You only assign Self Deploy profile to the Self Deploy group but the device is also member of the All Autopilot group. So technically the device get's 2 profiles.
  • Anonymous
    December 23, 2018
    If the device is automatically added to dynamic group how it is possible to remove it from it while still register to Autopilot so it can be added to an exceptions group.
  • Anonymous
    January 07, 2019
    I'm trying to use Hybrid Azure AD Join with Autopilot. I assigned "All Autopilot Devices" to the Domain Join profile and I am verifying with Hyper V virtual machine. In the Insider Preview version before 1809, it worked normally, but when I tried with Windows 10 1809, the Autopilot device can not be assigned properly to the Domain Join profile. Before trying this, I have activated the Security Baseline. Is this problem related to the Security Baseline?