Summary: Windows PowerShell MVP, Dave Wyatt, says the number 1 reason to upgrade to Windows PowerShell 4.0 is Desired State Configuration.

Microsoft Scripting Guy, Ed Wilson, is here. Today, Dave Wyatt, is back to share his ideas about upgrading to Windows PowerShell 4.0.

Dave is a Microsoft MVP (Windows PowerShell) and a member of the board of directors at PowerShell.org. He works in IT, mainly focusing on automation, configuration management, and production support of Windows Server and point-of-sale systems for a large retail company.

Blog: Dave Wyatt's Blog
Twitter: @MSH_Dave

When I got an email from the Scripting Guy asking for ideas for a series of posts about “Why upgrade to PowerShell 4.0?”, I replied that they should be called DSC, DSC, DSC, DSC, and DSC. As you have seen in the other posts this week, there are some neat new features in Windows PowerShell 4.0, but in my opinion, they’re small potatoes compared to the introduction of the Desired State Configuration feature.

At its core, Desired State Configuration is a configuration management engine. You can think of it like Group Policy on steroids. Instead of being limited to configuring registry values and a few other simple parts of Windows, a DSC configuration can quite literally do anything.

DSC embraces the DevOps staples of automation and “infrastructure as code.” By defining your server configurations in DSC, you can reinstall the operating system on a server, or you can duplicate its configuration to a new server or virtual machine and have the proper configuration applied with very little manual intervention, if any.

From a pure Windows point-of-view, DSC consists of the following parts:

• Local Configuration Manager: An agent that runs on all Windows computers that have Windows PowerShell 4.0.
• DSC resources: Small Windows PowerShell modules designed to configure a specific type of item on a computer.
• MOF documents: Standards-based text files that are read by the Local Configuration Manager. They tell it which resources to execute and what parameters to pass to these resources.
• Configuration scripts: Scripts written in Windows PowerShell that are used to produce the MOF documents.
• Configuration data: A set of parameters passed to the configuration script.
• Pull Server and Compliance Server: OData-based web endpoints that can serve resources and MOF documents to the Local Configuration Manager and can keep track of the compliance status.

The exciting thing about Desired State Configuration is that every one of these items doesn’t have to be tied to the Windows operating system and Windows PowerShell. Because of that MOF document layer, you can use DSC in a number of ways, for example:

• You could use the features listed previously as-is, and manage Windows computers from Windows computers.
• You could use an existing configuration management toolset, such as Chef, in conjunction with DSC, where Chef would be responsible for producing the MOF documents that are sent to Windows endpoints (essentially, managing computers running Windows from Linux computers).
• You could write configuration scripts in Windows and send them to Linux computers—thanks to the open management infrastructure (OMI), which includes a Linux version of the Local Configuration Manager. In this situation, you would have Linux-specific resources that are not Windows PowerShell modules, but rather, scripts or executables that run on Linux.

This is not the Microsoft I grew up with! Instead of making some proprietary piece of software that can only be used in basically one way, this architecture can play well with any non-Microsoft software vendor who wants to make use of it.

I’ve heard it said that DSC is an API that is intended to be used by other developers to produce a complete configuration management solution, and I think that’s a great description. The first version of it (as released with Windows PowerShell 4.0) can be a little bit rough around the edges, but Microsoft is putting a huge amount of effort into this feature, and it’s getting better every day.

There’s really no limit to the configuration management you can do with DSC, but let’s take a look at a quick and simple example. In our dummy configuration, we’ll create a .ini file and specify the contents that should be in that file. The configuration script looks like this:

Now, let’s take that .mof file and apply it to our test server:

As you can see from the screenshot, the Sample.ini file (and the entire C:\Temp folder, for that matter) did not exist prior to applying the configuration. After the configuration was applied and the file created, I manually deleted the file. The next time the Local Configuration Manager checked the machine’s state, it saw that the file needed to be re-created with the specified contents.

~Dave

Thank you, Dave, for your willingness to share your time and knowledge.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy