[Windows 10] 【轉貼】Update Orchestrator

-------- Forwarded Message --------
From: Paul <[email protected]>
Newsgroups: alt.windows7.general,alt.comp.os.windows-10
Subject: Re: How can I STOP a Windows 10 update please?
Date: Sat, 12 Dec 2015 20:36:26 -0500

M. Stradbury wrote:
> In the summer I updated windows 7 to windows 10 and now
> my windows 10 is updating when I need the machine most
> because I'm studying for finals.
> It has been updating for TWO HOURS!
> I don't have time for this.
> How can I gracefully stop it, and how can I prevent it from
> updating whenever it feels like it?

When the computer boots, you may see a black Command Prompt
window flash on the screen.

Sometimes, that gets stuck for a few moments, and if you're
lucky, you'll see a copy of something related to Update Orchestrator

Update Orchestrator has taken over some of the duties of
the Windows Update process, and as a result, some of the
previous recipes for Windows 10 (preview or release)
may no longer work the same. So while you may find articles,
with a certain registry key with values from 0..4 or so,
that may no longer work.


   http://www.blackviper.com/servic ... ice-configurations/

       Update Orchestrator Service   UsoSvc     Manual  Manual  Manual

Eventually, you'll find an intrepid individual who
turned that service off.

https://www.reddit.com/r/Windows ... ing/?ref=readnext_9

Q   "I have been on windows 10 for a few days now.
     I just went to run Windows Update...

     * On my Non-Admin local user account.
       Clicking windows update crashes Windows Settings.

     * On my Admin local user account.
       Clicking windows update works, but I just it never completes.
       Just looks like its working forever.

     Now I did disable some services using Black Vipers safe
     Windows 10 guide. I thought that had to be it, but I just went
     back through the services, I didn't disable anything that would
     cause this (I think). Is Windows 10 Update down for anyone else?

A    Update Orchestrator Service (UsoSvc) needs to not be disabled.

So that will potentially take care of it.

Now, a question would be, whether disabling that on a running system,
will stop all the scheduled tasks (such as a reboot task). The logic
might not be there currently, to make "intelligent control" possible.
You could try looking in Task Scheduler control panel, and zapping
anything related to usosvc.

https://social.technet.microsoft ... ith-logged-on-users

In Control Panels : Administrative : Task Scheduler, you
can see the stuff that usosvc has scheduled. (Excuse the
spelling mistake...)

So the sequence goes:

1) System boots.
2) Something is already scheduled, and causes a black command prompt
   windows to run, which you see flash on the screen. This might be
   something to "repair" changes. It may be a startup item (like
   a malware might use).
3) Usosvc is in control of orchestrating things.
4) If kicks off a Windows Update scan (wuauserv, BITS, etc)
5) It has the ability to define tasks in the Task Scheduler
   control panel. Including scheduling a reboot when you
   don't want it to happen.

If the machine is in the middle of something, I would think
it would be pretty difficult to kill it entirely. Disabling
Windows Update service and BITS service and rebooting, might
work if it is still downloading. If it is in the process of
upgrading to 10586, it probably isn't using USOSVC at the
moment, as 10586 is likely when it was added. And if you're
in the middle of an upgrade install, I can'r really predict
what additional monkey business goes on behind the scenes.
Once the files are downloaded, it might be really difficult
to stop it then (might need 45 minutes to Upgrade install).

This is the kind of stuff you do to stop Windows Update,
back when it was in control. But with usosvc running,
it's even possible it might be able to "repair" these.
You never know, with stacked designs, what could happen.

   net stop bits              <--- Background Intelligent Transfer
   net stop wuauserv          <--- Windows Update scanner
   net stop appidsvc
   net stop cryptsvc

Stopping the top two, is likely enough. Stopping
all four, is for doing maintenance on the associated
folders (part of resetting WU to correct deficiencies).

While I cannot provide a precise recipe, I think you
can see some of the levers.

Cleaning out all the Task Scheduler entries put there
by usosvc - those can be put back by usosvc later.

Note that "services" can have recovery procedures. They
can try to start themselves again, up to three times.
If you stop the usosvc, it may be set to start itself
again. (The Indexing Service works that way.) You would
look in Control Panels : Administration : Services
to see what policies are set for it. So you stop it
first, and make sure it stays stopped.

net stop usosvc

Then clean out the Task Scheduler entries, so they won't
trigger while you're working.

If you reboot, usosvc is going to start again. Even
though you stopped it previously, you may have
disabled it in Services, the black Command Prompt
window (from some startup item) may be in charge
of putting it *all* back. So like a malware,
you have your work cut out for you. And without
a proper GPO or GPEdit template, it might be
difficult to do it in a more intelligent manner
than is possible today. I can't find any threads
discussing how to stick a fork in it with GPEdit.

I particularly dislike working on a system issue
which is a moving target, like a kind of guerrilla warfare.
This is why my "real" system uses Windows 7.

From a behavioral analysis point of view, if the
computer is left running for a non-critical
interval (like four hours before you need it),
it may "quiet down". But of course, depending
on the release schedule at Microsoft, and the
fact that Windows Update may check more than
once a day, you might still run into another
maintenance interval later on. So when I do
use Win10 Insider edition boot drive, if the
work is critical (benchmarking), I may have
to wait for later. On Windows 7, I might wait
five minutes, and all would be quiet (barring
a long Indexing Service run, which killing
three times might solve...).

Just a guess,