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