2023-04-24
PowerShell Desired State Configuration (DSC) has been around the Microsoft Windows world since 2013. Learning Tree can help you learn how to make administering easier with Microsoft Powershell Training.
Specific setting changes, such as adding and removing Windows Server roles and features, cannot be accomplished quickly or with Active Directory Group Policy Objects (GPOs). This is because centrally managed GPOs are designed for AD domain machines, not stand-alone Windows machines, much less Linux or UNIX computers.
Understanding DSC
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 Microsoft, DSC settings rely primarily on Windows Management Instrumentation (WMI). Still, 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.
Idempotency of DSC configurations
Like GPO Preference settings, DSC configurations can be deployed once or deployed and then refreshed/reapplied on a schedule to keep managed systems compliant. And, like GPO settings, DSC configurations are idempotent; that is to say, they check to see if settings are already appropriately configured before reapplying them. This same background technique 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 ensures that the desired role, feature, etc., is in the desired state, present or absent. Personal details of a role's settings can also be configured. If they somehow drift from their desired state, they can be brought back into compliance individually at the single setting or attribute level.
Modes of PowerShell DSC
PowerShell DSC can work in two modes: Push and Pull. Push mode is comparatively simple to configure and deploy. You write the configuration code as you might write a function, then execute it to create a MOF file. After that, you can push the configuration as often as you like to its target(s) with the Start-DSCConfiguration cmdlet. Pull mode requires 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 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 to know what to do if a configuration has drifted. Do they check? Just monitor for drift? Or monitor and reapply 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 third standard 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 new or already configured systems as frequently as necessary without causing "object already exists" or other errors you might expect with regular 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 applying client configuration. You might prefer that option. Of course, you can switch modes later if your original choice doesn't work out.
DSC vs. Active Directory Group Policy
Desired State Configuration is not a replacement for Active Directory Group Policy, and it is intended primarily for Server operating system targets, although specific client configurations are also possible. In many enterprises, GPOs suffice, especially for desktop computers, but DSC should be considered when GPOs aren't a satisfactory solution, whatever the reason.
Happy coding!
~Mike
This piece was originally posted on October 4, 2019, and has been refreshed with updated styling and links.