This blog post will be the third one in my journey to discover what the “refresh schedule created by Declared Configuration to refresh any settings changed on the device” actually does and how this task is triggered.
WinDC | Epm Policies | Refresh Schedule | MMP-C (call4cloud.nl)
In the second part, I focused on PolicyConsistencyEnsurerJob and how this ” job” is executed every 15 minutes, and how we could play around with it. In this part, I am focusing on something that caught my eye when first looking at MMP-C and WinDC (DCSVC)
I will divide this blog into multiple parts
- Introduction
- Declared Configuration
- The Orchestrator kicks in
- Checking the Information
- Config Lock
- The Flow
1. Introduction
In one of my first blogs about MMP-C, I noticed that when the device needed to fetch the latest EPM policies, it would check into the MMP-C service by using this URL
/Devicecheckinfe/WcosCheckin
At that point in time, I could not explain it. At first, I thought WCOS stood for Windows Core OS. Which was and could also be a bit true. Let me explain a bit more. MMP-C was already mentioned in the deviceenroller.exe, the mdmregistration.dll, and the enterprisecsps.dll code back in 2020 (Windows 10 20h1)
At that time Microsoft was working on Windows 10x (CoreOs), right? But Microsoft abandoned that project and moved the best parts of it to Windows 11. For example, the App Isolation (Containers)
So I was like, WCOS should stand for Windows Core OS but was that a good assumption at that point in time? Let me show you why I am starting to doubt that assumption and, at the same time, thinking it is still the best assumption for now.
2. DeclaredConfiguration
While digging through the WinDC (Declared Configuration), I noticed that even before EPM is installed, the service is up and running, and the registry already contains some settings.
As shown above, in the Scenearioschema, we will notice that it mentioned the SecuredCore and the SecuredCoreState with some corresponding security settings. Every time I looked at it, I couldn’t see the bigger picture, but while working myself through the refresh schedule, I stumbled upon something
3. The Orchestrator Kicks in
Before showing you what I stumbled upon, let me explain a bit about how I got there. When looking at the logs and the dcsvc.dll, I just started up top and worked my way down.
At first, we will notice the fact that an RPC server group will be created and registered
When looking at dcsvc.dll we will notice that it indeed holds the RPC server
When jumping into the rabbit hole, I noticed that it would start by initiating the DC service
(okay not interesting… I know… but still, I needed to mention it)
When starting the service, It would eventually kick off the OrchestratorRefresh or OrchestratorResume function, depending on what needs to be done (Going to tell you everything about the Orchestrator in the next blog)
And now comes the interesting part, which I have looked at many times but couldn’t connect the dots
As shown above, all of the Orchestrator operations are “calling” the “IsWindowsCore” function. When we take a closer look at this function, it tries to get the DeviceFamilyInfo
This external function would just check out some registry keys to determine the device information.
Looking at it, it still points me to the first idea. MMP-C was created to be used for Windows Core OS because 0x00000010 points to the WINDOWS_CORE device family
4. Checking the Information
So noticing the “IsWindowsCore” function in the dcsvc.dll, the Stuff that we noticed in the registry keys mentioning some security features, and the fact that MMP-C was already being mentioned in the code in 2020, is it wrong for me to assume I am looking at the Windows Core OS or maybe it is something called Windows Secured-Core functionality?
Windows 10 Secured-core PCs | Microsoft Learn
When I read a bit more of the secured core PC documentation, I found some really interesting stuff.
- The same security features are mentioned that we spot in the Declared Configuration Registry keys (can’t be a coincidence)
- The Windows 10 Secured-Core article is from 2020
So combining this information started me to believe that WinDC andMMP-C was already work in progress back in 2020 when Microsoft was working on Secured Core PCs
So I decided to read some more about SCPC. While reading more about SCPC, it got me to an article about the Config Lock
5. Config Lock
When I read the document below, everything I spotted in the code started to make even more sense.
Okay… sounds great but this part even sounds more great….. “Detects drift remediations within seconds”
Secured-core configuration lock – Windows Client Management | Microsoft Learn
Mmmm… that almost sounds like a desired state configuration… (DSC) So is it a coincidence that this is also being mentioned in the DCSVC.DLL ? (and used… more on that in the next parts of this blog post series. I will put the link in it when it’s published)
When reading how we could deploy or enable this setting, it shows us we can create a policy to do so
Okay, so we need to push a CSP to the device to set this policy… guess where that leads me.. The enterprisecsps.dll
As shown above, yeah the enterprisecsp.dll also mentions the declaredconfigurationstore and the same time the SecureCoreState.
Now that one got me curious … as MMP-C was also mentioned in the DLLs, is the DeclaredConfiguration also already being mentioned/used in a DLL? Of course, dcsvc.dll isn’t on the device until (2022 October) or just not visible for normal human eyes (yeah I think it’s hidden) so I just got myself an old version of enterprisecsps.dll
Guess what that showed me! Yeah, a lot of declared configuration stuff that I wasn’t expecting!
It seems that the declared and the corresponding orchestrator functions were moved over from enterprisecsps.dll to dcsvc.dll at the end of 2022.
So for now I need to move away from the idea that MMP-C was designed to be used for Windows Core OS/Windows 10x and assume that MMP-C was created for something else. My second guess is that MMP-C and WinDC were designed to be used for the Secured Core PC functionality.
6. The flow
And of course the flow, we can add to the bigger picture to get a good understanding of how the refresh schedule works and what it touches.
Conclusion
Even though this part of the blog series is not exactly 100% about the refresh schedule, it was something that I noticed and wanted to tell because, with my last blog, I showed you how important MMP-C is and can be in the future. With this blog, I am trying to show you that MMP-C isn’t something new and being worked on for many years. The exact reason why MMP-C was created in the first place is still not sure… but it can’t be anything simple… that’s for sure