Windows Insider

PowerShell 4: Take the 'Dumb' out of Configuration Management

Greg Shields shares how Powershell's Desired State Configuration continues its evolution in transforming documentation into functioning code.

• By Greg Shields
• 07/30/2013

Documentation is dumb. While not everyone will agree with this, documenting IT systems can seem like the holy grail of configuration management, particularly for the non-technical. A documented system is one that's been "controlled" -- at least, that's how the theory goes. Once controlled, systems can then be managed through formalized change-control processes.

Again, that's the theory. My distaste for documentation is personal. One of my first IT jobs involved finishing a company's documentation package to submit for Capability Maturity Model Integration (CMMI) Level 3 certification. Achieving that certification required creating and controlling documents on everything IT had and did. It was a copy editor's nightmare.

Documentation itself isn't dumb. It's dumb documentation that's dumb. Our CMMI documentation captured a snapshot of IT systems and provided the starting point for all manner of formal change-control legislation.

But that's all it did.

Proper Documentation
I remembered this story as I learned about the Windows PowerShell version 4 Desired State Configuration (DSC) framework. DSC offers to remove the "dumb" by evolving documents into code. What results is documentation that can actually do something rather than merely describe it.

Microsoft Distinguished Engineer and Lead Architect Jeffrey Snover provided an early look at DSC during this year's TechEd conference in New Orleans. Snover's presentation is a bit aspirational at this point. But, oh, how aspirational it is.

Windows PowerShell has always been an "imperative" language. Cmdlets are run to do things: New-VM creates a new Hyper-V VM; Set-Mailbox modifies Exchange mailbox settings; Remove-Website disposes of an IIS Web site. I run Windows PowerShell commands and scripts to enact change.

DSC is so radically different -- and so potentially powerful -- because of a subtle shift in what it aims to accomplish. In layman's terms, DSC isn't so interested in telling Windows to do something; it wants Windows to be something. This is often referred to as being "declarative" as opposed to imperative. Its implications could revolutionize Windows configuration management forever.

Consider the example of a simple Web server, which runs the IIS role. On top of that role are additional configurations that define Web site characteristics and content. Other roles, features and even software packages might be installed to facilitate the server's delivery of Web services.

These constitute the configurations on that server. More specifically, they constitute the deviations from that server's initial state, which could be called "the state right after Windowsis installed."

It's here where DSC takes the "dumb" out of documentation. Just like those I authored a decade ago, DSC "documents" are lists of configurations a server must have: IIS is installed; a Web site is created; content is in the right location. What's different is DSC documents is Windows PowerShell code that can be processed by supporting Windows PowerShell modules. Executing the document calls the modules to say, "I need to be this. Do what's necessary to make me that."

A New Approach
Key to this approach is the notion of idempotence, or repeatability. Idempotence lets DSC drive what Windows systems "should be" as opposed to what they "should do." Because a DSC document defines a set of deviations from some initial state, it stands to reason you can execute that document against the server it describes at regular periods. If nothing's changed, there's nothing to do. If any configurations are in violation, you can fix them.

DSC documents can further revolutionize server and desktop deployment. These activities today are serviced through a hodgepodge of tools and approaches. Just imagine a future where a Windows image plus a document is all you need to generate a new desktop or server -- or ten thousand of them.

Get excited about this technology, but perhaps not too excited yet. Microsoft will need time to evolve Snover's thesis into a workable configuration-management solution. Until then, keep dreaming of that day when documentation need no longer be dumb.