SOLVED WUAHandler.log reporting "Scan failed with error = 0x8024000f"

[gafoorgk]

Hi,

I'm using SCCM CB 1902 on Windows 2016. WUAHandler.log in all clients is reporting error since almost a month back. Following is the last few lines from log;

Its a WSUS Update Source type ({7BDC6D42-1BB8-4DBD-AD96-E288D3E2E79A}), adding it.    WUAHandler    13/07/2019 03:04:13    17304 (0x4398)
This device is not enrolled into Intune.    WUAHandler    13/07/2019 03:04:13    18876 (0x49BC)
Device is not MDM enrolled yet. All workloads are managed by SCCM.    WUAHandler    13/07/2019 03:04:13    18876 (0x49BC)
SourceManager::GetIsWUfBEnabled - There is no Windows Update for Business settings assignment. Windows Update for Business is not enabled through ConfigMgr    WUAHandler    13/07/2019 03:04:13    18876 (0x49BC)
Existing WUA Managed server was already set (https://mycompany.contoso.com:8531), skipping Group Policy registration.    WUAHandler    13/07/2019 03:04:13    17304 (0x4398)
Added Update Source ({7BDC6D42-1BB8-4DBD-AD96-E288D3E2E79A}) of content type: 2    WUAHandler    13/07/2019 03:04:13    17304 (0x4398)
Scan results will include all superseded updates.    WUAHandler    13/07/2019 03:04:13    17304 (0x4398)
Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')    WUAHandler    13/07/2019 03:04:13    17304 (0x4398)
Async searching of updates using WUAgent started.    WUAHandler    13/07/2019 03:04:13    17304 (0x4398)
Async searching completed.    WUAHandler    13/07/2019 03:13:16    22532 (0x5804)
OnSearchComplete - Failed to end search job. Error = 0x8024000f.    WUAHandler    13/07/2019 03:13:16    1880 (0x0758)
Scan failed with error = 0x8024000f.    WUAHandler    13/07/2019 03:13:16    1880 (0x0758)

Tried googling about this error and found that it's about "Circular update relationships were detected in the metadata". I followed below thread and did exactly as suggested (yes, I had installed SUP around 3 months back for the sake of Dell driver and software updates)

SCCM 2012 (1606) - OnSearchComplete - Failed to end search job. Error = 0x8024000f.

social.technet.microsoft.com

But above effort didn't help me. Error still appears and as a result, I'm not able to apply latest Microsoft updates. Any help to fix this issue?

 

[gafoorgk]

The issue is resolved now.

For those who are having the same issue: Denying third party updates alone wouldn't resolve the issue. They have to be deleted from WSUS database. I used script from https://gallery.technet.microsoft.com/Delete-3rd-Party-Updates-e5bf19fe/view/Discussions to delete 3rd party updates. Since script is using only WSUS Powershell library exposed interface for operation, I think the script is safe to be run.

Please do share thoughts.

Regards,

 

[AndyJoin]

Hello gafoorgk and Prajwal,

this thread give me a lot of clues and a possible solution for the same issue i'm encountering in my organization.

The problem here is with SCCM CB 1810 RU2, same 8024000F entry found everywhere (Client and Server), with no wsus sync; I've been able to identify 2 offending updates with SQL query (both Dell Bios Updates, already removed from SUSDB).
After that, nothing improved and updates deployments are still blocked, so I've tried the script U suggested to remove third-party updates but while in test it worked (only 134 rows), now in Production there are more than 8000 entries...so the response is that:

GAC Version Location
--- ------- --------
True v4.0.30319 C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.UpdateServices.Administration\v4.0_4.0.0....
Exception calling "GetUpdates" with "0" argument(s): "The operation has timed out"
At C:\Users\andeadm\Desktop\Delete_nonMS_Updates_inWSUS.ps1:5 char:1
+ $wsus.GetUpdates() | Where {$_.UpdateSource -ne "MicrosoftUpdate"} | ForEach-Obj ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: ) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException


Already tried to increase the IIS Connection Time-out from 180sec to very high limit with no result.

Can U please help to avoid the timeout of Getupdates() method during deletion?
Beside that, there are other operations to do after successful third-party updates deletion?

Many Thanks!
Andrea

 

[gafoorgk]

I did ran into few errors while executing the script, not sure if this particular error was there or not. My point is I had to run script multiple times until complete non-MS updates got deleted.

Why don't you add Select-Object -First 500 in script commands to select smaller chunks and try, if it really is an issue of having large number of non-MS updates.

 

[AndyJoin]

Good advice,

the problem is that here in my vision what it's failing is the method GetUpdates(), so it seems that I cannot split data as you suggest (I hope yes), because the timeout occurs during the method execution (when loading updates data) and not during the cmdlet "ForEach-Object"...I report the script to be more clear:

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();

$wsus.GetUpdates() | Where {$_.UpdateSource -ne "MicrosoftUpdate"} | ForEach-Object {$wsus.DeleteUpdate($_.Id.UpdateId.ToString()); Write-Host $_.Title removed }

 

[Sam Banford]

That code's a little dated. What is it exactly you're attempting to do? Delete all 3rd party updates on a WSUS?

 

[AndyJoin]

That code's a little dated. What is it exactly you're attempting to do? Delete all 3rd party updates on a WSUS?

Thx Sam,

yes that was my original target, because from what I've understood, it might be the solution to the "8024000F search failing" entries inside my Server logs during WSUS sync...in the meantime i was able to modify the GetUpdate method, so now the script is running to clean DB until a certain date...have you some other suggestions regarding the code and/or to manage this issue?

A.

 

[Sam Banford]

It looks like you're running the code directly on the WSUS server so there's no need to load the Microsoft.UpdateServices.Administration namespace; your first two lines can be condensed to simply:
$wsus = Get-WsusServer

There's no need to but if you want to write all proper like you could use:
[Microsoft.UpdateServices.Administration.IUpdateServer] $anotherwsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer()
These both return the same IUpdateServer object of the local server as can be seen by running:
$wsus.GetType() and $anotherwsus.GetType() but most people don't like to type all that (I do though, hah).

All this is blah blah anyway because it seems the issue is the GetUpdates method of the IUpdateServer interface. Recently I had to stand up a domain at the same time another colleague was standing up a new WSUS on another domain and we both had to clear out thousands of unwanted updates as is the case with a new WSUS.

In our cases we needed to decline not remove but we still had to get all the update objects from the server like you do. We used the Get-WsusUpdate cmdlet which did take a very long time to run but it completed (each of us had over 5000 updates on our servers). Get-WsusUpdate and .GetUpdate() may appear to be the same thing but considering they take different parameters:

Get-WsusUpdate (UpdateServices)

Use this topic to help manage Windows and Windows Server technologies with Windows PowerShell.

docs.microsoft.com

IUpdateServer.GetUpdate Method (UpdateRevisionId) (Microsoft.UpdateServices.Administration)

docs.microsoft.com

I would say they are invoking separate code blocks. Additionally .GetUpdate()'s 3 years old and MS is saying that site's not getting any more updates.

Soo... this is an extremely long way of saying, try using the newer cmdlet like this (will write condensed):
$wsus = Get-WsusServer
$thirdPartys = Get-WsusUpdate | Where-Object { $_.Update.UpdateSource -NE 'MicrosoftUpdate' }
ForEach ($update In $thirdPartys) { $wsus.DeleteUpdate($update.Update.Id.UpdateId) }

If that runs with no errors you'll need to run a 2nd pass on the declined updates. Despite the documentation stating that Get-WsusUpdate's Approval parameter has no default value, if you don't pass one it defaults to AnyExceptDeclined.

So...
$declinedThirdPartys = Get-WsusUpdate -Approval Declined | Where-Object { $_.Update.UpdateSource -NE 'MicrosoftUpdate' }
ForEach ($update In $declinedThirdPartys) { $wsus.DeleteUpdate($update.Update.Id.UpdateId) }

My experience with Get-WsusUpdate shows different behavior than what you and others describe about .GetUpdates() in that the cmdlet will only get what's being asked and that method is getting everything using an older codeblock prone to some defined timeout.

Can't actually test here at home because I don't want to delete updates on my WSUS. Lemme know...

 

[AndyJoin]

Oookk,

many thanks Sam, I tried but honestly the command "$thirdPartys = Get-WsusUpdate | Where-Object { $_.Update.UpdateSource -NE 'MicrosoftUpdate' } " after 2 hours was still doing...nothing...(maybe there's a long time to wait?)

So I decided to modify my initial scope object including the ApprovedStates property , since we had already declined all non-Microsoft updates...and now it's running

Hope this could be enough to solve the issue but if you have any other suggestion will be appreciated.

A.

 

[Sam Banford]

after 2 hours was still doing...nothing...(maybe there's a long time to wait?)

Yes; depending on the age and wear/tear on that WSUS is can take hours as in over 3.

My life-learned lesson with WSUS is to not let it age too much. Deploy it in a way that you can destroy a WSUS and stand a new one back in its place in 3 hours total (with 98% of that time being the darn wsusutil import command). Splitting the DB off to an external SQL, keeping OS/service config in the hands of GPOs, etc...

WSUS retains a lot of garbage information even after you've delinced updates, ran the cleanup util, and performed SQL maintenance. The best medicine for an ailing WSUS is to rebuild it.

 

[AndyJoin]

WSUS retains a lot of garbage information even after you've delinced updates, ran the cleanup util, and performed SQL maintenance. The best medicine for an ailing WSUS is to rebuild it.

And finally it works!

Yeah you're right Sam, it's a mess!

Thank You guys, all of You...I promise from now on to maintain the WSUS environment as much as I can...

Andy