Part 2 – Purpose of Autopilot Profile
Introduction
So with the first part we went into the differences of paths when choosing a method of which way we want to proceed, whether that is a standard Autopilot profile deployment or if we want to use the white glove version of this process to move forward.
While that covered a lot of foundational ground, with this part, we want to dive into another area of interest. This will help our decision making and that stems around the purpose of the autopilot profile we are using or trying to create. Knowing exactly what we want to achieve with it, and how it will be constructed, will also play a factor in how we want our approach to be.
Again, this part lays out everything around understanding what you want your Autopilot profile itself to achieve, so you can start to customize and explain the suggestions and outline the requirements.
Main Purpose of Provisioning – New, Existing or both
Firstly we want to know what we are trying to achieve and what kind of devices we want to enable.
New Devices
New devices are really what we see as the ones which may come from a specific manufacturer, or perhaps they can be devices which are already on premise but not distributed to any users yet. These devices are then gathered and the hardware hashes are obtained and uploaded onto the Autopilot portal. Once added, the autopilot profile (depending on how you’ve assigned it) will apply to those devices which will allow them to go through the enrollment.
Existing Devices
Really new devices become existing devices anyway. But just in case, you may not have a need for new devices. For whatever reason you have the option to accommodate the devices which already exists. Basing this on a scenario of having an Azure AD environment and devices already enrolled into Intune, you can allow your autopilot profile to convert targeted devices to become autopilot devices.
Accommodate Both
Just like above, new devices become existing devices and vice versa. But that doesn’t necessarily mean that the processes will be exactly the same. Take for example, new devices may come from a manufacturer which already support Autopilot and CSP options. Devices will be sent directly to users or the client site already registered to Autopilot. So a user essentially just logs into the device while its enrollment takes place, but other options where a white glove scenario is concerned, that same device would already be ready to go without this. We will dive more into these topics on the next parts of this series.
How we apply the profile
Group for all Autopilot Devices
One of the main go-to or “best practice” options is normally to create a group which would contain a dynamic membership rule to contain all of the devices which are NOT registered to Autopilot.
Group Tags
Importing of devices, not only just with the hardware hash, but also containing the group tags allows you to allocate a category in which you can group devices to know exactly the role of functionality it may belong to, as well as other attributes it may be attached to.
Creating a group which contains a dynamic membership rule to grab devices by its order ID, which in turn relates to the group tag.
Required Software
The biggest part of them all possibly 🙂
So the mandatory software which would mark a device as qualified of being a company standard. This can be based around one piece of software or perhaps based around multiple. But we need to define what our mandatory list would be. This decision plays a role in our decision on how we will enroll and provision devices.
Parts of this category will start to dive into the overall user experience. But we will cover this in the next part. For now we want to outline this as a category within the requirement of defining an actual purpose for what our autopilot profile is trying to achieve.
For example, one piece of software which may be mandatory all round could be Office 365. So going with Office 365, we take into account many different areas of interest. For example:
- Update Channel
- Chosen Architecture
- Different versions to accommodate for removal
- Languages
These are just a few variations of decision making. If we have a varied amount of each category specified, these also have to be taken into account. Whether that is a justification to have devices already pre-provisioned or we’re going down a possible path of more than one profile, which we will dive into more for the next section below.
Multiple Autopilot Profiles?
This particular section makes it extremely interesting when it comes to the decision on which Autopilot option to go with. It’s not uncommon for organizations to use multiple autopilot profiles in order to segregate different areas of a business or certain functionalities performed within a business.
Software can play a part, but it shouldn’t rule the overall decision. Software can be made available within a company portal and we wouldn’t want to go down a route where autopilot profiles are essentially treated like task sequences within Microsoft Endpoint Manager. Other areas come into play like the user experiences, the compliance may be completely different for certain devices – not to mention security levels. Again these are all areas which we will dive a lot more later.
Most places use one Autopilot profile due to the simplicity. Typically a general experience is required for all devices where there are common denominators for required software, with perhaps one or two causing a slight separation. Multiple profiles can become a complicated matter. But there can be circumstances where these are needed which we will cover in part 3.
Next on Part 3
In the next part, we will go more into the finer parts of the overall user experience. We’ll discuss what the user and what we’ll see. This will aid in our overall decision in making the autopilot readiness process.
In the meantime, our Experts are always a click away. send us an email.
