A quick revision of the terminology: A Method is an overall logical method to achieve discovery of a related set of information. Within each method there is one or more Script that contains the knowledge of how to recover this information. In the case of UNIX these are actual shell scripts. The shell scripts can recover a number of properties and adapt to the slight differences between platforms.
Windows discovery is very slightly different. Rather than using the facility of a scripting shell the Methods contain several atomic scripts to recover elements of information needed by each method.
Device summary field behaves slightly differently depending what was found so that the best summary information is given for full discovery, probe discovery and across device types. All data is recovered from the DDD below
Device summary field behaves slightly differently depending what was found so that the best summary information is given for full discovery, probe discovery and across device types. All data is recovered from the DDD below
It will be normal behaviour on initial scans as Foundation works out what credentials and slaves to use that there will be session results. Session Results are logged sequentially – the hidden timeindex field can be used to reconstruct this sequence. Normally the successful session does not create a Session Result to save storage, but if there have been failures it will
Note that we always try UNIX login ahead of Windows if our cached results do not work – UNIX fails a lot quicker so this is more efficient
Notice that the credential from the scanner appliance is not a link – the credential is local to the scanning appliance so cannot be resolved on the consolidation appliance.
The status column is driven by the failure_reason attributes and is the legacy technique of feedback retained as a summary.
The script can be looked up on the Platforms page in Administration. If no script is recorded then none succeeded, the exception being geNames as a DNS query is so simple it doesn’t have a script!
There are considerably more scripts on Windows. This reflects the evolving proprietary methods across Windows versions but also the difference between the UNIX scripts trying several techniques internally. Neither is better or worse, they’re just different. Note that even using the preferred WMI access we still have to use other techniques to gather network connection details as these are not available via WMI.
Additional discovery is summarised by rolling up in the status column (driven by failure_reason) Script failure reports are reflect upwards and summarised.
On most platforms need to add specific privilege elevation Some platforms need additional software (lsof) UNIX scripts can be instrumented as they are *all* shell scripts and we have a function that can capture stdin/stdout. Windows scripts cannot be instrumented as there is no equivalent and they use a variety of techniques. This is partially mitigated as the Windows scripts tend to be much more atomic than the Unix ones.
UNIX scripts only. Use sparingly and in general do not leave on in production – if large amounts of data are captured from standard error it can impact the system due to increase load on storage.
After editing the discovery script and scanning the host we have now captured the command failure Click on the link to view result details
LSOF is not installed on this host in a place that the user we used could find
![Outline ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)