Microsoft Update Catalog: Download Any Windows KB (and Why the .msu Says 'Not Applicable')
Download any Windows KB as a .msu from the Microsoft Update Catalog, and fix the "not applicable" error caused by a missing checkpoint update.
- Louis
- 12 min read
- Affiliate Disclosure

Most Windows update problems never touch the Microsoft Update Catalog. But when Windows Update keeps failing on one specific KB, or the machine has no path to Microsoft’s servers at all, the Catalog at catalog.update.microsoft.com is the only official place to get that update as a standalone .msu.
Two things decide whether the download actually helps you:
- Search by KB number, not by the name of the update. The Catalog indexes packages by KB and by product, so title keywords return dozens of near-identical rows.
- If the
.msuopens with “The update is not applicable to your computer”, the file is usually correct. The machine is missing a checkpoint cumulative update that the package expects. Downloading another copy of the same KB, from another mirror, will produce the same message.
The rest of this guide covers both, plus how to confirm the update actually landed.
Updated November 2026 for the checkpoint packaging introduced with Windows 11 24H2 and the current build numbering of versions 24H2, 25H2 and 26H2.
What the Microsoft Update Catalog actually covers
The Catalog is Microsoft’s public distribution point for update packages that are normally pushed by Windows Update and WSUS. What you can get there:
| Included | Notes |
|---|---|
| Cumulative updates (LCU) | Monthly security and preview rollups for Windows 10, Windows 11, Windows Server |
| Servicing stack updates (SSU) | The component that installs other updates — order matters |
| .NET Framework and .NET updates | Separate KBs from the OS rollup, often installed alongside it |
| Driver packages | The ones Microsoft publishes for OEM and enterprise distribution |
| Feature updates and enablement packages | Including the small enablement packages that flip a machine from 25H2 to 26H2 |
| Safe OS Dynamic Updates | Servicing for WinRE, the recovery environment |
| Out-of-band hotfixes | Emergency fixes published between Patch Tuesdays |
What it does not cover: Microsoft Store app updates, Windows Insider preview builds, firmware and OEM component updates that Windows Update offers on its own driver pipeline, and Office Click-to-Run builds. If the thing you are chasing updates itself through the Store, through firmware, or through Office’s own channels, there is no .msu to find.
Search by KB number, not by title
Paste the KB number into the search box in the top-right corner — KB5132061 or just 5132061. Both work; the KB prefix is stripped anyway.

The results page is where most people pick the wrong file.

| Column | What it tells you | How to read it |
|---|---|---|
| Title | Package name, including architecture and language | Windows 11, version 25H2 vs Windows Server 2025 are different files |
| Products | The product and edition list the package targets | Read this before Title — it is the fastest filter |
| Classification | Security Update, Update Rollup, Driver, Feature Pack | A “Driver” row under a KB number is not the monthly rollup |
| Last Updated | Publish date | When several rows share a KB, this and Products are what you compare |
| Version | Internal version of the package | Compare against your own build’s revision |
| Size | Download size | A cumulative update runs to hundreds of MB; a few MB means you grabbed an SSU or a stub |
Select the checkbox for the matching row and click Download. A popup appears with the actual download links, one per .msu file.
For anything released after the 24H2 checkpoint change, that popup lists more than the update you searched for — the earlier checkpoints come along with it. That is not a bug, and it is usually the answer to “why won’t this install”.
The trap: checkpoint cumulative updates
Starting with Windows 11 24H2 (build 26100), Microsoft changed how monthly updates are packaged. Instead of shipping the full payload every month, it publishes a checkpoint — a baseline — every few months, and the monthly LCUs after that contain only the difference from the checkpoint forward.
KB5043080 (September 2024) is the first checkpoint for 24H2. Every later cumulative update for that version assumes it is already present. The package is not a standalone bundle of everything since release; it is a delta with a dependency.
That dependency is why a freshly imaged machine, a restored backup, a VM cloned from old media, or a PC that had updates blocked for a year will reject a cumulative update that looks perfectly correct.
Two different messages come out of this, and mixing them up costs people hours:
- “The update is not applicable to your computer” — the package’s applicability check rejects the current build.
- “Operation is not supported” — documented in KB5044786 for machines that have the checkpoint and an on-demand feature (FoD) or language pack added from local media. Those machines cannot be brought current without a connection to Windows Update or WSUS.
The Catalog already knows about this. Click Download on a checkpoint-era LCU and the popup lists every .msu you need, in order — checkpoints first, target last. Download all of them into one folder, and make sure that folder contains no other .msu file. A stray package in the same directory breaks the sequencing.
Microsoft’s standalone installer documentation adds one shortcut worth knowing: on devices that have KB5060829 or a later update installed, double-clicking the newest .msu is enough. Windows Update Standalone Installer applies the missing checkpoints in the correct order and then the target. On older builds, or when FoD and language packs are involved, that shortcut does not apply — you install each file individually in order, or hand the whole set to DISM.
“The update is not applicable to your computer”
Five causes, ordered roughly by how often they turn out to be the answer.
| # | Cause | How to confirm | What to do |
|---|---|---|---|
| 1 | Missing prerequisite (checkpoint LCU or SSU) | Build revision far below the KB article’s, and no checkpoint in update history | Download all files from the popup, install in order or use DISM |
| 2 | Wrong architecture | Settings → System → About → System type, or echo %PROCESSOR_ARCHITECTURE% | Take the arm64 row for ARM PCs, x64 for Intel/AMD |
| 3 | Wrong Windows version or edition | winver, then the “Applies to” line in the KB article | Match 26100 / 26200 / 26300 exactly |
| 4 | Already installed, or superseded | Get-HotFix -Id KBxxxxxxx, or Settings → Windows Update → Update history | Nothing to install — or install the newer KB instead |
| 5 | Version out of support | winver version and build | See the note below |
Cause 5 is doing a lot of work right now. Windows 11 24H2 Home and Pro stopped receiving updates on 13 October 2026, and 23H2 Enterprise and Education received their last update on 10 November 2026. If you are on either, the November 2026 cumulative update genuinely does not apply to your machine — no amount of redownloading changes that. From 24H2 the way out is one enablement package and a restart, which we covered in what Windows 11 25H2 changes. From 23H2 it is a full feature update, not a manual .msu. Windows 10 users have a third path — updates now require the ESU programme, explained in joining the Windows 10 ESU programme.
Read the error code before you read the fix
The dialog hides a code in its details pane, and the code tells you which of the five rows above you are in.
| Code | Name | Meaning |
|---|---|---|
0x80240017 | WU_E_NOT_APPLICABLE | Windows Update agent rejected the package as not applicable |
0x800f081e | CBS_E_NOT_APPLICABLE | Same verdict, reported by WUSA or DISM |
0x800f081f | CBS_E_SOURCE_MISSING | Different problem. Payload files are missing — usually a trimmed component store. Do not chase prerequisites |
0x80073712 | ERROR_SXS_COMPONENT_STORE_CORRUPT | Component store is damaged — run DISM /Online /Cleanup-Image /RestoreHealth |
0x8007000D | ERROR_INVALID_DATA | Download is truncated or corrupt — re-download, compare file size against the Catalog row |
0x800f081f is the one most guides get wrong. It looks like “not applicable”, it arrives at the same moment, and it sends people hunting for a missing checkpoint that is not the issue. If the payload is missing, DISM cannot stage it no matter how many checkpoints you install.
Install: three ways, pick one
1. Double-click the .msu. This hands the file to Windows Update Standalone Installer (WUSA). Put the target package and every checkpoint the Download popup listed into one folder with no other .msu in it, then double-click the newest file. On machines that already have KB5060829 or later, WUSA applies the missing checkpoints in the right order before the target. On older builds it does not chain them, the target fails its applicability check, and you want DISM instead. Simplest option, and the right default for a single machine that is roughly current.
2. WUSA from a command line. Same engine, same rules, scriptable:
wusa.exe "C:\Packages\Windows11.0-KB5132061-x64.msu" /quiet /norestart
Useful in a batch file that installs a set of updates. It will fail exactly where double-clicking fails — it is not a workaround for a missing prerequisite.
3. DISM. This is the path Microsoft’s own Windows Update troubleshooting guidance points to, and the one that handles checkpoints properly on builds that predate KB5060829:
DISM /Online /Add-Package /PackagePath:"C:\Packages\Windows11.0-KB5132061-x64.msu" /NoRestart
Run it from an elevated Command Prompt or Terminal, with the whole set of files in that same folder. With the target package as the only argument, DISM applies the missing checkpoints in the correct order before the target — the sequencing WUSA only gained later.
| Double-click / WUSA | DISM | |
|---|---|---|
| Chains missing checkpoints on old builds | No | Yes |
Works with .cab packages | No | Yes |
| Needs an elevated prompt | No | Yes |
| Good for | One machine, one file | Sets of files, scripted, or a stubborn build |
Two rules that save trouble regardless of method: do not rename the files — the filename encodes the KB, architecture and hash — and do not put a .cab through double-click. A .cab does nothing useful unless it goes through DISM /Add-Package.
Verify the build after installing
“Rebooted and nothing happened” is the most common false negative. Check the revision number, not just the version name.
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object DisplayVersion, CurrentBuild, UBR
Read the last two together: CurrentBuild 26200 plus UBR 9974 means build 26200.9974. Compare that against the build number in the KB article title.
As of 10 November 2026, KB5132061 moves the three supported versions to:
| Version | Build | Note |
|---|---|---|
| 26H2 | 26300.9974 | Current release |
| 25H2 | 26200.9974 | |
| 24H2 | 26100.9974 | Enterprise and Education only |
Then confirm the package is actually staged:
Get-WindowsPackage -Online |
Where-Object { $_.PackageName -like '*RollupFix*' } |
Select-Object PackageName, PackageState
PackageState matters. Installed means done. InstallPending means the files are in place but the machine has not restarted — and Windows Update history will not show the KB yet, which is why “it isn’t in my history” is usually a reboot question rather than an installation failure.
If Get-HotFix -Id KB5132061 returns nothing while the build revision is already correct, trust the revision. Get-HotFix does not reliably enumerate cumulative updates.
What aka.ms/diag_97275 is (and why it won’t run)
People find this short link in update logs and assume it is a download page for a repair tool. It is not.
aka.ms/diag_* links are diagnostic packages belonging to Windows troubleshooters. Microsoft documents the Windows Update troubleshooter — the component behind these packages — plainly: it addresses devices that stopped scanning for updates, it resets the update scanning process, it runs automatically on affected Windows 10 1903 and 1909 devices, and — the important line — it cannot be run manually.
So there is nothing to download and nothing to double-click. What you can do is check whether it already ran: Settings → System → Troubleshoot → View troubleshooting history, and look for Windows Update troubleshooter — Automatically repair system files and settings.
If you arrived here looking for a .msu, you want the KB number instead. The short link is a dead end by design.
If the KB isn’t in the Catalog at all
| Situation | What is happening | What to do |
|---|---|---|
| Search returns nothing for a valid KB | It has been superseded | Search the newer KB — cumulative updates are cumulative, the latest replaces all previous |
| Only “Driver” rows return | You searched a driver KB | Check Windows Update → Optional updates first; Catalog driver packages are for OEM deployment |
| Nothing for a preview feature | Preview and Insider content | Not distributed through the Catalog; use the Insider channel |
| The number looks short | It is not a real KB | KB numbers are six or seven digits; a short number is a typo |
And a sanity check that resolves a surprising number of cases: read the “Applies to” line in the KB article itself before downloading anything. If your build does not appear there, the Catalog page will happily give you a file that your machine will reject.
FAQ
Can I just download the newest .msu and skip the rest?
Only partly. The newest package is always the right target, but on a machine that never received the checkpoint, it needs the earlier files too. Take the whole set from the Download popup, drop them in one folder with nothing else in it, and let WUSA (on KB5060829 or later) or DISM handle the order.
x64, arm64, x86 — which one do I need?
Check Settings → System → About → System type. ARM laptops (Snapdragon X, some Surface models) need arm64. Everything else mainstream needs x64. Windows 11 has no 32-bit build, so an x86 Windows 11 cumulative update does not exist — if you think you need one, you are probably looking at a Server or Windows 10 row.
It asked me to restart, but the update isn’t in my history. Did it fail?
Probably not. Check PackageState first: InstallPending means it is staged and waiting for a reboot. Verify with the UBR value after restarting; if the revision moved, it installed regardless of what the history list says.
Can we deploy from the Catalog across a fleet? Technically yes, and it is a common emergency workaround. It is not the supported channel for routine patching — use WSUS, Windows Update for Business or Intune, which handle checkpoint sequencing and reporting for you. The Catalog is for one-off recovery: a machine that fell behind, an offline host, an image that needs a specific KB.
For everything else, let Windows Update do its job. The Catalog is a recovery tool, and the reason it exists is precisely that the automatic path sometimes fails on a machine you need working today.
