PowerShell 4: Desired State Configuration a Must-Have Feature

By the time you read this, the wraps will be off of PowerShell 4 and it's signature new feature, Desired State Configuration (DSC). The shell will ship first with Windows Server 2012 R2 and Windows 8.1, and will be a part of the Windows Management Framework (WMF) 4.0. We can expect WMF 4.0 to also be available for Windows Server 2012 and Windows 8; I also expect it'll ship for Windows 7 and Windows Server 2008 R2. We should know by the beginning of July if that expectation holds true, and if other, older versions of Windows will be supported (my personal bet: no).

So what is DSC? In short: disruptive.

With DSC, you use PowerShell to write very simple (or complex, if you like) declarative "scripts." "Script" isn't really the proper word, as there's no actual programming. You're really just building an exaggerated INI-esque file, where you specify configuration items that must or must not be present on a computer. You also specify specific "DSC resources" -- a special kind of PowerShell module -- that correspond to your configuration items. For example, if you want to ensure that IIS is installed on a computer, then there has to be a corresponding resource that knows how to check for its existence, and how to install or uninstall it. Microsoft will ship some basic resources with WMF 4.0, and because this is now a core OS feature, we can expect other product teams to follow suit in upcoming cycles.

PowerShell compiles your "script" to a MOF file, and you then ship that off to your computers. You can do that by deploying them over PowerShell Remoting, via Group Policy, or however else you normally deploy software. On those computers, PowerShell 4 again kicks in to "run" the MOF. It checks your settings and makes sure the local computer is configured as desired (hence the name of the feature). That re-runs every 15 minutes. You can also configure your computers to check a central URI for their declarative configurations, meaning they can periodically (every half-hour, by default) check in to see if there's been an update. In this "pull" model, you can also centrally locate DSC resources, and your computers can pull down the ones they need on-demand, so you don't have to manually deploy those resources before relying on in them in a configuration.

Were do I personally see this going? For one, replacing the anemic "configuration auditing" feature in System Center Configuration Manager (SCCM). That's a pretty sure bet, although it's hard to tell when it'll happen. Frankly, I can see this supplementing Group Policy objects (GPOs), if not outright supplanting them in time. After all, a GPO isn't a lot more than a bunch of registry writes, something DSC is already well-equipped to handle. Your DSC scripts are also a lot easier to version-control, back up, and so forth.

What's exciting is how extensible DSC is. Those under-the-hood "resources" are actually just PowerShell modules that internally confirm to a specific naming pattern. That means anyone can write one of these things. You could write resources that deal with your internal line-of-business applications, without needing to wait for an application vendor or developer to provide the resource to you. Anything you can do in a PowerShell script can be done in one of those DSC resources. With DSC in place, you'd configure a computer by simply pointing it to the right declarative file. "Hey, you're a Web server -- here's what you should look like. Get to it, and stay that way." Reconfiguring is as easy as changing your script: "Hey, all you domain controllers. I want you to look like this now. Go." The machines handle the reconfiguration on their own.

It's an incredible feature that'll take some time to become fully fleshed-out -- but this is clearly the "policy-based dynamic systems management" that Microsoft has been alluding to for years, and thus far failing to deliver. Now, the framework is in place.

Posted by Don Jones on 06/10/2013 at 1:14 PM