If you haven’t read my most recent post on Desired State Configuration (DSC)–the new feature coming with the Windows Management Framework v4 (i.e. PowerShell v4, which will ship in the box in Windows 8.1 and Windows Server 2012-R2) then I encourage you to check it out. Ever since DSC became public, there’s been a lot of buzz about it being the “killer feature” in the next version of Windows and next version of PowerShell–the “DevOps” configuration management solution that Microsoft needed to deliver. And while I have been equally enthusiastic about it– as a Group Policy MVP and someone who has seen Group Policy not receive the attention it deserved and needed within Microsoft–I’ve also started to reflect on what DSC means to the configuration management landscape within the Microsoft family of products. Frankly, if I were an IT customer, I would be a bit confused. And, to be fair, this is sort of inevitable. We are in a transition period in IT. Infrastructure is moving towards Cloud-based solutions, desktops are giving way to devices and the world in which we lived for the last 25 years is simply changing. That said, I think it’s worthwhile to look at DSC in the context of Group Policy, and that’s what I do in this posting.
So, I’m going to try to compare and contrast DSC vs. Group Policy. To be sure, these are not the only two configuration management technologies that Microsoft offers. To my knowledge, there are at least 4 in play today, including:
- Group Policy (free and in the box in Windows since Windows 2000)
- DSC (coming to a Windows box near you soon)
- System System Configuration Manager (and specifically Desired Configuration Management (DCM), which can get and set configuration items as of the most recent release)
- Windows InTune
To be sure, each of these is targeted at a different niche, and each has it’s strong points. Some of these, like DSC and Group Policy, are part of Windows (or are available as free add-ons). Some, like SCCM and InTune, are for-pay solutions, each potentially targeted at different segments of the market–SCCM for large enterprises and InTune for the SMB space (though that has been blurred by statements from Microsoft that talk about InTune being used as the configuration solution for Windows RT devices in any size enterprise). The problem with each of these solutions is that they use different underlying technologies to describe, deploy and enforce configuration. There are different features that are supported (or not supported) in each, resulting in overlapping areas of concern. Worse, there is no reconciliation capability across these technologies–so a customer deploying a password policy using InTune AND Group Policy have no way of knowing if they are each in conflict. The target node could essentially Ping-Pong between the two controlling systems’ values without the customer ever knowing it. The same issues hold true with Group Policy and DSC. In all likelihood, customers will jump on the DSC bandwagon as soon as it’s shipping (if not before). But before that happens, it’s essential to understand the difference between DSC and that other in-the-box technology–Group Policy–and what the strengths and weaknesses are of each. And make no mistake, just because its new and shiny does not mean DSC is the be-all, end-all solution to all configuration problems. There are some things that Group Policy does and will likely continue to do better for the foreseeable future. With that, let’s compare and contrast some key features of DSC and Group Policy, to see how/where each might be used going forward.
Event Driven and Push/Pull
The first difference between Group Policy and DSC I’ll talk about is how each delivers configuration information. Group Policy uses a combination of event-driven (e.g. computer startup and user logon) and polling-based mechanisms to deliver configuration policy. Specifically, GP processes in the “foreground” during a startup or logon event, and you are able to perform configuration tasks that take advantage of this event-based approach (e.g. apply policy to a user’s configuration as that user logs on). The polling approach (also called asynchronous background refresh) happens on a timed cycle and ensures that if centrally deployed GPOs change, the client nodes will be no more than 90 minutes out of current policy before they are refreshed (although this system is imperfect. Group Policy won’t actually fix a setting that has drifted unless something in the policy chain has changed–i.e. a policy has been updated).
As compared to Group Policy, DSC provides for two modes of configuration delivery–a “push” mode that happens centrally and a “pull” mode that happens periodically. Neither could really be called “Event Driven” except to say that a Push is an event. However, since it’s not an event happening at the target node, it has no context as to what is happening on the target node. For this reason, it is currently very hard to use DSC for certain scenarios, such as user-based configuration at logon time. That said, you could probably jury-rig this type of activity with a combination of Group Policy-based logon scripts and DSC’s equivalent of a “gpupdate” command. But I digress into the weeds a bit. The point here is that DSC is not really event-based, but does provide the centralized triggering of configuration distribution that Group Policy does not provide. In addition, DSC has the option of pulling configuration from a “Pull Server” on a configurable interval, giving it equivalent functionality to a GP background refresh. Finally, DSC also has the notion of a “Configuration Refresh”, which is designed to minimize configuration drift. This is essential because of how DSC gets it’s configuration. Unlike GP, which, during a foreground or background refresh interval, re-queries AD and SYSVOL to obtain configuration information, DSC stores it’s desired configuration locally on the target node (regardless of whether it’s pushed or pulled). So, it’s important that it have the ability to ensure it’s in compliance with it’s desired configuration regardless of whether its had a new configuration pushed/pulled to it. This Configuration Refresh serves this purpose and it’s a feature that Group Policy doesn’t really support effectively.
Desired State vs. Wishful Thinking
This next section is a bit hard for me to explain clearly but it underscores a key difference between DSC and GP. Namely DSC provides “declarative” extensions to the “imperative” PowerShell language. Declarative is a concept that can be hard to comprehend, but in the context of a programming or scripting language, think of it as a way of providing English language instructions as to what you want to do instead of writing an algorithm with steps of code as to what you want to do. For example, to declaratively configure a registry value you might provide a block of text that says, “Ensure that HKLM\Software\SDM Software\InstallDir is present with a value of 1” on a given machine. The implementation of this declarative statement is left up to the underlying language system. Conversely, an imperative language might specify a handle to a registry key, define the value name and type of that key, and its data. It might also put some conditional if-then statements in there to test to see if the registry value already exists, etc. The point is that the Declarative approach leaves many of those implementation details to the underlying system. In the case of DSC, that underlying system are the DSC Resources that Microsoft (and you) provides.
Ok…with that definition in hand, how does it impact our discussion here? Namely, DSC is primarily a declarative language on top of PowerShell. Group Policy could also be considered declarative, at least at design time when you’re describing your GPOs, but it quickly becomes an imperative system when policy is calculated, filtered and delivered. Regardless of the words, I think the big difference for me here is that in DSC, you “Declare” what the desired state is for a given endpoint (or endpoints). In Group Policy, you define GPOs with policy settings and a set of filters, but the ultimate state of the endpoint is unknown to you until runtime–that is, when the Group Policy is processed. Group Policy becomes a series of “wishes” that you hope get delivered the way you want, depending upon the various criteria that apply during GP processing (e.g. filtering, linking, etc.). DSC is what it is. When you define a DSC document, that is what will get sent to the target nodes–nothing more, nothing less. Which leads to the next big difference between GP and DSC–Conflict resolution.
Conflict Resolution…or Not
If you’ve worked with Group Policy for any period of time, you know that one of the hardest things to understand about GP is it’s targeting and, ultimately, it’s conflict resolution mechanisms. Why is that? Well, conflict resolution at run time is a hard thing to get right. This is especially true because, in GP-land, you’re allowed to filter GPO settings application based on any number of shifting, dynamic criteria–such as linking, security group filtering, WMI filtering, and even GP Preferences Item-Level Targeting. Each of these is evaluated at runtime–that is, when GP is processed. So, there is no way for you to know, in advance, what settings will be delivered to a given node (or user) with absolute certainty. Therein lies a big problem with GP, especially as it relates to using it for server configuration. In most IT shops, when a manager asks, “Does my server have all the security hardening settings it’s supposed to?”, it’s generally frowned upon to provide the answer, “Well, I think so. It should”. Not the best story. We did get Resultant Set of Policy (RSoP) with GP to help with this problem, but at best it’s a one-off, one-node-at-a-time solution to an intrinsic problem with policy-based configuration management.
So how does DSC solve the conflict resolution issue? Well, it doesn’t. It completely punts on the problem in fact. A given server can only have one desired state at a time. If I define a set of registry entries or packages that I want on a server using DSC, and then come along with another DSC document that defines a different set of things, the last one that is pushed, or pulled to/from the server is the one that’s considered the desired state. The first one is ignored, or at least no longer part of desired state for the purposes of reporting and enforcement. In addition, all “conflict resolution” such as it is, is done at design time-i.e. when you’re creating your configuration documents. If a given DSC resource has conflicting values within the same document, you’ll get an error. So, in a manner of speaking DSC solves the conflict resolution problem by…ignoring it. This may seem like an unfortunate decision but frankly, it’s probably not a bad idea, especially for servers. Typically, for a given group of servers, you want to know exactly what configuration they have at a given time. And what better way to determine that than to have it staring right at you, in a single document? Of course, you do give up some of the inherent flexibility of GP’s dynamic targeting system. DSC configurations are statically linked to given servers at design time, so if you wanted to deliver a configuration to a particular server based on a dynamic characteristic of that server (e.g. the IP subnet it was on or the group it belonged to) you’d be out of luck, for the most part. Again, whether this proves to be a real issue remains to be seen. Maybe folks will like the simpler assumptions that DSC makes. Or maybe this is what will delineates when folks use GP vs. DSC.
Tattooing
Ever since Microsoft invented “system policy” in NT 3.x (or was it 4.x? I don’t remember now) there has been this notion of policy tattooing. I wrote about this a while back in an article on my gpoguy.com website, but the notion is simple. In a policy-based system, if you apply a configuration to a system, and then remove the thing that applied that configuration, the configuration items should go away (ideally). In the case of Group Policy, this most often applies to registry settings. Administrative Templates policy was implemented in such a way that, if a GPO that delivered some registry settings no longer applies to a system, those registry settings are automatically removed. This is, of course, an artifact of Group Policy’s dynamic targeting mechanism, which allows for policies to come and go from a user or computer based on the state of those users and computers. Now, to be sure, not everything in GP follows this mechanism. Many security settings, for example, will remain “tattooed” on a system when their underlying GPOs go away. But the non-tattooing nature of GP is a unique characteristic of this technology that is not shared with DSC. Again, because of it’s declarative nature, a registry value, for example, is either defined in a desired state, or it’s not. You can define a registry value to be “Present” in one version of a configuration document, and then decide you don’t want it to be present in the next version. But you’ll need to tell that configuration document that you want the previous value to be “Absent”. And remember, because only one baseline configuration can apply to a system at a time, you’ll have to rev your configuration document each time you want to remove a setting that was previously defined. Perhaps this will get better in future versions but for now, that seems to be the way DSC works. That said, if you decide it’s ok that DSC is a declarative, desired-state configuration system rather than the imperative, dynamic, policy-driven system that is GP, then maybe this behavior isn’t so bad, and again, a key differentiator for when to use DSC vs. GP.
Server vs. Workstation
One of my first thoughts as I started working with DSC, was whether it was really a system optimized for managing server configuration vs. client configuration. The presentations I saw around DSC before and when it was released into the wild suggested it was a server configuration solution, ala Puppet or Chef. To be sure, there is nothing in DSC that precludes you from pushing desired state configuration to a workstation, but as I mentioned earlier, there’s at least one facet of DSC that make it less suited to workstation-based configuration that it’s predecessor, Group Policy. The main one of those is the lack of support for delivery of user-specific settings based on key user events, such as user logon. Without this trigger, there is no way you can guarantee that per-user settings, defined in a DSC configuration document, will be delivered when the intended user is logged into the target system. This is a basic and fundamental limitation around using DSC for workstation-based configuration management. As I mentioned earlier, there is likely a way you can jury rig this using a combination of Group Policy AND DSC, but DSC alone doesn’t seem to support it today. That said, there is certainly support within, for example, the DSC Registry Resource, for delivering registry entries to HKEY_CURRENT_USER, so it’s not as if it’s technically difficult to make this work. It’s just a question of timing!
What’s It All About?
So, in summary, do I think DSC is a 1-1 replacement for Group Policy? No–at least not today. I think Group Policy will still be the configuration management solution of choice for desktops. But there are lots of nifty features in DSC that make it better suited to server configuration management–especially as servers continue to drift from the corporate data center to the “cloud”. That said, I encourage everyone who manages GP today to play with DSC. It’s important to understand all the tools in your arsenal, and DSC is a formidable new addition for Windows environments. And who knows, maybe we’ll see DSC coming to a Linux server near you in the future! In any case, as you start making decisions about which in-the-box configuration management solution you bet on for the future, make sure you understand, for your own environment, where Group Policy and DSC will play a role, and try hard not to use both for the same thing :). I guarantee it won’t be fun.
Darren