Weekend Scripter: Intro to PowerShell 4.0 Desired State Configuration

Doctor Scripto

Dr Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, provides an introduction to Windows PowerShell 4.0 Desired State Configuration (DSC).

Microsoft Scripting Guy, Ed Wilson, is here. Today the Scripting Wife and I are in Prague, and we have been hanging out with Windows PowerShell MVP, David Moravec, and his lovely wife Andrea. Here they are waiting for me to get in the elevator:

Photo of friends

One of the things David and I have been talking about is how cool Windows PowerShell Desired State Configuration (DSC) is.

Note  Portions of today’s post are excerpted from my book, Windows PowerShell Best Practices, which is published by Microsoft Press.

Image of book

The killer feature of Windows PowerShell 4.0 is DSC. Every presentation at TechEd 2013 in North America and in Europe that discussed DSC received high marks and numerous comments from audience participants. Clearly, this feature resonates soundly with IT pros. Therefore, what is DSC, how is it used, what are the requirements for implementing it, and how does it help the enterprise administrator?

DSC is a set of extensions to Windows PowerShell that permit the management of systems for the software and the environment on which software services run. Because DSC is part of the Windows Management Framework (which includes Windows PowerShell 4.0), it means that it is operating system independent, and it runs on any computer that is able to run Windows PowerShell4.0. DSC ships with the following resource providers:

  • Registry
  • Script
  • Archive
  • File
  • WindowsFeature
  • Package
  • Environment
  • Group
  • User
  • Log
  • Service
  • WindowsProcess

The twelve default resource providers each support a standard set of configuration properties. The providers and supported properties are listed in the following table.

DSC Resource Providers and Properties




Destination, Path, Checksum, DependsOn, Ensure, Force, Validate


Name, DependsOn, Ensure, Path, Value


DestinationPath, Attributes, Checksum, Contents, Credential, DependsOn, Ensure, Force, MatchSource, Recurse, SourcePath, Type


GroupName, Credential, DependsOn, Description, Ensure, Members, MembersToExclude, MembersToInclude


Message, DependsOn


Name, Path, ProductId, Arguments, Credential, DependsOn, Ensure, LogPath, ReturnCode


Key, ValueName, DependsOn, Ensure, Force, Hex, ValueData, ValueType


GetScript, SetScript, TestScript, Credential, DependsOn


Name, BuiltInAccount, Credential, DependsOn, StartupType, State


UserName, DependsOn, Description, Disabled, Ensure, FullName, Password, PasswordChangeNotAllowed, PasswordChangeRequired, PasswordNeverExpires


Name, Credential, DependsOn, Ensure, IncludeAllSubFeature, LogPath, Source


Arguments, Path, Credential, DependsOn, Ensure, StandardErrorPath, StandardInputPath, StandardOutputPath, WorkingDirectory

 Because it is possible to extend support for additional resources by creating other providers, you are not limited to only configuring the 12 previous types of resources.

The DSC process

To create a configuration by using DSC, you first need a Managed Object Format (MOF) file. MOF is the syntax that is used by Windows Management Instrumentation (WMI), and therefore it is a standard text type of format. A sample MOF file for a server named Server1 is shown in the following image.

Image of MOF file

You can easily create your own MOF by creating a DSC configuration script and calling one of the 12 built-in DSC providers or by using a custom provider. To create a configuration script, begin by using the Configuration keyword, and provide a name for the configuration. Next open a script block, followed by a node and a resource provider. The node identifies the target of the configuration.

In the ScriptFolderConfig.ps1 script, the configuration creates a directory on a target server named Server1. It uses the File resource provider. The source files are copied from a share folder on the network. DestinationPath defines the folder to be created on Server1. Type identifies that a directory will be created. Recurse specifies that all folders beginning at and following SourcePath are copied. The complete ScriptFolderConfig.ps1 script is shown here.


#Requires -version 4.0

Configuration ScriptFolder
    node 'Server1'
      File ScriptFiles
        SourcePath = "\\dc1\Share\"
        DestinationPath = "C:\scripts"
        Ensure = "Present"
        Type = "Directory"
        Recurse = $true


After the ScriptFolderConfig.ps1 script runs inside the Windows PowerShell ISE, the ScriptFolder configuration loads into memory. The configuration is then called in the same way that a function would be called. When the configuration is called, it creates a MOF file for each node that is identified in the configuration. The path to the configuration is used when calling the Start-DscConfiguration cmdlet. Therefore, there are three distinct phases to this process:

  1. Run the script that contains the configuration to load the configuration into memory.
  2. Call the configuration, and supply any required parameters to create the MOF file for each identified node.
  3. Call the Start-DscConfiguration cmdlet and supply the path that contains the MOF files that you created in Step 2.

This process is shown in the following image. The configuration appears in the upper script pane, and the command pane shows running the script, calling the configuration, and starting the configuration via the MOF files.

Image of command output

DSC Week will continue tomorrow when I will talk about more cool Windows PowerShell DSC stuff. 

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy


Comments are closed. Login to edit/delete your existing comments