Desired State Configuration and Hyper-V Part 6 – How Does DSC Differ from Group Policy?

Welcome back for our final installment of Desired State Configuration and Hyper-V. Even though the series was targeted as an introduction to DSC, we still covered quite a bit of material. Below are the relevant links for parts 1 through 5 should you need a refresher on any of the topics previously discussed.

• Part 1: System Requirements and Benefits
• Part 2: DSC Resources
• Part 3: Generating DSC MOF Files
• Part 4: Pushing DSC Configurations
• Part 5: Pull Server Configuration

Today we’ll be wrapping up our series on Microsoft Desired State Configuration with a quick review of how DSC is different from Microsoft’s Group Policy technology. We’ll be covering pros and cons.

While Desired State Configuration and Group Policy can alter a lot of the same settings there are situations where DSC makes more sense than Group Policy and vice versa.

Let’s start with Group Policy as it’s the more tenured of the two technologies.

Group Policy

Let’s face it. Group Policy has been around forever, and with good reason! It’s a great technology when leveraged properly and can be exceptionally helpful in your day-to-day operations. Group Policy is also tried and true and you can find a lot of support for it online and amongst IT professionals due to its prevalence in the industry. Let’s start by covering its Pros.

Pros

1. Integration with Active Directory – This is potentially Group Policy’s biggest pro, and con (more on that in a second). With its tie-in to AD we have the ability to do fine grained targeting on a per-user or per-computer basis and leverage AD security groups while doing so.
2. Works on a vast array of Windows systems – This includes servers as far back as Server 2000, thus it’s great for use with legacy Windows systems that may not be able to accommodate all the requirements of Desired State Configuration.
3. Product is Quite Mature – Group Policy has been around for a while, thus it’s had the time to mature nicely into a refined product. When managed properly, it can be very easy to manage and requires relatively little time to keep under wraps in most environments.

Cons

1. Requires Active Directory – This is perhaps Group Policies largest flaw. AD is required, thus it’s a no go for non-domain joined machines and other OSs, such as Linux.
2. Easy to circumvent – It’s relatively easy to prevent a machine from receiving Group Policy updates from the domain if you know what you’re doing. If preventing changes to a machine is your goal, DSC is certainly the better choice in this situation.
3. Features are Dependent on Domain Functional Level – Depending on your domain controller make-up, you may be at a Windows 2000 domain functional level, a 2012 R2 functional level, or anywhere in between. Depending on the functional level of the domain, you may (or may not) have certain GPOs available for use. Because of this tie to the functional level of the domain, you may have to conduct some infrastructure upgrades in your environment prior to utilizing certain GPOs.

Desired State Configuration

The venerable topic we’ve been talking about in this series for some time. This is essentially the new kid on the block, but ultimately has a different use case than Group Policy.

Pros

1. Can be applied to multiple entities – The key word here is “entities”. DSC has no dependency on a directory structure like Active Directory, thus it has the ability to be applied to a vast number of different things. Windows server and desktops, Linux OSs (push configs only). There is even talk of DSC one day being able to affect change on devices like routers and switches…etc..etc. Essentially anything that can read the MOF file format would be able to apply the benefits of DSC.
2. Can be configured to be enforce persistence – DSC is much more difficult to disrupt and prevent it’s target configuration from being changed. Yes you could modify the values that a particular DSC config is managing, but the next time that server checks the MOF file for compliance, all those changes are removed and the MOF file is enforced. This check can be configured to occur every couple of minutes, so this helps configuration enforcement.
3. Highly Extensible – DSC and the MOF format lend themselves nicely to 3rd parties who want to create integrations and resources stacked on top of DSC. The framework is there for extensibility, and as DSC continues to grow, I think we’re going to start seeing a vast array of products tapping into that extensibility potential.

Cons

1. Still a relatively young product by software standards – DSC is still in its infancy. It may one day surpass Group Policy but as of this writing they are both viable. This is a con that will arguably become less so over time as the tool matures.
2. Requires Powershell know-how and familiarity – While it’s not a bad thing that PowerShell know-how is needed for this, the fact is I can walk in my place of work, throw a rock and hit half a dozen system engineers that know Group Policy like the back of their hands. DSC is not widespread yet, and it will take some time for the industry to accept and adopt it.
3. Deployment of DSC resources can be problematic – The resources for DSC that we talked about in Part 2 have to be present in several locations throughout your deployment zone. Depending on your network topology, this may (or may not) be a complicated process, whereas with Group Policy, you don’t have to worry about this.

Summary

While this certainly isn’t a fully comprehensive list, it certainly covers the main pros and cons of each technology and what the use cases are for both.

Again, thank you for joining us for this series on Microsoft Desired State Configuration, and if you find yourself needing more material regarding this topic, head on over to Powershell.org. They have a TON of material on this subject and can be of great assistance for more complex deployments.

Thanks for Reading!