Windows deklarativ mit DSC konfigurieren — IaC mit dsc.exe beginnen

Die Einrichtungsanleitung für einen neuen PC, die Excel-Tabelle mit den Serveraufbauschritten, die geheime BAT-Datei, die jemand hinterlassen hat, der das Unternehmen inzwischen verlassen hat — in vielen Betrieben läuft die Windows-Konfigurationsverwaltung noch über „ein Dokument, das die Schritte beschreibt“ und „ein Skript, das die Schritte ausführt“. Die Schwäche dieses Ansatzes ist klar: Die Schritte beginnen in dem Moment, in dem sie ausgeführt werden, von der Wirklichkeit abzuweichen, und das Skript geht beim zweiten Lauf kaputt.

Unter Linux und in der Cloud ist deklaratives IaC (Infrastructure as Code) wie Terraform und Ansible zur Norm geworden. Womit also verwaltet man Windows-Clients und -Server selbst in derselben Denkweise? Microsofts Antwort ist DSC (Desired State Configuration), und mit Microsoft DSC v3 (dsc.exe), 2025 als von PowerShell unabhängiges Kommandozeilenwerkzeug neu geschrieben, hat es endlich eine Form erreicht, mit der man „einfach anfangen“ kann.¹

Zielgruppe sind Entwickler und IT-Verantwortliche, die die Konfiguration von Windows-Clients und -Servern mit Anleitungen und Skripten verwalten und zur deklarativen Verwaltung wechseln wollen. Voraussetzungen sind Windows 10/11 und DSC 3.0 oder höher; grundlegende PowerShell-Bedienung wird als Vorwissen angenommen. Der Schwierigkeitsgrad ist mittel.

1. Zuerst das Fazit

Mit DSC schreiben Sie den „gewünschten Zustand“ in YAML, nicht die „auszuführenden Schritte“. Die Ressourcen übernehmen das Erkennen der Differenz zum aktuellen Zustand (test) und das Anwenden (set). Dasselbe File ist daher unabhängig von der Laufzahl sicher (idempotent), und die Konfiguration wird zu Daten, die Sie in Git reviewen können. Wenn Sie jetzt beginnen, ist Microsoft DSC v3 (dsc.exe) die einzige Wahl.

Der Unterschied zwischen einem Ablaufskript und einer deklarativen Konfiguration zeigt sich daran, wie sie kaputtgehen. Ein Skript, das Schritte kodiert, bleibt mit doppelter Anwendung oder Fehlern stehen, wenn Sie es erneut gegen eine Maschine laufen lassen, die unterwegs gescheitert ist oder bereits konfiguriert ist. Eine deklarative Konfiguration beschreibt nur den gewünschten Zustand; egal wie oft und aus welchem Zwischenzustand Sie sie ausführen, sie konvergiert zum selben Ergebnis.²

flowchart TB
    accTitle: Imperatives Ablaufskript gegenüber deklarativer Konfiguration
    accDescr: Ein imperatives Skript führt Schritte von oben aus, sodass ein erneuter Lauf zu doppelter Anwendung oder zum Abbruch führt, während deklaratives DSC den gewünschten Zustand deklariert und nur die Differenz anwendet, sodass es unabhängig von der Laufzahl zum selben Zustand konvergiert
    imp["Imperativ: die Schritte schreiben (BAT, Anleitung)"] --> i1["Von oben ausführen"]
    i1 --> i2["Erneuter Lauf: doppelte Anwendung, Fehler"]
    dec["Deklarativ: den Zustand schreiben (DSC)"] --> d1["Differenz zum aktuellen Zustand erkennen"]
    d1 --> d2["Nur die Differenz anwenden, jedes Mal sicher"]

Abbildung 1: Ein imperatives Skript ist empfindlich gegenüber „wie oft es gelaufen ist“; eine deklarative Konfiguration konvergiert unabhängig von der Laufzahl zum selben Zustand.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (17 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Die Verwirrung um den Namen „DSC“ entwirren — vier Linien

Das Erste, woran man beim Lernen von DSC scheitert, ist nicht die Technik selbst, sondern die Verwirrung in den Suchergebnissen. Vier Linien von Mechanismen tragen den Namen „DSC“, und sie unterscheiden sich darin, wie man sie schreibt, wie man sie ausführt und womit sie kompatibel sind.³

Microsoft DSC v3 ist nicht einfach eine Aktualisierung des früheren PowerShell DSC (PSDSC); es ist ein eigenes Produkt, neu geschrieben und von der Abhängigkeit von PowerShell gelöst. Konfigurationen werden zu JSON/YAML-Daten statt PowerShell-Skripten, Ressourcen können in jeder Sprache implementiert werden, und es läuft auf Linux, macOS und Windows gleich.¹

flowchart TB
    accTitle: Abstammung der vier DSC-Generationen
    accDescr: Aus dem in Windows PowerShell 5.1 eingebauten PSDSC v1.1 gehen PSDSC v2 für PowerShell 7 und die PSDSC-v3-Vorschau für Machine Configuration hervor, während Microsoft DSC v3, getrennt ohne PowerShell-Abhängigkeit neu geschrieben, die aktuelle Hauptlinie ist
    v11["PSDSC v1.1 (in WinPS 5.1 eingebaut)"] --> v2["PSDSC v2 (PowerShell 7)"]
    v2 --> v3ps["PSDSC v3 Vorschau"]
    v11 -.->|"Neuschreiben"| dsc3["Microsoft DSC v3 (dsc.exe)"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["Gegenstand dieses Artikels"]

Abbildung 2: Die Suche nach „DSC“ liefert Informationen aller vier Linien vermischt. Als Erstes festzustellen, von welcher Linie ein Artikel oder Dokument handelt, ist entscheidend.

Ab hier meint „DSC“ in diesem Artikel Microsoft DSC v3. Dass Assets der älteren Generationen nicht verloren gehen, kommt später (Abschnitt 6).

3. Was „deklarativ“ bedeutet — get, test, set und Idempotenz

Der zentrale Begriff in DSC ist die Ressource. Eine Ressource stellt für eine Art von Konfigurationsziel — etwa „Registrierungswert“, „Windows-Feature“ oder „Umgebungsvariable“ — die Operationen Bereitstellen des Zustands (Get), Bewerten (Test) und Anwenden (Set) bereit. Jede Ressource implementiert Get. Für Ressourcen ohne Test springt DSC mit einem synthetischen Test ein, der das abgerufene Ergebnis mit der Deklaration vergleicht. Set implementieren nur Ressourcen, die einen Zustand erzwingen können; schreibgeschützte Ressourcen wie OS-Informationen haben es nicht.⁴ Der Nutzer überlässt das „Wie konfigurieren“ der Ressource und schreibt nur „was in welchem Zustand sein soll“ als Daten.

Diese Arbeitsteilung erzeugt die Idempotenz. Beim Anwenden eines Konfigurationsdokuments (dsc config set) testet DSC zuerst jede Instanz und ruft set nur bei denen auf, die nicht im gewünschten Zustand sind. Deshalb ist das wiederholte Anwenden derselben Konfiguration sicher. Ein Unterschied: Bei dsc resource set auf einer einzelnen Ressource wird set immer aufgerufen; ob vorher ein Test läuft, hängt von der Implementierung der Ressource ab (implementsPretest).⁵

flowchart TB
    accTitle: Die Konvergenzschleife aus get, test und set
    accDescr: test vergleicht den im Konfigurationsdokument geschriebenen gewünschten Zustand mit dem aktuellen Zustand, bei keiner Differenz geschieht nichts, und bei einer Differenz wendet set nur die Differenz an und get bestätigt das Ergebnis, ein idempotenter Konvergenzfluss
    doc["Konfigurationsdokument (gewünschter Zustand)"] --> test["test: mit dem aktuellen Zustand vergleichen"]
    test -->|"keine Differenz"| ok["Nichts tun (idempotent)"]
    test -->|"Differenz"| set["set: nur die Differenz anwenden"]
    set --> get["get: den resultierenden Zustand bestätigen"]

Abbildung 3: Das Anwenden von DSC ist eine Schleife „zuerst vergleichen, dann nur ändern, was nötig ist“, die vom Begriff der Laufzahl befreit.

Den Unterschied zu einem imperativen Skript sehen wir im Code. Nehmen wir „diesen Wert in die Registrierung schreiben“: In einem Skript schreiben Sie Existenzprüfung, Erzeugen und Aktualisieren selbst, jeweils als eigenen Zweig.

# Imperativ: die "Schritte" schreiben. Jeden Zweig und jede Reihenfolge verwalten Sie selbst
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

In DSC schreiben Sie dasselbe als Deklaration des „gewünschten Zustands“. Es gibt keine Existenzprüfung und keine Verzweigung.

# Deklarativ: den "Zustand" schreiben. Erzeugen und Korrigieren sind Sache der Ressource
- name: Betriebsmodus der App
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. dsc.exe installieren und Ressourcen einzeln aufrufen

Es gibt zwei Wege, DSC zu installieren. Das Archiv aus dem GitHub-Release entpacken und zum PATH hinzufügen, oder unter Windows mit winget aus der Microsoft-Store-Quelle installieren.¹

# Die stabile Version aus der Microsoft-Store-Quelle suchen und installieren
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

Sobald es installiert ist, listen Sie zuerst die auf der lokalen Maschine verfügbaren Ressourcen.

dsc resource list

Bevor Sie ein Konfigurationsdokument schreiben, können Sie Ressourcen auch einzeln für sich aufrufen. Dass man „im Kleinen ausprobieren“ kann, macht v3 leicht zu lernen.⁶

# Den aktuellen Zustand abrufen (get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# Bewerten, ob der gewünschte Zustand vorliegt (test) — ändert überhaupt nichts
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: Die vier Operationen des Befehls dsc resource
    accDescr: Unter dem Befehl dsc resource hängen vier Operationen, list zum Auflisten der Ressourcen, get zum Abrufen des aktuellen Zustands, test zum Bewerten des gewünschten Zustands ohne Änderungen, und set zum Anwenden des Zustands (nur bei Ressourcen, die Set implementieren)
    cli["Befehl dsc resource"] --> l["list: Ressourcen auflisten"]
    cli --> g["get: aktuellen Zustand abrufen"]
    cli --> t["test: nur bewerten, keine Änderungen"]
    cli --> s["set: anwenden (Ressourcen mit Set)"]

Abbildung 4: Ressourcen lassen sich ohne Konfigurationsdokument einzeln aufrufen. Mit der Beobachtung zu beginnen, nur mit get und test, ist der sichere Einstieg.

Operationen, die über set Änderungen vornehmen, und Ressourcen, die HKLM oder Systemeinstellungen behandeln, erfordern Administratorrechte. Am sichersten beginnt man die Versuche mit Beispielen, deren Schreibziel im Bereich des Benutzers liegt (etwa HKCU).

5. Das Konfigurationsdokument — den „gewünschten Zustand“ in YAML schreiben

Ein Konfigurationsdokument deklariert mehrere Ressourcen zusammen. Es wird in YAML oder JSON geschrieben und definiert mindestens die beiden Eigenschaften $schema und resources. Jede Ressourceninstanz hat einen name (einen im Dokument eindeutigen Anzeigenamen), einen type (den vollqualifizierten Ressourcennamen) und properties (den gewünschten Zustand).²

# standard-pc.dsc.config.yaml — der gewünschte Zustand eines Standard-Client-PCs
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: Betriebsmodus der App
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

Mit parameters und variables lassen sich Unterschiede zwischen Umgebungen (etwa abteilungsspezifische Einstellungswerte) in einem einzigen Dokument ausdrücken. Die Ausdruckssyntax ist eine Teilmenge der ARM-Vorlagenfunktionen.²

flowchart TB
    accTitle: Aufbau eines Konfigurationsdokuments
    accDescr: Ein Konfigurationsdokument besteht aus einem Schema, das das Dokumentschema identifiziert, parameters und variables, die Umgebungsunterschiede aufnehmen, und einem resources-Array von Ressourceninstanzen, von denen jede name, type und properties hat
    docroot["Konfigurationsdokument (YAML / JSON)"] --> sch["$schema: URI des Dokumentschemas"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources: Array von Instanzen"]
    res --> inst["name, type, properties"]
    par -.-> inst

Abbildung 5: Ein Konfigurationsdokument ist schlichte Daten, nichts weiter als „Schema + Parameter + Ressourcendeklarationen“; es ist kein Programm.

Setzen Sie vor dem Anwenden immer „Beobachten“ davor. dsc config test meldet, ob es Differenzen gibt, ohne etwas zu ändern, und dsc config set --what-if zeigt eine Vorhersage, „was sich ändern würde, wenn das ausgeführt würde“.⁷

# 1. Prüfen, ob es Differenzen gibt (keine Änderungen)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. Eine Vorhersage anzeigen, was das Anwenden ändern würde (keine Änderungen)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. Anwenden, sobald Sie einverstanden sind
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. Den Zustand nach dem Anwenden bestätigen
dsc config get --file .\standard-pc.dsc.config.yaml

Es gibt auch einen Einstieg in die Gegenrichtung. Für die im mit --file übergebenen Eingabedokument aufgeführten Ressourcen (nur solche, die export unterstützen) erzeugt dsc config export ein Konfigurationsdokument mit jeder Instanz auf dem System und schreibt es auf die Standardausgabe. Es kann als Ausgangspunkt dienen, den aktuellen Zustand einer bestehenden Umgebung festzuhalten.⁸

# Ein Eingabedokument mit den Zielressourcen übergeben und das aktuelle Konfigurationsdokument speichern
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

flowchart TB
    accTitle: Die vier Schritte des sicheren Anwendens
    accDescr: Mit dsc config test, das nichts ändert, auf Differenzen prüfen, die Änderungen mit der Option what-if von dsc config set vorhersagen, nach Zustimmung mit set anwenden und das Ergebnis mit get bestätigen, in dieser sicheren Reihenfolge
    t["dsc config test (auf Differenzen prüfen)"] --> w["set --what-if (die Änderungen vorhersagen)"]
    w --> s["dsc config set (anwenden)"]
    s --> g["dsc config get (das Ergebnis bestätigen)"]

Abbildung 6: Solange Sie die Reihenfolge „beobachten, vorhersagen, anwenden, bestätigen“ einhalten, hat das Anwenden einer deklarativen Konfiguration nichts von der Angst vor einem einmaligen Glücksspiel.

Dass ein Konfigurationsdokument Daten ist, kein Programm, ist sein größter betrieblicher Vorteil. „Was auf dieser Maschine konfiguriert sein soll“ lässt sich als YAML-Diff reviewen, und die Änderungshistorie ist unmittelbar die Änderungshistorie der Konfiguration.

6. Vorhandene Assets weiterverwenden — Adapter für PSDSC-Ressourcen und WinGet Configuration

Zu hören, „v3 sei ein eigenes Produkt“, weckt Sorge um bisherige Assets, aber DSC v3 kann die PSDSC-Ressourcen älterer Generationen über einen Mechanismus namens Adapterressourcen aufrufen. Unter den aktuellen Namen in DSC 3.2 und später bedient Microsoft.Adapter/PowerShell die klassenbasierten Ressourcen für PowerShell 7 und Microsoft.Adapter/WindowsPowerShell die MOF-basierten und skriptbasierten Ressourcen für Windows PowerShell 5.1 (davor hießen sie Microsoft.DSC/PowerShell und Microsoft.Windows/WindowsPowerShell).⁹ Das über viele Jahre gewachsene Ökosystem der PSDSC-Ressourcen ist direkt aus einem v3-Konfigurationsdokument erreichbar.

Der andere Anschlusspunkt ist WinGet Configuration. Die .winget-Dateien aus dem Artikel zum PC-Kitting nutzen ab dem v3-Schema (WinGet 1.11 und später) DSC v3 direkt als Prozessor. Wenn Sie in den metadata der Konfigurationsdatei dscv3 als Prozessor angeben, ist der Körper des Dokuments selbst ein DSC-v3-Konfigurationsdokument.¹⁰

# WinGet Configuration v3 — der Körper ist ein DSC-v3-Konfigurationsdokument
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: Betriebsmodus der App
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

Es gibt einen Vorbehalt. Eine vorhandene Datei im v2-Format (das Format mit properties.configurationVersion: 0.2.0 und den Ressourcen unter properties) läuft unter dem dscv3-Prozessor nicht unverändert. v2-Dateien funktionieren weiter mit dem bisherigen Prozessor; um sie auf DSC v3 zu legen, migrieren Sie das Format nach der offiziellen Umwandlungsanleitung („Convert to v3“ im Samples-Repository).¹⁰

flowchart TB
    accTitle: Die Schichtenstruktur mit DSC v3 in der Mitte
    accDescr: Orchestrierungsschichten wie winget configure und Azure Machine Configuration rufen DSC v3 auf, und DSC v3 ruft native Ressourcen direkt und vorhandene PSDSC-Ressourcen über Adapterressourcen auf
    orch["winget configure, Machine Configuration"] --> dsc["dsc.exe (DSC v3)"]
    dsc --> native["Native Ressourcen (Registry usw.)"]
    dsc --> adapter["Adapterressourcen"]
    adapter --> psdsc["Vorhandene PSDSC-Ressourcen (PowerShell-Assets)"]

Abbildung 7: DSC v3 ist ein eigenständiges Werkzeug und zugleich die gemeinsame Grundlage unter höherliegenden Werkzeugen wie winget und Azure. Vorhandene PSDSC-Assets hängen unter dem Adapter.

Mit anderen Worten: Das Wissen und die Konfigurationen, die Sie für v3 schreiben, funktionieren mit dsc.exe auf der eigenen Maschine, mit winget configure beim Kitting und mit Machine Configuration in der Cloud-Verwaltung. Das ist kein Neuernen; die Wege laufen zusammen.¹

7. In den Betrieb bringen — in Git verwalten und Drift erkennen

Der Ort für Konfigurationsdokumente ist ein Git-Repository. Konfigurationsänderungen folgen dann demselben Ablauf wie die Softwareentwicklung: im Pull Request reviewen, mergen, anwenden. Der Begriff einer Anleitung, die niemand aktualisiert hat, verschwindet.

Die Herausforderung nach dem Anwenden ist Konfigurationsdrift (jemand ändert eine Einstellung von Hand, und die Maschine entfernt sich vom gewünschten Zustand). In DSC ist Drifterkennung schlicht das periodische Ausführen von dsc config test. Weil test nichts ändert, lassen sich Erkennung und Behebung trennen, und das ist eine wichtige Eigenschaft. Das sichere Betriebsmuster ist, zuerst die Erkennung zu automatisieren und erst nach Prüfung der Differenzen zu beheben (set).

# Für periodische Läufe: einen Fehlschlag von test selbst, Fehler je Ressource und Drift unterscheiden und in allen Fällen nichtnull beenden
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test selbst ist fehlgeschlagen (Exitcode: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # Die Dokumentvalidierung ist fehlgeschlagen oder eine Ressource ist nichtnull beendet. Die Prüfung ist nicht durchgelaufen, daher nicht als gesund melden
    Write-Error "Die Prüfung einiger Ressourcen ist mit Fehlern geendet. messages prüfen"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "Konfigurationsdrift erkannt"
    exit 1
}

Für die periodische Ausführung eignet sich auf Clients die Aufgabenplanung (der Entwurf unbeaufsichtigter Ausführung steht in einem eigenen Artikel), für Serverflotten CI-Runner. Für Organisationen, die die Verwaltung in Azure gebündelt haben, ist Machine Configuration der verwaltete Orchestrierungsdienst, der Konfiguration auf Azure-VMs und über Azure Arc auf lokalen Servern prüft und anwendet.¹¹

flowchart TB
    accTitle: Der Betriebszyklus der Konfigurationsverwaltung mit Git als Ausgangspunkt
    accDescr: Konfigurationsdokumente in einem Git-Repository werden in einem Pull Request gereviewt, bevor sie angewendet werden, periodische test-Läufe aus der Aufgabenplanung oder CI erkennen Drift, und nach Prüfung der Differenz kehrt der Zyklus zur Behebung oder zur Aktualisierung der Konfiguration zurück
    git["Git-Repository (Konfigurationsdokumente)"] --> pr["Änderungen in Pull Requests reviewen"]
    pr --> apply["Mit dsc config set anwenden"]
    apply --> sched["Periodischer Lauf: dsc config test"]
    sched -->|"Drift erkannt"| judge["Die Differenz prüfen und entscheiden"]
    judge -.->|"Konfiguration ist richtig"| fix["Mit set beheben"]
    judge -.->|"die Realität ist richtig"| git

Abbildung 8: Der Umgang mit Drift ist nicht nur „Beheben“. Ist die Änderung vor Ort die richtige, ist das Korrigieren und Mergen des Konfigurationsdokuments die angemessene Praxis deklarativer Verwaltung.

Der Zweig unten rechts in Abbildung 8 wird leicht übersehen. Drift ist nicht immer „schlecht“; manchmal bedeutet sie nur, dass eine vor Ort nötige Änderung noch nicht in der Konfiguration steht. Dann setzen Sie die Maschine nicht zurück, sondern aktualisieren das Konfigurationsdokument, damit es der Wirklichkeit entspricht. Solange Sie die Disziplin halten, dass die Quelle der Wahrheit stets die Deklaration in Git ist, bricht die Verwaltung nicht, egal nach welcher Seite Sie gehen.

8. Einschränkungen und Fallstricke

Hier, offen, die Einschränkungen, die Sie vor der Einführung kennen sollten.

Es gibt keinen LCM. Der LCM (Local Configuration Manager) in v1.1 war ein residenter Agent, der die Konfiguration hielt und periodisches Anwenden und automatische Behebung ausführte. v3 ist „ein Befehl, der nur läuft, wenn er aufgerufen wird“ und bleibt nicht als Dienst resident.¹ Brauchen Sie fortlaufendes Erzwingen, müssen Sie die Ausführungsinfrastruktur selbst wählen (Aufgabenplanung, CI, Machine Configuration), wie im vorigen Abschnitt. Das ist keine Regression, sondern eine Entwurfsänderung, die „wie es ausgeführt wird“ modernen Werkzeugen öffnet; trotzdem irritiert es, wenn man mit der Denkweise des Pull-Server-Betriebs von v1.1 ankommt.

Umgang mit Administratorrechten. set auf Ressourcen, die die ganze Maschine betreffen (HKLM, Windows-Features und so weiter), erfordert eine Erhöhung der Rechte, und die Nutzung von Windows-PowerShell-PSDSC-Ressourcen über den Adapter setzt ebenfalls die Ausführung als Administrator voraus.⁶ Benutzerbezogene und maschinenbezogene Einstellungen schon auf der Ebene des Konfigurationsdokuments zu trennen, erleichtert den Entwurf des Ausführungskontexts.

Schreiben Sie keine Geheimnisse in die Konfiguration. Konfigurationsdokumente sind Daten, die nach Git gehen. Schreiben Sie Passwörter oder API-Schlüssel nicht direkt hinein; parametrisieren Sie sie und übergeben Sie sie zur Laufzeit.

Lesen Sie fremde Konfigurationsdateien, bevor Sie sie ausführen. Ein Konfigurationsdokument hat die Macht, das System über Ressourcen zu ändern. Bevor Sie eine .winget-Datei oder ein Konfigurationsdokument aus einem öffentlichen Repository anwenden, prüfen Sie den Inhalt und die Vertrauenswürdigkeit der referenzierten Ressourcen. Das ist eine betriebliche Pflicht, vor der auch die offizielle Dokumentation ausdrücklich warnt.¹²

flowchart TB
    accTitle: Der residente LCM von v1.1 gegenüber dem Befehlsmodell von v3
    accDescr: In PSDSC v1.1 hielt ein residenter LCM die Konfiguration und übernahm periodisches Pull und automatische Behebung, während DSC v3 nur als Befehl gestartet wird, sodass Sie die periodische Ausführungsinfrastruktur selbst aus Aufgabenplanung, CI und Machine Configuration wählen und bereitstellen
    v1["PSDSC v1.1: residenter LCM"] --> pull["Hält die Konfiguration, periodisches Pull, automatische Behebung"]
    v3["DSC v3: nur Befehlsaufruf"] --> push["Die Ausführungsinfrastruktur stellen Sie bereit"]
    push -.-> ex["Aufgabenplanung, CI, Machine Configuration"]

Abbildung 9: In v3 gibt es niemanden, „der sich die Konfiguration merkt und sie von selbst richtet“. Ob Sie das als Unannehmlichkeit oder als zurückgewonnene Kontrolle über die Ausführung nehmen, ist die Entwurfsentscheidung.

9. Zusammenfassung — die Anleitung durch ein Repository ersetzen

• Wenn Sie jetzt mit deklarativem IaC für Windows beginnen, verwenden Sie Microsoft DSC v3 (dsc.exe). Von den vier Linien namens „DSC“ sollten Sie stets wissen, von welcher die Informationen handeln, die Sie lesen.³
• DSC schreibt den „gewünschten Zustand“, nicht die „Schritte“, in YAML/JSON, und test (vergleichen) und set (die Differenz anwenden) garantieren idempotente Konvergenz. Der sichere Ablauf beginnt mit Beobachten über dsc resource get/test, prüft die Auswirkungen mit --what-if und wendet dann an.⁷
• Vorhandene PSDSC-Ressourcen stoßen über Adapter zur v3-Welt hinzu, und .winget-Assets fürs Kitting über das WinGet-Configuration-v3-Schema (Dateien im v2-Format brauchen eine Formatmigration nach der Umwandlungsanleitung).⁹¹⁰
• v3 hat keinen LCM. Das Rückgrat des Betriebs ist, die Quelle der Wahrheit in Git zu halten, Drift mit periodischen Läufen von dsc config test zu erkennen und der Disziplin zu folgen: „Ist die Konfiguration richtig, beheben; ist die Realität richtig, die Konfiguration aktualisieren“.

Das Schicksal einer Anleitung war, von dem Moment an, in dem sie geschrieben wurde, von der Wirklichkeit abzuweichen. Deklarative Konfigurationsverwaltung macht aus dieser Abweichung eine „erkennbare Differenz“. Beginnen Sie damit, eine Handvoll Einstellungen der eigenen Maschine in ein Konfigurationsdokument zu schreiben und dsc config test auszuführen. Sie sollten ein Gefühl dafür bekommen, wie die Anleitung zu einem Repository wird.

Verwandte Artikel

• PC-Kitting mit winget + PowerShell automatisieren — Aus dem Handbuch ein ausführbares Skript machen
• Sollte diese Batch-Datei zu PowerShell wechseln? — Bestandsaufnahme von cmd/bat-Assets und die Migrationsentscheidung
• Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden — Ursachen eingrenzen und zuverlässigen Betrieb entwerfen
• Von Gruppenrichtlinien zu Intune — Ein Leitfaden zur Gerätemanagement-Migration für kleine und mittlere Unternehmen
• Windows Update-Verwaltung nach der WSUS-Abschaffung

Verwandte Beratungsbereiche

KomuraSoft LLC unterstützt die Migration der Konfiguration von Windows-Clients und -Servern zur deklarativen Verwaltung, die Automatisierung von Kitting und internen Standardumgebungen sowie die Umwandlung personenabhängiger Anleitungen in ausführbare Form.

• Technische Beratung und Design-Review
• Änderung und Wartung bestehender Windows-Software
• Nutzung und Migration bestehender Assets
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Es scheint mehrere Versionen von DSC zu geben. Welche soll ich verwenden?

Wenn Sie jetzt mit deklarativer Konfigurationsverwaltung beginnen, nehmen Sie Microsoft DSC v3 (dsc.exe). Es gibt vier Linien von DSC: PSDSC v1.1, das in Windows PowerShell 5.1 eingebaut ist, PSDSC v2 als Modul für PowerShell 7, PSDSC v3 (Vorschau) für die Linux-Unterstützung von Azure Machine Configuration, und Microsoft DSC v3, neu geschrieben als eigenständiger Befehl, der nicht von PowerShell abhängt. v3 ist plattformübergreifend, schreibt die Konfiguration als YAML/JSON-Daten statt als PowerShell-Skripte und kann vorhandene PSDSC-Ressourcen über Adapter wiederverwenden. Bei der Suche erleichtert das Anhängen von "DSC v3" oder "dsc.exe" die Trennung von Material älterer Generationen.

Worin unterscheiden sich DSC v3 und ein Ablaufskript (BAT oder PowerShell)?

Ein Ablaufskript beschreibt "die auszuführenden Schritte", daher müssen Sie Idempotenz selbst einbauen, damit der zweite Lauf nicht zu doppelter Anwendung oder Fehlern führt. DSC schreibt den "gewünschten Zustand" als Daten, und die Ressourcen übernehmen den Vergleich mit dem aktuellen Zustand (test) und das Anwenden der Differenz (set). Egal wie oft Sie dasselbe Konfigurationsdokument ausführen: Bei Elementen, die bereits im gewünschten Zustand sind, geschieht nichts. Sie können es also verteilen und erneut ausführen, ohne die Laufzahl zu beachten. Und weil die Konfiguration YAML-Daten ist, sind Diff-Reviews und Versionsgeschichte in Git deutlich einfacher als bei Skripten.

Werden meine vorhandenen PowerShell-DSC-Ressourcen und WinGet-Configuration-Assets wertlos?

Nein. DSC v3 kann vorhandene klassenbasierte und MOF-basierte PSDSC-Ressourcen über Adapterressourcen aufrufen (Microsoft.Adapter/PowerShell und Microsoft.Adapter/WindowsPowerShell in DSC 3.2 und später; davor Microsoft.DSC/PowerShell und Microsoft.Windows/WindowsPowerShell). WinGet Configuration nutzt ab dem v3-Schema (WinGet 1.11 und später) DSC v3 als Prozessor. Vorhandene .winget-Dateien im v2-Format laufen weiter auf dem bisherigen Prozessor; um sie auf den DSC-v3-Prozessor zu legen, müssen Sie sie nach der offiziellen Umwandlungsanleitung ins v3-Format konvertieren.

Wie erzwinge ich eine Konfiguration mit DSC v3 "fortlaufend"?

DSC v3 selbst ist ein Werkzeug, das als Befehl gestartet wird; es hat keinen residenten Agenten und keinen Mechanismus zur automatischen Behebung wie den LCM (Local Configuration Manager) von v1.1. Brauchen Sie fortlaufendes Anwenden und Prüfen, bauen Sie die Drifterkennung selbst, indem Sie dsc config test periodisch aus der Aufgabenplanung oder aus CI ausführen, oder legen Sie es auf eine Orchestrierungsschicht wie Azure Machine Configuration (die über Azure Arc auch lokale Server abdecken kann).

Ich scheue mich, dsc config set sofort auszuführen. Kann ich die Auswirkungen vorher prüfen?

Ja. dsc config test zeigt, welche Ressourceninstanzen nicht im gewünschten Zustand sind, ohne etwas zu ändern. Zusätzlich hat dsc config set die Option --what-if, die eine Vorhersage anzeigt, "was sich wie ändern würde, wenn das ausgeführt würde", ohne tatsächlich etwas zu ändern. Prüfen Sie die Differenzen zuerst mit test und --what-if, und führen Sie set erst aus, wenn Sie einverstanden sind; diese Reihenfolge ist sicher.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.