Getting
acquainted with PowerShell Desired State Configuration
Desired State
Configuration is a solid choice for administrators who have PowerShell chops.
Here's an introduction.
PowerShell Desired State
Configuration is a feature introduced in the latter half of 2013 that was
included by default with the final releases of Windows 8.1 and Windows Server
2012 R2. It is a configuration management system that uses standards-based Web services
to make sure your machines are set up the way you want them to be. In this
piece, I’d like to introducePowerShell Desired
State Configuration and show you a bit about how it works and the
tasks it can accomplish for you.
But first, a bit of context
and a question many administrators have when they first hear of this: what is
the point of using PowerShell Desired State Configuration over a tried and true
systems management solution like System Center or another third-party
tool? There are several advantages, but of them, three stand out the most.
PowerShell Desired State
Configuration is included in Windows Server, so there is no additional expense
in purchasing licensing and management instances of systems management and
configuration deployment software.
PowerShell Desired State
Configuration is pretty well agentless, and requires only PowerShell to be
installed along with access over port 80 or port 443 to query a Web server to
grab configuration information -- there is no additional management overhead
for the configuration system.
PowerShell Desired State
Configuration looks at only the functions that are defined within a configuration
file. It ignores other settings, which makes for a much lighter configuration
payload and speeds up other deployments while making it possible to define
multiple configurations and stacked workloads (a Web server that is also a file
server can get Web server settings without having its file server settings
overwritten), a type of deployment that many system management suites cannot
deal with easily or even at all.
Pushing and Pulling Configurations
The basic tenet of PowerShell Desired State
Configuration is to use two models of defining a desired configuration in order
to get machines to either pull the information about the correct configuration
from a central repository, or push it to them at various intervals that you as
the administrator can define.
The push model is an active configuration
model that runs when you issue the Start-DscConfiguration
–Computername –Path Powershell cmdlet and immediately pushes out
system configurations based on the files stored wherever the location is that
you entered for the –path attribute. This is pretty
much an immediate "do this now" style of managing your targets and
requires you to stick all your configuration files in a central location where
they can be accessed by all of the machines you plan on targeting. It requires
you always to push; there is no checking by default of configurations.
The pull model is a bit more passive; it
involves a server that acts as a clearinghouse for both the configuration files
and any components that act as intermediaries for configuring various facets of
a computer. You might, for instance, write a custom provider -- a piece of code
that provides the ability to use PowerShell Desired State Configuration -- that
can translate the instructions in configuration files for your homegrown custom
line of business application. The pull server is just a Web server running IIS that publishes an OData, a
typical, well-defined and supported standard, interface that PowerShell’s Web
service can query to retrieve the actual configuration data. This is the most
common method of implementing PowerShell Desired State Configuration and is
used in deployments where configurations "drift" off of a desired
state over time; PowerShell Desired State Configuration runs periodically,
pulls the right configurations down, and silently course corrects the
configuration to the desired state.
These configuration definitions are in the
format of management object files, or .MOF files,
which are just basically text files with a bunch of classes listed, referring to
elements of the Windows operating system that the PowerShell configuration
engine understands, as well as the parameters for each of these classes that
will define what the desired configuration will look like. Here is what a few
lines of an .MOF file look like just for reference:
instance of PowerPlan as
$PP
{
ResourceID =
"[PowerPlan]Default::[BaseServer]JustTheBasics::[VirtualServer]VMWare";
SourceInfo =
"C:\\windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\SELocalConfiguration\\StackExchangeConfiguration\\StackExchangeConfiguration.psm1::20::5::PowerPlan";
Name = "High
performance";
ModuleName =
"PowerPlan";
ModuleVersion =
"1.0";
};
MOF files are generally built manually once
and then copied and pasted as necessary. For configurations that involve
installing, removing or making sure certain Windows roles and features are
present, you can use the built in cmdlet Get-DscResource. This will grab the
correct syntax and any available options you have for any given name. For
example, just running that cmdlet as written will present the types of
configuration "areas" that PowerShell Desired State Configuration can
handle, and the sorts of tasks and configuration directives you can carry out
within each area.
Name
Properties
----
----------
File
{DestinationPath,
Attributes, Checksum, Con...
Archive
{Destination, Path,
Checksum, Credential...}
Environment
{Name, DependsOn, Ensure, Path...}
Group
{GroupName,
Credential, DependsOn, Descript...
Log {Message,
DependsOn}
Package {Name,
Path, ProductId, Arguments...}
Registry {Key,
ValueName, DependsOn, Ensure...}
Script {GetScript,
SetScript, TestScript, Credenti...
Service {Name,
BuiltInAccount, Credential, DependsO...
User {UserName,
DependsOn, Description, Disabled...
WindowsFeature {Name,
Credential, DependsOn, Ensure...}
WindowsProcess {Arguments,
Path, Credential, DependsOn...}
As you can see there are a variety of facets
of the operating system, from roles and features to scripts to registry
settings to credentials, that you can control using DSC.
Those are the basics of PowerShell Desired
State Configuration. For more information, check out powershell.org and in particular, the
resources there tagged with DSC.
