Sizif's job continues, obviously. I have to disappoint you again. Every intervention in the system will be corrected after Health Scan why he is responsible \System32\Upfc.exe and launches it HKLM\SYSTEM\Waas\Upfc\"NextHealthCheckTime" - 2018-12-29T12:00:25Z . (Look at the time when it will happen next time on your PC) Microsoft , he does not hate you, but all the possible changes that make the system unstable. I want you a very nice day with new fun in trying to exclude the same.
But all Sisyphus needs to do is get the boulder over the top of the hill . Nothing ventured, nothing gained. No challenge, no satisfaction. Maybe it would be of value to pay some attention to upfc.exe.
@shewolf Upfc.exe cannot reverse changes made by the wrapper script. Neither can SFC or DISM health check. The only thing that can is the included uninstaller script. So I'm not sure why you would mention Upfc.exe unless you don't know how the wrapper script works and don't want to know how it works because you've already got your mind made up that you know everything and everyone else is stupid and the world will end if everyone doesn't do things "your way". You post this method all over MDL every chance you get. We are all very fully aware of it. You beat us over the head with it every chance you get. I have no use for it and will never incorporate it into the wrapper script. Now that you know this, there's no use in posting it in my wrapper script thread once a week, or ever. This method has no use in the wrapper script, so why do you keep posting it in my thread? Here's an idea: leave that method in your thread. Here's another idea: stop trying to be an a**hole. I will contact the admins to attempt to prevent you from ever posting in my thread again. Oh, and Merry Christmas and a happy New Year! Now kindly f*** off.
@Windows_Addict Of course you're allowed discuss any shortcomings of the script. I want all ideas about windows update control to be discussed, even if it makes my script look bad posted by people that don't like the script. Especially people like you who present valid arguments without trolling me. These discussions allow me to improve my script. Sure, we can put Home aside, even though the script works with Home when most other methods won't, but for now we'll forget about it for the sake of discussion. The recommended options you mention provided by Microsoft don't work as well in Pro, but they do in enterprise versions, so installing Enterprise makes my script unnecessary. Installing Enterprise may not be an option for some people though, so that needs to be taken into consideration. Preventing driver updates through GPO work with Enterprise, although I've hear reports that GPO doesn't always prevent unwanted driver updates (especially Nvidia) requiring you to block the driver update by using hardware id's in GPO, but for the most part, yes, it works. About the shortcomings of the wrapper script. I agree that Delta (UUP) updates through BITS ond dosvc are a problem when using WUMT since it doesn't use BITS and dosvc, only wuauserv, so the end result is you get the whole CU and not just the delta parts. The UUP (delta) problem is not a dealbreaker for me. Downloading a 1 GB file isn't a big deal for me but I can see where it would be for people with limited or very slow internet with bandwidth caps, and people in that situation may want to not use the script and look for a better solution for them. I haven't personally experienced or heard of an issue where the script installs updates blocked on certain systems but if you have more info on that I'd be glad to hear it. The script actually lets you hide those updates, preventing the installation of those updates. Of course, that requires checking the KB's of bad updates presented by WUMT or WuMgr while running the script so you know which update(s) to block. The way I handle this is to google the KB's presented as installable when running the script before installing them. If it's a bad update I hide it. And yes, the script breaks the functionality of the Store if you just run the script and do nothing else. It doesn't break the functionality of the Store if you run the script and enable wuauserv, then run the Store. Same with net 3.5 installation. About activation problems, you should always activate Window 10 before running the script, eliminating any problems there. The SFC errors are caused by denying system access to Update Hijacker files. Sfc can't "repair" the locked system files because they are unreadable and unwritable to the system. This is what makes the script work. (For instance, you can't disable usosvc in 1809 without serious repercussions, but you can effectively disable it by removing permissions from usoclient.exe and osrss.dll.) Disabling these two files still allows usosvc to work and in fact the service always runs when using the script, it just can't initiate a forced update. The SFC error issue is easily fixed by uninstalling the script before running SFC which allows SFC to run without errors, then after SFC is finished, run the script again to lock the sytem files again. About "too much ownership taking", I think it's just the write amount, only used to lock carefully selected Update Hijacker system files determined through a lot of research and testing. How else am I going to lock Update Hijacker files to prevent them from ever being run? These ownership and locking methods by removing permissions I use are easily reversible by running the uninstall script, so no harm done. Of course, there are many update control methods available that don't lock select system files, but my approach is different than the others because of this. I think it's a good thing to have several different options because different update control solutions work better than others, and some methods may stop working in future versions of Windows 10, and the more projects providing different approaches the better. I never said my method is best, I've only said it's best for certain situations. Those situations include using Home and Pro and you want to control what updates are installed and when to install them on your schedule, not Microsoft's. The only files the script deletes are Windows Update Assistant files and folders because they can bypass the scripts update control, useless powerrun.ini (soon to be replace by NSudo), and just in case the script can't lock a system file it renames that system file and appends a "-backup" to the file name (which unexpectedly happened from the update from 1803 to 1809). Renaming an unlockable system file doesn't break it's symlink, and also prevents those system files from being executed (SFC will "repair" those files). Then at that point on subsequent runs of the script it checks for the original system files and if they exist deletes the "*.???-backup" files, and if "*???-backup" files exists it renames them to the original filename, then if it can't remove permissions from those system files, it renames them back to to "*???-backup", leaving symlinks intact and causing no harm to the Windows 10 installation or system integrity. The system files can be locked and not renamed with v2.5.4 of the script with 1809, but it still checks for renamed system files in case someone used an earlier version of the script without uninstalling the earlier version first, leaving renamed system files which 2.5.4 fixes. I respectfully disagree with you in that this is "not an ideal situation" It may not be for Enterprise, even though I use it on Enterprise versions because I use my script on all of my installs. I think it's perfect for Windows 10 editions that don't give you complete control of updates. Like I said before, improvements could be made, but ultimately, the wrapper script "just works". I appreciate your input on what you consider problems and shortcomings with the script, and your ideas on better options. Like I said before, input from people like you only make the script better. I welcome all concerns with the wrapper script. I admit it's not perfect, but what update control solution is? Thanks.
I'm working on getting the admins to block @shewolf from posting in this thread due to spreading misinformation and just generally being an a**hole. Wish me luck.
Just my experience.... Using Windows 10 1803 pro. I tried to follow the guidelines proposed by shewolf, setting metered connection without using the script. Although Windows came up with a message indicating that a cumulative update was available but will not be downloaded without my permission as I was in a metered connection, the download, update, and computer restart did happen while tasks were running on the computer. On version 1803, Microsoft has not yet solved the update issues. If this can be of any help to anybody, I describe below what is working for me on script version 2.5.4 (I haven't yet tried 2.5.5) with Windows 10 pro 1803. My problem is to keep updated 4 computers with a very slow and unreliable (but unlimited) Internet connection. I use the script to block WU. I run the script to open WUMT every so often when I have a reliable and not too slow connection. I note the available updates. I download them with Microsoft Update Catalogue using my fastest computer. I use the downloaded files on the 4 computers (with WUMT open to allow the updates to be executed as they somehow need WU, even if there is no Internet). This way I have only to download once the updates that can be used on the 4 computers.
Unfortunately that user is like a stuck record (whatever mental issue this might be). The suggestion only works on Enterprise/Education/LTSB(C) editions when updates are additionally paused for 30 days. Even WuMgr is unable to find any updates in that state. On Home/Pro even on metered connection Windows can still override the block if the updates are considered to be mandatory for security and/or stability. Update faciliators are another story since they are not bound to default Update services or will initialize them.
Love your work pf100 I'm still on v1803 which has been stable and works well, still staying away from v1809 with all the ruckus from Microsoft.... over the last couple of months. Just a question what is the better version to use? WuMgr or WUMT as they obviously do the same thing, Is it just another different looking interface? with maybe a few extra's which I'm not game to touch? By the way I have only ever used all you versions as the portable one. Thank You for all your efforts with this great script. Happy New Year to you and your family
@pf100, Nice work and great gift for the new year! The start menu installation option, which I personally prefer, works well, and I appreciate the WUMT/WuMgr chooser screen. The only constructive comment I have at this time is almost too minor to mention: The configurator screen just before the chooser screen telegraphs only WUMT. For (C), I suggest replace "run WUMT and check for Windows Updates" with "run the update tool to check for Windows Updates." Again, put at the bottom of the to-do list. The current screens aren't confusing and all works well together as far as I can tell.
For a future update, you could replace the statements 492-502 Code: if %errorlevel%==2 (goto startwumt) wub.exe /e >nul 2>&1 timeout /t 2 >nul 2>&1 echo CreateObject^("WScript.Shell"^).Run "WU-keep-alive.cmd",0 >WU-keep-alive.vbs&WU-keep-alive.vbs&del WU-keep-alive.vbs Start "" wumgr.exe -update -online 7971f918-a847-4430-9279-4a52d1efe18d -provisioned -onclose close.cmd exit :startwumt wub.exe /e >nul 2>&1 timeout /t 2 >nul 2>&1 echo CreateObject^("WScript.Shell"^).Run "WU-keep-alive.cmd",0 >WU-keep-alive.vbs&WU-keep-alive.vbs&del WU-keep-alive.vbs Start "" "%wumt%" -update "-onclose close.cmd" by : Code: if %errorlevel%==2 (set cmd="%wumt%" -update "-onclose close.cmd") else (set cmd=wumgr.exe -update -online 7971f918-a847-4430-9279-4a52d1efe18d -provisioned -onclose close.cmd) wub.exe /e >nul 2>&1 timeout /t 2 >nul 2>&1 echo CreateObject^("WScript.Shell"^).Run "WU-keep-alive.cmd",0 >WU-keep-alive.vbs&WU-keep-alive.vbs&del WU-keep-alive.vbs Start "" %cmd%