Welcome to Day 50 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC. If this is the first time you are viewing an article of the series and you are new to DevOps and PowerShell Desired State Configuration (DSC), I encourage you to read through the previous installments, particularly Day 1.
PowerShell Desired State configuration delivers a new paradigm in configuration management and deployment capabilities to Windows and Linux operating systems. One of the first realizations I see new users of DSC come to is that the capabilities of DSC overlap with the capabilities in Active Directory Group Policy.
And that leads to a very common question, one that in fact came up the very 1st day of our series. Better still, we received a common from the man himself!
Will DSC and Group Policy work together?
That answer immediately leads to yet another really important question:
Where and when should I should PowerShell DSC instead of group policy?
The right strategy will vary based on your environment and needs. No doubt the answer will evolve as DSC capabilities expend and advances in the Microsoft management stack evolves to leverage DSC capabilities.
Here in Day 50 of the “100 Days” series, I will briefly compare and contrast the differences, advantages and limitations of Group Policy and DSC, as well as some scenarios where DSC offers some advantages over Group Policy.
Targeting and Reach
The advantage of Group Policy over DSC, today anyway, is that Group Policy has greater ability to target computers based on their location in Active Directory, such as OU or AD site, WMI criteria, etc. Whether you use a DSC Push or Pull strategy, today DSC targeting is driven by you, the administrator. While it has become more flexible through the addition of Group Policy Preferences, Group Policy is still difficult to extend, because client extensions are native code. DSC can drive configuration and deployment using the reach of PowerShell. Finally, remember DSC runs on Linux (Push mode only). There is no such thing as Group Policy for Linux today.
While it will take time (DSC is a very young management feature), it seems likely DSC will supersede Group Policy in some areas over time.
Today, DSC is very server-centric, but this too could change in the future as the Windows client operating system evolves. Time will tell.
Because DSC employs a declarative model for each managed node defined in a single configuration MOF file, the potential for conflict is minimized. When something doesn’t go as expected, DSC logs errors in the Windows Event Log, easing the troubleshooting process. Since a given node can only have one desired state at a time, if I apply a new configuration MOF to a managed node, the new MOF is considered to be the desired state. In addition, DSC resolves conflicts at design time when you are actually creating the MOF file.
While group policy includes the Modeling Wizard to simulate policy application, as well as Resultant Set of Policy (RSoP) and GPResult.exe to troubleshoot policy application on a managed system, this is not a simple or quick process when you factor in policy precedence, WMI and security group filtering and the intricacies of Group Policy Preferences.
Chalk up another one for DSC here.
Local versus Connected
The DSC Local Configuration Manager (LCS) includes a periodic configuration refresh (15 min check for updates, 30 min application by default) designed to minimize configuration drift. This is essential because of how DSC gets it’s configuration. DSC stores it’s desired configuration locally on the target node (regardless of whether it’s pushed or pulled) so configuration can be applied whether or not the remote DSC Pull Server is accessible. Group Policy, on the other hand, re-queries Active Directory and SYSVOL to retrieve configuration information. It’s important to have the capability to enforce configuration regardless of connected state, especially in today’s world of disconnected clients (computers and devices). This is an area that make one wish for some client focus in DSC in the not-too-distant future.
And what about perimeter networks and other scenarios where an AD domain (and thus group policy) are not available? DSC definitely fills a gap in policy-based configuration of workgroup systems.
Tools and Integration
Management tools can’t easily leverage Group Policy due to the aforementioned native code. Because DSC employs a MOF file, a Desktop Management Task Force standard, any management tool that can generate a MOF file can potentially leverage DSC as a policy engine. Since DSC doesn’t have a front-end per se, leveraging other tools you may already own may prove convenient. I expect this aspect of DSC will change over time as well. One could certainly guess that the overlap between SCCM Settings Management and DSC is another opportunity for integration between DSC and the management stack in some future version of SCCM. Again, I have no inside info here, time will tell.
Bonus: DSC Management Pack
Speaking of management tools, there is now a DSC Management Pack for System Center 2012 Operations Manager (SCOM). Check it it out at
That’s all for this installment. I hope this provides some insight into the current state of Group Policy versus DSC and some scenarios where DSC offers some advantage or fills a gap. Please leave your thoughts and comments in the section below this post.
To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.