Windows Server 2019 – Desired State Configuration

How to change the time zone on Windows Server 2019

There is some new and powerful functionality in the more recent versions of PowerShell, provided by something called Desired State Configuration (DSC). DSC is a management platform plugged into PowerShell, which provides some new functions and cmdlets that you can take advantage of in your scripts to enable some really cool features. As the name implies, it allows you to build configurations inside PowerShell that will provided a desired state. What do I mean by that? Well, in a basic sense, DSC makes sure that the PowerShell scripts you build will always work the same way, across all of the servers where you apply them. It is quite easy to build a script in a way that it will work correctly on the server you are currently working from, but if you try to roll that same script out to a different server that might reside in a different organizational unit (OU), or have different items installed on it to begin with, then the script could produce different results than what it was originally intended to do. DSC was built to counteract these differences.

In building your DSC configuration, you identify particular roles, settings, functions, accounts, variables, and so on that you want to retain in your specific desired state. Once you identify and configure these variables, DSC will work to ensure they stay where you have them set, and that they remain uniform according to your DSC configuration policy, which means they are uniform against the other servers where you have run this script.

DSC also helps to prevent unwanted changes on servers. If your DSC-enabled script has identified that a particular service should be running all the time on your servers, and that service stops for some reason, DSC can be there to help spin it back up so that you don’t experience an outage. Alternatively, perhaps you have a script that configures a server to a particular set of standards, and another person in IT comes along and adjusts that configuration on the server itself—perhaps they log in and stop a service purposefully for some reason. Normally, this could result in an outage for that server, but DSC will get that service running again in order to maintain your originally-configured desired state for this server. DSC is your scripting nanny, so to speak. It helps to build configurations that will remain uniform across multiple platforms, and will then work to ensure these configurations are always true. You can then be confident that your servers are always running within the context of your specified desired state.

After building a configuration that identifies the items you want to be installed or monitored, something called the Local Configuration Manager (LCM) works to ensure the resources remain within the configuration specifications. LCM polls the system regularly, watching for irregularities and changes, and takes action when needed to bring your servers back into the DSC.

The ultimate goal of DSC is to keep everything constant and consistent across your servers and services. DSC’s capabilities and access to reach into more and more places in the operating system grows constantly, as roles are rewritten to accept DSC parameters and monitoring. In the end, I believe that it will be Microsoft’s goal that every server runs a DSC configuration script, ensuring that it is constantly working within your standards and helping to maintain your 99.999% uptime status.

There is a lot to learn about DSC, and I encourage you to explore this topic more once you are familiar with creating and using PowerShell scripts. Here are some great starting points for learning more about DSC:


Comments are closed.