Introduction

Every modern Windows (10/11) device can be setup and managed through Intune and enabled for organizational use. There are two types of ownership, one is personal and the other corporate. If a device is fully corporate-owned, the hard- and software should be registered for an organization, specifically in the Microsoft tenant of the org. The device then "knows" from which Intune service instance it must synchronize data and will always try to set up for organizational use in this tenant. This includes an Azure AD join.

Autopilot identities

Autopilot identities are unique hardware hash identifiers. Every Windows device has its own hardware hash, next to the serial number. This is great to identify devices and essential that hardware can be associated with only one Microsoft tenant to get enrolled through Autopilot during the Windows Out-Of-the-Box-Experience (OOBE) and receive the right configurations, apps and policies.

Once you upload a hardware hash with one of the following options:

• Get-WindowsAutoPilotInfo
• ConfigMgr Export or ConfigMgr convert
• Registering through your hardware vendor

Then the identities with some fundamentals information will be visible in the Devices>Enroll devices>Windows enrollment>Devices blade:

Every identity holds this attributes:

• Serial number
• Manufacturer
• Model
• Group tag — A string attribute that can be used to identify a group of devices. Intune’s group tag field maps to the OrderID attribute on Azure AD devices.
• Purchase order — String that the hardware vendor can supply to the device.
• User — User to pre-fill authentication during device setup.
• Device name — Prepopulate the device name. (not applicable to HAADJ)
• Profile status — Specifies if a deployment profile status is assigned (or not) to the device.
• Assigned profile — Assigend deployment profile name that will be used for Autopilot.
• Date assigned — Timestamp of when the profile was assigned to the device.
• Enrollment state — Specifies if the device is enrolled in Intune. (if a corresponding Intune device exists)
• Associated Intune device — Link to the Intune device object.
• Associated Azure AD device — Link to the Azure AD device object.
• Last contacted — Timestamp of when the Autopilot identity last contacted to the service.

Azure AD object memberships

There is a relationship between the Autopilot identity and the Azure AD object of the same device. The Azure AD object represents the device for identity and access purposes (later with Azure AD join). Some of the attributes that an Autopilot identity holds are also available for the Azure AD device object.

The key difference for us is, that Azure AD device objects can be added to groups, which you can then assign to profiles, configurations and apps. This is a sample of the attributes:

You can add the syntax of an Azure AD dynamic group to query for one or more of these attributes, as described in the next chapter. Please note that you can also choose from more device attributes. See the official docs

Create dynamic groups - syntax

Now we can create Azure AD dynamic groups to match a rule syntax. This means, that all devices (or users) that match the rule will get added as members of the group. Typically the syntax is some kind of validation of attributes of the identity.

Here the Group tag is a very common approach, since it is a free-text string that does not change over time, is empty by default and intended for this use. See some example rule-syntaxes:

All Autopilot identities (any Group tag or none):

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

Add Autopilot identities with the Group tag Azure AD:

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

Add all Autopilot identities, except if they have the Group tag AzureAD:

(device.devicePhysicalIDs -any (_ -contains "[ZTDId]")) -and -not (device.devicePhysicalIDs -any (_ -eq "[OrderID]:AzureAD"))

Add all Autopilot identities, except if they have set any Group tag:

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

Source: Microsoft Learn | Source: morethanpatches.com | Expression operators

Conclusion

I really like to use the ZTDID to fetch all Autopilot devices in one group. I assign this group to all of my default/base configurations, which every device should get. This works perfectly fine, if you only have one device type and run a rather small environment.

But keep in mind, that if not all devices should get the same profiles, multiple groups are needed. These may then be excluded from some profiles. For this to work, your environment must be built very well structured.

I like to keep it simple and only work with Group tags. Special configurations should get applied to distinguished device (preferred) or user groups. Also I don’t like to exclude groups from more than 5< profiles. It makes everything unnecessary complex and will grow historically until you lose perspective.

If you consider multiple defined device types that are fundamentally different (user deploying, self-deploying with kiosk etc.) I would recommend you that you use Group tags instead of complex exclusion groups. You can individually assign them based on the device workload type and the device. Each of the dynamic groups which queries the Group tag can then be independently assigned to profiles and other contents. You should also consider this when you want to have multiple device types like development, integration and production. Simply switching the Group tag results that the device will get other assignments. For population of the Group tags you may reach out to your hardware vendor, so that he can prefill any of the information of an Autopilot identity when you order a device.

Endpoint Management with Microsoft Intune

Ever wanted a full tutorial how to deal with Microsoft Autopilot Intune Technology? Well here it is!

OceanleafNiklas Tinner