Mit winget upgrade halte ich Windows-Programme mit wenigen Befehlen aktuell, ohne jeden Hersteller-Installer einzeln anfassen zu müssen. Für die Systemverwaltung ist das mehr als Komfort: Du siehst zuerst, welche Pakete veraltet sind, kannst Updates gezielt oder gesammelt ausrollen und vermeidest unnötigen Klickaufwand. Genau darum geht es hier, inklusive sinnvoller Optionen, typischer Stolperfallen und einem sauberen Ablauf für den Arbeitsalltag.
Die wichtigsten Punkte auf einen Blick
- Vor dem Massenlauf prüfe ich zuerst mit
winget list --upgrade-available, welche Pakete überhaupt betroffen sind. - Gezielte Updates sind meist stabiler als ein blinder Komplettlauf, besonders bei Fachsoftware und größeren Werkzeugen.
-
--all,--include-unknown,--include-pinnedund--uninstall-previouslösen konkrete Sonderfälle, sind aber nicht automatisch sinnvoll. - Für Administratoren zählen Rechte, Wartungsfenster und Protokollierung oft mehr als reine Geschwindigkeit.
- Wenn WinGet keine eindeutige Version erkennt oder ein Paket gepinnt ist, hilft kein Zwang, sondern nur die passende Option oder eine bewusste Ausnahme.
So lese ich die Update-Liste richtig
Ich trenne bei WinGet immer zwischen Inventur und Ausführung. Erst lasse ich mir anzeigen, welche Anwendungen überhaupt ein Update haben, und erst danach starte ich die eigentliche Aktualisierung. Das ist der sauberste Weg, weil du so nicht blind alles anfasst, was gerade auf dem Rechner liegt.
winget list --upgrade-available
winget updateWinGet kennt dafür auch den Alias update; in meinen Beispielen nutze ich ihn gern, weil die Lesbarkeit besser bleibt. Entscheidend ist: Der Befehl arbeitet nicht mit Wildcards, sondern erwartet einen möglichst eindeutigen Treffer. Wenn du ein Paket gezielt ansprechen willst, ist die ID fast immer robuster als der Anzeigename.
Praktisch ist auch, dass winget list nicht nur Pakete zeigt, die ursprünglich über WinGet installiert wurden. Die Liste kann also den realen Zustand eines Systems besser abbilden als viele erwarten. Ich achte dabei besonders auf die Spalte mit der Quelle, denn sie verrät mir, von wo ein Update überhaupt kommen würde. Wenn die Quelle nicht zur Umgebung passt, prüfe ich das lieber vor dem Start eines größeren Laufs.
Wenn die Ausgabe sauber lesbar ist, wird die eigentliche Aktualisierung deutlich sicherer. Und genau dort wird es interessant, wenn du einzelne Pakete oder ganze Gruppen anfassen willst.
Pakete gezielt oder gesammelt aktualisieren
Im Alltag arbeite ich meist in drei Stufen: ein einzelnes Paket, eine definierte Gruppe oder der komplette Bestand. Welche Variante sinnvoll ist, hängt nicht von der Technik, sondern von der Umgebung ab. Auf einem privaten Rechner kann ein Komplettlauf okay sein, in einer Firmenumgebung will ich vorher wissen, was genau passiert.
| Ziel | Befehl | Wann ich ihn nutze |
|---|---|---|
| Einzelnes Paket aktualisieren | winget update --id Microsoft.PowerToys |
Wenn nur ein Werkzeug kritisch ist oder ich gezielt testen will |
| Mehrere Pakete in einem Lauf | winget update Microsoft.Edit Microsoft.NuGet |
Wenn ein kleiner, klarer Satz von Tools gepflegt werden soll |
| Alle verfügbaren Updates prüfen | winget update |
Wenn ich erst einen Überblick brauche, bevor etwas installiert wird |
| Alle Pakete aktualisieren | winget update --all |
Wenn der Rechner in ein Wartungsfenster fällt und ich Zeit für den Komplettlauf habe |
Der Unterschied zwischen Anzeige und Ausführung ist in der Praxis entscheidend. Ich schaue mir die Liste oft morgens an, markiere die Pakete mit dem größten Risiko oder dem größten Nutzen und starte den Sammellauf erst später. So vermeidest du, dass ein einzelnes großes Update den ganzen Vormittag blockiert.
Für Teams mit mehreren Arbeitsplätzen ist das noch wichtiger. Ein sauberer Ablauf spart nicht nur Zeit, sondern auch Rückfragen aus dem Support. Wenn ein Paket Probleme macht, bleibt die Änderung klein und nachvollziehbar.
Microsoft Learn weist darauf hin, dass der Update-Befehl auch mit mehreren Paketen in einem Lauf umgehen kann. Genau das macht ihn für die Systemverwaltung attraktiv: Du musst nicht für jede Anwendung ein eigenes Tool oder einen eigenen Installerpfad pflegen.
Wenn du solche Läufe planst, lohnt sich der Blick auf die Zusatzschalter. Dort entscheidet sich oft, ob der Prozess wirklich robust ist oder nur auf dem Papier gut aussieht.
Wann sich die wichtigsten Schalter lohnen
Die Zusatzoptionen sind kein Zierrat. Sie lösen echte Sonderfälle, und genau deshalb nutze ich sie nur dann, wenn ich den Effekt auch will. Für Standard-Updates reichen oft wenige Befehle, aber in einer verwalteten Umgebung sind die Details schnell entscheidend.
Feste Versionen und Kompatibilität
Wenn eine Anwendung nur mit einer bestimmten Version sauber läuft, setze ich die Version bewusst fest. Das ist zum Beispiel dann sinnvoll, wenn ein Add-in, ein Plugin oder ein interner Workflow noch nicht mit der neuesten Ausgabe getestet wurde. Für solche Fälle ist ein stabiler Zwischenstand oft besser als das sofortige Maximum.
Der Schalter für eine exakte Version ist auch dann nützlich, wenn du Rollbacks oder abgestufte Freigaben im Team abbildest. Ich würde ihn aber nicht als Alltagseinstellung verwenden. In den meisten Fällen ist die aktuelle Version die bessere Wahl, solange kein Kompatibilitätsproblem bekannt ist.
Stille Läufe, Interaktion und Neustarts
Für automatische Wartungsfenster ist ein stiller Lauf meist die richtige Wahl. In einem manuellen Support-Termin kann die interaktive Variante dagegen hilfreicher sein, weil du den Ablauf direkt begleiten kannst. Wenn ein Update einen Neustart verlangt, plane ich das immer ausdrücklich ein und verlasse mich nicht darauf, dass „es schon irgendwie passt“.
Bei größeren Umgebungen kombiniere ich stille Läufe oft mit den Bestätigungsoptionen für Paket- und Quellenvereinbarungen, damit der Prozess nicht an einer Rückfrage hängen bleibt. Das ist kein Luxus, sondern schlicht Betriebssicherheit. Ein ungeplanter Dialog kann dir sonst einen ganzen Batch stoppen.
Lesen Sie auch: Windows-Uptime prüfen - wann die Laufzeit wirklich zählt
Unbekannte und gepinnte Pakete
Microsoft Learn weist darauf hin, dass manche Anwendungen keine sauber erkennbare Versionsangabe liefern. In so einem Fall hilft der Schalter für unbekannte Versionen, wenn du bewusst trotzdem aktualisieren willst. Das ist nützlich, aber nicht automatisch empfehlenswert: Ich setze es nur ein, wenn ich Quelle und Paket wirklich vertraue.
Gepinnte Pakete sind der zweite Sonderfall. Ein Pin ist im Grunde eine bewusste Bremse, damit WinGet ein Paket nicht anfassen soll. Wenn du diese Bremse entfernen oder ausnahmsweise übergehen willst, musst du das gezielt tun. Für die Verwaltung ist das wichtig, weil es sonst so wirkt, als würde WinGet „nichts tun“, obwohl das Tool sich nur an die Vorgaben hält.
Für spezielle Installationsarten gibt es zusätzlich das Verhalten, das die vorherige Version deinstalliert. Das ist vor allem dann relevant, wenn ein Paket nicht neben alten Versionen liegen darf. Ich prüfe diesen Punkt lieber zweimal, weil er den Unterschied zwischen sauberem Upgrade und ungewollter Doppelinstallation macht.
Wenn die Schalter klar sind, sinkt das Fehlerrisiko deutlich. Trotzdem gibt es ein paar Klassiker, die in der Praxis immer wieder für Verwirrung sorgen.
Typische Stolperfallen in der Systemverwaltung
Die meisten Probleme mit WinGet entstehen nicht wegen des Befehls selbst, sondern wegen der Umgebung. Genau hier trennt sich ein praktischer Workflow von einem bloßen Terminal-Trick. Ich halte mir dafür eine kleine Checkliste, damit ich nicht jedes Mal dieselben Ursachen suche.
| Problem | Wahrscheinliche Ursache | Was ich dann mache |
|---|---|---|
| Es erscheinen keine Updates | Die Quelle meldet nichts Neues oder die Version ist nicht sauber erkannt | Zuerst die Liste prüfen, dann Quelle und Paket-ID verifizieren |
| Ein Paket wird nicht aktualisiert | Es ist gepinnt oder die aktuelle Version ist unbekannt | Gezielt mit den passenden Ausnahmeoptionen arbeiten oder den Pin bewusst anpassen |
| Der Lauf wartet auf Eingaben | Interaktive Abfragen blockieren den Prozess | Für Wartungsfenster auf stillen Modus und Bestätigungsflags setzen |
| Der Befehl braucht plötzlich erhöhte Rechte | Das Paket oder der Installer verlangt Elevation | Shell bewusst als Administrator starten und nur vertrauenswürdige Pakete bearbeiten |
Wichtig ist auch die Berechtigungssituation. Ohne Administratorrechte können manche Pakete zwar angestoßen werden, verlangen aber während der Installation eine Erhöhung. In einer Administratorshell siehst du solche Rückfragen nicht immer genauso wie im normalen Fenster. Das kann bequem sein, ist aber nur dann sinnvoll, wenn du genau weißt, was du installierst.
Außerdem sollte die Quelle sauber sein. WinGet arbeitet mit Quellen, und in einer professionellen Umgebung will ich diese Quellen bewusst eingrenzen. Ein Update aus der falschen Quelle ist kein kleiner Schönheitsfehler, sondern ein echtes Betriebsrisiko.
Wenn WinGet auf einem Gerät gar nicht reagiert, liegt die Ursache oft nicht im Update-Befehl selbst, sondern in der Installation des Clients oder in einer noch nicht sauber registrierten App-Installer-Umgebung. Dann löst man nicht das Symptom, sondern die Basis. Genau das spart später die meiste Zeit.
Damit ist der technische Teil klar. Der letzte Schritt ist die Frage, wie ich daraus einen belastbaren Ablauf für den Büroalltag mache.
So wird daraus ein sauberer Update-Workflow im Büro
Für einzelne Rechner reicht meistens ein einfacher Rhythmus: erst die verfügbaren Updates anzeigen, dann gezielt die wichtigsten Pakete anpacken und erst danach einen Sammellauf starten. Für Arbeitsplätze mit klaren Wartungsfenstern würde ich Updates dagegen strenger staffeln, damit Browser, Kommunikations-Tools und sicherheitsrelevante Programme zuerst dran sind.
Wenn ich viele Systeme verwalte, denke ich nicht in Einzelbefehlen, sondern in Routine. Das heißt: feste Prüfpunkte, saubere Protokolle, ein klarer Umgang mit Ausnahmen und möglichst wenig spontane Überraschung. Genau dort spielt WinGet seine Stärke aus, weil der Prozess wiederholbar bleibt und nicht von jedem einzelnen Hersteller-Installer abhängt.
Für Windows 10 ab Version 1809, Windows 11 und Windows Server 2025 ist das ein solides Werkzeug, solange du die Grenzen ernst nimmst. Mein praktischer Rat ist deshalb simpel: Liste zuerst, aktualisiere gezielt, nutze Sammelläufe nur im passenden Zeitfenster und dokumentiere Ausnahmen bewusst. So bleibt Softwarepflege planbar statt hektisch, und genau das zählt in einer guten Systemverwaltung.
