Working with the Desired State Configuration Feature (Part 3)

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article in this series, I introduced you to several concepts that you need to understand in order to use the Desired State Configuration Feature. In this article, I want to continue the discussion by showing you how to build a configuration file.

As previously explained, the Desired State Configuration feature makes use of .MOF files. However, we can’t build a .MOF file from scratch. Instead, we have to create a PowerShell script and use that script to generate a .MOF file.

I spent quite a bit of time in the previous article discussing PowerShell functions, and I also mentioned that Microsoft has introduced a PowerShell function called Configuration. The Configuration function will be the basis of our script. The first thing that we will need to do is to assign the configuration a name. The name should be something descriptive that hints at the script’s purpose. For the purposes of this article, I am going to use PoseyConfig as my configuration name.

The next thing that you will need to create is a node block. A node block is really simple. It specifies the name of the node (or nodes) for which the configuration will be applied.

To show you how the configuration name and node blocks work, let’s pretend that we want to use the Desired State Configuration feature to make sure that the Hyper-V role is installed on a server named Lab4. The basic structure of the configuration file would look like this:

Configuration PoseyConfig

{

Node “Lab4”

{

#This is where the script’s actual code would go.

}

The first thing that you have to understand about the block of code shown above is that the indentions are not important. I used indentions as a way of better illustrating the various components that make up the script, but you don’t actually have to use indentions.

So as you look at the code above, you will see that the first line starts by calling the Configuration function. We are also applying my chosen configuration name. Like any other function, the entire configuration is enclosed in braces {}.

The third line of my script is Node “Lab4”. This is a node block that tells PowerShell that the configuration should be applied to a computer named Lab4.

The code beneath the node block is enclosed within its own set of braces {}. In this particular case, the node block only contains a comment. You will notice that the comment line begins with a pound sign #. In PowerShell, lines of code beginning with a pound sign are treated as comments and do not execute.

In essence, we have created a configuration script that contains a node block that doesn’t do anything. As I explained in the previous article, the actual configuration tasks are handled by providers. PowerShell includes twelve native providers and it is also possible to build custom providers.

Earlier I said that for the sake of demonstration, I would build a configuration script that would make sure that the Hyper-V role was installed on a server named Lab4. We used a node block to reference the Lab4 server, but we are going to have to use a provider to check for the existence of the Hyper-V role. The provider that we will be using is the DSC Windows Feature Resources provider.

In order to use this provider, you need to know what name PowerShell uses for the role or feature that you want to reference. The easiest way to get this information is to open PowerShell and type Get-WindowsFeature. Doing so will cause Windows to display a list of all the roles and features, as shown in Figure A. As you can see in the Figure, the Hyper-V role is simply called Hyper-V. PowerShell confirms that this role is currently installed, but our configuration file will help us to make sure that the role stays installed.

Figure A: You can use the Get-WindowsFeature cmdlet to retrieve a list of all of the Windows Server roles and features.

If your goal is to use the configuration file to make sure that a particular role (or feature) is installed, then there are two lines of code that you will need to be familiar with. The first of these lines is the Ensure line.

The Ensure line tells PowerShell what you want to do with the specified role or feature. You can either “ensure” that the role or feature is installed, or you can make sure that it is not installed. If you want to make sure that the specified role or feature is installed then you would set Ensure to “Present”. If you want to make sure that the specified role or feature is not installed then you would set Ensure to “Absent”.

The other line of code that you will need to write is the Name line. The Name line simply provides the name of the role or feature that you are checking. So with that said, let’s revisit the script that I created earlier and add the code to make sure that the Hyper-V role is installed. Here is what the script would look like:

Configuration PoseyConfig

{

Node “Lab4”

{

WindowsFeature HyperVExample

{

Ensure = “Present”

Name = “Hyper-V”

}

Much of the script shown above is identical to what I previously showed you, but let’s go through the new section line by line. Once again, our node block is encapsulated in braces {} and all of the new code exists within the node block braces.

So with that said, the first new block of code is WindowsFeature HyperVExample. There are a couple of things going on in this line of code. First, we are referencing the DSC Windows Feature provider, because that is the provider that is able to check for the existence of roles and features. As you will recall however, I mentioned that it is possible to create custom providers. When you create a custom provider, what you are really creating is a function. It should therefore come as no surprise that the natively included providers are also functions. Hence, WindowsFeature is a provider name, but it is really a function name.

So why is that important? Well, after I specified WindowsFeature, I entered HyperVExample. HyperVExample is a name that I made up. I am assigning the name to this particular block of code, just as I assigned the name PoseyConfig to the configuration file as a whole.

As you look through the script, you will notice that I am not using HyperVExample anywhere else. In this case, I have assigned HyperVExample as a name, but I am not actually doing anything with it. The reason why I chose to include this name is because most real world configuration files are far more complex than what I have shown above. Those files may use multiple providers to perform multiple tasks. Assigning a name to a task gives you the opportunity to reference the task from elsewhere in the script. For instance, you can check to make sure that a named task has completed successfully before you launch another task.

Like any other function, the WindowsFeature function uses braces to encapsulate its code. There are only two commands within the actual function. We are ensuring that the specified role is present and then we are providing the name of the role.

Conclusion

In this article, I have walked you through the creation of a sample configuration script. In the next article in this series, I will show you how to use this script to create a MOF file. After I show you how to use the desired state configuration, my plan is to revisit the script and show you some additional scripting techniques.

If you would like to read the other parts in this article series please go to: