The Wonderful Story of the MI Provider

Last Updated on October 2, 2023 by rudyooms

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!

I will divide this blog into multiple parts

  1. Introduction
  2. The Flow
  3. Microsoft Docs
  4. MOF file and MI Provider

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

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

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 Flow

3. Microsoft Docs

When first writing this part of the blog, I was telling a nice fun story 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

So Microsoft removed that keyword… Shall I put it back into Microsoft their documentation?

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 what MI Providers are by again just 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.

Afbeelding met tekst, schermopname, nummer, Lettertype

Automatisch gegenereerde beschrijving

If we open one of those nice MOF files, we will spot some nice lines of text.

Afbeelding met tekst, Lettertype, schermopname

Automatisch gegenereerde beschrijving

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.

Afbeelding met tekst, schermopname, diagram, lijn

Automatisch gegenereerde beschrijving

When adding the MI providers to the equation, this is what we will get.

MI providers act as the enforcers, interacting with the system’s components and the WMI repository to achieve and maintain the desired state. Let me explain by again using Get/Test/Set which I mentioned earlier.

“Get,” “Test,” and “Set” operations are used to retrieve the current state of a system (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 key role in implementing these operations for DSC resources (EPM Elevation Rules)

Leave a Reply

Your email address will not be published. Required fields are marked *

30  +    =  34