If you don't invoke UAC before running wub, you can't ctrl-c to cancel the script, so I left it. Well, you can cancel, but you have to do it more than once. Plus, the awesome code you wrote to check for looping, I think that'll help in certain situations.
Its up at MG, now we can all get back to normailty knowing that once again we have given MS the royal "Screw You"
Weird question... is anyone else besides OP having this problem with the WU service? I'm still on 1703 but this worries me somehow, as I plan to upgrade to the next iteration (one after 1709)... if this is going to be a nuisance...
Urk... that sucks... Aren't they aware their programmers suck hard and mess up stuff they don't bother to test, and that's the reason why people disables this crap so they can update manually whenever they fix their mess?... whatever. Besides the permissions thing for the UsoClient file... coudn't it be that disabling that task would prevent the WU service from restoring? Just wondering...
Tried that on FCU, WU still started itself, so ended up using WUB and forcibly deleting the schedule tasks relating to WU.
Dang... that means messing a bit with permissions so the service keeps disabled? Does it show any errors or simply that also restores itself? Sorry if ask so much, but if we find the core task (has to be a task) that messes with service settings, we are saved. (Athough we always have the WUB alternative to keep this controlled). Still? Crap... this is serious... Is this only happening in LTSB editions only?
Just to add... checking the links... seems 1703 has the same exact task, but WU never re-enables itself... I don't like this...
Most don't. Few days now, and all is still well with the WUB method No restarts as yet. There is another CU waiting for me to install, but I'm loathe to do it ATM, as system is running how I want it, for now.
Update related tasks in 1709 (most are inbox, some are created after install) Code: Microsoft\Windows\UNP\RunUpdateNotificationMgr Microsoft\Windows\WaaSMedic\PerformRemediation Microsoft\Windows\UpdateOrchestrator\Battery Saver Deferred Install Microsoft\Windows\UpdateOrchestrator\Maintenance Install Microsoft\Windows\UpdateOrchestrator\Policy Install Microsoft\Windows\UpdateOrchestrator\Reboot Microsoft\Windows\UpdateOrchestrator\Refresh Settings Microsoft\Windows\UpdateOrchestrator\Resume On Boot Microsoft\Windows\UpdateOrchestrator\Schedule Scan Microsoft\Windows\UpdateOrchestrator\USO_Broker_Display Microsoft\Windows\UpdateOrchestrator\USO_UxBroker_ReadyToReboot Microsoft\Windows\UpdateOrchestrator\MusUx_UpdateInterval Microsoft\Windows\WindowsUpdate\Automatic App Update Microsoft\Windows\WindowsUpdate\Scheduled Start Microsoft\Windows\WindowsUpdate\sih Microsoft\Windows\WindowsUpdate\sihboot and this task is system locked Code: Microsoft\Windows\UpdateOrchestrator\USO_UxBroker_Display
Hmmm... I'll fire up a VM and see if disabling some or any of those keeps WU shut Other option is to disable Update Ochestrator Service and see what happens...
Well... tested on a VM with Windows 10 1709 Home... I can disable s**t as usual, I have rebooted the thing many times and the service remains disabled... I disabled also telemetry service, and the Application Experience, Customer Service Improvement program and Windows Update tasks in Task Scheduler too... all remains disabled just like I left it, the OS is on the .98 version with latest cumulative update so, seems everything runs normal here. EDIT: Risked my butt and ran the task that is supposedly responsible of renabling WU service... nothing happened. all remains disabled, did a cold boot, nothing changed. Is there a chance this thing is affecting only LTSB users?
No. In addition to LTSB 2016 doing it, the Windows Update service was enabling itself on Pro 1709 on my laptop too. Microsoft is working to make disabling updates a diminishing moving target. Well, good luck with that, Microsoft. The people who want to be able to run manual updates will always find a way around your BS. Haha. Ha. **ckers.