Sergey Nivens - Fotolia
When a server configuration drifts from its approved baseline, bad things happen.
A seemingly innocuous setting change can trigger a catastrophic domino effect that ripples through the data center. A high availability cluster could crumble, or a disaster recovery configuration could collapse just when it's needed most. To protect the business -- and themselves -- the IT department should implement a change management tool, such as Windows PowerShell Desired State Configuration (DSC).
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Windows PowerShell DSC is a management extension in PowerShell that gives administrators more control over Windows machines. Introduced with PowerShell 4.0, Windows PowerShell DSC builds on that automation tool with its own cmdlets and language extensions to tighten controls on software deployments and server configurations. Windows PowerShell DSC sets a desired state for a server, which the IT department applies to existing or new machines. Administrators set up Windows PowerShell DSC to use push mode to send configurations to machines, pull mode to have the machines retrieve configurations from the server or a combination of these two modes.
In The DSC Book by Don Jones and Melissa Januszko, the authors explain these nuances and why administrators should use Windows PowerShell DSC for more than simple server deployments. The book, which comes in a Forever Edition format, meaning the authors will continually update and expand it, consists of six parts. After an introduction that details why Windows PowerShell DSC exists, the authors get into advanced territory, such as partial configurations and best practices for resource design. The book also covers common trouble spots and error messages in PowerShell DSC, with possible resolutions.
In this excerpt taken from the book's introduction, Jones and Januszko describe the difference between Windows PowerShell DSC and the Group Policy management tool:
On the surface, DSC and Group Policy seem to serve the same high-level purpose. Both of them enable you to describe what you want a computer to look like, and both of them work to keep the computer looking like that. But once you dig a little deeper, the two technologies are grossly different.
Group Policy is part and parcel of Active Directory (AD), whereas DSC has no dependency on, or real connection to, AD.
Group Policy makes it easy to target a computer dynamically based on its domain, its location (organizational unit, or OU) within the domain, its physical site location, and more. Group Policy can further customize its application by using Windows Management Instrumentation (WMI) filters and other techniques. DSC, on the other hand, is very static. You decide ahead of time what you want a computer to look like, and there's very little application-time logic or decision-making. Group Policy predominantly targets the Windows Registry, although Group Policy Preferences (GPP) enables additional configuration elements. Extending Group Policy to cover other things is fairly complex, requires native C++ programming, and involves significant deployment steps. DSC, on the other hand, can cover any configuration element that you can get to using .NET or Windows PowerShell. Extending DSC's capabilities is a simple matter of writing a PowerShell script, and deploying those extensions is taken care of by DSC's infrastructure.
Editor's note: This excerpt is from The DSC Book, authored by Don Jones and Melissa Januszko, published by Leanpub, 2016.
Microsoft adjusts PowerShell DSC in Windows Server 2016
Change management tools help IT stay in control
How to deal with the patch changes from Microsoft