Route Windows Autopilot Profiles With Group Tags and Dynamic Device Groups

To send each Windows AutopilotThe KBY LexiconWindows AutopilotWindows Autopilot registers device hardware identity to a tenant so new or reset Windows devices self-configure via Entra ID join and Intune policy during first boot. Read Full Context device to the right deployment profile without editing groups by hand, give every registered device a group tag, build one dynamic device group per tag with the rule (device.devicePhysicalIds -any (_ -eq "[OrderID]:YOUR-TAG")), and assign each profile to exactly one of those groups. Intune’s group tag field is written to the OrderID attribute of the Microsoft Entra device object, so the tag is what the rule matches. The key constraints: build rules only on Autopilot attributes, never assign one group to two profiles (the oldest profile wins), and do not hand a device out until its Profile Status reads Assigned and Date assigned is populated.

This assumes Intune is already your Autopilot service and that automatic enrolment and licensing are in place; if not, start with the Autopilot prerequisites in Intune: licences, automatic enrolment and branding.

#Current method: static groups and profile guesswork

Many teams start with one assigned (static) security group per profile, and a technician adds each newly registered device to the right group by hand. That works for a pilot of ten devices, not for a refresh of several hundred.

The friction is predictable:

• Every device needs a human edit. A device registered by an OEM or reseller lands in the tenant with no group membership, so it either receives the default profile (any profile assigned to all devices) or none, depending on how the tenant is set up.
• Mistakes surface at the desk. A device that missed its group boots into the wrong flow, and the user at OOBE is the first to notice.
• Overlapping groups produce silent precedence. If a device sits in two groups that target different profiles, Intune resolves the conflict by applying the oldest created profile, which may not be the one the technician intended.

Routing intent lives in people’s heads rather than on the device record. Group tags move it onto the Autopilot registration itself.

#Improved workflow: tag on the device, rule on the group

Each of the four stages produces something you can check before moving on.

1. Define a tag taxonomy. Input: your list of deployment profiles. Output: a short, documented list of tag values, one per profile, for example STD, KIOSK and LAB. Keep tags short and free of spaces. Matching is not case sensitive in dynamic rules, but a consistent convention prevents near-duplicate tags.
2. Create one dynamic device group per tag. Input: a tag. Output: a Microsoft Entra security group whose membership is calculated by the service, not edited by people. The trade-off is latency: membership updates when the dynamic rule is processed, not the instant you save a tag.
3. Assign each profile to one group. Input: the group. Output: a one-to-one map of tag to group to profile, which removes the oldest-profile-wins ambiguity.
4. Stamp the tag at registration. Input: the hardware hash CSV or the device record. Output: a registered device that routes itself. Tags can be supplied in the Group Tag column of the CSV import, edited per device in Intune, or set through Microsoft Graph.

Roles and permissions. Profiles and device tags are managed in Intune; uploading a hash with Get-WindowsAutopilotInfo -Online needs at least an Intune Administrator. Validating dynamic rules and pausing rule processing needs at least the Groups Administrator role in Microsoft Entra IDThe KBY LexiconMicrosoft Entra IDA concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change. Read Full Context . For scripted reads, the delegated Graph permission DeviceManagementServiceConfig.Read.All is enough; changing a tag through Graph needs DeviceManagementServiceConfig.ReadWrite.All. Device-based dynamic groups do not need a Microsoft Entra ID P1 licence per device; the P1 requirement applies to users in dynamic groups.

#Implementation

Run this first in a test tenant or against a pilot tag that no production profile uses. Each step lists what you should see before continuing.

1. Capture the current state. Before changing any tag, export every Autopilot device with its current group tag. This file is your rollback source.
   Code sample

   1Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
   2Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All |
   3  Select-Object Id, SerialNumber, GroupTag, EnrollmentState |
   4  Export-Csv -Path .\autopilot-tags-before.csv -NoTypeInformation

   Expected evidence: a CSV with one row per registered device. Stop if the row count does not match the device count shown under Windows Autopilot devices in Intune.

2. Create the pilot dynamic group. In the Microsoft IntuneThe KBY LexiconMicrosoft IntuneMicrosoft Intune is Microsoft's cloud-based unified endpoint management service for enrolling, configuring, securing and retiring Windows, macOS, iOS and Android devices. Read Full Context admin center select Groups > New group. Set Group type to Security, Membership type to Dynamic Device, and Microsoft Entra roles can be assigned to the group to No. Under Dynamic device members select Add dynamic query, add an expression with this rule, save the expression, then select Create:
   Code sample

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

   Expected evidence: the group exists with zero members, because no device carries the tag yet.

3. Tag one pilot device. In Devices > Windows > Enrollment > Windows Autopilot > Devices, select the device, set Group tag to PILOT and select Save. The Graph equivalent, useful for batches, is:
   Code sample

   1Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"
   2Update-MgDeviceManagementWindowsAutopilotDeviceIdentityDeviceProperty `
   3  -WindowsAutopilotDeviceIdentityId $id -GroupTag "PILOT" -WhatIf

   Here $id is the device’s Id from the step 1 export. Run it with -WhatIf first, then without. For batches, loop only over a reviewed list of Ids, keep each run small (for example 20 devices), and check that batch in Intune before starting the next. Expected evidence: the device row shows the new tag after you select Sync and refresh. Stop if a different device changed: restore its tag from the export.

4. Validate the rule before you trust it. In the Microsoft Entra admin center go to Entra ID > Groups > All groups, open the group, select Dynamic membership rules and use the Validate Rules tab with the pilot device and one untagged device (up to 20 at a time). Expected evidence: the pilot device is a member, the untagged device is not. A result of Unknown means the rule is invalid or the check failed; select View details.
5. Wait for processing. On the group overview, Dynamic rule processing status should read Update complete. Then confirm membership from PowerShell:
   Code sample

   1Connect-MgGraph -Scopes "GroupMember.Read.All"
   2Get-MgGroupMember -GroupId $groupId -All | Select-Object Id

   Expected evidence: the Entra device object ID of the pilot device. Stop if the status is Processing error.

6. Assign the profile. Open the target profile under Windows Autopilot > Deployment profiles, and under Assignments choose Selected groups and add the group under included groups, not excluded groups. Check the profile’s Created date under Essentials if more than one profile could reach the same device.
7. Confirm assignment before deployment. In Windows Autopilot devices, watch the Profile Status column move from Unassigned to Assigning to Assigned, then open the device and confirm Date assigned is populated. Only then run OOBE on the pilot device.
8. Scale out. Repeat steps 2 to 7 for each production tag. For new hardware, put the tag in the CSV’s Group Tag column so devices arrive pre-routed. The header must be Device Serial Number,Windows Product ID,Hardware Hash,Group Tag,Assigned User, with no extra columns and no quotation marks, up to 500 rows per file. Edit it in a plain-text editor such as Notepad; Microsoft warns that saving it from Excel produces a file Intune cannot import.

#Guardrails

• Use only Autopilot attributes in the rule. Rules on other attributes may not place the device in the group before OOBE and can deliver unexpected configuration.
• One group per profile, one profile per group. If a group is assigned to several profiles, the device receives the oldest created profile. Keep the routing map above as the source of truth.
• Avoid All Devices with exclusions. When a profile is assigned to All Devices you cannot use exclusions; Microsoft notes that attempting it can cause assignment problems and might require hashes to be uploaded again.
• Leave Convert all targeted devices to Autopilot off in this workflow. When set to Yes it registers corporate-owned devices in the assigned groups with the Autopilot service, and turning it off or removing the assignment later does not remove those registrations. Turn it on only as a deliberate, separately approved decision.
• Treat the tag as a privileged field. Whoever can edit a tag can change which profile a device receives, including whether its user becomes a local administrator. Restrict the role that can edit Autopilot devices and pair it with time-bound elevation, as described in local admin access that expires by design.
• Do not name profiles beginning with OfflineAutopilotprofile-. Autopilot for existing devices sets enrollmentProfileName to that prefix plus a correlator ID, and a device can report any correlator ID. If you also use enrollmentProfileName rules, match the whole value.

#Validation

A device is routed correctly when every one of these holds:

1. The device row in Windows Autopilot devices shows the expected group tag after a Sync.
2. Validate Rules shows the device as a member of exactly one tag group, and not a member of the others.
3. The group’s Dynamic rule processing status is Update complete.
4. The device’s Profile Status is Assigned and Date assigned is populated.
5. After deployment, the Windows Autopilot deployment status report (Devices > Monitor > Windows Autopilot deployment status) lists the device. The report is in preview, keeps data for 30 days and only records new Intune enrolments.

#Common mistakes and how to diagnose them

• Symptom: the group has no members after tagging. Likely cause: a typo in the tag or in the rule, or rule processing has not finished. Diagnosis: compare the tag on the device with the rule text and check the processing status. Case alone is not the cause: string matching in dynamic rules is not case sensitive.
• Symptom: Profile Status stays Unassigned. Likely cause: the group was added as an excluded group, or the device is not yet in the group. Diagnosis: open the profile’s assignments and run Validate Rules. For a deeper walk-through, see how to find why an Autopilot device shows profile not assigned.
• Symptom: the device received the wrong profile. Likely cause: it sits in two groups targeting different profiles, so the oldest created profile won, or it is in no assigned group and received the default profile. Diagnosis: list every group the device is in and compare profile Created dates.
• Symptom: a re-tagged device still gets the old experience. Likely cause: it is already enrolled. Profile changes reach an enrolled device only after it is reset and enrolled again. Correction: schedule the reset as a separate, approved change.
• Symptom: the CSV import fails. Likely cause: the file was saved from Excel, has extra columns, or holds a hash already registered (ZtdDeviceAlreadyAssigned) or registered to another tenant (ZtdDeviceAssignedToAnotherTenant). Correction: rebuild it in a plain-text editor without those rows.
• Symptom: the group shows Processing error. Effect: membership freezes at the last successful evaluation, so new devices are not added. Diagnosis: an alert appears at the top of the group’s overview page. Correction: fix the rule and confirm the status returns to Update complete.

#Recovery and rollback

Every change here is reversible if you kept the step 1 export. Recover in this order:

1. Stop new routing. A Groups Administrator can select Pause processing on the group while you correct the rule, or you can remove the group from the profile’s included groups.
2. Restore tags. For each affected device, set Group tag back to the value in autopilot-tags-before.csv, in Intune or with the same Graph cmdlet used in step 3.
3. Restore the rule. Put the previous rule text back and resume processing.
4. Verify recovery. Re-run the export and compare it with the original file; the GroupTag column should match for every serial number. Then confirm that each affected device’s Profile Status is back to Assigned against the intended profile.
5. Handle devices already provisioned. A device that completed OOBE with the wrong profile keeps it until it is reset and re-enrolled. Treat that reset as its own approved change, outside this playbook: back up the user’s data first and confirm the device’s BitLocker recovery key is escrowed, for example with the script that lists Windows devices with no BitLocker recovery key in Entra ID.

#Measurable outcome

• Baseline: from the step 1 export, count registered devices with an empty GroupTag, and count the manual group-membership edits your team made for Autopilot devices last month.
• Success signal: every newly registered device carries a tag from the taxonomy, and its Profile Status reaches Assigned before it is handed out, with no manual group edits.
• Method and cadence: re-run the export weekly during rollout and monthly afterwards, filtering for empty or unknown tags.
• Threshold: any device found at OOBE with the wrong profile, or untagged after a Sync, triggers a review of the registration step that missed it.

#Rollout checklist

1. Tag taxonomy written down, one tag per deployment profile.
2. Pre-change export of every device’s GroupTag saved where the team can find it.
3. One dynamic device group per tag, using only the OrderID rule.
4. Validate Rules run against a tagged and an untagged device for each group.
5. Each profile assigned to exactly one tag group, with no excluded-group mistakes.
6. Convert all targeted devices to Autopilot left off unless separately approved.
7. Pilot device shows Profile Status Assigned and Date assigned before OOBE.
8. CSV template with the Group Tag column shared with whoever registers hardware.
9. Rollback rehearsed once: tag changed, restored from the export, and verified.

After the pilot, move the profile with the fewest devices first, prove the full checklist on it, and only then retire the static group it replaces.