Hello everyone, and welcome back to our series on Desired State Configuration and Hyper-V!

Every once in awhile it seems like we run into a new technology that really changes the way that system administrators perform their jobs, and Desired State Configuration (DSC) is really beginning to lead in that direction.

As we saw in the previous entry in this series, we found that DSC’s primary function is to enforce configurations on a target node, but it also has a number of other useful features, such as making the configuration of new systems much easier, and preventing misconfiguration from occurring over time.

I’m sure I don’t have to spend much time attempting to convince you to start learning this technology as I’m hoping the intro post spoke for itself, so let’s dig right back into this series with DSC resources.

Today we’re going to be looking at what DSC can (and can’t) modify on the nodes that we are targeting with our MOF files.

MOF is an industry defined standard, therefore there are some limitations and guidelines as to what “CAN” be modified by a MOF file. These limitations are defined by the DSC resources that are available and what their associated functions are.

Let me explain further.

What are DSC Resources?

Think of a DSC resource as a product add-on. A resource extends and defines what DSC is able to do on a particular node.

By default PowerShell and DSC ship with a number of built in “official” DSC Resources in WMF 4.0, so you’ll have the below common set of resources out of the gate:

  • Archive (provides .zip functions)
  • Environment
  • File
  • Group (Local)
  • Log
  • Package (MSI and EXE)
  • Registry
  • Script
  • Service
  • User (Local)
  • WindowsFeature
  • WindowsProcess

You’ll be able to do a surprising amount with the built in resources, but what if you need something outside of the defaults?

As MOF is an industry standard, a large community has sprung up around the creation and use of custom resources. Even better, it’s entirely possible to create your own DSC resources if needed. We won’t be covering that possibility in this series, but I can certainly link to some resources in the event there are several folks who are interested in that functionality.

Where do I find said resources?

This information doesn’t do a lot of good if you don’t know where to grab these extra resource kits right?

Well, before I get too far into linking where to download the additional resource kits, there is some naming terminology that needs to be reviewed.

Overall, you’ll find that there are Official, Experimental, and Community based resource kits, and they’ve all been given their own naming scheme so it’s easy to identify them.

Official Resource Kits: These are the DSC resources that we’ve already spent some time discussing. These are the ones that ship with DSC and WMF 4.0 by default. These resources are tested extensively as to be free of bugs and glitches, therefore these resources receive no special naming conventions. Think of these resources as your bread and butter. Example: Service

Experimental Resource Kits: These resource kits are available for download directly from Microsoft, but they have not been tested enough to be deemed fully safe. “They are strictly use at your own risk”. All Experimental resources will start with the letter x in their name. Example: xAzure

Community Resource Kits: As stated, a large community has grown around DSC’s functions, and given the ability to create custom DSC resources, there are many available for download if one knows where to look. The primary benefit here being the fact that if you need a resource kit for a particular function, most likely someone has developed the corresponding resource kit already, so be sure to check our the community resources before you go to the trouble of creating your own. Community resource kits have the letter c preceding the name. Example: cRDPEnable

Microsoft experimental resources can be found HERE.

A great location for finding community created resources is the Powershell.org GitHub repo.

Installing DSC Resources

So, once we have additional resources, we need to install them before we can put their abilities to good use.

Installation of DSC resources is quite simple. Simply extract the resource to “C:\Program Files\WindowsPowershell\Modules”

Please note: Resources need to be installed on the machine that you are authoring your MOF file from, and on the node that will be applying the MOF!

In the below example I’ve extracted the xAzure resource kit and you can see that there are some subfolders and files present as well. There will be a .psd1 file and a DSCResources subfolder in most cases.


Once we’ve got the resource extracted, the next most common question I get is: “How do we verify that DSC sees the new resource kit?”.

Simple,..  we use some PowerShell magic with the Get-DscResource cmdlet.


As you can see in the image above, the xAzure resource kit is properly registering with PowerShell and the associated DSC functions. This is also a great way to see the entire list of resources that you have available on your MOF authoring system or a target node.

How do we use our Installed Resources?

We’ve been talking about all these resources, but you’re probably wonder how we use them in the creation of our MOF files.

The next post in this series will focus specifically on the creation of MOF files, but before we get to that, when you’re reviewing resources specifically, you can review the possible properties and functions of any individual resource by issuing the below PowerShell command.

Get-DscResource (ResourceName) | Select-Object -ExpandProperty Properties

For example, let’s look further at the xAzureSubscription resource


Looking at the potential properties kind of gives us an idea of what this particular DSC resource can do for us.

So, we can see that this particular resource would allow us to enforce connectivity to a particular Azure subscription, or insure that a certain subscription is NOT connected. This view also shows us what values are mandatory for the resource kit to function properly.

Most resources will have properties along these lines, which when combined with other resource kits, can enable DSC to be a very powerful tool in the sys-admin’s toolbox.

What’s next?

Thus far we’ve seen what Desired State Configuration is and what it’s use cases are. We’ve also delved into how DSC resources fit in and how they can extend DSC functionality to fit multiple needs.

In our next post on this topic, we’ll look at how we can take these resource kits and apply them into a configuration for the generation of the MOF files we have been talking about.

Hope you enjoyed today’s post, and keep an eye out for more talk on Desired State Configuration!