Hi Chris,

Great compilation. I have some questions:

• I think in an earlier discussion regarding the limitations of pre 2019 R2.2 agents, it was mentioned that an updated agent might be available for on prem customers. Did the fixes/changes only affect the agent or has the server application/db schema chnaged as well? If not, will there be an updated agent release before 2020 R1 on prem?
• The mentioned "Version = All" value for the manual mapper, does it result in the actual file version value being reported? Because when trying to use a wildcard (*), that character got reported as a result and made it impossble to distinguish between different versions.
• When looking at the ManageSoft Reader, there's some "crosstalk" between Usage and FileEvidence sections (RelevantSoftwareFile). At this point, I don't think discovering the executables via file scan is necessary for usage metering to work, but maybe you can share your thoughts on this?

Best regards,

Markward

Hi @mfranz ,

A few thoughts:

1. The latest agent available at this point in time for download with FlexNet Manager Suite on-premises is the 14.0 version from FlexNet Manager Suite 2019 R2. For Flexera partners who work with both FlexNet Manager Suite Cloud and On-premises, the 14.2 agent version from the Cloud environment could strictly be downloaded and used with an On-premises deployment. The next on-premises release which will include the agent latest improvements is in the process of cooking. Stay patient!

    

2. When using manual mapper configuration, version details from the WinPE header details on Windows can't be used for the application version. The exact version value that you specify in the "Version" registry entry is what gets returned and imported as installer evidence. In order to have different versions identified, you would need to be able to have different manual mapper entries that have different "ExecutablePath" values which somehow match to different versions (maybe based on path, or based on filename). However in practice I expect it would be difficult to manage this. If different versions of the software install an executable with the same name and same path then the best you will be able to do will be to identify something like "All" or "*" as the version.

    

3. I'm a little vague on the crosstalk you mention in the ManageSoft reader, but my starting guess is similar to your thinking here: I believe it is generally not necessary to gather file details as part of inventory for usage metering to work.

Hi @ChrisG  ,

@savin_shetty1  - I think you are referring to the "Application usage options" setting detailed at item 3 under the question "How can the values of configuration settings be changed?" in this post.

This setting can be used to enable/disable usage metering on agents running on computers covered by target(s) you configure.

If you want to enable usage metering on all computers, you could use this approach and configure a target to cover all IP address. An approach I've used for this is to configure a target covering 2 IP address ranges: "0.0.0.0/1" and "128.0.0.0/1". (Don't try to configure the range "0.0.0.0/0" as the UI won't allow a suffix of "/0".) Alternatively, if you just want metering enabled on a subset of devices, configure the target appropriately to cover those devices.

That's basically the situation. When active (open) it is seen as an 'App' in the Windows task manager, when inactive (closed) it drops to the tray and is changed to a 'Background process'. Looks like that's a tricky one. Something I'm still a bit confused about, is if raw usage contributes to 'Last used date' as a backup in this kind of situation, or if the agent must detect a proper start and termination of the process in order to record a used date? My take thus far is that Raw Usage does not generate Last Used Dates.

One more question regarding Manual Mapper. We have successfully enabled and created a manual mapping rule on a test system, and now see the executable as KNOWN  and associated with an application in the usageagent.log file, but still do not see a Last Used Date being recorded in FNMS for this device after ensure we meet the parameters for recording usage (launch, open for a few minutes, terminated). The info above says the MM rules are logged as Installer evidence. Is this something we should be able to see in the evidence properties of the application in FNMS? Wondering if we're missing something that associates the MM rule with the actual application in FNMS.

By the way @ChrisG  really appreciate this article and thread. Combined with some other knowledge, it's really given me a better understanding of how AppPortal/Agent/FNMS interact and helped improve the care with which we approach software reclamation. Let me know if I should take these questions to a support ticket.

@josecaronski  - for your Manual Mapper settings, first check that some usage for the manually mapped application appears in the Discovery & Inventory > Raw Software Usage grid.

• If you don't see anything there, that suggests the usage still isn't getting picked up OK and uploaded from the agent.
• If you do see something there, next check that you have configured an installer evidence recognition rule for the software name & version details you configured in the Manual Mapper settings and linked the evidence recognition rule to an appropriate application. (Or alternatively I think you could configure a file evidence recognition rule - but whatever the case is, the key point here is to verify that you've configured the ARL to recognize the manually mapped application details.) See the "When will a recognized application installation be marked as "used" based on metering data?" question in this article for a little more context.