Troubleshooting
Problem
Devices that should be co‑managed with Configuration Manager (SCCM) and Microsoft Intune are failing to enroll into Intune. Although devices are Microsoft Entra hybrid-joined, they do not complete MDM enrollment and do not show expected enrollment events.
Symptom
- Devices fail MDM enrollment even when triggered manually.
- No events appear under:
DeviceManagement-Enterprise-Diagnostics-Provider\Enrollment
- CoManagementHandler.log shows repeated errors such as:
Could not check enrollment url, 0x00000001
Co-management is disabled but expected to be enabled.
Device is not provisioned
Workloads rules are not compliant.
- Log also indicates:
- Enrollment attempted with RegisterDeviceWithManagementUsingAADDeviceCredentials
- Reports "Device is already enrolled"
Still fails to provision the device for co‑management
Cause
This behavior typically occurs when Windows MDM auto-enrollment prerequisites are not satisfied, or when the device cannot contact Intune MDM enrollment endpoints. Common root causes include:
MDM enrollment URL unreachable
- Firewall/proxy blocking access to Intune MDM URLs
- Device cannot validate tenant-specific MDM discovery endpoint
- Network interception (SSL inspection) interfering with enrollment
Broken or incomplete hybrid join state
- Device is hybrid-joined but not fully provisioned
- AAD device credentials not registered correctly
- Corrupted or missing NgcPrxyKey / AAD token data
MDM Enrollment Policy not applied
- Auto-enrollment GPO not applied
- Incorrect scope or missing MDM user rights
Co‑management configuration not compliant on the SCCM side
- Workload configuration mismatch
- Co‑management policy not arriving to the device
SCCM client reports MDM enrollment succeeded, but MDM never receives the device
- Device stuck in an incomplete, non-provisioned state
- Token provision failure (reflected in “Device is not provisioned”)
Device Management Enrollment service not generating event logs
- Typically indicates the enrollment engine is never invoked
- Usually caused by:
- network issues
- missing enrollment policy
- corrupted enrollment service registry keys
Environment
- Microsoft Intune (MDM/MAM)
- Configuration Manager (SCCM) with Co‑Management enabled
- Windows 10/11 enterprise devices
- Hybrid-joined via Entra Connect
- Auto-enrollment enabled (Group Policy or Azure AD)
- Affected devices show:
- No MDM enrollment logs
- CoManagementHandler reporting URL check failures
- Devices unable to validate or contact MDM endpoint
Diagnosing The Problem
1. Verify Hybrid-Join State
Run:
dsregcmd /status
Check:
- AzureAdJoined = YES
- DeviceId populated
- TenantInfo populated
- WorkplaceJoined = NO (or blank)
If not correct → issue with hybrid join.
2. Check Device MDM Enrollment Policy
Run:
gpresult /r /scope computer
Confirm the policy:
"Enable automatic MDM enrollment using default Azure AD credentials" is applied.
Registry validation:
HKLM\SOFTWARE\Microsoft\Policies\Microsoft\Windows\CurrentVersion\MDM
- AutoEnrollMDM
- UseAADCredentialType
Both should be set.
3. Test Access to Intune MDM URLs
Run these from the affected device:
https://enrollment.manage.microsoft.com
https://deviceenrollment.microsoft.com
https://login.microsoftonline.com
You should not receive:
- certificate errors
- proxy auth prompts
- SSL inspection warnings
If blocked → the 0x00000001 URL check error is expected.
4. Check Enrollment Service
If the below directory has no logs, the device is not attempting enrollment:
C:\Windows\System32\WinEvt\Logs\DeviceManagement-Enterprise-Diagnostics-Provider
This indicates the enrollment engine never started → usually caused by GPO or broken AAD registration.
5. Review CoManagementHandler.log Indicators
From your log:
- "Could not check enrollment url, 0x00000001"
→ device cannot validate MDM URL (network or registration issue) - "Device is not provisioned"
→ MDM identities not created on the device - "Co-management is disabled but expected to be enabled"
→ MDM enrollment never completed, so SCCM cannot shift workloads - "Device is already enrolled"
→ stale or corrupted enrollment records exist locally
6. Check Local Enrollment Records
Look at:
HKLM\SOFTWARE\Microsoft\Enrollments
HKLM\SOFTWARE\Microsoft\Enrollments\Status
Symptoms:
- Empty keys = enrollment never started
- Stale GUID keys = enrollment corrupted
7. Check SCCM Co‑Management Policy Delivery
In SCCM client logs:
- CoManagementHandler.log
- PolicyAgent.log
- ClientIDManagerStartup.log
Ensure co‑management policy is delivered and workloads are configured correctly.
Resolving The Problem
1. Fix Network / Proxy Issues (Most Common Resolution)
Ensure the device can reach ALL required Intune URLs:
https://learn.microsoft.com/mem/intune/fundamentals/intune-endpoints
Allow:
- manage.microsoft.com
- deviceenrollment.microsoft.com
- login.microsoftonline.com
- enterpriseregistration.windows.net
Disable SSL interception for Microsoft cloud URLs.
2. Reapply or Correct MDM Auto‑Enrollment GPO
Ensure policy:
Computer Configuration → Administrative Templates → Windows Components → MDM → Enable automatic MDM enrollment
Set to:
- Enabled
- User Credential or Device Credential (depending on your configuration)
Run:
gpupdate /force
3. Reset AAD Registration
Run:
dsregcmd /leave
Reboot, then re-join:
dsregcmd /join
This often resolves token provisioning issues.
4. Clear Corrupted MDM Enrollment Records
Remove:
HKLM\SOFTWARE\Microsoft\Enrollments\{GUID}
HKLM\SOFTWARE\Microsoft\Enrollments\Status\{GUID}
Then re-attempt enrollment:
ms-settings:workplace
5. Repair SCCM Co‑Management Configuration
- Ensure the device is assigned an Intune license
- Ensure co‑management workloads are properly configured
- Re-evaluate co‑management policy arrival via PolicyEvaluator.log
6. Trigger MDM Enrollment Manually
From elevated PowerShell:
$task = Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt" | where {$_.TaskName -like "*Schedule*"}
Start-ScheduledTask $task.TaskName
Or:
djoin.exe /provision
7. Reinstall the SCCM Client (If SCCM Policy is Corrupt)
As a last resort:
ccmsetup.exe /uninstall
Then reinstall, ensuring co‑management policy is delivered properly.
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
31 January 2026
UID
ibm17259376