Enrollment Configuration Priority: Why Your Second ESP Profile Never Applied

You built a second Enrollment Status Page profile for a pilot ring. You gave it a 120 minute timeout instead of the 60 minute default. You assigned it to the pilot group. Then you provisioned a pilot device and watched it time out at exactly 60 minutes. No conflict warning. No error in the portal. Nothing in the assignment report to explain it. The profile you created simply did not happen.

This is not a bug, and it is not a replication delay. It is the documented behaviour of a whole family of Intune policy that most administrators assume works like device configuration profiles. It does not. Device enrolment configurations are priority ordered, and exactly one of them wins per device. Everything else in the list is discarded silently.

The problem: the pilot profile that never applied

Here is the shape of the failure. It looks like a replication problem for about a day, and then it looks like a product bug for about a week.

A tenant has three Microsoft Entra groups that all contain the same Autopilot device. One group is the broad corporate device group. One is the pilot ring. One is the kiosk fleet. Each group is assigned its own Enrollment Status Page (ESP) profile, and each profile has different settings.

The administrator expects the pilot device to end up with a merged result. Perhaps the longest timeout wins. Perhaps the most restrictive blocking list wins. Perhaps a Conflict state appears somewhere. None of that happens.

Instead the device gets the settings from priority 1, and only from priority 1. The pilot profile and the kiosk profile might as well not exist. The symptoms line up like this.

• A newly created profile appears healthy in the portal but changes nothing on the device.
• No Conflict state is reported, because there is no conflict to report. One configuration won outright.
• Deleting the new profile changes nothing either, which reinforces the idea that something is broken.
• Moving a device between groups changes nothing, as long as the broad profile still matches it.
• The behaviour is consistent, repeatable and identical on every device. Replication problems are not.

Why it happens: priority ordered, not merged

The reason is a single sentence in the Microsoft Graph reference. It is worth reading twice, because it is the whole post.

Priority is used when a user exists in multiple groups that are assigned enrollment configuration. Users are subject only to the configuration with the lowest priority value.

That is the documented description of the priority property on the deviceEnrollmentConfiguration resource type, in both the v1.0 and the beta Graph references. Note the direction. Lowest priority value means the smallest number. Priority 1 beats priority 2. The Intune documentation for the Enrollment Status Page says the same thing in portal language: the profile set to 1 has the highest priority.

The documented evaluation order for ESP

For Enrollment Status Page profiles specifically, Microsoft documents a three step order. It is not just a numeric sort, because device targeting outranks user targeting.

1. Intune applies the highest priority profile assigned to the device.
2. If no profiles are targeted at the device, Intune applies the highest priority profile assigned to the user. This only works where there is a user. In pre-provisioning and self-deploying scenarios, Intune only applies profiles targeted at devices.
3. If no profiles are assigned to the device or the user, Intune applies the Default ESP profile.

So a device-targeted profile at priority 9 beats a user-targeted profile at priority 1. That single rule explains a large share of the "my profile is being ignored" reports. It is also invisible in the portal, because the priority column does not tell you whether a group holds users or devices.

What is additive, and what is single winner

This is the distinction that catches people out. Both models are documented, and they are genuinely different.

Which configuration types are in the priority family

The Graph beta reference exposes a deviceEnrollmentConfigurationType property whose enum tells you exactly which object types share this behaviour. Members with a default prefix are the built-in baselines.

Two precision points here, because getting them wrong is easy.

First, the Windows Hello for Business item under Devices > Enrollment is documented as a tenant-wide policy. It configures Windows Hello at the moment a device enrols. The admin center does not offer group assignment on it. For Windows Hello on discrete groups of devices, Microsoft points you at endpoint security Account protection policy, security baselines or the settings catalog. Those are ordinary configuration policies, and they use merge semantics rather than priority.

Second, Autopilot deployment profiles are not in this family. They are a different Graph resource with their own assignment rules. This post is not about them.

How shadowing actually forms

A profile is shadowed when every group it is assigned to is also assigned to a higher priority profile in the same family. Once that is true, there is no device or user anywhere in the tenant for which the lower profile can win. It is dead configuration that still looks alive.

Two variants cause almost all of it.

• The broad profile at the top. Someone assigned an early profile to a catch-all group, or to All users or All devices, and left it at priority 1. Everything created afterwards lands underneath it and never runs.
• The overlapping membership. The broad profile is assigned to three groups, one of which is the pilot group. The pilot profile is assigned to the pilot group only. The pilot group is a subset, so the pilot profile can never win.

Assignment filters complicate this, because a filter can carve members out of the higher priority profile and let the lower one through. Microsoft documents that only a restricted set of filter properties is available on enrolment policies. The device is not enrolled yet, so Intune does not have its full inventory. For Windows, the always-available properties are OS version, operating system SKU, ownership and enrolment policy name. Manufacturer and model need Windows 11 version 22H2 or later with KB5035942 or later. The documentation also warns that this processing is not instant. User, group and filter assignments between Microsoft Entra and Intune typically take around 15 minutes. So do not enrol a device immediately after changing group membership.

How to verify: read the list, then read the device

There are three places to look, and you want all three. The portal tells you the intended order. Graph tells you the order plus the assignments in one payload. The device tells you what actually arrived.

1. Read the priority list in the admin center

For the Enrollment Status Page:

For device platform restrictions:

For the Windows Hello for Business enrolment policy:

2. Read the whole family from Graph in one call

This is the fastest reliable read, because it returns priority and assignments together. The v1.0 endpoint is GET /deviceManagement/deviceEnrollmentConfigurations, and the least-privilege permission is DeviceManagementServiceConfig.Read.All, for both delegated and application calls.

If you need to know why a specific profile lost, read its assignments and compare group membership. The assignments relationship returns enrollmentConfigurationAssignment objects, each with a target, a source of either direct or policySets, and a sourceId. A source of policySets means the assignment came from a Policy Set rather than from someone editing the profile. Worth knowing before you go hunting for who did it.

3. Read what actually arrived on the device

The portal shows intent. The device shows outcome. Microsoft documents that all ESP settings and tracking information are logged in the device registry. The supported way to collect them is the MDM diagnostics tool.

The two keys that matter carry long paths, so here they are once, on their own.

Those subkeys and values are documented in the Microsoft ESP troubleshooting guide. Here is the reference table for the tracking key above.

4. Audit the whole tenant for shadowed configurations

Reading one profile at a time does not scale. The interesting failure is a relationship between two profiles, not a property of either one. The companion script does the pairwise comparison for you.

It connects with DeviceManagementServiceConfig.Read.All, issues GET requests only, groups every configuration into its family, sorts by priority, and then flags three conditions. SHADOWED means a lower priority configuration's assigned groups are all also assigned to a higher priority one. BROAD-ABOVE means a higher priority configuration targets All users or All devices. NO-ASSIGN means a non-default configuration has no assignments at all and therefore never applies to anyone.

The fix: reorder priority and tighten assignments

There are two levers. Reordering is the quick one. Fixing the assignment shape is the one that stops the problem coming back.

Reorder Enrollment Status Page profiles

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, expand Device onboarding, then select Enrollment.
3. On the Windows tab, under Windows Autopilot, select Enrollment Status Page.
4. Hover over a profile in the list until three vertical dots appear.
5. Drag the profile to the position you want. The narrowest, most specific profile belongs at the top, at priority 1.
6. Confirm the new order in the Priority column before you leave the blade.

Reorder device platform restrictions

1. Go to Devices > Device onboarding > Enrollment.
2. Under Enrollment options, select Device platform restriction.
3. Select the platform tab you are changing, for example Windows restrictions.
4. In the Device type restrictions table, select and drag the restriction to reposition it.

The same drag pattern applies to enrolment device limit restrictions and to enrolment notifications. In Graph the equivalent is POST /deviceManagement/deviceEnrollmentConfigurations/{id}/setPriority with a body of { "priority": 8 }, which returns 204 No Content. That call needs DeviceManagementServiceConfig.ReadWrite.All or DeviceManagementConfiguration.ReadWrite.All, so it is deliberately outside the scope of the read-only audit script.

Then fix the assignment shape

Reordering alone leaves you one new profile away from the same incident. Four rules keep the list honest.

• Use the Default profile as your broad baseline. That is exactly what it is for. Microsoft documents that Intune applies the default profile to all users and all devices when no other profile is available to assign. It also applies when no other profiles are assigned to the device or the user. It sits at the bottom of the list and it is not draggable, which is a feature: you cannot accidentally make it shadow anything.
• Do not assign a non-default profile to All users, All devices or a catch-all group. The moment you do, everything below it in that family is dead. If you already have one, move its settings into the Default profile and remove the broad assignment.
• Keep the specific profiles narrow and non-overlapping. If two profiles must overlap, be deliberate about which one is higher, and write down why.
• Target devices, not users, for pre-provisioning and self-deploying. Microsoft states that in those scenarios Intune only applies profiles targeted at devices. A user-targeted profile there is not merely lower priority, it is out of the running entirely.

There is no Group Policy equivalent

Proof it worked: a clean shadow report

Proof for this class of problem has to be structural, not anecdotal. One successful pilot enrolment does not tell you the ordering is right, because the broad profile may simply have matched what you wanted this time. What you want is the audit coming back with nothing to say.

The fix applied to the example tenant was this. Move the pilot profile to priority 1. Move the kiosk profile to priority 2. Drop the pilot and kiosk groups from the broad profile so it targets only the corporate group. Push the broad profile to priority 3. Delete the unassigned lab profile.

Then confirm on hardware. Provision one device from the pilot group and collect the diagnostics cab with mdmdiagnosticstool.exe -area Autopilot. Then check that the settings under the FirstSync subkey match the pilot profile rather than the broad one. That is the only evidence that closes the loop, because it is the only place the device tells you what it was actually handed.

Two sizing limits are worth noting while you are in there, and both are documented. A tenant can hold a maximum of 51 ESP profiles, being the Default plus 50. It can hold up to 25 device platform restriction policies. If you are anywhere near either number, shadowed profiles are almost certainly part of the reason.

The mental model to keep is short. Device configuration profiles are a set union. Enrolment configurations are a race. Once you know which family a policy belongs to, the behaviour stops being surprising.

References

• Set up the Enrollment Status Page — Microsoft Intune. The Prioritize profiles section, the three step evaluation order and the Default profile behaviour. Also the 51 profile limit, the quality updates targeting note and the known issues list.
• deviceEnrollmentConfiguration resource type — Microsoft Graph v1.0. The documented priority property description.
• deviceEnrollmentConfiguration resource type — Microsoft Graph beta. Adds deviceEnrollmentConfigurationType and roleScopeTagIds.
• List deviceEnrollmentConfigurations — Microsoft Graph v1.0. The endpoint and the least-privilege permission.
• setPriority action — Microsoft Graph v1.0. The write call and the permissions it needs.
• deviceEnrollmentConfigurationType enum type — Microsoft Graph beta. The full list of configuration families.
• enrollmentConfigurationAssignment resource type — Microsoft Graph beta. The target, source and sourceId properties.
• Overview of enrollment restrictions — Microsoft Intune. The default policy behaviour and the list of enrolment scenarios that always get the default.
• Create device platform restrictions — Microsoft Intune. Reordering, the 25 policy limit, the RBAC requirement and the supported filter properties.
• Questions with policies and profiles in Microsoft Intune. How device configuration and compliance conflicts are resolved at the individual setting level.
• Configure a tenant-wide Windows Hello for Business policy with Microsoft Intune. Confirms the enrolment-time policy is tenant wide, and points at Account protection for group scoping.
• Windows Hello for Business policy settings — Microsoft Learn. The Group Policy and CSP surface for the client-side settings.
• Troubleshoot the Enrollment Status Page — Intune. The FirstSync and EnrollmentStatusTracking registry keys, the value meanings and the log files to collect.
• EnrollmentStatusTracking CSP — Windows client management. The CSP behind the tracking registry data.
• Set up enrollment notifications in Intune. Confirms notifications carry a priority level, and that exclude is unavailable.