DSC v3.3 : RegistryList, Personalization et –what-if étendu

Le 17 septembre 2026, l’équipe PowerShell a publié Desired State Configuration (DSC) v3.3.0. On avait couvert la feuille de route de cette équipe pour 2026 dans cet article ; cette version en est la dernière étape publiée. Pas de refonte spectaculaire cette fois, mais trois ressources Windows qui comblent des manques réels, un adaptateur générique pour le registre, et une extension du mode --what-if à des ressources où tu en avais vraiment besoin.

Trois nouvelles ressources dans Microsoft.Windows

RegistryList : une instance, plusieurs clés

Jusqu’ici, gérer dix valeurs de registre voulait dire dix instances de Microsoft.Windows/Registry dans ta configuration. Microsoft.Windows/RegistryList regroupe un tableau d’entrées dans une seule ressource. Le binaire registry.exe sous-jacent gagne un commutateur --list pour ça, et les manifestes correspondants sont désormais rassemblés dans un fichier unique, registry.dsc.manifests.json, plutôt qu’éparpillés.

WindowsFeatureList : le même principe pour les rôles et fonctionnalités

Même logique appliquée à la gestion des fonctionnalités Windows (rôles, composants optionnels) : une liste plutôt qu’une ressource par fonctionnalité. Cette ressource est une contribution externe, signée Gijs Reijn — un bon rappel que DSC v3 reste un projet open source sur GitHub, pas seulement un produit Microsoft fermé.

Personalization : accent, thème clair/sombre, transparence

Nouvelle venue : une ressource qui pilote les réglages de personnalisation Windows — couleur d’accent, mode clair ou sombre, transparence. Utile pour standardiser l’image d’un poste de travail à grande échelle sans passer par une stratégie de groupe dédiée à chaque réglage.

Pour découvrir ce que chaque ressource accepte :

dsc resource list 'Microsoft.Windows/*'
dsc resource schema --resource Microsoft.Windows/Personalization

L’adaptateur de registre générique

Microsoft.Windows.Adapter/Registry fait le lien entre des propriétés JSON ordinaires et leur représentation dans le registre, en gérant lui-même les conversions. Pour l’instant, ces conversions ne couvrent que les types utilisés par Personalization — si tu écris une ressource personnalisée qui a besoin d’un type non géré, l’équipe invite explicitement à ouvrir une issue sur le dépôt plutôt que de contourner le problème en silence.

--what-if s’étend à trois familles de ressources

Prévisualiser un set sans y toucher, c’est le genre de garde-fou qu’on regrette de ne pas avoir eu la première fois qu’on casse un service en production. La v3.3 étend --what-if à Microsoft.Windows/Service, Microsoft.Windows/FirewallRuleList et aux ressources de configuration SSHD :

# service.dsc.config.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Print Spooler
    type: Microsoft.Windows/Service
    properties:
      name: Spooler
      startType: Disabled

dsc config set --what-if --file ./service.dsc.config.yaml

Dans la même veine, FirewallRuleList gagne une propriété unspecifiedRules, qui décide quoi faire des règles non listées dans ta configuration — avec action obligatoire, et direction/profiles en option.

Filtrage d’export expérimental : attention, la syntaxe va encore bouger

Quand une ressource ne sait pas filtrer nativement les instances qu’elle exporte, le moteur DSC peut désormais récupérer la liste complète et filtrer lui-même, à partir des propriétés que tu passes en entrée. Le mécanisme accepte les caractères génériques (*, insensibles à la casse) sur les valeurs, s’applique aux sous-propriétés imbriquées des objets, et traite plusieurs éléments d’un tableau comme un OU logique :

# services.dsc.config.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Automatically starting local account services
    type: Microsoft.Windows/Service
    properties:
      startType: Auto*
      logonAccount: '*Local*'

Pas de gestion des plages de versions ni des bornes numériques pour l’instant — évite donc de t’appuyer là-dessus pour filtrer par version de composant. L’équipe prévient elle-même que la syntaxe de cette fonctionnalité expérimentale peut changer avant de se stabiliser.

Autres changements à ne pas manquer

dsc mcp devient dsc server (l’ancien nom reste un alias), avec de nouveaux outils exposés (show_dsc_schema(), invoke_dsc_function(), invoke_dsc_expression()) pour qui pilote DSC via le protocole MCP plutôt qu’en ligne de commande directe. La fonction format() quitte le statut expérimental. Deux nouvelles fonctions arrivent : stateChanged(resourceId(...)), pour savoir si un set a réellement modifié quelque chose, et restartRequired() avec ses variantes système/service/processus.

Côté outillage en ligne de commande, --required-version remplace --version sur dsc resource * (l’ancien flag reste un alias) et accepte des plages façon Rust — ^1.1, ~1.2.3 :

dsc resource schema --resource Microsoft.Windows/RegistryList --required-version '^1.1.0'

Microsoft/OSInfo accepte maintenant des comparateurs (=, <, <=, >, >=) sur la version du système — un seul par instance. Et côté Linux, DSC v3.3 arrive enfin sur packages.microsoft.com en RPM et DEB, à l’image de la bascule que PSResourceGet a connue vers le Microsoft Artifact Registry (on en parlait ici) — ça simplifie l’installation sur les distributions qui s’appuient sur ce dépôt.

FAQ

Faut-il migrer mes ressources Registry existantes vers RegistryList ?

Pas dans l’urgence. Microsoft.Windows/Registry reste disponible ; RegistryList a surtout du sens si tu gères un grand nombre d’entrées et que tu veux réduire le nombre d’instances dans ta configuration.

DSC v3.3 est-il compatible avec les configurations écrites pour v3.0/v3.1 ?

L’article d’annonce ne signale aucun changement cassant pour les ressources existantes — les nouveautés sont additives (nouvelles ressources, extension de fonctionnalités existantes). Teste quand même en --what-if avant de déployer en production, par principe.

Où suivre l’évolution du projet ?

DSC v3 est développé en open source sur GitHub ; c’est là que partent les issues, les demandes de ressources et les contributions comme celle de WindowsFeatureList.

Pour aller plus loin

Si tu n’as pas encore basculé vers DSC v3, le guide d’installation officiel couvre Windows, Linux et macOS. Les notes de version complètes, avec la liste de tous les changements depuis v3.0, sont disponibles sur le dépôt GitHub du projet. Si une des trois nouvelles ressources comble un manque que tu avais contourné avec un script maison, c’est probablement le bon moment pour le remplacer.