From OMA-DM to MMP-C: The Evolution of Modern Windows Management

Modern Windows device management has undergone a significant transformation over the past decade. From the legacy days of Group Policy and SCCM to the cloud-native world of Microsoft Intune, the underlying protocols and architecture have evolved to meet the demands of modern IT. At the heart of this evolution lies the OMA-DM protocol, and more recently, Microsoft’s MMP-C and WinDC technologies.

Understanding traditional Device management with OMA-DM

What is OMA-DM?

OMA-DM (Open Mobile Alliance Device Management) is a secure management protocol that runs between a Device Management server (DM server) and a Device Management client (DM client) that was originally designed for managing mobile devices. Microsoft adopted it to enable modern device management for Windows 10 and 11.

The OMA-DM protocol runs within the context of a DM session, using a request/response transactional model. Once a DM session is established, the DM Server can send DM commands to the DM Client and receive responses from the DM Client.

It’s a transport‑agnostic protocol that uses SyncML (XML‑based standard) for communication between the DM server and DM client. In other words, the DM message is in reality a SyncML message send by the DM server to the DM client.

The communication is facilitated via a simple command set (Get, Add, Replace, Delete, Exec) that lets a DM server navigate and modify a device’s (DM client) Device Management Tree (DM Tree) over HTTPS.

The commands are as below:

• Get: Retrieves the value associated with the target node in the Management Tree of a device
• Add, Replace, Delete: Modify configuration values of the target node.
• Exec: Executes a predefined function, that is statically bound to the target node, on the device. Examples include initiating software download, running a diagnostic test etc.
• Copy: Replicates the structure and the node values associated with a sub-tree at one location to a different location within the Management Tree.

Each Windows device maintains a Device Management tree (DM Tree), where settings are exposed as nodes. These nodes are managed via Configuration Service Providers (CSPs), which act as the bridge between the SyncML commands and the Windows OS, enabling MDMs like Intune to configure PCs remotely.

Note: Windows 8 brought early MDM elements (Workplace Join, lightweight DM client), laying the foundation for OMA‑DM on Windows PCs. Windows 10 integrated a full MDM client using OMA‑DM v1.2 over HTTPS; Intune became the primary orchestrator of CSPs at scale.

Note: DM sessions are always initiated by the DM Client. However, a Server can also trigger the Client to initiate a session by sending an unsolicited message, known as the DM Notification, to the Client. 

The DM Notification “wakes up” the device and causes it to initiate a session with the requesting DM Server. This message can be delivered over a variety of transports including SMS, HTTP and SIP. 

For Windows, this is facilitated via the Windows Notification Service (WNS).

In addition, the DM client can, at times, also send Generic alerts to the DM server that MAY have a relation to Management Objects (Mos). For example, if a configuration drift (change) is observered, or a new MO gets available, the DM client may use an Generic Alert to notify the DM server that data in the device's DM Tree has changed after the last session.

Key Components Illustrated:

• Intune (DM Server): Sends SyncML commands to the device.
• WNS (Windows Notification Service): Used for server-initiated session triggers.
• DM Client (OMA-DM Engine): Parses and processes SyncML messages.
• CSPs (Configuration Service Providers): Apply settings as instructed by the DM client.
• PolicyManager (when applicable): Enforces policy-backed CSP settings.
• Status Reporting: SyncML responses are sent back to Intune with command execution results.

Key Concepts in OMA-DM:

DM Bootstrapping

Bootstrapping is the process by which a device moves from an un-provisioned, empty state, to a state where it is able to initiate a management session to a DM Server. Bootstrapping is a prerequisite for a DM Client to process messages from a DM Server.

Device Management Tree (DM Tree)

The OMA-DM protocol supports the notion of Management Objects (MOs). These are abstract representations of remotely manageable capabilities exposed by the device. All the available MOs pertaining to a device are organized in a hierarchical tree structure known as the Management Tree. 

Thus in simple words, the Management Tree may be looked upon as the complete management view of a device’s configuration and operational status. 

The DM tree comprises of nodes. A node reflects a set of configuration parameters for a device, actions that can be taken against this node might include reading and setting parameter keys and values. Each node in the tree corresponds to a specific configuration area, such as Wi-Fi, VPN, or Windows Update settings.

• Nodes are addressed/identified by URIs – The URI of a node is the concatenation of the names of all the nodes from the root of the Management Tree, using ‘/’ as the delimiter.

(e.g., ./Device/Vendor/MSFT/Policy/Config/DeviceLock/MaxInactivityTimeDeviceLock)

• Nodes can be interior (containers or Management Objects (MO)) or leaf (actual settings)
• The tree is manipulated using SyncML commands like Get, Add, Replace, Delete, and Exec

Configuration Service Providers (CSPs)

CSPs are the bridge between the DM Tree and the Windows OS. Each CSP exposes a set of settings that can be configured via MDM. For example:

• Policy CSP: Manages security and configuration policies
• WiFi CSP: Manages wireless profiles
• Update CSP: Controls Windows Update behavior

Many CSPs write to the PolicyManager registry under HKLM\SOFTWARE\Microsoft\PolicyManager\….

The WMI-to-CSP Bridge: WMI Bridge (MDM Bridge Provider)

To support traditional management tools like SCCM, Microsoft introduced the MDM Bridge WMI provider (WMI-to-CSP bridge). This allows administrators to use PowerShell or WMI to interact with CSPs, enabling hybrid management scenarios.

OMA-DM Workflow

Traditional OMA-DM workflow is imperative and transactional. From a high-level overview, it’s a Get -> Set -> Get model where the DM server queries device state, sends configuration commands, and verifies the result. This Get-Set-Get loop is repeated every 8 hours or on-demand.

Below is a detailed step-by-step breakdown of a typical OMA-DM session workflow from initiation to termination:

1. Session Initiation

• Trigger: The session can be initiated by either the DM server (server-initiated) or the device (client-initiated).
  • Server-initiated: Often triggered via a push message (e.g., WAP Push or SMS).
  • Client-initiated: Triggered by the device itself, often during boot-up or at scheduled intervals.
• Authentication: The device and server authenticate each other using credentials (e.g., username/password, certificates, or tokens).

2. Device Information Exchange (Bootstrap Phase)

• The device sends a SyncML Alert message to the server, indicating its readiness and providing basic device information (e.g., device ID, manufacturer, model, firmware version).
• The server may respond with a Bootstrap message to configure the device with initial settings (e.g., server address, credentials, management tree structure).

3. Management Tree Discovery

• The server queries the device’s Management Tree, a hierarchical structure representing manageable parameters and objects (e.g., network settings, installed apps, security policies).
• The device responds with the structure and current values of requested nodes.

4. Command Execution Phase

The server sends a series of management commands in SyncML format. Common commands include:

• Get: Retrieve values from the device.
• Add: Add new nodes or configurations.
• Replace: Modify existing values.
• Delete: Remove nodes or configurations.
• Exec: Execute specific actions (e.g., factory reset, install app).

The device processes each command and responds with status codes indicating success or failure.

5. Status and Results Reporting

• The device sends a SyncML Response message with:
  • Status codes for each command (e.g., 200 for success, 404 for not found).
  • Results of any Get commands or executed operations.

6. Iterative Command Exchange (if needed)

• If the server has more commands or needs to respond to device feedback, it sends another SyncML message.
• This loop continues until all commands are processed.

7. Session Termination

• Once all commands are executed and acknowledged, the server or device sends a Final message to terminate the session.
• The session is closed gracefully, and the device may return to idle or scheduled check-in mode.

Optional: Notification or Alert Handling

• Devices may send unsolicited alerts (e.g., error reports, status updates).
• The server may respond with corrective actions or log the event.

Example SyncML communication in traditional OMA-DM management

<xml version="1.0" encoding="UTF-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
  <SyncHdr>
    <VerDTD>1.2</VerDTD>
    <VerProto>DM/1.2</VerProto>
    <SessionID>1</SessionID>
    <MsgID>1</MsgID>
    <Target>
      <LocURI>./Device</LocURI>
    </Target>
    <Source>
      <LocURI>Intune</LocURI>
    </Source>
  </SyncHdr>
<SyncBody>
<Add>
      <CmdID>2</CmdID>
      <Item>
        <Target>
          <LocURI> ./Device/Vendor/MSFT/Policy/Config/Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices</LocURI>
        </Target>
        <Meta>
          <A:Format>int</A:Format>
          <A:Type>text/plain</A:Type>
        </Meta>
        <Data>1</Data>
      </Item>
</Add>
<Get>
      <CmdID>3</CmdID>
      <Item>
        <Target>
          <LocURI> ./Device/Vendor/MSFT/Policy/Config/Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices</LocURI>
        </Target>
     Item>
    </Get>
    <Final/>
  </SyncBody>
</SyncML>

Key Elements: Understanding SyncML message

• Header (<SyncHdr>)
  • Specifies protocol version (DM/1.2) and session details.
  • Target = Device
  • Source = Intune

• Body (<SyncBody>)

• Add Command
  • Adds a CSP node value:
    ./Device/Vendor/MSFT/Policy/Config/Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices
  • Sets value to 1 (int format) → Prevents automatic device encryption for AAD-joined devices.

• Get Command
  • Requests the current value of the same CSP node for verification.

• Final → Indicates end of message.

Why the shift to MMP-C and WinDC?

While OMA-DM works, it has its own limitations:

• Server-driven logic: The server must understand the device’s current state and orchestrate every change.
• Synchronous: Each step waits for the previous one to complete, increasing latency and complexity.
• Fragility: Failures in the command chain can delay enforcement.
• High overhead: Requires constant polling and deep knowledge of device internals.

The Shift to Modern management with MMP-C and WinDC

What is MMP-C?

Microsoft Management Platform – Cloud (MMP-C) is a new management plane designed for modern, scalable, and reliable device management. It introduces a declarative model where the desired state is defined once and enforced continuously.

Unlike OMA-DM, which is imperative and command-driven, MMP-C is state-based: Intune defines the desired state, and the device is responsible for achieving and maintaining that state.

• DM service (Intune) declares the desired state
• Device receives a single configuration document that defines the defined state
• The WinDC client applies and maintains the state
• If a setting drifts, the device re-applies the correct configuration

This approach is similar to PowerShell Desired State Configuration (DSC) but integrated natively into the Windows MDM stack as WinDC.

Example MOF Document

{
    Id = "Policy_Example_001";
    Version = "1.0";
    Settings = {
        instance of MSFT_DeclaredSetting
        {
            Path = "./Device/Vendor/MSFT/Policy/Config/DeviceLock/MaxInactivityTimeDeviceLock";
            Value = "300"; // 5 minutes
            DataType = "integer";
            Remediation = "Enforce";
        },
        instance of MSFT_DeclaredSetting
        {
            Path = "./Device/Vendor/MSFT/Policy/Config/DeviceLock/PasswordRequired";
            Value = "true";
            DataType = "boolean";
            Remediation = "Enforce";
        }
    };
    ApplicabilityRules = {
        instance of MSFT_ApplicabilityRule
        {
            RuleType = "OSVersion";
            MinVersion = "10.0.22000";
        }
    };
};

Key Elements

• Id & Version: Identifies the declarative configuration.
• Settings: Each setting maps to a CSP node (e.g., DeviceLock policies).
• Remediation: Specifies enforcement behavior.
• ApplicabilityRules: Defines conditions like OS version.

What is WinDC?

Windows Declared Configuration (WinDC) client stack is a modern component of the Windows management architecture, especially relevant in the context of MMP-C which is responsible for receiving, interpreting, applying, and maintaining the desired state configuration sent by a management service like Microsoft Intune.

It is central to the declarative management model introduced with MMP-C. It uses a MOF-based declarative document to define the desired configuration state.

Key components of MMP-C/WinDC

1. WinDC Agent

• Acts as the entry point for MMP-C payloads.
• Periodically pulls the desired state from Intune.
• Validates and parses the MOF-based configuration document.

2. PolicyManager

• Core engine that evaluates the current state of the device.
• Compares it against the desired state.
• Determines what needs to be changed to achieve compliance.

3. Configuration Service Providers (CSPs)

• Interfaces that expose specific device settings (e.g., BitLocker, Wi-Fi, Windows Update).
• Invoked by PolicyManager to apply settings.
• Return status and results after applying configurations.

4. State Repository

• Stores the current and desired state of the device.
• Used by PolicyManager to detect configuration drift.
• Enables self-healing by reapplying settings if they are changed or removed.

5. Reporting Engine

• Collects compliance and status data.
• Sends reports back to Intune for visibility and auditing.

Linked Enrollment: Dual Channels for Management

To support MMP-C, Microsoft introduced Linked Enrollment where a device maintains two enrolments:

• Primary: Classic MDM (Intune) using OMA‑DM.
• Linked: Declared configuration (WinDC) channel for MMP‑C workloads.

Note: The device performs a discovery to obtain declared‑config endpoints, then enrols (using new DMClient CSP policies) under a dependent channel. Microsoft’s documentation outlines the Discovery (JSON schema to Discovery Service) and Enrollment phases, and the requirement that this second enrollment exists only if a primary MDM enrollment already exists. Initially, it was Endpoint Privilege Management (EPM) policy activation that previously “kicked off” this linked enrollment automatically. But with the rollout of newer workloads like Device Inventory, Microsoft made this dual enrollment universal -  all Windows devices are onboarded to MMP-C without requiring any admin action.

The MMP-C Workflow

MMP-C workflow is declarative and state-based (Declare → Deliver → Enforce ).

• Initial Setup:

When the device first enrolls and the MMP-C channel is established, Intune uses OMA-DM SyncML commands to configure the DeclaredConfiguration CSP node. This sets up the declarative management channel.

• After Setup:

Once the DeclaredConfiguration CSP is configured, the actual MOF-based declarative document delivery and updates happen through the WinDC pull mechanism, not via SyncML.

• The device periodically checks in and pulls the latest declared state from Intune/MMP-C.
• This is asynchronous and uses HTTPS, not SyncML.

It is to be noted that, for MMP-C, the only time OMA-DM is involved is during initial setup phase (bootstrap) to configure the DeclaredConfiguration CSP. After that, all communication for declarative state happens over HTTPS pull initiated by the device.

Below is a detailed step-by-step breakdown of a typical MMP-C (WinDC) workflow:

1. Linked-Enrollment

• Device receives a CSP policy that triggers MMP-C enrollment, creating a secondary management channel linked to the primary Intune enrollment. This process is referred to as linked enrollment

2. Desired State Publication

• Intune, as the DM server, generates a MOF-based declarative configuration document.
• This document includes:
  • Target CSP nodes
  • Desired values
  • Applicability rules
  • Remediation instructions

1. Device Check-in

• Windows 11 device periodically initiates a pull-based sync. During this sync, the WinDC agent contacts the MMP-C platform to fetch the declared desired state.
• The declared state is delivered asynchronously via the DeclaredConfiguration CSP as a single MOF-based config document.

4. State Evaluation

• PolicyManager compares the current state of the device with the desired state as defined in the received declarative document and determines what needs to change for adherence.

5. Configuration Application

• PolicyManager invokes the appropriate CSPs to apply settings.
• CSPs apply the settings and return status.
• Updated state is stored in the local config repository.

6. State Reporting

• The device reports back:
  • Current state
  • Compliance status
  • Any errors or conflicts

7. Remediation (if needed)

• If the device drifts from the desired state (e.g., user changes a setting), PolicyManager re-applies the correct configuration. This ensures continuous compliance with the declared state.

Devices enrolled in MMP-C (WinDC) performs a pull-based sync approximately every 4 hours to fetch the latest declarative configuration from Intune/MMP-C. This is shorter than the traditional OMA-DM interval, which is typically 8 hours for policy refresh. The sync is lightweight and completes within seconds because it retrieves a single MOF-based declarative document rather than multiple procedural commands.

Benefits of MMP-C over OMA-DM

• Efficiency: Batch processing and asynchronous execution reduce network chatter as compared to OMA-DM flow.
• Scalability: Ideal for large enterprise environments with thousands of devices.
• Resilience: Devices self-heal by reapplying the declared state if drift is detected.
• Security & Compliance: Ensures consistent policy enforcement.

Drift Detection and Self-Healing with WinDC

One of the most powerful features of WinDC is its drift detection capability. Here is how it looks as an overview.

• Apply declaration locally (batch of settings for a “scenario”).
• Monitor intended vs. actual state.
• Remediate if drift is detected (re‑apply).
• Report exceptions to the service when remediation fails.

In simple words, the device continuously compares its current state with the declared configuration and if a setting is changed (e.g., by a user or malware), WinDC detects the drift. The system then automatically tries to revert the setting to the desired state. If the drift cannot be resolved, it is reported back to Intune for remediation.

This model ensures continuous compliance and reduces the need for frequent server-side polling.

Contrast with classic OMA‑DM: Windows 11’s Config Refresh improves the periodic enforcement for Policy CSP (as low as 30 minutes, offline reset of managed settings), but it’s still within the OMA‑DM/Policy CSP model. WinDC goes further by managing the entire scenario declaratively.

Real-World Use: Endpoint Privilege Management (EPM) and Device Inventory (Properties catalog)

One of the first workload to leverage MMP-C and WinDC in Intune is Endpoint Privilege Management (EPM). Instead of relying on OMA-DM, EPM policies are delivered via the MMP-C channel, enabling faster and more reliable enforcement of privilege elevation rules. This dual-enrollment model allows devices to:

• Continue using Intune for traditional MDM tasks.
• Use MMP-C for advanced, state-based configurations.

Moving forward, the Device Inventory workload of Intune also leverages the MMP-C path where Declared configuration is used to define what telemetry properties to collect; an agent enforces collection and uploads to Resource Explorer.

It is expected that more workloads will move to MMP-C way in the future, while classic OMA‑DM will continue to remain for breadth and compatibility.

Putting it together: OMA‑DM vs. MMP‑C at a glance

MMP-C vs OMA-DM in Intune

Conclusion

OMA‑DM brought Windows into the mobile management era and still provides broad CSP coverage and ecosystem compatibility. But as enterprises demand speed, resilience, and continuous compliance, Microsoft’s MMP‑C + WinDC stack brings the next evolution to Windows modern management – declare once, enforce always.

This evolution from OMA-DM to MMP-C and WinDC represents a significant leap forward in Windows device management. By embracing a declarative, state-based model, Microsoft is aligning Windows with modern management paradigms already seen in platforms like iOS/MacOS.

Over the next few product cycles, we expect more workloads to shift to this dual‑enrolled architecture, while classic OMA‑DM will continue to remain as the safety net for legacy settings and cross‑vendor parity.

As a closing note, we can confidently say that the future of Windows management is here—and it’s cloud-native, declarative, and resilient.

References

1. OMA‑DM protocol support in Windows (commands, behavior, HTTPS/SyncML) — Microsoft Learn
   <https://learn.microsoft.com/en-us/windows/client-management/oma-dm-protocol-support>
2. Server requirements for using OMA‑DM — Microsoft Learn
   <https://learn.microsoft.com/en-us/windows/client-management/server-requirements-windows-mdm>
3. OMA Device Management Protocol v1.3 — OMA Spec
   <https://www.openmobilealliance.org/release/DM/V1_3-20160524-A/OMA-TS-DM_Protocol-V1_3-20160524-A.pdf>
4. [MS‑MDM] Example of an OMA‑DM session — Microsoft Learn
   <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-mdm/65195c4e-3ac0-4eb4-a950-090cf36be3a5>
5. Windows declared configuration (WinDC) protocol overview — Microsoft Learn
   <https://learn.microsoft.com/en-us/windows/client-management/declared-configuration>
6. MMP‑C: Onboarding & Linked (Dual) Enrollment — call4cloud (Rudy Ooms)
   <https://call4cloud.nl/mmp-c-onboarding-linked-enrollment-dual-enrollment/>
7. When does the device sync with MMP‑C (every ~4h) — call4cloud
   <https://call4cloud.nl/when-does-a-device-sync-with-mmp-c/>
8. Declarative Device Management with Intune (WinDC RAW/COOKED, orchestration) — call4cloud
   <https://call4cloud.nl/declarative-device-management-intune-ddm/>
9. Device Inventory and MMP‑C: flow & visuals — Joost Gelijsteen
   <https://joostgelijsteen.com/device-inventory-mmp-c/>
10. OMA‑DM and Intune policy enforcement (Get‑Set‑Get deep dive) — Joost Gelijsteen
    <https://joostgelijsteen.com/oma-dm-and-intunes-policy-enforcement/>
11. Windows 10 MDM Bridge WMI Provider: Settings template — Peter van der Woude
    <https://petervanderwoude.nl/post/windows-10-mdm-bridge-wmi-provider-settings-template/>
12. Deploy OMA‑URIs to target a CSP via Intune (scope, syntax) — Microsoft Learn
    <https://learn.microsoft.com/en-us/troubleshoot/mem/intune/device-configuration/deploy-oma-uris-to-target-csp-via-intune>
13. MDM for device updates (flow diagram & concepts) — Microsoft Learn
    <https://learn.microsoft.com/en-us/windows/client-management/device-update-management>
14. MDM enrollment of Windows devices — Microsoft Learn
    <https://learn.microsoft.com/en-us/windows/client-management/mdm-enrollment-of-windows-devices>
15. Windows CSP caveats in hybrid/MDMWinsOverGP context — skiptotheendpoint
    <https://skiptotheendpoint.co.uk/windows-csp-a-tale-of-magic-betrayal-and-intrigue-part-2/>
16. Windows 11 Config Refresh (Policy CSP periodic enforcement) — Windows IT Pro Blog (Microsoft)
    <https://techcommunity.microsoft.com/blog/windows-itpro-blog/intro-to-config-refresh-%e2%80%93-a-refreshingly-new-mdm-feature/4176921>