@pf100 I've no LTSB or LTSC for testing, only standard Enterprise. Nevertheless i tryied to find a workaround to the timeoutsec issue by suppressing this parameter. The idea is using an asynchronous process to process the ms-defcon thing and watching it in the main stream by activating a timer testing the process completion. This technic uses the start-job and recieve-job powershell cmdlets. I hope you are well.
I have LTSB 2015, LTSB 2016 and LTSC 2019 VMs (for testing). If the code can be executed standalone, I could copy and test drive it a bit in the VMs.
Have prepared the test environment and will check it out as soon as get back to the desktop. Well, it already works well in Windows 7...
Checked it first with the latest build, 19619.1000. Testing was unreliable at timeout=10, when I changed that to timeout=30, it worked much better. No idea why, maybe because Powershell isn't exactly the fastest shell on earth (nicely put).
FYI: In the last couple of weeks I've been planning and completed a new gaming computer build so I'm slacking on the script. Good pc parts are hard to get and requires a lot of planning to not waste money. It took a week to get the motherboard I wanted and found a used one in perfect condition that amazon found under some debris in the corner of a warehouse that was missing the box but had all the stuff that goes with it. That was too much work but it was worth it. I promise I'll get back to work on the script soon. Being stuck at home a lot now is actually great.
After installing the 05-2020 cumulative to 1909 and rebooting, I noticed that some (but not all) of the update hijacker files were back to default permissions. Re-running Sledgehammer after the reboot fixed this of course. But should there be some mechanism to check these files automatically after update restart? Just running Wub.exe /d /p like normal might not be enough? 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
That's right, if those files permissions are restored to default, wub.exe /d /p won't be enough. I could create a permissions check at every boot if needed. The permissions should only get set to default if Windows 10 is updated so that a windows.old folder is created where it moves the windows folder to windows.old and creates an all new windows folder. Is KB4556799 the CU you're talking about?
Yes, please. Unattended one running as a task would be best*. Windows 10 is sneaky, unfortunately. *It should run the entire routine disabling WU service (WUB) + check and rectify permissions.
Yes. KB4556799 installed new versions of MusNotificationUx.exe, SIHClient.exe, MusNotification.exe and WaaSAssessment.dll (new versions of those files appeared under WinSxS and installed in System32).
I don't think it's intentional to foil the operation of the tool, more like collateral damage from updating. That's where a "check and reapply" routing will come in handy.
I just took a break from working on the re-deny permissions task (and a lot of other things) earlier today. And what I meant about not being surprised at what they're doing is because I know they'd like to completely lock down all system files. They would completely deny access to those files like android and ios does if they could, but they can't. There are a lot of tricks they could do as discussed in the "the future of controlling updates" thread in my signature and I doubt there's much they could do that hasn't already been discussed. I feel like I'm ready for whatever they can throw at me, but I guess time will tell. Resetting some update hijacker file permissions is pretty lame on their part so it's possible they may have added functionality to those files. I'm not sure what they thought that would accomplish. Pretty sure there's no scenario where those system files disable themselves, so I guess they're just covering their bases by updating them and doing a little more to make damn sure windows will force you to update.
It might also be related to some slight changes to the WaaS (Windows as a Service), caused by COVID-19. They announced extending the corporate support for old versions, and suspending the forced update of 1809 Home/Pro versions that are still left. Sledgehammer might not be on their map at all.