Using PowerShell 4.0 DSC to Control Configuration Drift

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using DSC in Windows PowerShell 4.0 to control configuration drift.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a very important topic. I am going to talk about controlling configuration drift. This (for me anyway) is one of the big deals about Windows PowerShell Desired State Configuration (DSC) in the first place. This is because when a server is configured, changes immediately begin to take place. Even with nearly perfect change control, things still end up going askew.

Using DSC simplifies troubleshooting, and it can also conduct remediation. Needless to say, it is cool. By the way, I will be speaking at the Windows PowerShell Summit in Bellevue, Washington. There are still a few seats available. It is a great chance to come up to speed on topics like DSC.

Note  Today is the fourth day in a series of blog posts about Desired State Configuration. Portions of these posts are excerpted from my book, Windows PowerShell Best Practices, which is published by Microsoft Press.

Image of book

Today we’ll talk about controlling configuration drift.

Because Windows PowerShell Desired State Configuration is idempotent, you can run the same configuration script multiple times without the fear of creating multiple resources or generating errors. Therefore, if the same configuration runs multiple times, if the configuration has not drifted, no changes are made. If the configuration has drifted, you can easily bring the server back into desired state.

You do not need to worry about modifying the configuration script to correct only detected errors. In fact, you do not even need to worry about configuration drift. You just run the same configuration, and you can be ensured that the server is brought back into state. In the situation where a server must match the DSM state, you can use the Task Scheduler to run Start-DscConfugration on a regular interval that matches the specific urgency of the required checks.

Another way to check for configuration drift is to use the Test-DscConfiguration function. The way to do this is to create a CIM session to the remote servers with a configuration that requires checking. Do this from the same server that was originally used to create the DSC to assure access to the MOF files. After the CIM session is created, pass it to the Test-DscConfiguation function. This technique is shown here:

PS C:\> $session = New-CimSession -ComputerName server1, server2 -Credential iammred\administrator

PS C:\> Test-DscConfiguration -CimSession $session

The SetServicesConfig.ps1 script creates two configuration MOF files—one for each server that is specified in the node array. This is shown here:


Configuration SetServices
 node @('Server1', 'Server2')
  Service Bits
   Name = "Bits"
   StartUpType = "Automatic"
   State = "Running"
   BuiltinAccount = 'LocalSystem'
  Service Browser
   Name = "Browser"
   StartUpType = "Disabled"
   State = "Stopped"
   BuiltinAccount = 'LocalSystem'
  Service DHCP
   Name = "DHCP"
   StartUpType = "Automatic"
   State = "Running"
   BuiltinAccount = 'LocalService'

SetServices -OutputPath C:\ServerConfig
Start-DscConfiguration -Path C:\ServerConfig

The image that follows illustrates running the configuration and using CIM to verify that the configuration is still intact.

Image of command output

DSC Week will continue tomorrow when I will talk about more cool Windows PowerShell DSC stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (3)

  1. Rob,
    Th CIs in SCCM can be used in conjunction with DSC or they can be entirely separate. I personally will do DSC over the configuration items for a couple reasons. DSC doesn’t require a control server or a domain, and SCCMs configuration items are a little cumbersome to set up. When you write them in powershell you need to build 2 scripts per item. a detection script and a remediation script.

  2. I agree with Rob, I think DSC for configuration management makes so much more sense. While it can be used in conjunction with a pull server and using it in a domain offers advantages not found outside of domain, the ability to use the same configurations
    for servers outside the domain, say in a dmz, make this a much more flexible solution for configuration management than SCCM. I wouldn’t be surprised if you see some of this functionality making it’s way into SCCM in future releases.

  3. Rob says:


    I’m struggling to understand how and when I should use powershell DSC versus SCCM’s configuration baselines and configuration items with auto remediation. Can you shed some light?


Skip to main content