discovery not updating OS related fields after initial scan

[klautrup]

Hi,

In   my developer instance running latest Jakarta version jakarta-05-03-2017__patch5-10-18-2017_10-25-2017_1637 if I do an initial Discovery scan of a windows 2012 server Discovery will correctly populate fields like 'OS Version', 'RAM', 'CPU count' etc.:

But if I manually overwrite for instance the value in field 'OS Version':

And do a new Discovery scan Discovery will not overwrite the manual update.

I have created no Reconciliation Rules saying that manual updates, or updates by other data source than "ServiceNow" takes precedence for the 'Os Version' field, so I would expect a new Discovery scan to revert to the value scanned by Discovery.

In Jakarta obtaining OS information like 'OS Version' still seems to be done by probes+sensors:

If I then upgrade my developer instance to Kingston latest version kingston-10-17-2017__patch0-11-06-2017_11-11-2017_1422 and same time upgrade my MID server to same level scanning a windows server still seems to use the old probes/sensors and 'OS Version' is still not overwritten by Discovery.

However, if I delete my personal developer instance and do a fresh install of the latest Kingston version and do a new scan of the windows server it will use the Discovery pattern named "Windows OS   - Servers" instead of the old probes/sensors:

And if then repeating my test and manually overwriting the 'OS Version' field and doing a new Discovery scan Discovery as expected will overwrite the manual update.

Why does Discovery not overwrite 'OS Version' in Jakarta and Kingston when upgrading from Jakarta when using the OS probes/sensors as it does when doing a clean install of Kingston where Discovery uses the OS pattern?

[VivekSattanatha · Accepted solution]

Hi Kristian,

I think it is because of probe results cache. Usually, we can store probe results as cache and we can use the same result until there is a real change in the device. But I am not sure we keep OS information as a cache. But you can clear the cache of the particular CI and you can try to discover again.

To clear cache of CI, you can find here. Understanding Probe Results Cache returning as "Processed"

Regards,

Vivek

Based on the impact hit like helpful or correct

[klautrup]

Hi Vivek,

You're right. This was due to caching of the probes.
I decided to set glide.discovery.use_probe_results_cache to false to avoid caching of the probes.

Since I didn't see this with a clean install of Kingston thus using the OS pattern instead of the probe+sensor I suppose similar caching is not happening for the patterns?

Do you know why upgrade from Jakarta to Kingston does not activate the "Windows OS   - Servers" pattern?
Should I do something to ensure Discovery uses the "Windows OS   - Servers" pattern?

Regards,

Kristian

[VivekSattanatha]

Since I didn't see this with a clean install of Kingston thus using the OS pattern instead of the probe+sensor I suppose similar caching is not happening for the patterns?

-- I don't think there is cache concept for patterns. Its only for probes.

Do you know why upgrade from Jakarta to Kingston does not activate the "Windows OS   - Servers" pattern?   -- I think because it will confuse the customers to use patterns if suddenly started using patterns. so they might have left it up to them to use in this version. But I guess later they will make it default.

Should I do something to ensure Discovery uses the "Windows OS   - Servers" pattern? -- ServiceNow slowly replacing the probes with patterns because patterns are easy to customize. So it's better to use patterns wherever it needed.

Regards,

Vivek

[Les1]

thank you for this! i was having a really difficult time figuring out why a CI attribute that was manually updated would not be overwritten by Discovery even though i had set precedence rules for it to do so

Since we are not on Pattern discovery yet, would it be preferable (or is there negative impact) to leaving glide.discovery.use_probe_results_cache  set to false?