Debugging a DSC script for Release Management

When preparing a DSC script for deploying an application using Release Management it is often handy to test and debug that script locally. Nobody writes code that works the first time, right? However, you’ll quickly run into the fact that Release Management does some things slightly different than “vanilla” DSC (for example: .psd1 is not .ps1) and also provides some extra’s, like the $ApplicationPath variable that holds the path to the bits you’re deploying and the configuration of WinRM. Because of this, I found myself using the following workflow:

  1. Write DSC script
  2. Test and debug locally
  3. Configure Release Management with this DSC script
  4. Test and debug deployment from Release Management
  5. Change DSC script to work from Release Management

I wanted to eliminate step #5 and seriously reduce the time needed for #4.

For that purpose, I have created a PowerShell wrapper script. This script takes the same input parameters that you would configure in Release Management and executes your DSC script for you, much in the same way as Release Management would. This means you can test and debug your DSC scripts locally (without using Release Management) and when you eventually configure them in Release Management you don’t have to change anything!

You can download the script from my GitHub: Deploy_RM_local.ps1. Here’s how it works.

In Release Management, you use a “Deploy Using PS/DSC” block for deploying using DSC:

image

The interesting variables here are:

  • PSScriptPath: the path to your DSC script. This path is relative to the location of the component you’re deploying (usually the folder from your TFS drop).
  • PSConfigurationPath: the path to the script that contains your configuration data. Again, this is a relative path.

Furthermore, Release Management will provide a variable $ApplicationPath that will contain the absolute path to the folder where Release Management will have copied your component. We’ll need these three variables.

  1. Download the bits that you want to deploy to the server you want to test on, e.g. to “C:\Deploy\SampleApp_20150527.3”.
  2. Make sure you have the “Deploy_RM_local.ps1” somewhere on the server, e.g. in “C:\Scripts”
  3. Open a PowerShell prompt and navigate to the folder containing the script:
    cd "C:\Deploy\SampleApp_20150527.3"
  4. Execute the “Deploy_RM_local.ps1” script, feeding it the three paths as input. Optionally, you can add the “-Verbose” parameter to get some more logging. For example:
    .\Deploy_RM_local.ps1 -ApplicationPath "C:\Deploy\SampleApp_20150527.3" -PSConfigurationPath "Deploy\DeployConfig_AzureD.ps1" -PSScriptPath "Deploy\Deploy.ps1" -Verbose

That’s it! Happy deploying!

Bug in xWebAdministration module in DSC resource kit on Windows 2008 / IIS7

At one of the clients that I’m working we’re doing a proof of concept on using Release Management vNext type release templates for deploying their application. We’re using Powershell Desired State Configuration (DSC) for the actual deployment script.

One of the requirements is that we should also be able to deploy to the existing environments, running Windows 2008R2 and IIS7. Since the application is a simple web application, I was using the xWebAdministration module from the DSC Resource kit. When deploying to a Windows 2012R2 machine with IIS8, everything worked like a charm. However, when deploying on a Windows 2008R2 machine with IIS7, I got all sorts of weird error messages. There were already a couple of websites running on that machine, and it seemed as if the DSC script was trying to update those. Of course, it shouldn’t touch already existing sites.

After a bit of searching, I ran into this bug on Connect. Apparently there is a problem with the “Get-Website” cmdlet on IIS7. It returns all websites, instead of only the one specified with the “-Name” parameter. Since the xWebAdministration module uses “Get-Website -Name xyz” to get a reference to the website it should modify, it’ll try to update all the websites in the IIS server. So that explains it. Now, how to solve this?

Actually, the solution is not very complicated. The easiest is to modify your copy of the xWebAdministration module. Open the “MSFT_xWebsite.psm1” file in your favourite editor. You’ll find it in the “DSCResources\MSFT_xWebsite” folder.

Then, do a “find and replace” and replace this:

$Website = Get-Website -Name $Name

With this:

$Website = Get-Website | Where { $_.Name -eq $Name }

You should find five occurrences of the above snippet. After doing the replace, save the file and run your deployment again. If all is well, it should work now 🙂

Happy deploying!