Desired State Configuration (DSC)

Analogy categoryAnalogies

What DSC Solves: Declarative Configuration

Desired State Configuration (DSC) is a declarative management platform in PowerShell where you describe what a system's end state should look like — a specific Windows feature installed, a service running, a registry key set — rather than scripting the imperative steps to get there. A Configuration block compiles into one or more .mof files, the Managed Object Format documents that the DSC engine (Local Configuration Manager, or the newer DSC v3 resource-based engine) reads and applies. Unlike a plain script that runs once, DSC configurations are idempotent: applying the same configuration repeatedly produces the same end state without duplicating side effects.

🏏

Cricket analogy: DSC is like a groundskeeper being handed a pitch specification sheet stating 'grass height 8mm, moisture 15%' rather than a list of mowing and watering steps — the crew figures out how to reach that state regardless of the pitch's current condition.

powershell

Configuration WebServerConfig {
    param([string[]]$NodeName = 'localhost')

    Node $NodeName {
        WindowsFeature IIS {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }

        Service W3SVC {
            Name  = 'W3SVC'
            State = 'Running'
            DependsOn = '[WindowsFeature]IIS'
        }
    }
}

WebServerConfig -OutputPath .\Output
Start-DscConfiguration -Path .\Output -Wait -Verbose

Resources: The Building Blocks

A DSC Resource is a reusable unit — built-in (like WindowsFeature, Service, Registry, File) or from a downloaded module like the xPSDesiredStateConfiguration or PSDscResources modules — that implements three functions internally: Get-TargetResource (reads current state), Test-TargetResource (compares current vs desired, returns a boolean), and Set-TargetResource (applies changes only if Test returns false). This Test-then-Set pattern is exactly what makes DSC idempotent and safe to re-apply repeatedly, since a compliant node's Test always short-circuits before Set runs.

🏏

Cricket analogy: The Test-then-Set pattern is like a curator checking the pitch moisture reading before deciding to water it — if it's already at target, no water is added, avoiding overwatering from repeated checks.

Community DSC resources (like PSDscResources or the newer DSC Community modules) extend far beyond the built-in set, covering things like SQL Server configuration, Active Directory, and networking — search the PowerShell Gallery with 'DscResource' tags.

Applying and Enforcing Configuration

After compiling a Configuration into .mof files, Start-DscConfiguration pushes and applies it in push mode, while pull mode has nodes periodically fetch their configuration from a DSC pull server or Azure Automation State Configuration. The Local Configuration Manager (LCM) on each node controls how often and how aggressively drift is corrected via its RefreshMode and ConfigurationMode settings — ApplyOnly runs once, ApplyAndMonitor detects but doesn't fix drift, and ApplyAndAutoCorrect actively reverts unauthorized changes back to the desired state on its refresh interval. DSC v3, the newer cross-platform rewrite, replaces MOF-based configurations with YAML/JSON resource manifests and drops the LCM push/pull model in favor of simpler CLI invocation.

🏏

Cricket analogy: ApplyAndAutoCorrect is like a groundskeeper who re-mows the pitch back to spec every single morning automatically if anyone tampers with it overnight, rather than just noting the discrepancy.

ApplyAndAutoCorrect will silently revert manual changes an administrator makes directly on a node, which can be confusing during incident response — always check the LCM ConfigurationMode before troubleshooting unexpected 'self-healing' behavior.

DSC is declarative: you describe the desired end state, and the engine determines how to reach and maintain it.
Configuration blocks compile into .mof files applied by the Local Configuration Manager (LCM).
DSC Resources implement Get-/Test-/Set-TargetResource, making configurations idempotent.
Push mode applies configuration immediately with Start-DscConfiguration; pull mode fetches periodically from a pull server or Azure Automation.
LCM ConfigurationMode controls drift handling: ApplyOnly, ApplyAndMonitor, or ApplyAndAutoCorrect.
Community resource modules (PSDscResources, DSC Community) extend built-in resources significantly.
DSC v3 replaces MOF/LCM with a cross-platform YAML/JSON resource model and simpler CLI invocation.