Winget-AutoUpdate: system-context winget updates on a logon trigger

A daily winget sweep running with system rights

Winget-AutoUpdate, shortened to WAU, exists because the winget client leaves upgrade policy to whoever happens to be sitting at the machine. WAU wraps it in a job that runs at logon with system context, updates what it finds, and raises a toast when an update lands or fails. The buyer here is an administrator or an IT team rolling one setup to many Windows machines, and the packaging says so: the deliverable is `WAU.msi`, an installer that carries prerequisites, not a script to paste into a profile.

winget install Romanitho.Winget-AutoUpdate

That command installs WAU through winget itself in the newest version available, which is the shortest route from a bare Windows image to a machine that patches itself. The same page points at an alternative, WAU Settings GUI, a separate project that installs WAU plus a portable standalone interface for changing every setting. Two contexts matter when scoping the tool. WAU runs with system and with user context, so packages installed at user scope are updated too, and a shortcut for manual runs can be installed beside the automatic one.

Logon triggers, 6 frequency values, two contexts

Logon is the default trigger, which ties every update to a real sign-in rather than to a clock. Frequency is configurable and takes 6 values: `Daily, BiDaily, Weekly, BiWeekly, Monthly or Never`. None of them is a wall-clock time, so on a host nobody signs into, a kiosk or a service box, no update run happens at all, and the README does not document a trigger independent of logon. That single choice decides where WAU fits: fleets with active users rather than unattended servers. Two execution contexts then cover the two package scopes, machine-wide and per user, and each run reports on both. How much you hear about those runs is a separate setting, the notification level, which picks between `Full`, `Success only`, `Errors only` or `None`. On a busy fleet the quiet end of that range is the setting an admin ends up choosing, because one toast per machine per day is noise people learn to dismiss.

Allow and block lists read from files beside the MSI

Which apps WAU touches comes down to 2 plain text files that sit in the same folder as `WAU.msi` at installation time. `excluded_apps.txt` is the blocklist: any app ID written there is left alone, which covers apps you want to keep at one version and apps that already update themselves. `included_apps.txt` inverts that and narrows a run to pre-selected IDs. Both files, and the Mods folder, are copied into the WAU install location, so what executes later is a copy rather than a link to the file you edited on your desktop.

excluded_apps.txt
included_apps.txt
Mozilla.Firefox*

Entries take a wildcard, so one line such as `Mozilla.Firefox*` covers every Firefox channel. Switching to allowlist mode takes `USEWHITELIST=1`, and the installer sets that property by itself when a whitelist is supplied during the run. Both halves of that instruction point at the installer: the file goes beside the MSI, and the MSI writes the flag. The README does not document a way to move an already installed copy into allowlist mode without installing again, so search the docs for the old spelling, not the new one. Naming drift matters here too: the feature is called allowlist and blocklist, the MSI property is still `USEWHITELIST`, and the external-source section still says Black/White List.

LISTPATH sources for lists held outside the machine

`LISTPATH` moves the list off the machine: the source can be a URL, a UNC path, a local directory or Group Policy, and WAU downloads or copies it into its install location. Freshness carries an exception that the documentation writes out. An external copy is taken when it is newer, except that when the web host answers no date or time header for the file, GitHub being the case named, the file is downloaded every time. A path must also end with a directory and never with a file, so a URL pointing straight at a text file is the wrong shape to hand the installer. `MODSPATH` does the same job for mods and drops its payload into a `mods` folder in the install location. Properties on the MSI command line steer both flows.

RUN_WAU=YES
DISABLEWAUAUTOUPDATE=1
USEWHITELIST=1

`RUN_WAU=YES` starts a run right after installation, which matters on a machine that will not see a logon for days. Group Policy detection was reworked along the way: passing GPO as a LISTPATH value is no longer needed, because WAU picks up a policy-defined list automatically as soon as one exists.

Escaping a SAS token when the MSI runs from CMD

A private Azure container needs a SAS token on the LISTPATH URL, and CMD eats it. Documentation shows the plain form, which does not work when PowerShell is called from CMD, followed by the form that does, with a caret in front of every special character, the percent escape included.

-ListPath https://storagesample.blob.core.windows.net/sample-container?v=2023-11-31&sr=b&sig=PLACEHOLDER_FOR_YOUR_AZURE_SAS_TOKEN&sp=rcw
-ListPath https://storagesample.blob.core.windows.net/sample-container^?v=2023-11-31^&sr=b^&sig=PLACEHOLDER_FOR_YOUR_AZURE_SAS_TOKEN^&sp=rcw

The only signal given about the failing line is that it does not work from CMD, which makes a quiet misconfiguration easy to carry into a deployment. The example covers CMD only, so a launch path built on PowerShell, a management agent or a deployment tool has no documented variant to copy, and that gap is worth closing against your own shell before a fleet run.

Notification levels and where the logs land under Intune

Notification level decides how much a user sees, with 4 settings: `Full`, `Success only`, `Errors only` or `None`. Toast text is localizable, because a locale XML config file can replace it, which is how a shop gets its own wording without editing the script. Logs are split by context. Privileged runs write into a logs folder inside the install location, which by default is a Winget-AutoUpdate folder under Program Files, while user runs of `Winget-Install.ps1` write to `%AppData%\Winget-AutoUpdate\Logs`.

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
%AppData%\Winget-AutoUpdate\Logs

When Intune Management Extension is installed, WAU creates a symlink named `WAU-updates.log` in the Intune logs directory, and the Winget-Install deployment path adds `WAU-install.log & WAU-user_%username%.log` there as well. Per-user filenames matter on a shared box, where several accounts each leave a file instead of writing over one another. How long those files are kept is not stated anywhere in the documentation.

Apps with an Unknown version drop out of the run

The sharpest limit is the app winget cannot put a version on. WAU links that case to a winget-cli issue numbered 1255 and chose to stop managing those apps instead of retrying them on every run. The consequence is quiet: an app reporting an Unknown version simply leaves the update cycle, and the documented remedy is to reinstall or update it by hand and see whether a version is detected afterwards. A blocklist you wrote yourself is visible and auditable, an Unknown version is not, so a deployment can quietly cover fewer apps than its author believes it does. The second limit is metered connections. WAU detects a limited link and stops itself, yet that default is documented as applying only to a fresh install, which leaves a machine installed on an unmetered connection with no stated way to change the behaviour later. Turning it off means installing again with `-RunOnMetered`, a full reinstall on hardware you thought was already configured.

Updating WAU itself and the separate GUI add-on

WAU updates itself. Self-update is on by default, pulls a newer version from GitHub, and deliberately leaves your configuration and the excluded apps list alone, so it does not quietly undo a blocklist. `DISABLEWAUAUTOUPDATE=1` at install time switches that off, and a manual update follows the same procedure as a first install. PowerShell sits under `Sources/` in the repository, with `Sources/Winget-AutoUpdate/Winget-Install.ps1` inside it and a `.gitleaks.toml` at the root. The last push was on 2026-09-14, and the newest tagged build is v3.0.0-1 dated 2026-09-09 as a nightly build, with 2.12.0 from 2026-05-11 behind it. An MIT LICENSE file at the root carries no source-disclosure duty into a patched copy, which suits a team that wants to change the PowerShell in house. Against the GUI add-on named earlier, the real difference is the configuration surface: an MSI plus two text files is a smaller thing to support across a fleet than a portable interface, while the engine, the logon trigger and the dual context stay as they are.

Editorial conclusion

Take Winget-AutoUpdate when you run Windows fleets where upgrades must apply as system with nobody sitting at the keyboard, and when you can live inside an installer-centred workflow. Leave it alone on a single personal machine. Verify three things before a rollout: whether the hosts sit on metered links, since the stop-on-metered default covers a fresh install only; whether your app IDs resolve to a known version, because apps winget reports as Unknown are dropped from management; and whether an allowlist exists at install time, because `USEWHITELIST=1` is written by that run.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Romanitho/Winget-AutoUpdate on GitHub