Mit WinGet und der Windows-Aufgabenplanung kannst du Software regelmäßig auf verfügbare Updates prüfen und Aktualisierungen weitgehend automatisch ausführen lassen. Die zuverlässigste Variante ist eine Aufgabe, die ein PowerShell-Skript zu einem passenden Zeitpunkt startet und WinGet mit den gewünschten Bestätigungsparametern aufruft. Vorher solltest du aber festlegen, ob nur Benutzerprogramme oder auch systemweit installierte Anwendungen aktualisiert werden sollen, denn manche Installationen benötigen Administratorrechte.
Für einen sicheren Einstieg lässt du die Aufgabe zunächst nur bei deiner Anmeldung oder zu einem festen Zeitpunkt im angemeldeten Benutzerkonto laufen. So kannst du Ausgaben, Fehler und mögliche Neustartanforderungen prüfen. Erst wenn der Ablauf zuverlässig funktioniert, ist ein unbeaufsichtigter Start sinnvoll. Wichtig ist außerdem, dass WinGet auf dem Rechner verfügbar ist und die verwendeten Paketquellen funktionieren.
Was WinGet bei automatischen Updates übernimmt
WinGet ist der Paketmanager von Microsoft für Windows. Er kann Programme aus registrierten Quellen suchen, installieren, aktualisieren und teilweise auch deinstallieren. Für die Aktualisierung mehrerer Anwendungen wird typischerweise der Befehl winget upgrade --all verwendet. Dabei prüft WinGet, welche installierten Pakete eine neuere Version anbieten, und arbeitet die gefundenen Einträge nacheinander ab.
Das Verfahren ersetzt keine vollständige Softwareverwaltung. WinGet erfasst nur Programme, die sich einer unterstützten Paketdefinition zuordnen lassen. Einige Anwendungen aktualisieren sich über eigene Mechanismen, werden von der Quelle nicht angeboten oder verlangen eine manuelle Zustimmung. Auch Programme mit speziellen Installationsroutinen können sich anders verhalten als klassische Desktop-Anwendungen.
Die Aufgabenplanung startet nicht selbst WinGet-Updates. Sie stellt lediglich den zeitlichen Auslöser bereit. Die eigentliche Prüfung und Installation übernimmt weiterhin WinGet. Diese Trennung ist hilfreich: Du kannst das Skript manuell testen, die Aufgabe unabhängig davon anpassen und bei Bedarf den automatischen Lauf wieder deaktivieren.
Voraussetzungen vor der Einrichtung prüfen
Öffne zunächst Windows Terminal, PowerShell oder die Eingabeaufforderung und prüfe, ob WinGet erreichbar ist. Für die erste Kontrolle reicht:
winget --versionWird eine Versionsnummer ausgegeben, kann die Befehlszeile grundsätzlich verwendet werden. Erscheint dagegen eine Meldung, dass der Befehl nicht gefunden wurde, fehlt entweder die zuständige App-Installer-Komponente oder der Pfad zu WinGet ist in dieser Sitzung nicht verfügbar. In diesem Fall solltest du WinGet zuerst über die vorhandene Microsoft-Softwareverwaltung beziehungsweise den Microsoft Store aktualisieren oder reparieren. Einen festen Installationspfad solltest du nicht blind in ein Skript eintragen, weil sich die Bereitstellung je nach Windows-Version, Benutzerkonto und Installation unterscheiden kann.
Danach lässt du dir die verfügbaren Paketquellen anzeigen:
winget source listEine aktive Quelle muss nicht bedeuten, dass jedes installierte Programm aktualisiert werden kann. Sie zeigt nur, dass WinGet eine Quelle kennt und deren Konfiguration lesen kann. Für eine erste Bestandsaufnahme verwendest du:
winget upgradeDer Befehl listet mögliche Aktualisierungen auf, führt sie aber noch nicht aus. Prüfe dabei, ob die angezeigten Programme tatsächlich von dir gewünscht sind. Wenn ein Paket fehlt, ist das nicht automatisch ein Fehler. Der Anbieter kann eine eigene Update-Funktion verwenden, die entsprechende Paketdefinition kann fehlen oder die installierte Version lässt sich nicht eindeutig erkennen.
Den vollständigen Update-Befehl zuerst manuell testen
Bevor du eine Aufgabe anlegst, solltest du den geplanten Befehl in einem normalen Terminal ausführen. Für einen automatisierten Durchlauf mit den üblichen Bestätigungen lautet er:
winget upgrade --all --accept-source-agreements --accept-package-agreements--all fordert WinGet auf, alle erkannten verfügbaren Aktualisierungen zu bearbeiten. Mit --accept-source-agreements und --accept-package-agreements werden die entsprechenden Vereinbarungen automatisch bestätigt, sofern WinGet sie verlangt. Diese Parameter sind praktisch für die Aufgabenplanung, weil während eines unbeaufsichtigten Laufs keine Eingabe erfolgen kann.
Die automatische Zustimmung bedeutet nicht, dass du jede Softwareprüfung überspringen solltest. Lies die Ausgabe beim manuellen Test und achte auf Paketnamen, Versionsnummern sowie Rückgabemeldungen. Wenn du ein bestimmtes Programm nicht automatisch aktualisieren willst, solltest du nicht pauschal alle Pakete verwenden. Stattdessen kannst du die Liste der gewünschten Paket-IDs prüfen und einzelne Aktualisierungen ausführen.
winget upgrade --id Microsoft.PowerToys --exact --accept-source-agreements --accept-package-agreementsDie Paket-ID im Beispiel muss zu dem Eintrag passen, den WinGet auf deinem Rechner anzeigt. Verwende keine Beispiel-ID für ein anderes Programm. Mit --exact verhinderst du, dass eine ungenaue Namenssuche einen ähnlich benannten Eintrag auswählt. Welche Optionen ein bestimmtes Paket unterstützt, kannst du mit der Suche und den verfügbaren Paketinformationen prüfen.
Während des Tests können Anwendungen geschlossen, Installationsfenster geöffnet oder erhöhte Rechte verlangt werden. Beende deshalb keine laufende Arbeit, bevor du den Ablauf kennst. Wenn ein Installer einen Neustart fordert, entscheidet nicht WinGet allein über das Verhalten des jeweiligen Installationsprogramms. Für einen unbeaufsichtigten Rechner ist es deshalb sinnvoll, den automatischen Start zunächst nur zu einem Zeitpunkt einzuplanen, an dem ein Neustart oder ein geschlossener Arbeitsplatz akzeptabel wäre.
Ein PowerShell-Skript für die Aufgabenplanung anlegen
Ein Skript bietet gegenüber einem direkt eingetragenen langen Befehl mehrere Vorteile. Du kannst Protokollierung ergänzen, die Ausgabe in einer Datei speichern und den Ablauf später ohne Änderungen an der Aufgabe testen. Lege beispielsweise im eigenen Dokumente-Ordner eine Datei mit dem Namen WinGet-Updates.ps1 an.
Verwende für einen ersten Durchlauf dieses Skript:
$ErrorActionPreference = "Continue"
$logDirectory = Join-Path $env:LOCALAPPDATA "WinGet-Automation"
$logFile = Join-Path $logDirectory "updates.log"
New-Item -Path $logDirectory -ItemType Directory -Force | Out-Null
$wingetCommand = Get-Command winget.exe -ErrorAction SilentlyContinue
if (-not $wingetCommand) {
Add-Content -Path $logFile -Value "$(Get-Date -Format s) WinGet wurde nicht gefunden."
exit 1
}
Add-Content -Path $logFile -Value "$(Get-Date -Format s) Updateprüfung gestartet."
& $wingetCommand.Source upgrade --all --accept-source-agreements --accept-package-agreements *>> $logFile
$exitCode = $LASTEXITCODE
Add-Content -Path $logFile -Value "$(Get-Date -Format s) WinGet beendet mit Code $exitCode."
exit $exitCodeDas Skript verändert zunächst nur den Ordner für das Protokoll und startet anschließend WinGet. Get-Command winget.exe sucht die ausführbare Datei in der aktuellen Umgebung, anstatt einen möglicherweise falschen festen Pfad zu erzwingen. Die Ausgabe wird in updates.log geschrieben. Dadurch kannst du nach einem automatischen Lauf nachvollziehen, ob Pakete gefunden, installiert oder wegen eines Fehlers übersprungen wurden.
Speichere die Datei in einem Ordner, auf den das Benutzerkonto zugreifen kann. Ein Pfad ohne Sonderzeichen und ohne Netzlaufwerk ist für den Anfang am unkompliziertesten. Wenn du das Skript mit einem anderen Konto oder ohne Anmeldung ausführen willst, musst du besonders auf Benutzerprofile, WinGet-Berechtigungen und die Verfügbarkeit des App-Installer-Kontexts achten.
Teste das Skript zunächst aus PowerShell. Wechsle in den Ordner, in dem die Datei gespeichert ist, und starte sie mit:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE est
gWinGet-Updates.ps1"Der Pfad im Beispiel ist nur ein Platzhalter und muss durch den tatsächlichen Speicherort ersetzt werden. Der darin enthaltene Schreibfehler wäre problematisch, deshalb solltest du den Pfad beim Einsatz sorgfältig anpassen. Ein Beispiel mit einem typischen Dokumente-Ordner könnte so aussehen:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE
test
gWinGet-Updates.ps1"Da Backslashes und Platzhalter in kopierbaren Befehlen leicht beschädigt werden können, ist ein einfacher Pfad besser. Wenn du die Datei beispielsweise direkt unter C:WinGet-Automation
gWinGet-Updates.ps1 gespeichert hast, lautet der Start:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:
gWinGet-Automation
gWinGet-Updates.ps1"Verwende beim Speichern selbstverständlich einen tatsächlich vorhandenen Pfad. Die Option -ExecutionPolicy Bypass gilt nur für diesen PowerShell-Prozess und ändert die Richtlinie nicht dauerhaft. In verwalteten Umgebungen kann eine Gruppenrichtlinie trotzdem verhindern, dass das Skript startet. Das Protokoll liegt nach dem Lauf unter %LOCALAPPDATA%
WinGet-Automation
gupdates.log.
Die Aufgabe grafisch in der Aufgabenplanung erstellen
Die grafische Aufgabenplanung eignet sich, wenn du Auslöser und Sicherheitsoptionen lieber sichtbar einstellst. Suche im Startmenü nach Aufgabenplanung und öffne die Anwendung. Wähle nicht die einfache Aufgabe, wenn du mehr Kontrolle über Konto, Bedingungen und Wiederholungen brauchst. Erstelle stattdessen eine Aufgabe über die entsprechende Funktion im Aktionsbereich.
Vergib einen eindeutigen Namen wie WinGet Software Updates. Eine Beschreibung hilft später bei der Wartung, etwa mit dem Hinweis, dass die Aufgabe ein PowerShell-Skript für WinGet startet. Verwende für den ersten Test das aktuelle Benutzerkonto und die Option, die Aufgabe nur bei bestehender Anmeldung auszuführen. Damit bleibt der Lauf an deine Benutzerumgebung gebunden und du kannst Eingabeaufforderungen oder Installer-Fenster sehen.
Lege anschließend einen Zeitplan fest. Ein wöchentlicher Termin ist für viele Rechner ein guter Start, weil du die Ergebnisse kontrollieren kannst. Eine tägliche Prüfung bedeutet nicht zwingend, dass täglich Programme installiert werden; WinGet aktualisiert nur, wenn eine passende Version verfügbar ist. Häufige Läufe erhöhen aber die Zahl der Prüfungen und können bei manchen Installern zu mehr Hinweisen oder Wartungsfenstern führen.
Als Aktion wählst du das Starten eines Programms. Trage als Programm powershell.exe ein. In das Feld für Argumente kommt der Start des Skripts, beispielsweise:
-NoProfile -ExecutionPolicy Bypass -File "C:
WinGet-Automation
gWinGet-Updates.ps1"Der Pfad muss wieder an den Speicherort deiner Datei angepasst werden. Das Arbeitsverzeichnis kannst du leer lassen. Wenn du die Aufgabe nur bei Anmeldung ausführst, verwendet PowerShell das Benutzerprofil, in dem WinGet bei deinem Test funktioniert hat.
Unter den Bedingungen kannst du festlegen, ob die Aufgabe nur bei einer bestimmten Stromversorgung oder nur bei verfügbarer Netzwerkverbindung starten soll. Eine Netzwerkbedingung ist sinnvoll, wenn der Rechner häufig offline ist. Sie verhindert jedoch nicht jeden Verbindungsfehler: DNS-Probleme, Proxy-Anforderungen, Filter oder eine nicht erreichbare Quelle können weiterhin auftreten.
Speichere die Aufgabe und starte sie anschließend über das Kontextmenü manuell. Beobachte, ob ein PowerShell-Fenster erscheint und ob der Zeitstempel im Protokoll aktualisiert wird. Wenn kein Fenster sichtbar ist, bedeutet das nicht automatisch, dass nichts passiert ist. Prüfe zuerst die Protokolldatei und den Verlauf der Aufgabe.
Die Aufgabe alternativ per PowerShell registrieren
Du kannst die Aufgabenplanung auch mit PowerShell konfigurieren. Diese Variante eignet sich besonders, wenn du die Einrichtung auf mehreren eigenen Rechnern nachvollziehbar wiederholen willst. Das folgende Beispiel legt eine Aufgabe an, die täglich um 03:00 Uhr läuft und das Skript im angemeldeten Benutzerkonto startet:
$taskName = "WinGet Software Updates"
$scriptPath = "C:
WinGet-Automation
gWinGet-Updates.ps1"
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$scriptPath`""
$trigger = New-ScheduledTaskTrigger -Daily -At 3:00AM
$principal = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Limited
Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger -Principal $principal -Description "Prüft Softwareupdates mit WinGet"Der Pfad in $scriptPath muss existieren. Interactive bindet die Ausführung an eine interaktive Anmeldung, während Limited keine erhöhten Administratorrechte anfordert. Das ist absichtlich die vorsichtige Ausgangskonfiguration. Systemweit installierte Programme können damit möglicherweise nicht aktualisiert werden.
Wenn du den Befehl verwendest, musst du PowerShell nicht zwingend als Administrator öffnen, sofern du die Aufgabe im eigenen Benutzerkontext anlegst und die lokalen Richtlinien dies erlauben. Für Aufgaben mit höheren Rechten gelten andere Sicherheitsanforderungen. Eine Erhöhung sollte nicht einfach ergänzt werden, nur weil ein einzelnes Programm beim Test Administratorrechte verlangt. Prüfe zuerst, ob der betreffende Installer selbst eine erhöhte Sitzung benötigt und ob du diesen Ablauf unbeaufsichtigt zulassen möchtest.
Die registrierte Aufgabe kannst du mit folgenden Befehlen kontrollieren:
Get-ScheduledTask -TaskName "WinGet Software Updates"
Get-ScheduledTaskInfo -TaskName "WinGet Software Updates"Mit dem nächsten Befehl startest du sie unabhängig vom Zeitplan:
Start-ScheduledTask -TaskName "WinGet Software Updates"Die Rückmeldung dieses Cmdlets bestätigt nur, dass die Aufgabe gestartet wurde. Ob WinGet erfolgreich war, erkennst du erst am Protokoll und am letzten Ausführungsstatus. Ein fehlender sichtbarer Prozess kann normal sein, wenn die Aufgabe im Hintergrund läuft.
Warum automatische Läufe manchmal nichts aktualisieren
Ein leerer Updatebericht ist nicht zwingend ein Hinweis auf eine Fehlkonfiguration. Wenn winget upgrade keine Einträge findet, können alle erkannten Programme bereits aktuell sein. Ebenso möglich ist, dass die verwendeten Anwendungen nicht von WinGet verwaltet werden oder dass die Quelle keine neuere Version anbietet.
Ein weiterer häufiger Unterschied ist die Verfügbarkeit einer interaktiven Sitzung. Manche Installer zeigen Dialoge an oder erwarten, dass ein Benutzer angemeldet ist. WinGet kann dann zwar starten, aber ein Paket bleibt mit einem Fehlercode zurück. Suche im Protokoll nach dem Namen des Pakets und dem jeweiligen Rückgabecode. Behandle den Code nicht als allgemeine Diagnose, wenn du seine Bedeutung nicht sicher zuordnen kannst. Der nächste Schritt ist dann die manuelle Aktualisierung genau dieses Programms.
Auch laufende Anwendungen können ein Update verhindern. Viele Installer können Dateien nicht ersetzen, solange das Programm geöffnet ist. Die Aufgabenplanung sollte daher nicht einfach alle Anwendungen zwangsweise beenden. Wenn ein bestimmtes Paket regelmäßig scheitert, schließe das Programm vor dem manuellen Test und prüfe, ob sich das Ergebnis ändert. Ein automatischer Lauf ohne Benutzeraufsicht ist für diese Anwendung möglicherweise ungeeignet.
Systemweite Installationen und Administratorrechte
Windows-Programme können nur für einen Benutzer oder für mehrere Benutzer des Rechners installiert sein. Bei einer Installation für alle Benutzer benötigt der Installer häufig erhöhte Rechte. Eine Aufgabe mit RunLevel Limited kann diese Aktualisierung überspringen oder mit einem Berechtigungsfehler beenden.
Das bedeutet nicht, dass du jede WinGet-Aufgabe mit vollständigen Administratorrechten ausführen solltest. Eine privilegierte Aufgabe darf Software installieren, die Systemänderungen vornimmt. Wenn ein Skript, ein Paket oder die Paketquelle manipuliert wird, kann daraus ein erhebliches Sicherheitsrisiko entstehen. Nutze erhöhte Rechte nur, wenn du die Aufgabe, das Skript, die Quellen und die zu aktualisierenden Programme kontrollierst.
Für einen privaten Rechner ist die manuelle Freigabe systemweiter Updates häufig die bessere Lösung. Lass die Aufgabenplanung die verfügbaren Updates prüfen oder protokollieren und starte die eigentliche Aktualisierung bei Bedarf in einer bewusst geöffneten PowerShell-Sitzung mit den notwendigen Rechten. So siehst du UAC-Abfragen und Installationsmeldungen, statt sie unbemerkt in einen Hintergrundlauf zu verlagern.
Quellen, Paket-IDs und Ausschlüsse prüfen
WinGet arbeitet mit Quellen, in denen Paketinformationen und Installationsdaten bereitgestellt werden. Zeige die aktuelle Konfiguration an:
winget source listWenn eine Quelle beschädigt oder nicht erreichbar ist, kann die Updateprüfung unvollständig sein. Setze Quellen nicht vorschnell zurück, wenn du ihre Konfiguration in einer verwalteten Umgebung nicht kennst. Unternehmensrechner können interne Quellen, Proxy-Regeln oder Richtlinien verwenden. Änderungen an der Quellenkonfiguration sollten mit der zuständigen Administration abgestimmt werden.
Für einzelne Programme ist die Paket-ID entscheidend. Eine Namenssuche kann mehrere Treffer liefern, während eine exakte ID den Zielbereich einschränkt. Die verfügbare Liste kannst du beispielsweise mit einer Suche nach dem Programmnamen untersuchen:
winget search "PowerToys"Verwende die angezeigte ID nur dann in einem eigenen Skript, wenn sie zum gewünschten Anbieter und zur installierten Anwendung passt. Ein ähnlicher Name allein genügt nicht. Bei mehreren Treffern solltest du Anbieter, Quelle und Version vergleichen.
Wenn du bestimmte Anwendungen ausnehmen möchtest, ist eine pauschale Aktualisierung mit --all nicht immer passend. Eine kontrollierte Liste einzelner IDs ist wartungsintensiver, verhindert aber, dass ein unerwartetes Paket automatisch geändert wird. Das ist vor allem bei Spezialsoftware, älteren Plugins oder Programmen mit fester Unternehmensversion sinnvoll.
Protokollierung und Erfolgskontrolle einrichten
Das Skript schreibt jeden Lauf in eine Datei unter dem lokalen AppData-Ordner des ausführenden Kontos. Öffne die Datei nach einem Test und prüfe mindestens den Startzeitpunkt, die erkannten Paketnamen und den Abschlusscode. Ein Zeitstempel ohne WinGet-Ausgabe kann darauf hindeuten, dass der Befehl nicht gefunden wurde oder die Aufgabe unter einer anderen Umgebung läuft.
Nach einer erfolgreichen Aktualisierung kannst du die installierte Version erneut auslesen:
winget listSuche den betreffenden Eintrag in der Liste und vergleiche ihn mit der zuvor angezeigten Version. Die Liste ist eine Bestandsaufnahme aus Sicht von WinGet und nicht zwangsläufig identisch mit jeder Windows- oder Herstelleranzeige. Bei Programmen mit eigenem Updatekanal kann die Herstelleroberfläche die verlässlichere Kontrolle sein.
Aktiviere in den Eigenschaften der Aufgabe den Verlauf, wenn du Startzeit, Ende und Rückgabestatus direkt in der Aufgabenplanung nachvollziehen möchtest. Der Verlauf ersetzt nicht die WinGet-Ausgabe, hilft aber bei der Unterscheidung zwischen einem nicht gestarteten und einem fehlgeschlagenen Lauf.
Bewahre Protokolle nicht unbegrenzt auf, wenn sie auf einem gemeinsam genutzten Rechner unnötig wachsen. Das einfache Skript hängt neue Ausgaben an dieselbe Datei an. Du kannst die Datei gelegentlich sichern oder löschen, wenn du die bisherige Diagnose nicht mehr brauchst. Ändere die Protokollierung erst, nachdem der grundlegende Ablauf funktioniert.
Automatische Aktualisierung sicher begrenzen
Ein Updatezeitpunkt sollte nicht mit laufenden Arbeitszeiten kollidieren. Wähle einen Termin, an dem Anwendungen geschlossen sein dürfen und ein Installationsfenster nicht stört. Auf mobilen Geräten ist zusätzlich die Stromversorgung relevant, weil ein abgebrochener Installationslauf bei niedrigem Akkustand ungünstig sein kann.
Vermeide Aufgaben, die unmittelbar beim Systemstart mit weitreichenden Rechten laufen, wenn dafür kein zwingender Grund besteht. Der Startvorgang kann noch von Netzwerkdiensten, Microsoft-Konto-Anmeldung oder App-Installer-Komponenten abhängig sein. Ein Lauf nach der Anmeldung oder ein bewusst gewählter täglicher beziehungsweise wöchentlicher Termin ist leichter zu kontrollieren.
Für wichtige Arbeitsrechner solltest du vor einer breiten Automatisierung festlegen, wie du bei einer inkompatiblen Programmversion zurückgehst. WinGet bietet nicht für jedes Paket denselben Rückweg. Manche Programme erlauben eine Reparatur oder eine Rückkehr über den eigenen Installer, andere benötigen eine vorher gesicherte Installationsdatei oder eine Wiederherstellung aus einer Unternehmensverwaltung.
Ein Systemwiederherstellungspunkt ist kein Ersatz für eine Datensicherung und schützt nicht zuverlässig jede Anwendungskonfiguration. Dokumente, Projekte, Browserprofile und andere wichtige Daten müssen unabhängig davon gesichert werden. Bei geschäftlich wichtigen Programmen solltest du automatische Updates zunächst auf einem Testgerät oder in einem getrennten Benutzerprofil prüfen.
Aufgabe ändern, pausieren oder vollständig entfernen
Wenn die automatische Aktualisierung unerwünschte Änderungen verursacht, deaktiviere zuerst die Aufgabe, statt sofort das Skript zu löschen. In der Aufgabenplanung kannst du die Aufgabe auswählen und deaktivieren. Damit bleibt die Konfiguration für eine spätere Analyse erhalten, aber neue Läufe werden verhindert.
Per PowerShell kannst du den Status ebenfalls ändern:
Disable-ScheduledTask -TaskName "WinGet Software Updates"Nach der Ursachenprüfung lässt sich die Aufgabe wieder aktivieren:
Enable-ScheduledTask -TaskName "WinGet Software Updates"Wenn du die Aufgabe nicht mehr benötigst, entfernst du sie mit:
Unregister-ScheduledTask -TaskName "WinGet Software Updates" -Confirm:$falseDieser Befehl löscht die Registrierung der Aufgabe, nicht automatisch die installierten Programme und auch nicht das PowerShell-Skript. Entferne die Skriptdatei und das Protokoll nur separat, wenn du sie nicht mehr brauchst. Prüfe vor dem Löschen den Namen genau, damit nicht versehentlich eine andere geplante Aufgabe betroffen ist.
Wenn der automatische Ablauf nicht zuverlässig arbeitet
Gehe bei der Fehlersuche in einer festen Reihenfolge vor. Starte zuerst das Skript manuell im selben Benutzerkonto. Funktioniert es dort nicht, liegt die Ursache nicht an der Uhrzeit der Aufgabe. Prüfe danach, ob winget.exe gefunden wird, ob die Quellen erreichbar sind und ob das einzelne Programm manuell aktualisiert werden kann.
| Beobachtung | Wahrscheinliche Einordnung | Nächster Schritt |
|---|---|---|
| Die Aufgabe startet, aber die Protokolldatei wird nicht erweitert. | Der Pfad zum Skript, das Benutzerkonto oder der Start der PowerShell-Aufgabe stimmt nicht. | Aufgabenverlauf und Aktionsparameter prüfen und das Skript manuell mit demselben Pfad starten. |
| WinGet wird nicht gefunden. | App Installer fehlt, ist nicht verfügbar oder die Aufgabe nutzt eine andere Umgebung. | WinGet im betreffenden Benutzerkonto prüfen und die Bereitstellung reparieren. |
| Ein Paket scheitert regelmäßig. | Der Installer verlangt Eingaben, laufende Programme blockieren Dateien oder Rechte fehlen. | Das Paket einzeln manuell ausführen und die Installationsanforderungen prüfen. |
| Keine Updates werden angezeigt. | Die Programme sind aktuell oder nicht durch die Quelle abgedeckt. | winget list, winget source list und die Hersteller-Updatefunktion vergleichen. |
Wenn ein Paket nach mehreren Versuchen immer wieder abbricht, entferne es nicht automatisch und lösche keine Installationsordner. Eine Reparatur, eine manuelle Aktualisierung oder die Dokumentation des Fehlercodes ist sicherer. Bei Sicherheitssoftware, Treibern, VPN-Programmen oder systemnahen Komponenten solltest du besonders vorsichtig sein, weil ein fehlgeschlagenes Update die Netzwerk- oder Startfunktion beeinflussen kann.
Auf einem Firmen-PC können Richtlinien, Endpoint-Schutz, Softwareverteilung oder interne Paketquellen den Ablauf steuern. Eine lokal angelegte Aufgabe kann dann gegen zentrale Vorgaben verstoßen oder durch die Verwaltung überschrieben werden. In diesem Fall ist die zuständige Administration der richtige Ansprechpartner. Auf einem privaten Rechner endet die Selbsthilfe dort, wo Datenverlust, wiederholte Installationsabbrüche oder ein nicht mehr startendes Programm drohen.
Eine kontrollierte Arbeitsweise für WinGet-Updates
Die Verbindung von WinGet mit der Aufgabenplanung funktioniert am zuverlässigsten, wenn du sie schrittweise aufbaust. Zuerst prüfst du die Verfügbarkeit des Paketmanagers, danach den manuellen Updatebefehl und erst anschließend das Skript. Die Aufgabe selbst sollte zunächst im angemeldeten Benutzerkonto mit eingeschränkten Rechten laufen.
- WinGet mit
winget --versionprüfen. - Mit
winget source listdie Quellen kontrollieren. - Mit
winget upgradedie erkannten Aktualisierungen ansehen. - Den vollständigen Befehl manuell ausführen und die Ausgabe bewerten.
- Das PowerShell-Skript speichern und separat testen.
- Eine Aufgabe mit einem nachvollziehbaren Zeitplan erstellen.
- Den manuellen Start der Aufgabe auslösen und das Protokoll kontrollieren.
- Fehlgeschlagene Pakete einzeln untersuchen, statt den gesamten Ablauf mit zusätzlichen Rechten zu versehen.
So bleibt jederzeit nachvollziehbar, welche Komponente versagt: die Quelle, WinGet, das Skript, die Aufgabenplanung oder der jeweilige Installer. Genau diese Trennung verhindert, dass ein kleiner Fehler durch weitreichende Berechtigungen oder unkontrollierte Änderungen verdeckt wird.
Häufige Fragen zu WinGet und der Aufgabenplanung
Kann WinGet auch Programme aktualisieren, die ohne Administratorrechte installiert wurden?
Das hängt vom jeweiligen Installationskontext und vom verwendeten Installer ab. Starte die Aufgabe zunächst im angemeldeten Benutzerkonto ohne die Option „Mit höchsten Privilegien ausführen“ und prüfe im Protokoll, welche Pakete erfolgreich aktualisiert werden; nur bei konkret benötigten systemweiten Installationen solltest du die Berechtigungen gezielt anpassen.
Warum läuft ein WinGet-Skript manuell, aber nicht über die Aufgabenplanung?
Die Aufgabenplanung verwendet möglicherweise ein anderes Benutzerkonto, einen anderen Startordner oder eine PowerShell-Umgebung, in der WinGet nicht gefunden wird. Verwende im Aufgaben-Dialog den vollständigen Pfad zum PowerShell-Programm, übergib den vollständigen Skriptpfad als Argument und kontrolliere anschließend die im Skript angelegte Protokolldatei.
Wie verhindere ich, dass ein einzelnes problematisches Paket den automatischen Lauf stört?
Teste das betreffende Paket zunächst einzeln mit seiner in WinGet angezeigten ID und dem Parameter –exact. Wenn der Installer Eingaben verlangt oder regelmäßig fehlschlägt, nimm das Paket aus dem unbeaufsichtigten Ablauf heraus und aktualisiere es manuell oder über die Herstellerfunktion.
Kann die geplante WinGet-Aufgabe Programme während der Arbeit schließen?
Ja, das Verhalten wird vom jeweiligen Installationsprogramm bestimmt und lässt sich nicht für jedes Paket einheitlich vorhersagen. Plane den Lauf deshalb außerhalb deiner Arbeitszeit, speichere offene Dokumente und teste vorher manuell, ob ein Programm beendet oder ein Neustart verlangt wird.
Was bedeutet es, wenn winget upgrade keine Aktualisierungen anzeigt?
Dann sind die von WinGet erkannten Pakete entweder aktuell, oder die betreffende Anwendung wird von den konfigurierten Quellen nicht abgedeckt. Vergleiche die Ausgabe von winget list und winget source list mit der Updatefunktion des Herstellers, bevor du die Aufgabenplanung oder das Skript änderst.
Ist eine tägliche WinGet-Aufgabe auf einem Firmen-PC erlaubt?
Nicht unbedingt, denn Unternehmensrichtlinien, Endpoint-Schutz oder zentrale Softwareverteilung können lokale Aufgaben und Paketquellen einschränken. Prüfe vor der Einrichtung die Vorgaben deiner Organisation und wende dich bei verwalteten Geräten an die zuständige Administration, besonders bei systemweiten Installationen.
Wie deaktiviere ich automatische WinGet-Updates, ohne WinGet zu entfernen?
Öffne die Windows-Aufgabenplanung, suche die von dir angelegte Aufgabe anhand ihres eindeutigen Namens und wähle zunächst „Deaktivieren“. Dadurch bleibt das Skript erhalten und du kannst die Aufgabe später wieder aktivieren; löschen solltest du sie nur, wenn du den automatischen Ablauf dauerhaft nicht mehr benötigst.
