Tenant to Tenant Intune Device Migration Part 3: A Group Tag Without Autopilot

Today was supposed to be covering the GroupTag and SetPrimaryUser tasks. But after I started digging into this one, it became clear that it needed it’s own post. So let’s jump in.

If you’re just joining us, start here.

GROUP TAG (TRIGGER: 5 MIN AFTER LOGON)

Group tags (also known as DevicePhysicalIds) are Azure AD device attributes that are typically used for Autopilot registration. They allow the device to be dynamically grouped based on this attribute before it is enrolled to Intune and we use them throughout the lifecycle of the device.

Last year, I wrote a 5-part deep dive on the group tag reference architecture, so be sure to check it out if you haven’t.

It is critical that when the PC moves from Tenant A to Tenant B, it retains the same group tag to ensure proper assignment of Intune profiles. But wait- why aren’t we just applying the group tag when we register this device to Autopilot in an upcoming script? And more curious, how do you apply a group tag without Autopilot?

We’re not running the AutopilotRegistration task until later, to ensure the device record has had time to be removed from Tenant A. But we can’t wait until then for the tag because we need the device in the right group as soon as possible. Now for the best part; adding a group tag without Autopilot registration.

Let’s take a look in the Microsoft graph API explorer and navigate to the devices endpoint. Here is what a standard, non-Autopilot, device looks like when joined to Azure AD without a group tag:

Notice the “PhysicalIds” attribute section.

Now let’s take a look at an Autopilot registered device with a group tag:

There are two additional entries in the PhysicalIds attribute section; ZTDID and OrderID. What do these mean? The ZTDID is the Autopilot registration entry. The OrderID is our group tag, which makes sense if you have written any dynamic Azure AD group rules for devices before. So knowing what the group tag attribute is and where it needs to go, we just need to add it directly to the graph.

Our PowerShell script for this contains three important pieces of information:

  1. The group tag name from Tenant A

  2. The OrderID attribute with our tag in JSON format

  3. The patch call to the Azure device endpoint

As always, we start by authenticating to the graph with an app registration, this time to Tenant B. Then we need to grab the group tag from the device in Tenant A… uh oh! Didn’t we remove the device from Tenant A Autopilot? We sure did, but don’t panic- remember, we stored some key info in our local MEM_Settings.xml file. The group tag from Tenant A can be retrieved from the XML and stored in a variable.

Next we have to get the Azure AD device ID in Tenant B. Problem; all we have to look the device up is the serial number, and Azure AD doesn’t store that as an attribute. But Intune does. And Intune objects are associated with Azure AD objects. Time for some correlation:

By looking up the serial number in Intune managed devices, we can retrieve the Azure AD object and store the ID in a variable. We know where the tag is going, now we just need to format it.

The group tag can not be added by itself. First we have to get the entire PhysicalIDs entry and append our tag to that.

Our $oldTag variable is placed inside of a string with [OrderID], so it will blend in. After the tag is added to the IDs, we can convert it to JSON:

Easy! Now all that’s left is to invoke the PATCH call to the Azure AD object:

The patch is fairly quick, so the device should be placed in the right dynamic group shortly after. And that’s it; we successfully added a group tag attribute to a device without Autopilot registration.

Next time…

Both the GroupTag.ps1 and GroupTag.xml have been uploaded to the Intune Migration repo. I promise, next post will cover the SetPrimaryUser task.

Steve Weiner