HomeSetup guides › Create a dynamic Autopilot device group (touchless Windows targeting)
Setup guide · from scratch

Create a dynamic Autopilot device group (touchless Windows targeting)

Targets Autopilot Windows devices before OOBE. Build the rule ONLY on Autopilot attributes (ZTDId or group-tag OrderID) — they populate only after registration. Requires Entra ID P1.

Intune / Microsoft Entra > Groups
≈ 10 min
Windows — Autopilot & USB provisioning · step 10 of 12 · ≈ 10 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
The Decolla way — skip the clicks.

Decolla creates the dynamic Autopilot device group with the correct membership rule for you - no hand-pasting the ZTDId or OrderID syntax that one stray character breaks. The rule is right by construction.

You get back: the created security group, the exact membership rule it applied, and the live member count once the devices evaluate.

⏱ By hand: about 18 min plus the evaluation wait, and a single syntax typo leaves the group silently empty. The Decolla way: correct on the first pass, every time.
Before you start
  • An Entra ID P1 licence live in the tenant - dynamic membership rules simply will not run without it.
  • Your rule text to hand: the ZTDId form for all Autopilot devices, or your exact group tag for the OrderID form.
  • Devices already registered in Autopilot - ZTDId and OrderID only populate after registration, so an unregistered device never matches.
  • For the Autopilot-for-existing-devices path only: the FULL enrollmentProfileName value, copied exactly.
0 of 6 done
Step 1. In Intune > Groups > New group set type 'Security' and 'Entra roles can be assigned to the group' = No.
Screenshot: New group blade, type Security (captured during a live customer build — coming to this page)
Why: 'Security' is the group type Intune and Autopilot can actually target - pick it here and this one group can carry the whole dynamic rule.
Don’t: Do NOT set 'Entra roles can be assigned to the group' to Yes - a role-assignable group only accepts manually added members, and the 'Dynamic Device' option disappears at the very next step.
Step 2. Set Membership type to 'Dynamic Device'.
Screenshot: Membership type = Dynamic Device (captured during a live customer build — coming to this page)
Why: Dynamic Device hands membership to a rule instead of a person - every registered Autopilot machine falls into the group on its own, so one rule fills a whole batch.
Watch for: 'Dynamic User' sits right beside it in the same list - choose Device, not User. Autopilot's identifiers live on the device object, so a user rule matches nothing.
Step 3. Click 'Add dynamic query' > 'Edit'.
Screenshot: Dynamic rule syntax editor (captured during a live customer build — coming to this page)
Why: 'Edit' opens the raw rule syntax editor - the point-and-click builder cannot express the -any / -startsWith operators the Autopilot rule needs, so you paste the rule as text here.
Step 4. For ALL Autopilot devices paste (device.devicePhysicalIDs -any (_ -startsWith "[ZTDId]")); or for a group tag paste (device.devicePhysicalIds -any (_ -eq "[OrderID]:<groupTag>")).
(device.devicePhysicalIDs -any (_ -startsWith "[ZTDId]"))
(device.devicePhysicalIds -any (_ -eq "[OrderID]:<groupTag>"))
Screenshot: Autopilot membership rule pasted in (captured during a live customer build — coming to this page)
Why: These two are the only attributes that identify an Autopilot device before OOBE - the ZTDId form catches every registered device, the OrderID:groupTag form narrows to a single group tag.
Watch for: [ZTDId] and [OrderID] are literal text and stay exactly as written inside the quotes - only <groupTag> is yours to swap for your real tag.
Don’t: Do NOT bolt on clauses about device name, OS or ownership - none of that is populated before OOBE, so the device would miss the very targeting you built this group for.
Step 5. For Autopilot-for-existing-devices, target the FULL enrollmentProfileName value to avoid spoofed-correlator collisions.
Screenshot: enrollmentProfileName rule variant (captured during a live customer build — coming to this page)
Why: Autopilot-for-existing-devices correlates on the profile name, and the FULL value is the one thing that cannot be imitated - an exact match keeps strangers out of the group.
Watch for: This variant is only for the in-place 'existing devices' path - a normal hardware-hash Autopilot device uses the ZTDId/OrderID rule from step 4 instead.
Don’t: Do NOT shorten it or reach for -startsWith - a prefix match is precisely the spoofed-correlator collision this step exists to avoid.
Step 6. Save, then Create; membership evaluates asynchronously (allow longer at scale).
Screenshot: Group Overview showing membership count > 0 once devices evaluate (captured during a live customer build — coming to this page)
Why: Save writes the rule and Create builds the group; Entra then evaluates the rule in the background, so the group is live before a single device has been assessed against it.
Watch for: A membership count of 0 straight after Create is normal, not a broken rule - evaluation is queued, and it takes noticeably longer as the tenant grows. The count climbs above 0 once devices evaluate.
Don’t: Do NOT rebuild the rule or re-register devices just because the count is still 0 - you'll only re-queue the evaluation and wait longer.

If it goes wrong

The failures people actually hit on this process, each with the diagnosis and fix:

See it on a real device.

Decolla is in private build — early-access members see a build defined, deployed and rolled back first.

Get early access