Follow-up on problem 0x8007000E

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

SELECT
  rs.Name0 as ‘Name’, SUM(ucs.status) as ‘Num updates’
FROM
  v_R_System rs
left join
  v_UpdateComplianceStatus UCS
    on ucs.ResourceID = rs.ResourceID
left join 
  BGB_ResStatus BGB
    on rs.ResourceID = BGB.ResourceID
where
  rs.Client0 = 1
group by
  rs.Name0
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.

Advertisements
This entry was posted in Configuration Manager and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s