Handling Multiple Windows Autopilot Profiles in Intune

Recently, I was helping a school with their Windows Autopilot journey, and we came across an interesting challenge they identified. They needed to deploy different Autopilot profiles to different devices, depending on who will be using that device. How to accomplish this isn’t obvious, so this blog post talks about how it can be done.

Scenario

The school I was helping needed one naming standard for Surface Pro devices for teachers and another naming standard for the Surface Pros the students would be using. They also needed the teachers to have local administrator rights, but the students to be standard users.

The Technical Problem

If you’re familiar with configuring Windows Autopilot, you will have seen various articles on how to assign Autopilot profiles. Most notably this article by Michael Niehaus or this Microsoft documentation.

Both articles talk about using a dynamic group in Azure Active Directory that holds the Windows Autopilot devices. The Autopilot Profile is assigned to this group, and that is how the device knows how to configure itself when it goes through the Windows Autopilot deployment process.

The most common practise people use is to create a group that includes all the Autopilot devices using this query:

(device.devicePhysicalIDs -any _ -contains "[ZTDId]")

This works well if all the Windows Autopilot devices will use the same Autopilot profile; but what happens when you need to use different Autopilot profiles that target different devices, like in my scenario above?

The Autopilot profile is responsible for setting the naming convention, local administrative rights, and what the user sees through the onboarding process. If this needs to be changed depending on the device or the user, then you will need multiple Autopilot profiles.

The Solution

While trying to figure this out, I came across this article written by Jake Stoker. He explains how to use different Autopilot profiles to target User Driven Deployment or Kiosk “Self-Deploying” devices.

Well – that’s sort of what I need, except I want to target teacher and student devices, all of which are user driven. But, the concept is there – I need to use more than one Autopilot profile.

As Jake mentions in his article, one of the dynamic queries that can be done is to group devices by an Order ID. However, this “Order ID” can literally be anything you want. It does not have to be an actual Order number.

Using this we can now create two dynamic device groups. One will use the dynamic query to look for “teacher” devices and the other for “student” devices. Those queries will look like this:

Teacher Devices

(device.devicePhysicalIds -any _ -eq "[OrderID]:Teacher")

Student Devices

(device.devicePhysicalIds -any _ -eq "[OrderID]:Student")

And those queries are assigned to my Azure AD groups:

The next step is to assign the Autopilot profiles to the relevant groups. I’ve added these images as an example of how the naming standard and administrative rights can be different for teachers and students.

Teachers Autopilot Profile

Student Autopilot Profile

To pre-stage a device for Windows Autopilot deployment a PowerShell script needs to be run to obtain the hardware hash of the device. This is a unique identifier that is used to tie the Windows 10 device to the Autopilot tenancy. This PowerShell script can be found here: https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo/1.3

Once the CSV file is obtained, the final step is to import the Windows Autopilot devices as either teacher or student machines. There are two ways this can be achieved. The first way is via the method Jake Stoker mentioned, by editing the CSV file and manually adding the information. Open the CSV file in an editor like Notepad++ and manually make the changes by adding the Order ID column, and the Order ID value.

I recommend using Notepad++ because I personally had problems with Intune accepting the CSV file after I made the changes in Excel (even though I saved the file as a CSV).

Manually editing the CSV file is ok for one or two devices, but it’s not feasible if you have 1,000 machines to organise. To automate the classification of devices, I updated the Windows Autopilot PowerShell script to insert the relevant field I needed.

I simply added my own variable called $Person to the script and assigned it the value of ‘teacher’…

…I then add Order ID with that value to the part of the script where it creates the pipeline object….

…and then include that in the output.

This then gave me a script I could run against the Teacher devices. I created another version of this same script for Students. I simply then run the teacher script on the teacher devices, and the student script against the student devices.

The end result is this…

As you can see my “Order ID” is my Deployment Group. The AAD groups I created will execute their dynamic queries and pick up this field, and hence the correct device will go the correct group, where the relevant Windows Autopilot deployment profile has been assigned.

And of course, you can have as many Order ID’s as you want – so this same method can be extended to however many Windows Autopilot profiles you need.

I hope you found this article useful and it has helped you understand how multiple Windows Autopilot profiles can be managed in an organisation.

If you are facing challenges like this or would like to learn more about Windows Autopilot follow me on LinkedIn or contact Data^#3.