Be prepared for Windows Declared Configuration in Intune

Imagine you have a list of rules for how your devices should behave. Declared Configuration is like giving your devices a set of instructions and telling them to always follow these rules. Once you set these rules, the devices will keep checking themselves to make sure they are following them correctly. If they find that they are not following the rules, they will fix themselves automatically without needing to ask for help.
But wait, isn´t this how Intune always have worked with configuration policies and scheduled sync. The thing is, Intune uses OMA-DM to configure the CSP in Windows. But the user can sometimes change these settings after the configuration is applied. This could break things or open a potential security risk. Declared Configuration is better at keeping the desired state in your devices.
How Does Declared Configuration Work?
Declared Configuration leverages a model similar to PowerShell Desired State Configuration (DSC). Devices declare their desired state and continuously enforce it, ensuring that any changes or deviations are automatically corrected. This self-healing capability is a significant advancement in device management, providing IT administrators with greater control and assurance over their device fleet.
Think of Declared Configuration as a self-driving car. You set the destination (the rules), and the car (your device) drives itself to that destination. If it goes off course, it corrects itself and gets back on track without needing to call you for directions.
By default, the task to run Declared Configuration refresh in Windows is executed every four hours, but you can change that if needed. Each time the refresh task runs, it checks for any differences from the desired state by comparing the current system setup with what’s specified in the Declared Configurations. If it finds any differences, the Declared Configuration engine tries to reapply the documents to fix them. If a Declared Configuration can’t be reapplied because some data is missing, it’s marked as drifted, and a new sync session is started to let you know there’s a drift.

Declared Configuration also uses MOF files, just like PowerShell DSC. The MOF file works as a blueprint for system settings. The MOF is then used for continues monitoring of the system and make sure it always is complaint with the MOF. This also ensures settings persist as defined, even if modified by users or applications.
What is OMA-DM and why is Declared Configuration better?
OMA-DM (Open Mobile Alliance Device Management) is a traditional method used in Intune to configure device settings. It involves deploying custom policies to target specific configuration settings on a device through the Windows Configuration Service Providers (CSPs). The deployment is based on scheduled check-ins to verify if there is any updates to the configuration policies, this is normally done every 8 hours..
It’s like having a driver who constantly calls you to ask for directions. Every time the device needs to check if it’s following the rules, it contacts the management service (Intune) to get updates and instructions.
Key Differences
- Self-Checking vs. Constant Updates:
- Declared Configuration: Devices check themselves and fix any issues automatically.
- OMA-DM: Devices frequently contact the management service to get updates and instructions.
- Efficiency:
- Declared Configuration: More efficient because devices don’t need to constantly ask for existing policies.
- OMA-DM: Less efficient because devices keep asking for updates to all existing policies, which can slow things down.
- Real-Time Compliance:
- Declared Configuration: Devices stay compliant with the rules in real-time.
- OMA-DM: Compliance is checked during regular updates, which can cause delays.
- Enhanced Security:
- Declared Configuration: By maintaining a consistent and compliant state, Declared Configuration enhances the security posture of managed devices.
- OMA-DM: Configuration and compliance can be changed between check-ins, this could lead to a potential non compliant device until next check-in.
Real world example with OMA-DM
Lets say we deploy a VPN connection to the client, this is a screenshot from a successful sync on 14 March:

The user change the VPN server address:

After waiting 3 days, the VPN server address is still wrong, even if successful sync has been performed:

Linked Enrollment
Linked Enrollment is a process that allows a device to be enrolled in multiple management systems simultaneously. This is particularly useful for organizations that use different systems to manage various aspects of their devices. For example, a device might be enrolled in both Microsoft Intune for mobile device management (MDM) and another system for specific security policies.
Linked enrollment has been used for a while to enable EPM (Endpoint Privilege Management). Declared Configuration also uses the Linked Enrollment to enforce settings. In Declared Configuration they call the server: “Declared Configuration Server” this is, if I understand correct, the same service in EPM that is known as: “MMP-C (Microsoft Management Platform – Cloud)”. Declared Configuration use Linked Enrollment for handling policy enforcement independently of the traditional Intune sync process. Here’s how Linked Enrollment works with Declared Configuration:
- Enrollment Process: When a device is set up, it uses specific configuration service provider (CSP) policies to facilitate dual enrollment. This involves setting certain policies and executing commands to manage the enrollment state.
- Configuration Management: Once enrolled, the device uses the declared configuration to enforce policies. This means that the device will continuously check and apply the required settings to ensure compliance.

Devices now have two MDM enrollments and sync running side by side. One is using OMA-DM for legacy policies, and the second using Declared Configuration for modern polices with better enforcement and compliance. This mean that OMA-DM still works as before and Declared Configuration is managed separately.
What does linked enrollment look like
Requirements
Ensure your devices are running Windows 10 or later and are enrolled in Microsoft Intune. Right now the Windows Declared Configuration (WinDC) is supported for all versions of Windows 10/11 that is Entra Joined. But WinDC enrollment for Microsoft Entra registered devices is only supported for Windows 10/11 with the following updates:
- Windows 11, version 24H2 with KB5040529 (OS Build 26100.1301)
- Windows 11, version 23H2 with KB5040527 (OS Build 22631.3958)
- Windows 11, version 22H2 with KB5040527 (OS Build 22621.3958)
- Windows 10, version 22H2 with KB5040525 (OS Build 19045.4717)
Linked Enrollment is automatically enabled and enrolled if you are updated and compliant.

You can also explore the linked enrollment CSP if you need to play with, change or modify the linked enrollment settings. But the note on that page inform it´s unsupported:

It also creates the scheduled tasks for Declared Configuration. Observe the 2 nodes for the dual MDM enrollments:

What can we configure with Declared Configuration?
This is not entirely clear yet. But if we take a look in the registry, we can get a hint:

Conclusion
Declared Configuration will be a powerful new feature in Microsoft Intune that makes managing devices more reliable and secure. By allowing devices to check and fix themselves, it reduces the need for constant updates and improves overall performance. I´m really looking forward to the new way of managing devices that makes it more robust and trusty.