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:
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 paramkeyword in the same manner as you use it with functions. The paramstatement 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 paramstatement 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 forscriptingregistry 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 DependsOnkeyword 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