Fix Auto MDM Enroll Failed 0x8018002b in Intune GPO Enrollment

Microsoft documents two causes for 0x8018002b: MDM user scope is set to None, or the user’s UPN uses an unverified or non-routable domain such as joe@contoso.local. To fix it, set MDM user scope to Some (with the user in a selected group) or All, and set MAM user scope to None. Then move affected users to a verified UPN suffix and let Microsoft Entra Connect sync before the next enrollment attempt.

Both fixes are on the tenant or identity side. Don’t wipe enrollment registry keys or rebuild the device first. The next scheduled attempt will fail the same way until scope and UPN are right.

Symptoms and exact error text

This article covers Windows devices that are domain joined and use the Group Policy setting Enable automatic MDM enrollment using default Microsoft Entra credentials to enroll in Intune. Microsoft’s Windows enrollment troubleshooting article describes two symptoms:

• In Task Scheduler, under Microsoft > Windows > EnterpriseMgmt, the last run result of the Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID task is:

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

• In Event Viewer, under Applications and Services Logs/Microsoft/Windows/DeviceManagement-Enterprise-Diagnostics-Provider/Admin, Event ID 76 is logged at level Error with the source DeviceManagement-Enterprise-Diagnostics-Provider.

Microsoft’s sample event description prints the code as 0x80180002b, with an extra zero. That looks like a typo in the doc. Search your logs for 8018002b so you match either form.

The device can show as Microsoft Entra hybrid joined and still log this error. Hybrid join and Intune enrollment are separate steps, and 0x8018002b comes from the enrollment step.

When this is a different problem

What you see	Where to go
dsregcmd /status shows AzureAdJoined : NO	Hybrid join hasn’t finished. Fix that first, for example hybrid join error 0x801c001d if the device can’t read the SCP.
Error 0x80180018 instead	Licensing or a MAM/WIP precedence issue: Intune enrollment error 0x80180018
0x80180014, “Your organization does not support this version of Windows”	Windows MDM blocked by an enrollment restriction: Autopilot error 0x80180014
Neither Event 75 nor Event 76 is logged	The enrollment task never ran. See The task never runs below.

For a side-by-side view of the other Windows enrollment codes, see Intune enrollment errors: 0x80180014, 0x80180018, 0x8018000A.

Fix 1: Set the automatic enrollment scopes

Start here. It’s one tenant setting, and changing it doesn’t touch any device.

1. Sign in to the Microsoft Intune admin center with an account that has the Global Administrator role. That’s the role Microsoft lists for this page.
2. Go to Devices, expand Device onboarding, and select Enrollment. On the Windows tab, select Automatic Enrollment.
3. If you see both Microsoft Intune and Microsoft Intune Enrollment, configure Microsoft Intune. Microsoft’s auto-enrollment troubleshooting guide calls this out.
4. Set MDM user scope:
   • None disables automatic MDM enrollment for all users. This is one of the two documented causes of 0x8018002b.
   • Some enables it for the groups you select. Confirm the affected user is in one of them.
   • All enables it for all users.
5. Set MAM user scope to None. Microsoft’s fix for this error includes that step. Some portals label it WIP user scope. If it has to stay on, keep its users out of the MDM user scope. (How MDM and MAM scope precedence works on personal devices is covered in the 0x80180018 article.)
6. Leave MDM terms of use URL, MDM discovery URL, and MDM compliance URL at their defaults. The discovery URL should be https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc.
7. Save.

If you don’t see the automatic enrollment settings at all, check licensing. Microsoft’s automatic enrollment setup page says automatic MDM enrollment is a Microsoft Entra ID P1 or P2 feature.

For a pilot I’d use Some with a small group. Switching to All makes every user eligible for automatic enrollment, so every device that gets the GPO can start enrolling. Plan that change.

Microsoft’s troubleshooting article gives a second route: in the Azure portal, open Microsoft Entra ID > Mobility (MDM and MAM) > Microsoft Intune. The settings are the same.

Fix 2: Move users off a non-routable UPN

The second documented cause is a UPN with an unverified or non-routable domain, such as .local. On the affected device, check what the signed-in user is using:

whoami /upn

If the suffix isn’t a domain verified in your Microsoft Entra tenant, follow Microsoft’s steps:

1. On the AD DS server, open Active Directory Users and Computers (dsa.msc).

2. For one user, open Properties > Account. Under User logon name, pick a valid UPN suffix such as contoso.com from the drop-down list. For several users, select them all, open Action > Properties > Account, check UPN suffix, and pick the valid suffix.

3. Wait for the next sync, or force a delta sync on the Microsoft Entra Connect server from an elevated PowerShell prompt:

   Import-Module ADSync
   Start-ADSyncSyncCycle -PolicyType Delta

Microsoft also points to configuring Alternate Login ID as another option, and says to read that article before you choose it.

After the sync, have the user sign out and back in so Windows picks up the new UPN before the task retries.

Check the GPO and the task

These checks don’t fix 0x8018002b on their own. They confirm the device is on the enrollment path that produces the error.

The policy is Computer Configuration > Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Microsoft Entra credentials (GPO enrollment doc). Microsoft’s procedure enables it with User Credential under Select Credential Type to Use. Device Credential is only supported for Intune enrollment with co-management or Azure Virtual Desktop multi-session host pools, because the Intune subscription is user-centric. If the policy is missing from the editor, install the latest ADMX for your Windows version. Microsoft says the latest MDM.admx is backward compatible.

On the device, confirm the policy applied:

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

When the policy applies, it creates the EnterpriseMgmt task, which runs every 5 minutes for one day. Event ID 75 (Auto MDM Enroll: Succeeded) in the DeviceManagement-Enterprise-Diagnostics-Provider Admin log means enrollment worked.

The task never runs

If neither Event 75 nor Event 76 appears, enrollment wasn’t triggered. Check Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational:

• Event ID 107 means the task was triggered. Event ID 102 means it completed, whether or not enrollment succeeded.
• Event ID 7016 with error code 2149056522 means the device is already enrolled in another MDM. Unenroll it from that MDM first.
• If none of these appear, run gpupdate /force and look for a Group Policy problem in Active Directory.

Capture evidence before you change anything

Before you change scope or UPNs, save the current state from one affected device so you have a before-and-after comparison. The log name and task path below come from the Microsoft articles cited here. I haven’t run this exact block, so check the output on your own device before you rely on it:

dsregcmd /status
whoami /upn
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Select-Object TaskName, State
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 50 |
  Where-Object { $_.Id -in 75, 76 } |
  Select-Object TimeCreated, Id, Message

In the dsregcmd /status output, Microsoft’s auto-enrollment guide expects AzureAdJoined: YES and DomainJoined: YES under Device State, and AzureAdPrt: YES under SSO State.

Other prerequisites from the auto-enrollment guide

If scope and UPN are right and Event 76 continues, work through the rest of Microsoft’s verification list:

• The user has a valid Intune license.
• The device runs Windows 10, version 1709 or later.
• In Microsoft Entra device settings, Users may join devices to Microsoft Entra ID is All, and the user is under the Maximum number of devices per user quota.
• Intune enrollment restrictions allow Windows enrollment.
• The device isn’t enrolled through the classic PC agent.

FAQ

What causes Auto MDM Enroll Failed 0x8018002b?

Microsoft lists two causes: the user’s UPN uses an unverified or non-routable domain such as .local, or MDM user scope is set to None.

Do I have to set MAM user scope to None?

It’s part of Microsoft’s documented fix for this error, and the auto-enrollment guide warns that a MAM scope can take precedence over the MDM scope. If you need MAM for some users, keep those users out of the MDM user scope.

Should the GPO use User Credential or Device Credential?

Use User Credential. Microsoft supports Device Credential for Intune enrollment only with co-management or Azure Virtual Desktop multi-session host pools.

The device is hybrid joined. Why isn’t it in Intune?

Hybrid join creates the Microsoft Entra device identity. Intune enrollment is a separate step that also depends on the user’s MDM scope and UPN, and that step is where 0x8018002b comes from.

How do I know enrollment worked?

Look for Event ID 75, Auto MDM Enroll: Succeeded, in the DeviceManagement-Enterprise-Diagnostics-Provider Admin log. Then confirm the device appears in Intune.

Sources

• Troubleshoot Windows device enrollment problems in Microsoft Intune: symptoms, causes, and fix for 0x8018002b
• Troubleshoot Windows 10 Group Policy auto-enrollment in Microsoft Intune: verification list, Event IDs 75 and 76, Task Scheduler events 107, 102, and 7016
• Enable MDM automatic enrollment for Windows: portal path, scope options, default URLs, licensing, role
• Enroll a Windows device automatically using Group Policy: policy path, credential type, ADMX note
• whoami and gpresult command references