Thanks RickC. Used this helpful bat file already. Was forced to do a long update today, although I had disabled wuauserv, which seemed to work until now. Can you tell me why you have set UsoSvc to manual? It works fine but throws an error msg.
1709's UsoSvc is still too new (and undocumented) for me to work out what's happening behind the scenes. I want Windows Update to be stopped yet still allow Windows Defender updates. As a result, I'm currently setting UsoSvc to manual to see if it triggers/re-enables BITS as a fall-back service, even though I currently have BITS disabled.Clive K said:
(Unfortunately my notes are stored on another forum which is currently unavailable so I can't tell you more... but it's re-emphasised to me the importance of storing information in multiple locations.)
I know from recent bitter experience that Microsoft can and does change the settings of various services so I'm trying to work out how, when and why UsoSvc works.
PS - Where are you getting the error message and what exactly is the error? This seems to be a shifting playground with MS trying to work around restrictions that we, its customers, try to place upon the operation of its OS when it doesn't work in our favour.
Hope this helps...
Sorry for the delay. The command did set the service to manual, with the following error msg:
C:\WINDOWS\system32>sc config UsoSvc start= manual
ERROR: Invalid start= field
DESCRIPTION:
Modifies a service entry in the registry and Service Database.
USAGE:
sc <server> config [service name] <option1> <option2>...
OPTIONS:
NOTE: The option name includes the equal sign.
A space is required between the equal sign and the value.
To remove the dependency, use a single / as dependency value.
type= <own|share|interact|kernel|filesys|rec|adapt|userown|usershare>
start= <boot|system|auto|demand|disabled|delayed-auto>
error= <normal|severe|critical|ignore>
binPath= <BinaryPathName to the .exe file>
group= <LoadOrderGroup>
tag= <yes|no>
depend= <Dependencies(separated by / (forward slash))>
obj= <AccountName|ObjectName>
DisplayName= <display name>
password= <password>
Clive, Thank you for bringing this to my attention. I've just double-checked and see what you mean.
I can only assume that MS has changed what's allowed for the 'Startup Type' for the Update Orchestrator Service during an update. (My two 1709 devices are now both on build 16299.103 and now show the same error when I use the script.)
Change the line from sc config UsoSvc start= manual to sc config UsoSvc start= disabled and you won't get the error.
I've amended the script in post #6 as well.
Hi, much simpler- try Windows Update Minitool (free) - set updates to Notify (A very handy option), Disabled, Scheduled etc...
If updates are set to Notify (available via Group Policy in Pro) then you can see what is being offered and choose to accept it then or later.
You need to identify what's happening. It might even be it's trying to upgrade and failing each time. What build is it? It shouldn't be receiving updates that frequently anyway, which is why I suggest the upgrade failing scenario- which is repeated.I suspect that's because every time I boot it up, it catches up on back updates.
Yep, very old build as you say- so I guess upgrades are failing- unless they are not even offered. (I think that can theoretically happen if MS deemed your PC was incompatible).
What does your Upgrade History look like?
Note: there are plenty of threads here and elsewhere about PCs failing to upgrade, and plenty of info on that and what to do- although in some cases that can take quite a while to resolve.
Thanks for all your help. I've now confirmed my original diagnosis: my secondary computer, which I boot up only for a couple of hours twice a week, has FAR too little run time to update itself, so when I go to use it there's a huge backlog of updates that eat up all the processor resourses and still don't have enough time to download and install the backlog. I've now solved the immediate problem by spending 24 hours nursing through the backlog of updates. But my original question is not solved, because it'll start happening again unless I change my routine. I'm thinking about using your STOP script in reverse: stopping updates immediately when I boot up, then restarting updates and checking for them before I shut down. What will happen if and update download or install is in progress when I run the STOP part of your script? It'd be nice if it paused the update process and the resumed where it left off when I restart it. What about the PAUSE button on the Advanced page of Updates? By the way, I was going to paste your Stop command into the command prompt but saw that the command prompted has been reploaced with something called PowerShell, which won't take a paste. Things get worser and worser.
Hi, first here's a script that is intended to REALLY stop windows updates- uses WMT and another utility too.
Here's a handy tool from your friends at MajorGeeks.com Solved - Windows 10 Forums
Now I don't think stopping updates is the right approach in general. But it's there, as MS is making this harder.
Second, Command prompt is still there. See the Tutorial section on accessing it or making more accessible now MS has hidden it a bit more. E.g. You can put it back in the Win X menu. Or start it by
Windows key R, cmd
Third, there shouldn't, in normal operation, be a huge number of updates at any one time. The principle is the latest major update is cumulative, thus older ones are no longer relevant.
However, you may get driver updates, flash updates, defender updates..... (and updates to 3rd party programs and apps- which update frequently but transparently).
But if you have either an upgrade, or the first update after an upgrade, these are both normally large, the first inevitably so.
Fourth, if you have Pro, you might consider using scheduled updates in conjunction with scheduled maintenance. That's described in the relevant group policy screed (see Group Policy Editor) - I've never tried it, but it would mean your PC starts up automatically and then does that. Personally I'd want to be around- so maybe you could schedule that for a time after you stop using your PC but you're still there. Just a thought you could investigate.
Your problem isn't stopping updates, it's allocating time for them. I'd have thought Notify is fine- then start the update as you finish working with the PC.
Quote