DSC vs. GPO vs. SCCM, the case for each.

EVA Post.pngThis is the showdown, guys. In the world of Windows tooling, which tool do we use?

In this post, we’ll cover the general benefits and pros and cons of SCCM vs DSC, and also consider GPO and MDT as well.

Plenty of people have offered their take on this, including my sempai, Declarative Configuration trailblazer and King Chef of the Realm Steven Murawski. I completely respect his opinion on the matter and encourage you to read it.  Murawski – DSC Which Direction Should we Go?.

My view differs slightly from my peers in that my background is in Enterprise Client Management, and I’ve been deploying SCCM since 2011 for customers into the tens of thousands of desktops and servers.

However, I also love to code, so maybe my perspective will help the concepts gel for you.

In my mind, this debate is not really about which tool is the one-true king to use in all cases, but rather about highlighting the strengths of each and noting when they should be used.  I’ll also describe how you deploy operating systems using each product as well.

It’s all about the evolution of tooling

First the Earth cooled, then we got GPO

For all practical purposes, the first true large scale management tool we had for Windows systems in the modern era was Group Policy, or GPO as it is commonly truncated.  This stemmed from Local Security Policy, which is a fancy GUI to control system settings via special registry keys which are locked down from general user editing. Local Security Policy could be shared among systems in a Workgroup which was a big improvement from setting the same configuration on each system.

Then with the advent of Active Directory Domain Services, we gained the ability to organize users and computers into a hierarchy and tier the application of these same policies to craft very granular configurations of machines based on who is logging on to which computer, and where those objects were placed in the directory. Join a machine to a domain, and bam, it gets the default policy, and then you can move the computer to the right folder (or organizational Unit, OU) to put the right amount of lock-down on the node.

People used it for everything, including installing software! It was later made possible to have multiple GPOs affect a computer like you can with collections in SCCM, using WMI Filters which execute on the machine to determine which GPOs should apply, but it’s much harder to get right, and there’s no easy mechanism to view which computers would be affected.

A GPO by any other name is a registry key…

The thing about GPO is that you need to have Active Directory in place.  This means Infrastructure, and suddenly, when all we wanted to do was configure certain settings across our environment, we’re now staying up late at night worrying about things like disks and server uptime and we now need a Sysadmin to run it all. Each of these steps in complexity is adding cost to the company which might not do much if anything to increase earnings.

Where GPO gets murky is that it’s kind of onerous when trying to assign multiple different sets of policy to machines based on many different conditions (imagine multiple departments, with different applications and settings for each). Additionally, it ain’t exactly quiet.  In big organizations who haven’t optimized their application of policy, it’s not uncommon to see multi minute long log in times, and unconstrained Windows Update installs rebooting computers during the middle of the day.

Mess up your GPO and people will be seeing this

In my day job, I still see people struggling with Group Policy, years after its release.

GPO, what is it good for?

With an Active Directory Domain, you can configure almost anything about the settings of Windows Computers, like what users are allowed to do, who is permitted to logon, setup Windows Updates and even install software. And if you have more than ten computers, you probably already have a Domain, so you kind of ‘get it for free’.

Group Policy is THE tool for configuring user experience and locking down PCs.

GPO is AWESOME for configuring desktop applications, like Microsoft Office and Chrome, and for configuring the user’s experience.

When to avoid GPO

It’s not good for installing software, it’s intrusive to users and if you mess up, it will be very public, potentially causing long log in times.

The very nature of hierarchical tiering of configuration also leads to great complexity. If you want to apply certain user settings only when they log on to particular machines it gets even harder. There are plenty of solutions, but that is some hard stuff to get right.

Additionally, it’s not great for configuring or installing server features, nor is it really made to ensure features and roles stay installed, like ensuring that IIS is installed and stays running. Etc

It’s also not lightweight, as you’ll need Domain Controllers and probably need people to run them for you, and if your organization is large, you’ll need to worry about network topology as well.

I only have AD and GPOs, what do I need to start imaging?

There is an imaging story for native Active directory tools and it involves using Windows Deployment Services to install a sysprepped image using PXE booting. This is not a good developer experience though, as we have to spend a lot of time with complex tools to save all of our imaging settings into an image, and can’t tailor the image to fit computers in certain regions, for instance.

Comparatively, SCCM and MDT allow us to we import an image from a Windows install disk and then run dozens of individual steps which are customized based on the target machines platform, model, office location and other factors. The sky is the limit.

GPO is hard, enter SCCM

To serve other configuration needs, Microsoft released their product ‘System Management Server’, which was eventually rebranded as System Center Configuration Manager.

Whereas GPO is something we get ‘for free’ when computers are a member of a domain, SCCM depends on an agent being installed on every computer you want to manage.  Big difference.

This tool adds an extra level of abstraction to Active Directory, sniffing for users and computers in a domain and then allowing an SCCM admin to organize them into collections.

These are one of the defining characteristics of SCCM, these groups which can be either manually created in a drag and drop fashion, or created automatically based on common factors, like a computers distinguished name (good for organizing based on active directory OU), or users department, OS Version, etc.

If you can think of a common factor of a group of systems or people in your firm, you can target them for applications or security policies using SCCM.  Collections solve the difficult problem of assigning policy based on logical placement of computers and users within AD.

SCCM excels with bare metal

You also gain the option of having cradle to grave control over systems too, as SCCM supports laying down an operating system to bare metal (industry term for brand new computers).

SCCM is easily the best imaging experience you can get with Microsoft tools. I’ve tried the other options as well, like Dell Kace (which is actually pretty good, if limited in comparison to the power of SCCM), but they’re simply not as good as SCCM.

The king of software deployment and user migration

If you’re upgrading OSes, deploying Windows Updates or software, SCCM is king.  You have limitless control over how to install applications, what the user sees and doesn’t see, and most importantly of all, none of your configurations will impact their login time like GPO does.  SCCM is the best at what it does.

Probably not the tool for ensuring compliance, however

SCCM DOES have a module called Desired Configuration Management, which kind of sounds like Desired State Configuration, but it relies on machines having an agent, being in a domain, etc. While you can ensure compliance with SCCM, it is a complex answer to a complex question relying on the SCCM admin to write complex tests to check for conditions and also provide remediation steps as well.

It works, but there are much easier ways to ensure system compliance than rolling SCCM.

SCCM is not lightweight

SCCM completely depends on Active Directory.  All site servers (all SCCM servers) must be members of a Domain, full-stop.

This means SCCM actually adds more complexity to AD.

You need your whole AD Infrastructure, plus at least one or two likely hefty servers to run SCCM too.  There is a lot of complexity in SCCM and a quick Google will show thousands of posts on the web of people asking for help with it. You’ll also need agents installed on every system you want to manage, need to pay attention to the network topology of your organization.

Finally, you will also need to be careful in your configuration, or you could nuke your whole company.

Don't do this to your environment!
Don’t do this to your environment!

Seriously, people have paved over their entire infrastructures before with SCCM.

I make my living helping companies recover from SCCM disasters or get started using it the right way, and so do hundreds of my peers. It is not easy.

DSC = Easier, safer, more lightweight configuration

So long as you’re running newer operating systems, we do have another option.

Rather than needing agents on machines and infrastructure like AD (which, frankly, is very much a typical Operations or Infrastructure approach to solve the problem of machine management), we have something wholly new, birthed from our developer brothers on the other side of the glass.

I’m not going to re-explain DSC here, as I’ve already done it in a previous post, and others have as well , but there is a LOT of excitement in the industry about this notion of treating our servers like cattle. One of the biggest mobile carriers in the world operates on this premise:

Servers only ever exist in a given state. If they deviate or we make changes, we refactor and redeploy. DSC drives it all and the machine will be up and running on a new OS, with data migrated in a matter of minutes.

Paraphrased from Jason Morgan in his awesome talk on Monitoring in the Enterprise at The PowerShell Summit last year.

Microsoft was very much a ‘Fast-Follower’ in this regard, jumping onto the trail that folks like Chef and Puppet blazed, all chasing this idea of simple to read, text-file driven configuration management.

Core Benefits of DSC

In my mind, DSC excels in a few use cases:
• You need lightweight configuration for dev/test
• You need to be able to revert to old builds or test new builds quickly, with A/B testing
• You’re primarily interested in Server Management
• You want a system to be Self-healing
• You’d rather have a one-page Build config instead of a 40 page ‘runbook’ of screenshots and aren’t afraid of code.

Lightweight

DSC only requires that your target operating systems be capable of running PowerShell v4 for most features. There is no domain pre-requisite, nor do you need to worry about imaging machines. It lends itself to environments with spend in virtualization, because you can easily build a template machine on a workgroup, pre-create an admin account and save it as a template.

Need to spin up some new test machines? Fire off a few templates and then describe what you want them to do in your DSC Configuration and Apply-DSCConfiguration. After maybe one or two reboots, you’ll be good to go. No lengthy builds or service requests, process flows. Quick, fast and in a hurry.

Configuration Reversion

Since you’re describing the full build-out of your application or Service in a handfull of DSC files, and rebuilding these machines is possible very quickly, you’re now trending towards checking in your server builds themselves as artifacts in your code versioning system. No longer do you need to spend an hour or five clicking your way through wizards to get a machine or upgrade ready. Instead, you can swiftly code-test-revert-repeat until your little snowflake is perfect.

Use the built-in DSC Resources to spin up domains, users, SQL, IIS, or roll-your own scripts for the last mile of config and just pull down the version of the environment you want and hit f5.

For developers, DSC is a godsend. You can ensure that your dev/test/prod environments are the same and avoid those awkward all-IT bridge calls where people try to figure out why a simple Exchange DB Update took down e-mail for hours.

Server Management

DSC CAN manage desktops. You can also pound nails with your screwdriver.

I must say that DSC on the desktop is a bit of an afterthought, and if you want to deeply provision or lock-down your desktops, you’ll end up resorting to Local Security Policy or Group Policy, because GPO has pretty much covered everything you could ever need for desktop configuration.

Self-healing

The really beautiful thing about DSC is that when you tell a machine to ensure that something is there, it’s going to do so, and KEEP doing so. DSC is wonderful for controlling configuration drift in your environment. By default, your machine is going to verify that it is in the Desired State every fifteen minutes. This is glorious, and means that your end-users really can’t break things too badly, most of the time. If they do, DSC will heal itself in less time than it takes to go grab a coffee.

Infrastructure as Code

For one, you get to say your infrastructure is code. I mean, how cool is that?!? It’s like the future!

This came up when I googled 'infrastructure as code .gif'
came up when I googled ‘infrastructure as code .gif’

For another, within about a minute, pretty much anyone can figure out what this is going to do:


WindowsFeature ADDSInstall
        {
            Ensure = 'Present'
            Name = 'AD-Domain-Services'
            IncludeAllSubFeature = $true
        }

        WindowsFeature RSATTools
        {
            DependsOn= '[WindowsFeature]ADDSInstall'
            Ensure = 'Present'
            Name = 'RSAT-AD-Tools'
            IncludeAllSubFeature = $true
        }

This will ensure that a machine has AD Domain Services installed (basically prepping it to be a domain controller) and then make sure the RSAT tools are present as well. To walk someone through getting this configuration working in words, you might easily have a page (or three, if you’re including screenshots)

I’ve got SCCM, should i replace it with DSC?

If your company already has SCCM installed, I would direct you to make use of the investment your organization has made there, but keep in mind the opportunity to reduce complexity in your environment with Desired State Configuration.

You should consider the strengths of DSC (easy transition from dev to prod, easy rollback, store configurations in a repo, 15 minute or faster self-healing) and ask yourself these questions:

• Instead of assuming I need AD, SCCM, and GPO, what’s the minimum viable configuration I can do for this service?
•  What if we didn’t have Active Directory, could this system work without it?
•  Are there any features of this configuration that would benefit from being enacted and stored as Source Code, rather than an inherently wasteful ‘click-click-finish’ configuration?

Closing things out here

 

So I hope I’ve summed up the relative merits of each tool, and when to use them. If you think I overstate, or understate your favorite tool, let me know in the comments below.

Advertisements

28 thoughts on “DSC vs. GPO vs. SCCM, the case for each.

  1. skatterbrainzz February 25, 2016 / 1:51 pm

    Thank you! This is a good, easy-to-digest comparison. I think the takeaway is that each option is a tool in box, and knowing which tool fits the job is what matters most. Too often it seem someone grabs the wrench to pound nails.

    • FoxDeploy February 25, 2016 / 2:38 pm

      Yep! And some types of people gravitate towards certain tools too, for instance, in the Infrastructure side we tend to get attached to servers and give them cute names. Meanwhile, our development friends have machines in aws with dynamic names! For them, build and configuration normally happens automatically.

      I think we’ll see more and more of this approach in the enterprise world as time goes on.

    • Brandon Padgett February 21, 2017 / 8:36 pm

      It’s not always about knowing which tool does the job best. You may know $tool is the best tool for the job, but if your organization doesn’t have access to it, then you have to do the best you can with the tools you have. Sometimes that might mean you have to get creative at using a wrench.

      • skatterbrainzz February 22, 2017 / 9:04 am

        This is very true. Constraints are always a real factor.

  2. Billy February 25, 2016 / 2:19 pm

    Good post, why not all three? DSC for servers, and GPO and SCCM for clients.

    Also if GPO is hard, then SCCM is a 15 tile 7 sided rubix cube. Based on the clients i’ve been to and the state the environments are in. There simply isn’t enough quality people to run these tools.

    • FoxDeploy February 25, 2016 / 2:40 pm

      A good mechanic knows how to use every tool in his toolbox. If you saw him pounding nails with a screwdriver, you’d probably start questioning other aspects of his work. (And what the heck is he doing using nails in my car?!)

      We should all aspire to be good tradesmen, and that means staying on top of new tools as they become available

  3. Fabien Dibot February 25, 2016 / 7:56 pm

    Sadly this is only a Windows server point of view 😉

    And with containers, configuration management, continuous integration, etc… You miss a whole part of what is infrastructure now. But i agree GPO/SCCM will survive for desktops, but in modern IT, they’re not fast/scalable enough to survive against DSC, Chef, Puppet, Ansible, Rundeck, etc

    My 2cts

    • FoxDeploy February 25, 2016 / 8:16 pm

      Good point! Once I see how containers are used in the enterprise (haven’t seen it yet because none of my costumers make software) I’ll understand how to include them!

    • FoxDeploy February 25, 2016 / 9:10 pm

      Such high praise, thank you very much Francois!
      !je vous remercie!

  4. John Bruett February 26, 2016 / 5:55 am

    As always Stephen a fantastic article.

  5. John Bruett February 26, 2016 / 5:57 am

    Great article, as always Stephen!

    • FoxDeploy February 26, 2016 / 9:00 am

      Thank you for the kind words!

  6. @ryanyates1990 March 3, 2016 / 11:10 pm

    Great Article from the view of those that may be working out which direction for their organisations to head in with the choices they have however I (again) have a slightly differing view.

    If an organisation haven’t yet deployed SCCM then it becomes less of a desire to add more complexity to their environment however there is with the new features in Windows 10 especially the ability to Domain Join a device to Azure AD means that, again, in my opinion, the whole tables have changed and I would be more suggestive of investing in Intune (for new mobile first devices) alongside SCCM (for existing and critical devices) n the Desktop space.

    However, again in my opinion, in the Server Space – DSC really makes the most sense for the reasons that you specify in this and other previous posts – the main winning point for me is the readability with a closely followed ability to stage your configurations in small changes when Server Admins work in a more Developer mindset.

    Source control & Unit testing are still massively alien topics to most IT Pros – and I hope that DSC will help be the turning point.

    That’s not to say that GPO should wither and disappear – however I don’t think its a strong contender going forward – again for the frustration points you’ve listed above.

  7. JD Eger July 18, 2016 / 3:20 pm

    This is a fantastic article and exactly what I was looking for. I’m just scratching the surface with SCCM – AD and GPO Sys admin for years. I’m at a new opportunity trying to make a better informed decision and this was the article I needed.

    • FoxDeploy July 18, 2016 / 3:31 pm

      First off thank you for taking the time to write to me. I’m really happy the article was helpful to you, I know that I learned a bunch formalizing my knowledge on topic to write this. I’ve got another in the works on sccm vs intune, so stay tuned!

  8. DoubleA October 6, 2016 / 6:42 am

    Good article… however I’m struggling to find an answer to what happens in an environment that is just starting to use SCCM, and it is discovered that SCCM can configure many of the same things as GPOs… more specifically stated, which one overrides if both are present? Both GPOs and SCCM can configure things like your WSUS server, folder redirection, or offline files etc. If those are already being configured by GPOs and then it is also configured in SCCM so that a particular target is receiving both… which one wins if there is a conflict?

    Thanks!

    • FoxDeploy October 8, 2016 / 11:33 pm

      GPO always wins if there is a conflict. In fact, one place you can see this is in the logs for sccm for windows update.

      If you have a GPO in place specifying an internal update location, you’ll see errors in the sccm log when it tries to change that value.

      GPO wins because it writes settings to special registry keys with special permissions.

      • DoubleA October 9, 2016 / 7:53 am

        Thanks very much for the reply! Funny I did in fact find out the answer about the day after I asked the question. 😉 Turns out over and above what you stated that all SCCM settings are written as local policies, which of course are always overridden by GPO. Thanks again!

  9. Scott Stephenson October 19, 2016 / 11:18 am

    Very good article.
    In the section: “Probably not the tool for ensuring compliance, however”

    You wrote: “but there are much easier ways to ensure system compliance than rolling SCCM”
    Please post some examples of what you believe are good overall compliance apps. Especially for a health care provider if possible.

    Thanks

  10. sharkrit December 16, 2016 / 10:53 am

    Thank you, this is very good Article. What about DSC vs Ansible would you recommend?

    • FoxDeploy December 16, 2016 / 11:39 am

      DSC is a very bare bones way of achieving what you can do with Chef and other configuration management tools like Ansible.

      Both chef, Puppet and Ansible provide a layer of tooling which makes working with configurations much easier than the psnative method we get in DSC.

  11. Brandon Padgett February 21, 2017 / 7:51 pm

    “Instead, you can swiftly code-test-revert-repeat until your little snowflake is perfect.”

    Lol, nice.

  12. Brandon Padgett (@BrandonPadgett) February 21, 2017 / 9:43 pm

    Liking the new Banner! I still think you should totally start making them for me.

    I’d like to see the numbers comparing companies who’s core business is and isn’t web based. You hear a lot of vocal people and companies saying that DSC or forms of other configuration management are the future, but it is coming from a very narrow perspective. Those environments I would argue are the minority in the grand scheme of things. There is no one or the other, but which tool works best for your needs.

    DSC is not going to replace SCCM or other client management solutions. They were designed for two completely different roles that aren’t mutually exclusive. I still think they went a little overboard and created a little too much controversy with some of their claims, which let’s be honest, were fueled by Azure. Maybe one day they will improve DSC for desktops, but that just doesn’t make sense to me. I just can’t see them killing the revenue that SCCM brings in.

    With that being said, should you learn DSC? Heck yeah! We need to think outside of the box here. There are things for even desktops that DSC is better suited for than something like SCCM.

    If your SCCM client gets borked, you might be left in a bad spot. DSC is lightweight and comes baked into the OS, so it is perfect to work as a watchdog type service to ensure your critical services and applications are always running and functioning the way they are supposed to. There always seems to be those services or apps that always break in specific ways. Using DSC to monitor things like ports, services, errors in logs, event logs, corrupt files, broken installations etc and then triggering the remediation immediately is a very big strength. I don’t think i’ve ever encountered a “client” or app that hasn’t broken or stopped functioning in some way, so having a builtin, lightweight way to monitor and remediate those is very compelling.

  13. alistg February 27, 2017 / 4:38 pm

    Would be nice to also talk about where these fit in :
    – MDM / EMM
    (and associated tools – Intune, MI Bridge etc)
    – OMS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s