Problem solve Get help with specific problems with your technologies, process and projects.

Lock down configuration drift with an automation deployment strategy

Microsoft now offers a built in option for automation deployment called Desired State Configuration. DSC will make configuration management easier.

Administering servers, both on-premises and in the cloud, is a tall order. It requires hundreds of deployments as well as constant monitoring to see if someone has added or removed unintended software or made configuration changes you did not intend. Scripts can be of some assistance in the deployments, but monitoring changes and enforcing your will to avoid configuration drift is another thing entirely. If you hail from a Linux/Unix background, you are familiar with automation and configuration management products such as Puppet and Chef. These declarative configuration tools make configuration management and automation deployment simple.

But what if you're a Windows Server IT pro? While Puppet and Chef will work for Windows, the concept of what these products do is somewhat foreign. Microsoft now has the same technology built into the Windows operating system (if you have PowerShell v4 installed) called Desired State Configuration (DSC).

Understanding the concept of declarative configuration management and gradually building experience with a technology like DSC is hard and requires hands-on experience. It's important to not only read this article, but to try using it yourself as well.

What you need to experience DSC

In order to get started with DSC, spin up two virtual machines (VMs) with Windows Server 2012 R2. Give them IP addresses on the same network. You don't need a domain for this, that's one of the features I'll discuss, just make sure they can ping each other. Also, don't install any roles; we will do that with DSC.

You can do this with an older version of Windows Server, but you need to have PowerShell v4 installed on both servers and PowerShell Remoting enabled. It is enabled by default on Windows Server 2012 R2. If you want to save time, just download the evaluation version of Windows Server 2012 R2 from Microsoft.

You may want to keep these VMs around for the next couple of months, so you can use them for the future articles when we start diving deeper into DSC.

Solving the business problem

The example problem is simple, but it is a real-world issue. I need to configure a server (or a million) with Internet Information Services (IIS). In this case, I want to ensure that I have support for ASP.NET version 4.5 and the IIS management console. So, let's make our first DSC script.

The VM computer names I'm using in this example are DC and S1. DC is where I'm going to write and execute my script and S1 is the target that I want to be the new Web server. Insert your own computer names as needed.

On DC, open the PowerShell ISE to create a new script named Install_IIS.ps1 and save it in a folder of your choice, such as C:\scripts. In that script, create something that looks very similar to a function but uses a unique keyword called "configuration." Similar to a function, the configuration needs a name, so I called mine "Install_IIS."

Configuration Install_IIS {

You're going to need to run this script and execute the configuration at the end. If you have run a PowerShell script with a function, you know that the function will be removed from memory when the script exits, so I want to change the script so that when you run it, it executes the configuration before exiting. Add the line below the last bracket:

Configuration Install_IIS {


A configuration file must have at least one node. Think of a node as a computer or collection of computers, but it's called a node because DSC is standards-based, which means it could be anything, even a network switch.

In my example, I'm adding a node for my computer S1.

Configuration Install_IIS {
     Node s1 {


Inside the node, specify what you want to configure. This is a very simple example and for this case, I want three Windows feature roles installed: the Web-Server, Web-Mgmt-Console and Web-Asp-Net45.

Here's how I found the names of the roles I wanted for my Web server. Open a PowerShell prompt on your server and type the following:

PS> Get-WindowsFeature *web*

The roles are listed under the name column.

Inside the node, I'm going to add an element called a resource. The one I'm using is a built-in resource called WindowsFeature that allows me to add roles. It looks similar to a function and also requires a name. Inside of WindowsFeature I will specify the name of the role and whether I want it "present" or "absent."

Configuration Install_IIS {
     Node s1 {
              WindowsFeature IIS {
                    Ensure = 'Present'
                    Name = 'web-server'

          WindowsFeature IIS-Console {
                    Ensure = 'Present'
                    Name = 'web-Mgmt-Console'

          WindowsFeature ASPNET45 {
          Ensure = 'Present'
          Name = 'Web-Asp-Net45'



Save the script to a folder, and then run the script. You will notice that a new folder is created named Install_IIS. If you take a look inside that folder, you will see a file named S1.MOF that was created by your script. This is part of the magic of DSC but, in a nutshell, we are about to send that Management Object Format (MOF) file to the S1 server. The S1 server has a special component (starting with PowerShell v4) called the Local Configuration Manager (LCM) that will use that MOF to configure the server.

To send the MOF (deploy) from the DC computer, open a PowerShell console, and type

PS> Start-DscConfiguration -Path C:\scripts\Install_IIS

The -Path parameter should point to the location of the folder created by your script. When you execute the above command, a PowerShell background job is started. You can view the job using Get-Job and wait until it ends.

Go to the target computer (S1) and open a PowerShell prompt. Run Get-Windowsfeature *web* and notice you now have a Web server configured just the way you wanted it.

Before you race off and start trying this in production, remember this was a simple way for you to get started using what is called a "push" mode configuration. This is not necessarily the best approach, but it's great for testing. In future articles, I will show you how to set up and use a "pull" model. With this model, DSC checks and verifies your configuration every 15 minutes, which means if someone makes changes to the configuration you set, those changes are removed.

There is much more to learn about DSC and how this will be the best way to manage deployments and configuration drift.

If you found this article helpful, or have questions, leave a comment and let us know.

Editor's note: This article is the first in a series on learning and using DSC.

Dig Deeper on Virtual machine provisioning and configuration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.