You change a device's group tag in Intune so it picks up a different Autopilot profile. You wait. You sync. Nothing happens. Then an hour later it works - or it never does, and nobody can explain why. Both outcomes have the same root cause: a group tag does not assign anything directly. It is one link in a three-stage chain, and each stage introduces its own delay.
The Intune "group tag" field is written to the Microsoft Entra device object as the OrderID attribute. An Entra dynamic group rule matches on it - (device.devicePhysicalIds -any (_ -eq "[OrderID]:YourTag")) - and the Autopilot profile is assigned to that group, not to the tag. So a tag change must propagate through Entra dynamic group re-evaluation and then through Autopilot profile assignment, and both take real time. There is also a flag on the cached profile, IsExplicitProfileAssignment, which when true means the profile was assigned directly to the device - and no group tag change will ever redirect it.
OrderID, a dynamic group's membership rule looks for that attribute, and the Autopilot profile is assigned to the group. Three separate systems, in sequence.The problem: a change that does nothing, then suddenly works
Typical presentations:
- You edit the group tag, the device is imaged shortly after, and it gets the old profile - or the default Enrollment Status Page instead of your custom one.
- You add devices to a dynamic group and the Autopilot profile shows as unassigned for a long time.
- The change works perfectly, but only after a delay long enough that whoever tested it had already concluded it was broken and changed something else.
- The change never takes effect, no matter how long you wait - which is a different problem entirely, covered below.
The delays are real and documented. Dynamic group membership updates take time on their own, Autopilot profile assignment adds more on top, and in some circumstances group updates have been observed taking many hours. Provisioning a device inside that window gives you the previous configuration.
Why it happens: group tag is OrderID is a group rule
Follow the chain in order, because each hop is a place where time passes:
- You set the group tag on the Autopilot device object in Intune.
- Entra stores it as
OrderIDon the device object, inside thedevicePhysicalIdscollection. - A dynamic group rule evaluates and the device becomes a member - or stops being one. This is Entra dynamic group processing, on Entra's schedule, not Intune's.
- Autopilot profile assignment then follows group membership, and the device's assigned profile is recalculated.
- Only then will a newly provisioning device download the new profile.
Steps 3 and 4 are the ones you cannot rush. And critically, they are asynchronous relative to each other - the group membership can be correct while profile assignment has not yet caught up.
How to verify: read the chain from both ends
Device side, the useful question is not "what is my group tag" - the device does not store it - but "was my profile assigned via a group at all?" The cached profile answers that:
Service side, check the dynamic group rule itself. These are the two expressions that matter:
IsExplicitProfileAssignment first. If it is true, you can stop immediately - the entire group tag chain is irrelevant for that device, and no amount of waiting or re-syncing will change its profile. That single flag saves the most frustrating version of this investigation.The fix: change the tag properly and wait deliberately
Context: there is nothing broken to repair. The fix is doing the change in the right order and treating the propagation delay as a planned step rather than a surprise.
- Sign in to intune.microsoft.com.
- Go to Devices › Enrollment › Windows Autopilot devices (Devices › Windows › Windows enrollment in some portal versions).
- Select the device and edit its Group tag. Save.
- Confirm the corresponding Entra dynamic group has actually picked the device up - check group membership, not just the tag. This is the stage that silently lags.
- Confirm the Autopilot profile assignment status for the device has updated to the expected profile. This is a second, separate propagation.
- Only provision the device once both step 4 and step 5 show the expected state. Provisioning earlier gives you the old profile, correctly.
Two structural choices that avoid the problem entirely
- Set the group tag at import time. If the tag is present in the CSV or set by the OEM/partner at registration, the whole chain has time to settle long before anyone unboxes the device. Retagging a device you intend to image today is the worst case.
- Do not rebuild the tag taxonomy per project. Every new tag value needs a new group, a new rule evaluation and a new assignment to propagate. A small, stable set of tags mapped to long-lived groups has far fewer moving parts than a tag per deployment wave.
Reference: attributes, rules and where each lives
| Thing | Where it lives | What it does |
|---|---|---|
| Group tag | Intune Autopilot device object (portal / Graph) | What you edit. Not stored on the device itself |
OrderID | Entra device object, in devicePhysicalIds | What the group tag becomes. This is what dynamic group rules actually match |
ZTDid | Entra device object, in devicePhysicalIds | The Autopilot registration identifier - used to match all Autopilot devices regardless of tag |
ZtdRegistrationId | Device: cached profile JSON in AutopilotPolicyCache | The device-side view of its own ZTD registration - a device identifier, handle with care |
IsExplicitProfileAssignment | Device: cached profile JSON | True means the profile was assigned directly, so group tags are irrelevant for this device |
PolicyDownloadDate | Device: cached profile JSON | When the device last actually pulled a profile - anything changed after this has not reached it |
Proof it worked: a real device that ignores group tags
A genuine run of Get-AutopilotAssignmentChain.ps1 from this series. The profile name and ZTD registration ID are redacted; the flags and dates are exactly as captured:
This is the most useful possible result, because it is the case people waste the most time on. IsExplicitProfileAssignment: True means this device's profile was assigned directly. Editing its group tag would achieve precisely nothing - not "eventually", not "after a sync", ever. Any investigation into propagation delay for this device would have been chasing a mechanism that is not in play.
Note also the deliberate limit of what the script claims. It does not report the current group tag, because the tag is not stored on the device - it lives on the Entra device object as OrderID. A script that invented a value there would be confidently wrong, so instead it tells you where to actually read it.
References
- Microsoft Learn - Create device groups for Windows Autopilot - the
ZTDidandOrderIDdynamic group rule syntax - Microsoft Learn - Configure Windows Autopilot deployment profiles
- Microsoft Learn - Manually register devices with Windows Autopilot - setting the group tag at import
Microsoft MVP community deep-dives
Verified and genuinely on-topic - the URL was fetched and confirmed before being cited here, not copied on trust:
| Author | Post | What it adds |
|---|---|---|
| Rudy Ooms (MVP, call4cloud.nl) | Step by Step: How Windows Retrieves the Autopilot Profile | Traces the full token-and-profile retrieval flow and independently documents the AutopilotPolicyCache registry key and wmansvc on-disk cache that these posts read from |
Script for this post is in Windows-Autopilot-Scripts.