Devices removed from the Autopilot group mid-enrolment cause a reset loop

A device that was enrolling normally suddenly resets and lands back at OOBE — or sits at "Please wait…" indefinitely. If the device dropped out of its Autopilot deployment group while the build was in flight, the deployment profile unassigned underneath it. Here is why membership flaps mid-enrolment, and how to make group targeting boring and stable before build day.

The problem

Partway through an Autopilot enrolment the device restarts and returns to the start of OOBE, then does it again — a reset loop. In other cases the Enrolment Status Page (ESP) never progresses and the device hangs at "Please wait…". When you check Intune afterwards, the device's Autopilot profile status has flipped from Assigned to Not assigned, even though it was assigned when you powered the machine on.

A Microsoft Q&A thread documents exactly this pattern for hybrid Autopilot devices: the device is removed from its deployment group during enrolment, the profile unassigns in flight, and the device falls into a reset loop. Microsoft's Autopilot enrolment documentation likewise points to unstable group targeting during OOBE as a cause of ESP hangs.

You are most likely to hit this if:

• Your Autopilot deployment group uses a dynamic membership rule, and something in the tenant changes device attributes or the rule itself while builds are running.
• You run scheduled cleanup or de-duplication scripts that purge "stale" device objects.
• You are doing Microsoft Entra hybrid join, where a second computer object appears mid-enrolment and confuses attribute-based rules.
• More than one group rule can match the same device — overlapping targeting with conflicting profiles or actions.

Why it happens

An Autopilot deployment profile is not stamped onto the device once at the start of enrolment — it is delivered through group membership, and Entra ID re-evaluates dynamic membership continuously. If the device leaves the group mid-build, the profile assignment goes with it, and the enrolment that depended on that targeting is now standing on nothing.

Ways a device gets ejected mid-flight

• Rule edits during a build window. An admin "tidies up" a dynamic membership rule while devices are enrolling. Entra re-evaluates, the device no longer matches, and it is removed from the group — and from the profile assignment.
• Attribute drift. Dynamic rules keyed on mutable attributes (displayName prefixes, enrolment profile names, OU-derived properties) break when those attributes change during enrolment — and several of them do change: the device is renamed, re-registered, or (in hybrid scenarios) a second computer object is created by the offline domain join and synced up by Entra Connect. The rule can end up matching the wrong object, or neither.
• Cleanup scripts. Scheduled jobs that delete stale or duplicate device records can catch a half-enrolled device — hybrid enrolments are especially exposed because the freshly synced computer object looks like a duplicate of the Entra registration record.
• Overlapping rules. Two groups match the same device: one carries the deployment profile, another carries a different profile or a destructive action. As membership resolves, the effective targeting flaps.

Why the result is a loop or a hang

When the profile unassigns in flight, the device's next check-in finds that the targeting it was enrolled under no longer applies to it. Depending on where in the sequence this lands, enrolment fails in a way that triggers a reset — and after the reset the device re-enters OOBE in the same broken state, so it fails and resets again. Alternatively, the ESP keeps waiting for apps and policies that are targeted at a group the device is no longer in, and the user stares at "Please wait…" indefinitely.

The fix

1. Put a change-freeze on Autopilot targeting while builds are in flight

Treat the deployment group's membership rule like production change control. During any build window:

• No edits to dynamic membership rules on Autopilot groups.
• No manual removals from the group.
• Pause scheduled device cleanup, de-duplication, and "stale object" jobs — or confirm their filters cannot touch enrolling devices.

2. Audit for overlapping rules before build day

Enumerate every group in the tenant whose membership rule can match Autopilot devices — search rules referencing devicePhysicalIds, [ZTDId], [OrderID], [PurchaseOrderId], enrollmentProfileName, or device name prefixes. For each match, list what that group assigns: deployment profiles, ESP profiles, apps, scripts, compliance actions. Exactly one deployment profile should ever be able to apply to a given device; anything destructive (wipe, retire) must not share a targeting surface with your Autopilot group.

3. Anchor dynamic rules on immutable attributes

Base the deployment group's rule on the Autopilot device attribute that exists from hardware-hash import onwards and never changes, rather than names or profile strings that mutate mid-enrolment:

(device.devicePhysicalIds -any (_ -startsWith "[ZTDId]"))

For a known, finite batch of devices, consider assigned (static) membership for the build window instead — nothing can re-evaluate a device out of a static group.

4. Guard your cleanup scripts

Any script that deletes device objects should exclude devices with an Autopilot ZTDID and anything enrolled within your build window (for example, the last 7 days). In hybrid environments, make sure it understands that the Entra device registration and the synced on-premises computer object are two records for one machine, not a duplicate to purge.

5. Rescue a device that is already looping

1. At OOBE, press Shift+F10 and collect diagnostics: MDMDiagnosticsTool -area Autopilot;TPM -cab C:\autopilot.cab.
2. In Intune, open Devices > Enrolment > Windows Autopilot devices, find the serial, and check the profile status column.
3. Re-add the device to the deployment group (or fix the rule so it matches again) and wait until the profile status reads Assigned — do not restart the build while it shows anything else.
4. Reset the device (Autopilot Reset, systemreset, or reimage) and re-run enrolment from clean.

6. Pre-flight check on build day

Before powering on the first device, confirm every serial in the batch shows profile status Assigned. That single column is your canary: if it says Not assigned or Assigning, the targeting is not settled and the build should not start.

How Decolla handles it

Honestly: Decolla does not manage your Entra ID group rules and cannot stop a colleague editing a dynamic membership rule while a build is running. The change-freeze and rule audit above are still yours to enforce — this article should let you do that today, with or without us.

What Decolla does change is the shape of build day. Decolla provisions Windows devices over your own Intune and Autopilot tenant, and every deployment starts from a written, itemised plan that you approve before anything runs. Prerequisites such as group membership and profile assignment become explicit, checked lines in that plan — settled before the build starts, not discovered as a failure mid-flight. Each item in the plan states its delivery method and reversibility class (automatically reversible, reversible, or flagged irreversible), and the deployment then runs unattended against exactly that approved plan — nothing is re-targeted ad hoc while devices are enrolling.

If something Decolla deployed needs undoing, rollback is per-item — covering Decolla's own changes; edits other admins make to your directory or group rules are outside that scope. Decolla is currently pre-launch, with a waitlist at decolla.app.

Sources

• Microsoft Q&A — Devices removed from hybrid Autopilot group during enrolment
• Microsoft Learn — Windows Autopilot enrolment