In Desired State Configuration (DSC), we have the concept of resources and configurations. In a nutshell, resources are the building blocks that are placed inside configurations, with each node having a single group of resources all working together to place the node in the desired state.

Adam Bertram

Adam Bertram is a 20-year IT veteran, Microsoft MVP, blogger, and trainer. Adam is the founder of the e-learning tech screencast platform TechSnips. Catch up on Adam’s articles at adamtheautomator.com, or follow TechSnips on Twitter at @techsnips_io.

In Desired State Configuration (DSC), we have the concept of resources and configurations. In a nutshell, resources are the building blocks that are placed inside configurations, with each node having a single group of resources all working together to place the node in the desired state.

Along with resource references, each configuration also holds a less obvious type of information: configuration data. What is this data? At its simplest, configuration data is all of the variables or parameters, if you will, for a particular configuration. It includes all of the specific pieces that make a configuration unique.

For example, perhaps you want to ensure a folder exists on a machine called SERVER1. One way you can do this with DSC is by using the File resource and specifying the DestinationPath and the Type like so:

Once this resource reference is placed inside a configuration, it will ensure that the C:\MyNewFolder folder exists.

When I run the configuration, it will create a MOF file for my server.

The configuration will create a MOF file for my server

The configuration will create a MOF file for my server

This works fine if you have a single folder to create or don't do anything more complicated than applying configurations to a single node. We typically don't have this luxury in the real world, where we're wrangling hundreds or thousands of servers at a time. In addition, perhaps I need to create a folder on each of my nodes but the path might be different. To make this happen, I'd have to copy and paste this reference hundreds of times. Obviously, this approach doesn't scale well.

How can we build this in a way that is shareable across lots of nodes and prevents us from having to do a bunch of copying and pasting? The answer is to separate out the configuration data from your configuration.

In our file reference above, what do you think is configuration data? In other words, what do you think might change when applied to lots of nodes? I would first pick the folder path. I'm sure I'll want to create a folder on different nodes, and it's not always going to be C:\MyNewFolder. This is configuration data.

How do we separate this from the configuration itself? Microsoft provides us two ways: use a PSD1 file or a hash table. However, we're going to focus on the file in this article. A PSD1 file is consumed at the time the configuration is executed, and all of the values inside are applied to the configuration. But first, what does this PSD1 file look like?

At its most basic, the PSD1 is a single hash table with an AllNodes key that must be an array. That's it. However, you can also have an optional key called NonNodeData that can be anything you want.

Now, let's say that I want to create this folder on a node called SERVER1 but create a different folder on SERVER2. We will define the node name and the folder names not inside the configuration itself but rather in our PSD1 configuration data file.

The PSD1 file will look something like this, with an individual hash table defined inside the AllNodes key for each node and, most importantly, the unique value of the folder that we'd like to create. The only required key inside each node’s hash table is NodeName. Otherwise, you can add anything else specific to that node there as you'd like.

We can then save this file with a PSD1 extension, naming it anything we'd like. To keep it simple, so I'll call it C:\ConfigurationData.psd1.

I'll now come back to my configuration with my single file resource reference and change it up a bit to essentially tell the configuration that my configuration data is in a different place.

Notice that I've replaced the SERVER1 reference with $AllNodes.NodeName. When configuration data is read into the configuration, this represents the AllNodes key in the hash table in our PSD1 file. In our case, this will iterate over each node hash table, reading both SERVER1 and SERVER2's node references. Then, inside that loop, I can reference each node's hash table by using $Node. You can see I've replaced that static folder path with $Node.FolderPath as well. Now, it will dynamically reference the folder path specific to each node.

I'll now run the configuration, ensuring that I use the built-in ConfigurationData parameter.

Running the configuration.

Running the configuration.

You can see it has generated MOFs for both our nodes. If we look in each MOF file, you will see that it will instruct each node to create a different folder.

Each MOF instructs each node to create a different folder.

Each MOF instructs each node to create a different folder.

Each MOF instructs each node to create a different folder

Creating a different folder.

Creating a different folder.

At this point, you'd run the configuration on each server, and you're golden!

Discover and separate out configuration data as much as you can. If you do, you'll see that scaling DSC will be much easier.

Join the 4sysops PowerShell group!

0
Share

Related Posts

1 Comment
  1. Henry 1 year ago

    I have an issue similar to this I would like your opinion on. Someone needs to write this up.

    I have a Configuration Data file for a Target Node. To keep things simple, I use the Resource attributes as keys in my Configuration Data file. In this case, I have a requirement to configure multiple instances of the Resource for the same Target Node. In my Configuration Data file, I can only reference the Resource attribute once. Subsequent references are ignore or will throw an error.

    To solve the issue, I created a new key as a hash, and put the Resource key-value pairs in there for each instance of the Resource.

    In my Configuration Script file, I then reference the data with an extended dot-notation. Instead of $Node.SomeAttribute I use $Node.xResource1.SomeAttribute

    The alternative is to be very creative with the attribute key names in the Configuration Data file, which got cumbersome very quickly.

    What do you think?

    0

Leave a reply

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

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2019

Log in with your credentials

or    

Forgot your details?

Create Account