‎Jun 03, 2019 05:42 AM
Hi Marius,
It is hard to tell, but from my experience, there is usually a reason for such things to happen. What I mentioned above, is just one possibility.
To really analyze the issue, you could manually compare your evidence against the ARL using a SQL statement JOINing them on description, version and publisher.
Maybe it got created locally in the first place and the ARL one came later? Have you tried removing it? Does it come back? As mentioned before, if the additional evidence gets created additionally to teh ARL entry, there is probably a reason.
Could you export both evidences to a Unicode capable file and attach them?
Best regards,
Markward
‎Jun 04, 2019 02:01 AM
Hi Marius,
I think @mfranz is probably right in the suggestion that the wildcarded ARL evidence entry was added *after* the explicitly versioned entry was created. This can happen (for example) as ARL updates are made releasing new evidence rules.
Just to address the question in original post though which was to clarify how FNMS works with evidence matching I thought I’d elaborate a little:
Since you have noted that the matchcount of the wildcarded and explicit evidence entries are the same I would say that the wildcard covers a ‘superset’ of the explicit one – hence there is no differences such as embedded spaces etc. That’s why I think the sequencing was that the explicit one was created first, then a subsequent ARL update caused the wildcarded one to be added.
When this situation occurs (a wildcard entry overlaps an explicit one) it is worth reviewing these and ensuring they link to the same application, but in general it is usually safe to delete the explicit entry and allow the wildcarded one to be used. During the next inventory import (MatchARL steps), the evidence steps above get done again and FNMS should see that the wildcard entry now applies and not create the additional explicit one.
‎Jun 04, 2019 11:41 PM - edited ‎Jun 05, 2019 10:25 AM
‎Jun 03, 2019 06:49 AM
What I have seen in the past: seemingly identical evidences, where the existing ARL entries should trigger, but didn't.
Reason was: different spaces in Add/Remove Programs entries. This even happens with Microsoft products.
Interesting: I would have thought that a case insensitive database would treat them all as space, but thats not the case.
‎Jun 03, 2019 11:21 AM
‎Jun 03, 2019 11:36 PM
Hi Marius,
It is hard to tell, but from my experience, there is usually a reason for such things to happen. What I mentioned above, is just one possibility.
To really analyze the issue, you could manually compare your evidence against the ARL using a SQL statement JOINing them on description, version and publisher.
Maybe it got created locally in the first place and the ARL one came later? Have you tried removing it? Does it come back? As mentioned before, if the additional evidence gets created additionally to teh ARL entry, there is probably a reason.
Could you export both evidences to a Unicode capable file and attach them?
Best regards,
Markward
‎Jun 04, 2019 02:01 AM
Hi Marius,
I think @mfranz is probably right in the suggestion that the wildcarded ARL evidence entry was added *after* the explicitly versioned entry was created. This can happen (for example) as ARL updates are made releasing new evidence rules.
Just to address the question in original post though which was to clarify how FNMS works with evidence matching I thought I’d elaborate a little:
Since you have noted that the matchcount of the wildcarded and explicit evidence entries are the same I would say that the wildcard covers a ‘superset’ of the explicit one – hence there is no differences such as embedded spaces etc. That’s why I think the sequencing was that the explicit one was created first, then a subsequent ARL update caused the wildcarded one to be added.
When this situation occurs (a wildcard entry overlaps an explicit one) it is worth reviewing these and ensuring they link to the same application, but in general it is usually safe to delete the explicit entry and allow the wildcarded one to be used. During the next inventory import (MatchARL steps), the evidence steps above get done again and FNMS should see that the wildcard entry now applies and not create the additional explicit one.
‎Jun 04, 2019 11:41 PM - edited ‎Jun 05, 2019 10:25 AM