Windows 10 Updates Run Amok - How to Manage Effectively

Because of critical operational damage done by KB4056892, we Disabled the wuauserve aka Windows Update service.  This KB corresponds to Windows 10 1709 Build 16299.192.

In the last few days, KB4088776 corresponding to Build 16299.309 was installed anyway.
The systems are left with wuauserve aka Windows Update service in the default Manual setting.
Fortunately, the only damage this time was that the Cortana icon no longer launches anything and the Cortana search box can't be typed into.  Perhaps there are other things but they haven't been found yet.

How is one to maintain system configuration management under these circumstances?  
I've not found anything but "delay" methods re: Windows updates.  That seems risky in the extreme.
LVL 27
Fred MarshallPrincipalAsked:
Who is Participating?
 
Cliff GaliherCommented:
Disabling windows update is not supported for reasons you've now found out.

You have two choices. Use an update management product like WSUS, or use settings such as Windows Update for Business to provide proper to properly test and potentially pause updates on a limited basis.
0
 
JohnBusiness Consultant (Owner)Commented:
The current build fixes a few issues and unless you have enterprise Long Term Service Branch , you cannot stop updates as you have found out
1
 
Fred MarshallPrincipalAuthor Commented:
"you cannot stop updates" flies in the face of effective system management.  What's the answer to *THAT*?  "Trust me" just doesn't cut it.  Critical operational configurations just can't be fooled with and certainly not "out of control".  It's a serious matter that needs illumination and resolution.
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
JohnBusiness Consultant (Owner)Commented:
As I said, unless you are on LTSB, you cannot stop them.

You can delay by days and by using the setting that defers until widespread use.

Windows-10-Defer-Updates
The new ways change things.
1
 
Fred MarshallPrincipalAuthor Commented:
The problem with delaying updates is that there are predetermined categories, each with separate maximum delay times.  
Along with this observation is the difficulty that one can't predict that there won't be a problem with an update no matter the category.  So, one may be stuck with a 30-day delay on an update labeled to be a "Quality Update" that brings a very serious issue with no known solution.  Then what?

Of course, the answer to that question is: "It depends".  If "only a few" users have the problem then "too bad" for them.

In the olden days, one could isolate a system because:
1) it was all hardware
then later
2) it wasn't connected to the internet
Neither of these observations would, by themselves, suggest that progress has been bad, that software as part of system operations is bad or that being connected to the internet is bad.
However, if system stability is endangered because of chosen use (or abuse) of the availability of an internet connection then that seems unfortunate, and indeed, untoward.

If I understand how it stands, the class of users who are:
1) small and with limited resources
2) ill-suited to use WSUS for a variety of reasons
are out of luck if system stability is important to them AND they rely on an internet connection.
But, yes, it does appear that there are solutions.

The other aspect of this is the reliability of the Windows Update process / the quality of the updates.  It seems to me that there are a few categories:
1) Good, solid updates that aren't in conflict with existing software.
2) Good, solid updates that ARE in conflict with existing software.
3) Not-so-good updates that cause trouble; with existing software and otherwise.
4) Updates that cause damage to the Windows OS and/or brick the hardware somehow.

The problem here is that nobody knows a priori which category might emerge or in what environments.
That's the apparent reason for suggesting delays.  So that the user might conduct tests in order to gain confidence.

Given that a test suggests a problem then what is the next step?
a) Report it to Microsoft and wait.
b) Find your own solution.
c) If you can relate the problem to 3rd party software, tell the provider and ask for a solution .. then wait.

This seems like a mostly-new endeavor for small business.  Isn't it?

In contrast, major releases of operating systems were serious matters which had considerable time and testing to reveal issues prior to full release.
Why do I feel that this is disappearing and the burden is being shifted onto the customers?
There is certainly no shortage of complaints and cautions from the pundits who follow all this very closely.
0
 
David Johnson, CD, MVPOwnerCommented:
I am a windows insider and have not had any problem with ANY of the windows updates.  Your problem with that particular update implies that you are using AMD processors, is this correct?
0
 
JohnBusiness Consultant (Owner)Commented:
So, one may be stuck with a 30-day delay on an update labeled to be a "Quality Update" that brings a very serious issue with no known solution.  Then what?   <--- I tend to keep up to date with updates so as to know what, if any, outcomes there are. Another reason not to turn updates off.

If I understand how it stands, the class of users who are: ....   ill-suited to use WSUS for a variety of reasons

So then you need the other solution offered.

What hardware are you using. Like David, I am a Windows Insider. My two Lenovo Production machines update flawlessly and my Lenovo Insider machine updates fine with some Windows Insider anomalies.
1
 
Cliff GaliherCommented:
You've definitely drawn some spurious conclusions.  And we could play "what if" all we want.  So I'll unpack your claims, but I won't go and try to delve too far into what-ifs.  I'll use a few of my own to demonstrate why its a trap.  A mental gymnastics used to justify any number of conclusions.

Can updates cause problems?  Sure.  That has been true going as far back as windows update was a thing.   "Along with this observation is the difficulty that one can't predict that there won't be a problem with an update no matter the category."

Great.  So on XP, if you installed QuickBooks 98, then skipped 99, then installed 2000, then installed Windows Live, some random update didn't expect the weird combination of DLLs that was left behind from all those programs and the machine blew up.  This has *ALWAYS* been true. Windows 10 doesn't change that, and so this comment doesn't seem applicable.



So, one may be stuck with a 30-day delay on an update labeled to be a "Quality Update" that brings a very serious issue with no known solution.  Then what?
Then nothing.  You restore a backup if its important.  Backups aren't rendered unnecessary in today's age.  Like I said, this isn't new.  It is absolutely impossible for any company to test every possible combination of programs, hardware, and the random solar flare that caused bit-rot.  That doesn't exactly qualify as "updates run amok."

n the olden days, one could isolate a system because: 1) it was all hardware
then later
2) it wasn't connected to the internet
Neither of these observations would, by themselves, suggest that progress has been bad, that software as part of system operations is bad or that being connected to the internet is bad.
However, if system stability is endangered because of chosen use (or abuse) of the availability of an internet connection then that seems unfortunate, and indeed, untoward.


That was a bit of word salad.  Nothing was ever all hardware, unless you want to count steam powered devices.  The term "bug" comes from literal bugs crawling into warm dark spaces and causing problems in old tube computers.  Computers programmed by punch-card/tape.  Which is still software.  Bugs existed *THEN* to describe bad code.  If you want a guarantee of no bugs, I can sell you a slide ruler.

As for the internet....Microsoft included its first winsock driver and PPP support in windows 95.  The internet was unsafe then, and is unsafe now.  If the system needs to be isolated, the truth of that hasn't changed.  Air-gapped systems absolutely exist with zero internet connect. Particularly in the military.  Yes, it is a real and viable solution if that's the level of isolation you need.  Windows 10 hasn't changed that.  It also goes pretty far afield of your original question.  But hey, you brought it up.

I
f I understand how it stands, the class of users who are: 1) small and with limited resources
2) ill-suited to use WSUS for a variety of reasons
are out of luck if system stability is important to them AND they rely on an internet connection.
But, yes, it does appear that there are solutions.
That's a bit of a stretch. I won't play hypotheticals.  Feature updates can be delayed for 365 days. Quality updates can be delayed for 35 days.  BOTH can be *paused* another 35 days as needed if a bug does sneak by.  And by then, I guarantee you Microsoft will have pulled a bad update.  Case in point, the meltdown patch that caused some computers to spontaneously reboot.  Pulled within two weeks of its release.  70 days is a *TON* of time if you need it.  All without WSUS.

And if you need more control than that, then you aren't ill-suited to use WSUS.  Again, this hasn't really changed.  You could take windows 7 and set it to never update.  But there are exactly two types of machines.  Those not on the internet...which makes that setting irrelevant.  And those on the internet, making that setting even more dangerous than the risk of a bad update.  We don't live in a world where you can be on the internet and not take security updates.  I can post the entire list of security flaws that *HAD PATCHES* that people didn't install, and later caused massive virus outbreaks.    SQL Slammer.  Blaster.  Nochi.  How about the major breach of a credit bureau?   Microsoft didn't make this change in a void.  People *NEED* to update.  Because when a botnet runs rampant, it isn't just the stability of a few computers that is impacted.  It is millions of people, quite literally.


The other aspect of this is the reliability of the Windows Update process / the quality of the updates.  It seems to me that there are a few categories: 1) Good, solid updates that aren't in conflict with existing software.
2) Good, solid updates that ARE in conflict with existing software.
3) Not-so-good updates that cause trouble; with existing software and otherwise.
4) Updates that cause damage to the Windows OS and/or brick the hardware somehow.
1) Most windows updates are this.  By a WIDE margin.

2) Honestly?  The few times I've seen this, it is always bad software.  Yes, testing patches has always been important, and that hasn't changed even a little.  You have test machines to make sure LOB software stays intact. If an update breaks it, you contact the vendor IMMEDIATELY.  And in some cases, you switch software because the vendor is that bad.  In every case I've seen, read about, been in a Microsoft call about, or saw a case study on, the vendor was actively doing things in the kernel of the OS they should not have been.  That's on the vendor, not MS.  And not updating (again, see the security argument) is not a valid option.  You buy enough time to get the vendor to fix it, or switch.

3) I can think of one quality update that did that in the last few years.  The aforementioned meltdown/spectre patch. Which was fixed before any delays/pauses would have caused it to install.  Feature updates can be delayed much longer, and *BY DEFAULT* don't install into the business branch for 4 months. They are stable by then, pretty much universally.

4) I know of exactly one instance of this with windows 10.  There is one patch that replaces an important driver, but due to a 3rd-party component (see #2), the driver does get deleted, but not replaced, causing the computer to not boot.  And again, delaying/pausing updates addresses this, if you are unlucky enough to have that 3rd-party component and tested to realize it.

The problem here is that nobody knows a priori which category might emerge or in what environments. That's the apparent reason for suggesting delays.  So that the user might conduct tests in order to gain confidence.

Given that a test suggests a problem then what is the next step?
a) Report it to Microsoft and wait.
b) Find your own solution.
c) If you can relate the problem to 3rd party software, tell the provider and ask for a solution .. then wait.

This seems like a mostly-new endeavor for small business.  Isn't it?

a) Usually not necessary.  Microsoft gets a ton of telemetry.  When problems occur, they know.  *DO* subscribe to lists or reddits so you can follow update issues.  That's a *basic* job of any I.T. Pro.  I block an hour out every morning to go through my RSS feed for tech news, including updates, security issues, trending topics.

b) Rare in the small business realm.  Not unless you have a ton of time to analyze crash dumps and the coding skills to fix interop issues.  If there was an order of priority here, this isn't b.  It is c or not an option at all.

c) This is A for me.  And relating it to 3rd party software is easier than you think.  And no, waiting is not a big thing.  The vendor acknowledges the issue and gives a timeline for a fix.  OR they no longer are my vendor.  Resolution comes in days, not weeks.  It isn't an endless wait game as you imply.

No, this isn't new for business. I've been preaching the necessity of patch testing for over 20 years.

In contrast, major releases of operating systems were serious matters which had considerable time and testing to reveal issues prior to full release. Why do I feel that this is disappearing and the burden is being shifted onto the customers?
There is certainly no shortage of complaints and cautions from the pundits who follow all this very closely.
Not at all.  Feature updates can be delayed for 365 days.  And there is LTSB if you need even more time.  It is a change, yes, but it isn't this shifting of burden.  It *is* making I.T. Pros be more responsible and learn new skills.  Which has *always* been true.  Back when small businesses ran on Novell (because Windows 3.1 was not a good business OS), the transition to windows was not easy.  OR moving from NT4 to 2000.  Or,,,,you get the point.  Change is inevitable.
0
 
Fred MarshallPrincipalAuthor Commented:
It appears that I've confused folks by being a bit too broad in the descriptions.  Sorry about that.  I'll try to boil down the essential elements.

Addressing "what if" is a part of worst-case analysis.  It may be overkill at times but it's always available.  Good analysis starts somewhere.

I believe we sort of agree that taking the updates as they come is good practice.  It's the practice that I'd prefer and what I'm trying to get back to after a real house of horrors.

The idea that all updates have been fine is great but not entirely correct.  The truth is that updates have been fine for MOST OF US.
We used to be able to "hide" updates using the MS web interface.  In a few cases it was found necessary to do exactly that.  In place of this is wushowhide - although the related Windows 10 interfaces are clumsy so you have to know which list of installs to believe. The list of UNINSTALL opportunities and not the Update History - which appears to only list installs but not reflect uninstalls; so the latter doesn't indicate current status.

The idea that one can walk away from a 3rd party provider is nice in concept.  Of course, it's theoretically possible.  But, In practice, many companies have huge investments in time and money that ties them to a single provider.  At issue is the time and cost of a massive conversion.  And, if the single provider is big enough and sluggish enough then the problems related to Windows Updates may never be fixed; much less even acknowledged.  I have heard recently: "Our software is fine.  You'll have to go to Microsoft for that".  My reply was: "Yes and they will tell me to go to YOU and this conversation of ours will just continue".

This relates to the difficulty I have with delayed-but-forced updates. I think this is a real problem because I've been living it:
I'm having a little trouble with definitions.
Specifically, KB4056892 is a Quality Update.  "No new operating system features are introduced".  Yet, it breaks our systems.
Those that followed are "Cumulative".
16299:201 on Jan 18 via KB4073291
16299.214 on Jan 31 via KB4058258
16299.248 on Feb 13 via KB4074588<<<<<This one is reported to have a USB bug.
16299.251 on Mar 5  via KB4090913
16299.309 on Mar 13 KB4088776
So, a question would be: "If an update is "cumulative" does that mean it will carry along with it a problem that was introduced earlier in the sequence of updates?  From recent experience, it appears not necessarily - thank goodness.
So what does "cumulative" mean then?
I do think it's nice for updates to bring bug fixes - including bug fixes to earlier update releases.
But then I don't know what to call them.  Maybe "cumulative" is meaningful but not complete?

So, we have the situation where KB4056892 is hidden using wushowhide.
And, to prevent further, perhaps equally damaging, updates, we reluctantly turned off the Windows Update service for a time pending new updates and testing.
We were about to test the latest update in our environment when KB4088776 was forced onto those systems and the Windows Update service was set back to "Manual" in the process.
There do remain broken capabilites in the OS with this update but, it appears, they aren't critical - thank goodness again.
At issue is that this forced update could have been truly disastrous as KB4056892 introduces a situation that damages the OS to the point that Windows 10 has to be reinstalled from scratch.  What if KB4088776 had carried that situation forward?

These are "Quality" updates and the maximum delay for them is 30 days - quoting both the MS website and in the gpedit delay settings.
Whether 30 days is adequate or not is arguable.  We have not yet completely recovered from January 3rd and that's where our resources have been focused.

The original question was:
How is one to maintain system configuration management under these circumstances?  
I've not found anything but "delay" methods re: Windows updates.
Whether I like it or not, I believe you all have answered it well.
Thank you.
0
 
Cliff GaliherCommented:
Well, let's unpack this a bit:

Good analysis starts with what you have in front of you.  Not with what-ifs.  Again, if you start trying to analyze by what-ifs, you can invent endless scenarios that never match your environment.  "What if I run a mainframe from 1986 with Fortran code and need an NFS client on my machines, but it can't interfere with any GPS radio drivers that also use the same ports as NFS."   You could analyze what programs and 3rd-party firewalls and switches could make such a convoluted scenario work, but if you don't actually run that setup, does it matter if an update breaks such a setup?  Why analyze it??

Thus the need for patch testing. Analyze what YOU have.  Not hypothetical what-ifs.


I never said that all updates are great.  Re-read my response.  I said *MOST* are great. That doesn't absolve the I.T. Pro of responsibility of testing patches.  Nor does it contradict what I've said, which is that...in combination with other *SUPPORTED* strategies, is enough.  If you have a real-world case where it wasn't...and that the factors are known, please share.  The "we think this update may be what broke things" is at best a random guess.

As for definitions:  Quality updates *ARE* cumulative. Those aren't two separate things.  Every new update replaces the old.  4056892 was the cumulative update for 16299.192.  All of the others you listed are also Quality updates.  In my last comment, I mentioned an issue with an update that...under VERY SPECIFIC CIRCUMSTANCES...would pull an old driver, but would fail to replace the newer driver, resulting in a blue-screen.  Well, guess what, that is THIS update. It is even listed in "known issues."

https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892

Guess what else is listed in known issues.  Which update supercedes it with the fix.  That update was released WITHIN the 35 day delay window.  So if you had tested the patch, found that you happened to fit the rare circumstances that caused the issue, and delayed the update, you'd have gotten the fix before the delay expired.  Thus proving my point that the delay strategy *DOES* work.

Quality Updates are indeed cumulative.  There is no mystery in what that means.  It'll carry forward any and all fixes from earlier updates.  And yes, unless fixed, any problems too.  *BUT* they are updates.  If they didn't introduce anything new, there'd be no reason for Microsoft to release them.  So...4056892 had a new bug.  It had all the fixes from any update that came before, had a ton of fixes of its own, but introduced a new problem. Then along came the few updates.  They fix new things, old things, and the fix for the bug in 4056892.  So how is that not cumulative?  Why do you feel that is "incomplete" as a word covering what these updates do?

If a new update doesn't bring forward a problem from an old update, it is because the problem was discovered and fixed. Not that code was magically left out.

Quality Updates can be delayed for 35 days.  But you can also PAUSE updates for 35 days.  From a technical perspective, there is a difference between a delay and a pause.  When you set the policy for delaying updates, it is persistent.  Every update in that category will experience that delay indefinitely.  A *pause* is a one-time thing.  It stops all updates for 35 days from the "start date" you set.  Once that 35 days are gone, updates resume as normal (where normal is your usual delay settings.)  So if you have a delay of 35 days.  Then pause updates, with the start date set to the last day of the 35 day window from the update you don't want, you have a total of 70 days,  That's quite a long time to stop updates, and for fixes to be found.

As for walking away from a vendor:  If it is truly a *massive* investment then you have very reason to use WSUS or LTSB to protect that investment.  There is no conceivable circumstance I can think of where you can say "we spent $250,000 on this specialized automation environment, but refuse to spend $500 to set up a WSUS server."  Nothing about that makes sense.  No, you  didn't actually claim that I know.  But in your previous comment you did say there are small businesses that, for whatever reason "can't" implement WSUS.  But then in this situation you've posed another what-if where there is this huge investment that can't be walked away from.  Two what-ifs...combined to make a contradictory position.  I suggest that if the investment is that important, the business that made it can't afford to NOT use WSUS.  That's what it is for.

If you are still recovering from 4056892, it shows a few major problems that aren't MS's fault, nor that indicate a new update management process needs to be found beyond what has been provided.  It *only* demonstrates two things to me:

1) That the Disaster Recovery plan was not sufficient to handle key failures.  Backups.  Failovers. Hardware can die.  A virus can completely mangle an OS more than any update, and zero-day attacks are far more prevalent than a rogue update.  I'll play "what-if" this once because it is real-world. What if a crypto-virus had mangled as many machines and data as 4056892 had?  What was your recovery plan for that?  If your only plan is "hope we don't get cryptoviruses" or "trust our antivirus" then I repeat my first statement. The DR plan was incomplete.

2) The second thing this demonstrates to me is that the update was not tested in your environment.  The very smallest business should have 1 machine take updates when they come out.  Delay the rest for 2 or 3 days. If the one machine breaks, pause updates (as described above) while the situation is investigated.  This can work for a business with only 5 machines.  But recovering from 5 machines breaking also shouldn't take 2 months.  IF you have many many machines (which is the only way I can think of that recovery is a months-long process) then you can easily set up staggered delays.  IT staff gets updates on patch Tuesday. 0 day delay.  Key power-users that can report problems get a 15-day delay.  The rest of the business is on a 30-ish day delay.  And *that* is an oversimplified example.  You could define 5-10 delay groups as needed to cover LOB app testing.  And if a problem is found...PAUSE.  Done.  Problem averted.  Restore systems impacted and investigate the problem and look for fixes.

This would have, in the real world, handled the problem you have described without a what-if.  And is in line with the advice you've already been given here without using unsupported techniques or workarounds, or even WSUS (which is totally supported and not considered a workaround, but seems to not be an option for you for some reason.)  

I hope that makes sense.
0
 
Fred MarshallPrincipalAuthor Commented:
Cliff Galiher:  It makes sense.  

You've analyzed the situation pretty well!  Well, except that silly "what ifs?" are just that: silly.  Indeed, why analyze one of those?  We agree.

You mentioned:
If a new update doesn't bring forward a problem from an old update, it is because the problem was discovered and fixed. Not that code was magically left out.
I was concerned about something different:
If a new update does bring forward an existing problem from previous updates, it is because the problem wasn't discovered (or acknowledged) and fixed.  Not that code was magically left out.
No matter, the walking away option isn't viable.
I didn't argue that WSUS isn't affordable - I didn't even mention it.  It's simply not in use at this point.  
And, using WSUS is a good suggestion.

(I'm still getting 30-day delay settings at the max for Quality updates.  Pause is separate of course.)

I believe that if we appear to disagree that it's not really disagreement, it's much more likely a matter of perspective.  
Your perspective is very different - and not without good reasons.
My perspective has been more "better is the enemy of good enough".  And, things have been "good enough".
So, while I may be conservative in analysis, it appears you're more conservative than I have been in practice.
Being more conservative in  practice is certainly food for thought.
So thanks for the comments!
0
 
Fred MarshallPrincipalAuthor Commented:
I am just writing some recommendations and a question occurs to me:

"Is there any way to know if an update is going to be "forced" or not?"
By this, I mean that one can Disable the Windows Update Service and apparently "skip" certain updates but not all updates?
(Whether that's a good idea or not is another matter).
At least this is borne out by recent history.
This appears to be what happened between KB4054517 and KB4088776.
KB4088776 changed the Windows Update service setting from Disabled to Manual and the update *was* installed.

Either KB4088776 was implemented with an intentionally NEW policy or it wasn't.  It was certainly different than its immediate predecessors.
So, either Disabling the Windows Update Service might effect delays longer than the 30-day Quality update setting for some updates, or it no longer will be able do that.
If it can, then what determines when the Windows Update Service will be re-Enabled to Manual?  How to find out?

It's good to know what one is working with....

On a more philosophical note:
David Johnson has seen no problems with any of the Windows updates.  I can believe that as I've seen the same good results in recent times on *some* computers at least.
Yet, folks suggest that updates must be tested before deployment.
Our experience and practices have relied on the same good results with reasonably good outcomes (until recently).

So, we didn't insist on testing and didn't control deployment and got away with it.
Testing and controlled deployment cost something but are a form of insurance.
I take it the consensus is: "comfort resulting from testing and controlled deployment are worth the effort - even though the test results are always OK for most computers".
If one is stuck, like I am, with computers that don't resemble "most computers" then pre-testing and controlled deployment is more important.  So I want to know as much as I can about the possibilities - as the environment changes sometimes quickly and sometimes slowly.
I get it that WSUS is a likely solution.
0
 
JohnBusiness Consultant (Owner)Commented:
By this, I mean that one can Disable the Windows Update Service and apparently "skip" certain updates but not all updates?

No. You can defer Feature updates for some days but not critical updates.

KB4088776 changed the Windows Update service setting from Disabled to Manual and the update *was* installed.

This keeps coming up "Updates can be disabled" when in fact they cannot be (not for any long term).

David Johnson has seen no problems with any of the Windows updates.


Neither have I on my machines or any big issue on any client machine.
0
 
Cliff GaliherCommented:
There are still things you can do to get closer to "most computers"  ...which results in more stable updating *and* less cost in testing updates.

1) Standardize your hardware.   Most business warranties are default 3 years, and can be extended to 5.  Depending on I.T. budget, you can play at either end, but I tend to land in the middle.  I recommend replacing 25% of the organization computers every year, meaning the oldest computer is 4 years old, and you get a 100% turnover in those 4 years.

2) Since you are buying computers in bulk with such a change, you can standardize.  90% of the computers can be the same make and model.  Then you standardize the rest as well. May be you need a few CAD workstations.  Make them all the same. Maybe you need laptops. Try to buy the same laptops.  You can usually boil down to between 1 and 3 models per year.  That means you have maybe 4 to 12 unique hardware combinations across 4 years.  Makes BIOS updates easier and updates that are hardware dependent more predictable.

3) Standardize your software installation.  Microsoft has had free image building software for decades.  MDT is perfectly functional.  It can install the OS in a known configuration, deploy drivers, and deploy software.  Again, if you don't have a machine with a ton of programs that were installed, uninstalled, every random download from the web introduced, you get a more stable system. Most updates that fail do so because the system was "crusty" with a bunch of junk from programs that don't clean up after themselves.

4) At a *minimum* don't let end users have admin privileges.  If you can move towards using app-locker to prevent even non-admin programs from running in an unauthorized way, even better.  There is a reason why iOS is considered a secure and stable OS, and it isn't because Apple's engineering is leaps and bounds better (it isn't...see the bugs in iOS 11 and the "bypass passwords" bugs in recent releases!)  It is that they don't have or allow 3rd-party programs to do whatever they want.  Microsoft needs to maintain backwards compatibility so they basically are at the mercy of those 3rd-parties.  But *you* don't have to be.

You can reduce patch testing to a few minutes, and staged deployments to power users to catch issues you don't catch.  Cost is near zero, without WSUS.  WSUS, of course, just adds more granular options and flexibility.
0
 
Fred MarshallPrincipalAuthor Commented:
Cliff Galiher:  Our issue with "most computers" is our key ASP software.  That's what makes them "unlike the others".  The rest of this is fairly well covered - except the hardware commonality.
0
 
Fred MarshallPrincipalAuthor Commented:
John Hurst:  All I can report is what I've observed.  

There was NO deferral or delay or pause set at all.
KB4056892 was hidden with wushowhide.
Windows Update service was Disabled.

Thereafter, KB4054517 was NOT installed nor any subsequent Quality updates UNTIL KB4088776.
So much for "cannot", eh?

This observation applies to a fair number of workstations.
0
 
JohnBusiness Consultant (Owner)Commented:
I have used wushowhide, but not for valid updates.
0
 
Fred MarshallPrincipalAuthor Commented:
I need to correct my observation:  

It appears that Windows Update service was set to Manual (i.e. normally enabled) on the set of computers that I based my observations on.  
So, even earlier updates may have been installed without being noticed.  In a way, a good thing as the troubles didn't fully recur.

And, for those computers with the Windows Update service Disabled, the updates didn't occur and the workstations remained at 16299.125 of December 2017.  So, my concern about things running amok was misguided.  It appears that Disabling the service does work - albeit not what one would want to do in a normal circumstance.

We are setting the Windows Update policies to defer and have initiated a testing protocol.
I have yet to figure out how to efficiently trigger "good" updates onto the population or to simply wait for 30 or 35 days.
Any ideas?

I had asked about 30 vs. 35 day deferral for Quality updates.  I note that on 1709, one can only set Quality updates to be deferred up to 30 days in the gpedit dialog.
But, 35 is the value that can be entered into the registry per:
https://docs.microsoft.com/en-us/windows/deployment/update/waas-configure-wufb.
Setting it in the registry at 35 seems to NOT be reflected in the gpedit dialog which remains at 30 (if set there).
0
 
Fred MarshallPrincipalAuthor Commented:
Thanks all!  While some of my initial observations were in error regarding what happened, the result of the discussion was VERY valuable!
0
 
JohnBusiness Consultant (Owner)Commented:
Thank you for the update and I was happy to help you and contribute here.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.