Autopilot Device Preparation Needs an Assigned Group, Not a Dynamic One

Windows Autopilot device preparation inverts a habit that most Intune teams have spent years building. Classic Autopilot rewards dynamic device groups driven by group tag or ZTDID. Device preparation refuses them, and it also requires a permission grant that almost nobody writes into their runbook. Miss it and the policy will not save the device group at all, with an error message that never names the cause.

The problem: the group you already have will not work

You have built Autopilot at scale before. Your muscle memory says the following. Create a dynamic device group. Write a membership rule against the ZTDID or the group tag. Assign your profile, your apps and your policies to that group. Let Microsoft Entra ID evaluate the rule after the device registers.

Device preparation breaks that pattern in two places at once.

The first break is the group type. The device preparation policy has a single Device group field. If you point it at one of your existing dynamic groups, the save fails. Microsoft documents the requirement in an Important block with no ambiguity. The device group specified in the Windows Autopilot device preparation policy needs to be an assigned security device group.

The second break is quieter and much more expensive. Even a perfectly correct assigned security group will be rejected unless a specific Microsoft first-party service principal has been added as an owner of that group. This is not a tenant-wide consent step you did once years ago. It is a per-group grant, on every group, that a human has to perform.

When the grant is missing, here is what the Intune admin center actually shows you. Microsoft documents two possible error strings on save.

Read those two messages again. Neither one contains the word "owner". Neither one names the service principal. The second one ends with "Something went wrong", which is the least actionable sentence in cloud management. The tell is the 0 groups assigned counter on the Device group row, which Microsoft explicitly calls out as an additional symptom of the same root cause.

There is a worse variant of this failure. Suppose the policy did save, months ago, because somebody added the owner correctly at the time. Then a cleanup exercise removes service principal owners from groups, or somebody converts the group from static to dynamic to modernise it. Provisioning does not fail loudly. Microsoft documents the outcome under a known issue titled "Security group membership update failures might lead to non-compliant devices", and lists owner removal and static-to-dynamic conversion as two of the causes. Devices reach the desktop. Group membership never lands. Everything assigned to that group is silently absent.

Why it happens: Intune writes to the group, it does not read a rule

The reason becomes obvious once you look at the direction the data flows.

A dynamic group is a pull model. You write a rule. Microsoft Entra ID evaluates that rule against object attributes and computes the membership itself. Nothing outside Entra ID ever writes a member into the group. That is exactly why a dynamic group is convenient for classic Autopilot, where the device object already carries a ZTDID and a group tag by the time the rule runs.

Device preparation is a push model, and it pushes early. The whole point of the feature is that the device joins the group during enrollment rather than after it. Microsoft calls this enrollment time grouping, and describes the benefit as preknowledge of the security group that the device will become a member of after enrollment. That preknowledge is what lets Intune deliver apps and policy during the out-of-box experience, instead of trickling them in over the following hours.

Two consequences fall out of that design.

First, there is nothing to write a rule against. At the moment membership needs to exist, the device object is brand new. It has no group tag, no inventory properties, and no meaningful attributes for a membership rule to match. A dynamic group would compute an empty membership, then maybe fix it later, which defeats the entire purpose. Hence the documented statement that device preparation only uses assigned groups.

Second, something outside Entra ID now has to write group membership. In the Microsoft Entra permission model, the standard way to grant an identity rights over one specific group is to make it an owner of that group. Graph documents owners as the set of users or service principals who are allowed to modify the group object. Intune's writer identity for this operation is a first-party service principal, and that is the object you have to grant.

Microsoft is careful about the naming here, and so should you be. The documentation says that in some tenants the service principal might have the name of Intune Autopilot ConfidentialClient instead of Intune Provisioning Client, and that as long as the AppID is f1346770-5b25-470b-88bd-d5744ab7952c it is the correct service principal. Do not build a script or a runbook check that matches on display name.

How to verify: three read-only checks before deployment day

There are exactly three group properties to confirm, plus one identity to confirm exists. Every one of them is readable with a GET request, so this belongs in your pre-deployment checklist rather than in your incident channel.

Start in the portal if you only have one or two groups. The group Overview blade shows Membership type, and the Owners blade shows the owner list.

For anything above a handful of groups, read it from Microsoft Graph. These are the calls that answer each question, with the least privileged delegated scope Microsoft documents for each one.

The ownedObjects call is the one worth knowing about, because it reads the same relationship from the other end. Instead of asking each group who owns it, you ask the service principal what it owns. One call, one answer, and the resulting list is precisely the set of groups in your tenant that can currently be used by device preparation.

The properties map cleanly onto what the portal shows you. Microsoft Graph documents that if the groupTypes collection includes DynamicMembership the group has dynamic membership, and otherwise membership is static. securityEnabled tells you it is a security group. isAssignableToRole is the Graph name for the "Microsoft Entra roles can be assigned to the group" toggle that the documented setup steps set to No.

There is one more read that costs nothing and catches drift after the fact. Intune ships a failures-only report for enrollment time grouping.

One honest limitation is worth stating. Reading which group a given device preparation policy is bound to is done through the Graph action retrieveEnrollmentTimeDeviceMembershipTarget, which is an HTTP POST, not a GET. A strictly read-only audit therefore cannot follow that link. The practical workaround is the one above. Enumerate what the service principal owns, then check the policy's Device group field in the portal to confirm the names line up.

The fix: an assigned security group with the right owner

Here is the full documented creation path. Follow it exactly, because every field on this list is load bearing.

1. Sign in to the Microsoft Intune admin center.
2. Select Groups in the left hand pane.
3. On Groups | All groups, make sure All groups is selected, then select New group.
4. For Group type, select Security.
5. For Group name, enter a name for the device group.
6. For Group description, enter a description.
7. For Microsoft Entra roles can be assigned to the group, select No.
8. For Membership type, select Assigned.
9. For Owners, select the No owners selected link.
10. In the Add owners blade, search for and select the service principal Intune Provisioning Client with AppId f1346770-5b25-470b-88bd-d5744ab7952c. Accept Intune Autopilot ConfidentialClient if that is the name your tenant shows for the same AppId.
11. Select Select, then select Create.

Do not add devices to the group by hand. Microsoft states that devices are automatically added to this device group during the deployment, that manually adding devices is not necessary, and that doing so has no impact on the process either way.

This is the prerequisite matrix in one place. Print it, or paste it into your build runbook.

The user group in the same policy plays by different rules, and mixing the two up is a common source of wasted hours.

If the service principal is missing from the tenant entirely, this is the documented way to create it. Run it as an administrator who can consent on behalf of the organisation.

Two access requirements sit around all of this and are easy to overlook. To add the Intune first-party app as a security group owner you need to be a Microsoft Entra Group Administrator, or hold the microsoft.directory/groups/owners/update permission, or already be an owner of that group. Separately, the group must be configured as a scope group for the admin who will use it in the enrollment policy.

On the Intune side, the administrator who creates the policy needs a specific permission that is not in the default roles. Create the custom role like this.

1. Sign in to the Microsoft Intune admin center.
2. Select Tenant administration, then Roles.
3. With All roles selected, choose Create, then Intune role.
4. Name the role, for example Windows Autopilot device preparation administrator, and add a description.
5. On the Permissions page set Device configurations to Read, Delete, Assign, Create and Update.
6. Set Enrollment programs to Enrollment time device membership assignment.
7. Set Managed apps to Read, Mobile apps to Read, and Organization to Read.
8. Select Next through Scope tags, then Review + create.
9. Assign the new role to whoever administers device preparation.

That "Enrollment time device membership assignment" permission is the one people forget. Without it, the troubleshooting FAQ lists a missing device group membership as one of the outcomes.

Proof it worked: what a clean readiness audit looks like

The companion script for this post is read-only. It performs GET requests only, requests four .Read.All scopes, and refuses to report a clean result if any query fails. It lists device preparation policies, resolves the Intune Provisioning Client by AppId, enumerates the groups that service principal owns, then checks each candidate group against the documented prerequisites.

The output above is illustrative. It is what the script prints, with fictional group names, not a capture from a live tenant.

Note the exit codes, because they matter if you wire this into a pipeline. Zero means every audited group meets the prerequisites. Two means the queries all succeeded and at least one group failed. One means something prevented the audit from completing, such as a missing scope or an absent service principal, in which case the script aborts rather than printing a reassuring zero-findings result.

Finally, the symptom-to-cause table. This is the lookup you want when someone pings you mid-deployment.

None of this is exotic. It is one group property and one owner grant. But it is a prerequisite that lives in Entra ID rather than in Intune, it is invisible from the policy blade until the save fails, and the error text points nowhere useful. Check it on a Tuesday, not on the morning of a hardware refresh.

References

• Windows Autopilot device preparation user-driven Microsoft Entra join - Create an assigned device group — the assigned security group requirement, the owner steps, and the service principal creation path
• Windows Autopilot device preparation troubleshooting FAQ — the two documented save errors and the 0 groups assigned symptom
• Windows Autopilot device preparation known issues — security group membership update failures, owner removal, static to dynamic conversion
• Windows Autopilot device preparation requirements — software, licensing, configuration and the RBAC permission list
• Windows Autopilot device preparation - Create a user group — confirms the user group may be assigned or dynamic
• Windows Autopilot device preparation in automatic mode for Windows 365 - Create an assigned device group — the same requirement for Cloud PCs
• Set up enrollment time grouping - Microsoft Intune — the Entra role needed to add the first-party app as owner, the scope group requirement, and the failures report
• group resource type - Microsoft Graph v1.0 — groupTypes, DynamicMembership, securityEnabled and isAssignableToRole
• List group owners - Microsoft Graph v1.0 — the note that service principals are currently not listed as group owners on v1.0
• servicePrincipals: List ownedObjects - Microsoft Graph v1.0 — the appId alternate key form and the Application.Read.All scope
• deviceManagementConfigurationPolicy resource type - Microsoft Graph beta — the enrollment technology value and the enrollment time membership target actions

Community deep dive, fetched and confirmed on topic: