WinUtil: what the script actually changes on a fresh Windows install

The problem WinUtil solves, and who ends up using it

A fresh Windows install is a sequence of small chores. Remove the bundled apps you never asked for. Turn off a handful of telemetry and advertising switches. Install the browsers, editors and runtimes you actually use. Decide what Windows Update is allowed to do. Each step is documented somewhere, and none of them live in the same place. WinUtil collects them into a single PowerShell entry point with a menu, then lets you save the result as a preset so the next machine takes minutes instead of an afternoon. The README frames it plainly: a curated compilation of Windows system tasks, and "Run it fresh on every new Windows install." That sentence describes the intended audience better than any feature list. It is for people who provision Windows machines repeatedly, whether that is a technician imaging a batch of laptops, a developer rebuilding a work VM, or someone who reinstalls Windows every year and is tired of repeating the same removals. It is not aimed at managed fleets, where Group Policy, Intune or a configuration management tool already owns these settings and where an interactive menu is the wrong interface.

How the script is put together: one entry point, four jobs

The repository layout tells you most of the architecture. There is a top-level windev.ps1, a Compile.ps1, and directories named config/, functions/, xaml/, lint/, pester/, scripts/ and tools/. The xaml/ directory is the giveaway: the interface is XAML, loaded by PowerShell, which is why the tool looks like a native window rather than a console wizard. The functions/ directory holds the individual operations, and config/ holds the data those operations read, including the preset.json referenced from the README. Compile.ps1 exists because the distributed form is a single script assembled from those parts. The README's quick start fetches that assembled script over the network and pipes it into Invoke-Expression, so the code you execute is whatever the endpoint returns at that moment, not a file you inspected. That is the core trade-off of the project: a very short path from nothing to a working menu, in exchange for executing remote code with Administrator rights. The four jobs named in the README map to the menu areas: installs, tweaks, config, and Windows updates. The release cadence is frequent, with 26.08.19 on 2026-08-19 following 26.08.04 and 26.07.28, so the assembled script changes often. Frequent releases are good for fixes and bad for reproducibility, since a preset applied in July may touch different registry keys than the same preset in August.

Installing and running WinUtil for the first time

There is no installer. The README's Quick Start requires an Administrator terminal, because the utility makes system-wide changes, and then a single command. The stable branch is the one the README recommends:

irm https://christitus.com/win | iex

If you prefer to see the code before running it, the same content is available from the repository, but the README does not document that path, so treat the one-liner as the supported entry point. There is a development branch at https://christitus.com/windev for testing unreleased changes. To open the terminal, the README gives two routes: right-click Start and choose Windows PowerShell (Admin) or Terminal (Admin), or press the Windows key, type PowerShell or Terminal, then Ctrl + Shift + Enter. When the command completes you should see the WinUtil window with its install, tweak, config and update areas. For unattended use, the README documents presets applied without manual selection:

& ([ScriptBlock]::Create((irm https://christitus.com/win))) -Preset Standard

The three presets are Standard (balanced defaults), Minimal (minimal changes) and Advanced (deep tweaks for power users). The README points at config/preset.json for the exact contents of each, and that file is the thing to read before running the command above on a machine you care about, because the preset name tells you nothing about which registry keys or services it touches.

Where WinUtil is the wrong tool

The most concrete limitation is rollback. The README does not document an undo, a restore point created automatically, or a log of what changed. If a tweak breaks a feature you rely on, you are diagnosing it from memory or from a backup you made yourself. That is a real cost, and it is not mentioned in the Quick Start. The second limitation is auditability. Piping a remote script into iex means the code is not pinned to a version and not signed by anything you verified. The repository does contain sign.bat, so a signing step exists in the project's own workflow, but the README does not describe a signed artifact you can download and check. Third, the interactive menu assumes a person is present. Presets reduce that, but the README documents only three preset names, not a way to express an arbitrary configuration as a file you keep in version control. Fourth, the scope is Windows client. Nothing in the README addresses Server SKUs, domain-joined policy conflicts, or machines where an administrator has deliberately locked down Windows Update. On a managed corporate laptop, running WinUtil is as likely to fight your existing policy as to help. Finally, the README points to a Known Issues page, which is an admission that some operations have edge cases the project tracks separately rather than fixing in place.

WinUtil compared with a scripted debloat approach

The closest alternative in the same category is a debloat script such as Win11Debloat, which people compare against WinUtil in search. The difference is in the interface and the unit of work. WinUtil is a menu with four broad areas and a preset system; you open it, click, and it acts. A debloat script is typically a parameterised script you run with flags, and its scope is narrower: it removes bundled apps and adjusts a defined set of settings rather than also installing programs and managing update behaviour. If your goal is only to strip a fresh Windows 11 install, a focused script is easier to read end to end, because it does one thing. If your goal is the whole first-hour setup, WinUtil covers more ground and the preset is the closest thing to a repeatable recipe. A different alternative is to skip interactive tools entirely and express the same changes as a PowerShell DSC configuration or an unattend.xml answer file. That route is far more work up front and gives you exactly what WinUtil does not: a declarative file, reviewable in a pull request, applied the same way every time. Choose WinUtil when speed matters more than provenance. Choose a declarative route when the machine is long-lived and someone else will inherit it.

Maintenance, releases and the MIT licence

The repository is not archived and the last push was on 2026-08-19, the same day as release 26.08.19. Two earlier releases, 26.08.04 and 26.07.28, show a roughly two-week cadence through that period. For a tool that touches Windows internals, that cadence is the maintenance model: fixes arrive as new releases rather than as patches to a pinned version. The practical consequence is that if you keep a copy of the script for reproducibility, you own it, because the upstream copy keeps moving. The licence is MIT, which is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are preserved. MIT also means there is no warranty, and the README's own warning that the tool performs system-wide changes is the operative risk statement. If you fork it for internal use, MIT does not oblige you to publish your changes, but it also gives you no support commitment from the author. The README mentions a paid faster .NET implementation sold separately, which is a distinct product from the MIT-licensed script and carries its own terms. Nothing here is legal advice; if you redistribute WinUtil inside a company image, read the LICENSE file at the repository root rather than this paragraph.

Editorial conclusion

Adopt WinUtil if you reinstall Windows often and want one menu for program installs, tweaks and update policy, and you are willing to read config/preset.json before trusting a preset. Skip it if you need per-change rollback, a signed installer, or a change log you can audit line by line; the README documents none of those. Verify first that you can open an Administrator terminal, that you know which preset you are applying, and that you have a restore point, because the script states it performs system-wide changes.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes