Einführung

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

Wie Level Winget ausführt

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

Wird ausgeführt als SYSTEM: Level führt Winget unter dem SYSTEM Konto, nicht als angemeldeter Benutzer oder in einer Standard-Adminsitzung. Jedes Paketverhalten, das vom Benutzerkontext abhängt, funktioniert auf diese Weise nicht.
Erzwingt 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 nahezu jeden Bericht der Art „funktioniert in PowerShell, aber nicht in Level".

Häufige Probleme

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

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 eine andere Umgebung und Registrierung hat als ein angemeldeter Benutzer. In den meisten Fällen äußert sich dies als Berechtigungsproblem oder als fehlender Benutzerpfad.

Für Pakete, die grundlegend eine Benutzersitzung erfordern, gibt es keine Umgehungslösung. Für diese sollten Sie einen skriptbasierten Ansatz mit PsExec oder eine geplante Aufgabe, die in einem bestimmten Benutzerkontext ausgeführt wird.

Paket installiert sich als Admin, aber nicht über Level

Level erzwingt Maschinenbereich. Ein Paket kann sich problemlos als Admin ohne --scope machine fehlschlagen, wenn Maschinenbereich erforderlich ist.

Testen Sie es direkt, um dies zu bestätigen:

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

Wenn dies in einer Admin-PowerShell-Sitzung fehlschlägt, stellt das Paket keinen Maschinenbereich-Installer bereit. Level kann es nicht über die Winget-Aktion installieren. Die einzigen Möglichkeiten sind, 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.

Die Upgrade-Aktion zeigt weniger Pakete als erwartet

Level fügt --scope machine zu Upgrade-Scans hinzu, sodass in der Upgrade-Liste nur maschinenbereichsbezogene Installationen 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.

Die Paketinstallation läuft in Level ab, funktioniert aber über Admin-PowerShell

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

Ein Paket von Auto-Updates ausschließen

Die Upgrade Winget Package Aktion hat ein integriertes Ausgeschlossene(s) Paket(e) Feld. Geben Sie dort eine oder mehrere Paket-IDs ein, und diese Pakete werden beim Upgrade-Lauf übersprungen – kein Pinning oder Befehlszeilen-Workarounds erforderlich.

Überprüfen, ob ein Paket den Maschinenbereich unterstützt

Die zuverlässigste 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 Admin-PowerShell-Sitzung aus. Wenn er dort erfolgreich ist, funktioniert er auch in Level.

FAQ

Verwendet Level das standardmäßige Microsoft Winget oder eine eigene Version? Level installiert und verwaltet seine eigene Winget-Implementierung. Die Install Winget Aktion (oder eine andere Winget-Aktion, die es automatisch installiert) richtet die von Level verwaltete Version ein. Dies gewährleistet ein konsistentes Verhalten auf allen Ihren Geräten, unabhängig davon, welche Winget-Version (falls vorhanden) bereits installiert war.
Ich kann eine Paket-ID nicht 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 Levels Winget installiert ist. Die gefundene ID ist diejenige, die in die Level-Aktion eingetragen wird.
Kann ich Winget-Befehle direkt vom Level-Terminal aus ausführen? Ja. Das Hintergrundterminal von Level wird ausgeführt als SYSTEM, sodass dort ebenfalls die Einschränkungen bezüglich 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. Die Winget-Implementierung von Level kann dem Community-Repository geringfügig hinterherhinken. Wenn ein sehr aktuelles Paket nicht angezeigt wird, prüfen Sie, ob der --scope machine Bereich ist noch nicht im Manifest definiert.