winget upgrade –all richtig einsetzen: So automatisierst du Software-Updates unter Windows

Warum dieser Befehl dir Zeit, Nerven und Risiken spart

Wenn du Windows-Rechner wartest – privat, im Team oder im Unternehmen – sind verlässliche, automatisierte App-Updates Gold wert. Der Befehl winget upgrade –all (oft als Keyword auch „winget upgrade all“ gesucht) ist genau dafür gedacht: Er prüft alle installierten Anwendungen auf verfügbare Aktualisierungen und installiert sie in einem Rutsch. Das reduziert Angriffsflächen, schließt bekannte Lücken in Drittanbieter-Software und verhindert veraltete, inkompatible Versionen in deinem Stack.

Was ist WinGet und wie hängt „upgrade –all“ damit zusammen?

WinGet ist der offizielle Windows Package Manager, ausgeliefert über die App App-Installer und ab Windows 11 standardmäßig vorhanden. Er erlaubt dir Software über die Kommandozeile zu installieren, zu aktualisieren, zu deinstallieren und mit Skripten zu automatisieren – ähnliche Konzepte wie bei apt, yum oder brew. „winget upgrade“ listet verfügbare Updates, „winget upgrade --all“ führt sie durch.

WinGet arbeitet über Quellen („Sources“), typischerweise:

  • winget (Community-Repository, manifest-basiert)
  • msstore (Microsoft Store, inkl. vieler frei verfügbarer Apps)
  • Private Quellen (z. B. intern gehostete Repos für Unternehmen)

Ob WinGet verfügbar ist, prüfst du mit:

winget --version

Unter Windows 10 installierst du bei Bedarf den „App-Installer“ aus dem Microsoft Store.

winget upgrade all

Die zwei Kernschritte: prüfen und massenhaft aktualisieren

Zuerst sehen, was ansteht:

winget upgrade

Dieser Befehl listet alle Pakete, für die Updates verfügbar sind – inklusive installierter und verfügbarer Version. Sobald du weißt, was aktualisiert wird, kannst du alles auf einmal upgraden:

winget upgrade --all

Das ist die Kurzform; in der Praxis ergänzen viele Administratoren sinnvolle Schalter (siehe unten), um alles unbeaufsichtigt, leise und mit sauberem Logging durchlaufen zu lassen.

Wichtige Parameter für „upgrade –all“

Mit zusätzlichen Optionen steuerst du Verhalten, Interaktion und Logging. Die folgende Tabelle fasst die wichtigsten Schalter zusammen:

Parameter Funktion Typische Anwendung
--all Aktualisiert alle Pakete mit verfügbaren Updates. Massenaktualisierung im Batch oder Task.
--silent bzw. -h Versucht die Installer ohne UI einzusetzen. Automatisierte, unbeaufsichtigte Updates.
--interactive bzw. -i Erlaubt Installer-UI/Prompts. Wenn du bewusst Entscheidungen im Setup treffen willst.
--include-unknown Bezieht Pakete ein, deren installierte Version unbekannt ist (z. B. viele Store-Apps). Wichtig, wenn dir sonst Updates „durchrutschen“.
--accept-package-agreements Akzeptiert Lizenzbedingungen der Pakete. Unterdrückt Nachfragen in automatisierten Durchläufen.
--accept-source-agreements Akzeptiert Vereinbarungen der Quellen (z. B. msstore). Verhindert Interaktion bei der ersten Nutzung.
--log <Pfad> Schreibt ein Installationsprotokoll in die angegebene Datei. Auditing, Analyse, Fehlersuche.
--force Erzwingt Update-Versuche, z. B. bei Hash-Konflikten. Fehlerumgehung in Ausnahmen (bewusst vorsichtig einsetzen).
--version <x.y.z> Aktualisiert gezielt auf eine Version (falls verfügbar). Pinpoint-Updates, wenn du nicht die neueste willst.
--source <name> Beschränkt das Upgrade auf eine Quelle. Nur msstore oder nur winget-Community aktualisieren.
--location <Pfad> Installationspfad (wenn der Installer das unterstützt). Spezielle Verzeichnisanforderungen.

Praxisbeispiele: von „quick win“ bis „vollautomatisch“

1) Schnelles, leises Komplett-Update

winget upgrade --all --silent --include-unknown --accept-package-agreements --accept-source-agreements

Damit deckst du in einem Schritt die meisten Szenarien ab – leise, ohne Rückfragen, inkl. vieler Store-Apps mit unbekannter Versionsmeldung.

Siehe auch  Windows hängt bei „Windows wird vorbereitet, schalten Sie den Computer nicht aus“: Ursachen, schnelle Lösungen und langfristige Fixes

2) Mit Logging zur Nachvollziehbarkeit

winget upgrade --all --silent --include-unknown --accept-package-agreements --accept-source-agreements --log "C:\Logs\winget-upgrade.log"

Gerade in Teams und Unternehmen ist ein sauberes Log Pflicht – für Audit, Fehlersuche und Compliance.

3) Nur Community-Quelle aktualisieren

winget upgrade --all --source winget --silent --accept-package-agreements

Sinnvoll, wenn du Store-Updates separat behandeln willst (z. B. über Richtlinien oder dedizierte Wartungsfenster).

4) Bestimmte App ausnehmen (mit Pinning)

WinGet kennt „Pins“, um Updates zu blockieren. Beispiel:

winget pin add --id "Mozilla.Firefox"

Danach wird Firefox nicht mehr durch „upgrade –all“ aktualisiert, bis du den Pin entfernst:

winget pin remove --id "Mozilla.Firefox"

Hinweis: Pinned-Pakete sind standardmäßig von Upgrades ausgenommen. Verwende Pins, wenn du kritische Versionen einfrieren willst (z. B. bei Regressionen).

winget upgrade all

Wichtige Unterschiede und Stolperfallen

  • Kein Windows-Update: „winget upgrade --all“ aktualisiert Anwendungen, nicht das Betriebssystem. Feature- oder Sicherheitsupdates für Windows laufen weiterhin über Windows Update/WSUS/Intune.
  • Installer-Varianten: WinGet ruft die vom Paket definierten Installer (MSI, EXE, MSIX) auf – deren Silent-Optionen variieren. Nicht jeder Installer verhält sich identisch.
  • Offene Prozesse: Läuft eine App noch, kann ein Update scheitern (oder eine Neuinstallation ohne Effekt passieren). Schließe große Anwendungen vor einem Massenupdate.
  • Store-Apps und „Unknown“: Viele Store-Apps melden keine installierte Versionsnummer an WinGet. Nutze --include-unknown, um sie einzubeziehen.

Automatisierung: Geplante Aufgabe mit PowerShell

Ein robustes Setup ist eine geplante Aufgabe, die täglich oder wöchentlich läuft. Beispielskript:

# C:\Scripts\Upgrade-All-Apps.ps1
$timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$log = "C:\Logs\winget-upgrade-$timestamp.log"
$arguments = @(
  'upgrade','--all',
  '--silent',
  '--include-unknown',
  '--accept-package-agreements',
  '--accept-source-agreements',
  '--log', $log
)
Start-Process -FilePath 'winget.exe' -ArgumentList $arguments -Wait -NoNewWindow

Geplante Aufgabe anlegen (als Administrator):

schtasks /Create /TN "WinGet-Upgrade-All" /TR "powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\Upgrade-All-Apps.ps1" /SC WEEKLY /D SUN /ST 03:00 /RL HIGHEST /F

So laufen Updates automatisiert und mit Admin-Rechten sonntags um 03:00 Uhr durch – inklusive Logdatei pro Durchlauf.

Fehlerbehebung: typische Probleme und Lösungen

1) „App Installer“/WinGet veraltet oder beschädigt

  • Im Microsoft Store nach „App-Installer“ suchen und aktualisieren.
  • WinGet-Version prüfen: winget --version
  • Bei hartnäckigen Fehlern „App-Installer“ deinstallieren und neu installieren.

2) Hash-Mismatch oder Signaturprobleme

Wenn ein Paket nicht zum erwarteten Hash passt, stoppt WinGet aus Sicherheitsgründen. Du kannst mit --force fortfahren, solltest das aber nur tun, wenn du der Quelle vertraust und das Risiko bewusst abwägst.

3) Installer-Exitcode 1603 (MSI, „fatal error during installation“)

  • Anwendung und zugehörige Prozesse schließen.
  • Temporäre Dateien bereinigen, Neustart versuchen.
  • Im Log nach konkreten Hinweisen suchen (--log verwenden).

4) Quelle (Source) liefert Fehler

  • Quellen prüfen: winget source list
  • Quelle neu initialisieren: winget source reset --force oder winget source update
  • Proxy/Firewall-Einstellungen prüfen, falls Downloads blockiert werden.

5) Store-Apps werden nicht aktualisiert

  • --include-unknown anhängen, um Apps ohne bekannte installierte Version einzubeziehen.
  • Bei lizenzpflichtigen Apps sicherstellen, dass die Store-Lizenz auf dem Gerät vorhanden ist (Anmeldung im Store/Intune-Verteilung).

6) Nur ein Paket läuft „silent“, andere öffnen Fenster

Installer verhalten sich unterschiedlich. Ergänze --silent und sorge für aktuelle Paketmanifeste. Einzelne Hersteller ignorieren den Silent-Flag teilweise; im Log erkennst du, welche Installer abweichen.

Siehe auch  PC neu aufsetzen: Der gründliche Praxis‑Leitfaden für Windows 10/11

7) Wo sind die Logs?

Mit --log <Pfad> führst du eine eigene Logdatei. Zusätzlich schreibt WinGet interne Diagnosen im Benutzerprofil (typisch unter LocalState). Für die operative Praxis ist das explizite Log pro Lauf die bessere Wahl.

Best Practices für saubere, reproduzierbare Upgrades

  • Regelmäßigkeit: Wöchentlich oder mindestens monatlich laufen lassen. Je konstanter, desto weniger „große Wellen“.
  • Logging und Rotation: Mit Zeitstempel loggen und alte Logs rotieren, damit die Platte nicht vollläuft.
  • Vorher schließen: Browser, Office, IDEs – offene Apps erschweren Updates. In Unternehmen: Nutzer informieren oder in Off-Zeiten planen.
  • Pins für Ausnahmen: Kritische Tools auf bekannter Version halten, bis Kompatibilität geklärt ist.
  • Quellenhygiene: winget source update regelmäßig ausführen; bei Fehlern resetten.
  • Security-First: --force nur in Ausnahmefällen. Vertraue nur bekannten Quellen.

Enterprise-Aspekte: Skalierung, Policies, Private Repositories

Im Unternehmenskontext punktet WinGet durch Skriptbarkeit, Nachvollziehbarkeit und Integration in bestehende Tools:

  • Intune/ConfigMgr: „Proactive Remediations“ oder Win32-Apps können „winget upgrade –all“-Jobs verteilen. Logs zentral einsammeln.
  • Private Repos: Eigene Paketquellen erlauben kontrollierte Freigaben, intern signierte Artefakte und abgestufte Rollouts.
  • Freigabeprozesse: Erst Test-Ring, dann breite Verteilung. Pins gezielt einsetzen, um Rollouts zu drosseln.
  • Compliance: Protokollierung, Nachweise, standardisierte Wartungsfenster – WinGet fügt sich gut in Audits ein.

Praxis-Tipp: Erzeuge pro Standort oder Gerätegruppe eigene geplante Aufgaben mit versetzten Startzeiten. So verhinderst du Peaks auf Proxy/CDN und verkleinerst das Risiko gleichzeitiger, fehlerhafter Upgrades.

„Unknown“-Versionen verstehen (vor allem bei Store-Apps)

Wenn WinGet für ein installiertes Paket die Version nicht ermitteln kann, zeigt es „Unknown“ an. Das kommt häufig bei Microsoft-Store-Apps vor. Standardmäßig werden solche Apps nicht aktualisiert, da WinGet nicht sicher erkennt, ob es überhaupt eine neuere Version gibt. Mit:

winget upgrade --all --include-unknown

weist du WinGet an, trotzdem einen Updateversuch zu starten. So vermeidest du „blinde Flecken“ – z. B. bei Medien- oder Kommunikations-Apps aus dem Store, die sicherheitsrelevante Fixes nur dort erhalten.

Abgrenzung: „winget upgrade all“ vs. „winget upgrade –all“

Als Keyword taucht häufig „winget upgrade all“ auf. Technisch korrekt ist die Variante mit doppeltem Bindestrich:

winget upgrade --all

Die Schreibweise ohne „–“ führt nicht zum gewünschten Verhalten. Verwende in Skripten daher immer die offizielle Syntax.

Erweiterte Techniken: Filter, Teilmengen, Exporte

  • Nur ein Paket aktualisieren: winget upgrade --id "Mozilla.Firefox"
  • Teilmenge per Quelle: winget upgrade --source msstore
  • Export/Import: Mit winget export sicherst du deinen Softwarezustand (Manifeste), mit winget import stellst du ihn wieder her – nützlich für Neuaufsetzungen.
  • Version fixieren: --version bei kritischen Tools, wenn du bewusst nicht auf „latest“ willst (sofern Paket die Version liefert).

Sicherheit und Vertrauensketten

WinGet verifiziert Downloads gegen erwartete Hashes, nutzt HTTPS und stützt sich auf Paketmanifeste. Trotzdem gilt: Die Kette ist nur so stark wie ihr schwächstes Glied. Deshalb:

  • Verwende ausschließlich vertrauenswürdige Quellen (Community, Store, interne Repos).
  • Setze --force nur gezielt und dokumentiert ein.
  • Protokolliere jeden Lauf und archiviere Logs revisionssicher in Teams/Unternehmens-Storage.
Siehe auch  ASUS Aura Sync

Checkliste: So setzt du „upgrade –all“ stabil auf

  1. App-Installer aus dem Microsoft Store aktualisieren und winget --version prüfen.
  2. Verzeichnisstruktur für Skripte und Logs anlegen (z. B. C:\Scripts, C:\Logs).
  3. PowerShell-Skript mit sinnvollen Flags und Log-Pfaden erstellen.
  4. Geplante Aufgabe wöchentlich im Off-Hours-Fenster einrichten.
  5. Pins für kritische Pakete setzen; Test-Ring definieren.
  6. Nach dem ersten Lauf Logs prüfen und Ausnahmen dokumentieren.

Häufige Fragen zu winget upgrade –all (FAQ)

Aktualisiert „winget upgrade –all“ auch Windows selbst?

Nein. Es geht ausschließlich um Anwendungen. Windows-Updates laufen über Windows Update, WSUS oder Intune.

Warum sehe ich bei manchen Apps „Unknown“ als installierte Version?

Weil WinGet die Version nicht zuverlässig auslesen kann – das betrifft häufig Store-Apps. Füge --include-unknown hinzu, um sie dennoch zu berücksichtigen.

Ich möchte bestimmte Programme bewusst nicht aktualisieren. Wie geht das?

Nutze Pins: winget pin add --id "<Paket-ID>". Entferne Pins mit winget pin remove. So verhinderst du ungewollte Upgrades bei „–all“.

Was ist der Unterschied zwischen „–silent“ und „–interactive“?

--silent versucht die Installer ohne UI und Rückfragen auszuführen, --interactive erlaubt UI/Prompts. Für Automatisierung ist --silent sinnvoller – vorausgesetzt, die Installer respektieren die Option.

Wo finde ich Logs, wenn ein Update schiefgeht?

Verwende --log <Pfad>, um eine Datei zu schreiben (empfohlen). Zusätzlich führt WinGet interne Diagnosen unter deinem Benutzerprofil. Für Produktionseinsätze solltest du explizit loggen und die Dateien zentral archivieren.

Ein Update bricht mit „Hash mismatch“ ab. Was nun?

Das ist eine Sicherheitsmaßnahme. Prüfe die Quelle, versuche später erneut oder setze in Ausnahmefällen --force ein. Dokumentiere solche Fälle.

Lässt sich „winget upgrade –all“ über die Aufgabenplanung betreiben?

Ja. Lege ein PowerShell-Skript an (mit --silent, --accept-*, --log) und erstelle eine geplante Aufgabe mit höchsten Rechten. So laufen Updates ohne Benutzeranmeldung.

Kann ich nur die Store-Apps aktualisieren?

Ja. Mit --source msstore beschränkst du den Lauf auf die Store-Quelle. Kombiniere das bei Bedarf mit --include-unknown.

Wie gehe ich mit Installern um, die trotz „–silent“ Fenster öffnen?

Das ist abhängig vom Hersteller-Installer. Prüfe die Paket-Manifeste, führe ein Log, melde Auffälligkeiten im betreffenden Projekt oder plane die Läufe außerhalb der Nutzungszeiten.

Gibt es eine „Dry-Run“-Option?

Ein expliziter „Dry-Run“ ist im Standard-CLI nicht vorgesehen. Verwende zunächst winget upgrade, um anstehende Updates zu sehen, bevor du --all startest.

Fazit

Mit winget upgrade –all automatisierst du App-Updates unter Windows zuverlässig und nachvollziehbar – von Einzelrechnern bis zur Flotte. Entscheidend für einen stabilen Betrieb sind sinnvolle Parameter (--silent, --include-unknown, --accept-*), sauberes Logging, regelmäßige Läufe und eine klare Governance (Pins, Test-Ringe, Quellenhygiene). Setzt du diese Bausteine konsequent um, wird „winget upgrade all“ zu einem robusten Bestandteil deiner Update-Strategie – sicher, transparent und mit minimalem manuellen Aufwand.