Deploying using PowerShell Desired State Configuration in Release Management

Deploying using PowerShell Desired State Configuration in Release Management

Rate This
  • Comments 1


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).

image



“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.


image


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:SystemDrive\SourcePath"
 7: DestinationPath = “$env:windir\DestinationPath”
 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:\users\public\dsc"
 17: Set-DscLocalConfigurationManager -Path "c:\users\public\dsc" 
 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

image

  • Copy custom modules using Initialization script
 1: Copy-Item $applicationPath\Modules $env:psmodulepath.split(";")[1] -Force -Recurse
 2:  
 3: $ConfigData = @{
 4: AllNodes = 
 5: @(
 6: @{
 7: NodeName = $env:COMPUTERNAME;
 8: SourcePath = “$env:SystemDrive\SourcePath"
 9: DestinationPath = “$env:windir\DestinationPath”
 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”

 

Leave a Comment
  • Please add 8 and 4 and type the answer here:
  • Post
  • I don't quite understand how Release management can play nicely with DSC in any environment where you have more than one project.

    Consider that DSC may be used to configure many different web applications on a web server, in addition to various other things. As soon as you "release" a new version of one of the applications will push that specific application's configuration to the server, completely overwriting the current settings of the LCM. This is especially important when you'd otherwise want to use a pull server to manage the server configurations.

    Wouldn't it be possible for the Release Management tool to instead of pushing configurations to spit out composite configuration files that can then be included in a larger configuration?

Page 1 of 1 (1 items)