Application usage metering with FlexNet agent on Windows for non-MSI applications

[ChrisG]

(Edit: For a more extensive review of usage metering capabilities and configuration, see the following blog post: Application usage metering using the FlexNet inventory agent)

There have been several threads in Community noting that the FlexNet inventory agent on Windows does not gather usage metering data for certain applications. By default, usage is only tracked for executables that are installed directly by an MSI (Windows Installer) package and that are invoked as non-system processes.

I've come across an internal preference "UseAddRemove" for the usage agent component which can be set to also track usage of executables which are found under any installation directories identified in the 32 bit Add/Remove Programs registry area (HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall). Setting the following registry entry on a computer with the FlexNet inventory agent installed will enable this preference:

HKLM\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Usage Agent\CurrentVersion\UseAddRemove=true

There are a few ways that this registry setting could be configured:

1. Configure the registry entry manually (for example, on a test device).
   
   
2. Through a setting in the mgssetup.ini file used when the agent is installed:
   

   [Usage Agent]
   desc0 = UseAddRemove
   val0  = True​

3. Through some other mechanism available in the environment that can set registry entries on computers.
   
   
4. Through FlexNet Manager Suite policy. This can be achieved by running the following SQL against your compliance database if you are using FlexNet Manager Suite On-premises. If you are running FlexNet Manager Suite Cloud you would need to submit a ticket to Flexera to request this be executed for your tenant.
   

   -- Ensure Target__windows exists
   EXEC dbo.BeaconTargetPutByNameInternal @Name = 'Target__windows', @Internal = 1, @Description = NULL, @Visible = 0
   
   -- Set usage agent UseAddRemove preference to "True" for all Windows devices
   DECLARE @btid INT
   SELECT @btid = BeaconTargetID FROM dbo.BeaconTarget WHERE Name = 'Target__windows'
   
   EXEC dbo.BeaconTargetPropertyValuePutByKeyNameBeaconTargetID
   	@KeyName = 'CUsageAgentUseAddRemove',
   	@BeaconTargetID = @btid,
   	@Value = 'true'
   
   -- Force beacons to update their policy to get latest settings
   EXEC dbo.BeaconPolicyUpdateRevision

Once the UseAddRemove preference has been set (and assuming the usage agent itself is enabled), you will start to see logging about usage of additional products & associated executables in the C:\WINDOWS\Temp\ManageSoft\usageagent.log file:

[12/18/2019 1:40:00 PM (G, 0)] {19592} Adding product 'Foo Bar' (priority 10) to product cache
[12/18/2019 1:40:00 PM (G, 0)] {19592} Adding directory 'C:\Program Files\FooBar' to product 'Foo Bar'
[...]
12/18/2019 1:40:46 PM (G, 0)] {19592} Session logging: KNOWN PRODUCT Session start (Path: C:\Program Files\FooBar\joe.exe, Product: Foo Bar, Product version: 1.2.3) Session will be added to cache on completion

I would be very interested to hear from anybody who is able to try this setting to see what extra usage data it enables you to gather in your environment. I suspect and hope it may help with gathering usage data for a range of Adobe products which are not covered by default. Please post your observations in reply to this thread.

[steve_young]

We have completed extensive testing with this setting and unfortunately it doesn't help with the Adobe applications, the problem is they are all installed in the same location on the device, so basically it detects the first Adobe application it finds and reports usage for that application,  but doesn't report on any other Adobe applications after this due to the fact the path is already assigned to the first application that was discovered.

So unfortunately it doesn't help for the reporting of usage for the Adobe CC products.

I believe the issue with the Adobe apps is going to be resolved in Q1 this year with the next release of FNMS

[ChrisG]

Thanks for the feedback Steve. The "multiple applications installed in the same directory" scenario that you describe is indeed a situation that arises with Adobe products. The way to deal with that is to ensure appropriate file evidence recognition rules for executables you want to track usage for is linked to application records in the ARL. The file evidence recognition rules will then be used to identify the usage instead of (or more strictly, as well as) the more limited/non-unique installer evidence that is referenced in the gathered usage data.

For example, imagine that applications A and B are both installed in C:\XYZ and you consider executable C:\XYZ\abc.exe to be part of application A. You will see usage of the A application being reported as long as you have a file evidence recognition rule for abc.exe linked to application A.

Assuming you also have installer evidence rules for A and B linked to applications A and B respectively, you will also see usage being reported based on one of those installer evidence records chosen [effectively] at random. It is possible that the record that is chosen is the wrong one (since the installer evidence is ambiguous with multiple applications installed in one directory), resulting in false positive reporting of usage.

I'm guessing in your testing scenarios  of particular Adobe CC products that file evidence recognition rules for the executables you were interested in were not linked to appropriate application records, and only installer evidence rules were in place.

An upcoming release of the inventory agent is likely to address the "false positive" usage reporting described above by not reporting installer evidence as part of usage data where multiple applications are installed to the same directory. However it won't remove the need to have file evidence recognition rules configured on application records in this scenario.

[steve_young]

Not quite the problem is the first application for example will report back as Photoshop.exe and from then on all other Adobe executable will not report back and will simply be listed as UnMappedExes and have no name to identify the application and match back to evidence.

I did have a call open for this and attached the logs that shows the usage agent doesn't map the exe's back after the first one.

[steve_young]

This is an example of the log that prevents it identifying the Adobe apps and comes once the first Adobe app is matched to the path

usageagent_qh11205368.log:[26/06/2019 10:58:57 AM (G, 0)] {3744} Session logging: UNKNOWN PRODUCT Session (Path: C:\Program Files (x86)\Adobe\Adobe Creative Cloud\ACC\Creative Cloud.exe, product is unknown) Session will not be added to cache.

I have attached the log from the usage agent that we submitted with the call we has open on this issue