Aller guten Dinge

von Thorsten Butz

ADMIN

2026

2026-02-25T12:00:00

IT-Automatisierung

SCHWERPUNKT

064

Automatisierung

Konfigurationsplattform

Kommandozeilen-Werkzeug

Desired State Configuration v3

Aller guten Dinge

von Thorsten Butz

Veröffentlicht in Ausgabe 03/2026 - SCHWERPUNKT

Mit der dritten Generation der Desired State Configuration vollzieht Microsoft einen grundlegenden Architekturwechsel. DSC v3 verabschiedet sich vom PowerShell-zentrierten Local Configuration Manager und setzt stattdessen auf ein schlankes, plattformübergreifendes Kommandozeilen-Werkzeug. Konfigurationen liegen nun in deklarativen Formaten wie YAML oder JSON vor und lassen sich ohne MOF-Generierung direkt anwenden. Der Artikel zeigt, was sich hinter diesem Neustart verbirgt.

Uunter Windows gelangt die DSC v3 als Kommandozeilen-Anwendung "dsc.exe" auf den Rechner. Der Local Configuration Manager (LCM) kommt nicht mehr zum Einsatz und das Übersetzen der gewünschten Konfiguration in MOF-Dateien entfällt. Es bleibt also Ihnen überlassen, die Konfigurationsdatei bei Bedarf anzuwenden – im einfachsten Fall über eine geplante Aufgabe (scheduled task). Vorhandene DSC-Ressourcen sind über ein Adaptermodell angebunden und lassen sich vollumfänglich weiternutzen. Microsoft bezeichnet die ersten beiden DSC-Versionen zur besseren Abgrenzung nun als "PSDSC" (PowerShell DSC). PSDSC-Konfigurationen lassen sich parallel verwenden. Die ersten beiden Versionen gelten zwar als veraltet, bleiben aber auf absehbare Zeit weiterhin unterstützt.

Erste Schritte

Um einen ersten Eindruck von DSC v3 zu gewinnen, installieren wir die Kommandozeilen-Anwendung mithilfe von "AppInstaller / WinGet" unter Windows 11. Sie finden das Paket mit dem Namen "DesiredStateConfiguration" im Microsoft Store:

winget search --query DesiredStateConfiguration

winget install --id 9NVTPZWRC6KQ --source msstore

Alternativ geben Sie WinGet als Paketquelle an, dort heißt das Paket "Microsoft.DSC". Anwendungen, die Sie aus dem Microsoft Store installieren, erhalten automatisch Aktualisierungen. Selbstverständlich können Sie auch andere Quellen oder Installationswege nutzen. Darüber hinaus steht das DSC-Paket auf den Projektseiten zum manuellen Download bereit [1].

Erste Schritte

winget search --query DesiredStateConfiguration

winget install --id 9NVTPZWRC6KQ --source msstore

Nach der Installation steht ihnen "dsc" als Kommandozeilen-Anwendung zur Verfügung, das Sie über Get-Command -Name dsc abfragen können. Dabei haben Sie verschiedene Optionen:

- dsc --version: Gibt die Version aus, zum Beispiel: 3.1.2

- dsc --help: Zeigt eine Hilfe an.

- dsc resource list: Listet native DSCv3-Ressourcen auf.

- Get-DscResource: Zeigt klassische DSC-Ressourcen an (DSC v1 und v2).

Hinter der Desired State Configuration steht die Idee, Konfigurationen als Code zu schreiben. Sie erstellen eine Konfigurationsdatei, die den gewünschten Zustand beschreibt. Dieser "Wunschzettel" stellt die Konfiguration jedoch nicht her und installiert auch nichts. Hierfür sind die sogenannten DSC-Ressourcen erforderlich, die den Wunschzettel auswerten und die erforderlichen Anpassungen vornehmen. Mit dem Cmdlet Get-DscResource können Sie nach klassischen DSC-Ressourcen auf Ihrem System suchen.

Mit dem Befehl dsc resource list erhalten Sie eine Liste der nativen Ressourcen der Version 3, die sich in einer beliebigen Programmiersprache erstellen lassen. In dieser Liste finden Sie unter anderem den Adapter "Microsoft.Windows / WindowsPowerShell". Über diesen erhalten Sie in DSC v3 Zugriff auf die klassischen DSC-Ressourcen, die in den letzten zehn Jahren in großer Zahl entwickelt wurden. Listing 1 nutzt eine solche klassische Ressource namens "WindowsOptionalFeature", mit deren Hilfe sich optionale Betriebssystem-Komponenten in Windows 11 nachinstallieren lassen.

Listing 1: Telnet-Client installieren

$schema: https://raw.githubusercontent.com/ PowerShell/DSC/main/schemas/2024/04/ config/document.json

resources:

- name: Use Windows PowerShell resources

type: Microsoft.Windows/WindowsPowerShell

properties:

resources:

- name: Telnet Client install

type: PSDesiredStateConfiguration/ WindowsOptionalFeature

properties:

Name: TelnetClient

Ensure: Enable

Um die gewünschte Konfiguration mit DSC v3 umzusetzen und damit den Telnet-Client zu installieren, übergeben Sie die Konfigurationsdatei mit den entsprechenden Parametern an das dsc-Utility. Nach wenigen Augenblicken sollte der Telnet-Client nachinstalliert sein. Auch wenn der Client sicher kein bedeutendes Windows-Feature ist, eignet es sich doch hervorragend für einen ersten Test. Auf die gleiche Weise können Sie auch Systemkomponenten wie Hyper-V bereitstellen:

dsc config test --file TelnetClientFeature.yaml

dsc config set --file TelnetClientFeature.yaml

Das Problem mit der Wiederholbarkeit

Die DSC ist angetreten, um ein vermeintlich simples Problem zu lösen: den Wunsch nach Idempotenz. Hinter diesem wunderbar wissenschaftlich klingenden Begriff verbirgt sich der Wunsch, Programmcode immer und immer wieder ausführen zu können, um jedes Mal das gleiche Ergebnis zu erhalten. Betrachten wir als Beispiel einen ganz simplen idempotenten PowerShell-Befehl:

Set-TimeZone -Id 'Nepal Standard Time'

Sie können diesen Befehl unter Windows beliebig oft ausführen und erhalten immer die gleiche Ausgabe sowie den gleichen Effekt. Ihr PC wähnt sich von nun an in Kathmandu. Dabei spielt es keine Rolle, welche Zeitzone Sie vorab konfiguriert haben. Vielleicht war Ihr System schon auf die nepalesische Zeit eingestellt. Sie dürften schnell feststellen, dass sich die meisten Befehle nicht idempotent verhalten. Betrachten wir in Listing 2 ein weiteres einfaches Beispiel: Sie möchten die Taskleiste linksbündig ausrichten, so wie Sie es von Windows 10 gewohnt sind.

Listing 2: Taskleiste ausrichten

$path = 'HKCU:\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced'

$propertyName = 'TaskbarAl'

$alignLeft = 1

$alignCenter = 0

$propertyType = 'DWORD'

Get-ItemProperty -Path $path -Name $propertyName

New-ItemProperty -Path $path -Name $propertyName -Value $alignLeft -PropertyType $propertyType

Set-ItemProperty -Path $path -Name $propertyName -Value $alignCenter

Remove-ItemProperty -Path $path -Name $propertyName

Sie könnten nun ein Skript schreiben, das zunächst prüft, ob der fragliche Registry-Wert bereits existiert und abhängig vom Ergebnis entweder New-ItemProperty oder Set-ItemProperty verwenden. Ein solches Powershell-Skript zu schreiben, wäre in diesem Fall kein Hexenwerk. Der Ansatz "Configuration-as-code" geht aber einen anderen Weg: Anstatt immer wieder eigene Lösungen zu entwickeln und eigenen Code zu schreiben, abstrahieren wir die gewünschte Konfiguration in ein rein beschreibendes Format. Schauen wir uns an, wie dieses Beispielproblem in den ersten Versionen der DSC gelöst wurde.

Wie alles begann: von MOF zu YAML

DSC erblickte mit dem Windows Management Framework (WMF) 4.0 das Licht der Welt, zusammen mit Windows 8.1 und Server 2012 R2. In diesem Framework bündelte Microsoft eine Reihe von Verwaltungskomponenten, wie die Windows PowerShell, WMI oder WinRM. Eine Kernkomponente der PSDSC, also der ersten beiden Versionen, ist der Local Configuration Manager (LCM). Dieser kam in Version 1 mit dem WMF 4 an den Start und hat in Version 2 mit dem WMF 5 signifikante Erweiterungen erhalten. Sie steuern den LCM über die Cmdlets

- Get-DscLocalConfigurationManager

- Get-DscConfiguration

- Start-DscConfiguration

Um dem LCM Leben einzuhauchen, sind mehrere Schritte erforderlich. Zunächst erstellen Sie eine Konfigurationsdatei (Listing 3). Hierzu wurde in Version 1 das Schlüsselwort "Configuration" neu eingeführt. Mit WMF 5 und DSC 2 wurde dieser funktionale Ansatz um Klassen erweitert, was die Einsatzmöglichkeiten der Technologie deutlich erweitert, zugleich aber auch deren Komplexität erhöht.

Listing 3: SetTaskbarAlignment im Local Configuration Manager

## Eine DSC v1 kompatible Konfiguration

Configuration SetTaskbarAlignment

{

# Import the standard DSC module for built-in resources

Import-DscResource -ModuleName PSDesiredStateConfiguration

Node 'sea-cl1'

{

# Resource Block: Ensures the Registry Value is present and correct

Registry TaskbarAlignment

{

Ensure = "Present"

Key = 'HKEY_Users\S-1-5-21-1276007578-2914169427-449847108-1108\Software\ Microsoft\Windows\CurrentVersion\Explorer\Advanced'

ValueName = "TaskbarAL"

ValueData = 0 # The desired DWORD value (0 for Left)

ValueType = "DWORD" # Explicitly defines the data type

}

## Ruft die Konfiguration auf und kompiliert eine MOF-Datei

SetTaskbarAlignment -OutputPath TaskbarAlignment

## Startet die eigentliche Anpassung

Start-DscConfiguration -Path TaskbarAlignment -Wait #-Verbose

Das Beispiel "SetTaskbarAlignment" zeigt, dass die gewünschte Änderung nur erfolgt, wenn die DSC-Ressource "PSDesiredStateConfiguration" geladen werden kann.

Durch den Aufruf der Konfiguration SetTaskbarAlignment -OutputPath TaskbarAlignment erstellen Sie für jeden Rechner (Node) eine MOF-Datei (Managed Object Format), die Sie durch den LCM mit Start-DscConfiguration anwenden (Listing 4). Das "Managed Object Format" (MOF) ist eine Sprache, die WMI/CIM-Klassen beschreibt. Schlussendlich kommt also die Windows Management Instrumentation (WMI) zum Einsatz, um lokal oder remote die gewünschten Änderungen durchzuführen.

Listing 4: Ausschnitt aus einer MOF-Datei

instance of MSFT_RegistryResource as $MSFT_RegistryResource1ref

{

ResourceID = "[Registry]TaskbarAlignment";

ValueName = "TaskbarAL";

Key = "HKEY_Users\\S-1-5-21-1276007578-2914169427-449847108-1108\\Software\ \Microsoft\\Windows\\CurrentVersion\\ Explorer\\Advanced";

Ensure = "Present";

SourceInfo = "::9::9::Registry";

ValueType = "Dword";

ModuleName = "PSDesiredStateConfiguration";

ValueData = {

"0"

};

In der Praxis führt dieses mehrschrittige Verfahren dazu, dass sich Ihre Konfiguration wie ein wachsender Jenga-Turm vor Ihnen aufbaut, der mit jeder neuen Schicht bedenklicher wackelt. Nun hat das PowerShell-Team um Steve Lee einen Schlussstrich gezogen und den LCM-Ansatz sowie die MOF-Dateien ad acta gelegt. An deren Stelle tritt eine deutlich einfacher zu handhabende Konfigurationsdatei, die Sie wahlweise in den Formaten YAML, JSON oder BICEP erstellen können (Listing 5). Die interne Verarbeitung der Daten findet im JSON-Format statt.

Listing 5: TaskbarAlignment.yaml

$schema: https://aka.ms/dsc/schemas/v3/ bundled/config/document.json

resources:

- name: Set taskbar alignment to left

type: Microsoft.Windows/Registry

## Die DSC-Resource

properties:

keyPath: HKCU\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced

valueName: TaskbarAL

valueData:

DWord: 0

_exist: true

Um diesen Konfigurationswunsch umzusetzen, rufen Sie – wie gehabt – das Konsolenprogramm "dsc" auf. Der Effekt sollte sofort sichtbar sein:

dsc config test --file .\TaskbarAlignment.yaml

dsc config set --file .\TaskbarAlignment.yaml

WinGet Configure und DSC

Bei der Suche nach einem unmittelbar praktisch anwendbaren Beispiel der neuen Architektur stoßen Sie unweigerlich auf Microsofts AppInstaller, besser bekannt unter dem Namen seines Kommandozeilen-Programms "winget.exe". Schon frühzeitig verfolgte das WinGet-Team die Idee, die aktuelle Konfiguration eines PCs exportieren und auf einem anderen Rechner importieren zu können:

## Export der aktuellen Einstellungen als YAML-Datei:

winget configure export --all --output myConfig.winget

## Validieren der YAML-Datei:

winget configure validate --file myConfig.winget

## Import der Einstellungen, Installation der Anwendungen:

winget configure --file myconfig.winget

Auch wenn die Dateiendung ".winget" es nicht unmittelbar anzeigt, erfolgt der Export im YAML-Format, das auf DSC v3 aufbaut. In Listing 6 ist dies anhand des Schema-Verweises im Kopf der YAML-Datei zu sehen. Übrigens entspricht die Versionskennung 0.3 (in Zeile 2 des Listings) der DSC v3. Mit dem Befehl winget configure export lassen sich sowohl Einstellungen als auch eine Liste installierter Anwendungen erfassen und alternativ zur Kommandozeile per Doppelklick auf die WinGet-Datei auf einem beliebigen System übertragen.

Listing 6: myconfig.winget

# Created using winget configure export 1.12.350

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.3

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/ document.json

metadata:

winget:

processor:

identifier: "dscv3"

resources:

# WinGet settings

- name: WingetSettings

type: Microsoft.WinGet/UserSettingsFile

properties:

settings:

experimentalFeatures:

experimentalCmd: true

experimentalArg: false

visual:

progressBar: "rainbow"

enableSixels: true

telemetry:

disable: true

$schema: "https://aka.ms/ winget-settings.schema.json"

# Winfile installation

- name: winget_Microsoft.winfile

type: Microsoft.WinGet/Package

metadata:

description: "Install Microsoft.winfile"

properties:

id: "Microsoft.winfile"

source: "winget"

# Brave installation

- name: winget_Brave.Brave

type: Microsoft.WinGet/Package

metadata:

description: "Install Brave.Brave"

properties:

id: "Brave.Brave"

source: "winget"

# Not implemented yet:

# scope: "machine"

So beeindruckend und praktisch dieser Ansatz auch sein mag, aktuell ist er nicht ohne Einschränkungen nutzbar. So ist es beispielsweise nicht möglich, eine Anwendung wie den Webbrowser Brave systemweit zu installieren und eine andere gezielt im Benutzerkontext bereitzustellen, wie es der WinGet-Parameter "--scope" ermöglicht:

winget install --id Brave.Brave --scope machine

winget install --id Vivaldi.Vivaldi --scope user

Grundsätzlich kann jedes Manifest, das im WinGet-Respository [2] verfügbar ist, eine Reihe von Installationsvarianten beinhalten. Wenn verfügbar, wählen Sie den bevorzugten Installationsweg mit dem Parameter "--scope" aus. Dies unterstützt der Export derzeit nicht, obgleich diese Erweiterung im Fahrplan bereits erfasst ist. Es ist also zu erwarten, dass dies in Zukunft möglich sein sollte. Die letzte Zeile im Listing "myconfig.winget" zeigt auf, wie diese Option implementiert sein könnte.

DSC v3 auf Windows Server

Im Kontext von DSC v3 scheint der Windows Server nicht so recht im Fokus der Entwickler zu stehen. Auf der Windows-Server-Seite arbeitet Microsoft vorrangig an der "Azure Machine Configuration" – einer richtlinienorientierten Technologie, die wesentlich auf PSDSC aufbaut. Es ist leicht nachzuvollziehen, dass insbesondere im Serverbereich Änderungen am Technologiestack nur mit größter Vorsicht stattfinden.

In der Desktopvariante von Windows Server 2025 ist mittlerweile der AppInstaller/WinGet verfügbar. Dadurch lassen sich die erforderlichen Komponenten einfach nachrüsten, doch müssen Sie hierzu unter Windows Server noch ein weiteres Programmpaket hinzufügen: die Visual-C++-Runtime:

winget install --id Microsoft.VCRedist.2015+.x64

winget install --id Microsoft.DSC

Da auf den "Core"-Varianten WinGet nicht vorinstalliert ist, müssen Sie die erforderlichen Pakete mit etwas mehr Handarbeit hinzufügen. Sie finden unter [3] eine Reihe von Beispielskripten, die diese Arbeit erledigen. Letztendlich unterscheidet sich die Arbeit mit der DSC auf dem Windows Server nicht grundlegend. Ihnen stehen die Windows-Server-Komponenten zur Verfügung, die auf einem Windows 11-Client fehlen.

Fazit

Es ist nicht leicht, den Überblick zu behalten, wenn es im Microsoft-Umfeld um das Thema Configuration-as-Code geht. DSC v3 ist mehr noch als WinGet eine große Baustelle. Dennoch geht von diesem Neustart ein gewisser Charme aus. Die winget-Dateien, mit deren Hilfe sich Konfigurationen mit wenigen Handgriffen auf andere Maschinen übertragen lassen, weisen den richtigen Weg.

Es bleiben jedoch auch viele Fragen offen. DSC v3 ist als eigenständiges Konsolenprogramm grundsätzlich unabhängig von der PowerShell. Die ausführbare Anwendung ist in Rust programmiert und steht neben Windows auch für Linux und macOS zur Verfügung. Unter der Haube greift das System jedoch an vielen Stellen auf die PowerShell zurück.

Wie die Beispiele gezeigt haben, geschieht dies in aller Regel mit genau jenen DSC-Ressourcen, die für die inzwischen veraltete PSDSC geschrieben wurden. Wer nach diesen Ressourcen sucht (Find-DSCResource), findet allein in der PowerShell-Gallery Hunderte von Modulen. Eine erhebliche Anzahl beginnt noch heute mit dem Kleinbuchstaben x, der in den Anfangstagen den Reifezustand der Ressource beschrieb: x-perimental.

Die Anwendung "dsc" findet bevorzugt aus dem Microsoft Store ihren Weg auf den Rechner. Eben jener Store ist auf Servern ohne Desktop überhaupt nicht verfügbar. Ebenso wenig wie das WinGet-Utility, das ursprünglich für diese miniaturisierten Server angedacht war (Microsoft startete mit WinGet für den Einsatz auf dem Nano-Server). Da passt es ins Bild, dass beim "Azure Machine Configuration"-Team noch nichts von diesem Neustart zu merken ist.

In diesem Artikel haben wir uns auf das Betriebssystem Windows beschränkt. Inwiefern sich Softwarefirmen und Distributoren finden, die DSC unter Linux oder macOS integrieren, bleibt abzuwarten. Mit Ansible, Puppet oder Chef stehen eine Reihe von Werkzeugen bereit, die prädestiniert wären, der Technologie einen Schub zu verschaffen.

(dr)

Links

[1] DSC auf GitHub: https://it-a.eu/q3z51

[2] WinGet-Repository: https://it-a.eu/os11l

[3] Beispielskripte des Autors: https://it-a.eu/q3z53