Fix Autopilot Self-Deploying Mode Error 0xC1036501: Multiple MDM Configurations in Microsoft Entra ID

If Windows Autopilot self-deploying mode fails and the diagnostics point to 0xC1036501, do not start with TPM firmware, Wi-Fi drivers, or a random wipe-and-retry loop. Microsoft’s current Windows Autopilot known issues page is explicit: this code means the device can’t do automatic MDM enrollment because there are multiple MDM configurations in Microsoft Entra ID.

That makes this a tenant-configuration problem first. The device can be healthy. The hardware hash can be correct. TPM attestation can even succeed. But if self-deploying mode reaches the automatic enrollment stage and Microsoft Entra is presenting conflicting MDM enrollment paths, the deployment stops.

For shared devices, kiosks, digital signage, and bench-built endpoints, that is a real outage. Self-deploying mode is supposed to remove user interaction. When 0xC1036501 shows up, the tenant is no longer giving the device one clean management destination.

Quick fix checklist

Use this order before you reset another device:

1. Confirm the device is using Windows Autopilot self-deploying mode, not user-driven or pre-provisioning.
2. Verify the visible code is 0xC1036501.
3. Open Microsoft Entra admin center and review the Mobility (MDM and MAM) automatic enrollment settings.
4. Confirm Microsoft Intune is the intended MDM authority for this tenant or for the affected user/device scope.
5. Check whether more than one MDM configuration, connector, or legacy enrollment path is still enabled.
6. Validate MDM user scope for Intune and make sure the scope matches your deployment design.
7. Check WIP user scope and confirm you are not creating conflicting user scope behavior.
8. Retry on one pilot device only after the enrollment settings are cleaned up.

If this is a shared-device rollout, fix the tenant once and then retest one kiosk. Do not burn time rebuilding ten identical machines against the same broken enrollment configuration.

What error 0xC1036501 actually means

Microsoft now lists 0xC1036501 in the Windows Autopilot known issues page under Windows Autopilot self-deploying mode fails with an error code. The documented description is:

The device can't do an automatic MDM enrollment because there are multiple MDM configurations in Microsoft Entra ID.

That wording matters because it separates this failure from other self-deploying mode problems:

• 0x800705B4 usually points to a timeout, often because the device is not TPM 2.0 capable or is a VM.
• 0x801c03ea means TPM attestation failed.
• 0xC1036501 means the device got far enough to need automatic MDM enrollment, but Microsoft Entra did not present one clean enrollment path.

So this is not primarily a TPM error and not primarily a profile assignment error. It is an identity-and-enrollment control problem between Autopilot self-deploying mode and Microsoft Entra automatic MDM enrollment.

Why this hits self-deploying mode especially hard

Microsoft’s self-deploying mode documentation says this deployment path:

• joins the device to Microsoft Entra ID
• enrolls the device in Intune or another MDM service using Microsoft Entra ID for automatic MDM enrollment
• provisions policies, apps, certificates, and networking before the device is released

That second line is the key dependency. Self-deploying mode is built around automatic MDM enrollment. There is no normal end-user flow where a person can pick through prompts and recover gracefully. If automatic enrollment is ambiguous, the workflow breaks.

Microsoft also states that self-deploying mode is only supported for Microsoft Entra join devices and depends on TPM 2.0 plus TPM device attestation. Many admins see those requirements and assume any failure must still be TPM-related. 0xC1036501 is the counterexample. The join pipeline can be valid and the enrollment handoff can still fail because the tenant is offering multiple management configurations.

Where the conflict usually comes from

Microsoft’s known-issues page gives the symptom, while the Intune automatic enrollment documentation explains the control plane behind it.

In the Enable MDM automatic enrollment for Windows guidance, Microsoft says admins should configure the MDM user scope for Microsoft Intune. The options are None, Some, or All. Microsoft also says to use the default MDM terms of use URL, MDM discovery URL, and MDM compliance URL values.

That sounds straightforward, but environments often accumulate drift:

1. Legacy or parallel MDM setup was never fully removed

A tenant may have historical enrollment settings from an older MDM strategy, lab tooling, a merger, or a prior proof of concept. If those settings still exist alongside Intune automatic enrollment, self-deploying mode can hit an ambiguous path.

2. Admins changed scope without cleaning the rest of the enrollment design

It is common to move from pilot to production by changing MDM user scope from Some to All. If the surrounding mobility configuration was not simplified first, the tenant can end up presenting more than one active management path.

3. WIP and MDM settings were treated as harmless overlap

Microsoft’s Intune enrollment guidance warns that if you enable automatic MDM enrollment for BYOD scenarios, you should make sure the WIP user scope is None or Some, and that users are not members of both scopes unless you understand the precedence rules.

That guidance is written for user enrollment behavior, but it also tells you something broader: scope design matters. Sloppy overlap in mobility settings is not a cosmetic problem.

4. Shared-device tenants inherit admin assumptions from user-driven enrollment

Self-deploying mode is often used for kiosks, shared stations, and frontline hardware. In those tenants, admins sometimes focus on Autopilot profiles and ESP while forgetting that Microsoft Entra automatic enrollment is still the gatekeeper for device management.

Where to check first

Start in the cloud admin controls, not on the local device.

In Microsoft Entra / Intune

Open the automatic enrollment path first:

Intune admin center > Devices > Device onboarding > Enrollment > Windows > Automatic Enrollment

Verify:

• MDM user scope is set intentionally: None, Some, or All
• Microsoft Intune is the intended MDM service for the affected deployment
• the MDM terms of use URL, MDM discovery URL, and MDM compliance URL remain the default Microsoft values
• WIP user scope is not creating avoidable overlap or confusion
• there is no leftover pilot configuration that points devices toward a different management design

Then review the device scenario itself:

Intune admin center > Devices > Windows > Windows enrollment > Deployment profiles

Check that the device is actually assigned a self-deploying mode profile and not a user-driven profile that somebody assumed was equivalent.

In Microsoft Entra device views

Microsoft’s device-management documentation says the Devices area in Microsoft Entra ID is where you review device identities and audit logs. Use that to check for recent device creation, deletion, or settings changes around the failure window.

That matters because 0xC1036501 is a tenant-state problem. If a new policy or mobility setting was changed just before kiosk deployments began failing, the audit trail helps you prove the failure is not random.

Logs and local evidence to collect

This issue is tenant-driven, but you still need one clean evidence package from a failed device.

Collect Autopilot diagnostics

Microsoft documents this command on the current Autopilot known-issues page:

Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Autopilot\autopilot-0xC1036501.cab

That gives you the CAB you can attach to your incident or compare across multiple failed kiosks.

Check join state

dsregcmd /status

You are not expecting dsregcmd to tell you “multiple MDM configurations,” but it helps confirm whether the device got through the expected Microsoft Entra registration and whether the failure is happening after the identity handoff rather than before it.

Pull recent Autopilot events

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Use the timeline to separate:

• profile download and tenant contact
• TPM-related failures
• the later enrollment break where 0xC1036501 surfaces

That separation matters when another admin insists the issue must be TPM because “self-deploying mode always fails on TPM.” Sometimes it does. This code is the proof that sometimes it does not.

Repair workflow that works

Step 1: Prove this is really self-deploying mode

Microsoft’s known-issues entry is specifically tied to Windows Autopilot self-deploying mode. If the failing device is actually in pre-provisioning or user-driven mode, stop and reclassify the incident first.

Step 2: Clean up automatic enrollment settings

In the Intune automatic enrollment page, confirm the intended production state:

• MDM user scope matches your rollout design
• WIP user scope is not creating unnecessary overlap
• default Microsoft enrollment URLs are intact
• Intune is the clear MDM path for the affected devices

If you discover legacy or duplicate mobility configuration, remove the extra path instead of trying to compensate with more profiles.

Step 3: Validate one device path end to end

Pick one affected kiosk or shared PC and verify:

• the device is registered in Autopilot
• the assigned profile is self-deploying mode
• the tenant is not relying on mixed enrollment logic
• the device has network access required for Autopilot and TPM attestation

This step is important because a tenant can have two real problems at once. You can fix the duplicate MDM configuration and still have one device with a separate network or TPM issue.

Step 4: Retest after the cloud change settles

After cleaning up enrollment configuration, rerun deployment on one pilot device. Watch for the failure point to move:

• If 0xC1036501 disappears, you fixed the tenant conflict.
• If the device now fails earlier with 0x800705B4 or 0x801c03ea, you uncovered the next real blocker.

That is still progress. One clean root cause at a time is better than a fuzzy incident with three theories attached.

Step 5: Check audit logs if the error returns

If the same code comes back after you think you cleaned up the mobility settings, go back to Microsoft Entra Audit logs and review:

• recent enrollment-setting changes
• device-related management changes
• actor names tied to mobility or device operations

This is often where you find a second admin or automation job reintroducing the conflict.

What not to do

Do not make these mistakes during a live rollout:

• Do not keep reimaging devices without reviewing automatic enrollment.
• Do not assume every self-deploying failure is TPM-related.
• Do not change Autopilot profile assignments first if Microsoft already told you the code points to multiple MDM configurations.
• Do not leave pilot-era enrollment settings half alive in a production tenant.
• Do not test on a full batch before one pilot device completes successfully.

Prevention

The durable fix is governance, not hero troubleshooting.

Use this pattern going forward:

1. Keep one clearly documented Windows MDM enrollment path for production devices.
2. Review MDM user scope and WIP user scope whenever you change Intune enrollment strategy.
3. Treat Mobility (MDM and MAM) settings as part of Autopilot change control, not a separate identity team concern.
4. Use Microsoft Entra Audit logs after any enrollment outage to capture exactly what changed.
5. Validate self-deploying mode on one shared device after tenant enrollment changes before expanding to the whole fleet.

Self-deploying mode is reliable when the tenant gives it a single clean management destination. 0xC1036501 is what you get when that assumption breaks.

Conclusion

0xC1036501 in Windows Autopilot self-deploying mode is Microsoft telling you the automatic enrollment path is conflicted. The practical fix is to clean up Microsoft Entra / Intune mobility settings so the device sees one valid MDM enrollment target, then retest on a pilot device. If your rollout is kiosks, labs, or shared endpoints, fix the tenant once and the bench failures usually stop all at once.