Welcome to Day 75 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.
In this post, I will talk about the capabilities of System Center Configuration Manager 2012 R2 (SCCM) versus PowerShell DSC for configuration management. The questions I’ll speak to include how these two tool complement one another, how their native functionality can be extended, where they overlap and where each fits best today.
In this post, we will visit
- Out-of-box (OOB) Functionality
- Use Cases (Desktop and Datacenter)
As with most Microsoft enterprise technologies in the world of agile development and the rapid release cycle, I expect the situation will evolve quickly.
Out-of-box (OOB) Functionality for Configuration Management
Both SCCM and PowerShell DSC have configuration management capabilities, but how they work is different as you would expect. Let’s take a look at each.
The Desired Configuration Management (DCM) feature in SCCM 2007 was renamed as Settings Management in SCCM 2012. Compliance is evaluated by defining a group of settings to be monitored, called a configuration baseline. That baseline contains individual configuration items that you want to evaluate and settings and rules that describe the level of compliance you must have. These can include evaluation of registry settings and values, T-SQL, LDAP and WMI queries, or even the results of Microsoft scripting languages like PowerShell, VBScript and Jscript and more. You can configure correction of deviations on an item-by-item basis, meaning you may have one configuration item in a baseline that auto-corrects the deviation and other items that simply alert.
In SCCM 2007, Microsoft released several pre-packaged baselines in Configuration Packs (see the list here), which also work in SCCM 2012. However, they have not released any in a few years, and now the most expedient method for quick configuration baseline creation is through the Security Compliance Manager Solution Accelerator, which enables you to create baselines based on OS and AD group policy settings in a few clicks.
This functionality comes in the SCCM Administrator Console, providing a good UI and reporting on compliance with baseline settings. You also have the capability to configure SCCM to tell the client to resolve any non-compliant settings.
As you know if you have been following the 100 Days of DevOps series, PowerShell DSC leverages PowerShell modules and mof configuration files, but has no UI. There are more than 100 resources as of Wave 8. DSC extends beyond the more simple settings focus of SCCM to enable configuration of entire server roles and features, and distribution of content in some cases, such as web sites, as demonstrated in Day 30: Enabling Highly Standardized Web Farm Configuration with PowerShell DSC. While you could do this in SCCM, it would require using the script option and a lot of custom script writing. In this sense, DSC feels more powerful than SCCM in datacenter scenarios, where role-specific configuration management of servers is key.
Settings related to corrective action are universal in DSC. You set behavior to monitor and correct deviations, monitor and log deviations, or simply log deviations.
Use Cases (Desktop and Datacenter)
You can apply SCCM baselines on any Windows computer with an SCCM agent, so it has reach to both the desktop and datacenter. SCCM does not provide this feature for UNIX and Linux systems, making it an incomplete solution for the datacenter. SCCM delivers this support for the Mac platform as well.
Since PowerShell DSC requires presence of the PowerShell DSC feature, DSC feels like a datacenter focused feature today, though there is no reason it cannot be used at the desktop. Another bonus with DSC is that it includes Linux support, though Linux support does not include DSC Pull Mode, making it less powerful in enterprise scenarios. There is no Mac support in DSC at this point in time.
Both SCCM and PowerShell DSC are extensible. Which is more easily extended to support your needs really depends on your skillset.
SCCM allows you to create configuration items a combination of the SCCM Admin Console and script, command or query-based means, like PowerShell, VBScript / JScript, T-SQL, and more. If you are a seasoned SCCM administrator with light Microsoft scripting skills, this likely feels like an easier extensibility option.
PowerShell DSC requires you extend native capabilities by writing new PowerShell modules. If you are a strong, seasoned PowerShell scripter without much SCCM experience, this probably feels like the more flexible and intuitive option.
I don’t see a clear winner here. It really depends on your requirements, your skillset, your use case and what pre-created examples you can find on the Internet. It is totally plausible that you may use the two together in the datacenter, though I think the same is less likely at the desktop at this point in time.
That’s all for this installment. I hope you are able to follow along as your schedule allows, building on your previous efforts to get yourself ready for the world of enterprise DevOps.
To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.