Archive

Posts Tagged ‘WindowsUpdate’

Update for Windows Update Client addresses ConfigMgr 2012 Update Scan Issue – Windowsupdate.log Error 8007000E

June 3, 2015 1 comment

Exclamation-iconYesterday Microsoft has released an update for the Windows Update client. This relates to the issue with Windows 7 and Software Updates which I blogged about a few weeks ago.

This is the KB article: Windows Update Client for Windows 7 : June 2015

Interesting: the KB Article mentions this update does not only address the out-of-memory issue but also contains general improvements made to support upgrades to a later version of windows.

If you have Windows 7 x86 clients in your environment the best approach would be to release this update in your environment as soon as possible. Important : you need to install the hardening update KB2938066 on your WSUS servers prior to releasing this update!

Hope it helps!

Tim

Advertisements

Update on the ConfigMgr 2012 Update Scan Issue – Windowsupdate.log Error 8007000E

April 16, 2015 1 comment

Last week Kim blogged about an issue with Windows 7 and Software Updates that some of his customers had been reporting.

Kim had already outlined the issue and the symptoms, plus also provided a few workarounds which may help in resolving it. Through this post I wanted to inform you that now Microsoft has published a blog post that:

a) gives some more details on the root cause of the problem

b) outlines some possible workarounds and

c) most importantly : states a hotfix is in the pipeline which will be available in (late) Q2

You can find the full details here.

I ran into the same issue at one of my customers last week and have been working with Microsoft support to get this resolved. Below you can read some findings and experiences from the past days.

The workaround to Move wuauserv (Windows Update Agent) to its own SVCHost.exe instance did not prove to be very successful. Although we saw the scan job succeeding on a few clients at first, after a few additional scans the issue returned.

Next step was cleaning up WSUS. First we needed to verify what we could potentially clean up using the script provided by Microsoft:

image

To get things back on the rails in the end the only successful method was to run WSUS cleanup script to decline all superseded updates. Running the script with the –DeclineLastLevelOnly switch was not sufficient.

Important: Before running this cleanup script make sure to identify if any of the updates are still needed! It could be a superseding update has not yet been released due to your internal approval and/or release processes!

And while you are checking that also note that the script output may be misleading. Set the LastLevel column filter to False if you are actually looking for the Last Level Superseded Updates.

clip_image001

Running the script itself took around 15 minutes.

Note: if you are running multiple SUPS in your environment you should only run this on one SUP – the one with Windows Update set as synchronization source.

Hope it helps!

Tim