PowerShell DSC

Author by Mitchell Grande

While configuration management software such as Ansible, Puppet, or Salt has become very popular for use in Linux environments, Windows hasn't had a similar push until relatively recently.  PowerShell Desired State Configuration (usually shortened to DSC) is a configuration management platform that is native to Windows and programmed using familiar PowerShell syntax.  Here, we'll cover the benefits of using configuration management, example use cases, and a technical overview.
 
Why Configuration Management?
The goal of configuration management is to define the state you want your systems to be in and then let the platform manage the changes required to achieve that state.  For example, instead of writing a PowerShell script that manually installs the IIS role and then downloads website files to the correct folder, you would write a shorter configuration file that declares that IIS and the websites files are required.  The difference being that the DSC engine will handle the specifics of the installation and download for you, including error statuses, dependencies, etc.
 
The ultimate idea of configuration management is to have a single, readable configuration file that describes the ideal state for a set of common servers, such as web servers for a certain application.  Your servers will then always automatically conform to those standards.  Optionally, any conflicting manual changes to the servers can be reverted automatically by the platform.  By doing so, you ensure that the servers are always configured correctly.
 
Use Cases
Although configuration management and DSC are most beneficial for developers and those in the DevOps space, more traditional systems can still benefit from the use of DSC.  For example, you could have a DSC configuration for each common server type that is deployed - AD DC, SQL, and Exchange.  Those DSC configurations could do things like install required Windows roles, pre-download installation/setup files, and configure Windows services if necessary.  You can even do the full installation and configuration of SQL Server 2017 via DSC if you want!  Doing so would allow you to simply apply a DSC configuration to a base server, and the platform will handle all of the steps to get the server configured.  If you keep the DSC configuration applied long-term, you can monitor to ensure the server configuration doesn't drift from the desired state.
 
Another example use is applying a base DSC configuration to every Domain Controller in a client environment.  By doing so, you can ensure they are all configured exactly to whatever standards the client requires.  If any unexpected changes are detected, you can simply alert on that or automatically revert them.
 
Technical Overview
To try out PowerShell DSC, the first thing to do is create a configuration file that defines what we want configured on the server.  A very simple example file, that simply ensures the base IIS server role is installed, would look like:
 
configuration TestConfig {
    Import-DSCResource -ModuleName PSDesiredStateConfiguration
    Node localhost {
        WindowsFeature IIS {
            Ensure = “Present”
            Name = “Web-Server”
        }
    }
}

 
To use this file, you must compile it into a *.mof file, then use PowerShell to apply that MOF file to the target server.  Alternatively, you can upload the configuration file to an Azure Automation account and use Azure Automation DSC.  Azure Automation DSC streamlines the steps of compiling and pushing the configuration out.
 
In more advanced scenarios, you can have different sections of a configuration file apply to different servers or use parameters to set unique options on specific servers.  These techniques allow you to share as much of the base configuration as possible, while allowing for flexible deploymens.
 
For more information about PowerShell DSC, see the Microsoft Overview or the Quick Start.
 
Author

Mitchell Grande

Systems Engineer

Tags in this Article