DSC Overview and Requirements
Desired State Configuration (DSC) was first introduced as part of Windows Management Framework (WMF) 4.0, which is preinstalled in Windows 8.1 and Windows Server 2012 R2, and is available for Windows 7, Windows Server 2008 R2, and Windows Server 2012. Because Windows 8.1 is a free upgrade to Windows 8, WMF 4 is not available for Windows 8.
You must have WMF 4.0 on a computer if you plan to author configurations there. You must also have WMF 4.0 on any computer you plan to manage via DSC. Every computer involved in the entire DSC conversation must have WMF 4.0 installed. Period. Check $PSVersionTable in PowerShell if you're not sure what version is installed on a computer.
|On Windows 8.1 and Windows Server 2012 R2, make certain that KB2883200 is installed or DSC *will not work*. On Windows Server 2008 R2, Windows 7, and Windows Server 2008, be sure to install the full Microsoft .NET Framework 4.5 package prior to installing WMF 4.0 or DSC may not work correctly.|
To figure out what DSC is and does, it's useful to compare it to Group Policy. There are significant differences between the two, but at a high level they both set out to accomplish something similar. With Group Policy, you create a declarative configuration file called a Group Policy object (GPO). That file lists a bunch of configuration items that you want to be in effect on one or more computers. You target the GPO by linking it to domain sites, organizational units, and so on. Targeted machines pull, or download, the entire GPO from domain controllers. The machines use client-side code to read the GPO and implement whatever it says to do. They periodically re-check for an updated GPO, too.
DSC is similar... but not exactly the same. For one, it has no dependencies whatsoever on Active Directory Domain Services (ADDS). It's also a lot more flexible and more easily extended. A comparison is perhaps a good way to get a feel for what DSC is all about:
|Configuration specification||GPO file||Configuration script (which produces a MOF file - more on those after this table)|
|Targeting machines||Link GPO to sites, OUs, etc.||Specify target nodes in the configuration script itself|
|Configuration implemented by||Client-side OS components||DSC resources, which are special PowerShell script modules|
|Extend the things that can be configured||Client-side GP extensions - usually written in native code, somewhat difficult to write||Simply write new DSC resources in PowerShell|
|Primary configuration target||Windows registry||Anything PowerShell can touch|
|Persistence||Settings "disappear" and re-applied each time for most GPO settings||Configuration changes are permanent (don't automatically "undo" themselves)|
|Number of configurations||As many GPOs as you want||One MOF per computer|
With DSC, you start by writing a configuration script in Windows PowerShell. This script doesn't do anything. That is, it doesn't install stuff, configure stuff, or anything else. It simply lists the things you want configured, and how you want them configured. The configuration also specifies the machines that it applies to. When you run the configuration, PowerShell produces a Managed Object Format (MOF) file for each targeted machine, or node.
That's an important thing to call out: You (step 1) write a configuration script in PowerShell. Then you (step 2) run that script, and the result is one or more MOF files. If your configuration is written to target multiple nodes, you'll get a MOF file for each one. MOF stands for Managed Object Format, and it's basically a specially formatted text file. Then, (step 3), the MOF files are somehow conveyed to the machines they're meant for, and (step 4) those machines start configuring themselves to match what the MOF says.
In terms of conveying the MOF files to their target machines, there are two ways to do so: push mode is a more-or-less manual file copy, performed over PowerShell's Windows Remote Management (WinRM) remoting protocol; the pull mode configures nodes to check in to a special web server and grab their MOF files. Pull mode is a lot like the way Group Policy works, except that it doesn't use a domain controller. Pull mode can also be configured to pull MOF files from a file server by using Server Message Blocks (SMB; Windows' native file-sharing protocol).
|You'll see the term "node" instead of "computer" or "machine" a lot, because DSC envisions a time when you might be sending configurations to devices other than computers, or even to services running on computers. "Node" is just a bit more generic.|
Once a node has its MOF file (and it's only allowed to have one; that's another difference from Group Policy, where you can target several GPOs to a single machine), it starts reading through the configuration. Each section in the configuration uses a DSC resource to actually implement the configuration. For example, if the configuration includes some kind of registry specification, then the registry DSC resource is called upon to actually check the registry and make the change if necessary.
You do have to deploy those DSC resources to your target nodes. In push mode, that's a manual task. In pull mode, nodes can realize that they're missing a resource needed by their configuration, and grab the necessary resource from the pull server (if you've put it there). For that reason, pull mode is the most flexible, centralized, and convenient way to go if you're managing a bunch of machines. Pull mode is something you can set up on any Windows Server 2012 R2 computer, and it doesn't even need to belong to a domain. If you're using the usual web server style of pull server (as opposed to SMB), you can configure either HTTP or HTTPS at your leisure (HTTPS merely requires an SSL certificate on the server).
In this guide, we're going to go through pretty much every aspect of DSC. The things we configure will be simple, so that we're not distracting from the discussion on DSC itself. This guide will evolve over time; if you notice blank sections, it's because those haven't yet been written. Errors, requests for more information, and so on should be reported in the PowerShell Q&A forum at PowerShell.org.