DSCv3: Microsoft's Desired State Configuration rebuilt as a cross platform CLI

What DSCv3 is, in the project's own terms

DSCv3 is the latest iteration of Microsoft's Desired State Configuration platform, and it is an open source command line application that abstracts the management of software components declaratively and idempotently.

The three words in that sentence are the design. Declaratively means you state what should be true and the tool works out the steps. Idempotently means applying the same configuration twice leaves the same result as applying it once, which is the property that lets a configuration be re-applied on every run without fear. And the abstraction of software components into resources is what makes the whole thing extensible without the tool knowing anything about what it is managing.

It runs on Linux, macOS and Windows without any external dependencies, which is a notable claim for a Microsoft configuration tool that grew out of a Windows feature.

The readme then lists what you can do with it. Author resources to manage your systems in any language. Invoke individual resources. Create configuration documents that define the desired state of a system.

That last bullet is the one that matters for anyone coming from the old platform. Configuration documents were PowerShell scripts that were executed to produce a result. Under DSCv3 they are data files, JSON or YAML, and they are documents in the sense of the word rather than programs.

The repository is Rust, MIT licensed, and the primary language is recorded as Rust. The recent releases are v3.3.0 from 2026-09-17, v3.4.0-preview.1 from 2026-09-10 and v3.3.0-rc.2 from 2026-08-24, so the stable line is 3.3 and the next minor is out in preview. The last push was on 2026-10-19.

The readme also carries the standard project furniture, a contributing guide, a code of conduct, a security policy and a note welcoming code contributions.

Five differences from PowerShell DSC

The readme has a section titled differences from PowerShell DSC, and it lists five things that changed. Each one is a deliberate design decision rather than an implementation detail.

The first is that DSCv3 doesn't depend on PowerShell. You can use DSCv3 without PowerShell installed and manage resources written in bash, python, C#, Go, or any other language. That is the change with the widest consequences, because it moves the tool from a Windows administration feature to a genuinely cross platform one.

The second is subtler and worth reading closely: DSCv3's use of PowerShell based resources does not depend on the PSDesiredStateConfiguration module. So the old module is not a hard dependency of the new platform, which is what allows the PowerShell-free claim to hold in practice rather than only in principle.

The third is that DSCv3 doesn't include a local configuration manager. DSCv3 is invoked as a command. It doesn't run as a service. That is a significant departure from how DSC worked, where a local configuration manager was a Windows service that responded to configuration requests. A command line tool has no startup cost, no service to install, no state left behind on the machine, and it fits the model of infrastructure as code where a run happens on demand.

The fourth and fifth are the format changes. Non-PowerShell resources define their schemas with JSON files, not MOF files. And configuration documents are defined in JSON or YAML files, not PowerShell script files. MOF was the old data format and JSON schema is the new one, so a resource author writes a JSON schema describing the resource's structure and its outputs rather than generating a compiled MOF document.

The readme then draws the important distinction, and this is the part that determines whether a migration is feasible. While DSCv3 represents a major change to the DSC platform, DSCv3 is able to invoke PowerShell DSC Resources, including script-based and class-based DSC Resources, as they exist today. The configuration documents aren't compatible, but all published PowerShell DSC Resources are. You can use PowerShell DSC resources in DSCv3 with both Windows PowerShell and PowerShell.

So the break is at the document layer and not at the resource layer. Existing resources continue to work, which means the migration path is to rewrite the configuration documents rather than to rewrite every resource.

Installing it and getting oriented

Installation is deliberately plain, and the readme gives three steps.

Download the latest release from the repository, expand the release archive, and add the folder containing the expanded archive contents to the PATH. There is no installer, no package manager requirement and no configuration wizard, which follows from the decision that DSCv3 is invoked as a command rather than installed as a service.

For anyone building or testing from source, the readme points at the Contributing Guide.

The exploration section is aimed at two different audiences and says so. If you are new to DSC or configuration management, the readme recommends reviewing the documentation, which links to the Microsoft Learn overview for DSC v3. If you are already familiar with DSC or just want to start experimenting with v3, it recommends the Samples repository and the accompanying tutorial site.

That second recommendation carries an extra instruction, and it is a good sign about the project's stage. The Samples repo is ready to accept pull requests, which the readme calls a great way to contribute while v3 is in early phases of development. So the sample set is both documentation and an open contribution target, and the tutorial site is where you are walked through them.

The readme also says the documentation and the samples are the place to start, rather than the source, which is the sensible ordering for a project whose implementation is large but whose interface is small.

The schemas, and why they are the integration surface

The integration section is the most interesting part of the readme, because it explains how DSCv3 is meant to be used by other tools.

DSCv3 is a platform tool that abstracts the concerns for defining and invoking resources. Higher order tools, like Azure Machine Configuration, Azure Automanaged VM, and WinGet, are early partners for DSCv3 as orchestration agents.

The word agents is doing work there. DSCv3 is not trying to be a configuration management system with a user interface and a pull model. It is a lower layer, something a larger tool calls to reconcile a piece of state, and the higher order tools are the ones deciding when and what to reconcile.

The mechanism that makes this possible is JSON schemas. DSCv3 uses JSON schemas to define the structure of resources, configuration documents, and the outputs that DSCv3 returns. These schemas make it easier to integrate DSCv3 with other tools, because they standardize and document how to interface with DSCv3.

That is a sound design for a platform component. A caller that wants to know what a given resource type accepts, and what shape the result comes back in, can read a schema rather than reverse-engineering a command's output. And because the same schema description covers inputs and outputs, a caller can validate before invoking and parse afterwards without two separate contracts to keep in step.

The schemas are also what makes the cross-language story consistent. If a resource is written in Go and another in Python, and both are described by JSON schemas, then a tool orchestrating them does not need to know which language produced them. The schema is the common denominator, and the readme's emphasis on standardizing and documenting the interface is the reason to believe that was the intent rather than a convenience.

The top level of the repository shows the scale of the effort behind this. There is a schemas/ directory, a dsc/ directory for the core, an adapters/ directory, a lib/ directory holding several shared libraries, a resources/ directory with a separate crate per resource type, an extensions/ directory, a tools/ directory, an archive/ directory, a packaging/ directory, a pal/ directory, a y2j/ directory, grammars/ with tree-sitter grammars for DSC expression and SSH server config, and an rfc/ directory.

The workspace layout and the resources it ships

The Cargo.toml shows the workspace structure, and it is the clearest picture of what the project contains.

The core is the dsc crate, with dsc-bicep-ext alongside it, which suggests an extension for Bicep, the Microsoft infrastructure-as-code language. The lib/ directory holds the shared libraries: dsc-lib-jsonschema and dsc-lib-jsonschema-macros for the schema layer, dsc-lib-osinfo for operating system detection, dsc-lib-pal for the platform abstraction layer, dsc-lib-registry for registry access, dsc-lib-security_context, dsc-lib-telemetry and dsc-lib itself. The pal directory at the top level is presumably the platform abstraction that the library sits on.

The resources/ directory is the part that shows the scope, because there is one crate per resource type. The list includes dism_dsc for Windows deployment image servicing, dscecho which is evidently a trivial resource for testing, file_dsc for managing files, osinfo, process, registry, runcommandonset for running a command at set time, sshdconfig for configuring the SSH daemon, windows_firewall, windows_service and WindowsUpdate, and environment_variable.

The platform spread is instructive. The Windows-specific resources are numerous, which makes sense for a project with Microsoft heritage, but file, process, osinfo, sshdconfig and environment_variable are cross platform or at least portable, and the presence of the sshdconfig resource alongside the grammars/tree-sitter-ssh-server-config grammar tells you the project takes server configuration seriously on the Unix side.

The grammars/ directory holds two tree-sitter grammars, one for DSC expression and one for SSH server config. Tree-sitter grammars are incremental parsers, and having them in the workspace means the configuration expression language has a real parser rather than a regular expression approximation.

There is also an adapters/ directory with a group_policy_template adapter, an archive/ directory, a packaging/ directory, an extensions/ directory, tools/ containing dsctest and test_group_resource, an xtask/ directory for build automation, and a y2j/ directory, whose name likely refers to a YAML to JSON conversion utility.

Two directories at the top level suggest a working practice worth noticing. The rfc/ directory holds request for comments, which is how a platform project handles design proposals that need to be agreed before implementation. And the examples/ directory has a single entry, examples/extensions/, so the extension mechanism has at least one worked example in the tree.

Editorial conclusion

Adopt DSCv3 if you are building configuration management for infrastructure that spans Linux, macOS and Windows and you want to write resources in the language your platform team already uses. Do not adopt it expecting your existing PowerShell DSC configuration documents to work, because the readme is explicit that the documents are not compatible even though the published resources are. Before you commit, read the schemas and the samples, and note that the version line is still in preview at v3.4.0-preview.1 alongside the stable v3.3.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PowerShell/DSC on GitHub
4. README
5. Releases