Evidence processing behavior (wildcards)

[marius]

Hi, I need some clarification on evidence processing behavior in FNMS. If evidence record with wildcards exists in the system, how evidence, matching one with wildcards, is handled in the system? In our tool I can see examples where we have two evidence records for potentially same installer evidence. One with wildcards from ARL, and another local. Is it expected behavior? I was hoping to have local evidence removed, if there is the match to evidence with wildcards. Example attached. Marius

[mfranz · Accepted solution]

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

[smullins]

@marius, our content team uses wildcards for evidence matching to cover multiple minor versions of evidence to avoid having to create individual evidence records for every iteration of the evidence. It sounds like someone created a local evidence record that overlaps these. It's best practice to remove the local overlapping evidence to avoid duplicate counts. You can view more on managing overlapping evidence from the Video Demo in the Learning Center as well as the online help. Links to both are below: https://learn.flexera.com/discovery-inventory-collection-with-flexnet-manager-suite/303234 https://helpnet.flexerasoftware.com/fnms/EN/WebHelp/index.html#tasks/Evid-ResolvingAlertsAboutOverlapEvid.html

[mfranz]

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.

• https://en.wikipedia.org/wiki/Thin_space
• https://en.wikipedia.org/wiki/Non-breaking_space

Interesting: I would have thought that a case insensitive database would treat them all as space, but thats not the case.

[marius]

Hi, both evidences have been created automatically. One with wildcards came from ARL, another have been created as part of SCCM inventory import. Both have same number of matches, so I guess evidence from ARL match evidence that came from SCCM. If I look at other evidences I see that when there is a match to evidence with wildcards system removes local evidences. I am trying to understand why it is not a case in this situation.

[mfranz · Accepted solution]

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

[MurrayPeters · Accepted solution]

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:

• FNMS imports raw evidence from connected inventory sources – as this point (during import) the evidence being considered is explicit
• For each piece of incoming evidence, FNMS checks existing evidence rules:
1. If no existing rules match, FNMS creates a new evidence rule with the explicit/exact details from the incoming evidence.
2. If a match (or matches) is found, FNMS does not create new evidence but uses the existing evidence id’s to associate with the device it was found on.

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.