Working with the PowerShell Desired State Configuration, Part 1: Theory and Initial Setup
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Windows PowerShell v4 and v5 include a feature that you really need to know about, called Desired State Configuration (DSC). DSC is a configuration management framework that uses vendor-neutral standards and enables you to prevent "configuration drift" on Windows Server, Linux, and eventually OS X server computers.
Configuration drift has historically been a big problem among Windows systems administrators. If your experience mirrors mine, another administrator will remove a component or tweak a setting, and you'll only learn about it after the server stops working and your help desk explodes with support tickets.
Although we can theoretically use DSC to configure Windows client systems, Microsoft really intended DSC as a method for applying consistency and standardization to servers. Is DSC supposed to replace Group Policy–based configuration management? Not exactly. By the end of this article, you will understand the overall DSC architecture and be better prepared to integrate DSC into your existing configuration-management structure.
Let's start by examining DSC system requirements.
DSC Requirements
Windows Server 2012 and Windows 8.1 both include Windows Management Framework (WMF) 4.0. To allow Windows Server 2008 R2 and Windows 7 boxes to participate in DSC, you first need to install WMF 4.0 on those systems.
Next, in Windows Server activate the DSC components by executing the following PowerShell "one liner" from an elevated PowerShell session:
Install-WindowsFeature -Name DSC-Service
Finally, download the appropriate DSC resources to all computers that will participate in DSC configuration.
DSC resources are building blocks that we can use to build DSC configuration scripts. Specifically, a DSC module contains one or more resources that provide targeted configuration management. For example, you might use the resources within the xActiveDirectory DSC module to configure and enforce the domain controller role. You might also employ the xDHCPServer module and its constituent resources to ensure that your DHCP Server role never changes without explicit override.
Notice the lowercase x that prepends each DSC module/resource name. This denotes "experimental," and means that these are likely not the resource's final names. In fact, let's delve more deeply into resources right now.
Important Notes About DSC Resources
Eventually you'll find, download, install, and manage DSC modules directly from within Windows PowerShell v5 by using the PowerShellGet and PackageManagement (formerly called OneGet) modules. In fact, you can do that right now. Given the high degree of flux DSC is in at the moment, I suggest that you download all the DSC modules as a single ZIP archive from the Microsoft TechNet Script Center.
Unpack the DSC module folders to the following location on each DSC node:
C:\Program Files\WindowsPowerShell\Modules
Keep the module folders intact, as shown in Figure 1.
)
Figure 1 Your resource folder should look like this on all DSC-participating nodes.
Let's take a closer look at the xChrome module, which allows us to enforce the installation of the Google Chrome web browser. As Figure 2 shows, the xChrome module contains only one DSC resource, named MSFT_xChrome.
)
Figure 2 The resources are inside the parent module's DSCResources subfolder.
The actual "guts" of the DSC resource are contained inside the .psm1 module file. Take a look at the annotated xChrome resource contents in Figure 3. The following table explains the annotations in the figure.
|
Annotation |
Description |
|
A |
DSC resources and configuration files use the Configuration data structure. This keyword functions similarly to a function, but it is indeed a separate construct. |
|
B |
The xChrome resource uses English as the default language and describes a default download path for the Chrome browser. |
|
C |
Importing the modules on which this resource depends. (Notice the DependsOn property in annotation E.) |
|
D |
Here we specify the Google Chrome download location and installation directory. |
|
E |
This section is the most important for systems administrators because we use these settings when creating the DSC configuration script. |
)
Figure 3 Contents of the .psm1 module file.
Basics of DSC Configuration Scripts
One of the coolest things about Direct State Configuration is that Microsoft chose to use the industry-standard Managed Object Format (MOF) instead of something proprietary or otherwise unwieldy.
MOF is the same easy-to-read data description format used by Windows Management Instrumentation (WMI) and the Common Information Model (CIM).
Although the standard way to define a DSC configuration right now is to work from within PowerShell, using the Configuration container, that situation will change. Eventually we'll see text-based and graphical front-ends that run on any OS that allows DSC configuration authoring. Cool stuff!
Meanwhile, back to our example. Let's say that we have a file share located at \\dc1\psscripts and it contains all our team's key PowerShell scripts. We need this folder to exist at C:\Scripts on our member server named adfs1, and we want to prevent it from being deleted.
Figure 4 shows my configuration script named EnforceScripts.ps1. The following table explains the annotations in the figure.
|
Annotation |
Description |
|
A |
The Configuration construct behaves similarly to a PowerShell function. |
|
B |
We target a single host in this example, but we could specify an array of hosts. |
|
C |
Taking care of prerequisites. All we need is PSDesiredStateConfiguration because File is a core resource. |
|
D |
The script can have one or more Node blocks; each is a separate configuration. (Note: A single node can have only one configuration at a time applied to it.) |
|
E |
Using the File DSC resource to ensure that \\dc1\psscripts folder (and its contents) exist on the target at C:\scripts. |
|
F |
We call the configuration just like we'd call a function. |
)
Figure 4 A sample DSC configuration script; this one uses the File resource.
After you run the configuration script, look for the folder named after your Configuration keyword; inside it is the MOF file, as shown in Figure 5.
)
Figure 5 The MOF file is the "deliverable" that contains the DSC configuration directives for one or more nodes.
Again, we could just as well have written the MOF file directly; the PowerShell Configuration keyword simply gives us another way to author the DSC configuration files.
Next Steps
We're ending this article on a bit of a "cliffhanger" note. Thus far, we've examined the purpose of DSC, and we're at the point of assembling the building blocks and writing a configuration script.
In next month's continuation, we'll complete this DSC example by pushing our configuration to the target node. While we're on that subject, I'll explain the various ways by which we can push or pull DSC configurations among nodes. We'll finish by learning how to tweak DSC client node behavior; for instance, how strict the node is about enforcing its DSC configuration, and how often the node checks its pull server for configuration changes.
See you then, and in the meantime, happy PowerShelling!