PowerShell Desired State Configuration


PowerShell Desired State Configuration (DSC) has been around the Microsoft Windows world since 2013, but it's just beginning to take off.

There are certain setting changes, such as adding and removing Windows Server roles and features, that cannot be accomplished easily, or at all, with Active Directory Group Policy Objects (GPOs). Centrally managed GPOs are furthermore designed for AD domain machines, not for stand-alone Windows machines, much less Linux or UNIX computers.

This is where DSC shines. You see, while DSC is a Microsoft technology, it is simply an avenue for PowerShell to create and apply Managed Object Format (MOF) text files, which are a DMTF industry standard (see DSP0221) written in Augmented Backus-Naur Form (ABNF) notation (see RFC5234). In the Microsoft world, DSC settings rely largely on Windows Management Instrumentation (WMI), but WMI has an industry standard counterpart, Open Management Infrastructure (OMI), which can be and is implemented on a wide variety of operating systems and even non-OS devices. DSC is primarily a declarative technology. You provide a collection of settings you desire to be configured. Microsoft provides the Local Configuration Manager (LCM) software for compatible clients, and it "figures out" how to achieve the desired result locally. In the end, the clients configure themselves.

Like GPO Preference settings, DSC configurations can be deployed once, or deployed and then refreshed/reapplied on a schedule to keep managed systems in compliance. And, like GPO settings, DSC configurations are idempotent; that is to say, they check to see if settings are already appropriately configured prior to reapplying them. This is the same background technique that prevents deployed applications from being re-installed every time GPOs are refreshed. The same goes for restricted group memberships, local user/group creation, etc.

Because of DSC's idempotency, server roles and features can be installed or removed on target computers without refresh-time errors due to their already being present or absent. The DSC configuration simply ensures that the desired role, feature, etc., is in the desired state, present or absent. Individual details of a role's settings can also be configured, and if they somehow drift from their desired state, they can be brought back into compliance individually at the single setting or attribute level.

PowerShell DSC can work in two modes: Push and Pull. Push mode is comparatively simple to configure and deploy. You simply write the configuration code as you might write a function, then execute it to create a MOF file. Thereafter, you can push the configuration as often as you like to its target(s) with the Start-DSCConfiguration cmdlet. Pull mode requires some more complex configurations, including installation of an IIS or SMB 3 Pull Server, complete with client-trusted certificates, to act as a distribution point for clients configured to request their own DSC updates. This is similar to GPO clients' need for a domain controller. The clients must also be configured with refresh and apply intervals and settings so that they know what to if a configuration has drifted. Do they just check? Just monitor for drift? Or monitor and re-apply if necessary? You decide what's best. Push once and recheck manually now and then, or do the extra work of setting up Pull mode to let the clients refresh themselves automatically.

A common third alternative is to create the necessary PowerShell scripts to perform the DSC Push configurations (typically one configuration for one or more similar computers), and schedule them to run regularly. Because of their idempotent nature, they can be run against fresh or already configured systems as frequently as deemed necessary without causing "object already exists" or other such errors you might expect with normal scripts. In some environments, pushing the same configuration to the same computers every 30 minutes via Task Scheduler has the same effect as setting them up in Pull mode with a 30 minute refresh and apply client configuration. You might prefer that option. You can always switch modes later, if your original choice doesn't work out.

Desired State Configuration is not a replacement for Active Directory Group Policy, and it is intended primarily for Server operating system targets, although certain client configurations are also possible. In many enterprises, GPOs suffice, especially for desktop computers, but DSC should be considered for those times when GPOs just aren't a satisfactory solution, whatever the reason.

Happy coding!

For more information on PowerShell DSC, see Microsoft's overview at https://docs.microsoft.com/en-us/powershell/dsc/overview/

For instructor-led training on this and other advanced PowerShell topics, visit the links below.

The Power of PowerShell

Written by Mike Covington