Well, the August updates are here, and even with the update service off and before any updates are installed, hidden updates have become unhidden. WUMT shows 1803 feature update available again! I think the WUMT Wrapper Script is working well to fend off MS's advances. But does anyone know how hidden updates become unhidden? Apparently, WUMT uses the MS WU process to hide updates, and that process has some time limit before automatically exposing selected updates. Where I did have 3 updates hidden, I now only have 1.
clearing the Windows\SoftwareDistribution folder most of the time unhides the updates and some updates like KB4023057 have newer revisions, meaning a newer version of that update becomes available & unhidden
Thanks, good explanation. Why, wouldn't clearing the SoftwareDistribution folder unhide all updates, though? (For example, KB4056254 stayed hidden, while 1803 and KB4023057 were exposed.)
Yeah, I understand from numerous forums that KB4023057 continues to get reincarnated, so I can see how it could get a new signature that Windows Update (and WUMT) would see as a new update, different from the hidden update. I think that update is included in the category pf100 referred to as update hijackers. I've got to admit that, as long as I've used Windows 10 Pro, I haven't used any of the Store apps, nor have I accessed the Apps & features list. Instead, being a fan, too, of Windows 7, I've ignored the Start screen in Win 8.1 and Win 10 by basically living in the Win 7 UI with StartIsBack from the get go. I also went straight to O&O Shutup 10 to block telemetry and other nuisances. When it's under control, I've found Win 8.1 to have substantive improvements over Win 7 (when using StartIsBack), and Win 10 to have substantive improvements over Win 8.1. All using StartIsBack for the interface. The problem arises when an update cuts the knees off an otherwise perfectly good computer, forcing the user to take, for example, such an arcane step of renaming the pcmcia.sys driver to stop a ridiculous issue of double entries in Device Manager and no network access, or to figure out other remedies for a new update-induced malfunction. MS update policy is the forced obsolescence of other people's equipment. That bulldozer approach needs to be suspended on a case-by-case basis, and the Wrapper Script lets us do that.
The paradigm has shifted. Open source "Windows Update Manager" replacement for WUMT has been created by @DavidXanatos. It's not finished yet, but it looks very promising. I hope it works well so I can switch to "wumgr" instead of WUMT. So instead of waiting for an update for WUMT which looks like it'll never happen, we can have an open source replacement than can be updated by the author and/or community since the source code will be included.
I edited my post to say wumgr. Thanks for the correction, although I was hoping it was WUM so I'd only have to remove the "T" from WUMT in the name of the wrapper script.
Please keep in mind the new tool also fails like WUMT when in newer builds the CU/SSU is delivered via UUP . In a test on 1803 it showed KB4343909 with 58,9 GB like WUMT does.
Thanks for the info. I have high hopes that the author and the MDL community can fix the UUP problem. Just yesterday the thought occured to me to open WUMT and Update in Settings in the wrapper script at the same time set to check for updates. But that's a little messy and still doesn't solve the problem of uninstallable updates through Settings. If enough gurus pitch in to the development of wumgr, I believe most of these problems can be overcome. Edit: I almost forgot. I can start the same or similar update check the same as the settings app alongside WUMT by using: Code: PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() I haven't tried it yet, and I may need to edit the command to edit "AutoUpdate" I just want to check for updates, not automatically install them. I need to test this. In case you're wondering, Code: wuauclt /resetauthorization /detectnow to check for updates doesn't work anymore. I only mention all this because I've noticed that if I run WUMT in the script and Settings > Update at the same time I get better results than WUMT alone. WUMT alone sometimes won't show an available update when the settings app will. And when the Settings app finds the update, it'll show up in WUMT. So to sum it all up, I may get better results with running the powershell command immediately before I start WUMT in the wrapper script.
Not yet. Only when wumgr works better than WUMT. THEN it's the final cut. What's standing in the way right now is the UUP Problem but he's working on it.