How Do I Create a Desired State Configuration?

Over the last number of posts, we have taken a look at all the key concepts which we combine to implement our Desired State Configuration (DSC). We began with two different methods of implementing a pull server to host our DSC configurations: using a simple PowerShell Script and with a new Resource Provider for DSC published by Microsoft to implement the pull Server.

With our server online, we then changed the focus over to our nodes, where we reviewed the procedures needed to create the configurations necessary to set our nodes as pull clients to the server. We also spent a little time to consider what we may need to do, if the node had a requirement to be placed into “Maintenance Mode.” But all of this work is of no value if we do not understand what we can actually manage as part of a Desired Configuration, therefore we reviewed all the “Resource Providers” that Microsoft included in the solution, ready for us to consume.

Now we need to take this next step and combine these resources to define our Desired Configuration. We also need to publish this to the pull server, so that our configured nodes can retrieve their respective configurations and apply as defined in the configuration.

Sample Configuration

Building from our initial configuration sample, we can now start to consider how to leverage PowerShell to assist in creating a more dynamic DSC configuration for our servers. Previously we illustrated some samples that combined the resource providers into a simple configuration, however, we can make this more powerful if we modify our approach just a little.

Servers and Roles

Starting with a simple hash table, we can create an list of servers to which we will apply DSC settings. Using this table, we can then define the settings that might need to be applied to ensure their configurations are appropriate for the role that they are playing in our environment.

To illustrate this approach, let’s consider this simple table as an example.

From this, we can quickly determine, that we have four servers, that three of these are virtual, and that the roles will be deployed on the respective servers. We could get all fancy and host this data in a configuration database, but this is going to be a great starting point.

Configuration Scripts

Now, that we have a table to work from, we can get to the real fun part, and start building our configuration using a combination of PowerShell and leveraging the resource providers we introduced earlier.

To make this easier, I will share a starting configuration, and we can review some of its elements. Rather than calling out each area, I will embed comments in the configuration, so be sure to read through carefully!

Now, we just need to register these configurations in our PowerShell environment, then we will use the master configuration, which I called PetriDCS, and pass in the hash table of our servers, which should be enough to have a set of configurations created, one per server.

Create a Desired State Configuration

The MOF files are ready. You can open them in Notepad. If everything worked to plan, each one should resemble the options you chose in your hash table.

Related Topics:

  • System Center

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