For years, OMA-DM (Open Mobile Alliance Device Management) has been the backbone of policy management in Microsoft Intune. It follows a structured yet somewhat rigid model: devices sync on a schedule, fetch policies, apply settings, and report back. While this has worked well enough, it comes with some limitations, most notably, compliance and enforcement only happen when the device checks in.
But Windows policy enforcement is evolving. With the introduction of Microsoft Management Platform – Cloud (MMP-C) and Declared Configuration, the way devices handle policies is changing. Instead of polling for updates, devices now subscribe to a declarative model, where the desired configuration is defined once and continuously enforced. This represents a fundamental shift in how policies are applied, monitored, and maintained.
The Limitations of OMA-DM Policy Sync
To understand why this shift matters, it’s important to look at how traditional OMA-DM policy management works. The model is built around a cycle of request, response, and validation (get -set -get), meaning that a device:
- Requests policies from the Intune service.
- Receives and applies them.
- Reports back on compliance.
- Waits for the next scheduled sync to repeat the process.
This approach introduces a clear weakness: compliance is only checked at the time of the sync. If a setting is modified between check-ins, there is no immediate enforcement, Intune will only detect the issue when the next sync occurs.
Additionally, OMA-DM policies rely on SyncML, an XML-based format for defining configurations. While SyncML is functional, it’s not particularly efficient for enforcing policies dynamically or scaling up in environments where changes need to take effect instantly. Read this blog below for more information!
These challenges set the stage for Declared Configuration, which rethinks policy enforcement by shifting from a sync-driven model to a continuous state enforcement model.
Declared Configuration: Always Enforced, Always Up-to-Date
Declared Configuration eliminates the need for periodic syncs altogether. Instead of the device repeatedly checking for updates, it follows a declarative approach:
- A configuration document defines the intended state.
- The Windows Declared Configuration Service enforces this state continuously.
- If a setting deviates, it is automatically corrected.
This means policy compliance is no longer dependent on a scheduled sync cycle. Instead, the device enforces the configuration locally and only reports back when it detects drift. This eliminates compliance gaps and ensures that settings remain applied at all times.
But this isn’t just about improved enforcement, it also changes how devices communicate with the cloud. Instead of repeatedly polling Intune for updates, Declared Configuration operates independently, significantly reducing network overhead while providing more accurate, real-time compliance reporting.
This self-enforcing model closely resembles PowerShell Desired State Configuration (DSC). Like DSC, Declared Configuration defines the desired state rather than prescribing step-by-step changes, allowing the system to maintain compliance autonomously.
However, to make this enforcement model work efficiently, Microsoft introduced a key piece of the puzzle: MMP-C and Linked Enrollment.
The Role of MMP-C and Linked Enrollment
To implement Declared Configuration, Microsoft developed MMP-C (Microsoft Management Platform – Cloud), a new platform for handling policy enforcement independently of the traditional Intune sync process.
This introduces Linked Enrollment, which is where things get interesting.
In the past, a Windows device had one Intune enrollment, which handled everything—from app management to policy enforcement via OMA-DM. With MMP-C, an additional Linked Enrollment is created, allowing Declared Configuration to run in parallel to traditional Intune policies.
This means that:
- MDM policies and compliance settings still come from Intune.
- Declared Configuration enforces its own set of policies independently.
Devices now have two policy engines running side by side, one still using SyncML (OMA-DM) for legacy policies, and the other using Declared Configuration for modern, real-time enforcement.
But how exactly does Declared Configuration apply policies? The answer lies in the MOF file.
The MOF File: Defining Policy at the Core
At the core of Declared Configuration is a MOF (Managed Object Format) file, which acts as a blueprint for system settings. Unlike traditional OMA-DM policies, which rely on command-based execution (set a value, verify it later), MOF-based policies are continuously monitored and automatically remediated.
The Windows Declared Configuration Service processes the MOF file, ensuring that all settings persist as defined. If any deviation is detected, whether due to user modification, system changes, or application interference, the system automatically restores the intended state.
But this doesn’t just apply to security baselines and system configurations. Microsoft has extended Declared Configuration into resource access policies as well.
Windows now supports Declared Configuration Resource Access, which enables IT admins to define and enforce access settings like certificates, VPN configurations, Wi-Fi policies, and network settings—all within the same self-enforcing model. This means:
- VPN and Wi-Fi configurations remain intact, even if a user attempts to modify them.
- Network settings enforce compliance dynamically, without requiring periodic syncs from Intune.
By integrating resource access into Declared Configuration, Windows strengthens its ability to maintain secure and consistent access policies, without relying on traditional OMA-DM polling or external enforcement mechanisms.
This approach directly aligns with Microsoft’s shift toward declarative policy management, making access control settings as resilient and self-healing as security baselines.
What This Means for Policy Management
The introduction of MMP-C and Declared Configuration represents a fundamental change in how Windows devices handle policies. While OMA-DM still exists for compatibility, the future of Windows policy enforcement is clearly moving toward a state-based model rather than a sync-based model.
This transition brings clear advantages:
- MDM policies were reactive, only verifying compliance when a sync occurred.
- Declared Configuration is proactive, continuously enforcing settings in real time.
For IT admins, this means:
- Less reliance on scheduled syncs to enforce policies.
- Improved compliance accuracy due to continuous monitoring.
- Lower network load since devices don’t need to poll Intune as frequently.
But more importantly, this modern approach to policy enforcement aligns Windows with cloud-first management strategies. As Microsoft continues to push for more automation, self-healing systems, and intelligent device management, Declared Configuration is likely to become the new standard.
Final Thoughts
Windows policy enforcement has always relied on a pull-based model—devices would check in, retrieve policies, and apply them on schedule. But this approach has inherent delays and gaps in compliance enforcement.
Declared Configuration changes that by shifting to a state-based model, where policies are always active, settings are self-correcting, and compliance is validated in real time.
With MMP-C providing a dedicated enforcement engine, this model is more efficient, more reliable, and far better suited for modern cloud-driven environments.
For organizations managing Windows devices at scale, this means a fundamental improvement in how configurations are applied and maintained, and a significant step forward in the way Windows enforces security, compliance, and policy settings in the future.