Oh wow it can still force an update with the service enabled? This is quite scary. Did you ever figure out how it's forcing the updates? I noticed that Windows 10 does not respect the group policy settings and it will actually ignore what is there , for example the "Configure automatic updates" even if this is set to disabled. it will still do an update without the user agreeing. This is really why I liked your script because I thought it was stopping any sort of updates from happening. I wonder how they are happening. Do you think metered connection or changing that policy "congifure automatic updates" would help in addition to the script changes being made? For some times when I'm playing Microsoft store games, they require a connection to the update servers. (I think microsoft did this intentionally) so you have to always be "online" with them to play and they want to make sure you're using the latest updates.Very annoying. Thanks for that good info about the updates being forced with the service on.
@trashman01X About some group policy settings not working in Windows 10, that's why I wrote this script in the first place. About forced updates with the Windows Update service (wuauserv) enabled, I had the idea a while back to see what happens if I run Sledgehammer and leave wuauserv enabled permanently. I tried it on a few different computers at different times and I noticed they updated eventually. I decided the best way to figure out what's going on is to enable wuauserv with wub.exe, then just manually disable the service with services.msc so that Windows can enable it whenever it wants to and to log the time it gets enabled. I wrote a script that I'll put at the bottom of this post that checks the status of wuauserv and logs the exact time (within a few seconds) that wuauserv is enabled. So I used the logged time to search for the cause of what's making windows to check for updates in the event viewer and the task scheduler and I couldn't figure it out. Obviously there's a trigger somewhere causing this but I couldn't find it. I never tried setting the connection to metered because I was doing this to work on ideas for people who know nothing about computers and if the wireless or ethernet driver gets updated it'll remove the metered setting, or at least it did when I was researching this. But setting the connection to metered should work to prevent updates, but probably no more than 6 months and I'm just guessing about that. I really have no idea about the "configure automatic updates" policy on whether that'll make any difference. So setting the connection to metered is probably your best option if you leave wuauserv enabled for a length of time. I wish I had done more research on this issue but I had other things going on and just stopped digging any further. Spoiler: wuauserv change monitor.cmd Code: @echo off setlocal enabledelayedexpansion color 1F mode con cols=38 lines=8 Title wuauserv service change logging ::::::::::::::::::::::::::::::::::::: echo ************************************************************************* >> wuauserv-status-log.txt echo [wuauserv logging started] (Re)Starting log on %date% %time% >> wuauserv-status-log.txt echo The first entry below shows the state of the service at start of logging. >> wuauserv-status-log.txt echo All subsequent entries are actual service state changes. >> wuauserv-status-log.txt :start mode con cols=38 lines=8 cls timeout /t 1 >nul 2>&1 ::::::::::::::::::::::::::::::::::::: echo. & echo ^ ^ Logging update service changes to echo ^ ^ ^ ^ ^ "wuauserv-status-log.txt" timeout /t 1 >nul 2>&1 ::::::::::::::::::::::::::::::::::::: Reg query "HKLM\SYSTEM\CurrentControlSet\Services\wuauserv" /v "Start" | find "4" >nul 2>&1 if !errorlevel! == 1 ( echo. & echo ^ ^ Windows Update service is enabled ) if !errorlevel! == 0 ( echo. & echo ^ ^ Windows Update service is disabled ) ::::::::::::::::::::::::::::::::::::: sc query | find /i "wuauserv" >nul 2>&1 & if errorlevel 1 ( color 1F timeout /t 1 >nul 2>&1 echo ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ and echo ^ ^ ^ ^ ---^>^>^> not running ^<^<^<--- set status=stopped timeout /t 2 >nul 2>&1 goto status2 ) else ( color 4F timeout /t 1 >nul 2>&1 echo ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ and echo ^ ^ ^ ^ ^ ^ ---^>^>^> running ^<^<^<--- set status=running timeout /t 2 >nul 2>&1 ) ::::::::::::::::::::::::::::::::::::: :status2 if !status!==!status2! (goto start) echo. & echo ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ Writing to echo ^ ^ ^ ^ "wuauserv-status-log.txt" timeout /t 2 >nul 2>&1 sc query | find /i "wuauserv" >nul 2>&1 & if errorlevel 1 ( set status2=stopped ) else ( set status2=running ) ::::::::::::::::::::::::::::::::::::: :statuschange timeout /t 5 >nul 2>&1 echo %date% %time% >> wuauserv-status-log.txt sc query "wuauserv" | findstr /i "STATE" >> wuauserv-status-log.txt goto start
Oh wow very interesting information. I never could figure out what enables all of this either. That is why I was using WUB alone but then one day I noticed when I turned the service back on for a moment to update a Windows store game, that the updates started up again. and that is when I started searching for your script. Basically I needed a tool that would block the windows updates, but still allow store and Xbox game functionality in Windows 10. Your script seems to be the only temporary method, I thought was permanent until you just pointed out that eventually it will turn the updates back on (somehow) I think that Microsoft is obsessed with figuring out how to turn the updates back on, no matter what we do. There is some reason for this although I'm not sure why. Probably because they make a great deal of money from advertisements that they continually push into the Windows 10 releases. Oh By the Way. When you noticed it was turning the updates back on with WUB disabled. What build/version of Windows 10 were you using, do you happen to know? I'm using an older build of Win 10, Version 1809 Build 17763.107 The only update I have installed is the KB4464455. I am wondering if maybe the build or version is having anything to do with whether or not the updates will "find a way" to turn themselves back on. (Even after your script changes)
Just to be clear, when windows updates are disabled with sledgehammer, windows can never re-enable the update service again. It's permanently disabled until you run the script and enable it or check for updates with it, or enable it with wub.exe, or you uninstall the script. As you found out, the way I disable updates can cause problems with the Store and some apps. If you don't use any update control method and just disable wuauserv with services.msc, Windows will turn wuauserv back on by itself and it's been like that since November or December 2017. I don't know exactly what version of windows that was. It was one of the updates for version 1709 is all I know. I've never tried this, but StopWinUpdates lets you keep the update service running. If it didn't work I'd have heard about it by now. I don't have time to research other update control solutions because I use my free time to work on mine. If you try it make sure to uninstall Sledgehammer first. Another option, but I don't think it works on Home versions, is Windows Update Manager. The latest version 0.9b is here. It's used as an update option in my script, but I only use the downloading updates, hiding updates, and installing updates parts of it. It's designed to be a standalone update control solution for Pro and higher, I believe. Let me know when you find something that works for you. I've never studied solutions that allow the update service to remain on.
@BAU Sorry. I completely forgot. I need to talk to you, or type at you about your project soon. Most likely, the reason I forgot is that I haven't studied your project enough. I glanced through the code and learned a few things when I did. I haven't studied enough of anything else because I eat my own dog food. I wish we weren't all doing our separate projects separately, but I guess that's the nature of the beast.
That's because we all are after the same goal - making our OS experience better - not for superficial things like online karma or whatever. Have to admit I kinda jiggled when I first saw the name of this reincarnation of @pf100 tool: "the Dark Sith Microsoft has driven the young Padawan to the dark side" - read it in Morgan Freeman's voice I'm actually contemplating an update on my almost two years old script @Yen - ༼ つ ◕_◕ ༽つ giff rights to new topic here ༼ つ ◕_◕ ༽つ
You say its 16299.15 The only thing I am concerned about is that I'm running Version 1809 Build 17763.107 . has the WUT been tested with this? I would be worried that somehow a MS update would start without my approval. That is my ultimate nightmare actually.
Yes, blocking domains at the router level usually blocks all direct access via IP, too. The trickery circumventing DNS by using IP is known. All MS gets here is a nice error page.
have used the windows update toggle for some month, not only on a 1809 machine. it was as reliable as all the other great snippets for powerusers! ;-) on the 1809 machine (17763.318 since february..) i noticed two folders of noticable size which should not have been there, skype and your phone app.. i removed teams and cleaned the junk apps.. even if the timespan seems long (~4 weeks after removing), it might be the case that teams (or office progs in general) causes broken, lovely immersive start menus ^^
Microsoft Store uses windows update for all it's download functions - if you block wuauserv - Store breaks as well. What you mention there are classified as Store updates (that includes all the start menu bloat). From the get-go WUT was meant to not impede Store, just block installation of windows updates. Unfortunately this less intrusive method (that is the default for WUT settings) let's windows download updates anyway (but those will not start installation, ever). It worked well as a compromise, as you could catch big updates and hide them manually, preventing further data usage. For those wanting to also catch downloading of windows updates, while still having the Store fully functional, I've added the Downloads ! TrustedInstaller hack option. Not ideal, but did the job well, and could toggle it from the desktop right-click at any time you needed it if you were an advanced user. Now, that no longer works for recent versions since Microsoft started downloading updates alternatively via UsoCoreWorker. Which brings us to the upcoming version, that will adeptly block updates from being downloaded, while allowing Store to function, and probably let Defender cloud updates pass trough in a timely manner as well. All that without locking ownership of files, disabling services or even IFEO used by WUT so far - just some crafted task schedules, least amount of blocking, not fighting microsoft update remediation services at all, and generating the fewest errors in event log. Sounds ambitious, I know!
Yeah, I saw that this morning but thanks for the notice anyway. I've been waiting for v1.0 to put it in the script. No hurry though since the current v0.9b works fine.
There are a few new files this year along with the ones I already knew about to force updates. It doesn't affect the script which already disables usoclient.exe which is the file that starts the whole chain reaction, I'm just dumping this list of a group of files here for future reference: usoclient.exe, usocoreworker.exe, usoapi.dll, usocoreps.dll, & usosvc.dll