The warning “Windows failed to apply the MDM Policy settings” does not always mean device management is broken. Microsoft documents a specific case where it appears after gpupdate /force on a Microsoft Entra hybrid-joined PC that is already enrolled in Intune. When the accompanying code is 0x8018000A and management is working normally, the warning is expected and can be ignored.
A different error code, a missing Intune record, failed check-ins, or policies that never arrive requires investigation. The safest response is to identify which situation you have before deleting enrollment data or disconnecting the device.
Decide Whether This Is a Warning or a Real Failure
Start with the result, not a long list of Windows repairs.
| What you find | What it usually means | Next action |
|---|---|---|
0x8018000A, device is already enrolled, Intune check-in and policies are healthy | Expected re-enrollment warning | No repair is normally required |
| A different MDM error code | Another enrollment or policy problem | Investigate that exact code and its matching event |
| Device is absent from Intune or has never checked in | Enrollment did not complete | Check join state, enrollment scope, licensing, and restrictions |
| Device is enrolled but one profile fails | Assignment, applicability, conflict, or profile-specific error | Inspect that profile in Intune and its local event |
| Personal PC unexpectedly shows MDM processing | A work or school connection may remain | Review the connected account before removing anything |
Do not use the word “failed” in the console output as the diagnosis. The error code, device state, and management health determine whether anything is wrong.
Why gpupdate /force Can Produce This Message
Organizations can use the Enable automatic MDM enrollment using default Microsoft Entra credentials Group Policy to enroll domain devices into Intune. Forcing a Group Policy refresh processes that MDM extension again.
On a device that is already enrolled, Windows may try the enrollment action and return:
Windows failed to apply the MDM Policy settings.
MDM Policy settings might have its own log file.The related GPSVC entry can report 0x8018000A. Microsoft defines this code as the device is already enrolled and describes the warning as expected in this exact scenario.
It is generally safe to leave the configuration alone when all these points are true:
- The warning appeared after
gpupdate /force. - Computer Policy and User Policy completed successfully.
- The code is
0x8018000A. - The device is Microsoft Entra hybrid joined.
- Intune shows the expected device record and a recent check-in.
- Required applications, compliance rules, and configuration profiles continue to apply.
Do not extend that conclusion to every MDM error. The same message with another code or broken management symptoms needs a proper diagnosis.
Check the Work or School Connection
Open:
Settings > Accounts > Access work or school
Select the organization account. A managed device should show its connection and may provide an Info button with management details and a Sync option.
Check the following:
- Is the expected organization listed?
- Does Windows say the device is connected or managed?
- Is Info available for the connection?
- Does a manual sync complete?
This page confirms that Windows knows about a management connection, but it does not prove that every assigned policy succeeded. An administrator should also check the device record in the Intune admin center.
Do not disconnect a company-owned PC while troubleshooting. Removing the work or school account can interrupt access to corporate applications, certificates, Wi-Fi, VPN, and security policies.
Verify the Microsoft Entra Join State
Sign in as the affected domain user, open Command Prompt, and run:
dsregcmd /statusFor the hybrid-joined situation in Microsoft’s documented warning, the important Device State values are normally:
AzureAdJoined : YES
DomainJoined : YESAlso examine:
- DeviceAuthStatus:
SUCCESSindicates that the device exists and is enabled in Microsoft Entra ID. - DeviceId: Use it to compare the local identity with the record in Entra ID and Intune.
- TenantName and TenantId: Confirm that the device points to the expected organization.
- MdmUrl: An empty value may indicate that MDM is not configured or the user is outside the enrollment scope.
An MDM URL by itself does not prove that the PC is enrolled. Windows can display those URLs when automatic enrollment is configured for the tenant even if the device is not currently managed. Confirm the actual device record and check-in status in Intune.
Check the Intune Device Record
An Intune administrator should search for the device and compare its record with the local DeviceId. Review:
- Last check-in time
- Microsoft Entra device ID
- Join and ownership type
- Primary user or enrolled user
- Compliance state
- Configuration profile status
- Enrollment errors
A recent check-in with successful policy results supports the harmless-warning diagnosis. A stale check-in, duplicate device objects, failed enrollment, or missing device record points to a real management issue.
Enrollment and policy assignment are separate. A PC can be correctly enrolled while one profile remains Not applicable, Pending, Conflict, or Error. Open the affected policy’s device status instead of re-enrolling a healthy device to fix one assignment.
Match the Warning to the Event Log
Open Event Viewer and navigate to:
Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin
Find entries created at the same time as the failed policy refresh or enrollment attempt. Record:
- Event ID
- Error or HRESULT code
- Policy or CSP name
- Enrollment stage
- Timestamp
- Any server response or message
The timestamp is important. An old enrollment failure may remain in Event Viewer after the device has recovered, while a current event can be correlated with the latest Intune check-in.
When the only relevant result is 0x8018000A on an already-enrolled, healthy device, it matches Microsoft’s expected-warning scenario. Another code should be researched on its own rather than being treated as the same problem.
Create an MDM Diagnostic Report
The built-in report is more useful than screenshots of a generic error because it captures the actual enrollment and policy state.
- Open
Settings > Accounts > Access work or school. - Select the managed account and choose Info.
- Select Create report near the bottom of the page.
- Choose Export when Windows displays the report location.
- Open
C:\Users\Public\Documents\MDMDiagnostics.
The report can include the management server URL, device ID, certificates, enrollment details, policies, and relevant event logs. Open MDMDiagHtmlReport.html first for a readable summary.
An administrator can also collect a ZIP from an elevated Command Prompt:
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"Review the report locally or provide it to the organization’s IT administrator. Enrollment reports can contain tenant, device, account, certificate, and policy information, so do not upload them to public forums without removing sensitive data.
Generate a Group Policy Report
The MDM warning is raised during Group Policy processing, so confirm which policies reached the PC:
gpresult /h "%USERPROFILE%\Desktop\GPReport.html"Open GPReport.html from the desktop and review the applied computer policies. Look for the automatic MDM enrollment policy under:
Computer Configuration > Administrative Templates > Windows Components > MDM
The report can confirm that the enrollment GPO is applied. It cannot, by itself, confirm that the Intune service accepted enrollment or that every cloud policy succeeded. Use it together with dsregcmd, the Intune record, and MDM events.
When Intune Policies Really Are Not Applying
When the device is genuinely unhealthy, the administrator should check the management chain in this order:
- Device identity: Compare the local
DeviceIdwith Entra ID and Intune. - Enrollment scope: Confirm that the affected user is included in the configured MDM user scope.
- License: Verify that the user has the required Intune license for the organization’s enrollment method.
- Enrollment restrictions: Check platform, device-limit, ownership, and personal-device restrictions.
- Policy assignment: Confirm that the profile targets the correct user or device group.
- Applicability: Make sure the Windows edition, version, and configuration support the assigned setting.
- Conflicts: Check whether Group Policy, Intune, Configuration Manager, or another profile controls the same setting.
- Current event: Use the exact error from the latest DeviceManagement event or diagnostic report.
Trigger a manual sync after correcting the identified issue. Avoid repeated unenrollment and re-enrollment attempts because they can create duplicate records and obscure the original failure.
MDM is often used to configure dedicated or shared computers. My Windows 11 Kiosk Mode guide explains the local kiosk configuration separately when that is the feature you are trying to deploy.
Fix an Unexpected MDM Warning on a Personal PC
A personally owned computer may retain a work or school connection from a previous employer, school, or Microsoft 365 setup.
Open Settings > Accounts > Access work or school and identify the organization before taking action. Remove it only when all of these are true:
- You own the computer.
- The organization no longer manages it.
- You no longer need its applications, email, certificates, VPN, or network access.
- You understand that disconnecting may remove organizational access and data.
Contact the organization when the connection cannot be removed or the PC returns to company enrollment after Windows is reset. A device registered with Windows Autopilot may still belong to an organization’s tenant and cannot be permanently released by deleting local files.
Avoid Repairs That Do Not Address the Cause
Several common Windows fixes add risk without resolving this warning:
- Do not delete enrollment registry keys. They represent the current management relationship and certificates.
- Do not delete EnterpriseMgmt scheduled tasks. Those tasks may be required for enrollment and renewal.
- Do not disable the automatic MDM enrollment GPO merely to hide an expected warning.
- Do not run SFC or DISM as the first response.
0x8018000Ais an enrollment-state result, not evidence of damaged Windows files. - Do not reinstall Windows when a healthy enrolled device only reports the documented warning.
- Do not disconnect a company PC without approval from its administrator.
These actions can turn a harmless console message into a real management failure.
What to Do After the Checks
Leave the device unchanged when it is hybrid joined, already enrolled, checking in normally, applying its policies, and only returns 0x8018000A after gpupdate /force. Microsoft explicitly describes that behavior as expected.
Escalate the case with the current Event Viewer entry, MDM diagnostic report, dsregcmd /status output, gpresult report, and Intune device details when enrollment or policy delivery is actually failing. Those artifacts give an administrator evidence to diagnose the real layer at fault without damaging a working enrollment.
