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.

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.

About the Author

Greg Shields is a senior partner and principal technologist with Concentrated Technology. He also serves as a contributing editor and columnist for TechNet Magazine and Redmond magazine, and is a highly sought-after and top-ranked speaker for live and recorded events. Greg can be found at numerous IT conferences such as TechEd, MMS and VMworld, among others, and has served as conference chair for 1105 Media’s TechMentor Conference since 2005. Greg has been a multiple recipient of both the Microsoft Most Valuable Professional and VMware vExpert award.

comments powered by Disqus

Reader Comments:

Mon, Jan 20, 2014

developed in the 1970s, formallyhttp://w DOT the Rural Hospital Program of Extended-Care Services, to use excess hospital beds in rural areas to deliver long-term care for the frail and disabled. Informally, it was known as “the swing-bed program.”a swing bed is a term used to describe the use of an inpatient hospital bed for either an acute or a skilled level of care. it applies to rural hopitals with fewer than a 100 beds. some eligibility criteria includes: that a patients must have prior qualifying hospital stay of at least 3 days.The swing-bed idea arose from a twin set of problems facing rural health care systems: (1) hospitals were built on a scale that often resulted in their having more beds than patients to fill them, and (2) frail elderly people who were disabled often needed to go to nursing homes far from where they lived. In this chapter, Sharon Begley, science columnist with the Wall Street Journal, who has contributed previously to The Robert Wood Johnson Foundation Anthology, tells the story of how some thoughtful leaders devised a seemingly simple solution to these two problems: use empty hospital beds for patients needing long-term skilled nursing care. Begley goes on to describe how the swing-bed idea developed, even over the initial reluctance of federal regulators to make an exception to Medicare regulations, the suspicion with which nursing homes received the idea, and the uncertainty about the level of care a practitioner could offer the occupant of a swing bed. The idea took hold, however; today, more than 60 percent of rural hospitals have swing-bed arrangements. In retrospect, the swing-bed concept proceeded in an unusually ideal manner: it was tested on a small scale, outcomes were measured, and then the model was slowly expanded to other rural areas. The federal government was involved from the beginning; the Foundation entered as the idea was gathering steam and was able to influence development and help guide the direction it took. As with many service innovations, the Foundation’s role was strategic and supportive, representing just one force in a larger national effort.

Sun, Jan 19, 2014

You write so hoeltsny about this. Thanks for sharing!

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.