PowerShell Desired State Configuration (DSC) – Introduction

It has been some time since I wanted to write about PowerShell Desired State Configuration, in short DSC, and I will try in this series of posts to demystify this new feature shipped with PowerShell 4.0 and Windows 2012 R2/Windows 8.1 and show you how to take advantage DSC to automate your whole datacenter management practices.

PowerShell Desired State Configuration – What is it?

This is a question I still hear people ask so I think it is worth starting exactly from here, defining what PowerShell Desired State Configuration is exactly and what it can do for you. Who knows me from some time knows that I come from a Unix/Linux background and despite loving Microsoft technologies I felt the lack of a strong automation framework, the lack of proper scripting language was filled with PowerShell, was evident and the biggest “lack of feature” in the Windows world, in Linux I used to be (and still am) a fan of a product called Puppetso when PowerShell DSC was announced I was really excited and thought “Yeah Finally!”.

Ok enough of a preamble, what is PowerShell Desired State Configuration and what can it do for you? Let’s try to summarize it here:

  • Install or remove server’s roles and features
  • Manage/create/delete files and registry settings on servers
  • Start/stop/manage services and processes on servers
  • Run PowerShell scripts
  • Add/remove/manage local environment variables
  • Check the actual configuration status of a machine (guess where the DSC name comes from?)
  • Change the configuration of a server that is not in line with the Desired State

Ok lat point is rather important so it’s worth repeating, PowerShell Desired State Configuration can fix for you a configuration that drifted away from the defined standard; there is actually more on what PowerShell DSC can do but the above list should give you a good idea already.

How does it work?

Now that you know what PowerShell DSC is and what it can do for you let’s examine how it works, PowerShell Desired State Configuration uses a pull/push model which is logically divided into three distinct phases Authoring, Staging, Implement/Deploy phase, the whole concept is depicted below (courtesy of Microsoft Technet website):
PowerShell DSC Phases
 In the Authoring phase the DSC is created through PowerShell or third-party tools, yes all of this is extensible!, and the output produced in this phase will be one or more MOF (Management Object File) files which are in turn read and consumed by DSC., while MOF files can be potentially created with any text editor PowerShell 4 adds support for syntax and schema checking on top of a declarative syntax which will make your life easier.
In the Staging phase MOF files are staged on a special IIS server which is called Pull Server the target system will contact the Pull Server to verify passing a URI containing a unique identifier to check its configuration and if all custom providers are available, if not they’re downloaded locally on the system. In the case Push model is used DSC data is pushed (forced) to the target system.
Finally in Implementation phase the data is either pulled or pushed to the Local Configuration Store , the configuration is parsed and the relevant WMI providers implement the change defined in the MOF file itself.
PowerShell DSC comes with 12 built-in providers allowing to perform a variety of actions you can read about these providers here but of course you can even write your own providers and extend DSC functionality.

PowerShell Desired State Configuration in Action

Now that how DSC works has been demystified let’s have a look at a couple of practical examples of what PowerShell DSC can do for us, I will keep it really simple as I will go in deeper details in subsequent posts, in the following example I will create a simple MOF file that will ensure a file named DSC.INI exists on the local machine:

#Declare the configuration name
configuration CopyFile
    # Apply to this node
    node localhost {
        file DSCFile
            # Ensure that the file exists under this path
            DestinationPath = "C:UsersLetheDSC.ini"
            # Ensure the file has this value
            Contents = "Value=This is a test of PowerShell DSC"

#This the output MOF file
CopyFile -OutputPath C:CopyFile

If you run a Get-Content C:CopyFileLocalhost.mof it will display a content similar to the following:

@GenerationDate=10/26/2014 21:47:13

instance of MSFT_FileDirectoryConfiguration as $MSFT_FileDirectoryConfiguration1ref
ResourceID = "[File]HeloCheckFile";
 Contents = "Value=This is a test of PowerShell DSC";
 SourceInfo = "::4::9::file";
 DestinationPath = "C:\Users\Lethe\DSC.ini";
 ModuleName = "PSDesiredStateConfiguration";
 ModuleVersion = "1.0";


instance of OMI_ConfigurationDocument
 GenerationDate="10/26/2014 21:47:13";

Once you have your MOF file in place it can be consumed by DSC with the following command:

Start-DscConfiguration -Path C:CopyFile -Wait -Verbose

The above command is running with the -verbose switch which will produce and output similar to the following:

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespace
Name' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer WKS-LETHE with user sid S-1-5-21-1917135671-2404458731-2718418079-1001.
VERBOSE: [WKS-LETHE]: LCM:  [ Start  Set      ]
VERBOSE: [WKS-LETHE]: LCM:  [ Start  Resource ]  [[File]HeloCheckFile]
VERBOSE: [WKS-LETHE]: LCM:  [ Start  Test     ]  [[File]HeloCheckFile]
VERBOSE: [WKS-LETHE]:                            [[File]HeloCheckFile] The destination object was found and no action is required.
VERBOSE: [WKS-LETHE]: LCM:  [ End    Test     ]  [[File]HeloCheckFile]  in 0.0100 seconds.
VERBOSE: [WKS-LETHE]: LCM:  [ Skip   Set      ]  [[File]HeloCheckFile]
VERBOSE: [WKS-LETHE]: LCM:  [ End    Resource ]  [[File]HeloCheckFile]
VERBOSE: [WKS-LETHE]: LCM:  [ End    Set      ]
VERBOSE: [WKS-LETHE]: LCM:  [ End    Set      ]    in  0.0450 seconds.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 0.104 seconds

Checking under the C drive the DSC.ini file is indeed there:

PowerShell_DSC_OutputThis, of course, was only a basic example of PowerShell DSC can do, in future posts I will go into more details about using DSC to deploy the same settings and files to multiple machines.

And you? Already used PowerShell Desired State Configuration to automate and standardize server’s configuration? Why don’t you leave a comment and share with us your experience and success story?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s