This blog examines Error code 65000 when deploying Settings Catalog policies in Intune, specifically for ADMX-backed policies. Normally, Intune delivers the required ADMX template via ADMXInstall CSP, allowing policies to be configured. However, multiple organizations on Europe 0301 (ASU) reported policies failing with Error 65000, and no trace of ADMXInstall in SyncML logs. This led to an investigation into missing policy commands, registry keys, and an issue beyond the admin’s control.
The 65000 Error Code
It all started with a simple message.
“Hey, do you know why our ADMX-backed OneDrive Policies aren’t applying?”
It’s not the first time I’ve heard that question. Policies failing to apply in Microsoft Intune isn’t exactly groundbreaking news. It happens. Maybe the device hadn’t synced properly, maybe there was a bad configuration, or maybe the user forgot to reboot.
But then, another company reached out. Then another. Then another.
By the time the fourth company reported the same issue, it was obvious this wasn’t some random delay.
Something was wrong.
But what?
- Devices were syncing with Intune, but policies weren’t applying
- No sign of ADMXInstall in SyncML logs
- Error 65000 across all affected devices
- And one very specific pattern: every single affected tenant was on the Europe 0301 azure scale unit
That couldn’t be a coincidence.
Step One: How ADMX Policies Are Supposed to Apply
Before diving into troubleshooting, confirming how things were supposed to work made sense. ADMX-backed policies follow a different process than standard MDM policies. Instead of interacting directly with the Policy CSP, OMADMClient.exe calls PolicyManager.dll, which handles ADMX ingestion and policy delivery.
Expected Flow of ADMX Policies
You configured the ADMX backed Edge/OneDrive policy in Intune and assign the policy to your devices
The moment the device checks in the MDMclient (OMADMClient.exe) syncs the policy and hands it off the power to PolicyManager.dll.
If the ADMX template is missing, the ADMXInstall CSP with the ADMX will be sent to the device. From there on the PolicyManager.dll triggers the Verify ADMX Policies Are not Set and IngestAdmxTextBlob functions, which downloads and registers the ADMX
- A registry entry is created in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled
- ADMX files are stored in: C:\ProgramData\Microsoft\PolicyManager\ADMXIngestion
- Once the ADMX template is in place, Intune applies the policy settings (sometimes it happens in the wrond way around and with it also causing the error code 65000)
At this point, the policies should appear in:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies and the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policymanager
This is where Edge settings, OneDrive policies, and any other ADMX-backed configurations should be enforced. But on affected devices, none of this was happening.
The ADMX Flow.
The corresponding flow to the stuff above….
Step Two: The 65000 Error. What It Actually Means
Before investigating further, it was worth looking at what Error 65000 actually tells us.
In a previous deep dive (65000 Error 0x82b00006 – Settings Catalog), we explained how this error does not indicate a specific failure. Instead, it is a generic response when the MDM client cannot process a policy correctly.
Why Does 65000 Happen?
- The policy is misconfigured
- The required ADMX template is missing
- Intune is sending an unsupported setting
- An issue in Intune’s backend prevents delivery
- The policy is first delivered before the ADMX
In other words:
“We don’t know what to do with this policy, so here’s a nice 65000 error for you.”
So….What if Intune never sent the ADMX template? What happens then?
Step Three: The Missing ADMXInstall CSP
If Intune was correctly deploying ADMX-backed policies, the SyncML tool should show us the admxinstall CSP dropping down to the device.
That command tells the device to ingest the ADMX template before applying policy settings. After pulling the MDMlogs from the Intune Portal we noticed that on every affected device, the admx itself was missing. In a working environment the logs should have included something like this:
There was no reference to the ADMX ingestion at all, only the event logs in which it is mentioned that the system cannot find the file specified for the corresponding ADMX policies
The devices weren’t only failing to apply policies, but they were never receiving the instruction to install the ADMX template in the first place. With it the ADMX files and the corresponding PolicyManager registry key weren’t created!
So now what? We had ruled out:
- Misconfiguration – policies were assigned correctly
- Sync issues – devices were successfully communicating with Intune
- Device-specific problems – all affected tenants were on EU 0301
What do you even troubleshoot when there’s nothing left to check?
At this point, there was no workaround. Nothing we could modify, reset, or adjust on the devices themselves. So, where does that leave us?
Step Four: Reaching Out to Microsoft about the 65000 error
With no leads left, we reached out to Microsoft “support” to ask:
“Are there any known issues affecting ADMX policy delivery ?”
After having a funny, long conversation, things started to become clear. It was not just us. Other organizations were seeing the same issue. While talking with Microsoft support, they asked us to look at the Health Service.
Step Five: What Was Happening at the Service Level?
There it was.
The Service Health Message above is telling us:
New or updated Administrative Templates policies may not be delivered to users’ devices.
Status: Service degradation
Scope: Admins in the Northern Europe region
Root cause: A backlog of ADMX policies was not being processed efficiently, resulting in a delay in delivering policies to devices.
That explained everything. This was not a sync issue, a misconfiguration, or an Intune bug. It was Microsoft’s backend, and companies on the EU 0301 ASU were stuck waiting for policies to be processed. There was nothing anyone could do but wait.
Step Six: The Moment It “Fixed Itself”
And then, hours later, it happened. One message after another.
“Surprise surprise, ADMX is working now. I just ran a sync, and they came through.”
No policies were modified. No configurations were adjusted. Microsoft cleared the backlog and suddenly, everything started working.
A final check confirmed it:
- SyncML logs now showed ADMXInstall
- Event Viewer confirmed MDM PolicyManager: ADMX Ingestion was processing
- Registry keys were created, and policies were finally applied
Just like that, the problem was gone. Whoooop!!
Final Thoughts: When ADMX Policies Disappear, Look Upstream
This case was a perfect example of how policy failures can look like a device issue when they are actually a backend infrastructure problem.
If ADMX-backed policies are not applying, do not just check the device. Instead:
- Check SyncML logs → If ADMXInstall is missing, the device never received the command
- Check Event Viewer logs → If MDM PolicyManager: ADMX Ingestion is not there, ingestion never even started
- Check the Microsoft Service Health Dashboard → If there is a backlog, you will not be able to fix it manually
Because sometimes, it is not your policy; it is just stuck in a queue that only Microsoft can clear.