WinGet nimmt Admins vor allem dort Arbeit ab, wo semimanuelle Installationen für die Konfiguration von Arbeitsplätzen oder Servern notwendig sind. Der Paketverwalter installiert, aktualisiert oder entfernt per Befehl Softwarepakete, die aus einer der zwei vertrauenswürdigen Quellen (Microsoft Store und WinGet-Repository) stammen. Statt etwa Visual Studio Code oder WinRar von den jeweiligen Herstellerseiten herunterzuladen oder gar als veraltete Version von einem internen Fileshare, kümmert sich WinGet per Kommandozeilenbefehl um das Herunterladen und Installieren der aktuellsten Software. Das spart Zeit, weil Sie das Softwarepaket nicht suchen und herunterladen müssen und WinGet zudem eventuelle Abhängigkeiten zu anderen Softwarepaketen automatisch auflöst. Zudem minimiert das Tool das Risiko, böswillige Pakete aus dem Internet zu laden.

WinGet bringt eine Exportfunktion für das Archivieren des Softwareinventars einer Maschine mit und erlaubt, das Inventar per Import auf einen anderen Rechner zurückzuspielen. Dies ist jedoch nicht zwingend der Weg, den Unternehmen wählen, um den Wunschzustand für Softwarepakete zu definieren. Besser ist es, den Sollzustand des Softwareinventars zu definieren und dabei die Rahmenbedingungen wie etwa erforderliche, weitere Windows-Konfigurationen zu beschreiben, damit nicht nur Software-, sondern auch die passende OS-Konfiguration hinterlegt und vollzogen wird.

WinGet kennt dafür das configure-Kommando, das mithilfe von Konfigurationsdateien von einem Paket- zu einem Konfigurationsmanager heranwächst. Die Konfigurationsdateien im YAML-Format können dabei, neben den zu installierenden Anwendungen und Anforderungen zu Version und Sprachdetails, auch Hinweise zur Windows-Konfigurationen enthalten. So steuern Sie, ob eine bestimmte Version von Windows erforderlich ist, oder ob Betriebssystemeinstellungen anzupassen sind. Letzteres kann das Einschalten des Entwicklermodus oder der Backupfunktion, das Nachinstallieren von Windows-Features oder das Setzen von Umgebungsvariablen umfassen.

Die Funktionen aus der Disziplin "Konfigurationsmanagement" sind dabei der PowerShell entliehen und basieren auf der Desired State Configuration (DSC). WinGet kann über die Konfigurationsdatei DSC-Ressourcen aufrufen, in Win-dows auswerten und – falls gewünscht – in einen Soll-Zustand überführen. Auch die Abhängigkeiten zu notwendigen DSC-Ressourcen hält WinGet dabei ein. Gilt es, verschiedene Ressourcen in Abhängigkeit zueinander zu konfigurieren, löst das PowerShell-Framework diese ebenfalls auf. Zum Beispiel lädt das System Teams-Hintergründe nur dann nach, wenn der Teams-Client erfolgreich installiert wurde.

Die Konfigurationsdateien können Sie entweder automatisiert ausführen oder Kollegen zur manuellen Weiterverarbeitung bereitstellen. Wählen Sie dabei einen modularen Ansatz, erlauben unterschiedliche WinGet-Konfigurationsdateien Flexibilität für die Zusammenstellung individueller Einstellungen für verschiedene Einsatzzwecke. Mit wenigen Konfigurationen können Entwickler über WinGet Entwicklungsumgebungen aufsetzen und Admin-Teams Jump-Hosts oder Terminalserver flexibel mit verschiedenen Paketen und Einstellungen bestücken.

Listing 1 zeigt die erste Konfiguration, die sich in die Abschnitte "Assertions" und "Resources" aufteilt. In beiden Abschnitten hinterlegen wir PowerShell-DSC-Ressourcen und Zustände, die WinGet ausliest und verarbeitet. In "Assertions" befinden sich Vorbedingungen, die vor einer erfolgreichen Ausführung erfüllt sein müssen. Das Beispiel prüft, ob die Windows-Version mindestens "24H2 (build 26100)" oder höher ist und erlaubt die weitere Ausführung der Konfiguration nur, wenn das Ergebnis positiv ausfällt – andernfalls wird abgebrochen.

Hingegen beschreibt "Resources" die Ressourcen, die auszuführen oder zu korrigieren sind. Zunächst prüft die Konfigurationsdatei, ob eine Umgebungsvariable gesetzt ist ("ClientType = Developer") und falls nicht, baut es diese ein. Anschließend erfolgt die Installation von PowerTools, WinRar und Visual Studio Code. Hierbei erhält Visual Studio als Abhängigkeit das erfolgreiche Setzen der Umgebungsvariable – das signalisiert die "DependsOn"-Eigenschaft. Jede Ressource ist eindeutig mit dem Property "id" referenzierbar, das innerhalb der Konfigurationsdatei frei wählbar ist. Somit werden Abhängigkeiten eindeutig aufgelöst, wenn Sie diese später via "DependsOn" referenzieren. Für alle Softwarepakete setzen wir außerdem "source" als Property. Im Beispiel ist das jeweils "winget", alternativ lässt sich der Microsoft Store ("msstore") oder ein selbst betriebenes WinGet-Repository im lokalen Netzwerk nutzen. Hierfür ist aber weitere Infrastruktur notwendig, die die relevanten APIs veröffentlicht.

Die Konfigurationsdatei aus Listing 1 speichern Sie als YAML-File, das Sie zunächst auf syntaktische Richtigkeit überprüfen:

Dies checkt die Syntax der Datei und stellt sicher, dass WinGet die referenzierten DSC-Module und Ressourcen auflösen und finden kann. Meldet sich WinGet nach einer kurzen Bedenkzeit nicht mit einem Problem, können Sie die Konfiguration anwenden:

WinGet wechselt nun in den Modus für das Konfigurationsmanagement und hilft, die notwendigen Änderungen zu analysieren. Bevor solche Anpassungen erfolgen, verlangt WinGet dafür eine Bestätigung. Für den vollautomatischen Betrieb nutzen Sie den Schalter "--accept-configuration-agreements", der den Warnhinweis unterdrückt. Vollautomatisch ist auch das Laden der notwendigen DSC-Module. Selbst wenn Sie zuvor keine weiteren PowerShell-Module nachgeladen haben, ist WinGet in der Lage, die richtigen Module aus der PowerShell-Gallery zu ziehen – eine Internetverbindung vorausgesetzt. Die erforderlichen Module checkt das Tool in der Validierungsphase der Konfiguration, unbekannte sucht es in der PSGallery und zeigt dies auch entsprechend an. Erst nachdem Sie den Warnhinweis quittiert haben und die Anwendung der Konfiguration startet, beginnt der eben beschriebene Downloadprozess.

Die Konfigurationsdatei kann im lokalen Dateisystem, auf einer Freigabe oder auf einem Webserver liegen. Solange der Benutzer oder Rechner – je nachdem in welchem Kontext WinGet läuft – die Konfiguration erreichen kann, ist sie ausführbar:

Nach der Installation sind die Softwarepakete sofort einsatzbereit. Wer neugierig vor dem Bildschirm sitzenbleibt, kann mitverfolgen, dass der Windows-Desktop flackert. Sowohl für WinRAR als auch Visual Studio Code werden die Explorer-Erweiterungen für das Kontextmenü aktualisiert. Beide Softwarepakete starten sofort und das YAML-File, das vermutlich auf Ihrer Testmaschine lagert, können Sie nun sofort mit VSCode öffnen und bearbeiten.

In unserem zweiten Beispiel (Listing 2) konfigurieren wir einen Windows-Server. Seit Windows Server 2025 gehört WinGet zum Funktionsumfang und ist somit auch ohne manuelle Installation eine valide Methode für Konfigurationsmanagement. In diesem Beispiel prüft das Skript zwei Vorbedingungen: die Windows-Version und die Präsenz der Remotedesktop-Serverrolle. Anschließend checken wir, ob die Ordnerstruktur eines angegebenen Fileshares auch lokal existiert – und falls nicht, samt Ordnern, Unterordnern und Dateien kopiert. Zudem wird die Remotedesktop-Gateway-Rolle überprüft und nachinstalliert. Gleiches gilt für das Softwarepaket für Microsoft Teams, das wir auf diesem RDS-Server nutzen möchten. Für die Windows-Serverrollen nutzen Sie den Namen des Windows-Features, den Sie in PowerShell viaGet-WindowsFeature  ermitteln. Sehen Sie sich die Module in Listing 2 genauer an, stellen Sie fest, dass Sie Community-Module mit Modulen von Microsoft beliebig mischen können. Das xRobocopy-Module ist ein Gemeinschaftsprojekt der Community und dem Powershell-Team.

In Listing 2 übernimmt das xRobocopy-Modul [1] das Prüfen und Nachkopieren der Dateien und Ordner. Es verfügt, wie der Name schon sagt, über ähnliche Funktionen wie das gleichnamige Kommandozeilentool. Sie erhalten darüber interessante Funktionen wie automatische Neustarts des Kopiervorgangs oder automatische Netzwerkanmeldung, sowie rekursives Kopieren komplexer Ordnerstrukturen – inklusive leerer Ordner.

Dieses Beispiel sollte auf einem neu installierten Windows-Server ohne RDS mit der Meldung "The system is not in the desired state asserted by the configuration." alle weiteren Aktivitäten verweigern. Das stimmt, denn die Prüfung nach der Rolle "RDS-Server" findet sich in der "Assertions"-Sektion der Konfigurationsdatei. Während Vorgaben in der Sektion "Resources" automatisch korrigiert werden sollen, stoppen Abweichungen aus "Assertions" die Konfiguration sofort und führen zum Abbruch. In diesem Fall müssen wir zunächst die RDS-Rolle installieren. Diese Methodik ist gut geeignet, um manuelle Arbeiten am Server abzufragen und auf Vollständigkeit zu überprüfen.

Listing 3 ist eine Erweiterung zu Listing 2 (hier sind die Assertions und die weiteren Resources gekürzt). In dieser Erweiterung verwenden Sie das DSC-Modul "FileContentDSC" zusammen mit "KeyValuePair", um eine Konfigurationsdatei anzupassen. Sie suchen im TXT-File den unter "Name" angegebenen Key und ersetzen den Wert, der in der Konfigurationsdatei steht durch "Text". So wird im Beispiel aus "SERVERDOMAIN=FABRIKAM" etwa "SERVERDOMAIN=CONTOSO", nachdem Sie die Konfiguration mit WinGet übernommen haben. Das Modul kennt weitere Ressourcen, wie INI-Dateimanipulation oder simple Textsubstitution [2].

Gerade für RDS-Server kann WinGet ein interessanter Weg sein, Softwarepakete zu installieren und aktuell zu halten. Da Sie meist mehrere Knoten für die verschiedenen Benutzersessions zur Verfügung stellen müssen, sollten diese optimalerweise denselben Softwarestand und die gleichen Softwarepakete mit identischer Konfiguration aufweisen. Definieren Sie an zentraler Stelle korrekt konfigurierte Server, entstehen Maschinen, die wie aus einem Ei gepellt aussehen. Auch wenn Sie später die Einstellungen anpassen und erneut anwenden lassen, zieht WinGet die Konfiguration nach. Softwareaktualisierungen für die Pakete führen Sie ebenfalls per WinGet aus – entweder als geplante Aufgabe oder als Remoteaktion via PowerShell.

Für das Konfigurationsmanagement setzt WinGet voll und ganz auf DSC. Schwierig bleibt in diesem Setup gerade für Neueinsteiger die Transferleistung der DSC-Modul- und Ressourcenamen, um sie in die WinGet-Konfiguration im YAML-Format zu überführen. Damit WinGet die richtigen Module für PowerShell DSC und innerhalb der Module die passenden Ressourcen findet, beschreiben Sie diese im Format "ModuleName/ Resource". In den Listings finden sich Beispiele hierfür, etwa "Microsoft.WinGet.DSC/WinGetPackage" oder" PsDscResource/WindowsFeature".

Die Schwierigkeit liegt darin, das verwendete Modul zu benennen, insbesondere wenn Sie die Module noch nicht kennen oder diese bereits im Betriebssystem enthalten sind. Da die Module in DSC-Konfigurationsskripten nur "WindowsFeature" oder "xRobocopy” heißen, in WinGet aber auf deren Namen basieren, ist das Übersetzen nicht immer einfach. Zum Einstieg müssen Sie hierbei auf eine Internetsuche zurückgreifen oder mit dem "validate”-Schalter gründlich testen. In Windows verfügbare Module sind in [3] beschrieben und über die Suche in der PSGallery [4] findet WinGet alle weiteren. Die Filter für "DSC Resource” helfen bei der Ressourcensuche. Darunter haben Sie Zugriff auf fertige Definitionen, die unter anderem auch die Änderung der HOSTS-Datei, der Windows-Firewall oder das Nachladen von Daten von Webservern erlauben.

Da WinGet regelmäßig für die Konfiguration von Entwicklungsumgebungen zum Einsatz kommt, hat das WinGet-Team an Erweiterungen für das Konfigurationsmanagement via DSC gearbeitet. Dabei kommt es zu einer Verschachtelung, wenn DSC auf eine Drittanbieterkomponente wirkt, die via DSC eingespielt wurde. In Listing 4 betrifft "npm" den Java-Script Paketverwalter. Anstatt in WinGet die Paketverwaltung von npm zu übernehmen, bedient sich WinGet via DSC der Funktionalitäten von npm. Denn damit kann WinGet flexibel viele npm-Pakete installieren.

Das Listing hat diesmal keine Assertions-Sektion, geht dafür direkt auf die Konfiguration ein. Über WinGet soll NodeJS auf den Rechner gelangen und anschließend wird das npm-Paket "Yarn" installiert. Das Listing ist eine abgeänderte Form eines Beispiels von Microsoft, das die Erweiterbarkeit des DSC-Frameworks zeigt. Die Ressource, um NodeJS zu installieren ist "Microsoft.WinGet.DSC/ WinGetPackage". Für die Installation der npm-Pakete hat Microsoft ein weiteres Modul geschrieben: NpmDsc mit der Ressource "NpmPackage".

Die Konfigurationen für WinGet sind in sich geschlossen. Alle Abhängigkeiten und Prüfungen im "Assertions"-Teil der deklarativen Definition gelten nur jeweils für die Konfigurationsdatei. Wer eine Reihe von Konfigurationsänderungen mit komplexen Abhängigkeiten kontrolliert durchführen will, kommt nicht umhin, längere Definitionen zu erstellen. Eine Maximalgröße dafür ist nicht bekannt, für die Wartbarkeit sowie für die flexiblere Nutzung bieten sich jedoch kleinere Konfigurationsdateien an.

Diese führen Sie nacheinander aus und da sie in sich geschlossen sind, erfolgt auch ihre Verarbeitung seriell. So bleibt zwar das Einhalten von Abhängigkeiten über mehrere Dateien auf der Strecke, die Konfigurationen sind dafür aber für einen breiteren Einsatz nützlich. Anstelle eine Definition pro Entwicklertyp zu erstellen, lässt sich eine Basisdefinition für alle Entwickler, sowie detaillierte Definitionen für Frontend-, Backend- und Datenbankentwickler anlegen. Die rollenspezifischen Definitionen sind dann einfacher durch die jeweiligen Gruppen wartbar und lassen sich besser auslagern. Ähnliches gilt für die Serverkonfiguration: Sie können sich für die auf Serverrollen basierende Konfiguration entscheiden oder kleinere, modulare Einstellungen erlauben, die bestimmte Szenarien oder Anwendungsfälle abbilden.

Da DSC aus Textdateien besteht, steuern Sie die Aktualisierung und Versionierung einfach mit bestehenden Werkzeugen, die auch andere Skripte und Automation verwalten. Besonders einfach machen Sie es sich mit einem eigenen GitHub-Repository, wo Sie Beispielskripte einbinden sowie internen Teams per Pull-Requests die Fähigkeiten zur Selbstverwaltung der Definitionen an die Hand geben. Die Änderungen wandern dann per Pipeline in YAML-Dateien auf dem Fileshare oder Webserver, von dem sie starten sollen.

Wer sich schon mit PowerShell DSC auskennt, wird sich schnell mit der Paket- und Konfigurationsverwaltung in WinGet zurechtfinden. Für Neulinge stellt das Layout der YAML-Konfiguration und das Übersetzen von Modulen und Ressourcen in die Konfigurationsdatei eine kleine Einstiegshürde dar. Dafür erhalten Sie aber ein Konfigurationswerkzeug, das sich leicht auch für Maschinen außerhalb zentral verwalteter Umgebungen nutzen lässt. Zudem können Sie die Konfigurationen für WinGet sehr leicht per Pipeline verwalten und veröffentlichen und Clients sowie Server periodisch auf Richtigkeit prüfen und nachinstallieren lassen.