Introduction
It’s no surprise that Configuration Management has become a part of the conversation for Systems Administrators in the recent years. It wasn’t long ago that using WSUS and SMS (Systems Management Server) which evolved into SCCM (System Center Configuration Manager) to patch servers became more common, but at the same time it wasn’t embraced by everyone.
Where SCCM has really taken hold was in the more Microsoft heavy organizations with obvious reason. The System Center family is growing and becoming a wide reaching product set, but there is a new tool which is a very exciting one that steps outside of the traditional software and patching push technology employed by SCCM.
Along came Stateful Configuration
Stateful configuration is the ability to use agents at the server side to manage software, services, and various components with continuous checking against a manifest (sometimes called a recipe) which holds the view of a desired state.
Puppet and Chef are the most popular of the open source tools that are available and heavily used. The downside to using Puppet and Chef is the requirement to have some Linux components for hosting the environment, plus having to deploy Ruby at each endpoint and have some understanding of the Ruby language to write manifests. These aren’t really significant enough reasons to automatically push Puppet and Chef aside, but imagine if we could use native tools and languages to the Microsoft ecosystem to use stateful configuration management.
Enter PowerShell DSC (Desired State Configuration)
Microsoft recently introduced PowerShell Desired State Configuration, which is a PowerShell based framework to control and configure your Windows Server environment using their widely used PowerShell scripting language.
Administrators have had the ability to use native PowerShell scripting to configure and manage Microsoft server and application environments, but the addition of a full configuration framework is big shift in how continuing management of the platforms will be done.
Configuration capabilities with PowerShell DSC include role/feature management, file system and registry controls, user and group management, environment management, process controls, and service management among others. The 12 built-in providers are a great start, but with the ability to launch external processes through a DSC configuration, the possibilities are seemingly endless to integrate any scriptable process in your endpoint state configuration.
PowerShell DSC versus Traditional PowerShell Scripts
Many have asked what the difference is with PowerShell DSC over regular PowerShell scripts. Outside of the syntax, the biggest change is the fact that using DSC, you can discover and affect the state of endpoints as well as just initiate actions against them.
The MOF (Management Object Format) schema includes current state checking, dependencies, and actionable commands.
Here is a sample of a simple configuration file to check the presence of, and to configure a registry key:
Figure 1
As you can see, the scripting language is easily readable with the dependency setting of Ensure which we have set to Present, which can also be set to Absent. The Registry configuration is clearly laid out as Key, ValueName, and ValueData and the goal of this file is to have it run with a parameter of $MachineName which will be the target node as set using the Node $MachineName in this example.
Roles and Features are configurable by using the WindowsFeature option:
Figure 2
These are just simple examples, but it also illustrates how these script blocks can be easily stackable inside a DSC configuration file.
In order for us to have done the similar registry creation, we can use the New-Item Cmdlet, but because it is not able to be run against a path where one exists already, we would have to wrap the command in some logic such as running Test-Path and then using an If statement to decide whether to add the key.
Beyond the configuration portion, there is also error handling and logging that isn’t easily managed with remote scripts being run using traditional PowerShell script files. Scheduling of the files will have to be done using the local Scheduled Task manager, and file versions are challenging to deal with on the remote machines.
With the simple registry example, it could quickly get out of hand if we were using multiple keys, and handling addition and removal of content, not to mention that scaling out to multiple nodes will be unmanageable. Using the PowerShell DSC, we will not only be executing these configuration settings once, but we will ensure that the settings are continually set using the DSC framework.
Configuration Modes for DSC
The local configuration manager on each of the endpoints is able to use DSC for one-time and continuously managed deployments. The three modes available are:
- ApplyAndAutoCorrect
- ApplyAndMonitor
- ApplyOnly
These allow for configurations to be active and stateful, or to warn on configuration changes. In other words, if the state of the node is different than the desired state, the local configuration manager will only log the issue and not make the change.
Community Modules for PowerShell DSC
Just as with many application environments, there is a community all around who contributes to the content. In this case, a growing and vibrant community is documenting and sharing examples for using PowerShell DSC. There is a GitHub repository hosted by the PowrShell.org community with many great examples of DSC modules that you can find here.
Figure 3
Limitations of PowerShell DSC
While PowerShell DSC has some great features, it is as important that we understand the limitations as we prepare to deploy it into our environment. These include:
- Multi-Node Management challenges – while DSC can manage a node quite effectively, there is no multi-node management possible with inter-node dependencies. In other words, you cannot use a configuration state on Node A to trigger a change in state on Node B. This may require a more traditional scripting solution for orchestrating this type of solution.
- Lack of a centralized dashboard – Although node management is powerful using PowerShell DSC, one shortcoming is the lack of a dashboard to indicate the configuration state of managed endpoints. Even within SCCM this has been a challenge to find the best way to view the state of the environment.
- The learning curve for scripting – PowerShell itself is simple to use for many administrators, but there is still learning required. The format of DSC configuration files is quite simple, and the language should find a happy home among administrators and developers alike.
- Platform dependence – Unlike other cross-platform configuration management tools, the PowerShell DSC framework is limited to managing Microsoft products at this point.
PowerShell DSC Going Forward
The adoption of PowerShell DSC has been very positive and is a sign that this framework will get continued focus in the Microsoft ecosystem. We can look forward to more development of modules, and extensions of the reach of PowerShell DSC on current and upcoming platforms. For anyone who is heavily involved in Microsoft systems administration, this is definitely a tool to take a look at.
