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.

Courtesy: JonathanHassell