As I wrote about on March 19 (https://larsnorman.wordpress.com/2015/03/19/windows-update-agent-returning-0x8007000e/) I have been having issues with incorrrect scans for security updates which can be traced down to an out-of-memory condition in the Windows Update Agent.
A large number of people have been in touch telling me about how they have the samme issue and things they have tried. And at the same time I have been busy trying to find a workable solution.
To see how many machines are impacted at a given time (and to find machines that can examined in more detail) you can use the following query
rs.Name0 as ‘Name’, SUM(ucs.status) as ‘Num updates’
on ucs.ResourceID = rs.ResourceID
on rs.ResourceID = BGB.ResourceID
rs.Client0 = 1
having COUNT(UCS.Status) = 0
order by rs.Name0
(the join with BGB is in so I can filter on machines that are currently online)
I have now seen massive improvement following two steps:
1. Decline updates marked as superseded in the WSUS database. See the process described here: http://www.tecknowledgebase.com/43/how-to-identify-and-decline-superseded-updates-in-wsus/ (thanks Mark!). Please note that running the WSUS Cleanup Wizard is not enough.
2. Change the WUAUServ service to run in its own memoryspace by running sc config wuauserv type= own After configuring the service you should restart the service. Note the discussion on failed scans below.
A few notes of interest. Declining the updates in WSUS must be performed at all your WSUS servers, including WSUS on CAS, secondary sites and any WSUS servers for redundancy or locatated on DMZs to provide access for IBCM machines. I ran the WSUS Cleanup Wizard post decline. Also while you are at it you could consider cleaning out updates for any OSes you do not longer support.
A noticed a sharp increase in load on WSUS servers post cleanup. The size of the daily IIS log file for WSUS was larger.
Also the WUAUServ (Windows Update Agent) service would still consume 1.1 – 1.3 GB of RAM on the 32bit clients so in reality the problem is only postponed until Microsoft releases a real update (which I was told by a number of contacts is forthcoming).
Approx. 5% of the machines I tested on would fail the scan with the same error code.
In testing I noticed that a number of machines would report back a failed scan when I configured the Windows Update Agent service and restarted it. So I have decided to only configure the service and wait for a restart. If you are not concerned about the scan statistics you should restart the service right away.