-
Notifications
You must be signed in to change notification settings - Fork 0
Home
If you've landed here, you're either trying to understand what this tool does, why it exists, or why your IT department deployed it on your machine without a detailed explanation. All three are valid reasons, and this wiki tries to answer all of them - at whatever level of depth you need.
WAU (Winget AutoUpdate) is an open-source tool that automates software updates on Windows machines using Microsoft's winget package manager. It sounds simple. It isn't trivial - and understanding why it exists requires a short journey through how software distribution actually works, why keeping it current matters more than it used to, and why doing it manually at scale is the kind of job that makes grown engineers quietly update their CVs.
This wiki is organized as a progressive narrative. You can read it cover to cover, or jump to the section that matches your current frustration.
There was a time when "if it works, don't touch it" was reasonable IT policy. That time has passed.
The security threat landscape changed substantially when large language models became capable of analyzing vulnerability disclosures and generating working exploit code within hours of a CVE being published. What used to be a window of days or weeks between a patch release and a weaponized exploit in the wild has collapsed. For a growing category of vulnerabilities, that window is now measured in hours - occasionally minutes. The old calculus of "we'll patch in the next maintenance window" carries different risk than it did five years ago.
At the same time, the opposite extreme - chasing every version update the moment it lands - carries its own category of risk. In environments with larger application portfolios, software components depend on each other in ways that are not always documented. A major version update to a runtime, a library, or a framework can silently break applications that haven't been tested against it. The answer is not to update everything immediately and not to update nothing at all. The answer is deliberate, structured automation with appropriate guardrails.
WAU is one of those guardrails.
Before WAU, keeping software current on Windows involved one or more of the following, none of which is entirely satisfactory:
Vendor-bundled updaters - applications like Steam, Chrome, Zoom, or Slack ship their own background update services. These work well in isolation but create a fragmented zoo of independent processes running on every machine, each with different behavior, different scheduling, different logging, and different failure modes. Managing twenty applications means managing twenty separate update mechanisms.
User-initiated prompts - many applications alert the user that an update is available and ask them to click something. This approach optimistically assumes the user understands what they're being asked, has the local administrator rights to proceed, and will not click "Remind me later" for the next eighteen months. In practice, this is how organizations accumulate a long tail of machines running three-year-old versions of PDF readers with known critical vulnerabilities.
Centralized MDM/SCCM-style deployment - enterprise tooling like Microsoft Endpoint Manager, SCCM, or Ivanti can deploy software updates centrally. This works, but it requires that someone has packaged each application, tested each update, and scheduled each deployment. In large organizations, this is the job of dedicated software packaging teams. In smaller ones, it's whoever drew the short straw.
Package managers - Linux distributions solved this problem decades ago. apt, yum, dnf, pacman - the concept of a unified package catalog that handles installation, updates, and removal is not new. macOS has Homebrew. Windows arrived late to this idea. winget is Microsoft's answer, and it's a reasonably good one.
winget upgrade --all works. You can type it, and it will attempt to update everything winget knows about. The problem is that "works on my machine right now" and "works reliably across a fleet of managed endpoints on a schedule with logging and error handling and a way to exclude problematic packages" are very different propositions.
For any organization managing more than a handful of machines, running winget manually is not a process - it's a chore. Automating it properly requires scripting the invocation, handling execution contexts (does this app run as SYSTEM or as the logged-in user?), managing a list of applications to include or exclude, scheduling that script to run reliably, capturing output for audit purposes, and notifying users when something happens. That's not a one-liner. That's a project.
That project is WAU.
WAU is a structured wrapper around winget upgrade that turns the above list of requirements into a deployable MSI with documented parameters. At its core it:
- runs on a configurable schedule (daily, at logon, or both)
- executes in both system and user context, so applications installed by the user rather than by an administrator are also covered
- supports an allow list (only update these applications) or a block list (update everything except these)
- integrates with Group Policy and Intune via ADMX templates for enterprise management
- produces structured logs in locations compatible with Intune Management Extension
- supports mods - per-application pre/post scripts for cases where winget alone isn't sufficient
- notifies connected users of update activity without requiring them to do anything It does not replace enterprise software packaging for complex deployments. It handles the long tail - the category of applications that are self-contained, low-risk, and simply need to stay current. Freeing packaging teams from routine small-update work so they can focus on the things that actually need attention is, in practice, where most of the value lives.
| I want to understand... | Go to |
|---|---|
| How software installation actually works on Windows | Software Distribution 101 |
| The security case for timely updates | The Update Imperative |
| How WAU compares to other approaches | The Landscape of Update Approaches |
| What winget is and how it works | Why Winget Is Different |
| Why manual approaches don't scale | The Manual Scaling Problem |
| How to install and configure WAU | WAU - What It Does and How |
Page 1 - Software Distribution 101 Cover: installer formats (MSI, MSIX, EXE, portable), machine vs. user context and why it matters, registry implications, UAC, the difference between "installed for all users" and "installed for current user." Audience: non-specialists. Keep it conceptual, avoid registry paths as the first thing a reader sees.
Page 2 - The Update Imperative Cover: CVE lifecycle, the narrowing exploit window, the role of AI-assisted vulnerability research (without hyperbole), patch Tuesday rhythm, stability risk from uncontrolled updates, the concept of a tested update pipeline. Reference real CVE classes (browser engines, PDF readers, archiving tools) as examples of high-frequency, low-complexity targets.
Page 3 - The Landscape of Update Approaches
Cover: vendor updaters (fragmentation problem), user-prompted updates (human reliability problem), MDM/SCCM (packaging overhead), package managers on Linux (apt/dnf) and macOS (Homebrew), chocolatey as Windows predecessor context. Neutral tone - each approach has legitimate uses. WAU is not mentioned here as a conclusion; save that for the Home page narrative.
Page 4 - Why Winget Is Different Cover: the winget catalog, package ID system, install/upgrade/uninstall/list commands, source configuration, version pinning, known limitations (version detection failures on some apps). This page should be genuinely useful as a standalone winget reference for someone who has never used it.
Page 5 - The Manual Scaling Problem Cover: what "scripting winget" actually entails, execution context problems, scheduling, logging, error handling, the fleet management dimension, the organisational cost argument (packaging team hours, ticket volume from outdated-software CVEs). This is the page that earns WAU its existence in the eyes of someone who already knows PowerShell.
Page 6 - WAU Architecture and Configuration Cover: component overview, installation (MSI parameters), allow/block list mechanics, system vs. user context execution, scheduling options, notification levels, GPO/Intune ADMX integration, mods system (global and per-app), logging paths, WAU self-update behavior, known limitations. This is the reference page. It can and should be the longest.