PowerShell DSC 3.0: How Declarative Configuration Works

PowerShell Desired State Configuration (DSC) 3.0 is a command-line platform for describing and managing system configuration as data. It is useful to Windows administrators modernizing existing DSC deployments, as well as automation and platform engineers who need a consistent way to query, test, or set configuration across operating systems. The name is familiar, but DSC 3.0 is architecturally different from legacy PowerShell DSC: it does not depend on PowerShell or run a background Local Configuration Manager (LCM).

Why PowerShell DSC 3.0 Is Being Discussed

Configuration tools often share a goal but use different execution models. Scripts tell a machine which steps to perform; declarative configuration describes the result that should exist. DSC 3.0 brings this desired-state model into a standalone executable that can use resources written in different languages. The Microsoft DSC overview describes it as cross-platform and independent of PowerShell.

That change matters to teams that know DSC mainly as a Windows feature based on PowerShell configuration scripts and the LCM. DSC 3.0 keeps the broad idea of defining state, but uses YAML or JSON documents, invokes resources through a command-line interface, and can adapt many existing PowerShell DSC resources. Understanding which generation a guide or script targets prevents operators from assuming that an old configuration file, service, or remediation schedule automatically carries over.

What Is PowerShell DSC 3.0?

DSC 3.0 is an open-source command-line application that coordinates resources to inspect and manage components of a system. A configuration document says what should be true; a resource knows how to read or change one particular component, such as a registry key, file, service, or application setting. DSC brings those resource operations together and reports what it found or changed.

The distinction between intent and implementation is central. A document can specify that a setting should have a particular value without embedding all the operating-system commands needed to change it. The selected resource implements those operations. Resources expose supported properties and capabilities, such as retrieving state, testing it, or setting it. An orchestration system or operator can then decide when to run DSC and how to distribute configuration.

The PowerShell DSC project on GitHub describes DSC 3 as a declarative, idempotent command-line platform for Windows, Linux, and macOS. “Idempotent” means that applying the same desired state repeatedly should converge on the same result rather than creating a new change each time. That behavior depends on resources correctly implementing their operations; the word does not guarantee every script or resource is safe to repeat.

The Problem It Solves

Manual configuration and imperative scripts are difficult to keep consistent across fleets. A runbook may say to create a registry value or install a package, but different operators can perform those steps differently. Scripts also need logic to determine whether a change is already present, report drift, and avoid unnecessary or unsafe changes. Over time, machines that began with the same setup can diverge.

Desired-state management makes the target explicit and separates it from the mechanism. A resource can compare the current state with that target, report a difference, and—if it supports the operation—apply a correction. This is useful for repeatable provisioning, configuration checks, and controlled maintenance. It does not by itself provide inventory management, policy approval, scheduling, reporting dashboards, or fleet-wide orchestration; those responsibilities belong to the surrounding tools and processes.

How DSC 3.0 Works

A typical DSC run has four parts:

1. Configuration document: YAML or JSON identifies resource instances and their desired properties.
2. Resource discovery: DSC finds resource manifests and executables available on the machine, including adapters for compatible resources.
3. Operation: The caller asks DSC to get current state, test it against desired state, or set the desired state.
4. Results: DSC returns structured output indicating actual state, differences, changes, or errors.

The get, test, and set operations answer different questions. Get reads the current state. Test determines whether it matches the requested state. Set attempts to bring it into line. A resource may not implement every operation; DSC can synthesize a test for some resources by comparing the result of get with the desired properties. A configuration’s test result is therefore not the same as applying it.

Legacy DSC resources commonly used MOF, a management-object format standardized in the wider Common Information Model ecosystem. The DMTF’s CIM standards overview provides that standards context. DSC 3.0’s native resource manifests instead use JSON or YAML schemas; this does not mean that DSC 3.0 itself is a DMTF standard.

Components and Key Concepts

Resources are the units that interact with manageable state. A resource manifest describes its type, properties, and how DSC invokes it. Before writing a configuration, use dsc resource list to see which resources are actually available on the target machine. A resource available on one host may be missing on another.

Configuration documents combine resource instances into a desired-state description. Each instance has a name, type, and properties. Documents use structured data rather than the old PowerShell configuration syntax; they are not interchangeable with legacy configuration files.

Adapters bridge supported resource models. DSC includes adapters for PowerShell DSC resources, including a Windows PowerShell adapter for compatible resources. Adaptation is a migration path, not a guarantee that every old configuration feature or workflow behaves exactly as it did under an LCM.

The caller decides when DSC runs. That may be a person in a terminal, a deployment pipeline, or a higher-level configuration service. Because DSC 3.0 does not continuously run an LCM, repeated drift correction requires an external scheduler or orchestrator to call it.

Real-World Use Cases

• Image and machine provisioning: check or set baseline configuration while building a workstation, server, or development image.
• Configuration validation: run a test before a deployment or maintenance window to find differences without immediately applying them.
• Local operations: manage a small number of systems with explicit, reviewable configuration documents and command invocations.
• Cross-platform automation: use a common engine for resources across Windows, Linux, and macOS, where suitable resources exist for each platform.
• Existing Windows DSC estates: evaluate whether compatible resources can be invoked through an adapter while planning a gradual transition.

For Windows security work, DSC can complement baseline and compliance processes, but it does not define the security policy itself. The Windows security baseline automation guide discusses policy sources and assessment alongside automation tools. Teams comparing approaches can also review configuration management with Ansible.

Getting Started with DSC 3.0

Download the archive for your operating system and processor architecture from the DSC project’s latest releases, extract it, and add the directory containing the executable to PATH. The project release instructions are authoritative for the current package layout. Confirm that the executable is available, then list resources:

dsc resource list

The command displays the resources DSC discovers. On Windows, the built-in Microsoft.Windows/Registry resource can be used for a small, user-scoped example. Save the following as example.dsc.config.yaml:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Example user registry key
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\dsc\example\key
      _exist: true

First test the document. Testing reports whether the key matches the requested state; it does not intentionally apply the change:

dsc config test --file ./example.dsc.config.yaml

If the output and target are correct, set the state and read it back:

dsc config set --file ./example.dsc.config.yaml
dsc config get --file ./example.dsc.config.yaml

This example only requests a key under the current user’s registry hive. For machine-wide settings or resources that require elevated permissions, review the resource documentation and security context before running set. Treat configuration files as change requests: inspect their resource types and properties, test first, and use source control and peer review for production changes.

For common troubleshooting, use dsc resource list to confirm that the resource exists, inspect its exact type and required properties, and rerun dsc config test to see which values differ. Check the command’s error output and the resource’s own documentation when a manifest is present but an operation fails. A successful discovery does not prove that the current user has permission to change the resource or that all external dependencies are installed.

Common Misconceptions

“DSC 3.0 is just a new PowerShell module.” It is a standalone executable and can manage resources that do not use PowerShell. PowerShell compatibility is provided through adapters where appropriate.

“DSC 3.0 continuously fixes drift like the old LCM.” It does not run as an LCM service. A test or set operation happens when DSC is invoked; recurring enforcement requires an external scheduler or orchestration platform.

“Every old DSC configuration works unchanged.” The document format and execution model differ. Many PowerShell DSC resources can be adapted, but old configuration scripts and LCM settings are not automatically converted into DSC 3.0 documents.

“A passing test means the desired state was applied.” A test reports whether state matches. Use set to request changes, and then use get or another verification method to confirm the result.

Related Articles

• Windows automation with PowerShell
• Windows security baseline automation
• Configuration management with Ansible

Changelog and Last Updated

Initial publication. The overview and examples were checked against Microsoft’s DSC 3.0 documentation and project materials.