Compare Group Policy (GPO) and PowerShell Desired State Configuration (DSC)
What is the difference between Group Policy (GPO) and PowerShell Desired State Configuration (DSC) ? Why would I use one over the other? I hear these questions frequently. Today we are going to fully explore the pros and cons of each. Is GPO going the way of the floppy disk? Let’s find out.
The Contenders
Group Policy Objects (GPO) have been around since Windows 2000 for configuring Windows clients and servers. They require Active Directory, and domain controllers host the policies. Clients download the policies at login based on their location in the organizational unit (OU) hierarchy and based on filters by security groups and WMI. This is the first choice for managing Windows machines in the enterprise, and it is included in-box with the operating system. GPOs enforce system settings and facilitate compliance with corporate and industry policies.
PowerShell Desired State Configuration (DSC) was introduced with Windows Management Framework (WMF) 4.0. Like group policy, it can configure settings on Windows machines. However, DSC can leverage the automation of PowerShell to configure nearly anything on the system, beyond the preconfigured choices of group policy. DSC is also built into the operating system on Windows 8.1/Windows Server 2012 R2 and above. It is available down level by downloading and installing the latest WMF update (currently 5.1). DSC does not have a graphical management interface and requires knowledge of PowerShell scripting to build out tools for administration.
Group Policy vs. PowerShell DSC
Comparing GPO and DSC is like apples vs. oranges, or pirates vs. ninjas, or Chuck Norris vs. .... Well. They each have strengths and weaknesses. And each technology was created to solve a different problem... in completely different eras of computing. 15 years after GPO we now have DSC, addressing a new set of problems that did not exist when GPO came on the scene.
I like to keep things simple, so let’s make a matrix to compare the two. This comparison will be very thorough. If you are impatient, then skip to the end of the article for guidance on when to use either technology.
If you have ever watched the show Who’s Line Is It Anyway, you know that “everything is made up and the points don’t matter.” I am going to give a point to each product along the categories of comparison. These points are based on my own personal bias, evaluating the capabilities of each technology in the current era computing. Do you disagree? Let me know in the comments area below.
| Category | GPO | Point | Point | DSC |
| History | I started using Group Policy in 1999 on the released candidate of Active Directory in Windows Server 2000. This familiarity gives GPO an advantage as the incumbent in the room. It also has the advantage of years of feedback and refinement (and acquisitions).GPO was an evolution of registry.pol files in the pre-Windows 2000 days. | 1 | DSC began in 2014 with the release of Windows Server 2012 R2, earlier if you count preview releases. Currently it is approximately a “version two” product still gaining momentum with broad community support and feedback. You know what they say, when Microsoft hits version three it is ready for prime time. | |
| Domain Environment and Authentication | GPO requires an Active Directory domain for traditional delivery, authentication, permissions, etc. GPO can be delivered to Nano Server via new cmdlets that will import a policy backup, but the policy engine is not available.Outside of this you can manually configure local GPOs. | 1 | DSC works in both domain and non-domain environments. In fact, DSC does not even need a network. For one customer I created a thumb drive deployment script for field techs to build servers. It can be that easy. DSC can authenticate via any of the methods supported by WinRM/WsMAN.DSC now has resources to leverage the Nano Server GPO cmdlets. | |
| Operating System Requirements (including non-Windows) | Wow. GPO works out-of-the-box on any Windows machine since Windows 2000. That’s huge.Scoring this section is difficult. GPO is ubiquitous and easy. DSC is more powerful, more complicated, and not as complete. DSC will win this later with more refinement; for now I’ll call it a draw. | draw | draw | DSC requires WMF 4.0 or above. (You REALLY want to use 5.x or above.) This is available as far back as Windows 7 and Windows Server 2008 R2. Do you really need to support Windows 2000 any more? If you are still running native PowerShell 2.0 on Windows 7/2008 R2, why? Upgrade today. It’s a no-brainer. The support desk will love you for it.(The only exceptions here are some server-tier products that don’t take kindly to a WMF upgrade. Be sure to read the release notes prior to deploying across your entire data center.)You also will need remoting enabled on your machines, which is automatic on Windows Server 2012 and above. If InfoSec doesn’t like this, then send them to this article addressing PowerShell security.But DSC also supports Linux/Unix machines and network switches… barely. Back in 2014 we announced DSC support cross-platform, but it is a work in progress and not really viable compared to all of the more mature solutions in that space… for now. Keep watching here. Azure is driving this, and it will grow quickly, especially since PowerShell is now open source cross-platform. |
| Behavior | GPO prevents changes to the operating system. When applied to GUI settings, the options are grey and simply unavailable. That is pretty strong.Group Policy Preferences (GPP) allow greater flexibility of setting something only once or allowing it to be changed temporarily. | draw | draw | DSC reverts setting via ApplyAndAutoCorrect configuration mode. If something does get changed, then DSC can put it back. However, DSC can also imitate GPO by setting the exact same registry keys and values. This gives DSC the advantage of both prevention and correction.Like GPP, DSC also has an ApplyOnly mode for initial configuration that can change later. |
| Authoring | Beginning in Windows Server 2003 you could click through the Group Policy Management Console (GPMC) to find and configure settings. Over time the number of settings has grown to thousands, and you need to download a spreadsheet to tell you where to find them in the interface. If you really like GUIs, then GPO is for you. “Just keep clicking; just keep clicking.” | 1 | DSC is authored in PowerShell, a 10-year-old scripting language that is present in all Microsoft enterprise products. This does require learning new skills, but so does everything else in IT. 15 years ago you had to learn GPO; now you have to learn DSC.DSC gets the point here, because the power of automation is a force-multiplier when creating configurations.Move your existing server build scripts into DSC for the win. | |
| Workstation Management | GPO wins here, no contest. GPO is your tool of choice for all of the unique workstation configurations across the enterprise. The number of variables would be overwhelming to DSC. | 1 | Yes, DSC can do workstations. I have a customer using it to apply security baselines across the enterprise, where the settings are all identical. DSC would also be handy for kiosks, classroom computers, and other static configuration scenarios. | |
| Server Management | GPO ensures compliance with industry security requirements for companies all around the world. This works well, even for non-domain machines where you have to import security templates. | 1 | DSC can do all that, too, and even easier than GPO in those non-domain environments.If you want to manage all of the unique server configurations across the data center, then DSC is going to require more effort and/or paid tools. Stick with GPO and System Center there. DSC would facilitate a good baseline build of each server, though. | |
| Server Build | GPO can apply settings and even install software for a new server build, but friends don’t let friends deploy software with GPO. You might have to wait a bit for GPO to fully kick in, even using GPUPDATE. And there is that whole non-domain environment problem as well. | 1 | This is where DSC shines. It was made for server deployment… over and over and over. On-prem, cloud, you name it. Once the box is provisioned, DSC takes over inside the box to fully build it out. GPO was not intended for this and lacks the broad coverage of PowerShell under the covers. Yes, you could probably force GPO into this, but it would require a lot more duct tape.Recently I helped a customer deploy non-domain joined Azure scale set VMs with GPO security baselines migrated into DSC. It was a beautiful thing. All servers came up identically and completely secured… all with just a couple PowerShell commands. | |
| DevOps and Cloud Environments | The domain requirement encumbers GPO in the agile world of DevOps. In order to deploy the same settings across multiple domain environments you would have to duplicate GPOs in each. This is no trivial task. It also requires management of OU and group memberships outside the DevOps pipeline. | 1 | If you want to go fast with modern cloud deployments or DevOps Continuous Integration/Continuous Deployment (CI/CD), then DSC is your tool of choice. DSC can make dev / test / qa / prod all match, for real, and keep it that way.DSC can both build the server and then ensure the configuration going forward. GPO doesn’t have the coverage to compete here. | |
| Extensibility | GPO has always had the ability for you to create custom registry setting template files (ADM/ADMX). Advanced GPO customization involves creation of Client Side Extensions (CSE), which requires developer skills. | 1 | DSC is all about roll-your-own settings, and the customization extends well beyond the registry. You can configure anything that you can script in PowerShell. DSC wins here for ease of customization. | |
| Community Support | There may be a few custom items on the TechNet Script Center, but GPO is generally lacking in community extensions when compared with DSC. | 1 | Um. DSC wins this one hands down. From the beginning Microsoft has encouraged community contributions, and we have a rich GitHub and Gallery environment full of community content. This is one of the first times in history YOU have been able to work WITH Microsoft on the product. Our DSC resources are all open source and welcoming of your improvements and fixes. Of course the community is full of other code repositories as well. | |
| Third Party Support | GPO has a few vendors who have improved the functionality of the product over the years, and Microsoft acquired some of those to put in the box (ex. Group Policy Preferences, AGPM – Advanced Group Policy Management). The group policy MVPs Jeremy Moskowitz and Darren Mar Elia each have released a number of GPO enhancements as well. | draw | draw | Where DSC lacks in robust management features, third party vendors have stepped up. Chef and Puppet lend their enterprise readiness from the Linux side of the house to make DSC more administrator-friendly at scale.Also, Azure Automation DSC has a nice dashboard experience for managing configurations and nodes. Keep an eye on this space. |
| Delivery Method | Group Policy uses a pull model. The client logs on to an Active Directory domain. Then it begins a back-and-forth conversation to discover all the policies and download their respective files. “Got any jacks?” “Go fish”The advantage of Active Directory is that the Domain Controllers (ie pull servers) are highly available and replicate automatically. | 1 | DSC offers push and pull. Similar to GPO, DSC can download a setting template (MOF) and the files that make it happen (resources). This pull server can be set up for SMB, HTTP, or HTTPS transport. However, the in-box pull server feature is not highly available. The Azure DSC pull server is highly available for nodes both on-prem and in the cloud, but this requires additional cost.DSC additionally has robust support for peer-to-peer delivery of settings via push. | |
| Firewall | GPO uses an assortment of ports: SMB 445, RPCSS 135, RPC random ports | 1 | One port, encrypted by default. WinRM/WsMan 5985, optionally SMB only if the configuration leverages it. | |
| Scalability | Both GPO and DSC scale to thousands of machines. GPO wins for ease-of-use here. | 1 | DSC requires your own tooling and automation to scale. It is honestly much more work than linking a GPO to an OU. However, the automation and complexity of DSC makes it much more powerful than GPO.If you need to encrypt credentials in DSC configurations, then scalability gets much more complicated with certificate management. It can be automated, but it is more complex. | |
| How many can I have? | It is really easy to apply multiple GPOs to a single machine, and you can see the result using GPRESULT or RSOP. You might have to trace down conflicts, but there is a clear winner and clear rules. | 1 | DSC can use partial configurations to apply multiple, unique MOF files to a single system. However, this is not best practice. Worse, this is a tedious process of configuring the LCM with specific names and publishing those via push or pull. GPO wins here for ease-of-use. | |
| Raw Power | GPO owns the Windows registry and obscure security settings that are difficult to reach via scripting techniques. It is a solid work-horse in this area. And Group Policy Preferences extend configuration coverage considerably. However, it simply lacks the breadth of settings compared to DSC, especially when we factor in ease of user-extensibility. | 1 | DSC can do just about anything GPO can do, but it has the impressive force of PowerShell behind it. Anything you can do in PowerShell can be deployed to all your nodes. The logic and extensibility of scripting is a clear winner here. | |
| Timers | GPO applies every 90 minutes, plus or minus up to 30 minutes, on machines in the domain. The exception is domain controllers which apply GPO every 5 minutes.This interval is configurable in the registry from 0 minutes to 45 days, but this is not a common practice.We will give the point to GPO here for the smallest refresh interval, but setting a smaller timer with either technology can cause issues. | 1 | DSC has two timers: 1. ConfigurationModeFrequencyMins determines how often the box is scanned for configuration drift. The minimum value is 15 minutes. 2. RefreshFrequencyMins is how often it polls the pull server for a new configuration to apply. This minimum is also 15 minutes.These values must be a multiple of one another.Whatever you do, don’t put the same setting in both GPO and DSC. The timers will battle back and forth resetting the same value all day long. There is no automatic conflict detection between the two. | |
| Command Line | GPRESULT and GPUPDATE are the most common commands. GPO also has a PowerShell module full of helpful commands like Invoke-GPUpdate and Get-GPResultantSetOfPolicy. The module is available when you install GPMC. However, GPO loses a point here, because the PowerShell cmdlets only work with registry-based settings of policies and preferences. When you try to script individual GPO settings you will hit this wall pretty fast.To be fair, there is a decent set of cmdlets for working with whole policies (links, inheritance, backups, permissions, etc.). | 1 | DSC has a vast array of command line support, since it was borne out of PowerShell:Get-DscConfigurationGet-DscConfigurationStatusGet-DscLocalConfigurationManagerRemove-DscConfigurationDocumentRestore-DscConfigurationStop-DscConfigurationInvoke-DscResourcePublish-DscConfigurationSet-DscLocalConfigurationManagerStart-DscConfigurationTest-DscConfigurationUpdate-DscConfiguration | |
| Logging | Both GPO and DSC have their own Windows Event Logs. | 1 | I am going to give the point here to DSC, because of the xDscDiagnostics module that does some cool collation across all the log sources. Also, DSC has a second logging mechanism to view with Get-DscConfigurationStatus, and this data is available centrally in Azure Automation DSC or from the in-box reporting/pull server. | |
| Troubleshooting | GPO has a generous assortment of event logs, text log files, and command line utilities for troubleshooting.GPO cannot do the live debug like DSC, at least in a user-friendly way. Well, I suppose you could attach a Windows debugger to troubleshoot GPO. Do you know anyone who can do that (besides people at Microsoft)? | 1 | DSC has the dominance in command line and logging as discussed above, but it also has the ability to live debug remotely with no special tools as a configuration is applying. Now that’s cool! | |
| Version Control | Version control and release scheduling for GPO requires an additional license for Advanced Group Policy Management (AGPM). | 1 | Since DSC is configuration-as-code, any source code management tool will work. Popular options are Visual Studio Team Foundation Server (TFS), git-based solutions, and other third party products. I’ll give the point to DSC here, because some of these are free. | |
| Updates | GPO combined with WSUS is an effective patching solution for many organizations. This is an established pattern that works well. “If it ain’t broke, don’t fix it.” | 1 | Yes, DSC can apply patches or updates using the xHotfix resource. However, you really don’t want to write all of that in configuration-as-code. Even though you could automate it with scripting, it is less than ideal. Stick with your other patching solution.The only exception here would be doing a new server build. Sometimes there are certain patches you might want to lay down first before proceeding to configure the box (like WMF 5.1). One-off patch scenarios like this are well-suited to DSC. | |
| What-If Scenarios | GPO can use RSOP modeling to determine “what configuration would this user and computer combination get in these OUs?” | 1 | DSC has a similar feature usingTest-DscConfiguration-ReferenceConfiguration. The advantage goes to DSC for the ability to scan multiple machines simultaneously and return object-oriented data for easy bulk reporting. | |
| Reporting | How would you produce a list of machines that were in or out of compliance with GPO? There is RSOP and GPRESULT, but those are quite tedious to view the entire environment. Perhaps you have a third party product to do this, but this visibility across the enterprise is not easy for GPO. I guess you could use the RSOP cmdlets if you wanted to build your own solution. | 1 | Enterprise-wide compliance reporting for DSC is marginally better. The current in-box reporting server leaves a lot to be desired (like high availability), and the Azure Automation DSC solution costs money. However, you can script your own reporting solution using a number of DSC cmdlets like Test-DscConfiguration, Get-DscConfigurationStatus, etc.I have heard of one person who built their own SCOM management pack for DSC. Other customer may leverage a System Center script to collect and report this data.DSC has a nice object model to clearly identify which parts of the configuration are in and out of desired state. | |
| Long-term Microsoft Direction | Many people wonder if “GPO is dead”, but we are still releasing new policies for Office and Windows with each subsequent version. I do not expect this to go away any time soon. | 1 | Microsoft is making significant investments in DSC and it is used widely across our modern offerings. This is not a passing fad. Learn it now. It will be here for decades to come. GPO, only time will tell. The PowerShell DSC team at Microsoft is full of ex-Group Policy product people. Maybe that is a clue. | |
| Point Tally | Group Policy | 7 | 16 | PowerShell DSC |
Summary Recommendations
Look at the score! Do these points really matter? Maybe. Depends on your goals. Clearly I am biased towards DSC. Why? Growth mindset. Stay locked into the old ways of GPO, or learn the new ways of DSC. Your choice. Tell me what you think in the comments area below.
At the time of this writing each technology has its own pros and cons. Here are the scenarios where I see each as most useful:
| Group Policy | PowerShell DSC |
|
|
If you are the typical enterprise environment, don’t rip and replace GPO with DSC. If you are building green field, doing DevOps, or moving to the cloud, then start using DSC right away. I recommend standard DevOps advice in every case: start small with DSC in a limited scope, learn it, get some early wins, and then build out the span of control as your experience and the product grow.
If you still have not learned PowerShell, then you are at a severe disadvantage in your career. PowerShell is not a “new thing”; it is 10 years old. Similarly, Desired State Configuration is three years old now. This is not one of those “wait and see” technologies. It is here to stay. Learn it today.
Resources
There are several places to learn about PowerShell Desired State Configuration online:
- Start here: https://microsoft.com/powershell. This page includes links for documentation, WMF download, etc. The documentation includes many code samples for getting started.
- Microsoft Virtual Academy has several good videos for training on DSC.
- Channel 9 also has many good training videos.
- Follow #psdsc on Twitter for all the latest news and blog posts. Connect real-time with people using DSC in the real world.
Comments
- Anonymous
February 28, 2017
Another great post Ashley I generally agree with your scoring, recognising that SCCM/GPO and DSC shouldn't be considered as competing solutions. As a product owner for MS infrastructure services I lean towards DSC because it is easier to version control and ensure consistency is part of my server build and consistency is within my control. I can't really think why you would try to manage a dynamic client machine with DSC, this is a much better use case for GPO / SCCM. - Anonymous
February 28, 2017
Nice post! I disagree with the updates section, it's just as easy have machines apply a dsc config for wsus, without too much effort. I would call this a win for dsc, or a draw at worst. - Anonymous
March 01, 2017
Thanks Ashley for this very extensive and instructive post! It's great to get your feedback from the fields. I think this post will be authoritative for a while and this is a good thing, furthermore it lays down most of the questions (and answers) people have, including me! I agree with you on most of the points even if I'm deeply convinced that the GPO days are numbered. Why Microsoft would keep these two technologies on the long run?But just like you, I may be biased because of my mindset ;-)Thanks again! - Anonymous
March 03, 2017
Great post. - Anonymous
May 01, 2017
Great Post. Quesiton if Security Compliance Manager was a source for new or updated baselines for OS etc. What is the source for this in DSC? thx - Anonymous
May 25, 2017
Bad link: https://blogs.msdn.microsoft.com/powershell/2017/02/17/managing-security-settings-on-nano-server-with-dsc/ - Anonymous
October 30, 2017
Great post, thank you! - Anonymous
September 10, 2018
How does GPO precedence work in relation to Desired State Configuration? Would GPO take precedence over DSC or would DSC take precedence over GPO?- Anonymous
September 12, 2018
Hello MGWhite,To quote Jeffrey Snover... "Running GPO and DSC on the same settings is like two cats in a trashbag. Don't do that." There is no conflict resolution built in between these two technologies. That is on you to manage the conflicts and avoid them.Cheers,Ashley
- Anonymous
- Anonymous
September 20, 2018
Ashley, thank you for the great post! Can you recommend a product that may enable me to utilize GPOs for establishing security baselines for servers and roles (i.e. CIS benchmarks), and combine this functionality with DSC for subsequent configuration changes with conflict detection and resolution capabilities?I am simply not aware of any reputable sources for .mof security baselines and will be much obliged if you can point them out to me.