# DSC v3.2 — Built-in Windows Resources and the Bicep Bridge


[Microsoft Desired State Configuration v3.2](https://devblogs.microsoft.com/powershell/announcing-dsc-v3-2-0/) was released at the end of April, and unlike the usual point release, this one brings substantial changes. First-class Windows resources without the [PSDSC](https://learn.microsoft.com/en-us/powershell/dsc/reference/resources/microsoft/dsc/powershell?view=dsc-3.0) adapter dance, an experimental Bicep ↔ DSC bridge, and a properly grown-up expression language.

> If you haven't caught up on DSC v3 yet, start with my [DSC v3 primer](/2026-05-16-dsc-v3-primer/) — this post assumes you know what `dsc.exe` is and how a v3 configuration document is structured. For everything else that happened in PowerShell-land over the same window, see the [April roundup](/2026-05-13-powershell-roundup-april/).

<!--more-->

## Built-in Windows resources

The headline change is a set of native Windows resources that don't need the PSDSC adapter sitting in front of them. If you've ever had to wrestle the adapter just to manage a Windows service or a firewall rule, you'll appreciate this list:

- `Microsoft.Windows/Service` — Windows services
- `Microsoft.Windows/OptionalFeatureList` — Windows Optional Features (requires the ZIP package)
- `Microsoft.Windows/FeatureOnDemandList` — Features on Demand (also ZIP package)
- `Microsoft.Windows/FirewallRuleList` — Windows Firewall rules
- `Microsoft.OpenSSH.SSHD/sshd_config` — full `sshd_config` management
- `Microsoft.OpenSSH.SSHD/Subsystem` and `Microsoft.OpenSSH.SSHD/SubsystemList` — SSH subsystem entries
- `Microsoft.OpenSSH.SSHD/Windows` — Windows-specific SSH server config

The OpenSSH set is particularly nice — Windows OpenSSH config has historically been a small, fiddly thing to automate well, and having dedicated resources for it removes a lot of the friction.

You'd think they'd show up the moment you install DSC — the announcement says they're *"ready to use without additional installation"*. On my machine, though, none of the four appeared in `dsc resource list`. They *are* in the package; each manifest just carries a condition:

```json
"condition": "[not(equals(tryWhich('sshd'), null()))]"
```

In other words: DSC only offers the OpenSSH resources when it can find `sshd`. No OpenSSH Server installed, no OpenSSH resources — so if they're missing from your list, that's the first thing to check.

## DSC meets Bicep (experimentally)

This is the bit I find most interesting. DSC v3.2 ships a [gRPC](https://grpc.io/) server that lets [Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview) orchestrate DSC resources directly. The `dsc-bicep-ext` extension is included in the MSIX package and put on `PATH` for you.

What this practically unlocks: you can describe Azure resources *and* the in-guest configuration in the same Bicep file, with DSC handling the bit Bicep can't see (services, registry, `sshd_config`, etc.). It's still flagged experimental, and the official wording calls it *"the foundation for the Bicep to DSC integration"* — meaning more to come. It's a clear signal of where the team is taking this though.

## `--what-if` on `dsc resource set`

A small but useful addition: `--what-if` now works on `dsc resource set`, so you can preview what a single resource change will do without committing. The announcement demos it against the Windows service resource, and you'd think that's the one example guaranteed to work. It took me two attempts to find out it doesn't (yet).

First stumble: the announcement uses `"startType": "disabled"`, and DSC rejects that outright:

```
ERROR Schema: "disabled" is not one of "Automatic", "AutomaticDelayedStart" or 2 other candidates
```

The `startType` values are case-sensitive and PascalCase, so it has to be `Disabled`:

```powershell
dsc resource set --what-if --resource Microsoft.Windows/Service --input '{
    "name": "Spooler",
    "startType": "Disabled"
}'
```

Second stumble: with the casing fixed, 3.2.0 still refuses:

```
ERROR Not implemented: cannot process what-if execution type, as resource implements pre-test and does not support what-if
```

So `dsc resource set --what-if` exists, but `Microsoft.Windows/Service` doesn't support it in this release. It's a known gap — [issue #1506](https://github.com/PowerShell/DSC/issues/1506) was opened by someone going through the very same announcement example, and [a fix](https://github.com/PowerShell/DSC/pull/1507) is already open. In the meantime, `dsc config set --what-if` with a configuration document that uses the same resource *does* work, so that's the way to preview a service change for now.

Resource manifests can declare a `whatIfReturns` field for richer preview output — so authors of community resources get a way to make their `--what-if` story properly informative rather than a vague "something would change."

## Version pinning that actually pins

Configuration documents now support pinning to specific DSC and resource versions using the `version` directive and the new `requireVersion` field (which replaces `apiVersion`). [Semver](https://semver.org/) constraints — which is the version pinning experience you actually want.

You'd think you could copy the announcement's example straight in. It pins `Microsoft/OSInfo` to `^1.0` — but OSInfo ships as version **0.1.0**, so nothing matches and the whole document fails:

```
ERROR Error: Resource not found: Microsoft/OSInfo ^1.0
```

That does at least prove the pinning works: DSC errors out when it can't find a compatible version, rather than quietly using whatever is installed. Check the `Version` column in `dsc resource list` before pinning. The fix is a single line — pin OSInfo to `^0.1` (which, for a 0.x version, means `>=0.1.0, <0.2.0`):

```yaml
  requireVersion: '^0.1'
```

With that change the same document runs fine. The full version:

```yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
directives:
  version: '=3.2.0'
resources:
- name: os
  type: Microsoft/OSInfo
  requireVersion: '^0.1'
  properties: {}
- name: echo
  type: Microsoft.DSC.Debug/Echo
  requireVersion: '>=1.0.0, <1.3'
  properties:
    output: echo
```

## A smarter expression language

The expression language has grown up a fair bit. The additions worth knowing:

- **Lambda expressions** via `map()` and `filter()` — borrowed from [ARM template](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/syntax) syntax
- **`dataUri()` and `dataUriToString()`** — for embedding content directly into configurations
- **`reference()` inside `copy` loops** — you can now reference iterating resources properly
- **`requireVersion`** replacing `apiVersion`, as mentioned above

If you've ever found yourself wanting to filter a collection of resources mid-configuration without resorting to PowerShell preamble code, this is the change for you. Credit where it's due — these came largely from community contributor [@Gijsreyn](https://github.com/Gijsreyn), who shows up multiple times in the release notes.

## New extension capabilities

Two new extension types were added:

- **Import** — process arbitrary files as DSC configuration documents. The example given is processing [TOML](https://toml.io/) files; the spirit is "bring your own format"
- **Secret** — retrieve secrets at runtime via a new `secret()` configuration expression, so credentials don't have to be baked into manifests

Both are practical answers to real problems people have hit when using DSC v3 for actual work.

## Try it

On Windows via winget:

```powershell
winget install --id 9NVTPZWRC6KQ --source msstore
```

Or grab the ZIP for Windows, Linux, or macOS from the [PowerShell/DSC repository](https://github.com/PowerShell/DSC) and drop it on `PATH`. The [full announcement](https://devblogs.microsoft.com/powershell/announcing-dsc-v3-2-0/) has the complete list.

The first v3.3 preview was published on 7 May, barely a week after v3.2 went GA, so the cadence isn't slowing down.

> **Update (October 2026):** [DSC v3.3.0](https://github.com/PowerShell/DSC/releases/tag/v3.3.0) went GA on 17 September 2026, and the first [v3.4 preview](https://github.com/PowerShell/DSC/releases/tag/v3.4.0-preview.1) is already out. `--what-if` support for `Microsoft.Windows/Service` arrived in v3.3 ([PR #1507](https://github.com/PowerShell/DSC/pull/1507)).

Happy configuring 😊