A Windows device that’s properly joined to Microsoft Entra ID but mysteriously absent from Intune’s management console is a familiar headache for IT departments. The problem often boils down to a simple but widely misunderstood distinction: identity join and mobile device management enrollment are separate stages, and neither guarantees the other. A pair of Event IDs—75 and 76—logged deep in Windows’ MDM diagnostic provider hold the definitive answer, yet many admins overlook them entirely.

According to Microsoft’s official troubleshooting documentation, these overlooked event entries are the most reliable way to determine why a device that should be Intune-managed appears unmanaged. The approach, long detailed in Microsoft Learn but infrequently applied, has gained renewed attention as organizations grapple with hybrid and cloud-native Windows deployments. It separates the investigation into three clean paths: enrollment never triggered, enrollment triggered but failed, or the device is already governed by a different MDM service.

The split between identity and management

Joining a device to Entra ID creates an identity link, but mobile device management enrollment is a separate operation requiring its own set of conditions. A device can be Entra-joined for months without ever picking up an Intune management profile. On hybrid-joined devices—those both domain-joined and Entra-joined—Group Policy is supposed to bridge that gap by firing an automatic enrollment task, but that mechanism can silently break. On cloud-only Entra-joined devices, enrollment relies on user-triggered workflows, though administrators often expect an automatic outcome that never happens.

Microsoft’s troubleshooting guide for Group Policy-based auto-enrollment, applicable to Windows 10 version 1709 and later, emphasizes that the presence of an Entra join record is not a guarantee of Intune enrollment. The documentation explicitly directs admins to a specific event log path and two crucial event IDs that act as a truth source for the enrollment attempt.

The diagnostic that changes everything

Inside Windows, enrollment activity is captured in the DeviceManagement-Enterprise-Diagnostic-Provider administrative log, found at:

Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

Within that log, two events are paramount:

  • Event ID 75: “Auto MDM Enroll: Succeeded” — automatic enrollment completed.
  • Event ID 76: “Auto MDM Enroll: Failed” — Windows attempted to enroll but ran into a problem.

The absence of both events on a hybrid-joined device means enrollment was never triggered at all. This single observation reframes the troubleshooting process. Instead of tearing down device records in Entra ID or Intune, admins can first check the event log to see whether Windows even tried to enroll. The resulting evidence dictates the next move.

First things first: check your device’s join state

Before diving into logs, confirm exactly how the device believes it is joined. Open an elevated command prompt and run dsregcmd /status. The output lists AzureAdJoined : YES and DomainJoined : YES for hybrid devices. For cloud-only, AzureAdJoined : YES with DomainJoined : NO. This step ensures you know which enrollment path should apply. A cloud-joined device will not log the same triggers as a hybrid-joined one, so misreading the state leads to wasted effort.

Scenario 1: Hybrid Entra-joined devices

On a hybrid-joined PC, Microsoft Intune auto-enrollment is orchestrated by the “Enable automatic MDM enrollment using default Microsoft Entra credentials” Group Policy setting. When that GPO applies correctly, it creates a scheduled task in Task Scheduler Library > Microsoft > Windows > EnterpriseMgmt. The task, titled “Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID,” runs every 5 minutes for one day after the GPO takes effect.

Here is where the event log becomes a precise instrument:

  • Neither Event ID 75 nor 76 appears — The GPO never reached the device, the scheduled task didn’t run, or another MDM already holds management. Check GPO application with gpresult /h and verify the EnterpriseMgmt folder exists. If the task is absent, troubleshoot the GPO deployment chain.
  • Event ID 76 is logged — Windows attempted enrollment but failed. The event’s details will often include a Win32 error code (e.g., 0x8018002b) pointing to a specific problem. At this stage, revisit the enrollment prerequisites (user scope, license, restrictions) because the device was ready to enroll but something blocked it. Focus on the recorded failure rather than re-running the entire enrollment stack.
  • Event ID 75 is logged — Enrollment succeeded from Windows’ perspective. If the device still doesn’t appear in Intune, look at sync timing or whether it enrolled into a different tenant. Management should be visible within the Intune console after the next sync cycle.

A common misinterpretation is to treat the existence of the EnterpriseMgmt folder as proof that enrollment worked. It is not. That folder tells you the auto-enrollment mechanism is scheduled; only Event ID 75 or 76 reveals the outcome.

Scenario 2: Cloud-only Entra-joined devices

Cloud-joined Windows machines do not depend on a Group Policy trigger. Enrollment in Intune is typically initiated by the user during Windows setup, through the Settings app under Accounts > Access work or school, or via Windows Autopilot. Yet administrators frequently assume that joining Entra ID alone should trigger enrollment—it does not.

For cloud-joined devices, use the same event log to check if an automatic enrollment was attempted. If neither Event ID 75 nor 76 exist, the device likely never received an enrollment command. Instead of chasing ghosts in the log, shift focus to the conditions governing enrollment:

  • Is the user within the MDM user scope under Mobility (MDM and MAM) in the Entra admin center? If the scope is set to “Some,” the user must be a member of the assigned group.
  • Does the user have a valid Intune license (e.g., Microsoft 365 E3, E5, or standalone Intune)?
  • Do enrollment restrictions allow Windows devices? Check Devices > Enroll devices > Enrollment device platform restrictions in the Intune admin center.
  • Has the user reached the maximum number of devices per user quota? Entra ID and Intune both enforce limits.
  • Is Microsoft Intune the configured MDM authority under Mobility (MDM and MAM), and not a competing service?

If those prerequisites check out, guide the user through the organization’s approved enrollment process—such as adding a work account from Settings or running the Intune Company Portal app. After that manual enrollment, the event log should show an equivalent success or failure entry, even on cloud-joined devices.

The “already managed by another MDM” pitfall

A subtle but common culprit is a device still enrolled in a legacy MDM, like System Center Configuration Manager or a third-party solution, or accidently included in a mobile application management (MAM) scope that blocks MDM enrollment. Windows can report itself as Entra-joined while another MDM retains management authority.

Event ID 76 can sometimes surface this conflict with error codes indicating an existing enrollment. Before attempting to bring such a device into Intune, the existing management relationship must be severed according to the other MDM’s removal process. This often means unenrolling from the old platform first, confirming the device is no longer managed, and only then triggering Intune enrollment.

Microsoft’s documentation warns that if MAM user scope is set to anything other than “None,” it can take precedence over MDM user scope and silently block enrollment. This setting, found alongside MDM user scope in the Entra admin center, is a frequent gotcha.

The prerequisites checklist that prevents repeat failures

Whether hybrid or cloud-joined, a quick audit of the following can resolve most enrollment blockages without deep log analysis:

  • User scope: Under Entra ID > Mobility (MDM and MAM), verify the user is covered by the MDM scope setting. “All” is simple; “Some” requires group membership.
  • License: Intune license assigned directly or via group-based licensing.
  • Enrollment restrictions: No policy block for Windows, personally owned, or corporate devices, depending on the scenario.
  • Device join permissions: In Entra ID > Devices > Device settings, “Users may join devices to Microsoft Entra” set to “All” or the user is in the selected group.
  • Device quota: The user hasn’t reached the per-user device limit (default 50, but often reduced).
  • No MAM scope conflict: Ensure MAM user scope is “None.”
  • No existing MDM enrollment: Check the device for any prior enrollment artifacts. If the device was previously in another tenant, it may need a full reset.

Once the prerequisites are verified, re-run the enrollment trigger (GPO update for hybrid, manual initiate for cloud) and check the event log again for a fresh 75 or 76. This creates a clear, auditable path instead of random retries.

A real-world troubleshooting workflow

Consolidating the above into a logical sequence saves time when a ticket arrives with “Intune isn’t managing this device”:

  1. Run dsregcmd /status to classify the join type.
  2. Open the DeviceManagement-Enterprise-Diagnostic-Provider admin log.
  3. For a hybrid device, look for Event ID 75 or 76. If neither exists, investigate the GPO deployment and EnterpriseMgmt task.
  4. For a cloud device, treat missing events as a sign enrollment was never attempted. Verify prerequisites and trigger manual enrollment.
  5. If Event ID 76 appears anywhere, decode the error code and cross-check the prerequisite list. This step often resolves the issue without touching device records in Entra ID or Intune.
  6. If Event ID 75 is present but Intune shows no management, check the tenant and sync status; the device may have enrolled into a different MDM authority or the sync delay may be responsible.

This flow respects the separation of identity and management, avoids destructive operations like deleting Entra ID device objects, and uses the event log as the single source of truth for enrollment attempts.

Outlook

As Windows management shifts toward cloud-native models, the divide between identity and MDM enrollment will only grow more common. Microsoft’s own documentation path for Intune troubleshooting is increasingly anchored in these event logs, and external community guides are filling in the practical gaps with clear decision frameworks. For IT administrators managing a mix of hybrid and cloud-joined devices, mastering the Event ID 75/76 diagnostic is no longer optional—it’s the quickest route to a definitive answer when a Windows endpoint refuses to show up where it belongs.