Fix Windows Autopilot Hybrid Join When User-Driven Deployment Does Not Grant Administrator Rights

If your Windows Autopilot user-driven hybrid join profile is set to User account type = Administrator, but the person enrolling the device still lands on the desktop without local admin rights, stop blaming the profile assignment first.

Microsoft documents a specific known issue for this branch: user-driven hybrid Microsoft Entra deployments might not grant Administrator rights even when the Windows Autopilot profile says they should. The trigger is not usually that the profile failed to download. The trigger is that another account already has Administrator rights on the device before Autopilot finishes.

That matters because the symptom looks like an Autopilot policy failure, but the root cause is usually earlier in the build sequence. A PowerShell script, hardening task, OEM step, or local account workflow created another local administrator too early, and the enrolling user never gets added the way the profile setting led the team to expect.

Quick Fix checklist

Use this order before you rebuild the profile or rerun the connector:

1. Confirm the deployment is Windows Autopilot user-driven and Microsoft Entra hybrid joined.
2. Open the assigned Windows Autopilot deployment profile and verify User account type = Administrator.
3. On an affected device, list the current members of the local Administrators group.
4. Check whether a script, policy, OEM task, or technician action created another admin account before Autopilot finished.
5. Remove or delay that extra local-admin creation step until after Autopilot completes.
6. Retest one pilot device from OOBE.
7. Verify the enrolling user is now in the local Administrators group.
8. Only after that should you revisit profile assignment, ODJ connector health, or hybrid-join plumbing.

If an unexpected local admin account already exists during OOBE, you are likely in the exact Microsoft-known issue.

What Microsoft is actually saying

Microsoft’s Windows Autopilot known issues page describes the issue this way:

Windows Autopilot user-driven hybrid Microsoft Entra deployments don't grant users Administrator rights even when specified in the Windows Autopilot profile

Microsoft then explains the trigger in one sentence:

This issue occurs when there's another user on the device that already has Administrator rights. For example, a PowerShell script or policy could create another local account that is a member of the Administrators group. To ensure this works properly, don't create another account until after the Windows Autopilot process is complete.

That wording is more useful than it looks.

It tells you:

• the scope is user-driven Autopilot
• the scope is specifically Microsoft Entra hybrid join
• the problem is about the local Administrators group result
• the trigger is usually another admin-capable account appearing too early
• the first fix is usually sequencing, not rebuilding Autopilot from scratch

Why admins misdiagnose this one

When the profile says Administrator, most teams assume the privilege decision is only controlled by the profile. Microsoft’s profile documentation is more specific than that. The Configure Windows Autopilot profiles article says:

User account type: Select the user's account type (Administrator or Standard user). We allow the user joining the device to be a local Administrator by adding them to the local Admin group. We don't enable the user as the default administrator on the device.

That means the expected outcome is not some hidden special elevation token. The expected outcome is simpler:

• the enrolling user should be added to the local Administrators group
• the built-in Administrator account is not what Autopilot is enabling
• if other local-admin logic runs first, the resulting membership state can drift away from what the deployment team expected

In real environments, this issue often appears after one of these changes:

• a remediation script creates a break-glass local admin during OOBE
• an OEM image or task sequence leaves behind a staging admin account
• a hardening script adds a service or support account to Administrators too early
• a local account management policy is scoped to Autopilot devices before first-run provisioning is complete
• a technician signs in or stages the device in a way that changes local group membership before the user-driven flow finishes

The tenant can be healthy. The profile can be assigned correctly. The ODJ connector can be fine. The user still lands as non-admin because the wrong account was established as the device-side administrator first.

Root cause in plain English

This known issue is really about timing and local-group state, not just profile intent.

For user-driven hybrid join, Windows Autopilot has to complete several moving parts in sequence:

1. download the Autopilot profile
2. authenticate the user
3. process hybrid-join requirements
4. complete MDM enrollment
5. apply the expected local account type outcome

Microsoft also notes in the hybrid-join deployment documentation that this scenario depends on extra infrastructure such as the Intune Connector for Active Directory and hybrid-join prerequisites. That already makes the workflow more fragile than cloud-native Microsoft Entra join.

If another account is placed in the local Administrators group before the Autopilot process is finished, the final account-type result can stop matching what the profile promised. That is why this problem behaves like a privilege-sequencing issue rather than a pure profile-download issue.

Where to check first

1. Confirm the profile really requests Administrator

In Intune admin center go to:

Devices > Windows > Windows enrollment > Deployment profiles

Open the profile assigned to the affected Autopilot device and verify:

• deployment mode is the intended user-driven mode
• join type is the intended Microsoft Entra hybrid joined path
• User account type is set to Administrator
• the profile is actually assigned to the device or the correct Microsoft Entra group

Do not skip this check. You want proof that the profile intent is correct before you blame device-side sequencing.

2. Check the local Administrators group on the affected device

If the device already reached the desktop, check who is in Administrators:

Get-LocalGroupMember -Group Administrators |
  Select-Object Name, ObjectClass, PrincipalSource

A second quick view:

net localgroup administrators

What you are looking for:

• unexpected local users
• support or staging accounts created too early
• OEM or script-created accounts that were not part of the intended design
• the enrolling user missing from the group even though the profile says Administrator

3. Check the current user’s effective rights

Run:

whoami /groups

If the enrolling user is not effectively in the local Administrators group, the symptom is confirmed.

4. Review any script or policy that touches local accounts during OOBE

This is often where the real answer lives.

Look for:

• PowerShell scripts that use New-LocalUser, Add-LocalGroupMember, or net localgroup
• endpoint hardening steps that create or rename local admins
• OEM or imaging actions that leave a deployment account in place
• custom provisioning steps designed for help desk or bench engineers

If one of those steps runs before Autopilot completes, it is a prime suspect.

5. Confirm the hybrid-join path is not also failing for a separate reason

This known issue explains missing admin rights. It does not explain a broken enrollment.

Run:

dsregcmd /status

Use it to confirm the device is actually on the expected join path and not failing for a different reason entirely.

If the device never completed hybrid join or never enrolled correctly, you may have two problems at once.

Logs and evidence to collect

Autopilot event log

Microsoft’s Autopilot troubleshooting FAQ says to review:

Application and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot

You can pull the latest entries with:

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

This will not always name the admin-rights issue directly, but it helps you verify:

• the profile was retrieved
• the Autopilot flow progressed normally
• you are not dealing with a more basic profile or tenant failure

Autopilot diagnostics CAB

Before the device is reset again, collect a diagnostics CAB:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot -cab C:\Temp\autopilot-hybrid-admin-rights.cab

Local admin membership snapshot

Capture the exact local admin state for your incident notes:

Get-LocalGroupMember -Group Administrators |
  Sort-Object Name |
  Format-Table Name, ObjectClass, PrincipalSource -AutoSize

If you want a quick before-and-after proof during pilot remediation, run that command both before and after you remove the early admin-creation step.

Practical remediation workflow

Step 1: Identify the extra administrator source

Find out what created or preserved the other admin account.

Common sources:

• custom PowerShell in Intune
• packaging or imaging leftovers
• local admin bootstrap steps from older hybrid-join runbooks
• support-account creation done for convenience during staging

Do not treat this as a theoretical possibility. Prove which step owns the extra admin membership.

Step 2: Delay that step until after Autopilot finishes

Microsoft’s workaround is clear: don’t create another account until after the Windows Autopilot process is complete.

That usually means one of these changes:

• move the script so it runs after enrollment finishes
• scope the policy away from OOBE-stage devices
• remove the temporary staging account from the base process
• replace the local account workflow with a post-provisioning support method

Step 3: Retest one clean pilot device

Re-test from OOBE with one device that previously failed.

Validate all of the following:

• the user-driven hybrid deployment completes
• the enrolling user reaches the desktop
• Get-LocalGroupMember -Group Administrators now includes the enrolling user
• no unexpected local admin account appears before completion

Step 4: Only then investigate profile assignment noise

If the extra-admin sequencing is clean and the user still does not get admin rights, then expand the investigation to:

• profile assignment coverage
• stale device records
• hybrid-join timing problems
• connector-side failures
• conflicting local account management policy

But do that second, not first.

PowerShell checks you can keep in the runbook

List current local admins

Get-LocalGroupMember -Group Administrators |
  Select-Object Name, ObjectClass, PrincipalSource

Search common scripts for local-admin creation commands

Select-String -Path 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\*.log' -Pattern 'Add-LocalGroupMember|New-LocalUser|net localgroup' -SimpleMatch

Confirm current join state

dsregcmd /status

Capture Autopilot log evidence

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Prevention

To keep this from coming back in the next rollout wave:

1. Do not create local support or break-glass accounts during OOBE unless you have validated the side effects on user-driven hybrid join.
2. Keep local-admin changes out of early Autopilot scripts.
3. Pilot any account-management policy on a small hybrid-join group before broad rollout.
4. Document the expected Administrators group membership for Autopilot-built devices.
5. Prefer cloud-native Microsoft Entra join for new devices where possible. Microsoft explicitly says hybrid join is not the recommended path for new deployments.

Bottom line

If Windows Autopilot user-driven hybrid join is set to Administrator but the enrolling user still lands as a standard user, the fastest high-value check is not the ODJ connector. It is the local Administrators group.

When another account already has admin rights before Autopilot finishes, Microsoft says this exact issue can happen. Fix the sequencing, re-test one clean device, and the profile usually starts behaving the way the deployment team expected.