Getting KB4458469 Installed When Windows Update Offer Absent
Yesterday, September 20, MS issued yet another Cumulative Update for Windows 10. Why do I call it that, listed only as “Update” in Update History? The Win10 Build number changes from 17134.286 to 17135.319 post-install. By definition, any update that ups the Build designation counts as a cumulative update. And in fact, if you check its Release Notes you’ll see it fixes a boatload of gotchas, minor and major, in the current-for-not-too-much longer version of Windows 10. But although my systems already had the Servicing Stack update (KB4456655) installed – a necessary pre-req for KB4458469 – WU didn’t offer it to any of the four PCs I have currently running 17134.286. That’s why I dug into the topic of getting KB4458469 installed when Windows Update offer absent this morning.
Although I had the servicing stack update installed, WU didn’t offer KB4458469 automatically.
Getting KB4458469 Installed When Windows Update Offer Absent Requires Manual Update
When WU doesn’t offer updates automatically, there’s always the Microsoft Update Catalog. As you can see (visiting the preceding link), it offers various versions of KB458469 for download. I grabbed x64 version for my systems, then ran the self-installing update file (.msu) to add it to my runtime image. Given the number of fixes it provides, this took a while to complete, as I’d more or less expected it to.
When DISM analyzed the component store afterward, it found a whopping six (6!) reclaimable packages in need of clean-up. That took a while, too. But it dropped the size of the component store from 8.10GB reported/7.64GB on-disk size to 6.90GB reported/6.74GB on disk. This makes post-install clean-up a bit more urgent than usual, IMO. For detailed instructions on component store cleanup, check this TenForums tutorial: Clean Up Component Store (WinSxS folder) in Windows 10.
Another Take on Post-KB4458469 Cleanup
The preceding numbers are from my Lenovo T520 laptop. On my i7-6700 Asrock Extreme7+ mobo production PC, they were a bit more dramatic. After installing the update manually there, things read: 9.26 GB reported/8.75GB on disk before DISM cleanup. Afterward, they dropped to 6.66GB reported/6.50GB on disk. That’s a pretty substantial space drop (2.6GB reported, 2.25GB on disk)! But I left the /startcomponentcleanup command running for over an hour before I got tired of waiting for it to complete. So I struck the Ctrl-C sequence to end the processing. Instead: the command line reported 100%, and then I ran /analyzecomponentstore again to get the “after” numbers. Weird!