Winget unter Windows 11 und 10 lautlos installieren: Diese Anleitung zeigt Ihnen die nötigen Schritte – einfach, schnell und ganz ohne Nutzerinteraktion.
Wer WinGet ohne Microsoft Store, ohne Nutzerinteraktion und ohne Klicks bereitstellen möchte, installiert die Komponente über PowerShell – entweder mit dem offiziellen Cmdlet Repair-WinGetPackageManager aus dem Modul Microsoft.WinGet.Client oder durch das direkte Einspielen der .msixbundle-Datei per Add-AppxPackage.
Beide Wege funktionieren unter Windows 10 und Windows 11 vollständig automatisiert und ohne sichtbare Dialogfenster.
Was bedeutet „WinGet installieren“ eigentlich?
WinGet ist Teil der Systemkomponente App Installer, die auf aktuellen Windows-10- und Windows-11-Rechnern normalerweise bereits vorhanden ist und über den Microsoft Store aktuell gehalten wird. In bestimmten Szenarien fehlt WinGet jedoch vollständig oder liegt in einer veralteten Version vor – etwa auf frisch abgezogenen Images, auf Windows-10-LTSC-Systemen, auf Windows Server-Installationen, in Windows Sandbox oder auf Firmenrechnern, bei denen der Microsoft Store per Richtlinie gesperrt ist. Genau in diesen Fällen muss WinGet manuell und lautlos nachinstalliert werden, bevor es überhaupt zum Installieren anderer Software genutzt werden kann.
Zudem betrifft dies häufig automatisierte Bereitstellungsszenarien, etwa im Rahmen von Intune, MDT oder eigenen Provisionierungsskripten, bei denen ein Rechner direkt nach der Ersteinrichtung bereits über eine funktionsfähige WinGet-Umgebung verfügen soll, ohne dass sich jemand manuell anmelden und den Store öffnen muss.
Voraussetzungen für die lautlose Installation von WinGet
Bevor Sie WinGet automatisiert bereitstellen, benötigen Sie eine unterstützte Windows-Version. Offiziell wird WinGet ab Windows 10, Version 1809 (Build 17763) aufwärts unterstützt, ebenso alle aktuellen Windows-11-Versionen sowie Windows Server 2025. Ältere Server-Versionen wie Windows Server 2019 oder 2022 gelten hierbei ausdrücklich als experimentell und nicht offiziell unterstützt.
Zusätzlich benötigen Sie eine aktuelle PowerShell-Umgebung. Für das offizielle Cmdlet Repair-WinGetPackageManager ist mindestens PowerShell 7 erforderlich, da das Modul unter der klassischen Windows PowerShell 5.1 nicht zuverlässig lädt. Falls PowerShell 7 noch fehlt, installieren Sie diese vorab, beispielsweise über winget install --id Microsoft.PowerShell auf einem Referenzsystem oder über das offizielle MSI-Paket von Microsoft.
Ferner müssen administrative Rechte vorhanden sein, insbesondere wenn WinGet für alle Benutzer eines Geräts bereitgestellt werden soll. Ebenso benötigen Sie eine Internetverbindung, da sowohl das PowerShell-Modul als auch die WinGet-Paketdateien selbst heruntergeladen werden müssen, sofern sie nicht bereits lokal vorliegen.
WinGet lautlos installieren mit Repair-WinGetPackageManager
Der von Microsoft empfohlene Weg, um WinGet ohne Benutzerinteraktion einzurichten, führt über das PowerShell-Modul Microsoft.WinGet.Client. Öffnen Sie dazu eine PowerShell 7-Sitzung mit administrativen Rechten und führen Sie folgende Befehle nacheinander aus:
$ProgressPreference = 'SilentlyContinue'
Install-PackageProvider -Name NuGet -Force | Out-Null
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery -Scope AllUsers | Out-Null
Repair-WinGetPackageManager -AllUsersDie erste Zeile unterdrückt sämtliche Fortschrittsbalken der PowerShell selbst, damit auch dieser Teil vollständig lautlos abläuft. Der Befehl Install-PackageProvider stellt sicher, dass der NuGet-Anbieter vorhanden ist, ohne den sich das Modul nicht laden lässt. Anschließend installiert Install-Module das WinGet-Client-Modul, wobei der Parameter -Force jegliche Rückfrage unterdrückt und -Scope AllUsers die Installation systemweit statt nur für das aktuelle Konto vornimmt.
Der eigentliche Kernbefehl ist Repair-WinGetPackageManager. Er lädt die passende WinGet-Version herunter, installiert sämtliche notwendigen Abhängigkeiten und richtet die Komponente vollständig automatisiert ein. Der Zusatz -AllUsers sorgt dafür, dass WinGet nicht nur für das aktuell angemeldete Konto, sondern für sämtliche Benutzer des Geräts bereitgestellt wird, was besonders in Unternehmens- und Imaging-Szenarien wichtig ist.
Möchten Sie stattdessen eine Vorabversion mit neuen Funktionen einspielen, ergänzen Sie den Parameter -IncludePrerelease:
Repair-WinGetPackageManager -AllUsers -IncludePrereleaseWinGet manuell über die MSIXBundle-Datei installieren
Auf Systemen ohne Zugriff auf die PowerShell Gallery oder in stark eingeschränkten Umgebungen bietet sich alternativ die direkte Installation über die offizielle .msixbundle-Datei an, die Microsoft über GitHub bereitstellt. Dieser Weg eignet sich besonders für Windows Sandbox, LTSC-Systeme oder Server-Umgebungen ohne Store-Anbindung.
Zunächst benötigen Sie zwei Abhängigkeiten: das Paket Microsoft.VCLibs.Desktop sowie das UI-Framework Microsoft.UI.Xaml. Anschließend laden Sie die aktuelle WinGet-Bundle-Datei direkt vom offiziellen Release-Bereich des winget-cli-Projekts herunter. Ein vollständiges, lautloses Skript sieht wie folgt aus:
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri "https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx" -OutFile "VCLibs.appx"
Add-AppxPackage -Path "VCLibs.appx"
Invoke-WebRequest -Uri "https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -OutFile "winget.msixbundle"
Add-AppxProvisionedPackage -Online -PackagePath "winget.msixbundle" -SkipLicenseDer Befehl Add-AppxPackage installiert dabei zunächst die Laufzeitabhängigkeit für das aktuelle Benutzerkonto. Anschließend übernimmt Add-AppxProvisionedPackage die eigentliche WinGet-Installation systemweit und provisioniert das Paket zusätzlich für alle zukünftigen Benutzerkonten des Geräts, was besonders bei der Image-Erstellung von Bedeutung ist. Beachten Sie zudem, dass ältere WinGet-Versionen zusätzlich eine separate License1.xml-Datei sowie das Paket Microsoft.UI.Xaml benötigen, während aktuelle Releases diese Abhängigkeiten meist bereits gebündelt mitliefern.
Nach der Installation sollte ein kurzer Neustart der PowerShell-Sitzung erfolgen, da der Pfad zu winget.exe andernfalls unter Umständen noch nicht korrekt geladen ist. Führen Sie anschließend winget --version aus, um die erfolgreiche Installation zu bestätigen.
WinGet in Windows-Images und bei der automatisierten Bereitstellung vorinstallieren
Für IT-Administratoren, die WinGet direkt in ein Referenz-Image integrieren möchten, empfiehlt es sich, die benötigten Paketdateien vorab lokal abzulegen, statt sie bei jeder Bereitstellung erneut aus dem Internet zu laden. Dazu speichern Sie die .msixbundle-Datei sowie die VCLibs-Abhängigkeit in einem gemeinsamen Skriptverzeichnis, beispielsweise unter C:\Windows\Setup\Scripts\winget, und referenzieren diese lokalen Pfade anschließend in Ihrem Bereitstellungsskript.
Diese Vorgehensweise eignet sich zudem hervorragend für MDT– oder Intune-Aufgabensequenzen, bei denen das Skript direkt im Rahmen der Ersteinrichtung ausgeführt wird. Ebenso empfiehlt es sich, im Anschluss an die Installation automatisiert zu prüfen, ob winget –version eine gültige Ausgabe liefert, um Fehler in der Bereitstellungskette frühzeitig zu erkennen, bevor nachfolgende Skriptschritte fehlschlagen.
WinGet unter Windows Server lautlos bereitstellen
Unter Windows Server 2025 wird die WinGet-Komponente inzwischen über reguläre Systemaktualisierungen verteilt, wodurch sich die Installation dem Verhalten auf Windows 11 stark angleicht. Bei älteren Serverversionen wie Windows Server 2022 ist die Bereitstellung hingegen weiterhin als experimentell einzustufen und erfordert in der Regel das manuelle Nachinstallieren sämtlicher Abhängigkeiten über die zuvor beschriebene MSIXBundle-Methode.
Da Server-Betriebssysteme zudem häufig ohne Microsoft-Store-Anbindung betrieben werden, ist der Weg über Add-AppxProvisionedPackage hier meist die einzig praktikable Option. Zusätzlich sollten Administratoren beachten, dass WinGet auf Server-Systemen offiziell weniger intensiv getestet wird als auf Desktop-Versionen, weshalb sich ein gründlicher Test in einer Staging-Umgebung empfiehlt, bevor das Verfahren produktiv ausgerollt wird.
Häufige Fehler bei der lautlosen WinGet-Installation und deren Lösung
Ein verbreitetes Problem besteht darin, dass der Befehl winget nach der Installation zunächst nicht erkannt wird, obwohl die Installation augenscheinlich erfolgreich war. Häufig liegt dies daran, dass sich die Umgebungsvariable PATH erst nach einem Neustart der PowerShell-Sitzung oder des gesamten Systems aktualisiert. Ein einfacher Neustart der Sitzung behebt dieses Problem in den meisten Fällen zuverlässig.
Ein weiterer häufiger Fehler betrifft fehlende Abhängigkeiten. Wird lediglich die .msixbundle-Datei installiert, ohne vorher Microsoft.VCLibs.Desktop bereitzustellen, bricht die Installation mit einer Fehlermeldung zur fehlenden Laufzeitkomponente ab. Stellen Sie deshalb sicher, dass sämtliche Abhängigkeiten stets vor der eigentlichen WinGet-Datei installiert werden.
Zudem kommt es bei der Ausführung im Systemkontext, etwa über Intune oder Aufgabenplanung als NT AUTHORITY\SYSTEM, gelegentlich zu Problemen beim Laden des PowerShell-Moduls. In diesem Fall hilft es häufig, den Pfad zu den Windows-Apps manuell in die Umgebungsvariable PATH der aktuellen Sitzung aufzunehmen, bevor das Modul importiert wird.
Empfohlene Vorgehensweisen für die WinGet-Bereitstellung
Für einen stabilen und wiederholbaren Ablauf haben sich einige empfohlene Vorgehensweisen etabliert. Zunächst sollten Sie stets Repair-WinGetPackageManager dem manuellen MSIXBundle-Weg vorziehen, sofern eine Internetverbindung zur PowerShell Gallery besteht, da dieser Weg offiziell unterstützt wird und Abhängigkeiten automatisch auflöst. Andernfalls empfiehlt sich die manuelle Methode mit lokal vorgehaltenen Paketdateien.
Außerdem sollten Sie jede Bereitstellungsmethode zunächst in einer Testumgebung validieren, bevor sie in produktiven Imaging- oder Rollout-Prozessen zum Einsatz kommt. Ebenso empfiehlt sich eine abschließende Prüfung über winget --version, um die erfolgreiche Installation programmatisch zu bestätigen, statt sich allein auf das Ausbleiben von Fehlermeldungen zu verlassen. Zusätzlich sollten Administratoren die verwendete WinGet-Version dokumentieren, da sich Parameter und Verhalten zwischen älteren und neueren Releases mitunter unterscheiden.
Unterschiede zwischen Windows 10 und Windows 11 bei der WinGet-Installation
Auf Windows 11 ist die App-Installer-Komponente in aktuellen Versionen bereits vorinstalliert, sodass eine manuelle Bereitstellung meist nur bei stark eingeschränkten oder älteren Builds notwendig wird. Unter Windows 10 hingegen hängt die Verfügbarkeit stärker von der jeweiligen Version ab: Während aktuelle Feature-Updates WinGet in der Regel bereits mitbringen, fehlt die Komponente auf LTSC-Varianten grundsätzlich, da diese keinen Zugriff auf den Microsoft Store besitzen.
Zudem unterscheidet sich die Handhabung geringfügig bei der PowerShell-Version. Während Windows 11 zunehmend mit neueren PowerShell-Umgebungen ausgeliefert wird, muss unter Windows 10 häufiger zunächst PowerShell 7 separat nachinstalliert werden, bevor Repair-WinGetPackageManager überhaupt nutzbar ist. Die eigentlichen Installationsbefehle und Skripte bleiben jedoch zwischen beiden Systemen identisch und lassen sich ohne Anpassung wiederverwenden.
Häufige Fragen zur lautlosen Installation von WinGet
Warum fehlt WinGet auf manchen Windows-Systemen komplett?
Dies betrifft vor allem LTSC-Versionen von Windows 10 sowie ältere Server-Betriebssysteme, da diese keinen Zugriff auf den Microsoft Store besitzen, über den die Komponente normalerweise ausgeliefert und aktualisiert wird.
Welche PowerShell-Version benötige ich für Repair-WinGetPackageManager?
Sie benötigen mindestens PowerShell 7, da das Modul Microsoft.WinGet.Client unter der klassischen Windows PowerShell 5.1 nicht zuverlässig geladen werden kann.
Kann ich WinGet auch ohne Internetverbindung installieren?
Nur bedingt: Sie können die benötigten Paketdateien vorab herunterladen und lokal speichern, um sie anschließend offline mit Add-AppxProvisionedPackage einzuspielen. Der Download selbst erfordert jedoch zunächst eine Internetverbindung.
Wie prüfe ich, ob die lautlose Installation erfolgreich war?
Führen Sie nach der Installation den Befehl winget --version aus. Erscheint eine gültige Versionsnummer, war die Bereitstellung erfolgreich; erscheint stattdessen eine Fehlermeldung, hilft häufig ein Neustart der Sitzung.
Was ist der Unterschied zwischen Add-AppxPackage und Add-AppxProvisionedPackage?
Add-AppxPackage installiert eine Anwendung lediglich für das aktuell angemeldete Benutzerkonto, während Add-AppxProvisionedPackage das Paket zusätzlich für sämtliche zukünftigen Benutzerkonten des Geräts bereitstellt.
Funktioniert die lautlose WinGet-Installation auch auf Windows Server?
Ja, allerdings gilt dies vor allem für Windows Server 2025 als offiziell unterstützt. Bei älteren Serverversionen ist die Vorgehensweise als experimentell einzustufen und erfordert meist die manuelle MSIXBundle-Methode.
Warum wird winget nach der Installation nicht sofort erkannt?
Dies liegt in den meisten Fällen daran, dass die Umgebungsvariable PATH erst nach einem Neustart der Sitzung aktualisiert wird. Ein Neustart von PowerShell oder des gesamten Systems löst dieses Problem in der Regel zuverlässig.
Benötige ich administrative Rechte zur Installation von WinGet?
Für eine systemweite Bereitstellung mit -AllUsers beziehungsweise Add-AppxProvisionedPackage benötigen Sie administrative Rechte. Für eine reine Installation im aktuellen Benutzerkontext genügen hingegen normale Benutzerrechte.
Lässt sich WinGet in ein Intune-Bereitstellungsskript einbinden?
Ja, sowohl Repair-WinGetPackageManager als auch die manuelle MSIXBundle-Methode lassen sich problemlos in Intune-Skripte oder Win32-App-Bereitstellungen integrieren, um WinGet direkt bei der Geräteeinrichtung automatisiert nachzurüsten.
