You linked the Enable automatic MDM enrollment using default Microsoft Entra credentials GPO. Devices are domain joined, Entra Connect is syncing, and a week later half the fleet still is not in Intune. On one of the missing PCs, Event Viewer says Event ID 76 — Auto MDM Enroll: Failed. The usual first moves are to run dsregcmd /leave everywhere, delete enrollment registry keys, or flip the GPO to Device Credential "because that's the one for computers."
Hold off. GPO auto-enrollment is a short chain: tenant allows the user to auto-enroll (MDM user scope + license) → device is hybrid joined and the user has a PRT → GPO lands and creates the EnterpriseMgmt task → the task runs and the enrollment attempt logs Event 75 (success) or 76 (failure) → Intune-side gates (enrollment restrictions, device limits) accept the device. Most "auto-enrollment not working" tickets die in scope/licensing, a missing PRT, or the wrong credential type. This post walks them in order. Every step below only reads until the change table at the end.
If the device shows Pending in Entra or AzureAdJoined : NO, stop here and use the hybrid join Pending triage first. MDM auto-enrollment rides on top of hybrid join; it cannot fix it. If the device is already enrolled and simply not checking in, use the Company Portal / device not syncing triage instead.
TL;DR
- Microsoft's auto-enrollment checklist is: valid Intune license on the user, MDM user scope = All (or Some including the user), MAM/WIP user scope = None, default MDM discovery URL, Windows 10 1709+, and
dsregcmd /statusshowing AzureAdJoined: YES, DomainJoined: YES, AzureAdPrt: YES. - The GPO creates a task called Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID under Microsoft > Windows > EnterpriseMgmt. It runs every 5 minutes for one day. No task = the GPO never landed.
- In
DeviceManagement-Enterprise-Diagnostics-Provider/Admin, Event 75 = Auto MDM Enroll succeeded, Event 76 = failed. If you see neither, enrollment was never triggered — go back to the GPO and task. - Device Credential is only supported for Intune enrollment with co-management or Azure Virtual Desktop multi-session host pools. For ordinary user PCs, Microsoft's GPO walkthrough selects User Credential.
-
0x8018002bon Event 76 usually means a non-routable/unverified UPN suffix (like.local) or MDM user scope = None — both are reads, not re-registrations.
Where in the chain did it break?
| Step | What happens | Typical symptom when it breaks |
|---|---|---|
| 1. Tenant scope | MDM user scope All/Some includes the user; WIP (MAM) user scope None; default discovery URL | Event 76 with 0x8018002b; nothing enrolls for one department |
| 2. User license | Intune license (plus Entra ID P1 for automatic enrollment) | Enrollment failures report row for "unlicensed"; only some users fail |
| 3. Join + PRT | Hybrid joined; user signed in with a PRT |
AzureAdPrt : NO; "Get AAD device token failure"; wrong TenantId |
| 4. GPO applied |
AutoEnrollMDM set; credential type matches the scenario |
No EnterpriseMgmt task; Device Credential (0x0/0x1) failures on user PCs |
| 5. Task runs | Scheduled task triggers every 5 min for a day | No Event 75/76 at all; Task Scheduler 7016 already-enrolled code |
| 6. Enrollment attempt | Event 75 (success) or Event 76 (failure + code) | Event 76 with an HRESULT you can decode |
| 7. Intune-side gates | Windows (MDM) allowed; device limit not reached; Entra join settings allow it |
0x80180014; Event 71 "too many devices enrolled"; DeviceCapReached |
Pick two missing devices you can reach and one that enrolled fine. Comparing a good and a bad PC at each step answers most tickets faster than any portal.
Step 1: Read MDM user scope and discovery URL
In the Microsoft Intune admin center > Devices > Enrollment > Windows > Automatic Enrollment (the same blade appears in Entra as Mobility (MDM and MAM) > Microsoft Intune):
| Setting | Want | If wrong |
|---|---|---|
| MDM user scope | All, or Some with a group that contains the failing user | None = no auto-enrollment; Some = users outside the group fail |
| WIP user scope (older docs: MAM user scope) | None (or users not in both scopes) | Microsoft notes MAM/WIP scope can take precedence and break MDM enrollment |
| MDM discovery URL | https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc |
Custom/blank URL — enrollment never finds the service |
| App you configured | Microsoft Intune (not Microsoft Intune Enrollment) | Both are listed; settings on the wrong one do nothing |
If the scope is Some, read the group membership for the failing user before touching anything else. "Scope = Some, user not in group" looks identical to a broken device from the client side.
Step 2: Read licensing for the user who signs in
Group Policy auto-enrollment is user-centric: the user who signs in is the one enrolling the device. Microsoft's checklist starts with a valid Intune license on that user, and automatic MDM enrollment is an Entra ID Premium (P1/P2) feature.
Read-only license check (Microsoft Graph PowerShell, User.Read.All):
Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUserLicenseDetail -UserId 'jdoe@contoso.com' |
ForEach-Object { $_.ServicePlans } |
Where-Object ServicePlanName -in 'INTUNE_A','AAD_PREMIUM','AAD_PREMIUM_P2' |
Select-Object ServicePlanName, ProvisioningStatus
INTUNE_A is the Microsoft Intune Plan 1 service plan. If it is missing or not Success, you have your answer for that user.
In the Intune admin center, Devices > Monitor > Enrollment failures (or Troubleshooting + support for one user) shows each failed attempt with a reason and enrollment method. To see failures for unlicensed users there, use the filter User not found or licensed.
Step 3: Read join type, PRT, and tenant info on the device
On a failing device, signed in as the affected user:
dsregcmd /status | Select-String -Pattern 'AzureAdJoined','DomainJoined','AzureAdPrt','TenantName','TenantId'
| Result | Meaning | Next |
|---|---|---|
| AzureAdJoined YES, DomainJoined YES, AzureAdPrt YES | Join + token healthy | Continue to Step 4 |
| AzureAdJoined NO (DomainJoined YES) | Hybrid join not finished | Hybrid join Pending triage |
| AzureAdJoined YES, AzureAdPrt NO | No user token to enroll with | AzureAdPrt : NO triage |
| TenantName / TenantId is a different tenant | Leftover join from a previous tenant | Read TenantInfo below before any leave/rejoin |
| Workplace joined (Entra registered) only | Not the GPO scenario | Microsoft's GPO path is for domain-joined, hybrid-joined devices |
Microsoft documents a specific 0x80180002b case: Event 76 plus AzureAdPrt : NO plus wrong TenantId / AuthCodeUrl, caused by a device previously joined to another tenant that did not unjoin cleanly. Read the leftover tenant data (read-only):
Get-ChildItem 'HKLM:\SYSTEM\ControlSet001\Control\CloudDomainJoin\TenantInfo' -ErrorAction SilentlyContinue |
ForEach-Object { Get-ItemProperty $_.PSPath } |
Select-Object PSChildName, AuthCodeUrl, AccessTokenUrl
If PSChildName (the tenant ID) is not your tenant, that device is a re-join candidate — but only after you have read it, and only that device.
Step 4: Read whether the GPO landed and which credential it uses
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM' -ErrorAction SilentlyContinue |
Select-Object AutoEnrollMDM, UseAADCredentialType
gpresult /scope computer /r
| Value | Meaning |
|---|---|
AutoEnrollMDM = 1 |
The policy is enabled on this device |
| Key missing | GPO not applied (link, security filtering, WMI filter, replication) |
UseAADCredentialType = 1 |
User Credential |
UseAADCredentialType = 2 |
Device Credential |
The Device Credential option arrived in the Windows 10 1903 MDM.admx. Microsoft's guidance: 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 ordinary user PCs log Auto MDM Enroll: Device Credential (0x0) / (0x1), Failed, read the GPO credential type before anything else.
If the policy does not appear in the GPO editor at all, your central store has an old MDM.admx. Microsoft's doc says the latest MDM.admx is backwards compatible.
Also check that nothing on the device sets Disable MDM Enrollment: Microsoft maps 0x80180026 (MENROLL_E_DEVICE_MANAGEMENT_BLOCKED) to that policy, and the same code shows up when the classic Intune PC agent is installed.
Step 5: Read the EnterpriseMgmt task and its history
Get-ScheduledTask |
Where-Object TaskPath -like '\Microsoft\Windows\EnterpriseMgmt*' |
Get-ScheduledTaskInfo |
Select-Object TaskPath, TaskName, LastRunTime,
@{ n = 'LastResultHex'; e = { '0x{0:X8}' -f $_.LastTaskResult } }
You are looking for Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID. Microsoft documents that it is created when the GPO is deployed and runs every 5 minutes during one day.
Task Scheduler's own log (Microsoft > Windows > Task Scheduler > Operational) adds:
| Event ID | Meaning |
|---|---|
| 107 | Task triggered |
| 102 | Task completed — logged whether or not enrollment succeeded |
7016 with code 2149056522
|
Task did not start: device already enrolled in another MDM (2149056522 = 0x8018000A) |
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-TaskScheduler/Operational'; Id = 102, 107, 7016 } -MaxEvents 200 -ErrorAction SilentlyContinue |
Where-Object Message -match 'EnterpriseMgmt|enrolling in MDM' |
Select-Object TimeCreated, Id, Message
If that channel returns nothing, check whether Task Scheduler history is enabled on the device before you conclude the task never ran. A 102 only proves the task finished; Step 6 tells you whether enrollment worked.
Step 6: Read Event 75 / 76 and decode the error
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'; Id = 71, 75, 76 } -MaxEvents 30 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message |
Format-List
| What you see | Documented cause | Read next |
|---|---|---|
| Event 75 Auto MDM Enroll: Succeeded | Enrollment worked | Device not in the portal? Search by serial/Entra device ID; check sync, not enrollment |
| No 75 and no 76 | Enrollment never triggered | Steps 4–5 (GPO, task, already enrolled elsewhere) |
76 0x8018002b
|
UPN suffix unverified or non-routable (e.g. @contoso.local), or MDM user scope = None |
Step 1 scope; user's UPN suffix in AD vs verified domains |
76 0x80180002b with AzureAdPrt NO + wrong TenantId |
Leftover join from a previous tenant | Step 3 TenantInfo |
| 76 Device Credential (0x0/0x1) Failed | Device Credential outside co-management / AVD multi-session | Step 4 UseAADCredentialType
|
0x80180026 |
Disable MDM Enrollment policy, or classic Intune PC agent present | Step 4; installed software |
0x8018000a / 7016 + 2149056522
|
Device already enrolled (another MDM, or another user's work account) | Settings > Accounts > Access work or school; MDM vendor |
0x80180014 "Your organization does not support this version of Windows" |
Windows (MDM) blocked in a device type enrollment restriction | Step 7 |
| Event 71 "The account has too many devices enrolled to Mobile Device Management (MDM)" | Intune device limit reached (DeviceCapReached) | Step 7 device limits |
For the UPN case, a read-only look at the user in AD:
Get-ADUser -Identity jdoe -Properties UserPrincipalName | Select-Object SamAccountName, UserPrincipalName
If the suffix is .local (or any domain not verified in Entra), the device side is fine. The fix lives in the UPN suffix and the next Entra Connect sync.
For a full evidence bundle you can attach to a ticket, Microsoft's built-in collector is read-only:
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"
Step 7: Read the Intune and Entra gates
| Gate | Where | Healthy |
|---|---|---|
| Device type enrollment restriction | Intune admin center > Devices > Enrollment > device platform restriction | Windows (MDM) allowed for the user's assigned restriction |
| Device limit restriction | Intune admin center > Devices > Enrollment > device limit restrictions | User's enrolled devices below the limit (stale records count) |
| Users may join devices | Entra > Devices > Device settings | Set to All (or Selected incl. the user) |
| Maximum number of devices per user | Entra > Devices > Device settings | User below the quota |
| Enrollment failures report | Intune admin center > Devices > Monitor > Enrollment failures | Row reason matches what the device logged |
Microsoft's support guidance on DeviceCapReached is to remove stale device records or adjust the limit in the right service (Intune vs Entra). It is a count problem, not a device problem.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| MDM user scope None, or Some without the user | Set scope to All, or add a pilot group to Some | Re-imaging devices that were never in scope |
| WIP/MAM user scope overlaps the user | Set WIP user scope to None (or remove the overlap) | Deleting the Intune app registration in Entra |
| User lacks Intune / Entra P1 | Assign the license; let the task retry | Mass dsregcmd /leave
|
.local UPN suffix (0x8018002b) |
Change the UPN suffix to a verified domain; wait for delta sync | Re-joining devices whose join is already healthy |
| AzureAdPrt NO with healthy join | Work the PRT triage on that device | Flipping the GPO to Device Credential |
| Device Credential on ordinary user PCs | Set the GPO to User Credential for those PCs | Leaving Device Credential outside co-management / AVD multi-session |
| Leftover tenant in TenantInfo (0x80180002b) | Microsoft's documented leave → delete objects → rejoin → sync, on that device only | Running it fleet-wide "to be safe" |
| Already enrolled elsewhere (0x8018000a) | Remove the other MDM / other user's work account first | Deleting HKLM\SOFTWARE\Microsoft\Enrollments keys blindly |
| Windows (MDM) blocked (0x80180014) | Allow Windows (MDM) in the restriction assigned to that user | Disabling all enrollment restrictions |
| Device cap reached | Remove stale device records; adjust the limit if policy allows | Making every user a Device Enrollment Manager |
| No task, no events | Fix GPO link/filtering/ADMX; gpupdate /force on a pilot |
Rewriting Intune configuration profiles |
FAQ
What does Event 76 "Auto MDM Enroll: Failed" mean?
The GPO-triggered enrollment task ran and the enrollment attempt failed. The code in the message is the clue: 0x8018002b points to UPN suffix or MDM user scope, Device Credential failures point to the GPO credential type, and 0x80180026 points to MDM enrollment being blocked. Event 75 is the success counterpart.
There is no Event 75 or 76 at all. Where do I look?
Enrollment was never triggered. Confirm AutoEnrollMDM exists under HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM, that the EnterpriseMgmt task exists, and whether Task Scheduler logged 7016 with 2149056522 (already enrolled in another MDM).
Should the GPO use User Credential or Device Credential?
Microsoft supports Device Credential for Intune only with co-management or Azure Virtual Desktop multi-session host pools. For normal user PCs, use User Credential.
dsregcmd shows hybrid joined but AzureAdPrt is NO. Will auto-enrollment still work?
Microsoft's checklist expects AzureAdPrt: YES. Without a PRT for the signed-in user, the enrollment task has no token to enroll with. Fix the PRT first; the task retries on its own schedule.
Should I run dsregcmd /leave or delete enrollment registry keys?
Only when you have evidence for it, such as the documented leftover-tenant case (wrong TenantId plus 0x80180002b), and only on the affected device. It is a change with a re-join and sync cost, not a diagnostic step.
Related posts
- Hybrid Azure AD Join Pending: A Read-First Triage Order for Entra Connect Admins
- AzureAdPrt : NO in dsregcmd /status: A Read-First Primary Refresh Token Triage
- Company Portal can't connect / device not syncing: a 10-minute triage order
- Intune Compliance: Not Applicable, Is Active, Minimum OS
Free checklist
Auto-enrollment is usually the step right before you require a compliant device in Conditional Access. If half the fleet is not enrolled yet, enforcing that grant locks those users out. The free Conditional Access pre-enforcement checklist keeps break-glass, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=auto-mdm-enroll-failed-event-76
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read. Pilot any scope, GPO, or re-join change on a small device group first, and check current Microsoft docs for auto-enrollment prerequisites and error codes.
Top comments (0)