Windows Update Service - what it does and does not do?

Doing unsupported processes always has unintended consequences.  I don't know who told you to disable Windows Update, but you shouldn't.

With that said, if a machine updated, it was running.  Windows (the OS) does not have another mechanism for updating. That is all managed by that service.

You really have three options when it comes to managing updates in a "good" way.

1) Let the systems update themselves. Millions of home users do this without problems.  Yes an occasional bad patch comes out, but it is rare when you consider the raw number of updates, machines, hardware combinations.  For a "hands off" approach, this is often used, even in business.

2) Light touch.  Set up deferral policies. Microsoft has been evolving their "Windows Update for Business" policies throughout windows 10's lifecycle.  It gives IT enough time to see problems before a widespread deployment occurs, but doesn't require infrastructure or manual approval processes where security updates can go weeks or months without deployment (which is what bit Equifax recently.)

3) Use a managed patch deployment system.  Many RMM tools do this.  Microsoft has WSUS to do this.  You have very granular control over what updates get approved.  A good option for the paranoid I.T. personality.  But with that power comes responsibility...regularly monitoring for new patches, testing those patches with your LOB apps, and making sure they get deployed in a timely fashion.

None of those options involves disabling Windows Update.

While there have been *isolated* reports of 4056892 causing problems, there is *nothing* widespread.  That you even have one machine that this broke is surprising.  If you have many machines, as it sounds like, then you have an infrastructure problem.  The patch just isn't that broken.  Even the things it breaks (the BSOD it causes with some antivirus programs) is behind a registry key that prevents it from installing unless the registry key exists. And the only way the registry key exists is if it is manually created or the AV vendor creates it.  So the patch can't "accidentally" get installed with a bad A/V product by Microsoft.  Someone has to screw up and set the registry key for that to happen.

While there have been *isolated* reports of 4056892 causing problems, there is *nothing* widespread

I agree. None of our client machines (or my own) broke because of that patch (in place for about a week now).

There is a ZD Net Article today about some instability for some systems because of the recent patches.

www.zdnet.com/article/meltdown-spectre-more-businesses-warned-off-patching-over-stability-issues/?loc=newsletter_large_thumb_featured&ftag=TRE-03-10aaa6b&bhid=23164040498209351948461508422926

Do your systems fit into this category?

Cliff Galiher:  Very useful information!  

#1 - we've been working fine with #1 for years and only in the last 1 1/2 years "not so well", even with the difficulties that's where we'd like to stay.  But the difficulties have been rather significant.  Our network settings and firewall settings have been CHANGED by updates.  That's not a small thing in a peer-to-peer network.

#2 - I don't understand #2 or how it's implemented in a peer-to-peer network environment.  Could you illuminate please?

#3 - I don't understand #3 or how it's implemented exactly.  I get the principle but not the mechanisms.  We have GFI Languard running and one might hope it would help with this.  But I'm just getting started with it.  All that said, I agree with your points in this regard.  It's not an attractive option really.

So, I'm back to #2.

Our problem is this:
We likely have "legacy software" that we use for critical day-to-day operations - from our application service provider (ASP).  When one module of this software is run with KB4056892 installed, not only does the critical app not work but the system OS is damaged to the extent that Windows has to be reinstalled from scratch.  A "keep the files and app's" reinstall isn't good enough.  (But the "from scratch" install keeps the files anyway (using the media creator web download).  Interesting....)

This is a BIG deal.  The aspect of changing ASP's is always an option.  The aspect of the ASP fixing their software overnight doesn't seem likely.
So, I expect if Microsoft or someone knowledgeable would ask: "Is the ASP software compliant with our xyz modern Windows standards?" the answer would be NO.   And, the answer to: "how long will it take to fix?"  is maybe "years".  I don't know but am preparing to ask.

That this type of problem isn't widespread is very good information for us.

*We* decided to temporarily disable Windows Update service because of the severe damage that became evident on 1/5.  
Then, we went for a few days with KB4056892 "hidden" and left Windows Update service running.  
However, the fear of new "bad" updates combined with our legacy software left us possibly at risk and the management decision was to go back to turning off the service.

I said it was "temporary" but today it became evident that even "temporary" is a PITA.  We had to turn it ON and then OFF up to 3 times in the process of installing a scanner.  So I am very much looking forward to a better approach.
My original question now seems naive.
There is just *no telling* when it's going to be needed and when not - and this independent of wanting security updates quickly.

So, having it turned OFF seems now rather extreme.  But if you'd experienced the damage we've had, you too would "think twice".

McKnife:  Good information!

This is the first and only time that the Windows Update service has been STOPPED.  I had rather suspected that the one machine was somehow missed.  But when you say:

any inplace upgrade resets the startup type of certain (if not all) system services to defaults, which, for windows update, is of course automatic. What is an inplace upgrade? Any major win10 upgrade can be installed as an inplace upgrade!

 I have seen a bunch of machines that come up in recent days saying "Welcome to the Creator's Fall Update".   I have so far attributed this to logging in using a very-infrequently used User login.  Then you get HI!, etc. etc.
So, I can't say that there were any "in-place upgrades" because I don't know what would cause them.  What might?

John Hurst:  Good information!  Thanks for the reference.

We don't have any systems like those mentioned in the article.

The fall creator's update is such an inplace upgrade. You can be sure that that was the cause of the startup type getting reset to automatic. If you don't know how those big upgrades are deployed in your organization, then you have a problem. Maybe there is another admin using scripted installations? Or some deployment system?

McKnife:  It's a small organization and there's only but one other "admin" who may have done anything - but would not have scripted anything.
All of the workstations were brought up to 1709 some time ago - except for a very small number that would not "move".
I'm still learning about GFI Languard that's now operating on the network.  It certainly has deployment capabilities (although I've turned this OFF for now) but I'm not sure about Windows Updates in this regard.  It looks like it's doing *something* and I'm trying to find out just what and why and how.

Fred, if the update service was disabled at some point in time and those machines were upgraded at a later point in time, then the windows update service is getting reactivated and set to defaults - that is reproducible and expected behavior.

So if you choose to disable this service, please setup a GPO to deactivate its startup type and that's all. It will not come back up again and no surprises.

McKnife:  Thank you!  Since this is on a peer-to-peer network, can this type of GPO be set up - even if one workstation at a time?  I've certainly used gpedit.msc to set things and even have scripts for that purpose.

Are we talking about "making a setting" or "resetting the result of a reset"?  I can imagine both.
But "making a setting" is what we've been doing manually and that's what you describe as being overridden with the set to defaults.
So, I can but imagine neededing to "reset the result of a reset" post facto.

What might you suggest?

What you say is *very* informative because we've been seeing our network and firewall settings being reset to *some* defaults fairly regularly.  There has never been an explanation of why or how.  Microsoft was no help in addressing this question.  So now maybe this helps us move toward a solution for THAT as well.   :-)

In a workgroup setup, sadly you cannot use GPOs for that. Configuring startup types of services is one of the few items missing in the local gpedit.msc, so you will need to enforce this via a startup script or via a scheduled task that is running as system account. The script would be batch and the command would be

sc config wuauserv Start= disabled

Select allOpen in new window

(exactly as written down here, including a blank after "=").
--
 "resetting the result of a reset" would match, but who cares, it makes no difference :-)
--
If your other anomalies are because of inplace upgrades? I don't think so. What those reset is documented and firewall settings are not being reset and "network settings" (what do you mean, exactly?) neither.

McKnife:  By "resetting the result of a reset" was a confusing choice of words.  I meant "reversing the result of a reset to defaults" to get one's settings back.

I have been reporting since mid-2016 that our firewall and network sharing settings have been changed by Windows updates.
Here is the most frequent list of things changed:
File and Printer Sharing firewall rules have added scope set to encompass other subnets.  These are erased and have to be re-set.
Password Protected Sharing in many cases is turned OFF.  This is reset to ON and has to be reset.
There are others on occasion but these two are the most common - particularly the Password Protected Sharing.

Now, as far as wuauserv is concerned:
I've become rather convinced in the last few days that having this turned off isn't such a good idea.  I have been admonished for such an approach here in EE.  :-(
Well, it does work as a stopgap measure but not as a long-term thing.
It gets in the way of mundane installations like some convenient approaches for printer installation (that use Windows update to add drivers), .NET framework 3.5 installation/turn on, ScanSnap scanner installation and who knows how many others?

Even though we have tried to bring everything up to 1709, it's likely that one of those inplace upgrades caused this one instance to happen - because we were pretty careful to STOP wuauserv on all the workstations earlier.  I just don't know how it could happen....
Knowing at this point isn't that important as I have to see that Windows is installed from scratch on that one.

Thanks for your insights!

Thanks!