Why are we using Autopilot group tags?

 

Why are we using Autopilot group tag? Do we need group tags? 

Two valid questions which I will discuss in this blog post.

So, why do we use group tags?

The short answer, to add the device to the correct group!

The long answer

As we are in over 40 countries and might even have multiple entities in those countries, we have around 90 legal entities with their own local support teams, and so we need to be able to distinguish the devices per entity.

Next, we have different device types for different use cases, we call them worker types. We currently have the standard device, engineering device, shared device, virtual device and kiosk device. User can have multiple devices which have different worker types. So, that is the second requirement.

Other requirements are to separate laptops, desktops and virtual devices. And yes, we could use filters instead, but they were not available 4 years ago. And finally, the need to mark devices as pre-production and to be able to see which global service the device is part of.

How do we use the group tags?

Based on the group tag, the device will be a member of a group. The group is used to add the scope tag to the device and to assign configurations and applications.

We also export the Autopilot data to Log Analytics, so we can leverage the group tag in our reporting.

Another cool thing we have build based on the group tags is an interface around Autopilot. In this way, we can add additional checks when importing device hashes, like only allowing specific hardware models and checking if the group tag is correct. It also provides a RBAC over the devices in Autopilot, once the initial import is done only admins for that entity change the device.

See the blog of Ivo Uenk on this topic: Import or remove Windows Autopilot devices based on specific criteria - Modern Workplace, Consultancy and Education | Udirection.

Can we do without group tags?

Yes, we can! We could also directly add the device to the correct group, which will have the same effect.

Looking at the new Autopilot version, Device Preparation, for use it would be mandatory that the device is added to the correct group, based on a identifier, in time to get the correct configuration.

And instead of group tag, we could use scope tags in the reporting or build some automation to get the information in Log Analytics. With scope tags only, we lose the ability to distinguish between environment and worker type.

How is the tag built up?

We have structured the group tag as follows:


How is dynamic query build?

The group tag value is stored in a multivalued string property of the device object in EntraID called physicalIds. The group tag string in this property has the prefix [OrderId], which can be used in a dynamic group query to add the device as a member to the group.

Some example queries:

• Add all Azure joined laptops to a group: 

(device.devicePhysicalIds -any (_ -match ".OrderId.:(STOLEN_|)A-…-.-.-L")) 

• Add all Azure and Hybrid joined Software Engineering Production Desktops of country XX/Entity YY to a group:

(device.devicePhysicalIds -any (_ -match ".OrderId.:(A|H)-CDS-S-P-D-XX-YY"))

Device filtering in Conditional Access?

You can use the group tag ([OrderId]) also as part of a device filter in a conditional access policy. But in this query, you need to specify the complete group tag value. You cannot use wildcards.

The query would be: 

(device.physicalIds -contains "[OrderId]:A-CDS-O-P-L-FR-00")


Comments

Post a Comment

Popular posts from this blog

Why pre-provision Windows devices?

Image
Recently I was asked again; “Why do you pre-provision devices?” I, or actually we, got that question several times last year. Also, in conversations with Microsoft this question pops up regularly. So, why do we pre-provision (aka. White Glove) devices? There are two main reasons to do this: Security Employee Experience And in addition, of course, the costs. Security Looking at security, by pre-provisioning devices we make sure we block things like Shift-F10, the Recovery Command prompt, etc. and to have the security policies applied before we hand the device over to the employee. Employee Experience Pre-provisioning devices will limit the time the employee needs to enroll the device to around 15 mins, with all applications installed on the device when the employee gets the desktop. As part of the pre-provisioning process, we make sure: The drivers and firmware are updated to the latest version before pre-provisioning. All core applications are installed as part of pre-provisioning....
Read more

How to do phased deployments in a cloud native world?

Image
   Back in the days when we had SCCM, we could easily setup phased deployments. In a cloud native world these controls are missing, but  we can create phased deployments based (dynamic) groups.  In this blog post I will show you how to set it up and use it. Groups First of we need to create groups that contains the devices for each phase. You can of course fill those groups manually, but in larger environments Dynamic Groups will be a better option. We will use the first character of the DeviceId in our dynamic query to select the devices per group.  Keep in mind that the DeviceId is containing hexadecimal characters, so that means 16 options (0 till F) per character. How big you want to make the groups is up to you, but I have chosen for a group for each first character, so 16 groups. With 16 group you have around 6.25% of your devices per group. Of course this is a bit depending on the size of the environment, for 60K+ clients environment the distribution look...
Read more