Windows Update Agent returning 0x8007000E

I have lately been working on an issue where Configuration Manager 2012R2 is reporting a large number of machines with a status of unknown for various updates. I have narrowed down the issue to an out-of-memory condition in Windows Update agent (as seen in WindowsUpdate.log). Here you will see something like

ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

The same error can be found in various other Configuration Manager 2012 logs.

I have an open case with Microsoft PSS on this issue and is hoping for a fix soon. The problem is only seen on x86 based systems (mine are all Windows 7, but I assume the problem could hit Windows 8/8.1 as well). Note that the issue is all about the size of the catalog – not the number of updates per deployment or number of deployments.

A few things that has helped a bit:

1. Applying the latest version of the Windows Update Agent (from The new agent initially looked like it fixed the problem but now we are experiencing the problem again.

2. Running the WUAUServ service in it’s own svchost.exe process

net stop wuauserv

sc config wuauserv type= own

net start wuauser

But the real solution is to contact Microsoft and make sure they are aware of this issue

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

6 Responses to Windows Update Agent returning 0x8007000E

  1. Dan Brooklands says:

    We are also experiencing the same issue with a small percentage of our clients. A couple of members also have a case open with Microsoft. See the following technet article for more info:

  2. Henry E. Wilson says:

    WOW Too funny – I’m on a PSS call now for this! I have WUA 7.6.7600.256 on Windows 7 sp1 and a significant number of systems (x86) are having this issue – Could it have been introduced by Microsoft in a recent catalog update?

  3. Dan Brooklands says:

    Hey everyone, the problem is now resolved in our environment. As others have pointed out, cleaning out the WSUS or SCCM software updates (in our case) did the trick. For us, cleaning out all expired updates and forcing a full SUP synchronization resulted in the problem devices to successfully scan for updates and not receive the 8007000E error. On the affected clients, I was able to run a Software Updates Scan Cycle, a Software Deployment Evaluation Cycle, and verified through the logs that there are now actionable updates to be installed. The ccmcache folder also started populating with the required updates. If all goes well, we will see patches installed during tonight’s maintenance window.

    Here is a link to the site with the steps taken to resolve the issue:

    Thanks for all of the feedback and suggestions! I hope you all get this resolved.


  4. Pingback: Follow-up on problem 0x8007000E | Lars Norman Søndergaard

  5. Hey there. For what it’s worth I recently wrote a quick post after encountering this error. I don’t know if it is bad blogettiqute to link to my own, but it does contain links to a server side and client side from Microsoft:

    Rash o/

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s