Fix Autopilot Device Preparation Security Group Membership Failures That Leave Devices Non-Compliant

If Windows Autopilot device preparation finishes but the device lands in the wrong compliance state, misses critical policy, or never picks up the group-based configuration you expected during OOBE, check enrollment time grouping before you blame the app package, the compliance policy, or the user.

Microsoft now documents a specific known issue where security group membership update failures might lead to non-compliant devices. That matters because device preparation depends on putting the enrolling device into a preselected static Microsoft Entra security group during enrollment. If that membership update fails, the whole design starts to drift. Apps, scripts, and policies that were supposed to arrive because of that group may come late, apply inconsistently, or not apply the way your rollout assumed.

This is the kind of issue that looks random from the help desk side. One device completes and is healthy. Another device using the same policy reaches the desktop missing baseline configuration. A third device shows up in Intune but never reaches the security group state that your compliance and deployment logic expects. The root cause is not always on the device itself. In this branch, the problem is often the group configuration behind device preparation.

Quick fix checklist

Use this sequence during an active rollout problem:

1. Open the affected Windows Autopilot device preparation policy and confirm which device group it targets.
2. Verify that the target group is a static assigned security group, not a dynamic group.
3. Confirm the group is not assignable to Microsoft Entra roles.
4. Check that the Intune Provisioning Client service principal is still an owner of that group.
5. If the service principal appears as Intune Autopilot ConfidentialClient, verify the AppID is still f1346770-5b25-470b-88bd-d5744ab7952c.
6. Make sure nobody deleted the group, recreated it under a new object, or changed its membership type after the policy was built.
7. Review the Enrollment time grouping failures report in Intune.
8. Manually add already provisioned affected devices to the correct security group if they missed the enrollment-time update.
9. Retest with one pilot device before changing more profiles.

That order is important. Microsoft’s known-issues guidance is not describing a generic compliance problem. It is describing a failure in the group-update mechanism that device preparation relies on.

What Microsoft is actually saying

Microsoft’s Windows Autopilot device preparation known issues page lists a still-relevant issue named:

Security group membership update failures might lead to non-compliant devices

Microsoft gives four concrete causes for this branch:

• Retry failures during the group-update window.
• Static to dynamic group changes after the profile is already configured.
• Owner removal when the Intune Provisioning Client service principal is no longer an owner of the configured group.
• Group deletion before Intune recognizes that the original group is gone.

That is more useful than a vague warning because it tells you exactly where to look. This is not just “group assignment is broken.” Microsoft is pointing at the mechanics behind enrollment time grouping.

The supporting Intune documentation explains why this is so sensitive. Device preparation uses enrollment time grouping to add the device to a Microsoft Entra security group during enrollment, not hours later after normal inventory-based grouping catches up. Microsoft says this is what reduces post-enrollment latency and helps devices receive apps and policy fast enough for setup.

So when the enrollment-time membership update fails, the damage is immediate:

• required apps selected in the device preparation profile can miss their intended group path
• scripts targeted to that group can arrive late or not at the right phase
• compliance or protection settings assigned to the group can lag
• the user can reach the desktop with an incomplete build or the wrong policy posture

That is why this issue deserves a troubleshooting article of its own and not a footnote under generic Autopilot failures.

Why this breaks Autopilot device preparation

The Overview of Windows Autopilot device preparation doc explains the model clearly: the device is added to a pre-defined device security group during enrollment, and apps, scripts, and policies assigned to that group are then delivered to the device.

The Intune Set up enrollment time grouping doc is even more direct. Without enrollment time grouping, Intune can take up to 8 hours post enrollment to determine and deliver all apps and policies through regular grouping paths. Device preparation exists partly to avoid that delay.

That means the security group is not an optional convenience. It is a provisioning dependency.

If the group setup is wrong, device preparation can lose the main advantage that made you choose it:

• faster group-based targeting during OOBE
• near-real-time delivery of selected apps and scripts
• more predictable compliance landing state

This is also why the issue gets misdiagnosed. Admins often start by checking Win32 app logs, ESP timing, or device check-in. Those checks are useful, but when the device never joined the intended group at enrollment time, the more basic question is: did the policy target the right static group, and could Intune legally update it?

Where to check first

1. The device preparation policy

In the Microsoft Intune admin center, go to:

Devices > Windows > Enrollment > Device preparation policies

Open the affected policy and note:

• the Device group selected in the policy
• the assigned user group
• whether the deployment is User-driven or Automatic
• which apps and scripts were selected as blocking items during setup

Microsoft’s device-preparation tutorial is explicit here: the policy must point to the device group created earlier for enrollment time grouping, not a user group and not a substitute group someone made later because the name looked similar.

2. The target Microsoft Entra security group

Now inspect the group itself. In practice, the fastest checks are:

• Group type = Security
• Membership type = Assigned
• Microsoft Entra roles can be assigned to the group = No
• correct owners are still present

The Intune enrollment time grouping doc says the group must be a static Microsoft Entra security group. Microsoft also says you must add the Intune Provisioning Client as an owner of the security group.

If someone converted the group to dynamic membership after the rollout was designed, that is a documented failure path.

3. The Intune Provisioning Client owner

This is the check too many teams skip.

Microsoft says the service principal Intune Provisioning Client with AppID f1346770-5b25-470b-88bd-d5744ab7952c must be an owner of the group. In some tenants it may display as Intune Autopilot ConfidentialClient instead. Microsoft says the name difference is acceptable as long as the AppID matches.

So do not stop at the display name. Verify the object identity.

If that owner is gone, group membership updates during enrollment can fail even if the rest of the profile looks correct.

4. The enrollment-time failure report

Intune now exposes a dedicated report here:

Devices > Monitor > Enrollment time grouping failures

Microsoft says this report shows failures where devices did not become members of the configured static device group during setup. That is exactly the report to check for this issue family.

Also note Microsoft’s warning: newly updated information can take up to 20 minutes to appear. So if you are testing back-to-back, do not assume the report is empty just because you refreshed too early.

5. The deployed device state

Once a device already slipped through, look for practical symptoms:

• the device is enrolled but missing expected group-based apps
• compliance does not evaluate the way the rollout intended
• security baselines or scripts assigned to the ETG group do not show the expected effect
• two devices with the same profile finish in different states

Those symptoms do not prove ETG failure by themselves, but they are consistent with the Microsoft-documented issue.

A practical remediation workflow

Step 1: Prove this is an enrollment time grouping issue

Answer these questions first:

1. Is this Windows Autopilot device preparation, not classic Autopilot profile deployment?
2. Does the profile use a specific device security group for group-based targeting?
3. Was that group changed, deleted, or recreated after the policy was built?
4. Is the group now dynamic, role-assignable, or missing the Intune Provisioning Client owner?
5. Do affected devices show up in the Enrollment time grouping failures report, or do they behave as if they missed the intended group-based assignments?

If that chain lines up, keep digging in this branch before you rewrite apps.

Step 2: Repair the group design

Based on Microsoft’s docs, the safe target state is:

• Security group
• Assigned membership
• Not assignable to roles
• Intune Provisioning Client owner present

If the original group was converted to dynamic membership, create a proper replacement static assigned group instead of trying to force device preparation to work with the wrong design.

If the owner was removed, restore the service principal with AppID f1346770-5b25-470b-88bd-d5744ab7952c.

If the original group was deleted and re-created, make sure the policy now points to the current correct group object and not the dead reference everyone assumes is still live.

Step 3: Correct already affected devices

Microsoft’s mitigation for already provisioned machines is simple and blunt: manually add the affected devices to the correct security group.

That does not recreate the exact OOBE timing, but it does get the devices back onto the intended assignment path so policy and app delivery can converge.

In the middle of an outage, that is often the fastest stabilization move.

Step 4: Re-test one pilot device

After repairing the group configuration, test one fresh enrollment and confirm:

• the device joins the intended static group during enrollment
• required apps start landing from the correct assignment path
• the device no longer appears in the ETG failure report
• compliance and security configuration settle into the expected end state

Do not skip the pilot. This issue often sits beside other profile problems, and a single successful retest helps separate the ETG fix from unrelated cleanup work.

Step 5: Check the supporting policy design

Once the group problem is fixed, review the basics Microsoft calls out in the policy tutorial:

• selected apps should be assigned to the device group used in the profile
• apps intended for OOBE should be appropriate for that stage
• selected PowerShell scripts should be assigned to the same device group
• those scripts should run in System context during OOBE

If those fundamentals are wrong, the group could be healthy while the device still lands incomplete.

Logs, reporting, and evidence to collect

This issue is more control-plane than registry-driven, but you still need evidence for RCA.

Capture at least these items:

• screenshot of the device preparation policy showing the selected device group
• screenshot or export of the target Microsoft Entra security group showing Assigned membership type
• owner list proving the presence or absence of Intune Provisioning Client / f1346770-5b25-470b-88bd-d5744ab7952c
• screenshot of the Enrollment time grouping failures report entry, if present
• serial number and approximate enrollment timestamp for one failed device and one successful device

If you need to present the case internally, the strongest story is usually:

1. the profile depends on enrollment time grouping,
2. the group was misconfigured or lost the required owner,
3. the device missed the intended group update during enrollment,
4. the downstream compliance and app state drifted from the design.

That is a much tighter explanation than “Intune was inconsistent.”

Caveats and limits

A few boundaries matter.

First, this article is about device preparation, not every Windows Autopilot scenario. Classic Autopilot user-driven, self-deploying, and pre-provisioning failures have different failure trees.

Second, not every non-compliant device is an ETG issue. If the device joined the right group and still missed configuration, you still need to investigate assignment filters, app packaging, script execution, compliance logic, or device health.

Third, Microsoft notes that the ETG failure report shows only failures and can lag by about 20 minutes. Use that report as evidence, not as the only source of truth in the first few minutes of testing.

Finally, if your process relies on people editing production groups casually, expect this issue to recur. Converting a static group to dynamic membership after a profile is already using it is explicitly called out by Microsoft as a risk.

Prevention

To stop this from coming back in the next rollout:

1. Treat device-preparation groups as protected configuration objects.
2. Keep them static assigned security groups for their full lifetime.
3. Add a preflight check that confirms the Intune Provisioning Client owner is still present.
4. Document the required AppID: f1346770-5b25-470b-88bd-d5744ab7952c.
5. Monitor Enrollment time grouping failures continuously during pilots and large hardware drops.
6. Avoid deleting and recreating groups without updating the dependent device-preparation policy.

If your organization uses change control, put the ETG group in the same category as the profile itself. It is not just a container. It is part of the deployment engine.

Bottom line

When Windows Autopilot device preparation leaves devices non-compliant or half-configured, do not assume the problem started with apps or scripts.

Start with the Microsoft-documented failure path: security group membership update failures in enrollment time grouping. Verify the group is still static and assigned. Verify the Intune Provisioning Client owner is still there. Check the Enrollment time grouping failures report. Then manually repair already affected devices and re-test with one pilot.

That is the fastest path from a vague “device preparation is inconsistent” complaint to a root cause you can actually fix.

Sources

• Windows Autopilot device preparation known issues
• Overview of Windows Autopilot device preparation
• Set up enrollment time grouping - Microsoft Intune
• Windows Autopilot device preparation user-driven Microsoft Entra join - Create a Windows Autopilot device preparation policy
• How to manage local administrators on Microsoft Entra joined devices