This is the first post in a multi-part series about the new release of DSC.

We’re pleased to announce the General Availability of Microsoft’s Desired State Configuration (DSC) version 3.0.0.

This version marks a significant evolution in cloud-native configuration management for cross-platform environments. DSC is a declarative configuration and orchestration platform that defines a standard way of exposing settings for applications and services. It’s a tool for managing systems and applications by describing what they should look like rather than how to make it that way. DSC simplifies system, service, and application management by separating what to do from how to do it.

Benefits of DSC

• Declarative and Idempotent: DSC configuration documents are declarative JSON or YAML files that define the desired state of your system in a straight-forward way. They include the instances of DSC resources that need configuration. DSC ensures the system matches that state, repeatedly if needed, without making unnecessary changes.
• Flexible: DSC Resources define how to manage state for a particular system or application component. Resources can be authored in any language, not only PowerShell.
• Cross-Platform: DSC works on Linux, macOS, and Windows without needing extra tools or dependencies.
• Integratable: Designed to be easily integrated into existing configuration solutions. DSC returns schematized JSON objects for trace messages and command output. Tool developers and script authors can easily validate and parse the output for integration with other configuration tools and frameworks. DSC simplifies how you call it by accepting JSON from stdin for all configuration and resource commands. DSC resources include a manifest that defines the resource properties as a JSON schema and how to invoke the resource. You can reuse this definition across various toolchains for tighter integration with DSC.
• Backwards compatible: This release of DSC can use all existing PowerShell 7 and Windows PowerShell DSC resources.

With DSC, you can:

• Create configuration files that define how your environment should look.
• Write DSC resources in any programming language to manage your systems and applications.
• Invoke DSC resources to perform specific actions.
• Define a standard way for applications and services to make their settings discoverable and usable. This means that you can discover and invoke resources directly, even without DSC.

Differences from PowerShell DSC

Windows PowerShell 5.1 includes PowerShell Desired State Configuration (PSDSC). We refer to as classic DSC, which encompasses PSDSC v1.1 and v2. However, DSC can use any classic DSC resources that exist today, including the script-based and class-based PSDSC resources. You can use PSDSC resources in DSC with both Windows PowerShell and PowerShell.

The release of DSC is a major change to the DSC platform. DSC differs from PSDSC in a few important ways:

• DSC no longer includes or supports the Local Configuration Manager (LCM).
• DSC doesn’t depend on PowerShell. You can use DSC without PowerShell installed and manage resources written in bash, python, C#, Go, or any other language.
• DSC doesn’t include a local configuration manager. DSC is invoked as a command-line tool. It doesn’t run as a service.
• The PSDSC configuration documents used Managed Object Format (MOF) files. Few tools were able to parse MOF files, especially on non-Windows platforms. DSC isn’t compatible with MOF files, but you can still use all existing PSDSC resources.
• DSC is built on industry standards, such as JSON, JSON Schema, and YAML. These standards make DSC easier to integrate into tools and workflows compared to PSDSC.
• DSC configuration documents are defined in JSON or YAML. The configuration documents use expression functions to enable dynamic values, rather than using PowerShell code to retrieve environment variables or join strings.
• DSC supports supplying parameter values for configuration documents at runtime either as JSON or by pointing to a parameters file instead of generating a configuration MOF file before applying the configuration.
• Unlike PSDSC, DSC returns strongly structured output. This structured output adheres to a published JSON Schema, making it easier to understand the output and to integrate it into your own scripts, reporting, and other tooling. When you test or set resources and configurations with DSC, the output tells you how a resource is out of the desired state or what DSC changed on your system.

Features of DSC

• Groups: DSC supports a new resource kind that changes how DSC processes a list of resources. Resource authors can define their own group resources and configuration authors can use any of the built-in group resources.The DSC repository has an example that shows how you can group resources together and use the dependsOn keyword to define the order those groups are applied in a configuration.
• Assertions: Use the Microsoft.Dsc/Assertion (a special group resource) to validate the environment before running the configuration.The DSC repository has an example that shows how you can use an assertion to manage a resource that should only run on a specific operating system.
• Importers: DSC supports a new resource kind that pulls in a configuration from an external source for reuse in the current configuration document. Resource authors can define their own importer resources and configuration authors can use the built-in Microsoft.DSC/Include resource.The DSC repository has an example that shows how you can use the Microsoft.Dsc/Include resource to reuse a separate configuration document file, enabling you to compose a complex configuration from smaller, simpler configuration documents.
• Exporting: DSC supports a new operation that resources can implement to return the list of all existing instances of that resource. You can use the dsc resource export command to get every instance of that resource on a machine. Use the dsc config export command to look up a set of resources and return a new configuration document containing every instance of those resources.
• Configuration functions: DSC configuration documents support a set of functions that enable you to change how DSC processes the resources.The DSC repository has an example that shows how you can reference the output from one resource in the properties of another.

Support lifecycle

DSC follows semantic versioning. The first release of DSC, version 3.0.0, is a Stable release.

The first release of DSC, version 3.0.0, is a Stable release. Patch releases update the third digit of the semantic version number. For example, 3.0.1 is a patch update to 3.0.0. Stable releases receive patches for critical bugs and security vulnerabilities for three months after the next Stable release. For example, version 3.0.0 is supported for three months after 3.1.0 is released.

Always update to the latest patch version of the release you’re using.

Next steps

As I mentioned at the top of this post, this was the first in a series of posts about the new DSC. For the subsequent posts:

• DSC refers to Desired State Configuration (DSC) v3.0.0
• PSDSC refers to PowerShell Desired State Configuration (PSDSC) v1.1 and v2

Now you are ready for the next post: Get Started with Desired State Configuration v3.0.0 (DSC)

Call to action

For more information about Desired State Configuration v3.0 (DSC), visit the DSC documentation. We value your feedback. Stop by our GitHub repository and let us know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell