Autopilot Group Tags

In the early days of Autopilot, we weren’t very concerned with the group tags (or ‘Order IDs). The real struggle was getting the hardware hash off the PCs and hoping they would register in Autopilot before hundreds of laptops arrived at a customer’s doorstep. But now it’s not enough to just capture all of your computers in Autopilot; we need to assign varying deployment profiles to different groups of machines based on use case or type of hardware. I’ve created a PowerShell script that we can run manually on a device and choose the correct group tag

There are plenty of write ups on the subject of dynamic groups based upon group tag as the membership rule. This is a particularly good article by Ewan Monro. Here’s a quick overview of what you need to do:

  • Create a dynamic device group in Azure AD with the membership rule (device.devicePhysicalIds -any _ -eq “[OrderID]:tagName”)
  • Assuming your main Autopilot profile is assigned to a ‘catch all’ group (device.devicePhysicalIds -any _ -contains “[ZTDId]”), assign an alternative Autopilot deployment profile to the new dynamic device group.

Now on a larger scale, the proper method for group tag assignment is at the procurement level. As long as your hardware vendor is properly setup for Autopilot enrollment, they should be able to assign group tags to your order. But for testing and existing devices, we need an easy way to choose a group tag when enrolling a device into Autopilot.

Before you start, make sure you read the latest post on oofhours by Michael Niehaus. This will give you the basics for setting up app-based Intune authentication with a PowerShell script. This is the first part of what I have done here:

$clientId will be your application client ID that is generated when you register the app. $clientSecret will also be generated during that step; it’s all in Michael Niehaus’ write up.

This piece connects your script to Intune without username and password authentication. Next is the easy part; generating the hardware ID information. This will be the serial number and hardware hash. We’ll also make sure we append the group tag. Instead of the typical Get-WindowsAutopilotInfo script, we can just take the individual pieces and bake them into our script.

But what about the group tag? First, look at the last part of the script, where everything gets assembled before being uploaded to Autopilot:

Sure, we could just write a variable for the $tag and set it to whatever string we want. But we want something dynamic and efficient. We want to be able to choose from a selection of group tags every time we run the script. We can use a PowerShell list box form as seen in the screenshot at the beginning of this post. Here’s the code assembly for that piece.

That takes care of the box itself, but what about our options? We want to choose from a list of tags. I could’ve embedded this in the script, but I prefer to keep lists separate. That way, I can easily make changes without going back and editing the script itself. Here’s the XML list:

Simple enough, right?

The list will sit in my Azure blob storage for easy access. We can invoke a web request which will download the XML list and place it alongside my script. I’ll then parse out the options from the XML and use that for my list choices. Here is the code for that:

You can see by the end, my $tag is taken from the selection that is made in the list. And that’s it!

For simplicity, I’ll usually place the PowerShell script alongside a .bat file on a USB stick. This way instead of instructing someone to launch the PowerShell script with appropriate privileges, they just need to type something like runMe.bat– here is the contents of that:

Powershell.exe -ExecutionPolicy Bypass -File .\groupTagScript.ps1 -Verb RunAs

Once run, the device shows up under my enrolled devices in Intune. And of course, it has the proper group tag.

While you will commonly see group tags utilized for Autopilot self-deploying kiosk devices, folks will now rely on them for devices like the new Surface Pro X, which can only run 32-bit applications. There has to be a clear way to separate the Pro X required apps and profiles from the rest of your standard fleet, which undoubtedly contains some 64-bit apps. This is a great way to achieve that.

Let me know if this method works out for you. Next, I’ll be working on gathering the actual group tags live from the Microsoft Graph.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s