Dynamic-group lag races the ESP: devices enrol before their apps are even assigned

Entra ID evaluates dynamic-group membership on its own schedule — minutes, hours, occasionally the better part of a day — while OOBE and the Enrollment Status Page start the moment the user powers on. If your app assignments hang off the ZTDId dynamic group, the ESP can run before the device is in the group, and the apps it was supposed to track simply are not assigned yet.

The problem

You import a hardware hash, the Autopilot device object appears, and your dynamic security group — the classic (device.devicePhysicalIds -any (_ -contains "[ZTDId]")) rule — is supposed to pick it up so the device inherits its Autopilot profile and app assignments. It does pick it up. Eventually.

The lag is real and well documented in the community. Call4cloud's write-up on Autopilot dynamic-group membership found that "3,5 hours later group membership was finally updated", and notes that "it can take up to 24 hours sometimes." Meanwhile the technician (or worse, the end user) has already unboxed the machine, OOBE has started, and the Enrollment Status Page is evaluating which apps and policies it should track — right now, against the assignments that exist right now.

Typical symptoms:

• The ESP shows fewer apps than you expect (or "0 of 0"), completes suspiciously fast, and the user lands on a desktop missing half its software.
• Blocking apps you assigned to the dynamic group are never tracked at all, because at enrolment time the device was not a member of the group they target.
• The apps quietly arrive hours later at the next Intune check-in — after the user has already logged a "my new laptop is broken" ticket.
• In the worst case the Autopilot profile itself is targeted via the dynamic group and has not been assigned when the device boots, so the machine skips Autopilot entirely and goes through vanilla OOBE.

It bites hardest on same-day deployments: hash imported at 09:00, device handed to the user at 09:20, group membership evaluated at 12:30.

Why it happens

This is a race between two systems that have no knowledge of each other:

1. Hardware-hash import creates the Autopilot device object, and a corresponding Entra ID device object carries the [ZTDId] tag in its devicePhysicalIds property.
2. Dynamic-group evaluation in Entra ID is an asynchronous background service. Membership rules are not evaluated at the moment an object is created; the change is queued and processed when the service gets to it. There is no per-device SLA — the call4cloud write-up cited in Sources measured a 3.5-hour delay in testing and notes that it can take up to 24 hours sometimes, and community experience routinely spans 30 minutes to several hours.
3. OOBE and the ESP start immediately on first boot. When the device enrols into Intune, the ESP builds its list of tracked apps and policies from the assignments that resolve at that moment. An app assigned to a group the device joins an hour later is not in that list — the ESP does not retroactively add it.

So the device can be enrolled, ESP complete, and user logged in before Entra ID has ever placed it in the group that all its software is assigned to. Nothing is broken in the sense of an error — every component did its job — but the ordering assumption baked into the design ("the device will be in the group by the time it enrols") is simply not guaranteed by the platform.

Note the two distinct failure surfaces: the Autopilot deployment profile (must be assigned before the device boots, or Autopilot does not trigger at all) and app/policy assignments (must resolve before the ESP snapshots its tracking list). Both lose the same race if they depend on the same lagging dynamic group.

The fix

You cannot make Entra ID evaluate dynamic groups faster. The fix is to remove the dependency on that evaluation for anything the ESP needs. In order of preference:

1. Target ESP-blocking apps deterministically

• Static (assigned) groups: add Autopilot devices to a static security group at import time — manually, or scripted via Graph as part of your hash-import process. Membership is immediate and there is nothing to wait for.
• All devices + assignment filter: assign apps and policies to All devices with a filter on enrollmentProfileName matching your Autopilot profile. Assignment filters are evaluated at enrolment/check-in time, not queued like dynamic-group membership, so they resolve correctly on first boot. This is the most robust pattern for anything the ESP blocks on.

2. Use enrolment-time grouping where it fits

Windows Autopilot device preparation (the newer Autopilot flow) adds the device to a security group you choose during enrolment, by design, precisely to kill this race. If your scenario fits its constraints (user-driven, Entra-joined), it removes the evaluation lag entirely. Check the feature's current limitations against your requirements before switching flows.

3. If you keep the ZTDId dynamic group, respect the lag

• Import hashes well ahead of deployment — the day before, not the hour before.
• Before booting a device, verify in the Autopilot devices blade that its deployment profile shows Assigned, and spot-check that the device appears in the group's membership list.
• Never target ESP-blocking apps at the dynamic group; reserve it for things that can tolerate arriving late.

4. Knowingly accept first-boot drift for non-critical apps

Slim the ESP blocking list to the apps a user genuinely cannot start work without. Everything else can be assigned as available, targeted at user groups, or allowed to trickle in at the next check-in. A deliberate decision to accept drift is fine; an accidental one is a helpdesk ticket.

How Decolla handles it

Decolla cannot make Entra ID evaluate dynamic-group membership any faster — nothing can, and we will not pretend otherwise. What Decolla does is take the ordering assumption out of the design.

Decolla provisions Windows devices over your own Intune/Autopilot tenant, and before anything runs it produces a written, itemised build plan: each item selected for that deployment — drawn from Decolla's curated catalogue of 260+ items across 21 sections — is listed with its delivery method and its reversibility class, and you approve the plan before deployment starts. Group targeting in that plan is deterministic — items the Enrollment Status Page depends on are targeted through mechanisms that resolve at enrolment time rather than through a dynamic-membership evaluation that may not have happened yet. The race described above is designed out at the planning stage, where it is visible on paper, instead of being discovered at first boot on a user's desk.

If a deployment item does not land as planned, Decolla supports per-item rollback of the changes it made — its own changes, in your tenant.

Decolla is currently pre-launch and open for waitlist sign-ups.

Sources

• Call4cloud — Autopilot dynamic group membership updating
• CIAOPS — Autopilot ESP: the deployment pattern that actually survives contact with real users
• Microsoft Q&A — Enrollment Status Page not assigning correctly