PowerShell DSC

Desired State Configuration (DSC) has been around for a while, but it’s just beginning to take off. There are certain settings changes, such as adding and removing 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 am avenue for PowerShell to create Managed Object Format (MOF) files, which are a DMTF industry standard (see DSP0221) using Augmented Backus–Naur Form (ABNF) notation (see RFC5234). In the Microsoft world, DSC settings rely largely on Windows Management Instrumentation (WMI), but that also has an industry standard counterpart, Open Management Infrastructure (OMI), which can be and is implemented on a wide variety of operating systems and even other non-OS devices.

Like GPOs, DSC configurations can be deployed once, or deployed and then refreshed/reapplied on a schedule to keep managed systems in compliance. And, like GPOs, DSC configurations are idempotent–that is to say, they check to see if settings are already acceptably 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 configuration can also be configured, and if they were somehow to “drift” from their desired state, they can be brought back into compliance individually, at the setting or attribute level.

PowerShell DSC can work in two modes: Push and Pull. Push mode is comparatively simple to configure and deploy. Pull mode requires some more complex configurations, including 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 refreshes, similarly to GPO clients.

A common alternative is to created the PowerShell scripts to perform the DSC configurations, and run them as Scheduled Tasks. Because of their idempotent nature, they can be run against the already configured systems as frequently as deemed necessary without causing “object already exists” or “object not found” errors you might expect with normal scripts.

Desired State Configuration is not a replacement for Active Directory Group Policy, nor is it even intended for desktop operating system targets, but it should be considered for those times when GPOs just aren’t a satisfactory solution, whatever the reason. For more information on DSC, see Microsoft’s overview at https://docs.microsoft.com/en-us/powershell/dsc/overview/overview

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

Happy coding!
~Mike
https://www.learningtree.com/courses/8459/automating-administration-with-powershell-moc-10961/

https://www.learningtree.com/courses/8462/advanced-automated-administration-with-powershell-10962/

https://www.learningtree.com/courses/4670/the-power-of-powershell-training/

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.