This blog explores why Windows Autopilot devices refused to enroll into MDM/Intune despite successfully joining Entra ID. The funny thing? Autopilot for pre-provisioned deployment worked (White Glove), but user-driven enrollment didn’t. By analyzing dsregcmd, Fiddler, CloudDomainJoin.js, and Graph API, we uncovered a hidden issue blocking the MDM enrollment during Windows Autopilot.
No MDM Enrollment during Windows Autopilot
Deploying Windows devices through user-driven Autopilot should be straightforward (It should…). The device joins Entra ID, enrolls into Intune, and receives policies automatically. However, in this case, something was off. After logging in, the device briefly displayed ‘Please wait while we set up your device‘ but then skipped the Enrollment Status Page entirely and jumped straight to Windows Hello setup. No policies were coming down, no Intune management Extension, and no indication that the device had enrolled into MDM.
Strangely, when testing Autopilot for pre-provisioned deployments, everything worked as expected. The device joined Entra ID, enrolled in Intune, and successfully applied policies.
Somehow, Autopilot for pre-provisioned deployments bypassed the issue by relying on device attestation, which does not require the mdm_enrollment_url. User-driven enrollment, however, relies entirely on this URL to determine where to enroll. Since it was missing, the process never even began.
Dsregcmd: No MDM Enrollment URL
The first step was confirming whether the device had successfully joined Entra ID and received the necessary MDM enrollment URLs. Running dsregcmd /status provided immediate insight. The output confirmed that the device was joined to Entra ID, single sign-on was enabled, and the correct tenant ID was assigned. However, as shown below, one crucial detail was missing. There were no MDM enrollment URLs present.
This was a major red flag. If a device is configured for automatic MDM enrollment, it should receive an MDM enrollment URL during authentication. Without it, the device had no instructions on where to enroll for management.
Trying to enroll the device manually without MDM urls configured just led to a failed Intune enrollment.
That makes sense! But the moment we manually specified the MDM URLs with a PowerShell script, as shown below, and kicked off the enrollment, it worked!!
The moment we manually entered MDM URLs and enrollment worked, that was a major clue that Intune itself was fine. This directly proved the issue was with automatic enrollment, not Intune.
Checking MDM Enrollment Scope and License
Since the device lacked an MDM enrollment URL, the next logical step was verifying whether the MDM user scope in Entra ID was set correctly and whether the user had the necessary Intune P1 license.
As shown below, the MDM scope was correctly set to “All users” for automatic MDM enrollment.
With the MDM scope being configured to all, we also checked if the user had the required Microsoft Intune P1 license and Intune License, which is necessary for automatic MDM enrollment.
Even after verifying these settings, dsregcmd /status still did not show any MDM enrollment URLs.
Investigating CloudDomainJoin.js
Since the Entra ID join itself wasn’t failing (which happened in this blog), the next logical step was investigating CloudDomainJoin.js, the component responsible for handling MDM discovery after a device joins Entra ID. Normally, this process begins with the Entra ID join request, followed by the negotiation of device capabilities with the server. Once completed, the ID token should include the mdm_enrollment_url. If present, the device requests an MDM Delegation Token, which triggers Intune enrollment.
The MDM Flow explained
The Corrosponding Documentation to the flow
Device Joins Entra ID:
- CloudDomainJoin starts as part of the enrollment flow.
Extracts and Decodes ID Token:
- The ID token should contain the mdm_enrollment_url for Intune.
MDM URL Check:
- If mdm_enrollment_url is present, CloudDomainJoin:
- Requests an MDM Delegation Token from Entra ID.
- Receives an access token for the MDM service (enrollment.manage.microsoft.com).
- Calls the MDM enrollment URI to start enrollment.
- If mdm_enrollment_url is missing, the MDM Delegation Token is never requested, meaning Intune enrollment does not happen.
MDM Enrollment Request:
- If the process succeeds, the device is enrolled in Intune, and ESP starts.
- If it fails, the device remains unmanaged.
As explained above, the ID token is important in this process. If we examine the Dsreg.dll more closely, we will notice the same.
DSREG.DLL
As shown below, the dsreg.dll contains an important function that parses the ID token from the JSON response and tries to find the MDM_enrollment uris inside that IDToken.
In this case, the ID token was missing mdm_enrollment_url entirely. This meant that the system never attempted to request an MDM Delegation Token, stopping the enrollment process before it even began.
With the mdm_enrollment_url missing from the IDToken, we needed to determine whether this was a processing issue or whether Entra ID was failing to provide the URL entirely. That meant diving into a Fiddler trace to inspect the authentication response.
Capturing a Fiddler Trace
To confirm what was happening, we captured a Fiddler trace during authentication. This allowed us to see exactly what the device was sending to Entra ID and what Entra ID was returning. First let me show you what should have happened the moment you join the device to Entra:
Note: You can download the png for a better view!
As shown above, the moment the device asks for the device.join access token, the MDM enrollment urls should be in the IDToken. From then on, it should ask for the MDM_delegaton token to kick off the Intune Enrollment.
We will notice something weird if we compare the working one with the one we got from this broken enrollment.
When examining the response from login.microsoftonline.com/common/oauth2/token, we expected to find mdm_enrollment_url in the ID token, but it was missing in action. This confirmed that Entra ID failed to provide the necessary information for enrollment.
Resetting MDM Scope and Verifying MDM Authority
To eliminate misconfigurations, we fully reset the MDM scope and enrollment URLs in the Intune portal. The MDM URLs were reset, the MDM scope was disabled and then re-enabled, and the settings were saved again to enforce changes.
Additionally, we verified that the MDM authority was correctly set to Intune, as misconfigurations in MDM authority can sometimes prevent devices from enrolling. As shown below, the MDM Authority was set to Intune, so this wasn’t the issue.
Even after resetting everything and checking the MDM authority, the issue persisted. We attempted another enrollment attempt, hoping the reset had resolved the issue, but the device still failed to retrieve the MDM enrollment URL. It was clear that the root cause lay deeper within Entra ID.
Investigating Entra ID’s MDM Policies and Conditional Access
Next, we checked the MDM policies in Entra ID. The portal showed Microsoft Intune as the only MDM provider, but something looked strange.
The Microsoft Intune name contained an unusual period, which raised questions about whether something had changed in its configuration.
Opening the Microsoft Intune MDM policy also showed us no obvious errors. The Microsoft Intune service Principle was enabled as it should. Somehow, I was expecting it to be disabled.
To be sure we were indeed looking at the right MDM policy (as it contained a weird . in the name), we tried to add the Microsoft Intune MDM policy, but that one failed with the message that it had already been configured for a single sign-in of Microsoft Entra ID.
To rule out external interference, we checked Conditional Access policies. If a policy required multi-factor authentication, compliance enforcement, or additional conditions before device registration, it could silently block enrollment.
We temporarily excluded the user from all Conditional Access policies to eliminate this possibility. However, the issue remained even after these changes.
Since the user and MDM enrollment were fully excluded from all Conditional Access policies, the mdm_enrollment_url was still missing, which confirmed that CA was not interfering with the process. The issue had to be deeper, inside Entra ID itself.
Checking MDM Policies with Graph API
Since the Entra ID portal wasn’t showing any obvious issues, we queried the Graph API for the policy ID that belongs to the Microsoft Intune MDM.
Import-Module Microsoft.Graph.Identity.SignIns
Select-MgProfile -Name beta
Connect-MgGraph -Scopes Policy.Read.All, Policy.ReadWrite.MobilityManagement
$uri = "https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies/0000000a-0000-0000-c000-000000000000/?$select=appliesTo"
$mdmscope = $null
$mdmscope = Invoke-MgGraphRequest -Uri $uri -Method GET
$mdmscopeAfter executing the above PowerShell command, it became clear that the Microsoft Intune MDM policy was valid even when the display name contained a weird “.”
After focusing on the original Microsoft Intune MDM policy, we opened the graph explorer, but this time, we asked for a full list of MDM policies. Running the command:
GET https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies
Among the results, we found an invisible, invalid MDM policy (IsValid: False). The policy was marked as invalid and had a null discovery URL.
This explained a bit why it wasn’t visible in Entra ID and why it had not provided the MDM enrollment URL during authentication. Why I mentioned a bit? Well, who can explain to me how the Entra background service uses an Invalid MDM policy to find the enrollment urls? In my opinion it should have skipped that one because… yes! It is Invalid!
Fixing the Issue
Once we identified the root cause, the solution was straightforward. The invalid MDM policy needed to be deleted. Using Graph API, we ran the following command to remove it:
After deleting the invalid policy, we performed a get command again. This time, no invalid MDM policy showed up!
After removing the invalid MDM policy, we reinstalled the device. Guess what happened? After entering our credentials, the device joined Entra, but this time, it showed us what we were waiting for: the Enrollment Status Page (ESP)!
Since Entra ID does not just use a single MDM policy but instead scans all available ones, the presence of an invalid policy caused it to skip issuing mdm_enrollment_url. Once removed, the correct MDM policy was applied, and enrollment proceeded as expected.
In other words, the system failed not because Intune was misconfigured but because it selected a broken policy over a valid one.
Conclusion: Lessons Learned
This case highlights an issue that cannot be detected in the Entra ID portal alone. When devices join Entra ID but fail to enroll in Intune, a deeper investigation is needed. Checking dsregcmd /status helps verify if MDM URLs are missing. Capturing a Fiddler trace allows confirmation of what Entra ID is sending in authentication responses. Querying Graph API helps uncover hidden or misconfigured policies that may interfere with enrollment.
Sometimes, the issue isn’t where you expect it to be. It may be buried deep in the backend, waiting to be found.