My Technical Context for the July 2022 Microsoft Tech Community AMA on Autopilot Enrollment - #Iwork4Dell

Part of my job at Dell is providing technical oversight and support to a talented team of field engineers delivering imaging and provisioning related projects, I'm also part of a group that helped to bring Dell's Connected Provisioning services live, and assist with troubleshooting and related escalations.

Among the ways I keep up to date with Microsoft technologies is subscribing to the Microsoft Endpoint Manager Tech Community for any live and past sessions.

The following is my summary and some background technical context for Ask Me Anything (AMA) session on Autopilot Enrollment for July 2022, and most importantly, ways in which my co-workers help in these areas today.

One-Time provisioning limitations will be lifted

In October 2021 devices started receiving error code 0x80180014, aka the One-Time provisioning limit for Self-Deploy and Pre-Provisioning profiles that leverage TPM attestation without a user account. It took some time for the Tech Community article and Known Issues guidance to be published to explain what was happening, but the reasons behind the limit are understandable: an Autopilot registered device is uniquely linked to a tenant, so if the device were ever resold or the motherboard replaced, the next owner could potentially run self-deploy/pre-provisioning against the original owner's tenant and get access to privileged data, or worse introduce an attack vector as a member of the original owner's environment. However, the impact this decision had increased logistical complexity on how devices could be re-provisioned if there was ever an error with Autopilot, which already has many dependencies that need to work right the first time. With the one-time provisioning limit everyone would have to coordinate deleting the Intune device record before self-provisioning/pre-provisioning could be retried. Our team ended up writing a tool that customers can run so they can manage device deletions in bulk when needed, but it's still a bit of a hurdle to work through.

Recently, the Win10 and Win11 preview release notes mentioned:

New!?We restored functionality for Windows Autopilot deployment scenarios that are affected by the security mitigation for hardware reuse. This update removed the one-time use restriction for self-deploying mode (SDM) and pre-provisioning (PP). This update also re-enabled any User Principal Name (UPN) display in user-driven mode (UDM) deployments for approved manufacturers.

The panel addressed this as the very first topic about 1.5mins into the session. Juanita Baptiste also explained a process called "Auto Remediation" as another added feature. This is something I'll be delving into this week as Intune Service Release 2207 goes live. I really appreciate that the limitations lift will be back-ported to all currently supported Windows 10/11 releases.

In the meantime, Juanita does provide more information later in the session on about how Intune will detect motherboard changes, and how unused devices should be deregistered by the original owners before reselling. There's also a recent Tech Community post that starts to explain how the features are coming back, but it's a little light on details for OEM support requirements and remediation steps, stay tuned for that.

UPDATE Preview patch: July 26, 2022—KB5015878 (OS Builds 19042.1865, 19043.1865, and 19044.1865) Preview (microsoft.com)

New!?Restores functionality for Windows Autopilot deployment scenarios that are affected by the security mitigation for hardware reuse. This update removes the one-time use restriction for self-deploying mode (SDM) and pre-provisioning (PP). This update also re-enables any User Principal Name (UPN) display in user-driven mode (UDM) deployments for approved manufacturers.

SCCM Client install during Autopilot for Co-Managed devices

Danny Guillory Jr. was asked around the 3:30 mark to discuss the recent feature that allows customers to install the Configuration Manager Client during Autopilot, including the ability to override co-management policy. One of the features this enables is running a task sequence (hello application install order!) as part of the client installation.

However, these scenarios are only supported for "Cloud Native Endpoints", or Azure AD Joined devices. For the Hybrid join scenarios, Microsoft already documented CM client install during Autopilot is not supported. Part of the issue is the CM client will "own" all management workloads upon install before it initializes and receives the co-management workload policies. This has a major impact as Intune needs to be managing the device during Autopilot free of unmanaged interruptions.

Hybrid Azure AD Joined devices

Joe asked the panel a question about Hybrid Azure AD join, which you see the panel smile about and maybe even squirm a little bit ??.

To be fair, setting up Hybrid Join is fairly complex and introduces additional risk and dependencies through On-premises agents, proper permissions, policy settings, implications with User ESP and the initial user logon to complete the final Hybrid join tasks, it requires a VPN client that can start a tunnel at the lock screen for remote users logging in the first time, it requires a PKI environment and additional configuration to support Windows Hello for Business, and as mentioned previously drops Config Manager support during Autopilot due to design limitations. The list of reasons why everyone should choose Azure AD join vs Hybrid Azure AD join are pretty compelling.

For Hybrid AAD Join what the panel and MS staff responding to questions in the Tech Community site are communicating seems to boil down to is: it's an available option, it's fully supported, it works, but you shouldn't be using it for new device scenarios.

However, for companies with tight deadlines and large legacy debt, overcoming the reasons to stay on Hybrid AAD Join like dependencies on legacy auth applications and mapped drives, lack of MS supported LAPS for Cloud-Native devices (note: Windows 11 has a LAPS feature for Preview Build 25145), or even an expansive list of GPO settings that even though can be migrated with Group Policy Analyzer, may still have inheritance and filtering rules assigned to a variety of OUs that need to be rationalized first - all of this and more will have an impact on deciding to stay with Hybrid AAD Join for new devices, Danny mentioned some of these in his explanation against Hybrid AAD Join.

To be fully cloud-native requires migration efforts, legacy cleanup, possible additional infrastructure (Cloud-management Gateway, etc.), and planning for migrating user and other data but in the end it really helps to get endpoints cloud-native.

Whether it's taking on the challenge to make Hybrid AAD Join work along with existing investments, or helping companies get to cloud native nirvana, all of these are what my co-workers help companies with everyday, regardless if it's a new environment or super complex.

Typical expected time for Autopilot to complete on a device

Juanita answers the question about the timeframe for a device to run through Autopilot in which she stresses simplicity in design by including pre-provisioning, and transition to web-based app in an effort to reduce the risk of failure with long Autopilot workloads.

Another reason for increased simplicity can be explained by a Microsoft comment response to a question about Autopilot performance:

Autopilot is a game changer that allows Windows OS to leverage provisioning features that mobile device platforms have had for a years. Autopilot is complex because it works differently due to its cloud services dependencies. Juanita reiterated pre-provisioning advice when asked again later in the session about Autopilot with endpoints connected to limited internet bandwidth.

Pre-Provisioning is part of Dell's Connected Provisioning services that also includes registration in the factory from a stable dedicated environment and away from on-premises corporate restrictions on internet traffic like proxies, firewalls, network appliances, and bandwidth limitations. Better than all that are pre-provisioned devices can be delivered straight to the user, secure in the knowledge that it's fully managed, ready, and trackable.

Custom Device naming with Autopilot

Device naming is currently limited with Autopilot. Cloud Native endpoints have the most flexibility because you can add a prefix, specific # of random characters and the device serial number. Hybrid Azure AD join devices are just a prefix with everything after being completely randomized. Automating device naming can be done via script post-Autopilot; Cloud Native just needs a computer rename and a reboot, where Hybrid AAD joined devices need line-of-sight to AD because that's where the device identify is sync'd from. However, Juanita makes a great point about the need to challenge the underlying reason for custom device names, especially the more complex ones that spell out user name, department, building, function, region, and any other criteria within the name. There's no easy fix or template to account for all customer scenarios to be built-in to Intune. However, our Delivery Engineers are familiar with these challenges as it's a very common request we get to provide solutions for.

Options for Drivers and Quality updates

Joe asked the panel about options Microsoft may have today to manage driver updates. With Dell devices, driver updates can be managed a few ways: WaaS policy can optionally include drivers with the quality updates OR an OEM tool such as Dell Command | Update, SupportAssist, or Dell Command | Update Catalog can also manage keeping drivers and firmware up to date on a more granular and controlled manner. From Microsoft however, the panel couldn't discuss upcoming plans that are in the works. What I imagine they meant is the upcoming new capability announced at last year's Ignite and being private previewed by some companies. This will allow drivers and firmware to be updated via Intune policies and has multi-OEM support.

For the follow-up question about Quality updates during provisioning, Juanita mentioned a can't-be-announced-yet-but-totally-exciting-upcoming-feature that "everyone will be happy with". I'm really excited to see any news about that ability.

BitLocker with PIN option

Juanita mentioned BitLocker PIN support is not something that's being investigated for implementation. BitLocker is limited with PIN and full disk encryption as well, it only uses "used space only", and while the encryption policy can be enforced during Autopilot, by design BitLocker encryption with protection isn't triggered until the user logs on.

The workaround for BitLocker PIN support is to trigger a prompt to the user on logon and set the desired PIN as an additional Protector via custom scripting. But even before anyone even considers supporting a PIN to begin with, does it make sense from a security standpoint given the risks with user behavior as Joe Lurie posited?

Re-Imaging a device for Autopilot

A question was raised about imaging a device for Autopilot with the latest updates and removing "bloatware" added by OEMs that are common with consumer devices, and having the latest patches embedded. Juanita does mention that getting the latest patches is in the works.

However, allow me to answer the question about a bloat-free image: Dell offers customers Autopilot Registration which can be combined with a Ready Image on the device and Connected Provisioning (pre-provisioning and order related) services. A Ready Image is specifically engineered to work with Autopilot and is free of any additional software. It can also be used by admins to re-image devices.

On the endpoint side, an upcoming capability called Self-Healing Image Recovery will allow Dell's Ready image to be downloaded from the BIOS interface and delivered via the cloud.