Microsoft DSC v3.2.0: nuove risorse Windows, version pinning e integrazione Bicep
Cos’è Microsoft DSC v3 e perché è importante
Microsoft Desired State Configuration (DSC) è uno strumento di gestione della configurazione che permette di descrivere come deve essere configurato un sistema Windows o Linux — quali servizi devono essere in esecuzione, quali regole firewall applicare, quali funzionalità installare — e di applicare o verificare automaticamente quella configurazione. Con DSC v3, Microsoft ha riscritto l’engine da zero rispetto alla versione 2.x integrata in PowerShell, separando nettamente il motore DSC dai moduli PowerShell e aprendo la strada al supporto multi-piattaforma e multi-linguaggio.
Il 29 aprile 2026, il team PowerShell ha annunciato la General Availability di DSC v3.2.0. Questa release porta con sé risorse Windows native, l’integrazione sperimentale con Bicep via gRPC, il version pinning, un linguaggio di espressioni più ricco e miglioramenti agli adapter PowerShell. Vediamo in dettaglio cosa cambia per i sistemisti e gli amministratori di sistema che adottano DSC nei loro ambienti.
Come installare DSC v3.2.0
La modalità di installazione più semplice è tramite WinGet:
winget install --id Microsoft.DSC --version 3.2.0
In alternativa è disponibile un pacchetto MSIX e un archivio ZIP per ambienti disconnessi o air-gapped. Il pacchetto ZIP è necessario per le risorse OptionalFeatureList e FeatureOnDemandList che, per il momento, non sono incluse nel pacchetto MSIX.
Nuove risorse Windows built-in
Una delle novità più attese di DSC v3.2.0 è l’espansione significativa delle risorse Windows native, ovvero risorse incluse direttamente nel pacchetto DSC e utilizzabili senza installazioni aggiuntive.
Le nuove risorse disponibili sono le seguenti:
- Microsoft.Windows/Service — gestione dei servizi Windows (stato, tipo di avvio, account di esecuzione)
- Microsoft.Windows/OptionalFeatureList — gestione delle funzionalità opzionali di Windows
- Microsoft.Windows/FeatureOnDemandList — gestione delle Features on Demand (FoD)
- Microsoft.Windows/FirewallRuleList — gestione delle regole del Windows Firewall
- Microsoft.OpenSSH.SSHD/sshd_config — gestione dell’intera configurazione del server SSH
- Microsoft.OpenSSH.SSHD/Subsystem e SubsystemList — gestione dei sottosistemi SSH
- Microsoft.OpenSSH.SSHD/Windows — configurazione Windows-specifica del server SSH (es. shell predefinita)
Un esempio pratico: per assicurarsi che il servizio Print Spooler sia disabilitato (pratica comune per ridurre la superficie d’attacco), basta ora scrivere:
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: DisabilePrintSpooler
type: Microsoft.Windows/Service
properties:
name: spooler
startType: disabled
state: stopped
Version pinning: configurazioni stabili e riproducibili
Una delle criticità di DSC v2 era la mancanza di un meccanismo affidabile per legare una configurazione a una specifica versione delle risorse. In ambienti enterprise con molti server e deployment automatizzati, una risorsa aggiornata poteva cambiare comportamento inaspettatamente.
DSC v3.2 risolve questo problema introducendo il version pinning sia a livello di documento di configurazione che a livello di singola risorsa. È possibile fissare la versione di DSC richiesta con la direttiva version e la versione di ogni risorsa con il campo requireVersion, usando la stessa sintassi semantica di npm/nuget:
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
directives:
version: '=3.2.0' # Questa configurazione richiede esattamente DSC 3.2.0
resources:
- name: os
type: Microsoft/OSInfo
requireVersion: '^1.0' # Versioni >= 1.0.0 e =1.0.0,
Se sul sistema non è disponibile una versione compatibile della risorsa, DSC solleva un errore esplicito invece di procedere in silenzio con una versione incompatibile. Questo rende le configurazioni DSC molto più affidabili nei pipeline CI/CD.
Supporto –what-if sulle singole risorse
Il flag --what-if esiste già da versioni precedenti per il comando dsc config set, ma era limitato all’esecuzione dell’intera configurazione. Con DSC v3.2, l’operazione di preview è disponibile anche sul comando dsc resource set, permettendo di testare il comportamento di una singola risorsa prima di applicarla:
dsc resource set --what-if \
--resource Microsoft.Windows/Service \
--input '{ "name": "spooler", "startType": "disabled" }'
Questo è particolarmente utile in fase di sviluppo di nuove risorse o durante troubleshooting di configurazioni complesse.
Integrazione sperimentale con Bicep via gRPC
La novità più ambiziosa di questa release è l’introduzione di un server gRPC in DSC, che permette a Bicep di orchestrare direttamente le risorse DSC senza passare per Azure Resource Manager (ARM). L’estensione dsc-bicep-ext è ora inclusa nel pacchetto MSIX e disponibile nel PATH di sistema.
In pratica, questo significa che sarà possibile scrivere configurazioni DSC nella sintassi Bicep, sfruttando il tooling e le funzionalità del linguaggio (modularità, parametri tipizzati, linting) per gestire la configurazione di sistema. L’integrazione è attualmente marcata come sperimentale, ma rappresenta una direzione strategica importante: avvicinare la gestione della configurazione di sistema agli strumenti Infrastructure-as-Code già adottati dagli ambienti Azure.
Miglioramenti al linguaggio di espressione
I documenti di configurazione DSC v3.2 supportano ora un linguaggio di espressione più ricco, che riprende in parte la sintassi ARM/Bicep:
- Lambda expressions con le funzioni
map() e filter() - Funzioni
dataUri() e dataUriToString() per la gestione di contenuti encodati - Utilizzo di
reference() all’interno di loop copy secret() per il recupero di segreti a runtime tramite estensioni dedicate
Il campo requireVersion sostituisce il precedente apiVersion per specificare i requisiti di versione, uniformando la sintassi con i nuovi meccanismi di pinning.
Adapter PowerShell: trace automatica e manifest adattati
Per chi utilizza risorse PowerShell esistenti tramite gli adapter PSDSC, DSC v3.2 porta alcune novità significative. È stata aggiunta la conversione automatica degli stream PowerShell (Write-Verbose, Write-Warning, ecc.) in trace DSC, il che significa che le risorse esistenti partecipano automaticamente al modello di tracing senza modifiche al codice.
È stato inoltre corretto il passaggio di credenziali alle istanze di risorse PSDSC adattate, un bug che causava problemi in ambienti con configurazioni di sicurezza elevate.
Conclusione
DSC v3.2.0 consolida la piattaforma DSC v3 con funzionalità concrete e richieste dalla community: risorse Windows native, version pinning per deployment riproducibili, preview granulare con --what-if e l’avvio di un’integrazione Bicep che promette di semplificare notevolmente la gestione IaC negli ambienti Microsoft.
Per chi gestisce ambienti Windows Server, Intune o pipeline DevOps su infrastruttura Microsoft, vale la pena iniziare a esplorare DSC v3.2 e valutare la migrazione dalle configurazioni DSC v2, la cui architettura è ormai considerata legacy.
Fonte: Announcing Microsoft Desired State Configuration v3.2.0 – PowerShell Team Blog
This post announces the General Availability of Microsoft Desired State Configuration (DSC) v3.2.0, with new Windows resources, Bicep gRPC integration, WhatIf support, expression language improvements, and adapter enhancements.
Jason Helmick (PowerShell Team)
Kevin Beaumont
in reply to Kevin Beaumont • • •Also, if your management has seen the widely reported "80% of Ransomware Attacks are AI-Driven" headline published by MIT, it was paid for by a vendor.
The paper is absolutely ridiculous. It describes almost every major ransomware group as using AI - without any evidence (it's also not true, I monitor many of them). It even talks about Emotet (which hasn't existed for many years) as being AI driven.
It cites things like CISA reports for GenAI usage.. but CISA never said AI anywhere.
reshared this
Kotes e Lesley Carhart reshared this.
Kevin Beaumont
in reply to Kevin Beaumont • • •The PDF is here and is absolutely crackers, MIT should be ashamed of themselves for letting this out the door.
cams.mit.edu/wp-content/upload…
No, REvil don't use AI to set ransom demands, CISA never said that, none of the sources cited said that, and they were running before the GenAI craze. It's just absolute nonsense, every page is.
reshared this
webhat e Oblomov reshared this.
Kevin Beaumont
in reply to Kevin Beaumont • • •If you want to know why MIT are working with Safe Security and what Safe Security are doing... they sell an AI product which they say is developed with MIT to solve the report they made up, after receiving 8 figures in VC funding.
reshared this
Kotes reshared this.
PhDog
in reply to Kevin Beaumont • • •Classic MIT.
@GossiTheDog
Kevin Beaumont
in reply to Kevin Beaumont • • •Update: MIT have removed the study after this thread.
reshared this
Lesley Carhart reshared this.
Kevin Beaumont
in reply to Kevin Beaumont • • •I have asked MIT these questions:
1) Is this paper being retracted?
2) How much money was paid to MIT Sloan by Safe Security?
3) What part did Safe Security play in the paper creation and review?
Kevin Beaumont
in reply to Kevin Beaumont • • •It isn't a new paper btw - e.g. senior MIT people have been using it in public at a cybersecurity conference earlier this year and linking to the now deleted PDF.
Kevin Beaumont
in reply to Kevin Beaumont • • •The Financial Times today links to the now deleted MIT study ft.com/content/56cb100e-7146-4…
If anybody knows anybody at the FT, could we please tell them it's fake?
Client Challenge
www.ft.comKevin Beaumont
in reply to Kevin Beaumont • • •MIT have also silently, without noting on the pages, started rewriting their website to remove references to their own work. They've also changed the URLs of the pages to remove references.
Left, before: archive.ph/SckSr
Right, after: mitsloan.mit.edu/ideas-made-to…
AI cyberattacks and three pillars for defense | MIT Sloan
MIT SloanKevin Beaumont
in reply to Kevin Beaumont • • •I'm coining another term - cyberslop.
Cyberslop is where trusted institutions use baseless claims about cyber threats from generative AI to profit, abusing their perceived expertise.
I'm also starting a series about it, called CyberSlop. Much more soon.
Kevin Beaumont
in reply to Kevin Beaumont • • •Kevin Beaumont
in reply to Kevin Beaumont • • •Several members of MIT sit on Safe Security's board -- who paid for the paper, including the person cited as the author of the paper.
Cat 🐈🥗 (D.Burch)
in reply to Kevin Beaumont • • •Kevin Beaumont
in reply to Kevin Beaumont • • •New by me - CyberSlop, where I look at orgs misusing GenAI fears to take from their own customers.
First threat actor - MIT and Safe Security go full cyberslop.
doublepulsar.com/cyberslop-mee…
CyberSlop — meet the new threat actor, MIT and Safe Security
Kevin Beaumont (DoublePulsar)RootWyrm 🇺🇦
in reply to Kevin Beaumont • • •K.C. Budd
in reply to RootWyrm 🇺🇦 • • •Tor Lillqvist
in reply to K.C. Budd • • •Ben Aveling
in reply to Tor Lillqvist • • •Maybe start here: theconversation.com/what-is-a-…
@tml @phreakmonkey @rootwyrm @GossiTheDog
What is a ‘toroidal propeller’ and could it change the future of drones? An expert explains
The ConversationK.C. Budd
in reply to Ben Aveling • • •@BenAveling @tml @rootwyrm Right, and you'll notiace that an "objective and scientific critique" this is *not*.
MIT's claims (and all the subsequent hype) around toroidal propellers being superior and quieter on drones were completely devoid of actual data or rigor, smelling almost entirely of snake-oil. Alternative propeller shapes have been in use for decades, this felt a lot like someone using MIT's name to push nonsense.
I've yet to find anything that substantiates it.
Matthew Skelton
in reply to Kevin Beaumont • • •"chasing the AI laser pointer" is my new favourite phrase 😁
🏮
Kevin Beaumont
Unknown parent • • •MIT Sloan's urgent review of their 80% of ransomware attacks are via Gen AI paper, progress update report after 4 months:
Kevin Beaumont
in reply to Kevin Beaumont • • •NosirrahSec 🏴☠️ guillotine enthusiast
in reply to Kevin Beaumont • • •Simon Rolfmore
in reply to Kevin Beaumont • • •