PowerShell Desired State Configuration (DSC) Journey – Day 1

After reading about DSC for a while now, creating a bookmarks folder with DSC related resources, and thinking about how awesome DSC is I have decided to start my journey into understanding DSC and am going to document it.  In addition to the bookmarks I have downloaded and installed all of the currently available modules from the 2 waves of the resource kit that have been released.  Those modules (11 in all) can be found here.  From everything that I have read it seems the learning curve can be steep and the documentation isn’t the greatest, but I am determined to figure this out because I see the massive potential of this tool.  Also, as Don Jones points out here DSC is what Microsoft has been building towards all along and is the final piece of Jeffrey Snover’s Monad Manifesto.  And it’s only in Version 1!  Which means a lot more is coming, and unlike with PowerShell I intend to be on the leading edge of this technology.

I have no idea how long this series will go, but am hoping to get at least a month of posts out of it, one for every day I’m at work unless something happens to catch fire or burn down.

Quick tangent.  The way I learn goes like this:  I read, and then I start failing as much as possible.  Then I read some more.  Then I fail some more.  Somewhere in there I will make slow but steady progress.  Reading is great, failing is better.

For my first step I went to my bookmark for the Windows PowerShell Desired State Configuration Overview here out on TechNet.  It describes DSC as “DSC provides a set of Windows PowerShell language extensions, new Windows PowerShell cmdlets, and resources that you can use to declaratively specify how you want your software environment to be configured. It also provides a means to maintain and manage existing configurations.”  That sounds incredibly awesome.  Let’s keep going.

Reading the practical applications sections, some use cases immediately jump to mind.  I can create a configuration that will ensure the IIS Feature is configured identically across all SharePoint servers in a farm.  I can create a configuration that makes sure no individual developers have somehow gotten local administrator rights on production servers, and if they do, the server can pull a configuration and wipe that out.  I can get the actual configuration of all my WSUS servers (maybe not the WSUS component, but the OS stuff) and compare them to make sure they are identical.

I like how they just kind of throw this line in there at the end:  “In addition, you can create custom resources to configure the state of any application or system setting.”  Oh really?  Any application or system setting?  Challenge accepted! That is something that I will have to attempt to break, because that’s just something I enjoy doing.

So far so good, there hasn’t been anything to scare me away yet.  Let’s move on to the first link provided in the “Important Functionality” table for “Get Started with Windows PowerShell Desired State Configuration” here.

Hilarious sidebar, what’s wrong with this picture?

DSC

Alright, so DSC introduces a new keyword called Configuration.  I first define a PowerShell script block using the Configuration keyword, then follow it with an identifier, then with braces to delimit the block.  Easy enough.  Sounds just like how you would use a function or create a new cmdlets.  Time to get this party started!  I am going to get real crazy and name my Configuration TestConfig.

Configuration TestConfig {

}

First configuration created, watch out!  Inside the configuration block you can define node blocks that specify the desired configuration for each node (computer) in your environment.  A node block starts with the Node keyword.  Why couldn’t they have just used the Computer keyword?  Why change it to Node when it stands for Computer?  I suspect because at some point in the future a Node will not be limited to a computer.  Follow this keyword with the name of the target computer (which can be a variable), and then use braces to delimit the node block.  Another thought.  If the target computer can be a variable, does the variable have to be defined in the Configuration, or can it be defined outside the Configuration and then piped into it?  Something like $computers = (Import-CSV C:\Scripts\Computers.csv) | Configuration TestConfig (or however you call the configuration).  Something else to test out I suppose.  So here’s my updated Configuration.

Configuration TestConfig {

    Node $targetcomp {

    }

}

I decided to make my Node a variable, because I want to be able to test how I can use that variable when I call the Configuration.  I realize that for the sake of simplicity that I should just use a single computer name here, but what’s the fun in that?  The idea here is to fail after all, and to learn by doing so.

Next step, inside the Node block, I can define resource blocks to configure specific resources.  A resource follows the same naming standard as a Configuration or Node.  Name of the resource, followed by the identifier, with braces to delimit the block.  So, what resource should I use?  Looking at the links on the left side of this article, I elect for the Built-In Windows PowerShell DSC Resources here.  Browsing through the list, I am going to pick something that seems relatively simple and go with the File Resource, which “manages files and directories on target nodes”.  I click on the link for the File Resource and I get the Syntax, the properties of the Resource and an example.  After reading through this I decide that I want to ensure that the Scripts folder on my test server (which is a server I used to play around with PowerShell Web Access configuration and setup) always needs to contain a script.  I immediately realize this would be useful, because I have SCOM rules and monitors that run that require that certain scripts exist on the servers they are targeting or the rules and monitors will fail.  I just stumbled myself right into another use case!  So after some setup on my end to make sure things work for this test, here is my new Configuration.

Configuration TestConfig {

    Node $targetcomp {

        File ScriptPresence {

        Ensure = "Present"
        Type = "Directory"
        Recurse = $False
        SourcePath = "C:\Scripts\DSC"
        DestinationPath = "C:\Scripts"

        }

    }

}

My very first thought is, will this copy the folder where I want to?  That is, will it place the DSC folder in the C:\Scripts folder on the destination server, or does the DestinationPath need to match the SourcePath like in the example.  Only one way to find out!

Back on the Getting Started page I am reading ahead to how to actually run this Configuration, and I think this is a good stopping point for the day.  I am excited to see how this runs tomorrow!

 

2 thoughts on “PowerShell Desired State Configuration (DSC) Journey – Day 1

  1. Your DSC journey posts now reside in my “DSC” Bookmarks folder 😉

    Liked this quote in particular “Reading is great, failing is better.”
    Will be following along in some time and putting my failures at my own blog.

    Thanks for sharing these

Leave a Reply