Where every OMA-URI lives. A path is a context root, the vendor namespace, then a CSP and its nodes. Dual-context CSPs appear under both roots — same provider, two scopes. This is the common subset, not the full tree.
context root — picks scopevendor namespace — always MSFTCSP + nodes — the actual setting
device contextuser contextstandard OMA-DM node⇄ dualsame CSP in both scopesreadreporting / Get only
./management tree root
│
┌─ Device/ Vendor/ MSFT/machine-wide
└─ User/ Vendor/ MSFT/enrolled user
Detail
Pick a CSP
Tap any node in the tree for an example OMA-URI, its scope, and what it does.
Dual rows appear twice — under Device and under User — on purpose. The CSP is the same; the prefix chooses the scope.
Inside the Policy CSP
⇄ dual-context
The one CSP worth opening up — it holds thousands of settings as Area/Policy pairs. Two parallel branches mirror each other: one you write to, one you read from.
./Device|./User / Vendor/MSFT / Policy / …
Config/
write · enforce
The desired-value surface. A profile Replaces a policy here to enforce it. This is what you target.
Result/
read · effective
A read-only mirror of the same Area/Policy structure, returning the value actually in effect. You Get from here to verify.
ConfigOperations/
extend
ADMXInstall ingests custom / third-party ADMX, so its settings become addressable as new Areas under Config & Result.
Areas under Config/ & Result/ — representative subset (there are dozens)
Tap an Area to see representative policies and the full OMA-URI — including how the same leaf reads back under Result/.
Reading the tree: the bare form ./Vendor/MSFT/… resolves to device scope, so device-only CSPs carry no prefix. A ./Device or ./User prefix only appears (and only matters) on the ⇄ dual CSPs. Context support shown is the common case — confirm a specific CSP in its reference doc, since a few have nodes in just one scope even within a dual provider.