[RESOLVED] WaptWUA: Some PCs remain in READY with a scan error

[t.heroult]

Good morning
Since the last patch Tuesday, I have several dozen PCs whose scans are failing with the following result:

Code: Select all

Ensure wuauserv Auto Update option is disabled
Download all updates
Scanning with windows updates rules:
{
 "direct_download":false,
 "default_allow":false,
 "include_potentially_superseded_updates":false,
 "filter":"Type='Software' or Type='Driver'",
 "download_scheduling":"2d",
 "install_scheduling":"2d",
 "install_delay":"20d",
 "postboot_delay":"10m",
 "user_locale":1033
}
Downloading wsusscn2.cab file from https://srvwapt.MonDomaine/waptwua/wsusscn2.cab
3145728 / 687267824 (0%) (2269 KB/s)
(...)
684720128 / 687267824 (100%) (3119 KB/s)
  -> download finished (3127 KB/s)
   Connecting to local update searcher using offline wsusscn2 file...
   Offline Update searcher ready...
Some windows updates have been installed/uninstalled since last scan
Looking for updates with filter: Type='Software' or Type='Driver'
Waiting for WUA search to complete
WUA Search completed !
Done searching
Updates scan done.
re-enabling wuauserv previous state: 0
(-2147319765, 'Élément introuvable.', None, None)
Traceback (most recent call last):
  File "<string>", line 1939, in run
  File "C:\Program Files (x86)\wapt\waptservice\waptservice_common.py", line 737, in run
    self._run()
  File "C:\Program Files (x86)\wapt\waptservice\enterprise.py", line 254, in _run
    self.result = wua.download_updates(self.force, uuids=self.uuids)
  File "C:\Program Files (x86)\wapt\waptwua\client.py", line 1609, in download_updates
    self.scan_updates_status()
  File "C:\Program Files (x86)\wapt\waptwua\client.py", line 1228, in scan_updates_status
    self.store_cached_update_property(update, 'IsDownloaded', update.IsDownloaded)
  File "C:\Program Files (x86)\wapt\lib\site-packages\win32com\client\__init__.py", line 485, in __getattr__
    return self._ApplyTypes_(*args)
  File "C:\Program Files (x86)\wapt\lib\site-packages\win32com\client\__init__.py", line 478, in _ApplyTypes_
    self._oleobj_.InvokeTypes(dispid, 0, wFlags, retType, argTypes, *args),
pywintypes.com_error: (-2147319765, 'Élément introuvable.', None, None)

0x8002802b : Élément introuvable.
Traceback (most recent call last):
  File "<string>", line 1939, in run
  File "C:\Program Files (x86)\wapt\waptservice\waptservice_common.py", line 737, in run
    self._run()
  File "C:\Program Files (x86)\wapt\waptservice\enterprise.py", line 254, in _run
    self.result = wua.download_updates(self.force, uuids=self.uuids)
  File "C:\Program Files (x86)\wapt\waptwua\client.py", line 1609, in download_updates
    self.scan_updates_status()
  File "C:\Program Files (x86)\wapt\waptwua\client.py", line 1228, in scan_updates_status
    self.store_cached_update_property(update, 'IsDownloaded', update.IsDownloaded)
  File "C:\Program Files (x86)\wapt\lib\site-packages\win32com\client\__init__.py", line 485, in __getattr__
    return self._ApplyTypes_(*args)
  File "C:\Program Files (x86)\wapt\lib\site-packages\win32com\client\__init__.py", line 478, in _ApplyTypes_
    self._oleobj_.InvokeTypes(dispid, 0, wFlags, retType, argTypes, *args),
pywintypes.com_error: (-2147319765, 'Élément introuvable.', None, None)

Any idea what's wrong?

Sincerely
Tom

[htouvet]

Good morning,
There is indeed a bug on Microsoft's side regarding the Windows Update service API interfaces since the last patch on Windows 11.
Other "third-party" patching tools also appear to be affected.
See for example: https://www.reddit.com/r/DattoRMM/comme...t/lcjisr0/

For a bit more in depth explanation of the issue: Normally if you search for updates using the IUpdateSearcher COM object, the ISearchResult object that is returned contains an IUpdateCollection object, which in turn contains the IUpdate objects that hold the actual update information.

However, on affected devices, the IUpdateCollection contains only blank COM objects. These objects have no properties or methods beyond those they inherit, so if you try to get the properties of the update, there is nothing found, and so it throws the 0x8002802B error we've been seeing, aka TYPE_E_ELEMENTNOTFOUND.

We hope Microsoft will respond.

On our end, we are currently working on redeveloping our waptwua module using a lower-level API, which, according to our tests, is not affected by this MS bug. However, it will take us 2 to 3 weeks to develop and integrate it to replace the current Python module.

[dcardon]

Hi Thomas,

to add to Hubert's answer, the regression in the latest Microsoft update impacts all Windows Update calls that rely on the TLB (Type Library), therefore all scripting languages, including Python (which WAPT uses), but also PowerShell Windows Update calls and many other languages ​​and patching solutions like Datto rmm or Altiris.

Regards,

Denis

[jacky35]

Things are starting to get really ridiculous at Microsoft.
The number of problems we're forced to deal with today because of their unreliability.

Jacky

[t.heroult]

Thanks Denis and Hubert for this information.

Well, we'll make do until a fix is ​​released!

Best regards,
Tom

[dcardon]

Hello everyone,

Microsoft has published an article regarding this issue: https://learn.microsoft.com/en-us/windo ... pdate-apis

The fix requires creating a group policy (GPO). We are currently working on creating the appropriate WAPT package.

Regards,

Denis

[t.heroult]

Thanks for the feedback.
I'd be happy to receive the package; the Microsoft procedure is problematic for creating the GPO with the invalid WMI filter...

[sfonteneau]

The package is available here:

https://wapt.tranquil.it/store/fr/tis-f ... date-issue

Note that a reboot is required.