How to Access Desired State Configuration MOF Metadata

I’ve been doing quite a bit with PowerShell and Desired State Configuration (DSC) over the last few months, and I expect that many of you have been as well. As you’ve probably realized, there are still many areas where DSC could use a little help. For now, many of these gaps are being filled by the PowerShell community. One of the gaps that I think needs to be filled in is managing MOF files via their metadata.

When you use the PowerShell cmdlets to create a DSC configuration, you’ll end up with an industry standard MOF. Something that might look like this;

The text at the beginning, which is a comment, and the OMI-ConfigurationDocument at the end, comprise the document’s metadata. Why should this matter?

When you set up a pull server, the MOF for a given node is copied to the server and renamed with a GUID that matches the node’s ConfigurationID, which is set in the Local Configuration Manager. If you were to do a directory listing of a pull server, it is almost impossible to know who the files belong to.

I’m not very good at memorizing GUIDs. What would be helpful I think would be to pipe these MOF files to a PowerShell function that would tell me who they belong to along with some other information like versioning. Here’s the function I came up with.

It is possible that you can use the .NET Framework to work with these documents, but these solutions are likely more complicated than what I’d like to deal with. My code uses common PowerShell cmdlets and techniques that an IT pro should recognize. Assuming you haven’t changed the beginning or end of the files, then you should be able to use my function.

I can get the metadata by using Select-Object to get the first few lines, skipping the first one.

For each line, I can split the item on the = sign. I need to get rid of the @ and ‘ characters so I’ll replace each with a blank

Because I’m going to be writing an object to the pipeline, I thought it would be nice if the date value was treated as a datetime object.

Each of these properties is added to an ordered hashtable. I do some similar string parsing with the OMI document section.

Notice that I’m using Select-String’s Context parameter. This allows you to capture the specified number of lines before and after the matching string. In my case, I want six lines. Actually, all I really want are the lines after the matching string, and specifically the version information.

I didn’t want to search the entire document because there could be other instances of “Version”, and I wanted the one that was part of the OMI document section. The PostContext property will be the six lines of text following the matching string. This helps me narrow down the selection. The last bit I thought would be helpful is to include some basic file information which I can retrieve with Get-Item.

After that all that remains is to turn the hashtable into a custom object. Armed with this function in my console, the directory listing is now much more meaningful.

As you can only have one MOF per node, this could be a handy way of identifying duplicate or obsolete MOF files. Because the function works like any other PowerShell command, you can do whatever you want with the output.

I hope this helps you get a handle on your MOF files. If you are still learning and getting started with DSC, I have a few courses on Pluralsight on the topic that should be helpful. In the meantime, are you using DSC? What sort of gaps are you running into it? I hope you’ll let me know via the comments.

Related Topics:

  • PowerShell

    Don't have a login but want to join the conversation? Sign up for a Petri Account