Customized SMS Adapter Package Not Loading

[RobertH]

I have created a customized SMS adapter starting with the one provided by Flexera.  I did this by copying the SMS adapter to the ProgramData\Flexera Software\Compliance\ImportProcedures\ObjectAdapter\Reader directory on the beacon server.  I updated the logic as desired and am able to run the adapter.  The execution reports status to the WebUI tasks list as successful.  Sadly, FNMS is not actually getting the updated information.  The IntermediateData/SCCM connector_4398... directory is loaded with the correct information on the application/batch server.  I have verified the Computer--312--ReadComputerNames.ing.xml file contains the desired results.  But, the information is not ending up in FNMS.   I have also noticed that the zipped package file never gets removed: it will remain for months and fill up the hard drive.

I have also attempted to copy the customized SMS apapter to the ObjectAdapter\Reader directory on the application/batch server.  This did not resolve the situation.

Does anyone have ideas on how to get the batch server to successfully import the data?

[ChrisG]

The SCCM (SMS) adapter is an "inventory" adapter, not an "object" adapter. So customizations to this adapter should live under C:\ProgramData\Flexera Software\Compliance\ImportProcedures\CustomInventory\Reader\SMS\, not under the ObjectAdapter directory.

I am a little unsure about how to manage this sort of customization on beacons, but I think the right approach is to place the customized files on the processing (application) server then your beacon will automatically download them in due course when it updates its configuration.

Note that customization of inventory adapters like this is currently only possible to do with FlexNet On-Premises; it is not possible to customize the SCCM adapter with FlexNet Cloud.

[mfranz]

Also noteworthy: If you copy adapter folders by hand to "CustomInventory", make sure the "reader.config" is in the default "Inventory" folder as well. Example:

• C:\ProgramData\Flexera Software\Compliance\ImportProcedures\CustomInventory\Reader\SMS_custom\
  • Computer.xml
  • InstallerEvidence.xml
  • reader.config
  • User.xml
• C:\ProgramData\Flexera Software\Compliance\ImportProcedures\Inventory\Reader\SMS_custom\
  • reader.config

[MurrayPeters]

Just to clarify the distinction between Inventory and Object adapters:

Inventory adapters are 'global' in the sense that they are managed top down from the app (processing) server and are downloaded to all beacons. In a multi-tenant system this applies to all beacons for all tenants.
So, the master copy of the importer definitions should only ever be modified on the app server - any changes made locally on beacons will be overwritten by policy updates and FNMS does signature checking on receipt of uploaded inventory data to ensure the version of the procedures on the beacon that generated the payload are identical to those on the app server.  If the signature does not match the data is rejected.

Inventory adapters are located in the following directory on the processing server:
%ProgramData%\Flexera Software\Compliance\ImportProcedures\Inventory
%ProgramData%\Flexera Software\Compliance\ImportProcedures\CustomInventory

Object adapters are 'private' and are managed locally on a single beacon - they are not shared between beacons and don't appear on the app/processing server.    This allows a custom adapter to be developed for a single tenant/beacon and since it is local to the beacon there is NO signature checking, however the Object adapters must conform to the specification and return data in the very specific/expected structure.

Object adapters are located in the following directory on a beacon:
%ProgramData%\Flexera Software\Compliance\ImportProcedures\ObjectAdapters

-Murray

[RobertH · Accepted solution]

Thanks for the great advice.  I took the approach of making a backup the native SMS adapter in the Inventory directory.  I updated the SMS adapter, leaving it in the Inventory directory on the application server.  The adapter was propagated to the beacon server: in my case I only have one.  Then I run the integration from the Beacon application.  Success!

Success for me was determining the calculated user as the account with the most factored minutes on the machine.  The factor is a percentage that decreases the longer a person has not logged onto the machine.  It results in a factor of 10% after 5 days and 1% after 10.  This gives me more timely information when a machine has been used by 1 person for quite a while and then the machine is transferred to another person.

[mfranz]

Hi  Robert,

This sounds like a very interesting approach. Would you mind sharing a SQL snippet?

Best regards,

Markward

[RobertH]

The native integration takes the user with the greatest number of logons as the calculated user in the GetLastLoggedOnUserData step.

SELECT
    MachineID,
    SystemConsoleUser0 as UserName,
    SUM(NumberOfConsoleLogons0) AS NumLogins
...

I modified the SUM to use and exponential decay based on the number of days since the last logon.

SELECT
   MachineID,
   SystemConsoleUser0 as UserName,
   SUM(TotalUserConsoleMinutes0)*
      EXP(-1/2.1718 * 
      DATEDIFF(d,MAX(LastConsoleUse0),SYSDATETIME())) AS NumLogins

The value of 2.1718 gives me the rate at percentage decrease: i.e., 10% at 5 days and 1% at 10 days.