The 5 things you need to know what changed from Microsoft DSC 3.1 to 3.2

The Microsoft DSC v3.2 GA release is standing right at the door. With more than 14 previews between v3.1, which shipped last year, and the release that is now almost here, a lot has changed, and some of it may well have slipped past you.

That's usually how things go. Platforms have to evolve, or they lose relevance. But that doesn't happen all at once. It happens preview by preview, gathering feedback from users, and implementing it. A trace improvement here. A new discovery extension there. And all of a sudden, it looked like another integration path was dropped.

Looking at each of these features, they look pretty small in the release notes. Yet, looking at it all together, they tell a clear story. DSC v3.2 is not just another version bump. It is the release of the platform that starts to feel easier to discover and reason about.

In this blog post, we will look at five things that changed between DSC 3.1 and DSC 3.2, and why they matter as the platform moves toward GA.

1. PowerShell resources finally talk to DSC cleaner

One of the most overlooked features added in v3.2.0-preview.13. The PowerShell adapters were updated to automatically convert PowerShell streams into DSC traces. Why does that actually matter?

See, not all messages that originally came from DSC resources landed in DSC's tracing engine. Warnings, errors, verbose, and even debug messages weren't picked up because they weren't speaking the way the adapter could handle.

With the current implementation, resource authors can use their native PowerShell streaming semantics, while the other side (the engine) transforms the messages properly. The result is not just nicer logging, it's also for better observability.

2. Cleverly discover PowerShell resources with an extra tint

Remember, PowerShell resources are discovered through this adapter model. DSC's engine doesn't know anything about DSC resources, nor does it know about PowerShell. That's why this adapter was written. It teaches DSC's engine about PowerShell's subsystem.

But there were two fundamentally things that weren't that good, let's say so. Firstly, discovering resources was an expensive task. The adapter itself runs the Get-DscResource or looks at all $env:PSModulePath PowerShell modules. Secondly, none of the DSC resources actually provided a schema, keeping newcomers still figuring out how to provide the actual input.

Luckily, I was fortunate to build a discover extension. In simple terms, a discover extension allows you to retrieve additional resources outside DSC's boundary. With DSC's boundary, I mean the PATH and DSC_RESOURCE_PATH the engine uses to discover resources.

This dedicated extension is built in when you install DSC and does faster enumeration when modules ship resource manifests or an adapted manifest.

3. Adapted resource manifests are becoming the real contact

That instantly brings me to adapted resource manifests. DSC's adapted resource model is more mature than guessing things through an adapter. This manifest tells DSC precisely what it needs: what is the DSC resource about, which adapter it requires, which capabilities it supports, and, better yet, what properties it has.

Here's an example of an adapted resource manifest:

{
    "$schema": "https://aka.ms/dsc/schemas/v3/bundled/adaptedresource/manifest.json",
    "type": "MyModule/MyDscResource",
    "kind": "resource",
    "version": "1.0.0",
    "capabilities": ["get", "set", "test"],
    "description": "Manages widget configuration.",
    "author": "Gijs Reijn",
    "requireAdapter": "Microsoft.Adapter/PowerShell",
    "path": "MyModule.psd1",
    "schema": {
        "embedded": {
            "$schema": "http://json-schema.org/draft-07/schema#",
            "title": "MyDscResource",
            "type": "object",
            "properties": {
                "name": { "type": "string" },
                "enabled": { "type": "boolean" }
            },
            "required": ["name"],
            "additionalProperties": false
        }
    }
}

In other words, adapted resources are the way forward to reason about data itself. Include that with the PowerShell discover extension, and you're supercharging your resources through DSC's engine. If you want to learn more in detail, check out this article.

4. The sudden removal of Bicep, or did it?

Some folks were in shock when they saw the pull request from Steve that removed the Bicep extension. But it actually never was gone fully.

DSC couldn't cope with new features being added constantly at the Bicep side. That's where Andy Lee Jordan stepped in and created a JSON-RPC implementation, letting Bicep become the higher-order tool (HOT).

It's a sudden change, but don't worry; it's still there, you only need to install Bicep to do the work. Want to learn about the full story? Check out: https://www.idontlikeai.dev/bicep-never-left-the-peaceful-return-of-microsoft-dsc-support/

5. Don't we have AI enough?

Probably. But in DSC's landscape, I would not say that is a bad thing. DSC has already come a long way, and the shift to decouple DSC from PowerShell can make some people uneasy because it introduces a different set of concepts, tools, and expectations.

That's exactly one of the reasons why Steve implemented an MCP server. It gives you a new buddy to talk to and is one of those changes that can look experimental until you realize how much it reframes the platform. DSC is not only a CLI utility or a schema that you wire in your editor. Instead, it can present itself as an MCP so tools and agents can discover resources.

It moves DSC closer to a protocol-first future, where authoring assistance is not bolted on through one bespoke extension, but exposed through a general interface that modern tools already know how to consume.

Closing thoughts

Clearly, with some of these 5 features that I mentioned, it can look like DSC is becoming more stricter. But guess what, that's actually a good thing. There have been enough talks about integration tools. If there's one thing integration tools need, it's a strong contract that they can work on. And it also makes the platform easier to trust.