Intune OMA-URI: why it fails, and why it will not revert

An Intune OMA-URI setting that does not apply almost never tells you so. The profile reports success, the assignment looks correct in the portal, and the device keeps its old value, because Intune confirms that it delivered the payload and not that Windows accepted it. This post covers where that gap opens, the five mistakes that account for most of it, and the behaviour that catches people out afterwards: removing the assignment does not reliably put the setting back.

Custom profiles are the last resort in Intune. They exist for settings that the settings catalog and the device restriction templates do not expose, which is a shrinking list and still a real one. That makes them unusually unforgiving. Nothing validates the string you type, and it is passed through to Windows close to verbatim. If the built-in surfaces might already cover what you need, check settings catalog vs administrative templates first, and if you are working a broader symptom rather than this one, start from Intune troubleshooting when the portal reports success. Every Microsoft fact below was verified against Microsoft Learn on 22 October 2026.

How the payload actually reaches the device

Most custom profile problems are easier to place once you can name which link in the chain broke. Microsoft’s guidance on deploying OMA-URIs to target a CSP breaks it into five parts, and the distinction between the container and the payload is the one that matters when you are reading a status.

Intune reports on the container. The CSP decides what happens to the payload, and it reports back through a separate read path. That split is the reason a profile can be green in the admin centre while the setting it carries was rejected on the device.

Why an Intune OMA-URI silently fails

Five causes cover most of it, and none of them produce a message that names the problem.

The string is case sensitive. Microsoft states this plainly in the documentation for custom settings for Windows devices. A URI copied out of a blog post and retyped with different casing is a different URI as far as the CSP is concerned, and a wrong one resolves to nothing rather than to an error you would notice.

The scope prefix is wrong for that CSP. Every policy has a scope fixed by the Windows platform, not by Intune, and the scope dictates the prefix. Some settings can only be configured at device level, others only at user level, and using the wrong one fails rather than falling back.

1# Device scope. Applies regardless of who signs in.
2./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName
3
4# User scope. Applies to that signed-in user only.
5./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName
6
7# The matching read path. This is the value the device reports back.
8./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName

Worth knowing before you copy anything: the Microsoft troubleshooting page sets out those scope rules and then gives a worked lock screen example that omits the prefix entirely, writing the URI as ./Vendor/MSFT/Policy/Config/DeviceLock/EnforceLockScreenAndLogonImage. The page does not reconcile the two. Check the scope of the specific setting in the Policy CSP reference rather than inferring it from an example.

The CSP does not support the operations Intune needs. A setting has to support Add, Replace and Get. If it does not, Intune cannot manage it through a custom profile at all, however well formed the URI is.

The setting does not exist on that build. Not every CSP setting works on every Windows client version. The CSP reference lists supported versions per setting, and a URI that is valid on one build resolves to nothing on an older one.

The value read back does not match the value sent. This one is worth dwelling on, because of how it is reported. If the Get value does not match what Add or Replace supplied, Intune records a compliance error. You go looking for a syntax problem and find a compliance result, which is the same confusion of categories described in Intune compliance policy delay, arriving from the opposite direction.

The failure modes, and where to read them

Microsoft reduces the diagnosis to two questions: did the policy reach the device, and did it reach the device but not take effect. Those have different evidence, and the order matters.

1. Confirm delivery first. The client logs should carry a reference to the custom policy or the OMA-URI setting. If that reference is absent, the policy did not arrive, and the problem is the profile configuration or the assignment, not the URI.
2. If it did arrive, read the device log rather than the portal. Rejected payloads surface in the Admin channel of the MDM diagnostics provider log, and Microsoft’s own guidance is that the cause is frequently a syntax problem in the OMA-URI string.
3. Only then start changing the URI. Each edit needs a sync and a re-read, so guessing is expensive.

1# On the device, this is where a rejected payload actually surfaces.
2# Event Viewer > Applications and Services Logs > Microsoft > Windows >
3# DeviceManagement-Enterprise-Diagnostics-Provider > Admin

The pattern of a policy that reports success and enforces nothing is not unique to custom profiles. It is the same reporting gap as Intune firewall rules that silently fail to apply, and when two policies describe the same setting you are also into the evaluation question covered in Intune policy conflict. Rule out conflict before you rule out syntax, because conflict is cheaper to check.

Why unassigning will not revert the setting

This is the part that deserves more attention than it gets, and it is documented rather than folklore. Changing the policy on the Intune side pushes the new value and the setting updates. Removing the assignment is a different matter. Microsoft states that removing the assignment of the policy from the user or device may not revert the setting to its default value.

A few profile types are designed to be removed cleanly: Wi-Fi, VPN, certificate and email profiles come off with the assignment. Everything else depends on the behaviour of the individual CSP, because that behaviour is controlled by the CSP and not by Intune. For an Intune OMA-URI payload, the realistic assumption is that unassigning leaves the value exactly where you put it.

The practical consequence is that a custom profile is not a toggle. Before deploying one, work out what the reversal looks like, which usually means a second payload that writes the default back explicitly rather than an absence of policy. Deciding that after a bad rollout is considerably worse than deciding it before.

The audit blind spot

One more behaviour that surprises people doing a review rather than a deployment. Values for the string, base64 and XML data types are obscured in the console. Only accounts holding Create, Read and Update on device configurations, such as the Policy and Profile manager role, or the Intune Administrator role in Microsoft Entra, can see them.

That is reasonable, since these payloads carry secrets often enough. It also means a read-only auditor cannot verify what a custom profile actually sets, and an inventory built from the console by someone without those permissions will be quietly incomplete. Pull the configuration through Microsoft Graph instead, with an account that holds the permission.

1# Lists every Windows custom profile in the tenant, which is the set
2# of policies carrying OMA-URI payloads. Useful before a migration.
3Get-MgDeviceManagementDeviceConfiguration -All |
4  Where-Object { $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.windows10CustomConfiguration" } |
5  Select-Object Id, DisplayName, LastModifiedDateTime

What I would do differently

I have not run an Intune OMA-URI rollout in production. My tenant is a lab with no enrolled devices, so what follows is what the documentation supports and where I would expect it to bite, not a measured result.

The first thing I would change is the order of work. The instinct with a custom profile is to get the setting working and move on, which leaves the reversal undefined at exactly the moment you are least likely to need to think about it and most likely to need it later. Given that unassignment may not revert anything, I would write the reversal payload at the same time as the deployment payload and keep both.

The second is scope discipline. One setting per profile is wasteful in clicks and much cheaper in diagnosis, because a profile carrying six payloads gives you a single status covering six things that fail for different reasons. The firewall case is the extreme version of this, where one malformed entry takes the whole profile down.

The third is to re-check the settings catalog before writing any new custom profile rather than after. Microsoft’s own guidance in the troubleshooting page is to use the built-in policy settings whenever possible and reserve custom OMA-URI policies for options that are otherwise unavailable. The catalog has grown steadily, and a payload that was necessary two years ago may now have a supported equivalent that reports properly and reverts properly.

What I would not do is treat a working custom profile as finished. It is a payload aimed at a platform surface that Microsoft keeps moving, with reporting that tells you about the container rather than the contents.

Last verified: 22 October 2026.