well whatever those changes are, they work perfectly. it looks like there are some changes which haven't been spotted. i request @BALTAGY to provide codes so the best method to disable updates can be integrated into wumgr to achieve fully manual windows updates.
Yea that's a start, its kind of what you can select as an admin on a WSUS Server. But I think we can improve on that. What annoys me a lot with windows updates is that when i boot some older VM or a PC that stood in the corner for a year or two, the first Thing it does when getting access to the internet is searching for updates what is quite CPU/HDD intensive (for win 7 at least it seams on 10 it does faster as there are not so many patches, yet) such that you if its a slower machine often cant properly use it. Windows's way is if a scheduled check for update have been missed to do it at the next possible opportunity. We should make it more user friendly, I'm thinking to make the tool start an update check only when there was no user input for 30 or 60 min or longer. (this value would need to be shorter than the default time to go to standby so in the end probably 20 minutes instead of an hour, or may be we can read the value form the registry and always pick 15 min less) This way the PC wont do anything CPU intensive while its needed. When the PC couldn't do a check for a given Periode of time it would ask the user if it can do a check while the PC is in use. And there is the problem of unwanted reboots, I haven't looked into which component is causing the reboots, is it wuauserv itself or one of the other once that were introduced in win 10. Also I would need to know if windows as is would nag for, or force, a reboot when an update which needs a reboot was installed using the tool instead of windows automatic update. Will have to test that unless someone shares the answer here a) If windows will want a Reboot its own that is no good, than we will need to only notify the user about the availability of an update that requiriere a reboot and only install the update when the user consented to a reboot. b) If we can install the update and than just ask the user ourselves for a reboot that would be better as the procedure for the user would be faster. On the down side when the user wants to quickly reboot for whatever reasons such an already "half" installed update would make the reboot take longer than needed. So we should have an option to choose between variants a (if possible) and b. What I'm also not sure about is he ideal interval to check or updates, as the offline option requiriere to re download a 300MB file each time. Well I think a solution in the end would be an online service that is vetting every update and making an educated Rekommandation which the clients than follow. Actually that is a quite workable idea, I think I should write this patchLady if she would be interested in doing that. About the check for updates interval, if we get a vetting service than we could use it to determine if there are even any new updates to begin with and only do a check for updates when we know we may find something.
I never saw any of the "upgrade facilitators" updates classified as Security Update e.g. KB4023057, KB4023814, KB4033631 it's true that latest Cumulative Updates include \Windows\UpdateAssistantV2\Windows10Upgrade.exe but afaik, that's only used during OOBE phase only although, WaaSMedic (or KB4023057) may launch it, but i didn't check that lately
It's possible I could be wrong, and I don't keep a list of which are the "bad" KB's, but I could have sworn I've seen upgrade facilitators included in security updates before. I only deal with the aftermath of them. I wish I'd kept notes.
That may be my mistake. On reinspection, I see that, rather than being in the "Security Update" category, KB4023057 (just issued anew), KB4023814, and KB4295110 are in the "Critical Update" category, but they each say in their description: "A security issue has been identified in a Microsoft product that could affect your system." So they are misleading at best. KB4295110 is reported to have "new stability improvements for the update components."
Some feedback… I have been using WUMT for years, and am making the switch to WuMgr and see many improvements to date v0.5… I would like you to please consider the following: As updates are being installed, it would be nice to have the Main window refreshed to remove them from the download / install list as each one is installed… After all the selected updates have been installed, then perform another search to refresh the Main window with current Windows / Microsoft Update status…
Having a minor problem with (version 0.4b and earlier) application display running under Win 8.1 on two different PCs. The interior 'Updates' listing window and the console window on the right hand side of the main window are very small. Problem does not happen with Win 10 (1511, 1703 or 1709). The main app window size is fine. I have .net 4.7.2, 3.5 SP1, 3.0 SP2 and 2.0 SP2 installed on both machines with up-to-date .net patches.
Can you please make a few screenshots? On a quick try I couldn't reproduce the issue on my surface running win 8.1 Cheers David X.
That's probably why I'm remembering security updates as including update "facilitators", the "Critical Updates" being presented as security updates. I just wanted to make sure we're all on the same page here as far as update classifications. Thanks for the info.
