Fix Intune Error 65000 Type 2 in Settings Catalog and Endpoint Security Policies

If an Intune policy shows Error code 65000 or Error type 2, do not treat that number as the root cause. In Microsoft environments, 65000 is usually a generic policy reporting failure. The real work is to identify the exact setting that failed, confirm whether the target device actually supports it, and then prove whether the issue is a scope mismatch, a conflict, or a stale report.

This comes up often with Settings Catalog profiles and Endpoint security > Account protection policies. Microsoft Q&A examples show it against settings such as password expiration, built-in administrator account settings, and local group membership changes. Microsoft’s current Intune documentation also explains why many of these failures collapse into the same few report states: Error, Conflict, Not applicable, and Pending.

This runbook is for Intune admins and Desktop Engineers who need the fastest path from 65000 to the actual broken setting.

Quick fix checklist

Use this order before cloning profiles or re-enrolling devices:

1. Open the failing policy and identify the exact setting that is in error.
2. Check Per setting status. Do not troubleshoot the entire profile if only one setting is failing.
3. Open Devices > Monitor > Assignment failures and export the report if multiple devices are affected.
4. Confirm the failed setting is supported on the device’s Windows version, build, and edition.
5. Check whether the setting is user scope or device scope.
6. Review whether the same setting also exists in another Settings Catalog policy, Endpoint security profile, security baseline, Administrative Template, custom OMA-URI, or on-prem GPO.
7. Force a sync on one affected device and wait for a fresh status before you change assignments.
8. Read the local Windows event log under DeviceManagement-Enterprise-Diagnostics-Provider/Admin.
9. Verify whether the setting actually applied on the endpoint even though Intune still reports 65000.
10. Fix one cause at a time and retest with a small pilot group.

What Intune error 65000 type 2 usually means

Microsoft’s Intune monitoring and troubleshooting docs do not define 65000 as a single well-scoped product bug with one fix. In practice, it is a generic failure bucket that appears when Intune can’t cleanly report successful enforcement for a setting or profile.

The useful signal comes from the surrounding status:

• Error: the setting attempted to apply and failed.
• Conflict: another policy or an existing value blocks the requested setting.
• Not applicable: the device, edition, feature set, or policy context does not support that setting.
• Pending: the device has not checked in recently enough, or it has not reported the final status back yet.

Microsoft’s Q&A examples for 65000 point admins back to device-side diagnostics instead of a portal-only fix. The repeated guidance is to inspect the Windows MDM event logs on an affected device. That lines up with Microsoft’s official Intune docs: the number alone is not enough to troubleshoot.

The root causes that matter most

1. Unsupported OS version, edition, or feature state

Microsoft says Windows settings can return Not applicable when the device does not support the setting. That can mean:

• the setting needs a newer Windows build
• the setting only works on Enterprise or Education
• the hardware does not expose the feature
• the setting belongs to a policy family that is not valid for that device state

This is one of the fastest ways to get a 65000-style report on a mixed fleet. One pilot device on Windows 11 Enterprise succeeds, while another device on Pro or an older build reports an error or not-applicable state.

2. User-scope and device-scope mismatch

Microsoft’s Settings Catalog documentation is explicit here: some settings are tagged (User) and some are tagged (Device). User-scope settings write to HKCU. Device-scope settings write to HKLM.

Important scope behaviors from Microsoft:

• If you assign a device-scope setting, it affects all users on the device.
• If you assign a user-scope setting to a device group, it can still apply to all users on that device.
• If the same setting exists in both scopes, user scope takes precedence over device scope.
• During initial check-ins, some user-scope settings can show Not applicable if there is no user hive yet.

That means 65000 type 2 is often not a broken policy engine. It is an admin placing the same setting in the wrong scope or assigning both scopes without realizing which one wins.

3. Duplicate policy ownership

Microsoft documents that Conflict happens when two settings apply different values to the same device and Intune cannot resolve it for you. Check all of the common owners, not just the profile that currently shows the error:

• another Settings Catalog policy
• Endpoint security policy
• security baseline
• custom OMA-URI profile
• Administrative Templates
• Group Policy analytics migration output
• co-management or on-prem GPO

If the same setting exists in two places, 65000 can be the symptom while the actual cause is a conflict you only see at the setting level.

4. Stale assignment or reporting lag

Microsoft notes that device assignment status can take 24 to 48 hours to reflect assignment or group membership changes in large tenants. It also explains that dynamic group membership can delay policy delivery until the next scheduled check-in.

That matters when an admin changes a target group, sees 65000, and immediately assumes the new profile is broken. Sometimes the wrong device simply has not evaluated the latest assignment yet.

5. The setting applied, but the report did not cleanly settle

This pattern shows up in the Microsoft Q&A thread for Endpoint security > Account protection. The admin reported 65000 type 2, but the real validation step was whether the local admin removal actually happened on the device. In other words, you must verify the device state, not only the portal state.

Where to check first

In the Intune admin center

Start here in order:

1. Devices > Configuration or the specific policy blade
2. Device and user check-in status
3. Per setting status
4. View report
5. Devices > Monitor > Assignment failures
6. Troubleshooting + support > Troubleshoot for the impacted user/device pair

The two most useful views are usually:

• Per setting status: tells you which exact setting is failing
• Assignment failures: helps when multiple devices or multiple settings are breaking at once

On the affected Windows device

Microsoft Q&A guidance for 65000 repeatedly points to this event log:

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

This is the log to read before you rewrite the profile.

Also check:

• whether the setting actually applied in the local UI or registry
• whether the device is on the expected Windows edition/build
• whether gpresult shows an on-prem GPO controlling the same setting

PowerShell commands to speed up triage

Pull the recent MDM policy events

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 200 |
  Where-Object {
    $_.LevelDisplayName -in @('Error', 'Warning') -or
    $_.Message -match '65000|policy|conflict|not applicable'
  } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Confirm Windows version and edition on the failing endpoint

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
  Select-Object ProductName, DisplayVersion, CurrentBuild, EditionID

Check whether Group Policy is still setting the same area

gpresult /h C:\Temp\gpresult.html
Start-Process C:\Temp\gpresult.html

Force a fresh device sync from an elevated session

Start-Process 'ms-settings:workplace'

Then open Access work or school, select the connected work account, choose Info, and run Sync.

A practical workflow that works in production

Scenario A: Settings Catalog password or local policy setting shows 65000

1. Open the policy and identify the exact failing setting.
2. Check whether that setting is also configured in a security baseline, Administrative Template, or another Settings Catalog profile.
3. Confirm the setting is supported on the failing Windows edition.
4. Pull the DMEP Admin log from one failing device.
5. If a conflict exists, remove the duplicate owner and keep one source of authority.
6. Sync one test device and confirm the status changes from Error or Conflict to Succeeded.

Scenario B: Endpoint Security Account Protection profile shows 65000 type 2

1. Verify whether the local admin or local group membership actually changed on the device.
2. If the policy effect is correct but the report still shows failure, capture the DMEP log and compare it with the policy timestamp.
3. Check whether another local users/groups policy is also targeting the same group.
4. Review whether the assignment uses the right group type and whether the user/device has completed a fresh check-in.

Scenario C: User-scope setting fails during enrollment or first sign-in

1. Check whether the device has a real signed-in user yet.
2. If the setting is user scope, wait for the user hive to exist and force another sync.
3. Re-check whether the previous Not applicable or 65000 state clears on the next evaluation.

Prevention

1. Choose one policy owner per setting family. Do not split the same Windows control across Settings Catalog, baselines, Endpoint security, and custom OMA-URI unless you documented the precedence.
2. Review scope tags in the setting name. (User) and (Device) are not decoration.
3. Validate edition and build support before rollout. Especially for security, account protection, and newer Windows 11 settings.
4. Use per-setting status as the first report, not the last report. It reduces guesswork fast.
5. Expect assignment-report lag on large tenants. Do not declare failure based only on a recent group change.
6. Pilot with one known-good device and one known-problem device. That exposes build and scope differences early.

Final takeaway

65000 type 2 is usually a signal to narrow the problem, not a fix in itself. The fastest resolution is to stop looking at the whole profile, isolate the exact setting, inspect per-setting status, read the DMEP Admin log, validate scope, and remove duplicate ownership. Once you do that, most Intune 65000 incidents stop looking mysterious and start looking like ordinary policy hygiene problems.