PowerShell DSC: Declarative Configuration for Windows Machines

Desired State Configuration (DSC) brought Infrastructure-as-Code thinking to Windows years before it was fashionable. Rather than scripting a sequence of imperative steps, you declare the end state you want, and DSC’s engine figures out how to get there — and keeps enforcing it.

Imperative vs Declarative, in Practice

A traditional PowerShell script installs IIS by calling Install-WindowsFeature once. A DSC configuration instead declares “this feature should be present,” and the Local Configuration Manager checks that state repeatedly, silently correcting drift if someone manually disables it later.

A Basic DSC Configuration

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

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

        File IndexPage {
            DestinationPath = 'C:\inetpub\wwwroot\index.html'
            Contents        = '<h1>Managed by DSC</h1>'
            Ensure          = 'Present'
            DependsOn       = '[WindowsFeature]IIS'
        }
    }
}

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

Checking for Drift

# Compares actual system state against the last applied configuration
Test-DscConfiguration -Detailed

DSC Today

Classic Windows PowerShell DSC has largely given way to WinGet Configuration (built on the newer PowerShell DSC v3 engine) for desktop provisioning, but the underlying concept — and much of the syntax — carries straight over, and DSC remains heavily used for Windows Server fleet management via Azure Automation State Configuration.