Desired State Configuration Basics in Windows PowerShell
This chapter is from the book
This chapter is from the book
This chapter is from the book
Desired State Configuration, also called DSC, is the marquee feature in Windows PowerShell v4 and later. Imagine being able to send configuration instructions to your servers such that, with no tedious mouse clicking on your part, the target servers simply (to quote Jean-Luc Picard from Star Trek: The Next Generation) “Make it so.”
I’m not kidding, either. In this hour, you’ll learn precisely what DSC is and how it works, and you’ll see its value proposition with your own eyes. Many of my IT professional colleagues whisper that DSC may very well spell the future standard for Windows server configuration and administration. Let’s make it so!
Historical Background of DSC
Windows PowerShell Principal Architect Jeffrey Snover wrote The Monad Manifesto in 2002, and in so doing outlined what he saw as the chief capabilities of a new command-line automation language for Windows.
Amazingly, Snover and his team at Microsoft realized every major point in that document. Specifically, with the Manifesto’s fourth point, Monad Management Models, they describe the basic elements that the team ultimately delivered in Windows PowerShell v4.
DSC is a Windows PowerShell-based system configuration platform. Here’s the scenario: You and/or your colleagues spend valuable hours manually configuring your Windows servers; I’m talking about tasks such as the following:
- Installing and configuring roles and features
- Installing and configuring other system software and services
- Deploying and maintaining file shares
- Managing Registry settings and environment variables
The preceding list barely scratches the surface of the myriad configuration events that must be performed on each server for that machine to be considered compliant by your organization.
However, if you have any degree of Windows systems administration experience, you know that “configuration drift” is a sad fact of life. Joe Administrator makes one setting, and then a week later Jane Administrator undoes said setting.
The configuration drift problem is all fun and games until questions of service level agreements (SLAs), licensure requirements, and industry/governmental regulations come knocking at your door, metaphorically speaking.
Long story short: DSC fills a need for us Windows server administrators, now more than ever before.
Competitive Landscape
Remember that Jeffrey Snover and the Windows PowerShell team are almost all longstanding experts in UNIX/Linux administration and systems programming. This fact should be patently obvious when you compare, say, the day-to-day operation of the Bash shell with how the Windows PowerShell command-line environment behaves.
To that point, there’s no denying the fact that Snover & Co. took a leaf from the competition’s playbooks with regard to this automated systems configuration framework “thing.” Specifically, two market leaders in the systems configuration/automation space are also (partially) open source projects:
- Chef (http://www.chef.io)
- Puppet (http://puppetlabs.com)
Don’t get too bent out of shape, though: Not only are Chef and Puppet compatible with Windows, but Microsoft Azure offers either configuration product as an option for their hosted virtual machines. Figure 18.1 shows a representative screenshot of Puppet.
)
Figure 18.1 Puppet has a browser-based management console that makes it equally simple to autoconfigure Windows/Linux servers.
Going further yet, we’ll learn shortly that DSC can actually be extended to support the autoconfiguration and remediation of Linux/UNIX boxes in addition to Windows machines. It’s a “New Microsoft,” to be sure.
Finally, as cool as Puppet and Chef are as cross-platform configuration management products, they cost money to license for most business scenarios. By contrast, Windows PowerShell comes to you “free” with the cost of a Windows Server license.
One final note before we delve into DSC: Although it’s possible to leverage DSC for desktop OS configuration, I’m cleaving to the most common DSC use case: server configuration. After all, most of our compliance requirements focus on how we’ve set up our infrastructure server computers as opposed to our users’ desktop PCs.