Das Symptom
Ein Admin baut ein Bereitstellungsskript: winget install für zehn Programme, ausgeführt per Aufgabenplanung als SYSTEM, über ein RMM-Werkzeug oder als Intune-Plattformskript. Interaktiv als Benutzer läuft alles, im Skript heißt es ‚winget ist nicht als Befehl erkannt’ oder der Aufruf scheitert still. Die Fehlersuche dreht sich um PATH, Neuinstallation des App Installers und Ausführungsrichtlinien, bis Stunden vergangen sind.
Die „Layer 8“-Wahrheit
Die Troubleshooting-Seite von WinGet nennt die Ursache unter der Überschrift System Context: „WinGet is delivered via the App Installer as a packaged application. MSIX (packaged) applications depend on the package being registered for the user.“ Und dann der entscheidende Satz: „As packages can be registered for any user except NT AUTHORITY\SYSTEM (aka LocalSystem, aka System), the WinGet CLI is not supported in the system context.“ Das ist keine Fehlkonfiguration, sondern eine Eigenschaft des Paketformats: Für den Benutzer SYSTEM gibt es keine Paketregistrierung, also auch kein winget.exe.
Microsoft nennt den Ausweg gleich mit: „The Microsoft.WinGet.Client PowerShell module can be used in the system context with applications that are installed machine wide.“ Skripte, die als SYSTEM laufen, nutzen also das PowerShell-Modul; die winget.exe bleibt dem Benutzerkontext vorbehalten.
Zusätzlich gilt für den Installationsbereich, und zwar auch im Benutzerkontext: „Not all installers support installing in “user” scope vs. “machine” scope consistently.“ MSIX-Pakete verhalten sich laut Seite zuverlässig, MSI-Pakete meist, EXE-Installer nicht deterministisch; und „Packages installed in user scope may still require UAC (User Account Control) authorization from an administrator.“ Der Scope-Schalter löst das SYSTEM-Problem nicht, er ist eine zweite Fehlerquelle daneben.
Wer wissen will, was winget wirklich getan hat, liest die Protokolle: „Use the command winget –info to find the directory path to your WinGet log files.“ Mit –logs oder –open-logs an einem beliebigen Befehl öffnet winget den Protokollordner danach. Im SYSTEM-Kontext findet man dort allerdings nichts, weil winget.exe dort nie gelaufen ist, und genau das ist die Diagnose.
Die Lehre ist übertragbar: Wenn ein Befehl in einem Kontext fehlt, der in einem anderen vorhanden ist, lohnt die Frage, ob er dort überhaupt existieren kann, bevor man sucht, warum er nicht gefunden wird. Bei MSIX-Paketen ist die Antwort an den Benutzer gebunden, und SYSTEM ist kein Benutzer, für den registriert wird. Das steht in einem Absatz bei Microsoft, und der Absatz ist kürzer als jede Fehlersuche.