Deploying using PowerShell Desired State Configuration in Release Management
With Microsoft Release Management 2013 Update 3 RC, you can now use Windows PowerShell or Windows PowerShell Desired State Configuration (DSC) for deploying and managing configuration data.
> Windows PowerShell (PS) >
>
Refer to Scripting with Windows PowerShell (PS) for more details. These scripts can be same as what you might have been already using to deploy using Microsoft Deployment Agent.
>
>
RM 2013 Update 3 “Deploy using PowerShell” requires PS version on the target servers to be of version 4.0 or higher.
>
>
Windows PowerShell Desired State Configuration (DSC)
>
DSC is a PowerShell extension and ships with Windows Server 2012 R2 and Windows 8.1. DSC is also part of Windows Management Framework 4.0 which ships as an optional update and can be installed to Windows Server 2012, Windows Server 2008R2, Windows 7 and Windows 8.
The PowerShell v4 DSC extension adds a new keyword called “Configuration”. With this keyword, which is actually a “function”, you define a DSC configuration block. RM leverages Windows DSC Local Configuration Management Engine to apply the configuration when a PowerShell script has “DSC Configuration” block in it.
Deployments using PS/DSC in Release Management
“PSScriptPath” action parameter
Specify the relative path to the PS/DSC script file with respect to the package path (Component).
“PSConfigurationPath” action parameter
Specify the relative path to the PS/DSC script initialization file with respect to the package path (Component). This is an optional parameter, when set, RM will run this PS script prior invoking the main-script file.
In RM, you can define configuration data separately from the logic of your configuration in a PS script file and use it to initialize the main script (Here main-script is the actual PS/DSC script referred by ‘PSScriptPath’).
Variables initialized here will be visible to the main script file. By using initialization script, you can potentially –
- Initialize environment specific variables
- Configure LCM setting
- Install custom Modules
Initialization PS script file has following advantages:
- It allows you to reuse your configuration data for different resources, nodes, and configurations.
- Configuration logic is more reusable if it does not contain hard-coded data. This is similar to good scripting guidelines for functions.
- If some of the data needs to change, you can make the changes in one location, thereby saving time and reducing errors.
Initialize environment specific variables
a) Look at the below sample which shows how you can parameterize your main DSC script using this initialization script file.
Sample PS DSC script file
1: Configuration MyDscConfiguration
2: {
3: Node $AllNodes.NodeName
4: {
5: File MyExampleFileCopyResource
6: {
7: Ensure = "Present"
8: Type = "Directory"
9: Recurse = $true
10: SourcePath = $Node.SourcePathtoFolder
11: DestinationPath = $Node.DestinationPathtoFolder
12: }
13: # Other DSC resources, custom resources
14: }
15: }
16:
17: MyDscConfiguration –ConfigurationData $ConfigData –Verbose
Initialization PS Script file
1: $ConfigData = @{
2: AllNodes =
3: @(
4: @{
5: NodeName = $env:COMPUTERNAME;
6: SourcePath = “$env:SystemDriveSourcePath"
7: DestinationPath = “$env:windirDestinationPath”
8: }
9: )
10: }
Note:
- $ConfigData is initialized using PS script file specified in ‘PSConfigurationPath’
- Ensure that you don’t specify “–OutputPath” parameter for the MOF file. RM handles the MOF file generated and its cleanup.
- You don’t need to call Start-DscConfiguration as you might’ve noticed. RM applies the cmdlet as part of the DSC execution
Configure LCM settings
Initialization script file can also be used to configure the LCM (Local Configuration Manager engine) of the target node.
Example:
1: Configuration ExampleLCMConfig
2: {
3: Node “localhost”
4: {
5: LocalConfigurationManager
6: {
7: ConfigurationModeFrequencyMins = 45
8: ConfigurationMode = "ApplyAndAutocorrect"
9: RefreshFrequencyMins = 90
10: RebootNodeIfNeeded = $true
11: AllowModuleOverwrite = $false
12: }
13: }
14: }
15:
16: ExampleLCMConfig -OutputPath "c:userspublicdsc"
17: Set-DscLocalConfigurationManager -Path "c:userspublicdsc"
18:
19: # Cleanup the 'meta MOF' generated
20:
Note:
- RM doesn’t apply ‘Set-DscLocalConfigurationManager’, needs to be set explicitly as shown in the sample above
- Cleanup of ‘Meta MOF’ file has to be handled outside of RM
Install custom modules
Initialization script to install custom modules
Example
- Drop the custom module along with build. For e.g. custom modules are packaged under “CustomModules” folder in the build
- Copy custom modules using Initialization script
1: Copy-Item $applicationPathModules $env:psmodulepath.split(";")[1] -Force -Recurse
2:
3: $ConfigData = @{
4: AllNodes =
5: @(
6: @{
7: NodeName = $env:COMPUTERNAME;
8: SourcePath = “$env:SystemDriveSourcePath"
9: DestinationPath = “$env:windirDestinationPath”
10: }
11: )
12: }
$applicationPath parameter
“$applicationPath” variable points to the root folder path of the build that has been copied locally onto the target node by RM.
Example
Consider this scenario: As part of your deployment if you intend to copy build to a folder on target machine say c: DeploymentFolder or D: DeploymentFolder
Initialization file
1: $ConfigData = @{
2: AllNodes = @(
3: @{
4: NodeName = $env:COMPUTERNAME;
5: DeploymentPath = $env:SystemDrive + "DeploymentFolder"
6: }
7: )
8: }
DSC script file (main-script)
1: Configuration FileCopy{
2: Node $AllNodes.NodeName
3: {
4: File CopyDeploymentBits
5: {
6: Ensure = "Present"
7: Type = "Directory"
8: Recurse = $true
9: SourcePath = Join-Path $applicationPath “DeploymentBits”
10: DestinationPath = $Node.DeploymentPath
11: }
12: }
13: }
14:
15: FileCopy -ConfigurationData $ConfigData –Verbose
Note:
- “$applicationPath”will always point to root directory of your build which you are deploying
- Here we have used a DSC File resource to copy the folders recursively. As the source path refers to “$applicationPath”
Light
Dark
0 comments