On Monday, here at TechEd North America, Microsoft took the wraps off of some new technology that will be shipping when Windows 8.1 is released later this year. I had had a preview of this technology a few weeks ago and was happy to see it finally made public. At the time I told the people presenting about DSC that it was the most excited I’d been about a Microsoft systems management innovation in a long, long time, and I remain just as excited when it was presented on Monday. The technology is called Desired State Configuration (DSC). The presentation on Monday was given by well-known Microsoft Distinguished Engineer and “Father of PowerShell”, Jeffrey Snover and fellow cohort in the PowerShell world, Program Manager Kenneth Hansen. You can catch the video of the presentation on the Channel 9, but I want to talk about what DSC is, and how it fits into the world of Group Policy, as I see it.
What is DSC?
First off, what is DSC? It is a framework for delivering and enforcing configuration on Windows systems. The thrust of how Jeffrey and Kenneth presented the technology on Monday was clearly around managing configuration of large numbers of Windows servers in data center environments (think farms of 100s or 1000s of nearly identical web or application servers). DSC is made real through PowerShell. What do I mean by that? As I said, DSC is a framework. I suspect that when Windows 8.1 ships, you won’t see a DSC admin console or fancy GUI letting you configure masses of systems with the touch of a button. Rather Windows 8.1 servers will come equipped with the ability to consume DSC Management Object Framework (MOF) documents that describe a desired configuration. The Local Configuration Manager (LCM) running on the server will enforce that configuration and makes sure it stays enforced, to prevent drift, etc.
DSC, as it was presented, provides for both pushing and pulling configuration documents to get them to servers. In the case of a pull, you would deploy one or more “pull servers” that client servers would get their configuration documents from. What’s clear is that the LCM relies on the WMI infrastructure to “Make it so”. Think of DSC and LCM as extending the power of WMI to provide desired state configuration, which is cool. Why? Because if it’s “just WMI” then all the same tools and technology around that infrastructure can be leveraged by and with DSC.
How It Works
So, by now you may be wondering how all this will work. How will you be able to specify configuration and have it be magically implemented on your servers?
The key, of course, is PowerShell. DSC and PowerShell are deeply intertwined–at least in the current incarnation. As a configuration author, you would create PowerShell scripts that define configuration. To facilitate this, the PowerShell v4 language has been extended to support new Declarative keywords. For example, instead of creating a PowerShell “function” (using the function keyword) a DSC PowerShell script would define a new “Configuration” (Configuration is a new keyword). Inside that Configuration “function” you code up a series of assertions that define what you want to configure. For example, you might have a “configure web server” script. In that script, you would assert that IIS should be installed, that the servers need some files (i.e. the contents of your web application), that it might also need some registry entries or some configuration files. These different assertions–Windows features like IIS, files, registry entries, are defined and enforced by “providers” running on the client servers. The cool part? These providers, which Microsoft will provide some default ones, can be just implemented as PowerShell modules that implement a pre-defined set of Get, Set and Test verbs. So, unlike Windows Group Policy, which requires quite a bit of coding skill to extend to new policy areas, you can write new providers with a simple set of PowerShell functions. This is powerful. To make things even easier, if a client receiving a DSC MOF document does not have a provider module for the resource its trying to configure– it will automatically download it from the pull server that it gets those documents from. So, no more pesky pushing of new agents out to your servers!
What Does This Mean for Other Configuration Technologies– like Group Policy?
The 64 thousand dollar question for me, when I first learned about DSC, was, how does this impact Group Policy and other Microsoft configuration technologies and products, like System Center Configuration Manager or Windows Intune? Although I can’t answer that question definitively (because I simply don’t know) I can speculate. Clearly this technology takes Windows configuration to a new level. A level that I’ve been personally waiting for, for a long time. It will be “plumbing” in the box in Windows 8.1. It will be interesting to see if it gets ported to down-level versions– I hope it does! I don’t see all of the various Microsoft products and technologies converting that perform configuration converting to DSC overnight, but I would certainly like to see that. Right now, between the products I mention, there is a patchwork of sometimes overlapping configuration capabilities, each with it’s own limitations. DSC represents a fresh, and most importantly, MODERN, approach to configuration management that will serve Windows well over time. Even though Jeffrey and Kenneth presented DSC as a data center server configuration technology, there is nothing in DSC that would preclude it’s use against Windows client OS’. To me, it represents a logical future path for Group Policy and I for one, would applaud that move.
What’s Next?
I suspect Microsoft will be releasing Windows 8.1 bits later this month at BUILD. I will be there waiting eagerly to dig into DSC. I’m planning on blogging and writing more details about DSC as they become available. If you are as excited as I am about this new configuration technology, then check back frequently for more cool stuff !
Enjoy,
Darren
Trackbacks/Pingbacks