With unreleased v2.7.3 of the script, when defender is updated the windows update and update orchestrator service are turned on to update defender and immediately disabled after defender update. With v2.7.2 of the script that would be just windows update service alone.
If we're still using 2.7.2 is there any risk that Windows Updates will sneak in and wreck things again before we upgrade to 2.7.3 with the fix, if Sledgehammer has already stopped automatic updates/WU.
I don't have any reports of forced updates with v2.7.2, just that update orchestrator is checking for updates. You should be fine. I expect to release 2.7.3 sometime later today tomorrow.
windows 10 has been able to do update stuff via MoUsoCoreWorker.exe directly since ~ September 2019 on modern versions, instead of doing it via svchost wu service. why have you danced around usosvc and not just ifeo block that one executable, WUT-style? Spoiler: what a mess, what a mess by comparison I had to do so very little maintenance to my solution. only borked it a bit last for very old versions. I've been teasing since forever a silky-smooth alternative, did not have the heart so far to share it (and maintain it), but that changed after working a lot with older hardware and older versions lately and be constantly reminded how abject WU is on real machines (I'm positive ms threats vm's better) and how all solutions are lacking one way or another.
MoUsoCoreWorker.exe, as part of a collection of craptastic crapware known as usosvc, has to call other files to work, such as one or more of usoclient.exe, usocoreworker.exe, usosvc.dll, and usoapi.dll, so it can't work in a vacuum. If I remove permissions from just usosvc.dll that will keep usosvc from running and I've known that for years. In lines 219-220 of the current script: Code: set s32list=EOSNotify.exe WaaSMedic.exe WaasMedicSvc.dll WaaSMedicPS.dll WaaSAssessment.dll UsoClient.exe set s32list=%s32list% SIHClient.exe MusNotificationUx.exe MusNotification.exe osrss.dll If I add usosvc.dll to the end of one of those lines, usosvc will be disabled permanently until permissions are reset with the uninstaller script so it would be incredibly easy for me to do. But I'm going to take the coward's way out and just let wub 1.1 disable usosvc for me because I'm lame like that. Trying to juggle which file does what is a very time consuming process I try to avoid whenever possible if I already know enough to know if I disable parts of a service it disables all of it effectively. I haven't been too concerned about usosvc in the past because it can't do anything if wuauserv is disabled. It still can't, at least with my script, but it tries a little too much for my liking now. And the way I look at "IFEO vs removing permissions" is, if I remove permissions to disable a file, that will never be flagged by an antivirus or antimalware program whereas with IFEO that is possible. I wish we could talk about this stuff for hours. You're not wrong and I'm not right, we just approach this thing from a different view which is good.
Hear, hear. Like I said, WU has made me angry recently working on some antiques - specialized pc's that can't even go above 1607 due to drivers. In pre-1607/pre-1803 windows, WU remains the same, tiworker hangs and timeouts making the PCs feel even more miserable. MS expanded their remediation annoyfication stuff. Microsoft Update Health Tools? CUAssistant? FFS! And they keep back-porting stuff like this to older versions without fixing the underlying update engine, because those improvements are reserved for newer versions..WAAS my arse. I say, to hell with this bastardized WU 10. At least in XP and 7 it was all about fixing security flaws - and there were so many of them! Now, it's mostly about s**tty icon changes, telemetry, pushing ChrEdge, fixing flaws comes fourth. - Microsoft, as long as you are hosting esd's from 1507 to 20H2, you better be providing a MCT for all of them. Because you can't legally force people to upgrade - there's no EOS clause in the license, and if it were, it would not stand in court. - Microsoft, as long as you are hosting esd's from 1507 to 20H2, you better update them more often. Otherwise you silently admit the last published one to be the bare minimum required for a working system, while any subsequent LCU can be viewed as optional by power users. For the longest time I've been a fervent advocate of running the latest version for added security, and that in part is true when it comes to UAC bypasses and other small stuff. But when it comes down to the real pesky stuff of privilege escalations, kernel & drivers pwning and network vulnerabilities, fact is ALL f**king windows 10 versions are affected! You can count on one hand major flaws specific to an older version. Don't take my word for it, check almost all LCU release notes, KB's and CVE's. So in the end, what difference does it make for users if you get pwned on 1507 or 1607 or 1803 that runs well on your PC, and just as well on the latest and greatest 19H2 or 20H2?! And now they've started bastardizing even more plug & play and driver updates. Prepare for malicious actors to take kernel level control of your PC much more easily in the future, now that MS will happily take and send over WU drivers from manufacturers without much oversight. Remember, everything gets made in china these days..
This may seem like a strange request, but . . . is there a way to have Sledgehammer not create the task that checks for WD definition updates on a schedule? Everything else about it runs perfectly, but I would like update checking (including WD) to be done totally manually via running the script and then proceeding to WuMgr and doing things from there. Possible?
Well in 2018 defender was malfunctioning without wu, been spotted not even having the once a day fallback check. That's why we all discussed it and agreed it was a necessity, and such schedules made their way into most popular WU blockers/managers. Not often do you see that level of cooperation from independent, competing solutions - and all to protect the users, even before users themselves asked for it. Now, I'd say it's safe to remove it completely, Defender will use WU if available but will otherwise update via it's own executable fairly often now compared to the past. The same warning applies: quick reaction cloud signature updates require WU, and although those will hit normal signature updates some time later, if you are the kind of person that runs new stuff every day and you disable WU, it's better to also replace Defender with a more reliable solution against 0-days from the likes of Avira or Bitdefender.
Yes. To prevent the WDU task from being created, in line 240 of v2.7.2 change this Code: call :create_task WDU "Windows Defender Update" to this Code: rem call :create_task WDU "Windows Defender Update" The line number of that code will change in future versions of the script but that code shouldn't change so just search for it.
I'm stick with Defender and also have Malwarebytes installed, but I do appreciate the concern. Sledgehammer (after startup/login) does the WD update checks and then after that I believe it's about noon and then again about 6:00 PM. I can do those on my own by just running the script. I tend to be a "control freak", as I've been told many times by my better half. Every so often, I'll look at the update history and there's an "aborted" WD definition update. Reason is always that MS has issued an update to WD itself and that update takes precedence over the definition update. The definition update subsequently installs successfully. Big deal, of course not. But (control freak, remember!) if I do the WD updates on my own via the script and then WuMgr, I'll see that there is a WD update along with a definition update and can install them sequentially and avoid the "aborted" update in the update history list. In any event, I figured out that I can accomplish what I need by changing one line of the script: ::Create WDU task, wub_task, and LockFiles task REM call :create_task WDU "Windows Defender Update" call :create_task Wub_task "Windows Update Blocker Auto-Renewal" call :create_task LockFiles "Lock system update hijacker files"
I just wanted everyone to know that since updates still aren't being forced with script v2.7.2, I'm taking some extra time to do more research. For instance, @BAU brought up MoUsoCoreWorker.exe and after some digging I've found that it can keep waking a pc needlessly and since I hate all update hijacking and it's a part of one, the next version will disable it. I was going to ignore it until I found that out. I'd like to do something about the MS-DEFCON thing. Only problem with that is it can stop working at any time so I need to spend time on making it not matter if it breaks. Anyone who has updated to 2.7.3rc1 are fine. That's the base for the next version, obviously.
Thanks! I've started to learn a few things here so I had figured it out. But thanks for the confirmation.
Have I told you all lately just how much I love you???! Man, again a very sincere thanks to you all for your hard work and cooperation. I just don't see this sort of "common enemy cooperation" approach in the real world much anymore, makes me so damned happy. Pf100, do you have some sort of a PP link to take donations? I'd like to at least buy you a dinner, or a few good whiskeys or something as a token of appreciation. Just feels like the right thing and the least I can do to show some appreciation.
Thank you very much, but no, I don't accept donations. This is a community effort. Money would just screw it up.
Fair enough friend, I understand. Well, suffice it to say then that I am very grateful to you and all the others here putting in the work. This little project has solved for me a major headache that's bothered me for years, and the daily relief this solution has provided to me is both real and significant. Thanks again to you and to all who are working hard to make this happen and keep it evolving.
Damn it! I wanted to pay you a coffee since we are in a pandemic and can't hug anyone! Really appreciate your hard work @pf100 ! Thanks for this tool! Love it <3
Hi, Non-pro (and very grateful) user here. Windows 10 Pro x64 v2004, Sledgehammer v2.7.2 installed. When I check Settings -- Update and Security, I see this: Windows Update *Some settings are managed by you organization Error encountered Last checked <some time during today> (...) Is this daily checking and message OK? I don't get any notifications, apart from Sledgehammer's reassuring notification on booting that Windows Update has been disabled. Also, I don't see any files in C:\WINDOWS\SoftwareDistribution\Download. So basically everything looks fine, but for this daily checking.