DeployR loves Windows Autopilot

It’s interesting that Windows Autopilot is seen as a replacement for bare metal imaging solutions.  In reality, the two are complementary.  Sure, there are great use cases for using an OS images preloaded on computers by the OEMs (whether that’s a standard OEM image, a paid OEM “cleaner” image option, or a paid “custom” image option), but there are plenty of times where you still want or need a bare metal imaging solution:

• Hardware failures.  If a hard drive fails and is replaced (or with some OEMs, when a motherboard is replaced), you need a mechanism to get an OS back onto the computer.
• Malware infestations.  If something infects the computer, you can no longer trust what is on the device; it needs to be wiped clean and start over.
• Break/fix.  Perhaps doing an OS reset is fine in many situations, but it’s not a fast process and is not always reliable either – assuming customers do everything right (e.g. getting the right drivers injected into Windows RE) it can still fail and require reimaging to fix.
• You don’t like or can’t use the OS that ships on the device.  This could be unwanted “bloatware” (there’s not a consensus of what constitutes bloatware; in some cases, it could be things like OEM utilities), the OEM shipping newer versions of Windows 11 than what you are using (e.g. they ship 25H2 before you’re ready for it), the device having a different SKU than what you want (e.g. ships with Home and you need Education, or with Pro and you want Enterprise LTSC), incorrect preloaded language packs, etc.

So, at the end of the day there are plenty of scenarios (some forced, some by choice) where you start off with a bare metal deployment and then want to finish with Windows Autopilot for the final provisioning steps in the new OS.  We’ve talked with lots of customers over the years who are doing exactly this (some with MDT who are now looking for a good replacement, some with ConfigMgr who don’t want to keep it around just for OSD after they’ve moved all the other device management workloads to the cloud).

So how exactly can we help with preparing a device for Windows Autopilot?  Well, first of all we can use a task sequence that deploys an OS image and drivers (potentially from the cloud) and then completes while still in Windows PE, without using an unattend.xml answer file.  In this case, the device will boot to OOBE and go through the normal Windows Autopilot flow.

What if you are using Windows Autopilot (v1 or v2) and need to register the device?  We can do that too, and most importantly do it securely.  If we add an additional step to the task sequence, we can see the available options:

Notice that we’re doing registration for Autopilot v2 in this case, which means creating a corporate device identifier, and this is being done while still in Windows PE (easy enough, since the manufacturer, model, and serial number are all that’s required for this).  How does this know what tenant and how does it authenticate with Entra ID?  Those details are kept securely on the DeployR server; the client asks the DeployR server to do this on its behalf.  That’s really the only safe way to do this – passing app IDs, app secrets, app certs, etc. around the network is dangerous because they will leak, and those app IDs need a lot of rights to do the necessary registration tasks.

While this still means you need an app ID and a certificate to secure it, those details never leave the DeployR server:

What about Windows Autopilot v1?  Well, that gets a little more interesting, but only because it can’t be done while in Windows PE.  In order to get the needed hardware details to get a good hardware hash from the device, it needs to boot into the new OS.  We can do that using Audit mode:

In this case, we specify that we want to register with Windows Autopilot v1, and let you specify (optionally) both a group tag and an Entra ID group name.  So we can then grab the hardware hash and pass it to the DeployR server.  It can then add the device to Autopilot with any specified group tag, add it to the specified Entra ID group, and then wait until the device has an Autopilot profile applied.  That can take a while, usually less than 15 minutes, but the task sequence won’t continue until it’s done.

Notice that we can also take advantage of the fact that we’re already in the full OS to do some customizations.  In this case, we chose to install eight apps (using the same .intunewin files that were used in Intune, described in my previous blog about DeployR apps).  Once the task sequence completes while in Audit mode, the computer will then reboot to OOBE (or you could tell the device to shut down) and would continue then with a normal Autopilot v1 enrollment and provisioning process.

Combine that with the "Disable Shift-F10" and “Require Internet” options mentioned in the DeployR operating systems post and you have a reasonably secure way to provision the device.  And for the end user, the process will be quick because the apps are already there; Intune can detect that and not download them again.

We have talked with customers who do a bare metal deployment, followed by Autopilot v1 pre-provisioning, followed by a user-driven Windows Autopilot deployment.  There is a better way, leveraging a task sequence that automates the first two pieces – DeployR can take care of that for you.  Also, if you want to do pre-provisioning with Autopilot v2, the task sequence shown above can do that too.

We can do Entra ID join separately too

Separately from Windows Autopilot, we can also do an Entra ID join using a “Join Entra ID” step.  This leverages a provisioning package (PPKG) that contains the bulk join details needed for that.  The Entra ID join will also cause an automatic MDM enrollment into Intune, to ensure that the device is managed.  But it would result in the device effectively being a shared device since there would be no primary user assigned.  To help with that, we have another “Set Intune device owner” step that allows you to specify the user’s UPN (which can be overridden via a task sequence variable):

The “Join Entra ID” step runs in Windows PE to inject the PPKG offline into the new OS, so it gets processed automatically when the OS boots for the first time.

There is one manual step that needs to be performed on the DeployR server to generate the PPKG file.  We provide a simple PowerShell script that uses Dr. Nestori Syynimaa’s (@DrAzureAD) AADInternals module to easily generate the bulk enrollment token (since the Configuration Designer tool provided by Microsoft via the ADK or the Microsoft Store tends to be flaky and fails often).  This token is only good for 180 days, so you have to repeat this process a couple of times per year, and there’s no way to avoid sending the resulting PPKG file to the device itself (there is no “offline domain join for Entra ID” process that can avoid that), so it is slightly less secure than the Windows Autopilot flows where it’s the user authenticating with Entra ID and Intune – while DeployR keeps the PPKG file secure, it can’t prevent the file from being swiped from a computer that is being deployed (e.g. grab it when the computer is rebooting from Windows PE to the new OS).