Multiple team, component, environment deployment via DSC (Part-2)

In part one I configured the environment, the pull server is set up and the target server is waiting for instructions. In this part I am going to create a DSC-resource, configure a DSC-configuration and tell the target machine what to search for at the pull server. Finally I will let it all come together in a single script to be used by any deployment tool.

The theory
By using Desired State Configuration (DSC) you describe the state you want your target machine to be in. When in that state it is assumed valid. That is the upper level of the DSC-scripts, here I define which applications and features should be on the targeted machine. Most OPS minded teams would want to be in control of these configurations but as long as you work together and provide versioning by code-repository this should be a good thing to start enabling DevOps. Teams provide the binaries (applications) to be deployed to the targets, these binaries should be accompanied by a DSC-resource file, all versioned, who can better deliver this than the same team which built the component. In the DSC-resource they describe how to bring the binaries in the required state and what parameters there are needed. When all compiled and placed correctly on the pullserver all targets will automatically sync up with the new configuration and only change when versions are out of sync.


Creating a DSC-resource
This very complex resource will just copy files from one folder to another. I am far from an expert in PowerShell but the scripts work :). You can download my resource xCustomCopyBits or you can read the entire article on how to create it yourself here.

Placing the resource in c:\program files\WindowsPowershell\Modules will enable DSC-scripts to use it during compilation. Get-DscResource can be used to validate whether the resource can be found and which versions are available.


A Dsc-Resource is created by implementing 3 methods: Test-TargetResource, Get-TargetResource, Set-TargetResource. By choosing how I implement the Test-TargetResource I can control when the resource is out of sync with its state. In my example I created a simple test whether a given path exists but I could also implement a more complex way with versioning to control the way my resource works.

In the Set-TargetResource I implemented the code to copy my binaries to the targeted path when its state is “Present” and to remove the path when the state is “Absent”. This is where the actual deployment of the binaries takes place.

Deploying the resource
Now I created my very complex resource I should make sure it is downloadable by the target. The way that works is to create a .zip file of the resource followed by versioning eg. “” and place it in “c:\program files\windowspowershell\dscservice\modules\”. By a created checksum the target can validate if there is a change and it should download a new version.

I decided to place my binaries side by side with the so that when the target pulls a new version of the resource my binaries are also on the targeted machine. Another way to get your binaries to the targeted machine is to implement a file download service so the target can download the binaries there. A nice example of how to do this exists inside the xChrome resource to download and install Google Chrome.

Create a DSC-Script
Now everything is in place to be installed, I have to create a DSC-Script that uses the newly created binaries and resources. I created a simple script that installs the windows feature IIS, deploys my special resource with binaries and write some logging.

For the target server to find it we need to compile it into a Managed Object Format (MOF) and name it by GUID. Place the created file in “c:\program files\windowspowershell\dscservice\configuration\” and generate a new checksum like I did for the DSC-Resource.

Everything is now setup on the pullserver, any target server who is searching for the GUID which I just placed will pull the configuration and download the additional DSC-Resource. To set up the target machine I used the script below. Configuring where to look for new configurations and by what GUID.

Within 30 minutes the target server will get the configuration and get itself in the requested state. I can confirm that by running the Test-DSCConfiguration -verbose.


With this article I showed how we could use a DSC-Resource to deploy my binaries to a target machine. I can configure any number of machines to point to the same GUID and by that be in sync with the current production version. Teams can update their DSC-Resource and just increment the version number to roll out a new deployment. But what about keeping the DTAP environments of other teams in sync? Well that’s just some infrastructure, by providing a pull server for each DTAP environment I will be able to scale any way I want to. Just make sure I push the configuration to each pull server when I release to production.


To simplify all the steps I created a single powershell script to be used by command line or by any releasemanagement tool for example MS ReleaseManagement. By modifying the version number of the DSC-Resource and providing the parameters.

DevOps can be implemented in many ways, this example was only to provide a solution for the given situation and should not be implemented without being well thought-through with the people and processes available. For a complete example with all files you can click here.

Have fun,



You may also like...

Leave a Reply