Automating Configuration Drift Prevention with PowerShell DSC

PowerShell Desired State Configuration (DSC) lets you declare what a machine’s configuration should look like — specific features installed, specific services running, specific files present with specific content — and then have that desired state continuously enforced going forward, rather than manually re-applying individual settings each time something drifts from what it should be.

Why declarative configuration beats manually reapplying settings

The traditional alternative — a script that installs a feature or sets a registry value once, run manually or via a one-time deployment step — has no ongoing enforcement built in. If something later changes that configuration (a well-meaning administrator makes a manual change, a piece of software resets a setting during its own installation), nothing detects or corrects the drift unless someone happens to notice and manually re-runs the original script. DSC’s model is different: the desired configuration is continuously (or periodically) checked against actual system state, with automatic correction when they diverge.

Writing a basic DSC configuration

Configuration WebServerConfig {
    Node "WebServer01" {
        WindowsFeature IIS {
            Ensure = "Present"
            Name = "Web-Server"
        }
        Service W3SVC {
            Name = "W3SVC"
            State = "Running"
            DependsOn = "[WindowsFeature]IIS"
        }
        File IndexPage {
            Ensure = "Present"
            SourcePath = "\\fileserver\share\index.html"
            DestinationPath = "C:\inetpub\wwwroot\index.html"
            Type = "File"
        }
    }
}

This declares three specific desired states: the IIS Windows feature should be installed, the W3SVC service should be running, and a specific file should be present with specific content — each resource type (WindowsFeature, Service, File) knows how to check its own current state and correct it if it doesn’t match what’s declared.

Compiling the configuration into a MOF file

WebServerConfig -OutputPath .\DSCConfig

Running the configuration function (it’s technically a PowerShell function once defined) compiles it into a Managed Object Format (MOF) file — the actual artifact DSC’s underlying engine consumes, independent of the PowerShell syntax used to originally define it.

Applying the configuration to a target node

Start-DscConfiguration -Path .\DSCConfig -ComputerName WebServer01 -Wait -Verbose

This pushes the compiled configuration to the target node and applies it immediately — checking current state against each declared resource and correcting any divergence found.

Setting up continuous enforcement, not just one-time application

A one-time application only fixes drift that already existed at the moment you ran it — the more valuable ongoing behavior is configuring the Local Configuration Manager (LCM), DSC’s own engine running on each target node, to periodically re-check and automatically re-correct drift going forward without requiring manual re-application:

[DSCLocalConfigurationManager()]
Configuration LCMConfig {
    Node "WebServer01" {
        Settings {
            RefreshMode = "Push"
            ConfigurationModeFrequencyMins = 30
            RebootNodeIfNeeded = $false
        }
    }
}

ConfigurationModeFrequencyMins = 30 tells the LCM to re-check the applied configuration against actual state every 30 minutes, automatically correcting any detected drift without requiring anyone to manually notice the drift and re-run anything.

Choosing between Push and Pull modes

The example above uses Push mode (configurations are explicitly sent to target nodes from a controlling machine), which is straightforward for smaller environments. Pull mode inverts this — target nodes periodically check in with a central Pull Server and retrieve their own assigned configuration, which scales considerably better for larger environments where individually pushing configuration to every node isn’t practical, at the cost of additional Pull Server infrastructure to set up and maintain.

Checking whether a node’s actual state currently matches its desired configuration

Test-DscConfiguration -ComputerName WebServer01 -Detailed

This reports whether the target node currently matches its assigned desired configuration, and specifically which resources (if any) are currently out of compliance — useful both for auditing compliance across a fleet of managed nodes and for confirming a specific configuration change actually applied correctly.

Why this matters most for environments prone to configuration drift

DSC’s value scales with how much configuration drift an environment is actually prone to — a small number of carefully, manually managed servers might not need it, but any environment with multiple administrators making ad-hoc changes, frequent software installations that might reset settings, or a compliance requirement to demonstrably maintain specific configuration states benefits directly from having drift automatically detected and corrected, rather than depending on someone happening to notice a manual configuration change went unintentionally reverted or overridden.