Fixing Microsoft Updates on multiple workstations
TL;DR: Updates no work. WSUS no work. Direct from Microsoft no work. 8024002e error everywhere. 150 Windows 10 1607 workstations. Tried Troubleshooter and Manual fix for Updates, no work. Please help. Centralized solution needed. Can't fix 150 workstations' Updates individually.
--------------------------
For those who have an attention span greater than the half-life of Hydrogen-7:
Background:
I support about 150 workstations and laptops combined, all running Windows 10 1607. Through GP, we've always pointed people to our WSUS server, which has crashed/gotten corrupted at least three times. Once as V3 and twice as V4. The last time, instead of going through all the repairs, I just said f it and launched a new VM and re-set the thing up.
Last weekend my co-worker said WSUS was causing an 8024002e error (that VERY specific error with the thousand ways of fixing, and none of them work), so he turned off the GP and sent everyone straight to Microsoft. The pressing issue was getting the WillCry updates (which were released in March, I think).
That's the background. My problem is, when I started going around to workstations to confirm the updates were received, everything is inconsistent (when I say everything, I mean, a number of workstations I checked). Some reported KB4019472 was successfully installed. Others said it failed, but in history it was successful. Some had no Update History at all.
My question:
Is there a way to centrally fix this? I've run the Microsoft Update Troubleshooter with really no success. It's fixed nothing. Always fails when running as Administrator with 803C0103. Manual fix (stopping services, renaming SoftwareDistribution and Catroot2, etc.) doesn't work.
My fear is the corruption of WSUS screwed up Updates for the workstations, and now each is left in an inconsistent state. Refocusing them to get Updates directly from Microsoft works on some, doesn't work on others. Re-pointing them to WSUS just results immediately in the Update Failed 8024002e, "we'll try again later" error.
Any thoughts? Also, for my edification, have Updates been shaky since 8.1 was released? I swear I've had to run these fixes on my home machine at least three times in the last three years. Either Updates are less reliable than they ever have been, or I'm a terrible admin. And I wouldn't rule out being a terrible admin, I'm just saying...
Also, any suggestions on third party auditing software to inventory the updates each workstation has would be great. Spiceworks, for instance? Is that reliable? This assumes I'm not using WSUS until I clear this up. WSUS would give me an inventory, etc.
TIA,
Steve
--------------------------
For those who have an attention span greater than the half-life of Hydrogen-7:
Background:
I support about 150 workstations and laptops combined, all running Windows 10 1607. Through GP, we've always pointed people to our WSUS server, which has crashed/gotten corrupted at least three times. Once as V3 and twice as V4. The last time, instead of going through all the repairs, I just said f it and launched a new VM and re-set the thing up.
Last weekend my co-worker said WSUS was causing an 8024002e error (that VERY specific error with the thousand ways of fixing, and none of them work), so he turned off the GP and sent everyone straight to Microsoft. The pressing issue was getting the WillCry updates (which were released in March, I think).
That's the background. My problem is, when I started going around to workstations to confirm the updates were received, everything is inconsistent (when I say everything, I mean, a number of workstations I checked). Some reported KB4019472 was successfully installed. Others said it failed, but in history it was successful. Some had no Update History at all.
My question:
Is there a way to centrally fix this? I've run the Microsoft Update Troubleshooter with really no success. It's fixed nothing. Always fails when running as Administrator with 803C0103. Manual fix (stopping services, renaming SoftwareDistribution and Catroot2, etc.) doesn't work.
My fear is the corruption of WSUS screwed up Updates for the workstations, and now each is left in an inconsistent state. Refocusing them to get Updates directly from Microsoft works on some, doesn't work on others. Re-pointing them to WSUS just results immediately in the Update Failed 8024002e, "we'll try again later" error.
Any thoughts? Also, for my edification, have Updates been shaky since 8.1 was released? I swear I've had to run these fixes on my home machine at least three times in the last three years. Either Updates are less reliable than they ever have been, or I'm a terrible admin. And I wouldn't rule out being a terrible admin, I'm just saying...
Also, any suggestions on third party auditing software to inventory the updates each workstation has would be great. Spiceworks, for instance? Is that reliable? This assumes I'm not using WSUS until I clear this up. WSUS would give me an inventory, etc.
TIA,
Steve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Please note that Win10 v1607 (anniversay Update) has a bug with WSUS. You need at least a patch from a few month after its release (september, october 16?) installed manually for it in order to work with WSUS. It might be that this 8024002e was even the errorcode that one receives.
ASKER
Oh geez, figures. MS has often had to correct an update with another update. Thanks, that's probably the issue. I'll google it.
Oh, and I just pushed the reg changes through GP, so that's that. Thank you!
Oh, and I just pushed the reg changes through GP, so that's that. Thank you!
ASKER
I applied the registry fix, and will check for the 1607 Update bug patch.
Just apply the latest cumulative update for 1607, no need to search for the first patch that fixed it - any newer cumulative update will do.
ASKER
Correct, it was the fact that the latest update seemed to be failing to install on random workstations, so I didn't know a) how to identify which workstations failed and b) how to install it since it failed. I have the actual file, but what I've done is changed the GP to point everyone back to WSUS. I'm hoping that by getting the update directly from MS it fixed the WSUS issue (for the workstations where it didn't fail.) But then I could use deductive reasoning to figure out the workstations that failed, since they would be on either the failure report or not on the report at all.
I really appreciate the suggestions!
I really appreciate the suggestions!
ASKER
So, yes, in testing WSUS again, I immediately get the 8024002e error, even on workstations that have the latest (or at least a CU) after September. I am trying manually, by hitting "Retry" on the Update screen, but I think the result is the same if they try to communicate automatically with WSUS. This is the issue that's killing me, because the fixes for 8024002e are vast and rarely work. And they're not trivial...The Microsoft Update Troubleshooter Wizard also has failed on every computer I've tried running it. Phhhhhhhhhhht
Consider upgrading one to v1703 for a test.
ASKER
I may. Case in point, just had a user drop off a laptop that has been off-network and last update was April 25. Great! A fresh, uncorrupted laptop to work on. It got one definition update, then the rest failed. It got the GP and pointed to WSUS and failed with that same error. Then I tried manually installing the 4019472 msu. It ran through the installation...but failed. The "Update Cleanup Troubleshooter" failed for both normal run and Administrator run.
This is what I'm dealing with. This is the first time such widespread failures are occurring. Under WSUS with Windows 7, rarely had a problem until the server's database corrupted (yet another issue.) Sorry for venting, this is incredibly frustrating. I'll use myself as a guinea workstation for 1703.
This is what I'm dealing with. This is the first time such widespread failures are occurring. Under WSUS with Windows 7, rarely had a problem until the server's database corrupted (yet another issue.) Sorry for venting, this is incredibly frustrating. I'll use myself as a guinea workstation for 1703.
ASKER
The WSUS install is a brand new deployment. I just set it up and sync'd it two weeks ago. Yet workstations are still shooting back 8024002e when forced to update from it. With the caveat that, this is what my co-worker told me when I was out last week, so I'm taking their word. It may only be happening on a couple of machines, but you know how a couple turns into "everyone."
I guess if I point them back to WSUS, I would then be able to at least run a report. I have no real way of auditing if they're just grabbing them from MS.