none
Some Clients Not Updating. Reporting "Compliant." hr=8007000E Error in WindowsUpdate.log

    Question

  • I have a significant number (but not all) of my SCCM 2012 R2 CU3 clients not updating though my SCCM software updates. On these problem clients, I get this error in WindowsUpdate.log:

    "COMAPI WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E"

    Then these machines report "Compliant" even though they don't install the updates. Almost all of our workstations are Windows 7 SP1 32bit. We are running SCCM 2012 R2 CU3. My site servers are running Windows 2008 R2.

    I don't see much in WUAhandler.log or scanagent.log. These client are however, getting my SCEP definition updates just fine. (I have an ADR for those.) And when you go out to Microsoft for security updates it works. I have tried all of the usual Windows Updates repair suggestions (re-register dlls, rename software distribution folder, etc.) And I tried un-installing and re-installing the SCCM client on a problem PC, to no avail. I also tried using a Software Update Group with fewer updates (<100) and targeting a problem system with only that SUG, to no avail.

    Any assistance would be greatly appreciated. Thank you.

    Tuesday, March 17, 2015 3:33 PM

All replies

  • I think this is a new issue that's cropped up with Windows 7 (has nothing to do with ConfigMgr) because the size of the update catalogs has grown so much recently. You should contact Microsoft support to see if they have a fix available.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, March 17, 2015 4:17 PM
  • The same exact thing is happening in our environment right now and it has very frustrating.  Only Windows 7 (x86) machines.  This started happening with the February round of patches.  MS had us run a batch file (this one).

    Net stop wuauserv
    Sc config wuauserv type= own
    Net start wuauserv


    This is apparently supposed to stop some kind of memory leak issue for Windows 7 machines.

    This seemed to remedy the issue with the February round of patches but this occurred again with March patches.  We tried re-running the batch file on the environment and we had the same mixed results.

    We have an open call with MS regarding this issue.  If anyone has heard of any remedy for this issue it would be greatly appreciated.

    Thank you!

    Tuesday, March 17, 2015 7:30 PM
  • We have an open call with MS regarding this issue.  If anyone has heard of any remedy for this issue it would be greatly appreciated.

    We are also on CM12R2CU3 and seeing this too, but so far only on "resource constrained" computers.

    If you have the prem case #, I can reference that to my prem case, and lay some +1 action on those MSFT guys...


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, March 18, 2015 2:49 AM
  • Same problem for us. We have about 100 computers of 600 managed by SCCM2012R2CU4 who no longer report Updates to SCCM. No problem with x64 computers. dotNet452 has been deployed. can this be an issue ?. Any clue ? Thx!
    Wednesday, March 18, 2015 11:29 AM
  • No, as mentioned, this is a Windows 7 issue/bug (and only x86 at that). For now, you either need to wait for Microsoft to resolve it and/or open a support case so that they can help you directly.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Wednesday, March 18, 2015 1:43 PM
  • Thanks everyone. I have had some success with running sfc /scannow on problem workstations and then getting updates to work. I will test out the batch file idea from Microsoft- thanks!

    If you guys hear anything else from Microsoft, please let me know! Thanks.

    Wednesday, March 18, 2015 6:21 PM
  • Hi all,

    We are also experiencing the same issue on a small percentage of PC's in our environment.  The problem seems to have started this month (March).  On one of the problem machines, I was successfully able to run Windows Updates manually, which tells me the problem does not seem to be related to the Windows Update agent.  Weird thing is SCCM states the machines are "Compliant", when they are really not.

    Looking at the WindowsUpdate.log file, I see the following errors:

    WARNING: PopulateDataStore failed: 0x8007000e

    WARNING: Sync of Updates: 0x8007000e

    WARNING: SyncServerUpdatesInternal failed: 0x8007000e

    COMAPI WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

    I've tried the suggested fixes mentioned in this article, un-installed/re-installed the SCCM client, repaired WMI, to no avail.

    UpdatesDeployment.log states EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = 0 although there are at least 18 updates really needed.

    WUAHandler.log states OnSearchComplete - Failed to end search job. Error = 0x8007000e. and Scan failed with error = 0x8007000e.

    I've seen several articles that state Microsoft is looking in to the issue, so I want to add our problem to the growing list of people that are also experiencing the same problem.

    Our environment is CM2012 SP1 CU3.  Clients are mostly Win 7 Pro SP1 - x86.

    Hopefully Microsoft will have a fix for this soon.

    Thursday, March 19, 2015 11:31 PM
  • I can reference that to my prem case, and lay some +1 action on those MSFT guys...

    So, my prem case has taken an interesting direction...

    The diagnostic has paused at the moment, whilst we determine/confirm "health" of our SUP/WSUS.
    Apparently the possible lack of "routine maintenance activity" on WSUS (server cleanup wizard, SUSDB reindexing, etc) and the updating of WUAgent to latest versions on clients, is indicated. I'm not yet sure of the direct relevance of these things, but it suggests to me that some kind of "excessive cruft" is either suspected, or, maybe a tolerance/threshold has been reached..

    I had been wondering for a while, if the WSUS layer of SUP might require some TLC, and maybe slower_client_machines + clogged_WSUS = timeout/crash/bang...

    /justwondering/notconfirmed/ohdear/


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, March 20, 2015 7:51 AM
  • Hi

    any good news from Ms? I tried your suggested batch file  and it worked fine for me.

    thanks

    Friday, March 20, 2015 8:24 AM
  • Add me to the list!

    About 50% of Our Windows 7 SP1 x86 Clients have this error (WindowsUpdate.log: "COMAPI WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E").

    Have tried a number of Things, including cleaning WSUS, updating latest WSUS server patch and Client agent (7.6.7600.320).

    The only thing that Works is the batch script posted here. Unfortunately, after a reboot and you run a Update Scan on the client again you get the same error message in WindowsUpdate.log and you will not se any updates available.

    We need a permanent fix for this!

    Friday, March 20, 2015 2:51 PM
  • Ok, I'll try and explain this the best I can.  We have finally had success and it was accomplished by essentially grooming the WSUS catalog.  From the explanation I got, Windows 7 (x86) machines are restricted to 4GB of memory.  The process that takes place when the update sync runs is blowing out causing this error to occur.  The catalog has just gotten too big over time.  That's why 64 bit and Servers are not having this issue.

    The first thing you should do is to successfully run the WSUS cleanup wizard. Run them one at a time.  If you have not run this in awhile or anytime at all it will possibly disconnect you from the server during the "Unused updates and update revision" job.  This will cause you to lose your mind, especially if you thousands of unused updates in the database.  We got past this by manually removing the 1st record from the database using the SQL command that you can find all over the internet shown here:

    USE SUSDB
    GO
    exec spGetObsoleteUpdatesToCleanup

    and

    USE SUSDB
    GOexec spDeleteUpdate @localUpdateID=000000

    Replace 000000 with the Update ID

    If this doesn't work, you need to reindex the SUSDB database in the SQL Management Studio.  Make sure that the options are set so that the Index is being rebuilt.

    After a successful run (it could take hours), open up the WSUS Console and decline all Superceded Updates.  This article explain how to do it. 

    http://www.tecknowledgebase.com/43/how-to-identify-and-decline-superseded-updates-in-wsus/ 

    Follow the instructions step by step.  We didn't do the Optional one.

    Make sure you only declining the Superceded Updates that the article is telling you.  There should only be two kinds.  They look like some symbol that Quaid would use to start the reactor on Mars.

    This literally cut the size of the catalog that was being presented to our environment in half.  After this, we Synchronized the Software Updates in the SCCM console and ran a batch file that restarted the Windows Update Service on all the Windows 7 (x86) machines.

    Net stop wuauserv
    Net start wuauserv

    You can also accomplish this by rebooting the machines.

    Anyway, that's what worked for us.  We'll see how the April round of patches goes, but it looks like the WSUS DB as well as the Catalog will have to be better maintained as the catalog will eventually grow again.

    Good luck!

    Andrew

    Friday, March 20, 2015 9:37 PM
  • Ok, I'll try and explain this the best I can.  We have finally had success and it was accomplished by essentially grooming the WSUS catalog.  From the explanation I got, Windows 7 (x86) machines are restricted to 4GB of memory.  The process that takes place when the update sync runs is blowing out causing this error to occur.  The catalog has just gotten too big over time.  That's why 64 bit and Servers are not having this issue.

    The first thing you should do is to successfully run the WSUS cleanup wizard. Run them one at a time.  If you have not run this in awhile or anytime at all it will possibly disconnect you from the server during the "Unused updates and update revision" job.  This will cause you to lose your mind, especially if you thousands of unused updates in the database.  We got past this by manually removing the 1st record from the database using the SQL command that you can find all over the internet shown here:

    USE SUSDB
    GO
    exec spGetObsoleteUpdatesToCleanup

    and

    USE SUSDB
    GOexec spDeleteUpdate @localUpdateID=000000

    Replace 000000 with the Update ID

    If this doesn't work, you need to reindex the SUSDB database in the SQL Management Studio.  Make sure that the options are set so that the Index is being rebuilt.

    After a successful run (it could take hours), open up the WSUS Console and decline all Superceded Updates.  This article explain how to do it. 

    http://www.tecknowledgebase.com/43/how-to-identify-and-decline-superseded-updates-in-wsus/ 

    Follow the instructions step by step.  We didn't do the Optional one.

    Make sure you only declining the Superceded Updates that the article is telling you.  There should only be two kinds.  They look like some symbol that Quaid would use to start the reactor on Mars.

    This literally cut the size of the catalog that was being presented to our environment in half.  After this, we Synchronized the Software Updates in the SCCM console and ran a batch file that restarted the Windows Update Service on all the Windows 7 (x86) machines.

    Net stop wuauserv
    Net start wuauserv

    You can also accomplish this by rebooting the machines.

    Anyway, that's what worked for us.  We'll see how the April round of patches goes, but it looks like the WSUS DB as well as the Catalog will have to be better maintained as the catalog will eventually grow again.

    Good luck!

    Andrew

    Hi Andrew,

    Thanks for posting this fix up.  I tried the steps on our SCCM 2012 SP1 server (has WSUS role).  I selected 2 updates with the blue square in the middle, declined them, then performed the Server Cleanup Wizard.  After performing the wizard, there was nothing deleted or removed, so I'm not sure if this applies to SCCM or only standalone WSUS servers. 

    How can you determine the size of the WSUS catalog?  Is it by the amount of updates?

    Thanks in advance,

    Dan

    Friday, March 20, 2015 11:08 PM
  • declined them

    Why would you decline updates? Not only is that not in the instructions above, but its totally unsupported to this from a ConfigMgr perspective.

    Everything outlined above is for WSUS and has nothing directly to do with ConfigMgr.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Saturday, March 21, 2015 8:21 PM
  • During patch testing, our company ran into this last week on some of our 5 year old Windows 7 x86 machines. We are running Configuration Manager 2012 CU4.

    As others have mentioned, when monitoring the deployment it showed that the problem computers were compliant with patches but it turned out they were not.

    I suspected an issue with WMI as rebuilding WMI fixed the issue on a test computer.

    For many reasons I did not want to rebuild WMI on machines so I kept digging. I found that if you install hotfix KB2692929, this will fix the issue and Software Updates will start coming back down again. https://support.microsoft.com/en-us/kb/2692929

    To combat this issue we are targeting a silent installation of KB2692929 on Windows 7 x86 computers, suppressing the reboot and a week later will roll out our monthly updates.

    I also discovered that an Enterprise rollup is available that includes KB2692929 and about 90 other hotfixes specific to enterprises. https://support.microsoft.com/en-us/kb/2775511

    This rollup is interesting and you may choose to roll this out instead.

    Hope this helps,

    Dave


    • Edited by dknoll Monday, March 23, 2015 12:04 PM bad formatting again
    Monday, March 23, 2015 11:55 AM
  • I also discovered that an Enterprise rollup is available that includes KB2692929 and about 90 other hotfixes specific to enterprises. https://support.microsoft.com/en-us/kb/2775511

    This rollup is interesting and you may choose to roll this out instead.


    We rolled out this rollup KB2775511 quite some time ago, and we're having this problem.

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Monday, March 23, 2015 7:58 PM
  • So for our case, the SCW in WSUS ran once, cleaned up some stuff, then on successive re-runs, times out every time after 2 minutes. We're now running the other steps provided by our case engineer;
    Ran the SUSDB reindex/defrag via SSMS.
    Ran the spGetObsoleteUpdatesToCleanup via SSMS
    [
    which revealed 3721 obsolete updates in WSUS.]

    and

    spDeleteUpdate @localUpdateID=<first updateID from above>

    Ran the [delete all obsolete updates query, provided by engineer] (several times, since it also times out, but it's nibbling away at the problem at about 1000 deletes per run, each run takes a couple of hours)

    I'll check again this morning when I get in to the office to see where it's up to.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)



    • Edited by DonPick Tuesday, March 24, 2015 9:23 AM fix typo
    Monday, March 23, 2015 8:12 PM
  • I started testing next months patches this afternoon and noticed the COMAPI WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E issue has returned for our environment. Keeping tabs on this thread for a hopeful resolution.

    Monday, March 23, 2015 9:15 PM
  • Update:  This issue seems to be growing in our environment.  When I check the monitoring status for our March 2015 MS patch deployment, checking the Compliant tab, I noticed a pattern for the devices that are reporting a "false patch state".  When you right click on the device, click "More Details", then select the "Software Updates" tab.  Normally, there will be patches listed with the Article ID, Bulletin ID, Title, etc.  The devices encountering the issue will have nothing displayed in the tab, which can be verified by checking the WindowsUpdate.log file.

    I also tried the suggestion "dknoll" suggested and installed the KB2692929 hotfix, rebooted, and performed a Software Updates Scan.  Ended up with the same results.  I also installed the KB2775511 roll up package, rebooted, and performed a Software Updates Scan, ending up with the same results as well.  I performed a WMI repair on an affected device, but that did not do the trick either.

    At this point, I'm hoping Microsoft releases a fix soon as the number of false compliant devices is growing.

    Monday, March 23, 2015 10:34 PM
  • Cleaning WSUS seems to do the trick (+decline expired updates).

    On our WindowsUpdate.log files, updates count drop from 432 to 279 and the getupdatemetadata2 disappears.

    however, you need to restart the Windows update service on the client. On some computers, it seems necessary to even restart the computer.

    I had also to validate Software Update Point Components Properties box in Site Configuration/Site/Configure Site Component/Software Update Point because new published updates were not detected by the client.

    Tuesday, March 24, 2015 8:32 AM
  • 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:  http://blogs.technet.com/b/configmgrteam/archive/2012/04/12/software-update-content-cleanup-in-system-center-2012-configuration-manager.aspx

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

    Dan

    Tuesday, March 24, 2015 9:54 PM

  • Here is a link to the site with the steps taken to resolve the issue:  http://blogs.technet.com/b/configmgrteam/archive/2012/04/12/software-update-content-cleanup-in-system-center-2012-configuration-manager.aspx


    Just a site note: the script is no longer needed when using CM12 R2. 

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, March 25, 2015 6:55 AM
  • This console extension is probably easier to use: https://gallery.technet.microsoft.com/Clean-Software-Update-5ae68ba2#content

    Check it out, works well!

    Frode

    Wednesday, March 25, 2015 12:06 PM
  • I must have spoke too soon. The problem re-appeared. Back to the drawing board...
    Wednesday, March 25, 2015 3:51 PM
  • Does anyone have any additional updates on this issue?  Did you guys end up finding a fix or are you still having issues?
    Thursday, March 26, 2015 1:58 AM
  • Does anyone have any additional updates on this issue?  Did you guys end up finding a fix or are you still having issues?

    we are still working through the various cleanup tasks.

    some of our estate is fine (detecting/reporting/updating/reporting), and some, is barfing with the 8007000E error.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, March 26, 2015 7:56 AM
  • We are experiencing the same problem in a freshly installed 2012 R2 (on Server 2012 R2). Clients: W7 SP1 x86.

    Clients are having problems during OSD and after the OS installation has been completed. (Offline servicing of an image is working fine. Currently no x64 clients available for testing.)

    Working on a solution now; first attempt will be to try the console extension as suggested by Frode. Will post update if succesful.

    Edit: I can confirm that our environment works with W8.1 x64 clients; still waiting for the results from the removal. The console extension itself seems to work fine; it said it removed 224 updates.

    Edit 27/3:

    Used the console extension to remove the expired and superseded updates. Did a full (scheduled) sync and ran the automatic deployment rule. Still no succes.

    • Edited by Davey400 Friday, March 27, 2015 8:16 AM
    Thursday, March 26, 2015 9:04 AM
  • Thanks for the feedback, makes me feel a little better now that I'm not the only one pulling my hair out!

    I found this article from Kent Agerlund that I'll try on our lab server today.  If all goes well, I'll move forward with our production server.  I'll report my findings later on.

    http://blog.coretech.dk/kea/house-of-cardsthe-configmgr-software-update-point-and-wsus/

    Thursday, March 26, 2015 4:04 PM
  • Thanks for the feedback, makes me feel a little better now that I'm not the only one pulling my hair out!

    I found this article from Kent Agerlund that I'll try on our lab server today.  If all goes well, I'll move forward with our production server.  I'll report my findings later on.

    http://blog.coretech.dk/kea/house-of-cardsthe-configmgr-software-update-point-and-wsus/

    Kent's article is a good one. It refers to much the same steps as we've all been trying, and, it all matches with the steps provided to use by premier engineer for our case so far.

    we were  re-running the cleanup tasks again last night, so I will check again when I get to the office this morning.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, March 26, 2015 8:09 PM
  • we were  re-running the cleanup tasks again last night, so I will check again when I get to the office this morning.


    sadly, when I checked this morning, the cleanup task had yet again timed out.

    So I re-ran all cleanup tasks, in sequence, and this time they all ran successfully (and quickly), so, it seems the cleanup has achieved a nice tidy SUSDB, but, clients are still randomly timing out with 8007000E errors ...

    I've also performed the ConfigMgr cleanup "remove all expired updates from SUGs", and am now starting the SUSDB cleanup of our single secondary site server/SUP/DSS. (but I have a feeling that isn't going to make a difference to the issues we see on primary site clients..)

    prem case updated with this process of elimination, and back to waiting for the next set of suggestions from MSFT.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, March 27, 2015 9:33 AM
  • Today we did perform a removal of the SUP role, followed by a de-install of WSUS, and a database cleanup.

    After a reboot we re-installed WSUS and added the SUP role again. This time we only selected 'critical updates'.

    The client now seems to work fine; it is not reporting any errors. However, since we already applied all of these critical updates by letting ConfigMgr edit the wim-file we use, none of the currently available updates are applicable.

    Later this afternoon we added 'security updates' as well; unfortunately this process is taking a long time. We will let the PSS stabilize itself during the weekend, and will perform some new tests next Monday. (It's not that I am not curious enough; but we have to leave the building. ;) )

    Regards and good luck,

    Dave

     
    Friday, March 27, 2015 4:15 PM
  • I deployed that batch file from Microsoft that ufcandrew posted, to all our Win7x86 clients . And I also worked for days on performing the various SUP/WSUS server database cleanup type tasks that have been discussed here, and elsewhere. So far, those interventions have made a significant difference, as many more clients have patched successfully.

    I'm curious to see how the April updates will go!

    Thanks.

    Friday, March 27, 2015 8:54 PM
  • we were  re-running the cleanup tasks again last night, so I will check again when I get to the office this morning.


    sadly, when I checked this morning, the cleanup task had yet again timed out.

    So I re-ran all cleanup tasks, in sequence, and this time they all ran successfully (and quickly), so, it seems the cleanup has achieved a nice tidy SUSDB, but, clients are still randomly timing out with 8007000E errors ...

    I've also performed the ConfigMgr cleanup "remove all expired updates from SUGs", and am now starting the SUSDB cleanup of our single secondary site server/SUP/DSS. (but I have a feeling that isn't going to make a difference to the issues we see on primary site clients..)

    prem case updated with this process of elimination, and back to waiting for the next set of suggestions from MSFT.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    I also have the same results to report.  Cleaned up all obsolete, expired, superseded updates, and the rest of the Server Cleanup Wizard options, and verified the SUSDB is clean, but we still have some devices that are returning 8007000E error. 

    It seems like the machines (x86) that have "Updates found" of more than 300 updates are encountering this issue.  We have many machines (x86) with "Updates found" of around 200 updates, that do not suffer from this issue.

    Hopefully Microsoft will have a permanent fix soon.

    Friday, March 27, 2015 11:31 PM
  • What a great way to start the week:

    The re-install we did last Friday (and the stabilize period during the weekend) seemed to have done the trick.

    Updates are working now; both for running systems (x86) and during OSD (x86).

    For now we will not be syncing any additional update-categories or products, until a real fix is available.

    Good luck to you all!

    Dave

    Monday, March 30, 2015 7:05 AM
  • Hi all,

    One of the bigger nuissances of this particular bug is that it's hard to identify from a central location that you've fallen victim to it. Without spot-checking client machines you'd be none-the-wiser. This most likely results in a lot of shops out their thar are completely unaware they have a security issue with a false sense of "fully patched" security.

    I've create the following guidelines to identify whether you are indeed one of the victims.

    1. create a script configuration item.
    2. Select All Windows 7 32 bit as the supported platform
    3. Use String as the data type
    4. Choose powershell as your script language of choice
    5. Paste the following text in the discovery script:select-string-pattern'GetWARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E'-path"$env:windir\windowsupdate.log"
    6. Add the configuration item to a Configuration baseline
    7. Deploy the configuration baseline to All Windows 7 32bit machines
    8. The report list of assets by compliance state for a given baseline is a good report to check the results.
    9. !!!! Any machines reporting compliant to this baseline have a serious issue as they won't install any software updates, yet report compliant on all !!!!

    Good luck

    Monday, March 30, 2015 3:28 PM
  • I have the same problem with my Win 7 and Win 8 x86 clients.

    The message I get in windowsupdate.log is "Update is not allowed to download due to service regulation or download size limit"

    Getupdatemetadata3 failed, hr=8007000E

    I have seen some scripts to purge the sccm database for expired updates and remove them from the distribution point, so will try that after removing them from the SUG.


    Jaz

    Monday, March 30, 2015 3:32 PM
  • The message I get in windowsupdate.log is "Update is not allowed to download due to service regulation or download size limit"

    I've only ever seen that message occur when communicating with MicrosoftUpdate.com, since ConfigMgr doesn't implement regulation within WUAgent. Are you sure that message is related?

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Monday, March 30, 2015 8:01 PM
  • Don,

    That is the message in the windowsupdate log, and this is just happening on the x86 machines, the x64 are fine.

    Everything looks fine on the x86 machines apart from it wont pull down any updates, and the windowsupdate log also has references to Microsoft update sites (doesn't look the same as a x64 log). I will raise a new problem, but the info on this question looked very similar, and it does sound like a bug.

    I have reinstalled the client a few times and looked at wmi, wuau commands etc, but I'm going round in circles. I did remove a few expired updates last month and a couple of the x86 machines I was looking at suddenly started to download their updates, so it did seem to be size related. However, all the rest of the x86 machines are not pulling down their updates.


    Jaz

    Monday, March 30, 2015 10:22 PM
  • Hi, we are also experienced this issue with clients reporting as compliant when no updates have been applied. Looking in windowsupdate.log the clients are reporting the error  ISusInternal::GetUpdateMetadata2 failed, hr=8007000E.

    I have used the powershell script to clean all software update groups of expired and superceded updates and also run the clean process on the SUSDB last night. This cleaned out about 3000 updates and took about 4hrs to run. A full synchronisation has occurred overnight.

    However looking at clients this morning they are still reporting the error 800700E, I'll send out the baseline Kim has detailed above to see how many machines are affected.

    However looking at our current compliance level, its going to be a lot of machines.

    Monday, March 30, 2015 10:32 PM
  • no resolution as yet for us.
    further recommendations from prem engineer today: decline a heap of superseded/unapproved updates directly within WSUS (not in ConfigMgr) on our SUP.
    Ok then, sure. That's one way to cull the list, I guess.
    So I've attacked it with the Decline button.
    Let's see what happens.

    I'm also going to give that DCM baseline a try, to try and get a handle on the scope/size of this on our fleet.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, March 31, 2015 8:11 AM
  • Update:

    We did seem to have a working solution after the re-install of WSUS and selecting a smaller amount of updates.

    However: Installing updates during OSD deployment does not seem to be reliable.

    The task-sequences (both x86 and x64) sometimes fail to install updates with the good old 'Exceeded max server round trips: 0x80244010'.

    Exceeding the maximum number of round trips is an issue that I have not seen since the last years of the XP era. We did try to use the fix that worked back then, by setting the value for MaxXMLPerRequest in de WSUS database to 0. This entry still exists in the WID that we are using here, and yesterday it did look like changing this value fixed the round trip issue.

    But it did not.

    We seem to be in a situation where Software Updates work. Sometimes.

    Wednesday, April 01, 2015 10:18 AM
  • Thanks for the CI idea, Kim! That helps.
    Wednesday, April 01, 2015 5:48 PM
  • Hi to give an update, I've cleaned out all the SUG's on all expired and superseded updates using the TechNet script (great script). However this made no difference.

    We have now declined all superseded updates directly in WSUS to reduce the size of the catalog and synched to SCCM.

    Following this some clients have begun to scan without errors and install missing updates. I don't know if this has resoled the issue for all machines or for a subset at this stage but its definitely helping.

    Wednesday, April 01, 2015 11:25 PM
  • Hello,

    In our enviroment this problem first surfaced because the System Center Endpoint Protection (SCEP) definition files stopped installing on Windows 7 x86. Only after a week of research we discovered all other WSUS updates had also stopped installing. This was not clearly visible because the updates scan reported "Compliant".

    Following the advice in this article, which was also given by our Microsoft Support Engineer we performed several steps, none giving a full solution but each resulting in some improvement.

    1. Clean up WSUS
    2. Index the WSUS database
    3. Set the Windows Update Service on clients to run in its own SVCHost process withthe command "sc config wuauserv type= own" after stopping the Windows update service.
    4. If possible reduce the number of products for which updates are synchronised in WSUS to reduce the total number of imported updates. Deselecting unused products should be considered.

    Because we had serious problems with SCEP, which uses the Windows Update Service, we were advised to enable updates through an UNC path. This can be set in the Antimalware Policies in SCCM. This update method should be set as first or only update mechanism for SCEP. Directly after this modification SCEP definitions started installing on all clients, raising the percentage of online systems with current definitions from 44% to 87% in a few hours time. UNC path updating is the only update method not relying on the malfunctioning Windows Update service. This is only advised as a temporary solution untill the Windows update mechanism is repaired.

    The Microsoft support technician confirmed there is an error in the Windows Update service which causes the service to run out of memory during the update scan if the number of updates is too large. Currently the issue is only reported on X86 systems. If and when the error occurs in an environment is unpredictable and highly dependend on the WSUS maintenance, the number of updates to scan, installed products on a system (less products = less updates). Microsoft is working on a patch to fix this issue but doesn't expect to publish it on or before next patch Tuesday.

    To set the Windows update service to run in it's own svchost process and thus make some extra memory available for the upates scan we performed the following steps. Warning after doing this we've seen the Windows Update service temporarily peaking at 25% CPU and 780MB memory on a Windows 7 x86 client.

    Create a batch script with the following content:

    Net stop wuauserv
    Sc config wuauserv type= own
    Net start wuauserv

    Create an SCCM application which runs the batch script.

    As detection method we used the registry value which is modified with the above command:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wuauserv

    The registry value "Type" will be set to 16 after performing this operation (32 before).


    Thursday, April 02, 2015 7:08 PM
  • Hello, has anyone had any more luck with this issue?
    Monday, April 06, 2015 9:07 PM
  • So, after a few days holiday/celebration, the issue persists.
    Spent a couple of hours today declining all superseded updates for all Office products, all Windows7, and declining everything for WinXP/WinVista/OfficeXP. SCW ran to cleanup, no timeouts or errors for SCW.. Did this on our primary/USS and our sole secondary/DSS.

    Still getting scan errors on clients. updated the premier case engineer with the disappointing outcome.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, April 07, 2015 8:00 AM
  • Thanks for the update Don.  I'm also in the same predicament.  Performed the cleanup, re-indexing, etc. on the SUSDB, ran the batch fixes on some affected clients, but the problem always seems to return.  I've created the configuration baseline to see exactly what percentage of our environment is affected, but the early results are not looking good.  

    Come on Microsoft, we need a fix for this!

     
    Tuesday, April 07, 2015 6:46 PM
  • Hi all,

    One of the bigger nuissances of this particular bug is that it's hard to identify from a central location that you've fallen victim to it. Without spot-checking client machines you'd be none-the-wiser. This most likely results in a lot of shops out their thar are completely unaware they have a security issue with a false sense of "fully patched" security.

    I've create the following guidelines to identify whether you are indeed one of the victims.

    1. create a script configuration item.
    2. Select All Windows 7 32 bit as the supported platform
    3. Use String as the data type
    4. Choose powershell as your script language of choice
    5. Paste the following text in the discovery script:select-string-pattern'GetWARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E'-path"$env:windir\windowsupdate.log"
    6. Add the configuration item to a Configuration baseline
    7. Deploy the configuration baseline to All Windows 7 32bit machines
    8. The report list of assets by compliance state for a given baseline is a good report to check the results.
    9. !!!! Any machines reporting compliant to this baseline have a serious issue as they won't install any software updates, yet report compliant on all !!!!

    Good luck

    Hi, Does the configuration item need any kind of compliance rule setup to make it work?
    Tuesday, April 07, 2015 7:28 PM
  • In SCCM 2012, you'll need to create a Configuration Baseline, then deploy it.
    Tuesday, April 07, 2015 9:20 PM
  • Hi, to update, we have performed cleanup on WSUS (decline all superseded updates) and then run through the cleanup wizard. This has improved our compliance rate greatly - I've also sent out a baseline checking for the error in windwosupdate.log in the last two days and at this stage we have about 10% of all machines that still have the issue so its not fixed but vastly improved.

    Prior to clean-up the majority of our x86 machines had the issue.

    Wednesday, April 08, 2015 6:43 AM
  • So, this morning, rebooted my 3 sample client machines, and, no errors to be seen :)

    Looks like we finally got enough declines done, and cleaned up, for these to scan successfully.

    And, general chatter suggests that people are seeing "loads of patches coming down from IT", which is also a sign that scans are now working where previously not working.

    Some more settling down and monitoring, but I've managed so far not to re-configure any clients, for me, it's all been back-end tasks, to get to this point.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, April 08, 2015 8:45 AM
  • Hi, to update, we have performed cleanup on WSUS (decline all superseded updates) and then run through the cleanup wizard. This has improved our compliance rate greatly - I've also sent out a baseline checking for the error in windwosupdate.log in the last two days and at this stage we have about 10% of all machines that still have the issue so its not fixed but vastly improved.

    Prior to clean-up the majority of our x86 machines had the issue.

    How do you configure the baseline to only check the last 2 days of the windowsupdate.log? Thanks!
    Wednesday, April 08, 2015 8:12 PM
  • Hi, Microsoft support supplied us with a configurable baseline which I've scheduled to run daily and set to check the past 2 days. That way we can monitor if the issue starts to come back again. I cant attach files here but the script is as follows -> $Threshold is the number of days.

    There are also three compliance rules (only the critical non-compliance means the machine has the issue -> When keyword is found in last x number of days: 1
    Keyword: hr=8007000E

    <# This script will parse the windowsupdate.log file and search for a keyword in last x ($threshold) number of days. Following values can be returned:
    0 - When keyword is found but NOT in last x number of days.
    1 - When keyword is found in last x number of days.
    2 - When keyword is NOT found in the log file.
    For any questions please contact Karanr
    #>

    # Define custom properties here:
    $Threshold=2
    $Keyword="hr=8007000E"
    #End

    $WinFolder = (Get-WmiObject Win32_OperatingSystem).WindowsDirectory
    $Batch = 200
    $DateTimeArray = (Get-Content $WinFolder\WindowsUpdate.log -ReadCount $Batch | Select-String "$Keyword" -SimpleMatch | foreach { [DateTime]($_.ToString()).Substring(0,10) } )
    If ($DateTimeArray -ne $null)
     {
      [TimeSpan]$NoOfDays = ([DateTime](Get-Date) - [DateTime]$DateTimeArray[($DateTimeArray.Count - 1)])

       IF ($NoOfDays.Days -le $Threshold) {Write-Host 1}
        ELSEIF ($NoOfDays.Days -gt $Threshold) {Write-Host 0}
     }

    Else
     {
      Write-Host 2
     }

    Wednesday, April 08, 2015 10:19 PM
  • Thanks for the script Carlitog!  I just set it up and deployed to a small test group.  Looking forward to the results.
    Wednesday, April 08, 2015 10:54 PM
  • Thank you Carlitog!  Gonna give that script a try.
    Wednesday, April 08, 2015 11:16 PM
  • Should the script report "Non-Compliant" even when it returns a "2"? We're seeing it reporting "Non-Compliant" on test machines that do not have the issue, not sure if I setup the Compliance Item properly or not (seems easy enough, we've entered the script and 3 conditions using the Integer returned)...

    Jack

    Thursday, April 09, 2015 10:12 PM
  • I figured it out, all rules are for compliance only, not rules for compliance or non-compliance!

    Jack

    Thursday, April 09, 2015 11:06 PM
  • On our SCCM, the following sql query report computers which have issues reporting security updates. After cleaning/declining updates at the WSUS level and reboot of the computers, no more pb (we are below 300 updates scanned). If this can help...just change the collectionid

    -------

    SELECT * FROM (

    SELECT left(SystemType0 ,3) as platform, convert(datetime,lastHWScan) as lastHWscan, v_R_System.Netbios_Name0 AS [Computer Name], SB.SerialNumber0 AS [Serial Number], CS.UserName0 as UserName0, CS.Model0 AS Model, v_R_System.AD_Site_Name0 AS Site, convert(datetime,v_R_System.Creation_Date0) AS [Creation_Date0],
     case
     when (sum(case when UCS.status=2 then 1 when UCS.status is null then 9999 else 0 end))>0 
     then cast(sum(case when UCS.status=2 then 1 when UCS.status is null then 9999 else 0 end) as varchar(10)) 
     else '0'
     end as 'WindowsUpdatesNeeded',
     lastbootuptime0
    FROM v_R_System 
    LEFT JOIN v_GS_SYSTEM_ENCLOSURE SE ON v_R_System.ResourceID = SE.ResourceID 
    LEFT JOIN v_GS_PC_BIOS SB ON v_R_System.ResourceID = SB.ResourceID 
    LEFT JOIN v_GS_COMPUTER_SYSTEM CS ON v_R_System.ResourceID = CS.ResourceID 
    LEFT JOIN v_GS_WORKSTATION_STATUS WS ON v_R_System.ResourceID = WS.ResourceID 
    LEFT JOIN v_GS_OPERATING_SYSTEM OS ON v_R_System.ResourceID = OS.ResourceID 
    LEFT JOIN v_FullCollectionMembership FCM ON v_R_System.ResourceID = FCM.ResourceID  
    LEFT JOIN v_UpdateComplianceStatus UCS on CS.ResourceID = UCS.ResourceID 
    LEFT JOIN v_CICategories_All catall2 on UCS.CI_ID=catall2.CI_ID 
    LEFT JOIN v_CategoryInfo catinfo2 on catall2.CategoryInstance_UniqueID = catinfo2.CategoryInstance_UniqueID and catinfo2.CategoryTypeName='UpdateClassification' 
    LEFT JOIN v_UpdateInfo ui on UCS.CI_ID=ui.CI_ID 
    where /* FCM.collectionid = 'ES100014' */  FCM.collectionid= 'ES10006F'
    and ((catinfo2.CategoryInstanceName like 'Security Updates' and ui.Severity >6)  or (ucs.Status is null))
    and v_R_System.Name0 like '%'
    Group by 
    v_R_System.Name0, 
    systemtype0,
    CS.UserName0, 
    CS.Model0, 
    ws.lasthwscan, 
    FCM.collectionID,
    v_R_System.Netbios_Name0,
    SB.SerialNumber0,
    v_R_System.AD_Site_Name0,
    v_R_System.Creation_Date0,
    lastbootuptime0

     /* order by v_R_System.Name0,  v_R_System.Creation_Date0 desc */

     ) as test
      where WindowsUpdatesneeded=9999

    Friday, April 10, 2015 8:26 AM
  • Thanks NicoFa!  I was able to run this query and identify over 400 affected machines.  I created a collection with the affected machines and deployed the WUAUSERV script.  After running the script, I noticed most of the 8007000E errors are resolved.  Now, after re-running the query, the number of affected machines dropped. 
    Friday, April 10, 2015 9:33 PM
  • I'm a bit confused...How did you create a Collection based on this SQL query? Did you manage to convert it to a WQL query? The SQL query Works fine in SQL studio manager, but not in SCCM...
    Tuesday, April 14, 2015 8:54 AM
  • I'm a bit confused...How did you create a Collection based on this SQL query? Did you manage to convert it to a WQL query? The SQL query Works fine in SQL studio manager, but not in SCCM...

    I ran the query in SQL Server Management Studio and created a (WQL) collection of machines based on Computer Name. 

    Like this: 

    select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where Name in ( 'ComputerName1',   'ComputerName2',  'ComputerName3',  'ComputerName4', ...)

    Tuesday, April 14, 2015 3:35 PM
  • I ran the query in SQL Server Management Studio and created a (WQL) collection of machines based on Computer Name. 

    Like this: 

    select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where Name in ( 'ComputerName1',   'ComputerName2',  'ComputerName3',  'ComputerName4', ...)

    OK, thank you. I was looking for a dynamic query based collection, I guess I can do it like this manually once a month...
    Wednesday, April 15, 2015 9:19 AM
  • Microsoft now has a blog post going into more detail about this issue.

    Support Tip: ConfigMgr 2012 update scan fails and causes incorrect compliance status

    http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

    Wednesday, April 15, 2015 8:34 PM
  • I found my first 64bit desktop suffering from this problem while trying to do a test deployment of this months patches.

    Even though the Microsoft Blog post says they are not affected the symptoms were identical.

    This was on a computer with 8GB memory however it hadn't been rebooted for a month and had VMs and a lot of apps running as well. I closed everything down and tried another Software Update Scan Cycle and still got the "WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E" error.

    I rebooted and tried the Scan again and it completed fine and I was able to apply the patches.

    The Blog post says it fails if "not a large enough contiguous block of free memory to satisfy the request" so I guess in theory that could apply 64bit as well.  

        

      

     
    Thursday, April 16, 2015 9:59 PM
  • Anyone have anything further  on this issue? 

    So previously I've always heard that we should NEVER manage updates within WSUS since they are managed from SCCM, and we may have unreliable results.  Now we should decline updates in WSUS?  Any potential issues?

    Also, is there really a need to reindex and do a cleanup, other than for performance?  It should not have an effect in repaiting this issue, correct?

    Finally, does fooling with WSUS actually resolve anything?

    Tuesday, May 12, 2015 2:30 PM
  • No further news or updates on the hotfix so far afaik.

    If you have the issue in your environment the proposed cleanup does work around the problem (at least for the time being). 

    One (operational) aspect/caveat to take into account: 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.


    Tim | Blog | @Tim_DK

    Tuesday, May 12, 2015 3:26 PM
  • Anyone have anything further  on this issue? 

    So previously I've always heard that we should NEVER manage updates within WSUS since they are managed from SCCM, and we may have unreliable results.  Now we should decline updates in WSUS?  Any potential issues?

    Also, is there really a need to reindex and do a cleanup, other than for performance?  It should not have an effect in repaiting this issue, correct?

    Finally, does fooling with WSUS actually resolve anything?

    Since the cleanup and reindexing, and, the all the declines I did in WSUS, our environment has returned to normal.
    I had the same concerns (told not to touch WSUS, but am now told to touch WSUS), and discussed this with the MSFT engineer.
    The advice was, that too much cruft in WSUS causes the scan session to exhaust available memory and/or timeout. Reduce the cruft, and optimise performance, allowing less memory to be needed, and take less time to do it.

    Approving updates in WSUS remains not-recommended, mainly because approvals should only be done ConfigMgr. Approvals in WSUS might cause unexpected update deployment, depending upon your WUAgent settings.

    It's been suggested (in a blog by MSFT, from memory), that an update/fix for WUAgent will be released later this year.

    In the meantime (and maybe forever), we apparently all need to get busy cleaning up our WSUS's, doing the maintenance that we should have always been doing (but never knew we had to do it)...


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, May 12, 2015 9:23 PM
  • In the meantime (and maybe forever), we apparently all need to get busy cleaning up our WSUS's, doing the maintenance that we should have always been doing

    In the context of this issue, it seems to me that declining the updates is all that is needed.  That seems to have worked in my environment.  Declined about 1400+.  The other items, reindex and server cleanup script, just seem to be for basic maintenance.  Is that correct?

    As for the server clean up script, if we've never run it before, should I run just one item at a time?  Are there any potential issues to running it? 

    Monday, May 18, 2015 2:55 PM
  • In the meantime (and maybe forever), we apparently all need to get busy cleaning up our WSUS's, doing the maintenance that we should have always been doing

    In the context of this issue, it seems to me that declining the updates is all that is needed.  That seems to have worked in my environment.  Declined about 1400+.  The other items, reindex and server cleanup script, just seem to be for basic maintenance.  Is that correct?

    As for the server clean up script, if we've never run it before, should I run just one item at a time?  Are there any potential issues to running it? 

    I'd say that all of these tasks need to be considered as basic maintenance. Otherwise, eventually the performance will degrade over time anyway.

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, May 19, 2015 8:49 AM
  • Agreed with Jason. I just got off a call with MSFT on this same issue as I am seeing it quite prevalently in my enviornment. They pointed me to the following blog post which is already on this thread.

    http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx

    I was told MSFT is working on a permanent fix as opposed to the workarounds proposed in the above blog post and it is slated for release sometime in June / July. For the last two months, I have been running WSUS Cleanup via Scheduled Task as well as the Decline-Superseded script after patch Tuesday and the issue persists. I am likely going to deploy the 'take own=wuauserv' workaround for a few machines and see how that helps. I have had good success running it manually but am reluctant to deploy wide scale as there are others which report the issue returns before long.


    Gabe | @ConfigMgrGeek

    Tuesday, May 19, 2015 6:39 PM
  • Microsoft just released an update to the Windows Update Client:

    https://support.microsoft.com/en-us/kb/3050265

    Tuesday, June 02, 2015 6:04 PM
  • The update provided by Matt above to the windows update client appears to have done the job for us - have only seen the issue in x86 PCs so far
    Wednesday, June 03, 2015 11:07 AM
  • Microsoft has just released a hotfix: 
    http://blogs.technet.com/b/sus/archive/2015/06/03/new-windows-update-client-for-microsoft-windows-7-available.aspx

    Ronni Pedersen | Microsoft MVP - ConfigMgr | Blogs: www.ronnipedersen.com/ and www.SCUG.dk/ | Twitter @ronnipedersen

    Wednesday, June 03, 2015 7:39 PM
  • KB3050265 worked for us. Although not all W7 machines with the issue could download it and install it normally, due to the same issue. I had to create a package/program and use a wusa.exe command to push it out silently.
    Thursday, June 25, 2015 3:39 PM
  • This is the latest fix for this issue.  https://support.microsoft.com/en-us/kb/3112343
    • Proposed as answer by staino Saturday, December 05, 2015 12:36 PM
    Friday, December 04, 2015 8:43 PM
  • Any version for Windows Server 2008?  We seem to have x86 servers with 8007000E error in windowsupdate.log.
    Tuesday, December 22, 2015 9:31 PM
  • I am seeing the same issue. My systems are all running Windows 7 Enterprise X65 with SP1 installed.  I am using SCCM 2012 r2 to push out the updates and according to the person I just took over for, it seemed to be running well, tho some systems were not updating.  So  I performed this:

    Net stop wuauserv
    Sc config wuauserv type= own
    Net start wuauserv

    I also went out and got the update KB3112343 and applied it to a system and then forced it to run updates:

    KB3112343 -- Assume that you use Software Update agent to apply software updates or determine the software update compliance in System Center Configuration Manager 2007 R2. Windows Update agent scans client computers periodically. In this situation, the scan fails and generates a "Not Required" state for all updates. Additionally, you receive an "8007000E" error message.

    I forced a scan of the system to see if it would go and pull down the updates and the windows update log shows:

    2016-02-26 12:15:38:671 1076 25f0 Misc Validating signature for C:\Windows\SoftwareDistribution\ScanFile\134fd4e6-54fe-43e0-9951-9f0c26178b85\Source.cab with dwProvFlags 0x00000080:
    2016-02-26 12:15:38:908 1076 25f0 Misc  Microsoft signed: Yes
    2016-02-26 12:15:39:250 1076 25f0 DtaStor Default service for AU is {7971F918-A847-4430-9279-4A52D1EFE18D}
    2016-02-26 12:15:39:648 1076 25f0 Agent WARNING: WU client fails CClientCallRecorder::RemoveService with error 0x80248014
    2016-02-26 12:26:15:973 1076 25a4 Misc Validating signature for C:\Windows\SoftwareDistribution\ScanFile\6d07eeb2-b13b-4150-8726-b0e9935cc976\Source.cab with dwProvFlags 0x00000080:
    2016-02-26 12:26:15:983 1076 25a4 Misc  Microsoft signed: Yes
    2016-02-26 12:26:16:059 1076 25a4 DtaStor Default service for AU is {7971F918-A847-4430-9279-4A52D1EFE18D}
    2016-02-26 12:26:16:073 1076 25a4 Agent WARNING: WU client fails CClientCallRecorder::RemoveService with error 0x80248014
    2016-02-26 12:28:43:380 5008 2674 COMAPI -------------
    2016-02-26 12:28:43:380 5008 2674 COMAPI -- START --  COMAPI: Search [ClientId = CcmExec]
    2016-02-26 12:28:43:380 5008 2674 COMAPI ---------
    2016-02-26 12:28:43:444 5008 2674 COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec]
    2016-02-26 12:28:43:444 1076 2c54 Agent *************
    2016-02-26 12:28:43:444 1076 2c54 Agent ** START **  Agent: Finding updates [CallerId = CcmExec]
    2016-02-26 12:28:43:444 1076 2c54 Agent *********
    2016-02-26 12:28:43:444 1076 2c54 Agent   * Include potentially superseded updates
    2016-02-26 12:28:43:445 1076 2c54 Agent   * Online = Yes; Ignore download priority = Yes
    2016-02-26 12:28:43:445 1076 2c54 Agent   * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"
    2016-02-26 12:28:43:445 1076 2c54 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2016-02-26 12:28:43:445 1076 2c54 Agent   * Search Scope = {Machine}
    2016-02-26 12:29:00:821 1076 2c54 PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    2016-02-26 12:29:00:821 1076 2c54 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://XXXXSCCM.xxx.local:8530/ClientWebService/client.asmx

    Since most of my systems are remote from where I am, how can I go about and fix this.  It does seem that it started with right after the Jan updates or Feb updates.  Has this been resolved with that one update KB3112343 or is this still an ongoing issue.  Any assistance would be welcome.

    Mark Reny

    Friday, February 26, 2016 5:48 PM
  • I am seeing the same issue. My systems are all running Windows 7 Enterprise X65 with SP1 installed.  I am using SCCM 2012 r2 to push out the updates and according to the person I just took over for, it seemed to be running well, tho some systems were not updating.  So  I performed this:

    Net stop wuauserv
    Sc config wuauserv type= own
    Net start wuauserv

    I also went out and got the update KB3112343 and applied it to a system and then forced it to run updates:

    KB3112343 -- Assume that you use Software Update agent to apply software updates or determine the software update compliance in System Center Configuration Manager 2007 R2. Windows Update agent scans client computers periodically. In this situation, the scan fails and generates a "Not Required" state for all updates. Additionally, you receive an "8007000E" error message.

    <.....>
    2016-02-26 12:15:39:648 1076 25f0 Agent WARNING: WU client fails CClientCallRecorder::RemoveService with error 0x80248014
    <.....>
    2016-02-26 12:26:16:073 1076 25a4 Agent WARNING: WU client fails CClientCallRecorder::RemoveService with error 0x80248014
    <.....>

    I don't think you have the same issue. You're running 64bit, and this issue was reported against 32bit. You're getting 0x80248014, but this issue wasn't about that error code at all, this issue was about error 0x8007000E and returning inaccurate compliance.

    The error you're getting, is very different, and suggests a problem with the service or the datastore for the WUAgent on the client machine

    0x80248014
    An operation did not complete because the service is not in the data store.
    Source: Windows Update Agent
    -----

    As a test, on an affected client machine, you could try resetting the datastore;
    - net stop wuauserv
    - rename windowsupdate.log windowsupdate001.log
    - rename c:\windows\softwaredistribution c:\windows\softwaredist001
    - net start wuauserv
    watch the (freshly created) windowsupdate.log

    You may also need to check on the WSUS patch levels (patches for WSUS itself) on your SUP.
    What is the Windows OS version on your SUP/WSUS?
    Is your SUP a downstream WSUS of another WSUS on your network?
    If so, what is the Windows OS version of that upstream WSUS?
    What patch levels of WSUS are applied to all of your WSUS/SUP? (e.g. KB2938066 ?)

    - Although it may not be directly related to your issue, Have you been performing the routine maintenance to WSUS (running the WSUS cleanup wizard, reindexing the SUSDB, performing declines, etc)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, February 26, 2016 11:08 PM
  • Don,

    Here is what the log is reporting after performing the steps you recommended above. I am not sure what the patch level is for the WSUS.  SCCM is running 2008 R2 x64 and I believe the others would be running that but am not able to validate that at the moment.  Am trying to get that info now. 

    Also you mentioned running wsus cleanup wizard.  Running it from SCCM 2012 where would I do into that to perform that.  I know that in the past until I came onboard and started realizing the issues, updates were just being added to the update groups without any consideration to removing expired and old ones that no longer apply.

    2016-02-29 09:52:33:606 1076 74c Report CWERReporter finishing event handling. (00000000)
    2016-02-29 10:05:10:545 1076 1730 AU ###########  AU: Uninitializing Automatic Updates  ###########
    2016-02-29 10:05:11:996 1076 1730 Report CWERReporter finishing event handling. (00000000)
    2016-02-29 10:05:12:354 1076 1730 Service *********
    2016-02-29 10:05:12:354 1076 1730 Service **  END  **  Service: Service exit [Exit code = 0x240001]
    2016-02-29 10:05:12:354 1076 1730 Service *************
    2016-02-29 10:15:03:938 1076 bec Misc ===========  Logging initialized (build: 7.6.7600.320, tz: -0500)  ===========
    2016-02-29 10:15:03:938 1076 bec Misc   = Process: C:\Windows\system32\svchost.exe
    2016-02-29 10:15:03:938 1076 bec Misc   = Module: c:\windows\system32\wuaueng.dll
    2016-02-29 10:15:03:938 1076 bec Service *************
    2016-02-29 10:15:03:938 1076 bec Service ** START **  Service: Service startup
    2016-02-29 10:15:03:938 1076 bec Service *********
    2016-02-29 10:15:03:954 1076 bec Agent   * WU client version 7.6.7600.320
    2016-02-29 10:15:03:954 1076 bec Agent   * Base directory: C:\Windows\SoftwareDistribution
    2016-02-29 10:15:03:954 1076 bec Agent   * Access type: No proxy
    2016-02-29 10:15:03:969 1076 bec Agent   * Network state: Connected
    2016-02-29 10:15:05:358 1076 bec DtaStor Default service for AU is {00000000-0000-0000-0000-000000000000}
    2016-02-29 10:15:05:358 1076 bec DtaStor Default service for AU is {9482F4B4-E343-43B6-B170-9A65BC822C77}
    2016-02-29 10:15:05:420 1076 bec Agent WARNING: failed to access the auth cab, fatal error 0x80070003
    2016-02-29 10:15:05:420 1076 bec Agent WARNING: Invalid service in the backup data store; cleaning up
    2016-02-29 10:15:05:420 1076 bec Agent WARNING: Failed to add and register service 7971f918-a847-4430-9279-4a52d1efe18d to the data store 0x80240031
    2016-02-29 10:15:05:420 1076 bec Agent WARNING: Default Service Recovery: Attempting to add pending registration for service 7971f918-a847-4430-9279-4a52d1efe18d to the data store
    2016-02-29 10:15:50:445 1076 bec Report CWERReporter::Init succeeded
    2016-02-29 10:15:50:445 1076 bec Agent ***********  Agent: Initializing Windows Update Agent  ***********
    2016-02-29 10:15:50:445 1076 bec Agent   * Prerequisite roots succeeded.
    2016-02-29 10:15:50:445 1076 bec Agent ***********  Agent: Initializing global settings cache  ***********
    2016-02-29 10:15:50:445 1076 bec Agent   * WSUS server: http://xxxxxxSCCM.rac.local:8530
    2016-02-29 10:15:50:445 1076 bec Agent   * WSUS status server: http://xxxxxxSCCM.rac.local:8530
    2016-02-29 10:15:50:445 1076 bec Agent   * Target group: (Unassigned Computers)
    2016-02-29 10:15:50:445 1076 bec Agent   * Windows Update access disabled: No
    2016-02-29 10:15:50:445 1076 bec DnldMgr Download manager restoring 0 downloads
    2016-02-29 10:15:50:445 1076 bec AU ###########  AU: Initializing Automatic Updates  ###########
    2016-02-29 10:15:50:445 1076 bec AU   # WSUS server: http://xxxxxSCCM.rac.local:8530
    2016-02-29 10:15:50:445 1076 bec AU   # Detection frequency: 22
    2016-02-29 10:15:50:445 1076 bec AU   # Approval type: Scheduled (User preference)
    2016-02-29 10:15:50:445 1076 bec AU   # Scheduled install day/time: Every day at 3:00
    2016-02-29 10:15:50:445 1076 bec AU   # Auto-install minor updates: Yes (User preference)
    2016-02-29 10:15:50:445 1076 bec AU   # Will interact with non-admins (Non-admins are elevated (User preference))
    2016-02-29 10:15:50:445 1076 bec AU Setting AU scheduled install time to 2016-03-01 08:00:00
    2016-02-29 10:15:50:835 1076 bec Report ***********  Report: Initializing static reporting data  ***********
    2016-02-29 10:15:50:835 1076 bec Report   * OS Version = 6.1.7601.1.0.65792
    2016-02-29 10:15:50:835 1076 bec Report   * OS Product Type = 0x00000030
    2016-02-29 10:15:50:866 1076 bec Report   * Computer Brand = Hewlett-Packard
    2016-02-29 10:15:50:866 1076 bec Report   * Computer Model = HP Compaq 8100 Elite SFF PC
    2016-02-29 10:15:50:866 1076 bec Report   * Bios Revision = 786H1 v01.02
    2016-02-29 10:15:50:866 1076 bec Report   * Bios Name = Default System BIOS
    2016-02-29 10:15:50:866 1076 bec Report   * Bios Release Date = 2009-12-16T00:00:00
    2016-02-29 10:15:50:866 1076 bec Report   * Locale ID = 1033
    2016-02-29 10:15:50:898 1076 bec AU Successfully wrote event for AU health state:0
    2016-02-29 10:15:50:898 1076 bec AU Initializing featured updates
    2016-02-29 10:15:50:898 1076 bec AU Found 0 cached featured updates
    2016-02-29 10:15:50:898 1076 bec AU Successfully wrote event for AU health state:0
    2016-02-29 10:15:50:898 1076 bec AU Successfully wrote event for AU health state:0
    2016-02-29 10:15:50:898 1076 bec AU AU finished delayed initialization
    2016-02-29 10:15:56:077 1076 10b8 Report CWERReporter finishing event handling. (00000000)
    2016-02-29 10:27:07:639 5008 2f64 COMAPI -------------
    2016-02-29 10:27:07:639 5008 2f64 COMAPI -- START --  COMAPI: Search [ClientId = CcmExec]
    2016-02-29 10:27:07:639 5008 2f64 COMAPI ---------
    2016-02-29 10:27:07:639 5008 2f64 COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec]
    2016-02-29 10:27:07:639 1076 10b8 Agent *************
    2016-02-29 10:27:07:639 1076 10b8 Agent ** START **  Agent: Finding updates [CallerId = CcmExec]
    2016-02-29 10:27:07:639 1076 10b8 Agent *********
    2016-02-29 10:27:07:639 1076 10b8 Agent   * Include potentially superseded updates
    2016-02-29 10:27:07:639 1076 10b8 Agent   * Online = Yes; Ignore download priority = Yes
    2016-02-29 10:27:07:639 1076 10b8 Agent   * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"
    2016-02-29 10:27:07:639 1076 10b8 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2016-02-29 10:27:07:639 1076 10b8 Agent   * Search Scope = {Machine}
    2016-02-29 10:27:07:920 1076 10b8 PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    2016-02-29 10:27:07:920 1076 10b8 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://xxxxxxSCCM.rac.local:8530/ClientWebService/client.asmx
    2016-02-29 10:27:10:276 1076 10b8 PT WARNING: Cached cookie has expired or new PID is available
    2016-02-29 10:27:10:276 1076 10b8 PT Initializing simple targeting cookie, clientId = 0b70cc3a-0bc2-45e4-b0bd-27f8cb9e28c5, target group = , DNS name = dad0247.rac.local
    2016-02-29 10:27:10:276 1076 10b8 PT   Server URL = http://xxxxxSCCM.rac.local:8530/SimpleAuthWebService/SimpleAuth.asmx
    2016-02-29 10:28:31:033 1076 10b8 PT WARNING: Exceeded max server round trips: 0x80244010
    2016-02-29 10:28:31:033 1076 10b8 PT WARNING: Sync of Updates: 0x80244010
    2016-02-29 10:28:31:033 1076 10b8 PT WARNING: SyncServerUpdatesInternal failed: 0x80244010
    2016-02-29 10:28:31:033 1076 10b8 Agent   * WARNING: Failed to synchronize, error = 0x80244010
    2016-02-29 10:28:31:033 1076 10b8 Agent   * WARNING: Exit code = 0x80244010
    2016-02-29 10:28:31:033 1076 10b8 Agent *********
    2016-02-29 10:28:31:033 1076 10b8 Agent **  END  **  Agent: Finding updates [CallerId = CcmExec]
    2016-02-29 10:28:31:033 1076 10b8 Agent *************
    2016-02-29 10:28:31:033 1076 10b8 Agent WARNING: WU client failed Searching for update with error 0x80244010
    2016-02-29 10:28:31:080 5008 1cf8 COMAPI >>--  RESUMED  -- COMAPI: Search [ClientId = CcmExec]
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI   - Updates found = 0
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI   - WARNING: Exit code = 0x00000000, Result code = 0x80244010
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI ---------
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI --  END  --  COMAPI: Search [ClientId = CcmExec]
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI -------------
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI WARNING: Operation failed due to earlier error, hr=80244010
    2016-02-29 10:28:31:096 5008 1cf8 COMAPI FATAL: Unable to complete asynchronous search. (hr=80244010)
    2016-02-29 10:28:36:041 1076 10b8 Report REPORT EVENT: {B18217C1-9D9A-40B0-B3ED-FEDE01B39270} 2016-02-29 10:28:31:033-0500 1 148 101 {00000000-0000-0000-0000-000000000000} 0 80244010 CcmExec Failure Software Synchronization Windows Update Client failed to detect with error 0x80244010.
    2016-02-29 10:28:36:041 1076 10b8 Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2016-02-29 10:28:36:041 1076 10b8 Report WER Report sent: 7.6.7600.320 0x80244010 00000000-0000-0000-0000-000000000000 Scan 101 Managed
    2016-02-29 10:28:36:041 1076 10b8 Report CWERReporter finishing event handling. (00000000) 

    Monday, February 29, 2016 3:38 PM
  • Here is what the log is reporting after performing the steps you recommended above. I am not sure what the patch level is for the WSUS.  SCCM is running 2008 R2 x64 and I believe the others would be running that but am not able to validate that at the moment.  Am trying to get that info now. 

    Also you mentioned running wsus cleanup wizard.  Running it from SCCM 2012 where would I do into that to perform that.  I know that in the past until I came onboard and started realizing the issues, updates were just being added to the update groups without any consideration to removing expired and old ones that no longer apply.

    >>
     2016-02-29 10:28:31:033 1076 10b8 PT WARNING: Exceeded max server round trips: 0x80244010

    this is a good article (I'm not sure I'd consider it "the complete guide" but it's a fine article)

    https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/

    The first time connection/detection (after nuking the softwaredistribution datastore), there will be a couple or "warnings", because a bunch of stuff locally on the client has to be rebuilt, so this "max round trips" is to be expected.
    Check this client again, and the log should show progress.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Monday, February 29, 2016 8:08 PM
    Monday, February 29, 2016 8:02 PM
  • You may need to decliine update associated with MS16-014 and see the result. these updates are high lenght updates released by MS in Feb 2016.


    MS Forum, PankajR

    Saturday, March 12, 2016 2:18 PM
  • Just install https://www.microsoft.com/en-us/download/details.aspx?id=47352

    Works like a charm!

    • Proposed as answer by Raghu.M.C Wednesday, May 11, 2016 7:51 AM
    Monday, May 09, 2016 9:31 AM
  • I know this is somewhat of an old thread, but I had similar issues running updates on some of our x86 clients. I had installed the latest Update agent which alone did not resolve. I installed KB3050265 (https://support.microsoft.com/en-us/kb/3050265) along with the most recent update agent to resolve (https://support.microsoft.com/en-us/kb/949104).   A reboot is required after installing KB3050265.  Now I am able to run updates again!
    • Proposed as answer by bbooher2011 Monday, June 13, 2016 2:25 PM
    Monday, June 13, 2016 2:25 PM
  • Install https://support.microsoft.com/en-us/kb/3112343; this update to the windows update client fixes this issue and other related issues with clients not checking into sccm. 
    Thursday, July 14, 2016 6:06 PM
  • Well what fixed this for me on Windows 7 32-bit was KB3065987, KB3112343, & KB3050265. At least on two of the computers I tried it on so far. Have to push to rest of my computers to see if fixed everywhere.

    We also did the sc config wuauserv type= own command mentioned here --> https://blogs.technet.microsoft.com/configurationmgr/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status/

    Still working on getting a fix for Win 8 32-bit. Working with MS support currently and will update here if we find a fix.


    Paul


    • Edited by PRAMAG Friday, October 28, 2016 9:13 PM
    Friday, October 28, 2016 9:00 PM
  • There are no Windows 8 32-bit equivalent hotfixes like Windows 7 32-bit has (see my previous post). The only thing that worked for Win 8 32-bit is to upgrade them to Windows 8.1.

    Paul

    Tuesday, March 28, 2017 8:37 PM