Using PowerShell 4.0 DSC Parameters

Using PowerShell 4.0 DSC Parameters

  • Comments 4
  • Likes

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell 4.0 Desired State Configuration parameters.

Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I are still in Prague. I’ll tell you what, there is excellent tea here, and totally rad buildings to photograph. David and Andrea are proving to be excellent hosts. I am not sure we will ever come back. Here is a photo of the beautiful city of Prague:

Photo of Prague

As always, when David and I get together, the conversations float to Windows PowerShell—in fact, to DSC. This is the second in a series of articles about DSC. The first one was Intro to PowerShell 4.0 Desired State Configuration.

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

To create parameters for a configuration, use the param keyword in the same manner as you use it with functions. The param statement goes just after opening the script block for the configuration. You can even assign default values for the parameters.

When a configuration is created, it automatically receives three default parameters. These parameters are: InstanceName, OutputPath, and ConfigurationData. The InstanceName parameter holds the instance name of the configuration.

  • The InstanceName of a configuration is used to uniquely identify the resource ID that is used to identify each resource specified in the configuration. Normally, the default value for this is good.
  • The OutputPath parameter holds the destination for storing the configuration MOF file. This permits redirecting the MOF file that is created to a different folder than the one holding the script that is run. The default is to create the MOF files in the same folder that holds the script that creates the configuration. However, storing the MOF files in a different location makes it easier to reuse them and to update them.
  • The ConfigurationData parameter accepts a hash table that holds configuration data. In addition, any parameters that are specified in the param statement in the configuration are also available when calling the configuration. By calling the configuration directly from the script that creates the configuration, you are able to simplify the process of creating the MOF. The following ScriptFolderVersion.ps1 script adds a second resource provider to the configuration. The Registry provider is used to add the forscripting registry key to the HKLM\Software registry key. The registry value name is ScriptsVersion and the data is set to 1.0. The use of the registry provider is shown here:

      Registry AddScriptVersion
      {
        Key = "HKEY_Local_Machine\Software\ForScripting"
        ValueName = "ScriptsVersion"
        ValueData = "1.0"
        Ensure = "Present"
      }

The additional resource provider call is placed right under the brace that is used to close off the previous call to the File resource provider.

 The complete ScriptFolderVersion.ps1 script is shown here:

ScriptFolderVersion.ps1

#Requires -Version 4.0

Configuration ScriptFolderVersion
{
 Param ($server = 'server1')
    node $server
    {
      File ScriptFiles
      {
        SourcePath = "\\dc1\Share\"
        DestinationPath = "C:\scripts"
        Ensure = "present"
        Type = "Directory"
        Recurse = $true
      }
      Registry AddScriptVersion
      {
        Key = "HKEY_Local_Machine\Software\ForScripting"
        ValueName = "ScriptsVersion"
        ValueData = "1.0"
        Ensure = "Present"
      }
     
    }
}

ScriptFolderVersion

Setting dependencies

Everything does not happen at the same time when calling a DSC configuration. Therefore, to ensure that activities occur at the right time, use the DependsOn keyword in the configuration. For example, in the ScriptFolderVersionUnzip.ps1 script that follows, the Archive resource provider is used to unzip a compressed file that is copied from the shared folder.

The script files are copied from the shared folder with ScriptFiles activity that is supported by the File resource provider. Because these files must be downloaded from the network shared folder before the zipped folder can be uncompressed, the DependsOn keyword is used.

Because the File ScriptFiles resource activity creates the folder structure that contains the compressed folder, the path used by the Archive resource provider can be hardcoded. The path is local to the server that actually runs the configuration. The Archive activity is shown here:

      Archive ZippedModule
      {
        DependsOn = "[File]ScriptFiles"
        Path = "C:\scripts\PoshModules\PoshModules.zip"
        Destination = $modulePath
        Ensure = "Present"
      }

The ScriptFolderVersionUnzip.ps1 script parses the $env:PSModulePath environmental variable to obtain the path to the location of the Windows PowerShell modules in the Program Files directory. It also calls the configuration and redirects the MOF file to the C:\Server1Config folder. It then calls the Start-DscConfiguration cmdlet and provides a specific job name for job. It then uses the –verbose parameter to provide more detailed information about the progress. The complete script is shown here:

ScriptFolderVersionUnzip.ps1

#Requires -version 4.0

Configuration ScriptFolderVersionUnzip
{
 Param ($modulePath = ($env:PSModulePath -split ';' |
    ?  {$_ -match 'Program Files'}),
    $Server = 'Server1')
    node $Server
    {
      File ScriptFiles
      {
        SourcePath = "\\dc1\Share\"
        DestinationPath = "C:\scripts"
        Ensure = "present"
        Type = "Directory"
        Recurse = $true
      }
      Registry AddScriptVersion
      {
        Key = "HKEY_Local_Machine\Software\ForScripting"
        ValueName = "ScriptsVersion"
        ValueData = "1.0"
        Ensure = "Present"
      }
      Archive ZippedModule
      {
        DependsOn = "[File]ScriptFiles"
        Path = "C:\scripts\PoshModules\PoshModules.zip"
        Destination = $modulePath
        Ensure = "Present"
      }
    }
}

ScriptFolderVersionUnZip -output C:\server1Config
Start-DscConfiguration -Path C:\server1Config -JobName Server1Config –Verbose

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • This is really very awesome place and we are capable to provide phone line system to your country and particular region.
    check out my website http://www.inlinecom.com/">InLineCom

  • Thanks for this intro to DSC. I do a lot of Group Policy stuff and this is very interesting.

    Comment: My system has additional tools installed, so when I split the $env:psmodulepath variable on my system, I get two paths returned:

    C:\Program Files\WindowsPowerShell\Modules
    C:\Program Files\Microsoft Message Analyzer\PowerShell\

    Question: Does the DSC model allow us to use additional PowerShell code inside 'Resource Provider' script blocks (i.e. File, Registry, Archive, etc.) to handle these kinds of things or do we have to handle them externally?

  • @Jer,

    Have you figured this out? I think you have to handle them outside, or perhaps in the configuration script in some fashion. There is a script resource which is...um...mildly difficult to grapple with ;-) I've not read through all of these yet, but perhaps Ed gives us a better understanding of that particular resource.