DSC v3 — A Quick Catch-Up

Microsoft DSC v3.2 was released at the end of April and is genuinely the most interesting thing to happen in DSC-land in a long time. Before going into what’s new in v3.2 though, it’s worth a primer — DSC v3 has been around for a bit, but if you tried it in v1.1, bounced off it in v2, or just never made the time for it, the landscape now is meaningfully different. Here’s the quick catch-up.

For everything else that’s happened in PowerShell-land recently, see the April roundup.

What DSC actually is

Desired State Configuration is a declarative configuration platform: you describe the state you want a system to be in (a service running, a firewall rule present, a file at a path, etc.) and the DSC engine makes it so — idempotently, repeatably, and without you having to write the procedural “if this then that” code yourself. Same general idea as Ansible, Chef, or Puppet, with a heritage rooted in the PowerShell world.

For years, that meant PowerShell DSC: a Windows-centric, MOF-compiled, Local Configuration Manager-driven thing tied tightly to Windows PowerShell 5.1 and later PowerShell 7. It worked, but it came with a fair bit of overhead. Plenty of folks tried it once and quietly walked away.

Why people bounced off v1/v2

If you remember (or actively avoided) PowerShell DSC v1.1 and v2, the friction points are easy to list:

• MOF compilation — you wrote PowerShell that compiled to MOF that the Local Configuration Manager (LCM) then enforced. Three layers of abstraction for what should be a simple “make this true” operation
• The LCM — a Windows service that managed state, with its own configuration, scheduling, and lifecycle. Misbehave and the diagnostics were… not friendly
• Windows-first, cross-platform second — DSC for Linux existed but was effectively a separate world with its own quirks
• PSDesiredStateConfiguration handoff — starting with PowerShell 7.2, the module got pulled out of the PowerShell package into the PowerShell Gallery as a separate install. Not a big deal in isolation, but a signal that PSDSC was being treated as legacy rather than core

The result was a configuration tool that mostly worked, mostly on Windows, but rarely felt good to live with. By the time most teams were genuinely doing IaC, tools like Ansible and Bicep were where the energy was.

What DSC v3 actually changed

DSC v3 — officially “Microsoft DSC” rather than “PowerShell DSC” — is a clean break. The architectural shifts that matter:

It’s a standalone tool, not a PowerShell module. DSC v3 ships as a single command-line binary (dsc) written in Rust. It runs on Windows, Linux, and macOS without external dependencies. PowerShell isn’t a prerequisite — though you can absolutely use PowerShell-based resources via the PSDSC adapter.

No MOF, no LCM. Configuration documents are written in YAML or JSON. There’s no compilation step, no Local Configuration Manager service, no MOF files. You run dsc config set against a document and the engine does the thing.

Resources are language-agnostic. A DSC resource in v3 is anything that produces structured JSON on stdout in response to a few defined inputs. Write a resource in Rust, Go, Python, PowerShell, or a shell script — DSC doesn’t care. Resource manifests describe what a resource accepts and returns, and DSC handles the orchestration.

Designed for higher-order tools. DSC v3 isn’t trying to be the user-facing automation tool. Microsoft is explicit that it’s a platform for things like WinGet, Microsoft Dev Box, and Azure Machine Configuration to call into. That doesn’t mean you can’t use dsc directly — you absolutely can — but the design centre of gravity has shifted to “this is a configuration substrate” rather than “this is your end-to-end automation tool.”

Compatibility with PSDSC resources. Existing PowerShell DSC resources still work through the PSDSC adapter, so the catalogue of community resources isn’t wasted. The adapter has been the bridge for the in-between period, and DSC v3.2 starts adding first-class Windows resources that don’t need the adapter at all.

What it looks like in practice

Installation is one command. On Windows:

winget install --id 9NVTPZWRC6KQ --source msstore

On Linux or macOS, grab the release archive and drop the contents on PATH.

A minimal configuration document, in YAML. It uses Microsoft.Windows/Service, one of the built-in Windows resources that arrived in v3.2 — you’d think a service resource has always been there, but on an older v3 it simply doesn’t exist:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: spooler
  type: Microsoft.Windows/Service
  properties:
    name: Spooler
    startType: Automatic

Mind the casing on the values: startType only accepts PascalCase (Automatic, Disabled, …). Lowercase fails schema validation — something I found out the hard way in the v3.2 post.

And the commands you’ll actually use:

# List installed resources
dsc resource list
# Get the current state of one resource
dsc resource get --resource Microsoft.Windows/Service --input '{"name":"Spooler"}'
# Apply a configuration
dsc config set --file config.yaml
# Preview what an apply would do
dsc config set --what-if --file config.yaml

Here’s what dsc resource get returned for the Spooler on my machine (trimmed):

actualState:
  name: Spooler
  displayName: Print Spooler
  _exist: true
  status: Running
  startType: Automatic
  executablePath: C:\Windows\System32\spoolsv.exe
  logonAccount: LocalSystem

You might expect JSON back, since that’s what resources speak under the hood — but in the console DSC shows you YAML. Same structured data, just easier on the eyes.

That’s the whole interaction model. No compile step, no LCM scheduling, no remoting setup. Run the binary against a document, get structured output back.

Where v3 sits today

DSC v3 went GA via the v3.0.0 release and has shipped point releases steadily since. v3.2 — released at the end of April 2026 — is the most substantive update so far: first-class Windows resources, an experimental Bicep integration, a properly grown-up expression language. The first v3.3 preview was already out on 7 May, so the next release is on its way.

If you’ve been waiting for DSC v3 to feel ready, v3.2 is a good moment to take another look — for the standalone post on what v3.2 changes specifically, see here.

Documentation worth bookmarking:

• Microsoft DSC overview — the canonical entry point
• DSC JSON Schema reference — for understanding the wire format
• PowerShell/DSC repository — source, releases, issues

Update (October 2026): DSC v3.3.0 went GA on 17 September 2026, and the first v3.4 preview is already out.

Happy configuring 😊