Error 0x80240fff in WUAHandler Log on Windows 10 Workstations after April 11 Updates

    דיון כללי

  • I couldn't find any information when I received this error, so we placed a Service Call with Microsoft.   Hoping this may help someone else experiencing the same problem.   Here is details about our issue and the resolution.

    We have SCCM-1511, Version 5.00.8325.1000 and Build number 8325. 


    Here is the issue we were having:

    We attempted to send the April updates via SCCM -1511 to our workstations and all of our Windows 10 – 1511 workstations return a deployment state of “Enforcement State Unknown.”  However, updates worked fine on all of our Windows 7 workstations as well as all of our Server Workstations.   Looking at the WUAHandler.log on all of these Windows 10-1511 workstations there was an error 0x80240FFF occurring frequently when the synchronization with WSUS on the SCCM server began.   According to Microsoft Technet this particular error code means “An operation failed due to reasons not covered by another error code.”  I’m wasn’t sure what this meant.

    Here is what was re-occurring several times daily on our Windows 10-1511 workstations according to the WUAHandler.log

    Its a WSUS Update Source type ({C0F6558D-213D-49CE-B5BF-7D898F633551}), adding it.

    Existing WUA Managed server was already set (Our Server FQDN Name), skipping Group Policy registration.

    Added Update Source ({C0F6558D-213D-49CE-B5BF-7D898F633551}) of content type: 2

    Scan results will include superseded updates only when they are superseded by service packs and definition updates.

    Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')

    Async searching of updates using WUAgent started.

    Async searching completed.

    OnSearchComplete - Failed to end search job. Error = 0x80240fff.

    Scan failed with error = 0x80240fff.

    These errors in the WUAHandler.log began the day after Microsoft released the April Patches on 4/11/2017.  On 4/12/2017 these errors began showing up on all of our Windows 10-1511 workstations and SCCM was unable to push updates because these workstations were showing up with an “Enforcement State Unknown” status.   We have not yet upgraded to Windows 10-1607 Anniversary edition at our organization due to issues with our current Third Party Encryption Software on all of our Windows 10 workstations.  

    I put in a service call to Microsoft Tech Support.

    This turns out was a known “bug” that Microsoft is working on.   With the new 1703 Creator’s edition now released our Windows Update logs were giving errors due to a confusion of two feature updates in our WSUS Server.     Here, in summary is what Microsoft Tech Support did to resolve our issue:

    “As we discussed over phone, the issue you are facing is a bug from Microsoft’s end. The product group is working on resolving it.

    Until then, we have a temporary workaround ( Declining either the 1607 upgrade or the 1703 upgrade ), to enable your clients to start scanning for updates again.

    We declined the “Feature update to Windows 10 Enterprise, version 1607, en-us”.  The clients are scanning fine with no issues.”

    יום שישי 21 אפריל 2017 16:49

כל התגובות

  • I've seen reports by others that this is caused by having two Windows 10 1703 feature upgrades in the update catalog and that declining one (directly in WSUS) will resolve this issue. Can't say I've tried myself though. For reference:

    Jason | | @jasonsandys

    שבת 22 אפריל 2017 04:22
    מנחה דיון
  • Thanks a lot for this. This issue was driving me crazy. I guess you declined the update through WSUS directly, right?
    יום שלישי 25 אפריל 2017 15:40
  • Correct.

    Jason | | @jasonsandys

    יום שלישי 25 אפריל 2017 16:33
    מנחה דיון
  • Thank you for posting this fix. Can Confirm it works. Declined feature update through WSUS. Sync Software Updates within SCCM and redeployed Software Updates. Error no longer reported in WUAHandler.log and clients downloading and installing updates once again.
    • נערך על-ידי Robin.Thomas2011 יום שישי 28 אפריל 2017 11:10
    יום שישי 28 אפריל 2017 11:08
  • Here is a guide for some not sure how to do it,

    יום ראשון 30 אפריל 2017 03:17
  • Hi,

    Is there fix for this bug? Steel not possible to upgrade Win 10 1511 to 1703 via SU SCCM.

    יום ראשון 07 מאי 2017 15:18
  • Have you declined the update?

    Jason | | @jasonsandys

    יום ראשון 07 מאי 2017 15:57
    מנחה דיון
  • IMHO, declining the update in WSUS is a workaround, not a fix.

    Since usually we're told to leave WSUS completely alone when it's being used wit SCCM.

    So, question remains; when will this be formally fixed by Microsoft?

    יום שני 08 מאי 2017 09:18
  • If a viable and easy work-around exists, they usually choose not to waste engineering time on a fix. In this case, the issue happened because the there was an issue in WSUS catalog that violated an assumption made by the WUA. They may yet fix the WUA, but you can't always count on that. You'll have to ask Microsoft when/if they intend to fix whatever the root cause of the issue is. Waiting for a fix when a workaround is available is, well, not a good idea. Workarounds are a completely legitimate way of dealing with bugs and other shortcomings and are very much standard practice.

    As for not touching WSUS, that recommendation is outdated and has been for over a year now:

    Jason | | @jasonsandys

    יום שני 08 מאי 2017 14:10
    מנחה דיון
  • The issue is solved by the latest CU for 1511 (KB4019473 at the time of this writing). I was kind of stuck between a rock and a hard place because the fix is a Windows Update and my SCCM software updates wouldn't work.

    I, therefore, created an Application in SCCM to install KB4019473, which I downloaded from the Microsoft Update Catalog.....

    Command line:

    wusa.exe "windows10.0-kb4019473-x64_c23b6f55caf1b9d6c14161b66fe9c9dfb4ad475c.msu" /quiet /norestart 

    PowerShell based detection method:

    Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName . -Property HotFixId -filter "HotFixID = 'KB4019473'" 

    No need to go into WSUS console and decline updates or anything.

    יום שני 15 מאי 2017 01:53
  • Command line:
    wusa.exe "windows10.0-kb4019473-x64_c23b6f55caf1b9d6c14161b66fe9c9dfb4ad475c.msu" /quiet /norestart 

    PowerShell based detection method:

    Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName . -Property HotFixId -filter "HotFixID = 'KB4019473'" 

    No need to go into WSUS console and decline updates or anything.

    This update also resolved my issue :)
    יום חמישי 13 יולי 2017 12:03
  • Glad to hear it's helping. I replace my application each month with the latest CU for 1511. I also got a cleaner detection method from someone in a different post on the same issue.

    get-hotfix | Where-Object {$_.HotFixID -match "KB4025344"}

    The KB number represents the latest CU for 1511 as of this posting.

    יום שישי 14 יולי 2017 12:57
  • Thank you so much for sharing this alternate fix.  I did not want to have to go and change anything in WSUS if I really didn't have to either.  I can confirm that this worked in my current environment as well.  After the machine received the KB4019473 update I did a download Policy and Check for updates and 2018-01 cumulative update that was stuck in "Unknown" status successfully installed.  This made my day/week.  Thank you.
    יום שני 29 ינואר 2018 21:56
  • This procedure solve my issue too!


    -- emnavarro02

    יום חמישי 29 מרץ 2018 17:41
  • We are dealing with this issue now with 1511 clients we are trying to get upgraded to 1709. However, on the 2 machines I looked at the Windowsupdate.log only shows this for the entirety of the log:

    1600/12/31 19:00:00.0000000 1264  7084                  Unknown( 190): GUID=f8140e8b-45e5-2974-519a-7d3a6d974222 (No Format Information found).

    There are other GUIDs specified as well but there are more than 2 discrete ones listed. How can I determine which updates to decline?

    יום שישי 13 אפריל 2018 15:25
  • So I discovered tha the issue here is decoding these Windows Update files. The Get-WindowsUpdateLog cmdlet does not generate anything readable, even after wiping out the directory C:\Users\powellbc\AppData\Local\Temp\WindowsUpdateLog. IS there anything special that needs to be done to get the correct symbols?
    יום שלישי 17 אפריל 2018 12:56