Last Updated on November 21, 2023 by rudyooms
This blog will be the fourth blog post in the WinDC series and will zoom in a bit more into the RAW and COOKED state of the declared documents AKA EPM Policies and how the “Chef” handles these ingredients.
I strongly believe this “new type of management (DDM)” and the needed infra (MMP-C) are going to revolutionize device management!!! It will change everything we know…
I will divide this blog into multiple parts
1. Introduction
When looking back at the first 3 posts, we have learned that EPM doesn’t use the same methods as we are familiar with when deploying policies from Intune.
When the device syncs, it will get its policies from the Device Management service (MMP-C Infra). EPM relies on the WinDC service to determine and apply the policies (Declared Configuration Documents)
To “refresh” AKA keeping those policies in line and a desired state, a dedicated scheduled task is created when the device gets a linked enrollment with MMP-C. This “refresh schedule” is being called upon every 15 minutes by the PolicyConsistencyJob job that lives in the EPM world and it has the power to refresh the policies even when the device is offline.
When you want to change the 15-minute refresh schedule, you could change/add some hidden registry keys to speed up that process (don’t do it in production!!!)
But how are those declared documents being refreshed? Luckily, when first encountering the Declared Documents and the Windows Declared Configuration service in this blog below, I stumbled upon the RAW and COOKED parts.
So my first advice would be to read this blog first, as it will explain some basic principles about how the policies are downloaded and applied
MMP-C | Declared Configuration | dcsvc.dll | Service (call4cloud.nl)
As mentioned in that blog post, I was already intrigued by that refresh scheduled task, so let’s take a closer look now at how these policies are refreshed (even offline)
2. The Orchestrator
So this part is more a rehearsal of the blog I mentioned in the introduction but while writing it I started noticing some more details.
The moment EPM is being deployed on the device, I noticed that the “Manager AKA The Chef” will be notified to start doing its job and by doing so the corresponding DmOrchestrator registry keys will be created
Each subfolder of the DMOrchestrator correlates to an EPM policy
(for now… I assume the Declared Configuration Service is going to be used for more policies in the future)
This “manager” is being referred to as the DMOrchestrator (Device Management Orchestrator). I guess the name Orchestrator spoils its function a bit. The orchestrator is a central component that plays a crucial role in coordinating, monitoring, and applying the declared configurations on the device. It’s the heart and soul!
When taking a closer look we will notice that when a policy arrives on the device, this manager will find out the current state of the policy and will “update” the corresponding settings to a “cooked” state by determining if the current state is the desired state of the policy
With the orchestrator in play, the device can detect when the state changes and can take action WITHOUT contacting the device management service. Almost as if the “DmOrchrestrator” is the same as the Local Configuration Manager LCM (DSC PowerShell)… owww wait it is….
3. Declarative Device Management
When spending more time on the Orchestrator and the WinDC documents, it became way more clear what the orchestrator was doing and what I was gazing at.
With the orchestrator doing its day-to-day job and just by looking back at the dmwappushservice DCSVC its true name, we can be pretty sure that Microsoft is moving to Declarative Device Management(DDM). In one of my previous blogs, I mentioned that MMP-C will revolutionize device management, and with this MS article below, mentioning that Microsoft moving to DDM….. damn!!!
Microsoft is bringing DDM to Endpoint Manager because this will improve performance on policy delivery, device compliance, app inventory, and much more… This is the way!!!
Even when this blog refers to IOS…. believe me … it’s not only going to be for IOS!!!!!! Do you remember an older blog of mine in which I noticed, some references of declared configurations showing up in older DLLs?
So let’s compare the good old MDM with DDM
| Aspect | MDM | Declarative Device Management (DDM) |
|---|---|---|
| Command Execution | Requires multiple server-device interactions for command implementation. | Devices monitor themselves and can notify MDM when changes are applied. |
| Device Autonomy | The device does not proactively contact MDM for changes; relies on MDM commands. | Devices have the autonomy to initiate updates and notifications to MDM. |
| Change Deployment Speed | Slower deployment due to server-device interactions for each change. | Faster change deployment with less interaction, resulting in quicker updates. |
| Offline Protection | Limited protection when the device is offline or when the MDM server is unavailable. | Could bring back the device to a desired state even when being offline. Autonomously detects and responds to changes. |
| Policy Application | This may lead to delays in policy implementation. | Enables swift policy application, improving fleet management efficiency. |
| Information Accuracy | Admins may receive less real-time information about device status. | Admins benefit from more accurate, timely device status information. |
With Declarative Device Management /Declared Configuration (dcsvc) the device itself can now (re)apply (….did you read the sentence… even offline) policies to keep the device in a “desired state” without the need to reach out to the management service. Faster, More Secure, more Autonomous!!! I love it!
4. But wait!!
In part 3 of this blog series, I already explained that I noticed some parts of the declared configurations being mentioned in an older version of the enterprisecsps.dll.
WinDC | MMP-C | SecuredCore | ConfigLock | WCOS | EPM (call4cloud.nl)
But somehow I was missing something, Let me take you with me on this small journey. The dcsvc.dll belongs to a service that was introduced last year and got installed with a nice Windows Update.
So that got me wondering a bit, as that DLL itself wasn’t on the device even when the enterprisecsps.dll was mentioning the declared configuration CSP node.
So there should be something else that was doing the declarative management AKA a service. You probably know that I am staring a lot at DLLs. In one of my older internal screenshots, I placed a red mark on something weird I noticed.
Why does the dcsvc initialization function mention “DmWap” ? So I decided to run Textcrawler and just start looking for a specific keyword: “DeclaredConfiguration” and setting the location to the 2004 source files (extracted the WIM file)
One of the files that was mentioned often was the DMPushRouterCore.dll file, which correlates to the DMWapPushService. That couldn’t be a coincidence, right?
To be sure I opened the Windows 2004 DMPushRouterCore.dll and the latest one in IDA. After opening them both I immediately noticed some difference. The latest dll file holds no references to DeclaredConfigurations but wait…. the 2004 version mentions almost everything! The Orchestrator, The declarative Management (the Raw, the Cooked) everything!
I decided to install the 21h2 22000.856 build of Windows 11. guess what showed up during the enrollment?
So again… Microsoft working on declarative management isn’t something new !!! It was already in production in Windows 2004 when we enabled Config Lock for Windows Secured Core devices but the Declarative Device Management code was just hidden in plain sight in an already existing DLL?
5. ChatGPT
I was trying to come up with a good understandable story and flow and explaining how EPM and declarative device management worked together… At that point, I just described the whole story to ChatGPT and asked to come up with a funny story. So this is the story behind the flow….
Declared Documents (Raw Data): These are like the raw ingredients in a recipe. Declared documents represent the initial, raw configurations or settings specified by administrators in the device management service. They serve as the starting point for configuring devices.
Declarative Configurations (Cooked Data): Think of declarative configurations as the “cooked” or processed version of the raw data. The orchestrator translates the declared documents into specific device configurations. It takes the raw ingredients (declared documents) and turns them into actionable instructions for devices to follow.
Orchestrator (The Chef): The orchestrator acts as the “chef” in this analogy. It processes the raw ingredients (declared documents) and follows a recipe (policy) to create specific configurations for devices. The policy defines what the desired state should be.
Policy (The Recipe): The policy serves as the “recipe” in this context. The policy determines what the desired state should look like.
Desired State (The Ideal Dish): The desired state represents the ideal configuration or condition that you want your devices or system to be in. It’s the “perfect dish” you aim to achieve based on the recipe (policy) and the configurations sent by the orchestrator.
Current State (The Current Dish): The current state is like the “dish” you currently have on your plate. It reflects the real-time status or configuration of your devices or system. The orchestrator continually monitors and adjusts the current state to align with the desired state defined by the policy.
In summary, declared documents provide the raw data or initial instructions, and the orchestrator acts as the chef that processes and transforms this raw data into usable configurations (declarative configurations), based on the recipe (policies) to reach the desired state while constantly comparing it to the current state.
6. The Flow
Conclusion
With part 4, we only have 2 parts left, In the fifth part I am going to focus on why sometimes the refresh schedule could be missing on the device and how to fix it! This part is funny as with the latest Windows Insider preview build, something else will happen to that task.
For now, I hope this part of the blog series describes what the “Chef” is capable of and why this component is very important!
