Fix Autopilot Device Preparation When Local Administrator Settings Skip Provisioning

If Windows Autopilot device preparation keeps dropping users to the desktop without the apps you marked as required, and the policy is set for Standard user, check the Microsoft Entra Local administrator settings before you repackage apps or rebuild the deployment profile.

Microsoft documents a specific compatibility problem here. When the Windows Autopilot device preparation policy uses User account type = Standard user, and the Microsoft Entra setting Registering user is added as local administrator on the device during Microsoft Entra join is configured the wrong way, provisioning gets skipped. The user can still reach the desktop, but the deployment does not finish the way desktop engineers expect. That is why this issue gets misread as an app-delivery problem even though the real fault is in the admin-role logic.

Quick fix checklist

Use this order during an active rollout incident:

1. Open the affected Windows Autopilot device preparation policy and confirm User account type is set to Standard user.
2. In Microsoft Entra ID > Devices > Device settings, check Local administrator settings.
3. Look specifically at Registering user is added as local administrator on the device during Microsoft Entra join.
4. If that Entra setting is Selected or None while the device preparation policy is Standard user, treat it as the documented conflict branch.
5. Check whether failed users reached the desktop without the expected required apps or scripts.
6. Change to one of Microsoft’s supported setting combinations before retesting.
7. Retest one pilot device first. Do not fan the change out to the full batch until one device completes cleanly.

This is one of those cases where a clean app package and a healthy network still produce a bad user outcome because the wrong control plane setting wins.

What Microsoft is actually saying

Microsoft’s Windows Autopilot device preparation known issues page describes a compatibility problem between:

• the device preparation policy User account type setting, and
• the Microsoft Entra Local administrator settings for the user performing Microsoft Entra join.

The exact failure pattern matters:

When the Windows Autopilot device preparation policy User account type setting is set to Standard user and the Microsoft Entra ID setting Registering user is added as local administrator on the device during Microsoft Entra join under Local administrator settings is set to either Selected or None, provisioning gets skipped during a Windows Autopilot device preparation deployment.

Microsoft also says this conflict can leave you in a misleading state where users reach the desktop without having the expected applications installed.

That single sentence explains a lot of ugly tickets:

• “Autopilot looked like it finished, but the machine is missing half the build.”
• “Required apps never installed, but the user still got through OOBE.”
• “The profile is assigned and enrollment worked, so why did provisioning not block?”

If those symptoms line up with a Standard user deployment, the local-admin setting deserves priority over app-side debugging.

Why this setting combination breaks device preparation

Microsoft’s step-by-step user-driven Microsoft Entra join device preparation tutorial says that when a device is joined to Microsoft Entra ID, the user is added to the local Administrators group by default. The same doc says that if User account type is set to Standard User, device preparation removes that user from the Administrators group before deployment completes and before the user reaches the desktop.

That means device preparation is already trying to control the user’s final privilege state.

Separately, the Microsoft Entra local-admin documentation says the device registration policy also controls whether the user performing Microsoft Entra join becomes a local administrator. Microsoft exposes that behavior through the device registration policy property:

azureADJoin.localAdmins.registeringUsers

So you effectively have two different control points trying to influence the same outcome:

1. Microsoft Entra device registration policy decides whether the joining user becomes a local admin during join.
2. Windows Autopilot device preparation decides whether the final user account type should be Administrator or Standard user by the time provisioning ends.

When those settings disagree in the wrong way, Microsoft says provisioning can be skipped.

This is also why the issue fools experienced admins. The tenant is not broken. Enrollment can still happen. The user can still sign in. The failure shows up in the part of the workflow that decides whether provisioning fully completes with the expected app and script delivery.

Where to check first

1. The device preparation policy

Go to the Microsoft Intune admin center:

Devices > Windows > Enrollment > Device preparation policies

Open the affected policy and verify:

• Deployment mode
• Join type
• User account type
• assigned user group
• required apps and scripts

If User account type is Standard user, keep following this branch.

2. Microsoft Entra device settings

Go to:

Microsoft Entra ID > Devices > Device settings

Then inspect the setting Microsoft calls:

Registering user is added as local administrator on the device during Microsoft Entra join

Do not confuse this with Additional local administrators on all Microsoft Entra joined devices. That role-based setting is separate. The conflict Microsoft documents is about the registering user behavior during join.

3. The deployment outcome in practice

This issue usually surfaces as a user-experience mismatch, not a dramatic hard stop. Check whether the affected device:

• reached the desktop before expected apps finished
• skipped required build steps
• looks enrolled but incomplete
• shows a help desk symptom that sounds like “Autopilot did not block long enough”

That pattern is much more consistent with this setting conflict than with a broken installer.

4. Local admin state after sign-in

If the device already reached the desktop, verify the resulting local group membership:

Get-LocalGroupMember -Group Administrators

And confirm the current user’s effective group membership:

whoami /groups

These checks do not prove the root cause by themselves, but they help confirm whether the final privilege state matches the intended design.

The Microsoft-supported setting combinations

Microsoft does not just describe the problem. The known-issues page also lists the supported combinations to use until the issue is fixed.

If the user should end up as a standard user

Microsoft documents three supported combinations:

Intended outcome	Microsoft Entra local administrator setting	Device preparation User account type
Standard user option 1	None	Administrator
Standard user option 2	Selected and the standard users are not selected	Administrator
Standard user option 3	All	Standard user

The third one is the easiest to misread. It looks backwards at first glance, but it is the exact combination Microsoft lists for a standard-user end state in this known-issue branch.

If the user should end up as a local administrator

Microsoft lists two supported combinations:

Intended outcome	Microsoft Entra local administrator setting	Device preparation User account type
Administrator option 1	All	Administrator
Administrator option 2	Selected and the administrator users are selected	Administrator

The practical takeaway is simple: do not leave device preparation at Standard user and pair it with Entra Local administrator settings of Selected or None unless you have validated the exact Microsoft-supported combination.

A practical remediation workflow

Step 1: Prove this is the conflict branch

Before changing anything, answer these questions:

1. Is the deployment using Windows Autopilot device preparation, not classic Autopilot profile flow?
2. Is Join type set to Microsoft Entra joined?
3. Is User account type set to Standard user?
4. Is the Entra setting for the registering user set to Selected or None?
5. Are users reaching the desktop without expected applications installed?

If the answer is yes across that chain, you are on the documented branch.

Step 2: Decide the real end-state requirement

Do not patch the settings blindly. Decide whether the business requirement is actually:

• the user must be a standard user, or
• the user must be a local administrator.

A lot of tenants drift into this issue because one team assumes “standard user” should be enforced in Intune while another team already tightened the Entra join behavior globally.

Step 3: Move to one supported combination

Use one of Microsoft’s supported combinations from the tables above.

For most enterprises trying to keep users non-admin, the safest thing is to standardize one approved pattern and document it in the build runbook. Do not let each admin choose a different combination per profile.

Step 4: Retest one pilot device

Retest with one device that previously reproduced the problem. Watch for these outcomes:

• OOBE blocks as expected while required apps install.
• The user does not reach the desktop too early.
• The final local-admin state matches the design.
• Required apps and scripts show the expected status.

If the device now finishes correctly, the settings conflict was your primary blocker.

Step 5: Check the rest of the policy only after the settings are clean

Once the local-admin conflict is fixed, then validate the normal device preparation dependencies:

• apps selected in the profile are also assigned to the device group
• scripts run in System context
• the correct assigned device group is being used
• enrollment time grouping is functioning as expected

That order matters. Otherwise you can waste time fixing app delivery that was never the first problem.

Caveats and limitations

A few limits matter here.

First, this is a device preparation issue, not a blanket explanation for every Autopilot deployment that lands on the desktop early. Classic Autopilot profiles, ESP policy choices, app assignment mistakes, and managed-installer behavior can all create similar symptoms.

Second, do not confuse the registering user local admin setting with the Microsoft Entra Joined Device Local Administrator role or with Intune account-protection policies that manage local groups later. Those are separate control paths.

Third, if the device preparation policy and Entra device settings are corrected but apps are still missing, continue with the normal assignment and reporting checks. Microsoft documents this setting conflict as one branch, not the whole tree.

Prevention

To keep this from resurfacing in the next rollout:

1. Pick one approved standard-user design for device preparation and document it.
2. Review Microsoft Entra device settings before creating new device preparation profiles.
3. Add the registering user local administrator setting to your Autopilot preflight checklist.
4. Keep a screenshot or runbook entry showing the exact supported combination your team uses.
5. When a device reaches the desktop without expected apps, check this setting conflict before blaming packaging.

Bottom line

If Windows Autopilot device preparation is set to Standard user and users are reaching the desktop without the expected build, do not start with Win32 app logs.

Start with the Microsoft-documented conflict between User account type and Registering user is added as local administrator on the device during Microsoft Entra join. Move the tenant to one of Microsoft’s supported setting combinations, retest one pilot device, and then validate the rest of the deployment.

That is the fastest path from a vague “Autopilot skipped provisioning” complaint to a clean root cause.

Sources

• Windows Autopilot device preparation known issues
• 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
• Set up enrollment time grouping in Microsoft Intune