It will not shorten in case of web request (which in case of WU can last annoyingly long) but will speed up the command processing in general, very noticeable on slower machines like my C2Duo notebook or in a 2-Core 4 GB VM.
August 21, 2018 WUMT Wrapper Script 2.5.1 Fixed problem with WUMT taking a long time to open. Thanks @Wolfzz and @nghiabros for the reports.
WUMT Wrapper Script 2.5.1 Works perfectly thanks for the great work. Just one question do I do anything with the settings below Update Service: once I run the Script or just leave them as they are at Default.
1) If you leave it at default (disabled), the update service will stay off permanently except for when you're checking for updates and the script handles that automatically. Then after you update and close WUMT or reboot with WUMT the update service is automatically disabled again. So you don't have to enable it to do windows updates with the script. 2) If you set it to enabled, it'll stay enabled permanently (leaving update hijackers disabled) until you change it back to disabled. This is useful if you want to, a) temporarily allow the update service to use the Store or update Store Apps, and then change it back to disabled, or b) leave the update service running always so you can use the Store at any time at the risk of possible forced updates. So, yes, you can just leave it at default (disabled). I'll try to make it more clear in the next version of the script what these options do.
hey. i guess the question implies.. what happens if i change any setting via the update orchestrator ui (immersive control panel) while script is active?!! indeed this is a good question i think.. my answer as a user of the script for 6 month now would be: nothing, until i stop using the script (uninstall) rather i would disable the update orchestrator service too, so the immersive control panel crashes if i mistakenly got the idea to push some buttons to face rempl once more.. it's no longer possible to open the update settings ui, the window crashes every time before a button could be pushed ;-) generally i keep these section of immersive control panel at distance
Thanks @pf100 for the nice update So, if my application need .NET Framework 3.5, must I download it from microsoft.com via web browser? When I need run DISM command, how to do that?
1) Enable windows update with the script. 2) Install .net or run dism as you would normally. 3) Disable windows update with the script.
Pf100, if l may jump in for a minute, it looks like we might be talking about three different but related things: I think Wolfzz's question is about the settings in WUMT under "Update Service" near bottom left while the script is running, and you have already recommended no changes to those settings in your written guidance. Your reply to Wolfzz seems to address the actual initial script interface options (E,C,X) and the default being disabled. app_raiser's comment appears to address the native Windows Update in Settings at the time the script is running (or perhaps as long as it's installed). I think part of the overall curiosity is general uncertainty by some (that would include me) of WUMT's supreme control over the Windows Update Service while it's running. In other words, why does or why would the native Windows Update in Settings take a back seat to WUMT? pf100, you've been doing amazing work that should be appreciated by the majority of Windows 10 users. Your script, with WUMT -- and hopefully even better with wumgr -- provides a gatekeeper for users' machines to regulate Microsoft's firehose of automatic updates. (MS mistakenly believes those machines belong to them because of their Windows as a service concept.) I don't believe you have an FAQ list, but I think you've definitely got a full plate. If you think it would be appropriate, I'd be glad to provide a starter list of questions that could be added to. The problem is that I would have answers for few of them. Nevertheless, FAQs would benefit all of us. @pf100, to clarify, you've got a tremendous amount of good documentation about how it works, how to install, etc. in your first post and with your script distribution and execution. It's just that it can be helpful to have an easy-to-scan list of Q&As that people might most often want to understand.
@Whistler4, thanks for clearing that up. A FAQ is a good idea and any help with that would be great. It's harder for me to come up with questions for a FAQ when I already know how everything about the script works.
i write / improve some cmd's for work right now, and one more question came up. Win7 SP1: KB2952664 Win8.1: KB2976978 Win10: KB4033631 these are the three windows analytics updates, with the first one i deal almost every day (and night). i remember your words @pf100 about calibers in what someone does / should do, adressing windows updates very well. with the new "sihost.exe issue" in windows 10, everybody can see that microsoft is a "hard" enemy.. so i learned to erase the w7 update effectively even when w7 is in a "late state" and keep the machine stable, protected against winblows update. ;-) searching for updates with WUMT, i remember some cases i saw KB4033631 offered to a windows 10 machine at least (physical and VM). in other cases it was not offered although expected.. so i would like to know, do you adress this KB?! i don't know if in windows 10, when this update is installed once, there are steps to revert or not - or if it is updated hidden and automaticly in any way. what i do know is, hidden or "lost" update history IS a problem in windows 10 for a long time. greetings!
KB4033631 is an information gathering update that reports that windows is ready to be upgraded to a newer version, basically. And yes, without the script it would start the update hijackers installing. It may also have something to do with reporting what version your hardware is capable up upgrading to. I'm not blocking any of that because it can't install anything unless you let it with the script. It's not a problem and I wouldn't worry about it. If I weren't using the script, then I'd be worried about it..
@Lars220 When I first included an installer with the script I picked an avatar that represented the aggressiveness of the script. But yeah, I should change it. Adding the script version to the installer's "finished page" would be good if I didn't have to jump through hoops to do it. So if anyone knows how to do this with Inno Setup, I'll add it. I hate Pascal Script. Your wording for continuing the script is much better than mine, so it'll be in the next version.
Thanks @s1ave77. Yes, that would be a lot easier. I'm just going to leave this here so I don't have to look it up again later. Code: [Messages] // define wizard title and tray status msg // both are normally defined in innosetup's default.isl (install folder) SetupAppTitle = Setup YourApplicationShortName SetupWindowTitle = Setup - YourApplicationName YourApplicationVersion This will modify the "title bar" and the "app title" in the tray.
May I suggest, while the subject is being thought about, that instead of "E(x)it" X to exit, you make it "Any other key to exit." As it is, both "Enable" and "Exit" start with "E", and someone might be too quick on the draw and tap "E" for exit. (I might have been sleepy .) Not being proficient at writing script, I don't know if "E, C, or Any other key" is doable. I am, however, a good foolproof tester.
@Whistler4, how about "Q" for quit or something? What you propose would require rewriting parts of the Configurator. The Configurator used to be a separate script and getting it to work correctly inside the wrapper script was really, really hard. So I don't want to touch the code in that part of the script other than to change the text or the key you can press to do something. How about: [E]nable Update Service to allow Windows Store... [C]ontinue script to run WUMT and check for Windows Updates... [Q]uit script if you're just verifying or changing the update service status... Please select [E], [C], or [Q] What are your thoughts on this?
I like these ideas, and would like to request, if possible, make any other keys like [Q]uit without changes, in case some other key is pressed. On second thought, maybe not, just have all other keys do nothing. The window X at top right should still "Quit" = Exit, with no other actions, though. Don't you think? As in, remember with Win 7 GWX campaign, when clicking the top right red X got you "upgraded" from 7 to 10 without you realizing you had just been clobbered by M$? Top right X should Exit with No changes. Enable, Continue, Quit, or the window X which will eXit with no changes. Thanks pf100 for looking into and thinking about this. What ever you decide is fine.
Closing the Configurator window with X in the top right of the window closes the script without making changes, which works exactly the same as pressing E[x]it in the current script 2.5.1. I can remove the exit part and just say, "close window to exit script". The "press any other key to exit" scenario would take way too much work to accomplish. So I'm open to any other ideas you may have. Thanks for the feedback.
Perfect! I like the "Q". It's the first letter of Quit and leaves little room for error. Plus, closing the window with the corner x icon also does the trick. If you want to, you could put in parenthesis "(or close window to exit script)" at the end of your (Q)uit description so that users know it has the same effect.