Working with the Desired State Configuration Feature (Part 2)

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

Introduction

In my first article in this series, I explained that the Desired State Configuration feature is a tool that you can use to verify that a server adheres to the required configuration, and to take corrective action if configuration drift is discovered. In this article, I want to continue the discussion by showing you some techniques for using the Desired State Configuration Feature.

Now that you understand some of the things that can be done by using the Desired State Configuration Tool, I want to talk about how the tool works. As previously alluded to, the Desired State Configuration Tool is based on PowerShell. In fact, when you build a configuration, that configuration works in almost an identical manner to a PowerShell function. But I’m getting a little bit ahead of myself.

Stages of Operation

The first thing that you need to understand about the way that the Desired State Configuration tool works is that there are three different stages of operation. The first of these stages is known as the Authoring Phase. This is the part of the process where you specify the desired configuration through PowerShell. The syntax for authoring a configuration is fairly easy, and I will show you some examples of the configuration process later on as we go along. For right now, the most important thing that you need to know is that the configuration that you define is used to build a Managed Object Format (MOF) file.

The second step in the process is something that Microsoft commonly refers to as the staging phase. The staging phase is the part of the process in which your MOF file (and any custom providers that you might have) is made ready for use. The staging phase can work in a few different ways, but most commonly adheres to a pull model. I’m not going to get into the anatomy of the staging process too much right now because I think that it will probably make a lot more sense if you can see the process in action. As such, I will revisit the topic later on.

The last stage in the process doesn’t seem to have a formal name. A lot of the Microsoft documentation refers to this step as the “make it so” stage. This is the step in which the desired configuration is applied.

An Introduction to Providers

In the previous section, I briefly mentioned the concept of custom providers, but I didn’t really talk about what custom providers are. Custom providers are a mechanism by which you can extend the Desired State Configuration tool’s functionality. The creation of custom providers are beyond the scope of this article series, but you do need to understand the concept of providers.

A provider’s job is to manage a specific aspect of the configuration process on the target system. For example, in the first article in this series, I mentioned that it was possible to use the Desired State Configuration Tool to ensure that a server role is installed on the target system. The process of adding or removing roles and features is handled by a provider.

There are twelve providers that are built into the Desired State configuration tool. These twelve providers should be adequate for most purposes, but you can build custom providers should the need arise. Incidentally, some of the Microsoft documentation refers to providers as Resources rather than calling them providers.

Here is a list of the providers that are included with the Desired State Configuration Tool:

  • DSC Archive Resource – Allows for the decompression of ZIP files on the target system
  • DSC Environment Resource – This provider allows you to configure environment variables on the target system.
  • DSC File Resource – Allows you to manage files and folders on the target system.
  • DSC Group Resource – Allows you to manage local group membership on the target system
  • DSC Log Resource – Can be used to log configuration messages
  • DSC Package Resource – This provider allows for application installation on the target system. It supports the use of Windows Installer packages and Setup.exe packages.
  • DSC WindowsProcess Resource – Allows for the configuration of Windows processes on the target system.
  • DSC Registry Resource – This provider allows you to configure registry keys and their corresponding values on target systems.
  • DSC Windows Feature Resources – This is the provider that is used to install roles and / or features on a target system.
  • DSC Service Resource – Allows for the management of system services on the target system.
  • DSC User Resource – Allows for the configuration of local user accounts on the target system.

As you can see, the built in providers allow for a somewhat granular level of control over a target system. You can control everything from user accounts and group membership to registry values and feature installations.

You may recall that in the first article I mentioned that the Desired State Configuration tool isn’t a full blown deployment tool, but rather a tool for checking (and if necessary, correcting) a system’s configuration. That functionality becomes a lot more apparent as you look at the list of built in providers. For example, a true deployment tool would likely contain resources for joining a system to the Active Directory. But such functionality is conspicuously missing from the Desired State Configuration Tool.

PowerShell Functions

One last subject that I need to talk about before I show you how to actually use the Desired State Configuration Tool is PowerShell functions. The reason for this is that the entire declaration process through which you define your system’s desired state is based on a PowerShell key word called Configuration. In actuality however, the Configuration keyword is really a function.

So what is a PowerShell function? To put it simply, a function is really nothing more than a name that is assigned to a block of PowerShell code. This allows you to execute the code simply by using the function’s name. You can use functions to build libraries of reusable code.

When you create a function, you must provide a function name, an optional set of parameters, and a script block. The script block is the code that will be associated with the function name.

Earlier I said that the Desired State Configuration tool uses a keyword called Configuration, and that Configuration is actually a function. More correctly, Configuration is the function name. We don’t have to define Configuration as a function name because it has already been defined, but we can provide parameters and a script block.

To give you a more concrete example of how a function works in PowerShell, let’s create a really simple function. In PowerShell it is possible to display the current date and time by entering the Get-Date cmdlet. Let’s pretend however, that we wanted to make it easier to get the current date and time by creating a function called Time. The code might look something like this:

Function Time {Get-Time}

The line of code shown above is actually a function. We are declaring a function name by entering Function Time. The Function keyword tells PowerShell that we are creating a function, and Time is the name of the function. In this case, {Get-Time} is our script block. This particular function does not contain any parameters. If we wanted to execute this function, we could simply enter the word Time and the function would run the script block, which in turn would display the current date and time.

Conclusion

In this article, I have spent quite a bit of time talking about the inner workings of the Desired State Configuration feature. In the next article in this series, I will put this information to work and show you how to create a configuration.

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

About The Author

2 thoughts on “Working with the Desired State Configuration Feature (Part 2)”

  1. Function should be Get-date, get-time doesn’t work in Powershell.

    Below is the error:

    PS C:\Users\Admin> function time {get-time}
    PS C:\Users\Admin> time
    get-time : The term ‘get-time’ is not recognized as the name of a cmdlet, function, script file, or operable program.
    Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:16
    + function time {get-time}
    + ~~~~~~~~
    + CategoryInfo : ObjectNotFound: (get-time:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top