Next Generation Windows Provisioning with Autopilot and Autopilot v2 ("Autopilot Device Preparation")

Windows Autopilot, initially launched in 2017, has recently undergone a significant overhaul to enhance its existing capabilities. This update aims to provide organizations with additional options, enabling user-driven provisioning for Windows devices.

The naming conventions are slightly confusing so let's get that out of the way:

• Windows Autopilot - This is the current Autopilot process where device hardware is registered with your tenant ahead of time which unlocks user driven provisioning, applying Intune policies and apps based on current assignments.

• (NEW V2) Autopilot Device Preparation - User driven provisioning of Windows devices that uses device-based just in time group membership. Devices do not need to be pre-registered ahead of time which simplifies the process.

What is Autopilot Device Preparation and what is different from that old Autopilot?

Windows Autopilot, The original

Windows Autopilot is a solution provided by Microsoft to streamline the process of setting up Windows devices for users. Previously, provisioning a new Windows devices for end users involved a complex setup process, including creating a master image of Windows, managing device drivers, setting up network PXE booting, packaging applications, and pre-staging user profiles. This process often required provisioning devices at specific locations and shipping them to remote offices or users' home offices.

Autopilot streamlines the process by enabling the vanilla installation of Windows, which comes pre-installed by the manufacturer, to be used out of the box. This allows users to sign in through a wizard-driven experience using their user ID and password, set up Multi-Factor Authentication (MFA) if required, and enroll their device.

Autopilot Device Preparation, The new guy

Under the hood, the new v2 Autopilot Device preparation is a “re-architecture” of Windows Autopilot. The user experience for admins and end users will seem similar but the underlying technology will be different. The expectation is that these changes will allow for faster development cycles for new features and bug squashing.

Autopilot Device Preparation leverages an Entra ID device group that contains devices that are assigned by the service once the Autopilot process has kicked off. By using that assigned group (as opposed to query-based dynamic groups), it expedites the process by bypassing the need to wait for dynamic groups to get updated.

Another benefit is that DoD and GCC high tenants can take advantage of this feature today assuming devices are configured as cloud native and not domain joined.

Side by Side Implementation

In its current iteration, Autopilot Device Preparation can co-exist and supplement your company's existing Autopilot configurations that are in place today. Devices that are currently enrolled in the Autopilot service the old way, will continue to get their Autopilot deployments the same way as before. Devices that do not have their hardware bound to your tenants Autopilot service with an Autopilot profile deployed can be easily provisioned with Autopilot Device Prep.

To rollout Autopilot Device Preparation, some changes should be made in your Intune tenant on what policies and applications are assigned to users vs devices. During the provisioning process, only device-based policies are applied so anything that must be done before the user can see the desktop should be applied to device-based targeting (as opposed to user based). User-based policies will be applied after Autopilot is complete and the user is presented with the desktop.

Autopilot Device Preparation Limitations and Feature parity

A few key differences exist in the product as it currently stands, since Autopilot Device Preparation is relatively new and has not yet reached full capability parity.

• No option for automatic device naming: For devices provisioned by Autopilot Device Preparation, hostnames will be user chosen at the start of the Windows “Out of Box Experience”. The usefulness of a programmatically named hostname is becoming less and less important but this is a key feature that most enterprises expect at some level today.

• No option for hybrid join (maybe EVER?): It’s no secret that Microsoft considers on-premises domain join a “legacy” configuration. In the real world, this is not a viable solution for all enterprises. The old Autopilot can do hybrid join but it can be an adventure getting it to work (especially if a VPN is involved for remote users). Autopilot Device Prep doesn’t give you that option. It's Entra ID or bust.

• No option to pre-provision devices or do self-deploying for shared PC’s (yet 😉). Autopilot pre-provisioning allows for apps and configurations to be pre-staged allowing for an even faster Autopilot process. As of now, Autopilot Device Prep doesn’t support it. Shared devices and kiosks use Autopilot self-deploying mode. Today Autopilot Device Prep only allows for user-driven provisioning so shared devices will have to be configured the old way.

• Limited to 10 applications during provisioning: Currently, Device Prep only allows for 10 apps to be included in the wizard driven provisioning. Microsoft mentioned in their documentation that “90% of all Autopilot deployments are deployed with 10 or less fewer apps”. My takeaway is that essential apps can go here and that anything extra should be user targeted for deployment once the user gets to their desktop. Link

• Slightly different onboarding experience. The menus presented to the end users are different than the standard Autopilot and we don’t have the same options to hide menus if we don’t want to give users a choice, for example give the PC a hostname or select telemetry options.

Security Considerations for Autopilot Device Preparation

Autopilot Device Preparation changes the way that devices are onboarded and potentially allows for anyone to enroll a device without IT involvement. Pay careful attention to how the process works and make sure there are no surprises!!

Conditional Access policies can be used to limit access to company resources by requiring a compliant device to grant access to Microsoft 365 data. A compliant device requires that a device is enrolled in Intune and passes administrator defined security to be present (example: BitLocker and Windows Defender). For this reason, safeguarding the provisioning process is crucial to prevent unauthorized access to a device by individuals outside the organization, potentially using stolen credentials.

There are a few ways to minimize exposure and allow for the flexible device provisioning process this feature brings:

• Deploy Security Policies to Device Groups: Make sure important security policies are applied to device groups, including the Autopilot Device Preparation group, to make sure they are applied during device onboarding. User-based policies will apply later but we want to make sure security policies are there before the user has access to their desktop.

• Limit enrollment to “Corporate Device Identifiers”: This will allow for device serial number and manufacturer to be pre-staged ahead of time. This will only allow for approved devices to be enrolled to limit potentially rogue devices.

• Enable Device Onboarding Notifications: This nifty feature emails the end user if their user account is used to onboard a device in Intune. The email notification gives a link to click if they don’t recognize the device that was provisioned.

• Scope Assignment to specific users: Limit device provisioning to users that need the ability to enroll their devices. Make sure that these policies are targeted to in-scope users and not “All Users” that might include accounts that should not need to use Autopilot.

• Require MFA for device enrollment: Entra ID can be configured to require MFA to perform Entra ID join. This can be enabled in the Entra ID portal under the devices blade or through Conditional Access (recommended). Just make sure you account for all scenarios including company provided mobile phones that might not have the Authenticator app configured during onboarding.

Final Thoughts

Autopilot Device Preparation serves as a valuable addition to a feature set designed to streamline the device provisioning process. It offers a convenient method to simplify device onboarding, particularly useful for scenarios such as disaster recovery, large hardware refreshes, or rapid enrollment of unmanaged devices with minimal IT intervention. I’m optimistic that we will quickly bridge the feature parity gap, thanks to the changes made to the underlying technology.