Call4Cloud | MMP-C | Autopilot | Device Preparation

The Wonderful Story of the MI Provider

Patch My Pc | install & update thousands of apps

This blog is part 6 of the WinDc (Windows Declared Configuration) Refresh Schedule series. This time, I am showing you some more information related to how the policies are set back to their 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 looking at the DMOrchestrator (AKA the Chef) and some of the message analyzer traces I received, 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 MI Provider Flow

MI Provider Flow (IWindows Management Infrastructure)

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

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

Let’s continue, and let me tell you the story about the MOF file and how the MI Providers 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 (managed object format) files that belongs to the endpoint privilege management client

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

GetTargetResource / TestTargetResource / SetTargetResource (get-test-set)… 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 define what needs to be managed (Epm Elevation Rules), and they 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

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)

Leave a Reply

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

6  +  4  =  

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.