My Initial Impressions of Desired State Configuration (DSC)

Adam Bertram

Adam Bertram

Read more posts by this author.

I’ve heard of DSC and have very briefly read up on it previously but this is the first time I ever let myself just digest the topic and play with it a little bit. I thought a non-technical, review blog post might help others brand new to DSC. I’m not going to go into what DSC is and what it does. �There’s plenty of content already out there for that. I am, however, going to give you my own interpretation of the technology and how I see this going in the near future.

SCCM already has some “DSC-like” properties.

As an SCCM admin, I immediately compared this to SCCM’s Compliance Settings and SCCM 2012’s application model. In SCCM RTM, Compliance Settings was referred to as Desired Configuration Management. Sound familiar?

In regards to the application model, there are numerous references in the documentation, WMI classes, and other places that refer to the “Desired State” nomenclature. The technology that DSC and SCCM’s Compliance Settings and Application Model’s requirements, detection methods, and global conditions are uncanny. It’s clear that DSC was not just married to Powershell but rather the “desired state” technology seems to have been created and adapted by numerous Microsoft products.

DSC is still very early

It’s clear the DSC is in its very early stages. It’s less than a year old and has some misc little gotchas here and there that show that. This is understandable. It’s new and shiny and that may prevent it from being truly production-ready other than the brave Steven Murawski getting DSC implemented over at Stack Overflow.

I can’t even begin to look into deploying DSC to my client’s production environment because they are just now getting to Windows 7 and 2008 (let alone Windows 8.1 and Server 2012). However, I do plan on rolling out a test pilot as a pet project here pretty soon.

Microsoft really is opening up

The “new Microsoft” in which I heard numerous times at TechEd really is more open to other vendors. Never before have I seen such a focus on open standards. Microsoft really has embraced this, at least in my areas of expertise. Having DSC just create MOF files (which I’ve used extensively as a SCCM admin) to actually store the configuration is an excellent idea. Not only does it allow the possibility to apply DSC configurations to Windows boxes but even as Jeffrey Snover wowed the audience last week, it can even work on Linux boxes as seen in the DSC Overview session!

PowerShell is just a DSC configuration manager

All I’ve been hearing is “Powershell DSC, Powershell DSC” but I didn’t quite understand until I looked at it more was that DSC and Powershell are mutually exclusive. DSC is an entity all it’s own and, for all intents and purposes, really has nothing to do with Powershell. Powershell just acts as DSC’s MOF file creator and applier. Powershell does what Powershell does best; allow the automation of existing technologies and provide an easy to understand interface to us, the admins, to the technology. I’m super excited it integrates so well with DSC!

That’s it for now. As I said, I’m just now playing with DSC and I’ve got a lot to fully understand yet. I’m disappointed I won’t be able to really use it other than just pet projects here and there due to its dependency on Powershell v4.0 but I’m not going to let that stop me from learning it and looking to the future.

Subscribe to Adam the Automator

Get the latest posts delivered right to your inbox

Looks like you're offline!