Fix Auto MDM Enroll Failed 0x8018002b in Intune GPO Enrollment

Auto MDM Enroll: Failed (Unknown Win32 Error code: 0x8018002b) is one of those Intune errors that looks like a client problem but usually points back to tenant scope, identity, or the wrong credential type in Group Policy. You see the device in Active Directory. You may even see it as Microsoft Entra hybrid joined. But the automatic MDM task keeps failing under Microsoft > Windows > EnterpriseMgmt, and the endpoint never becomes a managed Intune device.

This guide is for Desktop Engineers and Intune admins cleaning up Windows automatic enrollment for domain-joined or hybrid joined endpoints. The goal is to separate the three common failure zones: Microsoft Entra identity state, Intune automatic enrollment scope, and the local Group Policy setting that triggers MDM enrollment.

What 0x8018002b usually means

Microsoft documents 0x8018002b under Windows automatic MDM enrollment failures. The symptom appears in two places on the client:

Task Scheduler: Microsoft > Windows > EnterpriseMgmt > Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID
Event Viewer: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin, often as Event ID 76

The event text normally says:

Auto MDM Enroll: Failed (Unknown Win32 Error code: 0x8018002b)

Microsoft lists two primary causes: the user’s UPN contains an unverified or non-routable domain such as .local, or the Intune MDM user scope is set to None. In practice, the same investigation should also confirm that the device is actually hybrid joined, that the automatic enrollment GPO is configured with the correct Microsoft Entra credential option, and that Windows enrollment restrictions are not blocking Windows MDM.

Do not start by deleting random enrollment registry keys. That can be appropriate for stale enrollment cleanup, but 0x8018002b often means the client cannot get the right identity or enrollment authority context in the first place. If you wipe local state before checking tenant scope, the device will just fail again on the next scheduled run.

Confirm the client symptom before changing Intune

Start on one affected device. You need to prove whether this is an automatic enrollment failure, an Autopilot failure, or a stale previous enrollment.

Open Event Viewer and check:

Applications and Services Logs
  Microsoft
    Windows
      DeviceManagement-Enterprise-Diagnostics-Provider
        Admin

Filter for Event ID 76 and search the event text for 0x8018002b. Then check Task Scheduler:

Task Scheduler Library
  Microsoft
    Windows
      EnterpriseMgmt

Look for the enrollment task named similar to Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID. If the task exists and its last run result maps to 0x8018002b, you are in the GPO automatic MDM enrollment path.

Next, run:

dsregcmd /status

For a normal hybrid join plus Intune auto-enrollment scenario, the important fields are:

AzureAdJoined : YES
DomainJoined  : YES
AzureAdPrt    : YES

If AzureAdJoined is NO, stop and fix hybrid join first. Automatic MDM enrollment through this path depends on a working Microsoft Entra device identity. If AzureAdPrt is NO, the user sign-in token path is suspect. That often points to user UPN, federation, proxy, or device registration health rather than an Intune policy problem.

Fix the tenant-side MDM user scope

The fastest tenant check is the Intune automatic enrollment setting. In the Microsoft Intune admin center, go to:

Devices > Enrollment > Windows > Automatic Enrollment

Or from the Microsoft Entra admin center path:

Microsoft Entra ID > Mobility (MDM and MAM) > Microsoft Intune

Check MDM user scope:

None disables automatic MDM enrollment for all users.
Some enables automatic MDM enrollment only for the selected users or groups.
All enables automatic MDM enrollment for all users.

For a pilot, Some is usually the right choice. Confirm the affected user is directly or indirectly in the selected group. For broad migration projects, All is simpler, but do not flip it during business hours unless you are ready for more devices to attempt enrollment.

Also keep the default enrollment URLs unless you have a documented reason not to. Microsoft calls out the MDM terms of use URL, discovery URL, and compliance URL in the automatic enrollment configuration. Broken custom values are rare now, but they are still worth checking in older tenants.

If the scope was None, change it to Some or All, wait for policy propagation, sign out and back in on the client, then run the scheduled task again. You can also trigger a Group Policy refresh first:

gpupdate /force

Then run the enrollment task from Task Scheduler or wait for the next automatic attempt.

Fix UPN problems before blaming the endpoint

The other Microsoft-documented cause is an unverified or non-routable UPN, such as user@contoso.local. This is common in older hybrid environments where the on-premises AD domain is not the same as the public Microsoft 365 sign-in domain.

Check the signed-in user:

whoami /upn

Then compare it with the user’s Microsoft Entra sign-in name. If the Windows sign-in UPN ends in .local or another suffix that is not verified in Microsoft Entra ID, automatic enrollment can fail because the client cannot line up the user identity with a valid cloud enrollment context.

The clean fix is to add and use a routable UPN suffix in Active Directory, such as contoso.com, then update affected users to that suffix. The high-level workflow is:

Verify the public domain in Microsoft Entra ID.
Add the same UPN suffix in Active Directory Domains and Trusts.
Update pilot users from user@contoso.local to user@contoso.com.
Confirm Microsoft Entra Connect sync has exported the updated UPN.
Have the user sign out and sign back in on the Windows device.
Recheck dsregcmd /status, then retry the enrollment task.

Do not rename the Windows device, rebuild the Autopilot profile, or remove Intune licenses as a first move. If the user token is built around a non-routable UPN, those changes do not address the enrollment decision point.

Validate the Group Policy setting

Microsoft’s GPO-based enrollment doc says the policy is under:

Computer Configuration
  Administrative Templates
    Windows Components
      MDM
        Enable automatic MDM enrollment using default Microsoft Entra credentials

If you do not see this policy, update the ADMX templates for the Windows version you manage. Microsoft notes that the latest MDM.admx is backward compatible, so stale central store templates can make the right setting disappear from Group Policy Management.

Open the policy and confirm two things:

The policy is enabled.
The credential type matches your scenario.

For most user-driven hybrid joined enrollments, use user credentials. Device credentials are used for specific supported scenarios and should not be selected casually just because the device is domain joined. The wrong credential type can create confusing behavior because the scheduled task exists, but the enrollment authority still rejects the attempt.

On the client, confirm the GPO applies:

gpresult /h C:\Temp\mdm-gpo.html
Start-Process C:\Temp\mdm-gpo.html

If the policy is missing from the report, troubleshoot OU link, security filtering, WMI filtering, inheritance blocking, and replication. If the policy applies but the task still fails, move back to identity and tenant scope.

Check enrollment restrictions and licensing

0x8018002b is mainly an automatic enrollment identity or scope error, but admins often work on it alongside other enrollment blocks. Check these before declaring the device fixed:

The user has an Intune license or a license bundle that includes Intune.
Windows MDM enrollment is allowed under enrollment restrictions.
Device limit restrictions are not blocking the user.
The device is not already enrolled under a stale object that should be retired or deleted.
The platform and ownership restrictions match your expected enrollment path.

In Intune, review:

Devices > Enrollment > Enrollment restrictions

Microsoft’s enrollment restrictions documentation separates platform restrictions from device limit restrictions. Platform restrictions can block Windows MDM enrollment. Device limit restrictions can block a user who has already hit the maximum number of enrolled devices.

A related but different error is 0x80180014, where Microsoft states that Windows MDM enrollment is disabled in the tenant and the fix is to allow Windows (MDM) in enrollment restrictions. If you see 0x80180014 on some devices and 0x8018002b on others, treat that as a signal that more than one tenant-side control may be wrong.

Practical remediation workflow

Use this order when multiple devices are failing. It prevents wasted endpoint cleanup and gives you a clean rollback point.

1. Pick one pilot user and one pilot device

Do not test against ten endpoints at once. Choose a user who should be in scope and a device that is domain joined, online, and representative of the failed population.

2. Capture the current client state

Run:

dsregcmd /status
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Select-Object TaskName, State
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 50 |
  Select-Object TimeCreated, Id, ProviderName, Message

Save the output before changing anything. If the fix works, this becomes your baseline for the rest of the rollout.

3. Confirm tenant automatic enrollment scope

Set MDM user scope to Some or All. If using Some, confirm the pilot user is in the selected group and that group membership has had time to update.

4. Confirm the UPN is routable

Run whoami /upn. If the suffix is .local or another unverified domain, fix the AD UPN suffix and sync before continuing. Retrying enrollment before the user signs in with the corrected UPN is usually a waste of time.

5. Confirm the GPO applies

Run gpupdate /force, then generate a gpresult report. Confirm the automatic MDM enrollment policy appears under computer settings.

6. Retry enrollment

Sign out and sign in again. Then run the scheduled task manually or wait for the next run. Recheck Event Viewer. A successful run should create or update the Intune enrollment state, and the device should appear in Intune after normal service-side delay.

7. Scale the fix

Once the pilot works, apply the UPN, scope, or GPO correction to the affected OU or user group. Track failures separately instead of assuming every remaining device has the same root cause.

Caveats that cause repeat failures

Hybrid join and MDM enrollment are related, but they are not the same state. A device can be hybrid joined and still fail Intune enrollment if the user is outside MDM scope. A user can be in MDM scope and still fail if the Windows sign-in UPN is not a verified Microsoft Entra domain. A GPO can apply and still fail if the credential option does not match the supported enrollment path.

Also watch for timing. Microsoft Entra Connect sync, group membership evaluation, Group Policy refresh, and Intune device inventory do not update at the same speed. After you change scope or UPN, give the client a fresh sign-in and give the services time to catch up before you declare the fix failed.

Finally, avoid using registry cleanup as a blanket fix. Removing enrollment keys can help when a device has stale enrollment artifacts, but it is not the first-line fix for 0x8018002b. If tenant scope is None or the user signs in with user@domain.local, the next enrollment attempt will fail for the same reason.

Conclusion

Auto MDM Enroll: Failed 0x8018002b is usually not a mysterious Windows client defect. Treat it as an enrollment authority problem until proven otherwise. Confirm the event, verify hybrid join with dsregcmd /status, check Intune MDM user scope, fix non-routable UPNs, and then validate the automatic MDM enrollment GPO.

That order gives you a clean path from symptom to root cause. It also keeps you from rebuilding healthy endpoints when the actual failure is a tenant setting or identity mismatch.