Ambiguous warnings in Computer Details

Hi Andrewm,

section 4.3.2.2 in the administrator guide covers this section.

From the help for managed computers "Computers with a yellow shield indicate a computer that has failed more than five times consecutively to be inventoried. The yellow shield can also be displayed if the EminentWare system had issues retrieving one or more of the inventory datasources." 

Basically an inventory has failed to return information for a certain datasource, because this part of the WMI query failed.

Thanks Michael, but the message is still not informative. I realize that the yellow icon means there's a problem inventorying the computer, but what is the meaning of the information in the error message, or is it simply listing what could not be updated rather than the reason it could not be updated? How can I find where I should be looking to resolve the issue?

Here are two examples of errors reported by two different computers that display the yellow exclamation icon.

What does it mean when the details report says:

The following errors were detected or one or more datasources have exceptions:  
Programs and Features
Windows Update History

Instead of the much more informative errors on machines that are not accessible at all, such as the following:

The following errors were detected or one or more datasources have exceptions:  
Exception occurred at 5/17/2012 2:34:19 PM: Unable to resolve the MAC address. Message:
ICMP Ping failed.
ICMP Ping failed.
ICMP Ping failed.
ICMP Ping failed.
The MAC address retrieval using ARP resolution was not attempted for XXX.XXX.XXX.XXX because the ICMP ping failed.
Unable to resolve NetBIOS information on target. Message:
Unable to retrieve NetBIOS domain name and computer name.
Unable to connect to the endpoint mapper. Message: Unable to establish a TCP connection to the Microsoft Endpoint Mapper (Port 135)
Unable to connect to the File and Print port . Message: Unable to connect to the NetBIOS (139) or NetBIOS over TCP/IP direct hosting (445) ports on MACHINE.domain.com and provisioning of the EminentWare provider requires the 'File and Print Sharing' exception to be enabled.

Additionally, how does one go about clearing that flag?  I have some managed computers that are all reporting errors in the Windows Update History.  It's good that I am made aware of a particular Windows Update that failed, but without being able to clear it then you wind up with having to check the computer every time to see if there is a new failed update or if it's the same one.  Re-running the Inventory doesn't clear the flag.  Am I missing something?

Greetings Andrew.

The yellow icon scenario simply lists the datasource(s) that the inventory task was unable to obtain data from. Typically these are transient errors and will clear themselves. Each time an inventory task is initiated on that target system, all configured datasources are queried. If a previous attempt that failed, is now successful, the yellow icon will be cleared and the details will report no issues.

We provide significantly more detail information on the connection attempt because its' a more complex process, and because a failed connection attempt is something that is actionable. That is to say, you can *fix* a computer that cannot be connected to. Generally if a datasource fails a query, there's not much you can do except try again. In some cases, if the failure occurs repeatedly, there may be a conflicting task on the target system that is interfering with the data collection effort. Sometimes, it may also be an indication that the target data is not available.

But how does that work in regards to the Windows Update History?  I have a few machines that show all Success connection attempts and Inventory collection, but do list the Windows Update History under the errors detected/datasource exceptions.  The computers do show some failed Windows Updates, but they were resolved before the PatchManager product was deployed, and the computers have had no updates pending or installed since the WMI connector software was deployed.  How would one go about resolving that?  Thanks!

It has no impact on the Windows Update History itself. What is being indicated is that the Windows Update History could not be read via WMI. Most likely this is a manifestation of some other process/task that was writing to Windows Update History.

Thanks LGarvin, that clears it up. Do you know if there's any straightforward way to determine the cause of repeated failures?

Not from PatchManager directly. There is a report in the Errors and Exceptions report category named Datasource Exceptions by Device that lists the speciifc WMI object(s) that failed - in the Exception Table field. But beyond that information you'd need to enable some client-side logging to find out specifically what was happening with/to that object.

One clue that can be helpful is to run a one-off inventory against just that target system. If the WMI object contines to be problematic, that could suggest a configuration issue with the client.  In earlier releases we had an issue with the Terminal Service faulting excessively. I believe that was a factor of Remote Desktop being not-enabled on those systems. Eventually we pulled Terminal Service from the default collection template. If the collection works fine in a one-off then I would look for other events causing conflicts during the inventory time. The Managed Computers node, Computer Inventory Details tab, will tell you exactly what time the inventory attempt for that inventory object was last executed. You can use that to trace back to the client logs for any related activity.