I did some digging around about Microsoft Update Health Tools (MUHT) installed by KB4023057. It installs some files in "C:\Program Files\Microsoft Update Health Tools" which do effectively the same thing as an older version of the same KB4023057 which installed files in "C:\Program Files\rempl" The script already locks the rempl folder, but it's not really necessary because every method it calls to force an update is already disabled by the script downstream from that. So if you're using the script you can uninstall "Microsoft Update Health Tools" or not, it doesn't really matter, although being a control freak I'd rather it be gone. KB4023057 can't force an update with the script, so it's nothing to be concerned about. I'll probably force an uninstall of MUHT, or lock the folder, in a future update just because I enjoy killing this worthless crap with fire.
@pf100 Wishing you well with the "paradoxical drug reaction" recovery. I actually had to Google what it was. Weird stuff to be sure! As for KB4023057, on my system, it is sitting quietly in the "hidden" folder in WuMgr, which is where it will continue to reside. This must be the fifth or sixth time that MS has re/re/re/released this particular update. If nothing else, they are persistent.
Wishing you well Any plans to do that in the next release? I'm aware WUB was "open sourced" previously in this thread, but I think it's worthwhile replacing it to make the script more explicitly open source, especially for the benefit of users who haven't seen the posts about reverse disassembling WUB.
@dkn849 Thank you for the thoughts. I've only reverse disassembled wub 1.0, not 1.1 which I'm still not sure if I'm going to use it in the next release or not. Wub works by blocking and unblocking permissions for registry entries, when I like to do it by locking files and folders instead. I can lock files in the script and disable wuauserv and usosrvc, and unlock them so they'll work at will with a toggle and I may do that, eliminating the need for anything wub does, but I need to do more testing. Windows 11 is near so I need to check for any changes that need to be made to the script for that, and time spent reverse engineering wub 1.1 is time taken away from that. I really need to put this project on github or somewhere and I plan to do that eventually after it's 100% open source. TLDR; I may drop wub and what it does altogether leaving only WUMT as closed source which is entirely optional to use in the script and I would have removed it but I had requests to leave it in there. I will never reverse engineer WUMT because I never use it.
I went through the thread to find suggestions and this is what I came up with. If anyone sees anything I missed let me know. Thanks. 1. The uninstaller doesn't display "Sledgehammer uninstalled. Press any key to exit . . ." when unins000.exe exists. - @Whistler4 2. Warn against enabling wuauserv in configurator, then just leaving that window open which will defeat the script if you leave it like that long enough. (Not a suggestion, I threw this in here) 3. Do something about KB4023057's uhssvc service and C:\Program Files\Microsoft Update Health Tools. - @dkn849 4. Fix schtasks error message not being displayed - @rpo https://forums.mydigitallife.net/th...-10-update-control.72203/page-90#post-1656445 5. Fix redundancy with LockFiles.cmd and script. - @rpo https://forums.mydigitallife.net/th...-10-update-control.72203/page-91#post-1656709 6. Install over existing install without first uninstalling - @Homer712 7. Provide info on askwoody's ms-defcon on opening screen, but pressing any key will just advance to second screen.
Don't think this was missed, just thought I'd throw it in to see if it might be a possibility (I don't code, so, I have no idea if this would be a "sure, lets do it" type of thing, or a "are you kidding me!" type of thing). So, what are the chances that when a new version comes out, you could do an "install over existing install" update?
I think we can work on Win10 at least before autumn 2022 without any problems, Anyway, that's what I'm going to do.
Hi sledgehammer team! For future reference, there is a new Update Orchestrator Scheduled Task in Windows 11. The "UUS Failover Task" \Microsoft\Windows\UpdateOrchestrator\UUS Failover Task It's new to me anyway, it's not on Windows 10 20H2.
@spanishfly The new UUS Failover task, just like several other tasks that came before it, tries to run usoclient.exe which is already disabled by the script. 99% of new tasks do the exact same thing as older tasks and I don't see why microsoft does that because I see no advantage for them to do things this way.
in case of multiple user accounts in windows 10, how can I install the script for all of them in one single installation task?
I have two questions I cannot find the answer, please: 1- If I have multiple users accounts in my Windows 10 and execute sledgehammer from one admin user account, do the updates get blocked for the other users accounts too? Or do I have to run sledgehammer in every single user account? 2- is sledgehammer still blocking updates in the latest versions of windows 10 (20H2 21H1)? thank you
does it matter if the other users are standard or admin? what if the users accounts are created after sledgehammer is installed/executed?
As long as you've run the script once with an admin account, it doesn't matter if other users are standard or admin. And it doesn't matter how many or what type of accounts you add after the script has been run. "It just works."