@DavidXanatos I don't mean to be the voice of doom, but in my opinion, I would not trust that this method would work for any length of time. Options are being removed all the time without notice, as you already know. I would say it's not only highly probable, but inevitable that they will remove this option from Pro (even if it works now). MSFT really does not like you stopping updates and they'll do everything they can to stop you from stopping updates. Placing your bets on this seems like a bad idea. As I said, this is only my opinion and I don't want to discourage you. If you think something might work, by all means investigate it and ignore my paranoia
@pf100 I would think that each time wuauserv gets started on a pro/home machine its up to chance if it will decide to check for updates, instead of idly sitting by and waiting for us to finish using whatever tool we are using, and disabling it again. Or is that a misconception? Whats your experience with the wrapper script? If M$ disables the WSUS workaround we could instead use the windows firewall to block the update service from communication with M$. imho they would not go so far as to break a whole into the windows firewall, or the Windows Filtering Platform API.
You're exactly right and it's not a misconception on your part. Every time you start wuauserv you're rolling the dice on a forced update. WaasMedic(Svc), Update Orchestrator, Remediation Service, and other "Update Hijackers" are ready and waiting for you to enable wuauserv to start unwanted Update downloads and installation. And even if you don't enable wuauserv, they'll enable it for you! And then there's Update Assistant that doesn't even need wuauserv enabled to force an update. And in my experience with the wrapper script, and in relation to it helping your project, and if I understand your question correctly, the biggest problem of all is that the Store and many other things, like some operations with DISM, installing dotNet 3.5, etc., cannot work without wuauserv running (and the update hijackers are waiting for that). For instance, it would be nice if wumgr could enable the update service, install updates, then disable the update service and then remove permissions to the wuauserv registry keys forcing wuauserv off permanently (like Windows Update Blocker (wub.exe) does) until the next time wumgr is run while disabling the update hijackers. But you can't do that because then the damn Store and the other things I mentioned won't work and Windows Defender would update through resource hogging MMPC instead of through wuauserv. So with the wrapper script I give these options: 1) Leave wuauserv always off except for update checks with WUMT (soon to be replaced with wumgr), and Defender updates using a task that runs every 2 hours that temporarily and unknown to the user (unless they read the readme and/or examine the script) enables wuauserv, updates Defender, then immediately permanently disables wuauserv again while update hijackers are disabled (safest). 2) Run wuauserv temporarily to use the Store or update an App or whatever else you might need wuauserv for while update hijackers are disabled (very safe). 3) Permanently enable wuauserv while the "Update Hijackers" are disabled in case for some reason they want to leave wuauserv always enabled while still keeping at least some protection from forced updates (not recommended, and protection from forced updates not guaranteed, but far safer than no protection at all). It's a shame that they've tied wuauserv to so many critical operations needed by the majority of users and there is no easy answer to this (as far as I know) other than to use a wrapper script with it. It would be great if it would be possible to somehow disable the ever-changing update hijackers with wumgr, but if you go down that rabbit hole it'll keep you busy for the rest of your life, or until MSFT gives us the option to disable updates like untouched Windows 7 SP1 does, but we both know that will never happen. MSFT will never give up coming up with new ways to force updates. That's my job, keeping track of all that crap and killing it. And if you can come up with a way to block the things I'm blocking without disabling system access to hijacker files like I'm doing, or even if you can't, I'm all in on wumgr and will help you in any way I can. The wrapper script is working fine (for now) so I have about a month until the next script update which will be mostly cosmetic unless a new KB introduces a new hijacker on patch tuesday (tomorrow!) or any time this month, and if it does I'll kill it with a script update. Sorry about the long explanation, but it's complicated. The firewall method should always work, unless they decide to do like they did with the hosts file and let certain system exe's and dll's (and whatever else) bypass it, but I agree with you that they probably won't punch holes in the firewall. The only thing that I don't like about the firewall method is you have to reboot, unless someone has come up with a workaround for that that I'm not aware of, and I really don't like the idea of having to reboot just to disable/enable updates. Like I said, it's complicated. Also if you want to integrate any or all parts of my open-source wrapper script (except WUMT and WIndows Update blocker which are closed source, but I already know exactly what WUB does and could open source it, and WUMT is about to be replaced with wumgr finally killing WUMT forever) it would all be open source and you're welcome to use any of the code in the script. Just an idea. I'm really not pushing my script, just pushing the idea of wumgr doing more than WUMT ever dreamed of, using some method of controlling the Update Hijackers which must be dealt with. It doesn't have to be by using my method, but it definitely needs to be done with some method.
@pf100 That indeed sounds like a lot of work, ... > Sorry about the long explanation, but it's complicated. Don't be sorry, verbose explanations are great! So to sum up there are various ways of disabling automatic updates, a) some that work on enterprise and above editions b) some that work (for now) on all editions without deep system modifications (WSUS workaround from the "Windows Restricted Traffic Limited Functionality Baseline" and possibly firewall) c) and some that work on all editions and use deep system modifications I think a good way to go would be to implement options a and b into the client as they use documented windows facilities and I think for the foreseeable future M$ wont break that GPO's and WSUS support in enterprise products, other corporate interests and the EU GDPR should make sure of at least that. Even if M$ removes WSUS support from non enterprise SKU's the settings will have a function in enterprise/education and server editions. The check for updates button in the settings is "dangerous" and the WSUS workaround takes care of that. About the firewall I will have to think about it, should be doable without a reboot, but its not a clean solution imho it may not work at all when a 3rd party firewall is being used as they often disable the windows firewall, so lets set that aside for now. The solutions which require system modifications would be best realized with external scripts. This way they can be independently updated and maintained. I'm thinking about adding a WuMgr.ini to the program directory in which one can configure scripts to be invoked and configured by WuMgr to enable/disable wuauserv on an as needed basis. The user could for example enable wuauserv from the tray icon in order to run a .NET installer, and than disable it again manually, or it could have a configurable timer when enabling it as to when to again disable wuauserv automatically. Depending on the configured script for as long as wuauserv is running internet access could be disabled to avoid gambling on an unwanted forced update, etc... Will wuauserv try to initiate an unwanted update in windows 10 on its own or only when some "Update Hijacker" requests that? I took a quick look at WUB, it seams that it disables some scheduled tasks and changes many registry values but it will be some afford to dig out the relevant once. If you could post what you know about WUB methods that would be great. Disabling the windows Update page in the settings app would be cool. Cheers David X.
@pf100 You must be smart in your head to use third program like WUB to perform the same results. If you set WUMT (AU Disabled) and run it with this command : https://forums.mydigitallife.net/threads/windows-update-minitool.64939/page-37#post-1332773 You will see the same thing in the registry. I already told you this once, but......? And placebo you need to complete ignorance.
You... must be... stupid!... in your head... You... must be... stupid!... in your head... You... must be... stupid!... in your head... I keep repeating that to myself cause I didn't know one could be stupid in in hum... the hand? foot? I know !! My lower head right? And placebo you need to complete ignorance... Placebo, do you listen placebo? You need to complete fully your ignorance, ok? Spoiler Sorry guys for the OT, this is the last one for this bitch.
@shewolf wuauserv won't stay off like that. It'll just get turned back on again by itself and it's been that way for a year now. You have to remove permissions from those registry keys also. I'm very well aware of the "sc config wuauserv start=disabled" command.
Extract from the forum rules : 1.3 Treat other members as you would want them to treat you. Any comments of a personal nature such as but not limited to, race, religion, intelligence, literacy, gender to another member will be deleted and the poster banned.
The tool does the following changes to the system registry when executed with all Options: HKML\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate/AutoDownload=2 2 = Turn off automatically update user apps 4 = Turn on automatically update user apps HKML\SOFTWARE\Policies\Microsoft\Windows Defender\Signature Updates/SignatureUpdateInterval=6 HKML\SOFTWARE\Policies\Microsoft\Windows Defender\Signature Updates/FallbackOrder="InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC" HKML\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata/PreventDeviceMetadataFromNetwork=1 HKML\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching/SearchOrderConfig=0 0 = Yes, do this automatically 1 = No, let me choose what to do, Always install the best. 2 = No, let me choose what to do, Install driver software from windows update 3 = No, let me choose what to do, Never install driver software from Windows HKML\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate/ExcludeWUDriversInQualityUpdate=1 HKML\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings/ExcludeWUDriversInQualityUpdate=1 HKML\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer/SettingsPageVisibility="hide:windowsupdate" HKML\SYSTEM\Maps/AutoUpdateEnabled=0 block access for system account to: HKLM\SYSTEM\CurrentControlSet\Services\UsoSvc HKLM\SYSTEM\CurrentControlSet\Services\WaaSMedicSvc I'm thinking now when to disable the update settings page, always when a non standard gpo is selected or add a separate switch for that.
If this fits with the "mechanism", I think one option should be (1) all updates except Feature updates and another should be (2) only security updates. Of course, the devil is in the details, since the various update hijackers, often KBs posing as security updates, try to force feature updates. This is basically what I meant in an earlier post: Or just the reverse in ranking: Highest risk - All automatic updates through to Lowest risk - No updates. I guess the root of the problem as to which updates to install is the MS psuedo-malware pretending to be beneficial updates. I think there has to be a reliable master list of updates that have been vetted and proven to not cause harm that WuMgr compares new MS offerings to. Perhaps one Low risk category of updates to install would be those that end up in the Windows Catalog, since they'd be less likely to be interim hijackers, although they could still cause problems for some users' machines. But you've got that covered with the offline option (again, need to be able to filter out Feature Updates or otherwise stratify the type of update, though). What a quandary! Hope this is the sort of suggestion you're asking for.
It also disables 3 tasks in the task scheduler: "Microsoft\Windows\LanguageComponentsInstaller\Installation" "Microsoft\Windows\LanguageComponentsInstaller\Uninstallation" "Microsoft\Windows\LanguageComponentsInstaller\ReconcileLanguageResources" it does not seam to disable the more important "\Microsoft\Windows\WindowsUpdate\SHI" task though I haven't spottet any other changes done to the system.