This blog will be part 6 of the WinDc Refresh Schedule series. This time I am showing you some more pieces of information related to how the policies are been set back to its desired state when the “Refresh Schedule created by declared configuration to refresh any setting changed on the device” kicks in. The MI Provider, DSC, and the MOF file are definitely the keywords!
1. Introduction
While spending some time looking at the DMOrchestrator (AKA the Chef) and looking at some of the message analyzer traces I got, I stumbled upon some fun things
![](https://call4cloud.nl/wp-content/uploads/2023/10/word-image-15433-1.png)
As shown above, it mentioned: Begin and Ending DSC (Desired State Configuration): Native MI Provider
So, I decided to open the IDA tool, opened the dcsvc.dll, and started searching for these kinds of operations in a function that mentions how a single Declared Document is being processed
,
This function from the dcsvc.dll also shows the raw and cooked parts I mentioned in part four of the Windc Series (so I knew it must be somewhere in this function)
While looping through this function using the pseudocode, I stumbled upon a different function “DeclaredConfigurationStore_ConfigureBasedOnDocumentsAndcontext” … that couldn’t be a coincidence, right? Because the message analyzer just told me just before beginning the native MI Provider, it was entering that same function
![](https://call4cloud.nl/wp-content/uploads/2023/10/word-image-15433-3.png)
Microsoft is making it too easy for me to look under the hood at what’s going on. So let us start with the flow that will show you how I stumbled upon the MOF files and the corresponding MI Provider (Windows Management Infrastructure)
2. The MI Provider Flow
![](https://call4cloud.nl/wp-content/uploads/2023/10/word-image-15433-4.png)
3. Microsoft Docs
When I first wrote this part of the blog, I was telling a nice, fun story about how I was supposed to tell it, but somehow, when I came back from the WorkPlace Ninja summit, Microsoft decided to post their own documentation… almost a coincidence.
Declared configuration protocol – Windows Client Management | Microsoft Learn
But….when reading those docs, it also looks like they updated those docs a bit because somehow they removed some essential keywords…. like MMP-C
![](https://call4cloud.nl/wp-content/uploads/2023/10/image-1-1024x234.png)
So Microsoft removed that keyword… Shall I put it back into Microsoft their documentation?
![](https://call4cloud.nl/wp-content/uploads/2023/10/image-2.png)
Let’s continue and let me tell you the story about the MOF file and how the MI Provider are having a good time together.
4. MOF File and MI Provider
So, let me explain a bit more about MI Providers by again using the “chef cook” in a nice story.
After reading a bit more into the PowerShell desired state configuration, it was obvious that I needed to start looking at the MOF (Managed Object Format) files inside the EPM folder first.
![The EPMElevationRulesdapter mof files that belongs to the endpoint privilege management client](https://call4cloud.nl/wp-content/uploads/2023/10/afbeelding-met-tekst-schermopname-nummer-letter.png)
If we open one of those nice MOF files, we will spot some nice lines of text.
![The mof file showing the gettargetresource, testtargetresource and settargetresource desired state command](https://call4cloud.nl/wp-content/uploads/2023/10/afbeelding-met-tekst-lettertype-schermopname-au.png)
Get/Test/Set Target Resource… that sounds familiar… Desired State Configuration. A MOF file is a text file that defines a DSC configuration and its desired state
These MOF files act as blueprints for the configuration of devices and are stored in a “cookbook”.(sorry couldn’t help myself… as with the cooked and raw state, I needed to mention the cookbook)
So, in simple terms, MOF files are used to define what needs to be managed (Epm Elevation Rules), and these files are compiled into a format that becomes part of the WMI repository as WMI objects.
![register-cimprovider.exe and how we could generate a mof file](https://call4cloud.nl/wp-content/uploads/2023/10/afbeelding-met-tekst-schermopname-diagram-lijn.png)
When adding the MI providers to the equation, this is what we will get.
MI providers act as enforcers, interacting with the system’s components and the WMI repository to achieve and maintain the desired state. Let me explain again using the Get/Test/Set I mentioned earlier.
The “Get,” “Test,” and “Set” operations are used to retrieve a system’s current state (Get), compare it to the desired state (Test), and make necessary changes to bring the system into the desired state configuration (Set).
Conclusion
To summarize, MI providers are a critical part of the infrastructure that makes DSC work. They handle the interaction between DSC resources, DSC configurations (MOF files), and the target systems, helping to ensure that the systems are configured according to the desired state. The “Get,” “Test,” and “Set” operations are fundamental to this process, and MI providers play a crucial role in implementing these operations for DSC resources (EPM Elevation Rules)