Win_ISO_Patching_Scripts: building a patched Windows installation ISO

The workflow is one file, one command

The README describes the entire operating procedure in one line, and it is worth quoting because it says exactly what the tool does and where it gets its data:

##### Usage: Put the Windows image (ISO format) in the root directory of the folder. Run Start.cmd to start downloading the latest patches and start creating an ISO with the integrated patches. The download address of the patch file is from Microsoft.

So the workflow is: put a Windows installation ISO in the root of the folder, run Start.cmd, and the script downloads the current patches from Microsoft's own distribution points and produces a new ISO with those patches integrated into the image.

That last point is the distinction that matters. Windows ISO images go stale. A base image captured months ago does not contain the updates that have shipped since, and every machine deployed from it starts by downloading them. For an internal deployment pipeline, integrating the patches into the image means the installer applies them rather than the machine, which changes both the time taken to provision a machine and the number of moving parts on the network at install time.

The scripts themselves are Batchfile and PowerShell, with the primary language recorded as Batchfile. The repository also ships a Chinese readme alongside the English one, which is a reasonable signal about the audience for this kind of tooling.

The supported version table is the documentation

For a tool that rewrites operating system images, the list of what it supports is the first thing an evaluator should read, and the README keeps it current. The table is dated, with the internal versions given as last updated on October 16, 2026.

Windows 10 Enterprise LTSB 2016 and Windows Server 2016 are at Build 14393.9612. Windows 10 Enterprise LTSC 2019 and Windows Server 2019 are at Build 17763.9376, with a note that this is the 2024-6 build and that the Arm version has reached end of life. Windows 10 22H2 and Windows 10 Enterprise LTSC 2021 are at Build 1904x.7807. Windows Server 2022 is at Build 20348.5761.

On the newer side, Windows 11 23H2 is at Build 22631.7652 and Windows Server 2025 at Build 26100.33650. Windows 11 26H1 is at Build 28000.3231, with the parenthetical that the x64 version is not recommended. Windows 11 26H2 and Windows 11 Enterprise LTSC 2024 are at Build 26300.9711.

Two of those annotations deserve attention. The Arm end-of-life note on the 2019 LTSC line means the scripts can still target it but the hardware is going away. And the recommendation against the x64 build of 26H1 is the kind of caveat that is usually the result of a specific problem someone hit, so it is worth reading the issue tracker before choosing that line.

The list also spans the whole range from a 2016 image to a 2026 one, which tells you the project tracks the long tail of enterprise builds rather than only the newest consumer release. That matters for anyone still deploying Server 2016.

W10UI.ini is where you decide what the image contains

The behaviour switches live in W10UI.ini in the root directory of the folder, and the README documents each one with its default value and what happens when you change it.

Net35 defaults to 1, and setting it to 0 skips integrating .NET 3.5. wim2esd defaults to 1 and generates an install.esd file instead of install.wim to reduce space usage, and the README is explicit that this process consumes a lot of time and computer resources while the image size is reduced by about 25 percent. Setting it to 0 skips that step.

AutoStart defaults to 1, which means that for multi-version images the script downloads and integrates all the images by default and starts automatically. Setting it to 0 lets you select a specific version, for example generating an integrated update image for the Professional edition only, and the README explains the interaction: after the script is run you press 8 to select the version, you can select multiple versions, and after selecting you press 0 to start.

Then a group of switches that default to 0 and turn a behaviour off when set to 1: nosuggapp disables the installation of third-party apps after a new installation of Windows, nosuggtip disables the suggestion tips and functions, norestorage disables the reserved storage space usage, nogamebar disables the Game Bar, and oobebypass disables online accounts and enables local account creation.

Two of those are worth a second look. Disabling the suggestion of third-party apps changes the out-of-box experience of every machine you deploy, and bypassing online accounts to allow local account creation is a provisioning decision that may interact with your directory setup.

One option is explicitly temporary. ltscfix defaults to 1 and repairs the library files for LTSC 2021 and 2024, with the note that this option will be removed after the official patch is released. netfx481 defaults to 1 and controls support for .NET Framework 4.8.1.

The toolchain it borrows, and who maintains it

The README closes with a credits table listing the tools the scripts depend on and where they come from, which is the fastest way to understand what this repository actually is: an orchestration layer over existing tools rather than a from-scratch implementation.

7-zip handles the archive work. wimlib from wimlib.net handles the Windows Imaging Format manipulation, which is the format Windows installation images are stored in and the part that requires careful handling. aria2 is the downloader, which explains how the patch downloads from Microsoft are handled, and oscdimg from Microsoft produces the final ISO. PSFExtractor handles the servicing stack files that the patches need.

And then W10UI, credited to the BatUtil repository by abbodi1406, which is where the W10UI.ini settings and the W10UI.cmd entry point in this repository come from. W10UI is the tool that edits the contents of a Windows image, and this project wraps it with the patch downloading, the multi-version selection and the ISO creation.

That division of labour is worth understanding, because it explains the shape of the repository. The top-level entries are Start.cmd as the entry point, W10UI.cmd, W10UI.ini for the settings, W10UI-ReadMe.txt for the upstream documentation, Update-Meta4.ps1, a Scripts directory, a bin directory for the bundled executables, and the two readmes with their.gitattributes,.gitignore,.github and LICENSE files.

So when something behaves unexpectedly, the question is whether the fault is in the orchestration here or in one of the upstream tools, and the credits table tells you where to look.

Version names carry a year, a month and a letter

The release naming is unusual and quite informative. The recent versions are v2026.10b from 2026-10-13, v2026.9d_26h2 from 2026-09-30 and v2026.9d from 2026-09-22.

The pattern is a year, a month and a letter, so v2026.10b is the second build of October 2026, and v2026.9d is the fourth build of September 2026. The suffix on the middle one, _26h2, is not a build letter but a note about which Windows release it targets, which tells you that the same script set can be pointed at different Windows versions and that the tag records which one it was tested against.

That is a sensible scheme for this kind of project, where a build might be re-issued for a configuration change without any change to the patches themselves, and where the reader needs to know at a glance whether a given build predates or postdates a particular Windows release.

The licence is MIT and the repository is not archived, with the last push on 2026-10-16, which is the same date the supported version table records as its last update. The default branch is master, the primary language is Batchfile, and there is no homepage beyond the repository itself.

With monthly builds across several Windows versions, the practical consequence for an adopter is that the tool is versioned by Windows target rather than by feature, so the upgrade question is usually which Windows build you want to ship, not whether a new version of the script does anything new.

What this produces, and what it does not

It helps to be clear about the boundary, because the word patching can suggest more than is intended.

The output is a Windows installation ISO, rebuilt by these scripts with Microsoft's own patches integrated and with the features you turned off in W10UI.ini actually turned off. The patch data comes from Microsoft. Nothing in the README describes replacing licensing, bypassing activation or supplying media that the ISO did not already contain.

That still leaves real operational questions, and the README does not answer all of them. It does not say whether the resulting image carries the original digital signature or how a rebuilt image affects one, and it does not describe how to validate the produced ISO. For a deployment pipeline, that matters, because an image that has been rebuilt is not the same artefact Microsoft signed, and the machine imaging tools, update agents and servicing stack inside it will all see a modified image.

It also assumes a particular environment. The scripts are batch files and PowerShell running on Windows, creating an ISO with oscdimg, which means the tooling has to be on the machine doing the build rather than in a Linux CI container. The wim2esd step is the one the README flags as slow and resource-hungry, so a first run on a large multi-version image will take a while.

The last practical point is that several defaults are opinionated. A built image will have .NET 3.5 and .NET Framework 4.8.1 integrated, and the suggestion of third-party apps will still be enabled unless you set nosuggapp to 1. Anyone building images for other people's machines should read the ini table before running it rather than after.

Editorial conclusion

Win_ISO_Patching_Scripts fits a deployment engineer who ships Windows images internally and wants offline installers that already contain the current patches rather than a base image plus a patching step on every machine. It is the wrong choice if you need a signed, vendor-supported image, since what it produces is a repackaged image built by these scripts, and the wrong choice if your workflow already integrates updates another way. Verify first that your target Windows version appears in the supported table with a build you intend to use, that you can run the script with the privileges ISO creation needs on Windows, and which of the W10UI.ini switches you actually want, because several of them default to on and change what the installed system offers.

Frequently asked questions

Official sources

1. adavak/Win_ISO_Patching_Scripts on GitHub
2. Issues
3. License: MIT
4. README
5. Releases