Part 1 – Understanding Autopilot Methods

Introduction

When we think of any kind of device provisioning and the full automation of deploying a managed device to be setup from beginning to end, and especially when we are wanting to have the notion of transitioning into a move from on-premise into Intune, we think of the process which we call Autopilot.

It’s very easy to get into Autopilot but what scenario or what requirements actually suit you? Many organizations have different interpretations for what we feel is “device ready” and “user ready” and many terms to describe a certain stage where that managed device is ready to be provided to an end user (or no end user). We want to not only fully investigate all of the options we have but we also want to know which avenue best suits us. So here we have a new series which is going to cover them and understand the core reasons as to why those options are perhaps more applicable than others.

What options do we have

Option 1 – Autopilot (No White Glove)

Perhaps the most convenient option to go down. This is where we want to simply put a device through the process of going through its company standard policies, software and domain memberships in which a specific user is then allocated to the device. A lot of the beauty of Autopilot primarily comes from this, where we can actually assign a user to a device very similar to how you would see a CMDB process of assigning a CI etc.

A personalized login and being aware of its allocation is very important to a lot of organizations for the overall setup. Now I must say that this process doesn’t mean that this cannot be done in the white glove option. You can absolutely do the exact same thing in either one. This option just allows the OOBE (out of box experience) to be taken through by the end user once they enter in their email address from the custom brand they would receive from the branding settings within their Intune tenancy.

Option 2 – Autopilot (White Glove)

This is the same process as the one above, however the fundamental difference is how the actual Autopilot profile itself is brought down and accessed. In order to kick it off once you go through the OOBE process where you are provided the languages, you have to hit the shift key 5 times in where you would be provided three options to select the Autopilot Profile provisioning.

Now the essence of this route is that where option 1 will allow the end user to go through the motions of the device preparing and building its policies in front of them, this option allows you to pre-stage everything out of the way.

The benefits of this option is that the average Autopilot process can take from 30 minutes up to maybe a few hours (yes I’ve really seen this 🙂 ) and that can have an impact on the overall end user experience as well as productivity. This scenario isn’t just down to a lengthy Autopilot profile or enrollment page, it can be just necessary policies which need to apply etc. So having a device already gone through this process, a device can essentially be handed to a user whether they’ve been assigned or not and really just hit the ground running.

Why not just go with White Glove all the time if its convenient?

Not every decision should just be driven by convenience. There are many factors you may want to consider before making a decision on either option. There is no right or wrong answer as to which way you should go, but this series will try to explore its pros and cons over each side so you have an un-biased understanding of everything. Below are just a few highlights as to why someone may not want to go this route:

Administrative Effort

Whilst having a device ready to go to give to a user, it doesn’t go without its administrative effort. Someone has to essentially kick off that Autopilot provisioning stage before we can even get it to that level. A potential lengthy process could be offloaded to staff in which we perhaps recreate a build-room scenario which some may be wanting to move away from.

OS Requirement for White Glove

Prerequisites such as the Windows 10 level must be on at least 1903 before you can even see that option listed after hitting the windows key 5x. Anything lower than this and you will only get two options with the Autopilot Provisioning missing. So you would need to check across your estate if enrolling devices which already exist (if not converted to autopilot already) so that they are indeed eligible for this.

TPM Requirements

Do your due diligence on hardware requirements and BIOS level where the device has to support TPM 2.0 and ensure that it is enabled, or you may have issues with an Autopilot provisioning profile not wanting to apply. This can cause errors which will leave your device in a not-so-good position.

Categories of Interest for formulating a decision

Throughout the series there will be many parts. I’ve listed a few bullet points which will be categories that can help give context to the decision that you will make. This applies to provision devices in your overall modern endpoint management design.

• Purpose of Autopilot Profile – How our profile is configured
• User Experience – How do we want the end user to experience the process
• Time frame of Device/User Readiness – Examining the duration of the whole process to get to readiness
• Third Party Options – Exploration of how third party vendors come into play
• Active Directory (Azure AD or Hybrid) – Looking through the different types of AD setups and its influence.
• Security – Impact of policies from Endpoint Security, anti-virus/malware and security structure.

Next on Part 2

The next part of this series will focus on the purpose of the Autopilot profile so that we can understand the core goal of what we are trying to achieve. This will help formulate a plan of attack and it will be more beneficial in our Autopilot journey.

In the meantime, if you’re facing challenges or have questions in this area, reach out to our experts via email or phone!