OMA-URI Policy Builder
Browser-onlyBuild a custom configuration setting with the right data type and a value in the exact form Microsoft Graph expects, then export a profile you can create in Intune.
./Device/Vendor/MSFT/... for device scope, ./User/Vendor/MSFT/... for user scope.
How it works
Choose the data type for the CSP node, enter the OMA-URI and value, and the tool checks the
URI shape and enforces the canonical value form. It then produces two outputs: the single
omaSetting object, and a full
#microsoft.graph.windows10CustomConfiguration profile containing it.
The value is validated against the form Graph returns on read. That matters because Intune
applies a policy, reads the value back, and reports a compliance error if the two do not
match. Submitting True instead of true, or an integer with leading
zeros, is a common reason a custom profile silently fails.
Data types
| Type | Expected value |
|---|---|
| String | Any text. |
| Integer | Whole number, no leading zeros, e.g. 30 or -1. |
| Boolean | Exactly true or false, lowercase. |
| Floating point | Decimal, e.g. 1.5. |
| Date and time | UTC RFC 3339 ending in Z, e.g. 2026-01-01T00:00:00Z. |
| Base64 (file) | Base64 content plus a file name. |
| String (XML file) | Well-formed XML plus a file name. |
Supported scenarios
- Building a custom profile for a CSP setting the Settings catalog does not expose.
- Turning a known registry or policy value into a correct OMA-URI setting.
- Checking a value's format before pasting it into Intune or a Graph call.
Common problems
- OMA-URIs are case sensitive and must start with
./. - Device scope uses
./Device/Vendor/MSFT/...; user scope uses./User/Vendor/MSFT/.... - Base64 and XML settings need a file name; Graph rejects them without one.
- Only CSP nodes that support the Add, Replace and Get operations work with Intune.