I was reading Paul Thurrott’s most recent column on the Windows IT Pro Magazine website today. The column ostensibly talked about naming of features and products in Windows 8, but at the bottom, was this interesting tidbit,
“Blurring the lines in a way that’s almost diabolical, Microsoft recently announced that it’s introducing yet another form of PC/device management that will somewhat straddle the line between device-based management through EAS and full PC management with Active Directory/Group Policy. It’s called … actually, I don’t know what it’s called because Microsoft has yet to provide a name for this technology! But it consists of a System Center-based “management infrastructure” in the cloud, a Windows RT/ARM-based agent, and a Metro-styled “self-service portal” by which enterprises will be able to securely deploy Metro-based apps to these clients. “Paul was talking about the recent revelation that the upcoming Windows-on-ARM (WoA), at least so far (it is still in Beta after all), will not be joinable to AD, and of course, will not process Group Policy. This continues a trend that Microsoft has been following with respect to configuration management of Windows systems–blurring the lines of responsibility that each of the various configuration management solutions they provide serve. Let’s take a look at all the ways that Microsoft provides configuration management today:
- Group Policy: My favorite of course–Group Policy has been around since 2000 and requires AD to take full advantage of all it’s features. Group Policy handles everything from software deployment (albeit weakly) to security configuration, desktop lockdown, browser lockdown and drive/printer mapping, and that’s just the short list.
- System Center Configuration Manager (SCCM): SCCM (nee SMS) has been around for a long time–since about 1994– and has always been the go-to tool for enterprise software distribution (i.e. deploying software to Windows devices). More recently SCCM continues to morph and blur the lines between it’s sweet spot and what Group Policy is good at. Of course, Group Policy is “in-the-box” and SCCM costs additional money, but with the recent release of SCCM 2012, the previous read-only, desired configuration management (DCM) feature now also has the ability to set (i.e. write) the kinds of settings that most shops manage with Group Policy.
- Windows Intune: Is a cloud-hosted endpoint monitoring, software distribution and configuration management solution for small and medium-sized businesses, that also blurs the lines of responsibility in terms of what Group Policy is used for and what Intune does. The nice thing about Intune is that it’s not tied tightly into AD, and so can handle managing endpoints that aren’t necessarily under AD management (or aren’t on the corporate network, such as roaming PCs). Interestingly Intune uses a completely different mechanism for configuring Windows than does Group Policy.
- As yet unspecified WoA Managment Infrastructure: We don’t know much about this yet, except what folks like Paul and Microsoft themselves have written. Will it be a self-hosted version of Intune? Add-on to SCCM? Something else? Suffice it to say that if you’re deploying WoA devices in the future, you may need something besides what you’re doing now (especially if Group Policy is your configuration management tool of choice now).
The bottom line here is that, depending upon your needs and your targets, you could have up to 4 different mechanisms for doing configuration management in Windows. Choice is good, right? Well, yes and no. The problem is that each of these solutions (at least the ones we know about) keeps it’s own idea of what desired state is. Each one describes configuration differently and each one keeps track of configuration state on endpoints differently. This means you have to make some very conscious choices about what Configuration Items (CIs) you will manage with each mechanism that you use in-house, or, restrict the mechanisms you use. Why?
Well, the worst case scenario is that you have multiple configuration systems managing the same CIs. I can envision a scenario where the group that is managing SCCM decides to implement a DCM baseline on all your Windows servers that enforces a security setting to a particular value that is in conflict to what you happen to be setting via Group Policy. And then each time GP refreshes, it undoes the DCM baseline value, which DCM then comes along and fixes, and so on.
The bottom line here is that over time, it is likely you will have multiple configuration management capabilities depending upon the segment of your Windows environment. As a result, you’ll need to think about “domains of configuration management” where a particular technology is only responsible for the CIs that it is good at managing and for the devices that it is best suited to manage.
Where is Windows Configuration Paradise?
Where I’d like to see all of this go, is that the underlying plumbing for describing, enforcing and reporting on configuration within Windows becomes the same, regardless of whether it’s SCCM, Intune, Group Policy or any other mechanism. Once you have that, then the management of conflicts can become inherent in the plumbing rather than the responsibility of the tooling (i.e. SCCM or Group Policy, etc.) and you can use the tooling that is best for your scenario. Each of the current mechanisms has strengths and weaknesses. Wouldn’t it be cool if it didn’t matter which tool we used and that we could mix and match or “trade up” over time without re-work? I think so. What do you think?
Darren