They should be ignored, but if you have any problem you could just delete the contents of "\Windows\SoftwareDistribution\Download" (you'll lose your update history) which should fix it.
Good question. I previously mentioned that Wub is stupid in that it doesn't wait to finish enabling or disabling wuauserv before the next command runs in the script, and I have to include a 2 second timeout after each time wub runs to let it finish before going on to the next command. Those 2 second timeouts add up. In one place in the script I need a 3 second timeout after wub. And since I only enable and disable the windows update service with wub 1.0 in the script, there is no advantage to using v1.1 since all it offers over v1.0 is the ability to disable more services which I don't want. I could have included a special wub.ini with v1.1 to make it act just like v1.0, but there was no point in doing that and I was concerned that people would think it's a good idea to block services with v1.1 by adding services to disable in wub.ini and possibly breaking stuff. It just wasn't worth it. However, with v1.2 I can use the /wait switch to allow the exact time needed for wub to finish disabling and enabling wuauserv without using timeout hacks, which is the same slight speed improvement I got by switching from PowerRun to NSudo 6.1. (PowerRun is stupid too in that it doesn't wait to complete it's operations which requires added timeouts, and NSudo does wait the exact amount of time needed with no timeouts). So that way, wub only waits exactly as long as it takes to disable/enable wuauserv instead of screwing around with timeouts that are too long just to be on the safe side. Sure, somebody could add services to disable in wub.ini in v1.2, and if they do that's on them and will void their money back guarantee, but now there's a compelling reason to use something other than v1.0: the /wait switch in v1.2. I can make v1.2 act just like v1.0, plus I can disable manipulating the noautoupdate registry value that doesn't work, requiring slightly less time for wub to finish operations, plus remove the timeouts. So to sum it up, the advantages of v1.2 over 1.0 are too many to not use it, while v1.1 is not worth it at all. I hope this long-winded explanation made sense.
Yeah, good explanation and justification. Maybe making wub.ini read only, or using some other method, might lock it down for the script purposes (similar to WuMgr options being locked)?
Making the script create/overwrite wub.ini every time the script is run before wub runs would prevent anybody from altering wub.ini.
Correct. Anybody who wants to run WUB separately can easily and simply put WUB into a different folder to run it independently with whatever options they want. (I would expect you'd advise against doing that anyway, as before, because of the various options that a user might add to the .ini that your script wouldn't have control over to reverse, otherwise opening Pandora's box to issues that the script may be blamed for.) Here's a WUB feature request you might be able to influence, since you have Sordum's ear: Ask them to incorporate the option to minimize to the notification area with status icon! Maybe they could do it in v1.2 along with the /wait option. You could then use that feature with the script to indicate the script is in use. Unless I'm mistaken, there is no immediate sure-fire way to know if the script is running or not without the user taking action to do something. If WUB could show that the update service was disabled in the tray/notification area, that would take the place of alternatives such as ServiceTray, Windows Service Monitor, or having WUB sitting on the taskbar. I asked Sordum to make WUB minimize to tray a long time ago in a comment post but got no feedback. (Edit: And such a feature would certainly enhance the quality and effectiveness of WUB as a standalone utility for Sordum.)
Hi, Just downloaded and init v2.5.5 (portable) by running WUMTWrapperScript.cmd. Questions: 1. The only way to get to the Configurator to perform any updates (eg. Microsoft Store, Windows Updates) is to fire WUMTWrapperScript.cmd again? 2. Is it not possible to access the Configurator directly without re-initing the whole script again? Much appreciated.
@stderr You can run wub.exe in the wrapper script folder to enable the windows update service to use the store and do updates. That'll bypass the configurator.
@pf100 So basically after initing the script, now I can: 1. Run wub.exe to enable WU Service and leave it open 2. Perform updates via Microsoft Store or firing the included WuMgr.exe 3. Disable WU Service via the running wub.exe 4. Close everything 5. Reboot computer if needed 6. And I will still enjoy the same protection offered by your script? Did I get it right?
@stderr that's correct. And if you need to reboot after an update you don't have to run wub.exe again to disable the windows update service (steps "3" and "4" in your list). The task created by the script, Wub_task, automatically disables the windows update service when you reboot or logoff and log back in, and rebooting closes everything cleanly so no need to do "4". But if you don't reboot, you still need to do "3" and "4".
Downloaded version 2.5.5, installed and it functions perfectly. Thank you for one slick solution! Question regarding Windows Defender definition updates though. I'm retired and typically the laptop only runs for a couple of hours or so each morning (time it takes for two or more cups of coffee and to catch up on what got screwed up in the world while I was asleep). So, with the Defender updates being triggered only once every six hours, is there a chance that I may not receive any of those updates for weeks on end as the laptop never approaches that amount of time being on?
The Windows Defender Update task (WDU), is set to "run task as soon as possible after a scheduled start is missed", so yes, it updates defender after a missed update. Having said that, I leave my computers on most of the time and don't just turn them on every once in a while like you do. Give it a day and let me know if there are any problems with Defender updating and I'll work with you on a fix. If there is a problem you can run the task manually, and keep in mind the task delays updating Defender for 5 minutes (in case of a missed run after boot/reboot so it doesn't suck all your resources). But so far I haven't gotten any reports of missed updates and I'm pretty sure someone would have pointed that out to me by now. But like I said, let me know if there's a problem and I'll fix it. Thanks.
you installed ~100 updates at once? i would expect errors doing so... defender issues spread by ms appear from time 2 time.. i would (i always do) kill defender off the system, the firewall and securityhealthservice, thanks 2 nsudo, also. hint: takeown and sdelete "defenderapplicationguard.wim"'s from windows\containers folder which winblows 1809 is brewing since RTM!
If "app_raiser" is referring to my post (and images) above, then no. The 123 updates are over months and months. At least since the last Win 10 1809 from MS. Windows Updates are down in certain areas all over, and not just the US. The thread at TenForums regarding this is growing by the hour.