Desired State Configuration v3.2.0¶
What it is¶
Microsoft Desired State Configuration (DSC) v3.2.0 reached General Availability on April 29, 2026, announced on the PowerShell DevBlog by Jason Helmick (Sr. Product Manager, PowerShell team).
DSC v3 is the cross-platform, declarative configuration platform that succeeded the original PowerShell-coupled DSC. The v3.2 release is incremental but substantial: new built-in Windows resources, experimental Bicep integration, a richer expression language, version pinning, custom functions, and continued PowerShell-adapter improvements. The release explicitly credits the WinGet team and community contributors (notably @Gijsreyn for lambda/map/filter expressions and the experimental PowerShell discovery extension, and @mimachniak for adapter credential handling).
What's new in v3.2¶
New built-in Windows resources¶
A noticeably broader out-of-the-box Windows surface:
Microsoft.Windows/Service— manage Windows servicesMicrosoft.Windows/OptionalFeatureList— Windows optional features (ZIP package only for now)Microsoft.Windows/FeatureOnDemandList— Features on Demand (ZIP package only)Microsoft.Windows/FirewallRuleList— Windows Firewall rulesMicrosoft.OpenSSH.SSHD/sshd_config— entire SSH server configMicrosoft.OpenSSH.SSHD/SubsystemandMicrosoft.OpenSSH.SSHD/SubsystemList— SSH subsystem entriesMicrosoft.OpenSSH.SSHD/Windows— Windows-specific SSH settings (e.g. default shell)
All ship inside the DSC package; no extra install step is needed for those not flagged ZIP-only.
Bicep integration via gRPC (experimental)¶
DSC v3.2 introduces a gRPC server that lets Bicep orchestrate DSC resources directly, bypassing ARM entirely. The dsc-bicep-ext extension is now included in the MSIX package and exposed on PATH. This is positioned as the foundation for Bicep-to-DSC integration — i.e. write configuration in Bicep, have Bicep drive DSC resources locally over gRPC.
This is the first practical bridge between Azure's declarative IaC language (Bicep) and DSC's local configuration engine.
Extended --what-if support¶
Prior to v3.2, --what-if only worked at the configuration level (dsc config set --what-if — runs all resources in preview mode). v3.2 adds --what-if to dsc resource set, so you can dry-run a single resource in isolation:
dsc resource set --what-if --resource Microsoft.Windows/Service `
--input '{ "name": "spooler", "startType": "disabled" }'
Resource manifests can declare whatIfReturns to describe what a what-if call returns, enabling richer preview output across resources.
Version pinning¶
Configuration documents can now pin both the DSC engine version and individual resource versions:
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
directives:
version: '=3.2.0' # exact engine version
resources:
- name: os
type: Microsoft/OSInfo
requireVersion: '^1.0' # >=1.0.0 and <2.0.0
properties: {}
- name: echo
type: Microsoft.DSC.Debug/Echo
requireVersion: '>=1.0.0, <1.3'
properties:
output: echo
DSC picks the latest version of a resource that satisfies the constraint; if none qualifies, it errors out instead of silently degrading. When the version directive is present, DSC also raises an error if the running engine is incompatible. Prior to v3.2, DSC always used whatever resource version it found, which made reproducibility brittle.
Expression language improvements¶
- Lambda expressions with
map()andfilter()(ARM-syntax compatible). dataUri()anddataUriToString()functions.reference()is now usable insidecopyloops.requireVersionreplacesapiVersionfor version requirements.
These reduce duplication across resources and bring DSC's expression layer closer to ARM/Bicep ergonomics.
Adapter improvements¶
- Adapted resource manifests are now supported by the PowerShell adapters — authors can ship a manifest that prevents adapters from doing heavy discovery.
- Automatic conversion of PowerShell streams to DSC traces — resource authors get tracing "for free" via the standard
Write-*cmdlets. - Fix for passing credentials to adapted PSDSC resource instances.
Metadata and execution improvements¶
Microsoft.DSCmetadata is now split into directives and executionInformation — cleaner separation of intent vs context._refreshEnvresource metadata updates Windows environment variables during deployment without requiring a reboot.- Resource manifests can specify
requireSecurityContextper operation — preventing the common surprise whereget/testworks butsetfails with access denied. - Resources and extensions can be marked deprecated, with a runtime message.
New extension capabilities¶
Two new extension types in v3.2:
importcapability — an extension can process arbitrary files as DSC configuration documents. The blog's example is a TOML file (example.dsc.toml) being transformed into a standard YAML/JSON DSC document at the point ofdsc config *invocation. DSC inspects the file extension; if no extension claims it, DSC falls back to parsing as a native config doc.secretcapability — an extension can retrieve secrets at runtime. Paired with a newsecret()configuration expression that resolves secrets by name. This pushes secret handling out of the core engine, so it can integrate with arbitrary secret backends without bloating DSC itself.
Experimental PowerShell discovery extension¶
A new discovery extension finds DSC resources inside PowerShell modules — both resource manifests and adapted resource manifests. The key consequence: resource authors can ship DSC resources written in PowerShell that are not PSDSC resources — for example, a resource implemented as a PowerShell script, provided the module includes a valid manifest.
Bug fixes (selected)¶
- Duplicate resources no longer appear in
dsc resource list. - Attempting to use DISM resources via Appx now raises a clear error (previously a silent failure).
executionInformationis now correct in config-export results.- Discovery failures on unsupported manifests are handled gracefully.
Installation¶
On Windows, prefer the Microsoft Store via WinGet for automatic updates:
winget search DesiredStateConfiguration --source msstore
# stable
winget install --id 9NVTPZWRC6KQ --source msstore
# preview
winget install --id 9PCX3HX4HZ0Z --source msstore
On Windows, Linux, or macOS the ZIP package from the PowerShell/DSC GitHub repo is the alternative — download, unzip, add to PATH.
Support lifecycle¶
- DSC follows semantic versioning.
- v3.2.0 is the current stable release as of April 29, 2026.
- Patch releases (3.2.1, 3.2.2, ...) carry critical bug and security fixes.
- Each stable release is supported for three months after the next stable release ships. So v3.2.0 will be supported until three months after v3.3.0 GA.
- Always update to the latest patch version of the release stream you are on.
Previews of v3.3 begin shortly after v3.2.0 GA.
Limitations / Caveats¶
- Bicep-via-gRPC is experimental — the API surface and behaviour may change before GA. Don't bet production IaC on it yet.
- PowerShell discovery extension is experimental — likewise.
- Two of the new Windows resources (
OptionalFeatureList,FeatureOnDemandList) require the ZIP package rather than the MSIX/Store install. Mixed-distribution environments need to account for this. - The
secret()expression is only as good as the secret-extension implementation behind it — the core engine doesn't validate secret lifecycle, rotation, or scope. Pick a vetted secret extension. - Single-source reference page (the official Microsoft DevBlog announcement). Confidence is high because it is a first-party release announcement, but watch for follow-up documentation as community-authored resources catch up to the new manifest features.
- The original PowerShell-coupled DSC (v1/v2, "PSDSC") and DSC v3 are different platforms — adapter improvements in v3 do not retroactively help legacy DSC pull-server / LCM workflows.
Sources¶
- Announcing Microsoft Desired State Configuration v3.2.0 — PowerShell DevBlog, April 29 2026 (Jason Helmick, Sr. PM, PowerShell team)
Changelog¶
- 2026-05-18 — Page created from the PowerShell DevBlog announcement of DSC v3.2.0 GA dated 29 April 2026. Single official Microsoft devblog source; confidence rated high based on first-party authorship and the release-announcement nature of the post.