Keith Doolan

Autopilot is Microsoft’s ‘zero-touch’ endpoint deployment tool for Windows 10/11 and HoloLens devices; I’m not going to delve into what Autopilot does, you’ve found my blog, so I’ll assume you have experience with Autopilot or at least know what it does. If you want to know more, please follow the link: Overview of Windows Autopilot | Microsoft Learn 

There are three ‘common’ Autopilot provisioning modes, User-driven deployment mode, Self-deploying mode and pre-provisioned deployment mode, which is also called the ‘white glove experience’. Before choosing a deployment mode, we must first understand the environment, which in most cases is a hybrid environment (On-prem AD with group policies applied locally). A hybrid environment dictates the deployment mode as Microsoft doesn’t recommend the Pre-provisioned deployment mode for new devices that you want to hybrid join to a domain. This doesn’t mean you can’t; you can with a caveat, the caveat is additional complexity, and you should expect technical issues to arise.  

Self-deploying mode  

Does what it says on the tin, primarily used for Kiosk devices with no primary user assignment. My opinion, it’s not utilized much because the service desk or helpdesk who provision devices tend to stick to one deployment method out of convenience. The self-deploying mode does not hybrid join a device therefore an MDM solution is required to manage it.  

Pre-provisioned deployment mode (White Glove) 

This mode is when the device is partially enrolled with device context apps installed first; domain joined then packaged by IT and sent to the end-user. The end-user then finishes the enrollment process by signing into the device with their credentials. At this point, user-context apps and policies are applied.  

I call this mode the ‘Off Branch User-Driven Deployment Mode’ because this deployment mode won’t work without the User-driven deployment mode configured correctly. I know, it’s confusing, right? I recently deployed Autopilot for a large Government organization, and it was impossible to explain this without illustrating it in a process flow diagram.   

Green arrows = Pre-provisioned deployment mode 
Red arrows = User-driven deployment mode   

User-driven deployment mode 

I intentionally left the User-driven mode to the end because, well, hear me out. *Deep Breath* ‘Employers don’t want their non-IT employees driving the Autopilot deployment!’ When speaking with clients, they want to keep everything as it was before but speed up the device provisioning process for the IT Team. IT do all the work in the background and hand over the device to the end-user; the end-user signs in with their credentials and away they go. Yes, there are use cases like when an employee is fully remote, but even then, employers want the device configured, domain joined, checked over and then shipped to the employee. Employers don’t want their employees clicking through the enrolment status page (ESP), they want them to simply sign into their device like everyone else. In my experience, the Pre-provision deployment mode (white glove experience) is generally used when there’s a delay in the employee onboarding process or there’s a surplus of devices in stock that the IT Team want to partially provision before a user account is assigned to the device.  

My Opinion 

*Deep Breath* ‘Remove the Pre-provisioned deployment mode’. This mode is only necessary when there’s no Intune licensed user assigned to the device. IT Teams are already using their own accounts to complete the Autopilot user-driven deployment process, because it’s convenient for them. When this occurs the IT Admin changes the primary user and management name on the device properties page in Intune.

 To simplify this process, Microsoft could introduce an Autopilot Deployment Manager like they introduced the Intune Device Enrolment Manager (DEM) to solve enrolment difficulties for unlicensed users/devices.