locked
Mysterious 3rd Party Update Errors in WindowsUpdate.Log File RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have enabled 3rd Party Updates for Lenovo and HP and in a separate environment, Dell. Updates deploy more or less as expected but I get errors in the WindowsUpdate.log for any machine, not just the machines targeted. On a daily basis, I am seeing well over a thousand errors appearing in the WindowsUpdate.Log file on not just the targeted Lenovo/HP/Dell machines but also various VMs and other machines including my main Server 2019 physical machine. All errors reference UniqueUpdateIDs of 3rd Party Updates and almost all are metadata-only (blue icon in MEM). The error [8004100E] relates to the WMI namespace missing but that would be expected on non-Lenovo or non-Dell machines so don't see why this is showing up as a failure. Incidentally, this error happens even when the machine is a Lenovo (haven't tested on a Dell yet).

    1. Why are these happening on machines that aren't even targeted?

    2. Why am I getting these "failures" for updates that are metadata?

    3. I'm happy to log a bug report but would like confirmation this isn't expected. There are many other people with this issue on other forums but most are unanswered or don't provide a credible answer.

    My environment is MEM 1910 with SQL 2019 but have also seen the issue on ConfigMgr 1810 with SQL 2016.

    Typical errors below.

    2020/04/16 08:04:50.8586780 6164  5892  EEHandler       *FAILED* [8004100E]   EE: ConnectServer for namespace Root\Lenovo\drivers

 2020/04/16 08:04:50.8586841 6164  5892  EEHandler       *FAILED* [8004100E] Method failed [COperatorTreeNode::Evaluate:390]

 2020/04/16 08:04:50.8586889 6164  5892  Agent           *FAILED* [8004100E] Evaluate Installed rule, updateId = {<!-- -->{B5455020-0AA7-4B11-8746-0C2CD7D48DFD}.1}

 2020/04/16 08:04:50.8683930 6164  5892  EEHandler       *FAILED* [8004100E]   EE: ConnectServer for namespace Root\Lenovo\drivers

 2020/04/16 08:04:50.8684154 6164  5892  EEHandler       *FAILED* [8004100E] Method failed [COperatorTreeNode::Evaluate:390]

 2020/04/16 08:04:50.8684202 6164  5892  Agent           *FAILED* [8004100E] Evaluate Installed rule, updateId = {<!-- -->{54302520-8B01-46BC-889B-804C7FCC1FCE}.1}

 2020/04/16 08:04:50.8695780 6164  5892  EEHandler       *FAILED* [8004100E]   EE: ConnectServer for namespace Root\Lenovo\drivers

    LENOVO...

    AND DELL...


    Thursday, April 16, 2020 4:40 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Managed clients in ConfigMgr receive the metadata for *all* updates in the WSUS catalog and they all scan for the compliance of all of those updates using that metadata; there is no targeting or granularity here.

    When you add a third-party catalog, the metadata for all updates published in that catalog is added to the WSUS catalog and thus every managed client receives the metadata for those published third-party updates and scans for their compliance. In this case, the compliance rules defined by the vendor are attempting to query WMI namespaces and classes that don't exist on these systems as they are hardware-specific. 

    > don't see why this is showing up as a failure

    Because it's looking for something that's not there. It doesn't know why, just that it isn't there. Not all errors are fatal or even actionable.

    The errors are ultimately benign (and thus ignorable although annoying) and if you want to use these third-party catalogs, there's no way to avoid them.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, April 16, 2020 6:23 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Managed clients in ConfigMgr receive the metadata for *all* updates in the WSUS catalog and they all scan for the compliance of all of those updates using that metadata; there is no targeting or granularity here.

    When you add a third-party catalog, the metadata for all updates published in that catalog is added to the WSUS catalog and thus every managed client receives the metadata for those published third-party updates and scans for their compliance. In this case, the compliance rules defined by the vendor are attempting to query WMI namespaces and classes that don't exist on these systems as they are hardware-specific. 

    > don't see why this is showing up as a failure

    Because it's looking for something that's not there. It doesn't know why, just that it isn't there. Not all errors are fatal or even actionable.

    The errors are ultimately benign (and thus ignorable although annoying) and if you want to use these third-party catalogs, there's no way to avoid them.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, April 16, 2020 6:23 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi,

    When you subscribe to a third-party catalog in the console of ConfiMgr, the metadata for every update in the catalog are synced into the WSUS servers for your SUPs, the sync of the metadata allows the clients to determine if any of the updates are applicable.
    And I agree with Jason, not every red message in the log file requires us to troubleshoot, unless you find some functional problems. Until then, we can safely ignore those benign errors.
    Thanks for posting in TechNet, If there is any other assistance we can provide, please feel free to let us know, we will do our best to help you.


    Best regards,
    Larry

    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 17, 2020 6:09 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Many thanks Jason. I just needed the confirmation that this wasn't something that was misconfigured in some way. If it's benign, then I'm (relatively) happy.


    Friday, April 17, 2020 11:41 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Larry,

    Appreciate the metadata is used for scanning/applicability, was just a little surprised to see '*failure*' in the WindowsUpdate log, hence my question. Thanks, I'm happy with the answer given.

    Friday, April 17, 2020 11:53 AM