Einführung

Level's Winget-Aktionen werden als SYSTEM Benutzer und erzwingt den Maschinenbereich für alle Vorgänge. Die meisten Installations- und Aktualisierungsfehler lassen sich auf eine dieser beiden Einschränkungen zurückführen. Wer diese von Anfang an versteht, kann die Mehrheit der gemeldeten Probleme lösen.

Wie Level Winget ausführt

Für jede Level-Winget-Aktion gelten immer zwei Dinge:

Wird ausgeführt als SYSTEM: Level führt Winget unter dem SYSTEM Konto, nicht als angemeldeter Benutzer oder eine normale Administratorsitzung. Jedes Paketverhalten, das vom Benutzerkontext abhängt, funktioniert nicht auf dieselbe Weise.
Erzwingt den Maschinenbereich: Level fügt --scope machine für alle Winget-Vorgänge. Nur Pakete mit einem in ihrem Manifest definierten Maschinenbereich können über Level installiert oder aktualisiert werden.

Diese beiden Einschränkungen erklären fast jede Meldung „funktioniert in PowerShell, aber nicht in Level".

Häufige Probleme

Paket wird über PowerShell, aber nicht über Level installiert

Wenn Sie ein Paket als aktuell angemeldeter Benutzer installieren können, die Level-Aktion jedoch fehlschlägt, liegt der Unterschied im Benutzerkontext. Level wird ausgeführt als SYSTEM, das über eine andere Umgebung und Registrierung als ein angemeldeter Benutzer verfügt. Meistens äußert sich dies als Berechtigungsproblem oder fehlender Benutzerpfad.

Für Pakete, die grundsätzlich eine Benutzersitzung erfordern, gibt es keine Umgehungslösung. Erwägen Sie für diese eine skriptbasierte Vorgehensweise mit PsExec oder eine geplante Aufgabe, die unter einem bestimmten Benutzerkontext ausgeführt wird.

Paket wird als Administrator, aber nicht über Level installiert

Level erzwingt den Maschinenbereich. Ein Paket kann problemlos als Administrator ohne --scope machine aber schlagen fehl, wenn der Maschinenbereich erforderlich ist.

Testen Sie es direkt zur Bestätigung:

winget install --scope machine -e --id PACKAGE_ID

Wenn dies in einer administrativen PowerShell-Sitzung fehlschlägt, stellt das Paket keinen Maschinenbereich-Installer bereit. Level kann es nicht über die Winget-Aktion installieren. Die einzigen Optionen bestehen darin, eine alternative Paket-ID zu finden, die den Maschinenbereich unterstützt, oder es über eine „Skript ausführen"-Aktion mit einem anderen Installer zu installieren.

Aktualisierungsaktion zeigt weniger Pakete als erwartet

Level fügt --scope machine zu Aktualisierungsscans hinzu, sodass nur Installationen im Maschinenbereich in der Aktualisierungsliste erscheinen.

Sie können dies überprüfen, indem Sie den entsprechenden Befehl selbst ausführen:

winget upgrade --scope machine --all

Wenn die Ergebnisse mit dem übereinstimmen, was Level anzeigt, ist Level korrekt. Pakete, die im Benutzerbereich installiert wurden, werden nicht angezeigt.

Paketinstallation läuft in Level ab, funktioniert aber über administrative PowerShell

Dies ist selten. Es passiert, wenn der Installer des Pakets den Silent/Quiet-Modus nicht korrekt verarbeitet und auf Benutzerinteraktion wartet, die niemals eintreffen kann, da Level ausgeführt wird als SYSTEM ohne Benutzeroberfläche. Hierfür gibt es keine Umgehungslösung – das Problem liegt beim Installer selbst. Überprüfen Sie die offenen Issues des Pakets im winget-pkgs-Repository.

Ein Paket von automatischen Aktualisierungen ausschließen

Die Winget-Paket aktualisieren Aktion verfügt über ein integriertes Ausgeschlossene(s) Paket(e) Feld. Geben Sie dort eine oder mehrere Paket-IDs ein, und diese Pakete werden während der Aktualisierung übersprungen – keine Pinning- oder Befehlszeilen-Workarounds erforderlich.

Prüfen, ob ein Paket den Maschinenbereich unterstützt

Die definitive Prüfung ist das Paketmanifest im winget-pkgs-Repository. Suchen Sie nach InstallerScope: machine im Manifest. Wenn es fehlt oder auf user, kann die Winget-Aktion von Level es nicht installieren.

Die praktische Abkürzung: Führen Sie den winget install --scope machine Befehl oben in einer administrativen PowerShell-Sitzung. Wenn er dort erfolgreich ist, funktioniert er auch in Level.

Häufig gestellte Fragen

Verwendet Level die standardmäßige Microsoft Winget-Version oder eine eigene? Level installiert und verwaltet seine eigene Winget-Implementierung. Die Winget installieren Aktion (oder eine andere Winget-Aktion, die sie automatisch installiert) richtet Level's verwaltete Version ein. Dies gewährleistet ein konsistentes Verhalten auf allen Ihren Geräten, unabhängig davon, welche Winget-Version (falls vorhanden) bereits vorhanden war.
Ich kann keine Paket-ID finden. Wo suche ich? Durchsuchen Sie das winget-pkgs-Repository oder führen Sie winget search <name> in einer PowerShell-Sitzung auf einem Gerät, auf dem Level's Winget installiert ist. Die gefundene ID ist das, was in die Level-Aktion eingetragen wird.
Kann ich Winget-Befehle direkt aus Level's Terminal ausführen? Ja. Level's Hintergrundterminal wird ausgeführt als SYSTEM, sodass dort ebenfalls die Einschränkungen für Maschinenbereich und SYSTEM-Kontext gelten. Testen Sie Befehle zuerst im Terminal, bevor Sie sie in eine Automatisierung einbauen.
Ein Paket wurde kürzlich zu winget-pkgs hinzugefügt, aber Level zeigt es nicht als verfügbar an. Level's Winget-Implementierung kann dem Community-Repository gegenüber leicht verzögert sein. Wenn ein sehr aktuelles Paket nicht angezeigt wird, prüfen Sie, ob der --scope machine Bereich ist noch nicht im Manifest definiert.