Summary

Connects the Tachyon and SLA components to support Management group and Tachyon Powered Inventory features. The Tachyon Powered Inventory feature uses instructions to fetch inventory data from Tachyon clients, and is a prerequisite for Patch Success.

This configuration procedure assumes you will always use the Tachyon Connector to synchronize Management groups, and optionally import data for the Tachyon Powered Inventory feature.

The following steps are always required:

  • Create a Tachyon user for account ACME\SLATACHYON with Management Group Sync Initiators role
  • Configure the Tachyon Connector to provide Management Group Synchronization
  • Test the connector.

The following steps are only required if intending to use the Tachyon Powered Inventory feature:

  • Create an instruction set called 1E Inventory, and upload its instructions
  • Create a custom role called 1E Inventory Questioners, assign questioner permission on the instruction set, assign to All Devices, and add the Tachyon user as a role member
  • Execute the Tachyon Connector Sync Data action.

To understand synchronization, please refer to How Management Group Synchronization works. For information about how to configure and use Management groups please refer to Management groups page.

Tachyon Powered Inventory is used to populate an inventory repository with inventory and usage data by using instructions which collect data from Tachyon clients. It is required by the Patch Success application. For details of how these instructions are used, please refer to How Tachyon Powered Inventory works.

Prerequisites

Before adding the Tachyon connector, you will need the following:

  • A domain user account  dedicated for use by the Tachyon connector, that will be configured as a Tachyon user. This is effectively like a service account. In our examples this is ACME\SLATACHYON this account will need to be assigned to the following Tachyon roles:
    • Management Group Sync Initiators
    • Global Questioners
  • A Tachyon user with Global Administrator role permissions, to configure the connector and related tasks.
  • Alternatively a user with the following more granular role permissions:
    • If the connector is only used to support Management groups, then your administrator will need the following role permissions:
      • Connector Administrators role in order to add or configure the connector
      • Permissions Administrators role in order to create the above Tachyon user
      • Log Viewers role to aid troubleshooting (optional)
      • Management Group Administrators to create and update Management groups (optional).
    • If the connector is also used to support the Tachyon Powered Inventory feature then your administrator will also need the following:
      • Instruction Set Administrators role to upload the Tachyon Inventory Product Pack instructions and assign them to a new instruction set
      • Inventory Administrators role to populate an inventory repository
      • Schedule Administrators role to schedule a Sync using the connector.

If the connector is to be used to support the Tachyon Powered Inventory  feature then you will also need:

  • The Tachyon Inventory Product Pack for Inventory instructions used to get data from Tachyon clients
  • An appropriate Tachyon License to permit using Tachyon connector inventory instructions. This is normally included in a standard Tachyon license.

The Tachyon Powered Inventory feature is a prerequisite for Patch Success.

On this page:

Creating the user

These steps create the Tachyon user required by the Tachyon Connector and assigns it to the Management Group Sync Initiators system role.

You need a domain user account in Active Directory, in our example this is ACME\SLATACHYON.

  1. Logon to the Tachyon Portal using a Tachyon user account with a Permissions Administrators role.
  2. Open the Settings application.
  3. Navigate to the Settings→Permissions→Users page.
    1. Click on the Add button, doing this displays the Add user popup.
    2. In the Select user field type the name, or part of the name, for the Active Directory user or security group that you want to add. A list of matching names will be retrieved from Active Directory and displayed as you type, these are filtered so that users or groups that have already been added do not appear.
    3. Select the Active Directory user or security group from the list of matching names displayed in the drop-down list. In our example this is ACME\SLATACHYON.
    4. Click Add.
  4. On the Settings→Permissions→Users page, click on the user's name link for ACME\SLATACHYON.
    1. On the User: SLATACHYON page click the Edit button to display the Edit roles assigned to user popup.
    2. Select Management Group Sync Initiators.
    3. Select Global Questioners.
    4. Click the Save button.

Configuring the Tachyon connector

These steps add and test a Tachyon connector:

  1. Navigate to Settings→Configuration→Connectors
  2. Click on the Add button.
  3. In the Add connector popup select the Tachyon type. 

  4. In Connector name enter a logical name for this connector. 

    You should use a naming convention for connector names:

    <connector type> <scope> <RCR>

    Scope describes where data is coming from or what it's being used for. For example Demo, Test, Lab, Q2 Audit.

    Include RCR in the name if you have enabled Run Consolidation Reports.

  5. In URL, enter location of the Tachyon consumer, in following format

    https://<TachyonDNSAliasFQDN>/consumer

    Please note that, as stated above /consumer must be included in the URL, in the same way that Tachyon needs to be added to <TachyonDNSAliasFQDN> when a Tachyon users browses to the Tachyon Portal.

    In our example the URL is https://tachyon.acme.local/consumer .

  6. In User Name, enter the name of the Tachyon user that has permission to run the Tachyon Inventory instructions. In our example this user is ACME\SLATACHYON.
  7. In Password, enter the password for this account.
  8. Leave the other fields empty.
  9. Check the Run Consolidation Reports checkbox if you want consolidation actions to be processed each time the Sync Data action is executed for the connector.

    This can lead to unnecessary processing if you enable this on more than one connector. The recommended method of processing consolidation actions is to schedule the action Generate Report - Basic Inventory Consolidation to execute after the Sync Data actions have run for all connectors. This will execute the remaining consolidation actions. Alternatively check the Run Consolidation Reports checkbox on one of your connectors. You can view action processes in Settings→Process log.

  10. Click Add.

You should then test the connector:

  1. Select the connector you want to test from the list of Connectors by checking the box at the left-hand end of the connector's row.
  2. Click the Test button.
  3. The Test status column for the connector will display a clock icon  indicating that the test has been queued for executing.
  4. If the test succeeds Test status will display a check icon  and the Last tested column will display the date and time the test succeeded.
  5. If the test fails the Test status will display a failed icon  and you'll need to check the details you entered for the connector.

If you have access to the Process log you can see an entry for the Test action.

The test confirms if the Tachyon User Name is assigned to the necessary Tachyon roles:

  • Management Group Sync Initiators
  • Global Questioners

Creating the 1E Inventory instruction set

These steps are only required if:

  • you have not already loaded the 1E Inventory Product Pack using the Product Pack Deployment tool as part of the Tachyon Setup process
  • you will be using Tachyon Powered Inventory

The steps show how to create an instruction set called 1E Inventory.

The 1E Inventory instruction set will contain the 5 instructions listed in the following table: 

Instruction text (ReadablePayload)TypeDescriptionData to Sync categoryInstruction file nameVersion

Which processors are in the device? With a stagger of <limitSecs> seconds.

Question

Processor details

Uses  Device.GetProcessors  method.

 Click here to expand details of data collected...


Method

GetProcessors

ModuleDevice
LibraryCore
Action

Retrieves information about the CPUs plugged in to the motherboard of the device.

Parameters(None)
Return values

Vendor (string): The vendor of the processor

Name (string): The vendor-defined name of this processor package

CoreCount (int): The number of cores inside this package

SpeedMhz (int): The clock speed of the processor in its current operating mode

From v5.1 onwards these columns also appear :

LogicalCoreCount (int) : The number of logical cores inside this package

Hyperthreading (bool): Indicates whether the cores are hyperthreaded, true for yes, false for no.

Example
 Device.GetProcessors();
Platforms
  • Windows
  • Linux
  • MacOS
  • Solaris Intel
  • Solaris Sparc
Notes

Name is the immutable string that the CPU reports to SMBIOS. This often contains the publicly marketed and sold average speed of the CPU, which usually differs to the actual speed of the processor instance.

SpeedMhz on Windows can change over time for one particular CPU. Modern CPU's can adjust their clock in response to heat and power from moment to moment. This parameter cannot be relied upon for scoping future instruction executions unless some kind of range of values is in the scope to cope with natural speed variance.

Processor
1E-Inventory-Device-GetProcessors
3

Inventory - what is the summary of file usage since <startDate>? With a stagger of <limitSecs> seconds.

Question

Process Usage data inventory for SLA

Uses the  $ProcessUsage_Daily inventory table, if Module.Inventory.ProcessUsage.Enabled setting is true (default) in the 1E Client configuration file.

Please refer to 1E Client 5.2 - Tachyon client settings: Capture source settings.

 Click here to expand details of data collected...

Windows only. The following table shows fields available in the $ProcessUsage_Daily table.

FieldDatatypeDescriptionSample valueTables
CommandLinestringThis is a single instance of the command used to launch that instance, most probably the first one. It will not contain any differences if other instances are launched with a slightly different comand line. It is an indication of a typical command line for this instance.C:\Program Files\Git\mingw64\libexec\git-core\git-credential-manager.exe
DurationintegerThe number of minutes covered by the individual execution(s) of at least one instance of this executable.
Duration can never be more than 1440 minutes, being the number of minutes in a day.
1
ExecutableHashstringThe MD5 hash of the binary that contains the entry point (usually an exe)ad3ec70ae9e82582bdf6aa6fd5811376
ExecutableNamestringThe name of the binary that contains the entry point obtained from stamped version information where possible, the filename if not.git-credential-manager.exe
ExecutableSizeintegerThe size of the binary that is hashed below 131168
ExecutableVersionstringThe version information stamped into the executable where available.1.5.0.0
ExecutionCountintegerThe number of instances observed during the Duration period2
IsOSProcessinteger

A value of 1 indicates that this is categorised as an operating system by the rules in place.

A value of 0 indicates that it is not.

0
LastSeeninteger

The UTC Timestamp of when the last instance of the executable (of all the accumulated subjects of this record) was last seen (polling) or actually exited (events).

Whilst any instance is running, for the current day records, LastSeen will creep across the day and duration will increase as time passes if the process remains running.

Once midnight is crossed then the daily records for yesterday are 'closed off' by setting LastSeen = TS + 86400 (the number of seconds in a day), which is midnight of the next day.

If all instances of one binary are exited and never run again that day, then the LastSeen field for that daily record should 'stick' at one value and never ever change again.

In other words the maximum difference between TS and LastSeen in a single row is at most 86400, being the number of seconds in a day.

Tracking of an execution summary from one day to another ("carry-over") can be achieved by looking for a record based on TStomorrow = LastSeentoday with all the other key information the same. If that exact key record with the 'carry over' conditions is not found then the process did not theoretically continue across midnight.

Note that a process that dies after 23:59:00 and starts before 00:01:00 the next day will appear to be a continuous process in the summary tables. Even though it could theoretically have stopped for nearly two minutes. This is because the resolution of the table is to the start of the minute the event occurred in.

1526982245
TSinteger

When the record was added to the table. See Timestamps.

Midnight UTC that is the start day of the 24 hours covered by this record.

1526947200

The Tachyon client captures executable usage; this is from the moment the executable is turned into a process, hence the process usage. The Process Usage data presented is grouped by executable binary, and parallel runs are accumulated in the ExecutionCount, but not in the Duration, where coverage time period is desired instead.

Software Usage
1E-Inventory-FileUsageSummary
3

Inventory - what software is installed? With a stagger of <limitSecs> seconds.

Question

Software inventory for SLA

Uses a combination of:

 Click here to expand details of data collected...


Method

GetInstallations

ModuleSoftware
LibraryCore
Action

Gets a list of the installed software available to all users, optionally filtered by product and/or publisher.

Parameters

Product (string; optional): If specified, search for just this product.

Publisher (string; optional): If specified, get just this publisher's software.

Return values

A table of:

    • Product (string): The product name.
    • Publisher (string): The publisher of the product.
    • Version (string): The version of the product.
    • InstallDate (string): If available, when the product was installed.
    • Architecture (string): Platform architecture of this installation (e.g. x86, x64)
Example

Get all software:

 Software.GetInstallations();

Find and remove all installed instances of Calculator Plus:

Software.GetInstallations( Publisher : "Microsoft", Product : "Microsoft Calculator Plus");
evaluate;
Agent.Echo( Message: "Is installed");
Software.Uninstall( Publisher : "Microsoft", Product : "Microsoft Calculator Plus");

To select a specific version, use a SQL WHERE clause:

@installs = Software.GetInstallations( Publisher : "Microsoft", Product : "Office Professional");
SELECT DISTINCT * FROM @installs WHERE Version LIKE "16.0%";
Platforms
  • Windows
  • Linux
  • MacOS
  • Solaris Intel
  • Solaris Sparc
  • Android
Notes

To find additional software installed for specific users, use Software.GetUserInstallations.


Method

GetUserInstallations

ModuleSoftware
LibraryCore
Action

Gets a list of the software installed for specific users, optionally filtered by product and/or publisher.

Parameters

Product (string; optional): If specified, search for just this product.

Publisher (string; optional): If specified, get just this publisher's software.

Return values

A table of:

    • Architecture (string): Platform architecture of this installation (e.g. x86, x64)
    • InstallDate (string): If available, when the product was installed.
    • Product (string): The product name.
    • Publisher (string): The publisher of the product.
    • Sid (string): The user identifier for whom this software has been installed.
    • Username (string): Friendly representation of the Sid - this will only be resolved locally.
    • Version (string): The version of the product.
Example

Get all user specific software:

 Software.GetUserInstallations();
Platforms
  • Windows
Notes
  • Sid resolution may fail as this method will not go over the wire. In this case Username will be NULL.
  • The file modified and accessed time attributes of the NTUSER.dat directory entries under the %USERPROFILE% folder for each user and service principal might be updated to some time during the execution of this method. This is a side effect of loading and unloading the user hive and is housekeeping performed by Windows, not the 1E Client. This can cause "unused" profiles to appear to be used if the modified times are employed to determine whether a user has logged in, which is not a reliable method of establishing this fact.

  • This method reads user uninstall registry keys from HKU, but will not load hives.
  • Installs for this function are retrieved from HKU:\<SID>\Software\Microsoft\Windows\CurrentVersion\Uninstall

Installed Software
1E-Inventory-Software
3

Inventory - summary of which users have logged on since <startDate>? With a stagger of <limitSecs> seconds.

Question

User data inventory for SLA

Uses the  $UserUsage_Daily  inventory table, if Module.Inventory.UserUsage.Enabled  setting is true (default) in the 1E Client configuration file. Top Console User is also calculated from this table.

Please refer to 1E Client 5.2 - Tachyon client settings: Capture source settings.

 Click here to expand details of data collected...

Windows only. The following table shows fields available in the $UserUsage_Daily table. 

FieldDatatypeDescriptionSample valueTables
Durationinteger

The number of minutes covered by the individual user session(s) of at least one instance of this login.

Duration can never be more than 1440 minutes, being the number of minutes in a day.

12
  •  $UserUsage_Daily
EmailstringThe email address that is cached in the system for this user. This may not necessarily be the email address to use to contact the user via corporate email.abrown@acme.org
  •  $UserUsage_Daily
FirstNamestringThe forename that the system has cached for the user.Alice
  •  $UserUsage_Daily
LastNamestringThe surname that the system has cached for the userBrown
  •  $UserUsage_Daily
LastSeeninteger

The UTC Timestamp of when the last instance of the user session (of all the accumulated subjects of this record) was last seen (polling) or actually exited (events), rounded down to the start of the minute in which the event occurred.

Whilst any session is in progress, for the current day records, LastSeen will creep across the day and the duration will increase as time passes if the user remains logged in. That is Duration and LastSeen will increase each time you query the table (with at least a minute between queries).

Once midnight is crossed then the daily records for yesterday are 'closed off' by setting LastSeen = TS + 86400 (the number of seconds in a day), which is midnight of the next day.

If all users sessions for one user are exited and never occur again that day, then the LastSeen field for that daily record should 'stick' at one value and never ever change again.

In other words the maximum difference between TS and LastSeen in a single row is at most 86400, being the number of seconds in a day.

Tracking of a user session summary from one day to another ("carry-over") can be achieved by looking for a record based on TStomorrow = LastSeentoday with all the other key information the same. If that exact key record with the 'carry over' conditions is not found then the user session did not theoretically continue across midnight.

Note that a session that exits after 23:59:00 and starts again before 00:01:00 the next day will appear to be a continuous user session in the summary tables. Even though it could theoretically have not existed for nearly two minutes. This is because the resolution of the table is to the start of the minute the event occurred in.

See Timestamps.

1526990846
  •  $UserUsage_Daily
SIDstringThe Windows NT SID of the user.S-1-5-21-xxx-yyy-zzz
  •  $UserUsage_Daily
TSintegerWhen the record was added to the table. See Timestamps.1526947200
  •  $UserUsage_Daily
Usernamestring

The user account name, with a domain prefix if applicable.

For Windows devices not a in a domain, the 'domain' is the local machine name. For non-Windows devices such as Linux there is no domain part.

aliceb

acme\AliceBrown

  •  $UserUsage_Daily

The Tachyon client captures user sessions (usage); this is from the moment the user instigates a login/logout, hence User Usage. The usage data presented is grouped by SID and Username, and parallel login durations are really the coverage of the time period, not the total time for all the individual sessions.

User and administrator accounts are included, either local or remote. System accounts, and accounts used to run services, are excluded. 

User
1E-Inventory-UserUsageSummary
3

Returns patch status for 1E Inventory consumption, staggering for <limitSecs> seconds.

The 1E-PatchSuccess-PatchStatus instruction is not required if you do not intend using the Patch Success application, and will not run if you do not have a license for Patch Success. For more information about configuring Patch Success please refer to Configuring Patch Success.

This instruction is part of this 1E Inventory instruction set used by the Tachyon Connector. Do not move it to the 1E Patch Success instruction set used by the buttons visible in the Patch Success application.

QuestionReturns patch status for 1E Inventory consumption

Patch

1E-PatchSuccess-PatchStatus
5.0

You can use the Product Pack Deployment tool to simultaneously Upload the instructions and Create the Instruction set, or use the manual steps below.

These instructions are included in the 1E Inventory product pack, available in the TachyonPlatform.v5.x.x.x.zip file downloaded from the 1E Support Portal.

Upload the instructions

First upload the instructions:

  1. Download the TachyonPlatform.v5.x.x.x.zip file from the 1E Support Portal .
  2. Extract the 1E-Inventory.zip from the Classic folder
  3. Logon to the Tachyon Portal using a Tachyon user account with the Permissions Administrators and Instructions Administrators roles.
  4. Open the Settings application.
  5. Navigate to the Settings→Instructions→Instruction sets page.
  6. Click on the Upload button.
  7. In the Open dialog navigate to the location of the 1E-Inventory.zip file.
  8. Select 1E-Inventory.zip and click Open.

Create the instruction set

All the instructions contained in the zip file will initially be added to the default Unassigned instruction set. Instructions in the Unassigned instruction set cannot be used, so first you will need to create a new instruction set with the verification instructions.

  1. Select the 5 instructions you want to add to the new set, by clicking the checkbox at the start of each instruction row in the list.
  2. Click the Add new set button in the button panel to the right of the page.
  3. In the Add new instruction set popup subsequently displayed, and type:
    1. 1E Inventory as the name.
    2. Tachyon Powered Inventory as the description.
  4. Ensure that the Include 5 selected instructions checkbox is checked.
  5. Click the Add button to add the new instruction set, with the selected instructions.

Configure the Tachyon Connector

Follow the steps in Configuring the Tachyon connector and then return to Executing the Tachyon Connector Sync Data action.

Executing the Tachyon Connector Sync Data action

These steps are only required if you will be using Tachyon Powered Inventory. When you've finished setting up the Tachyon connector you will then need to synchronize it to populate an inventory repository with the data from Tachyon.

You can execute the Tachyon Connector Sync Data action in the same way as other connectors, manually or using a schedule, however the Tachyon connector manages its actions differently to other connectors.

First, you should run the Sync Data action manually to confirm it works, in particular to test the user permissions and its ability to run the instructions.

For our Tachyon example, you will be running the Sync Data - Tachyon action on the default inventory repository called Default inventory. You can select which Data to Sync. The data categories displayed are dependent on the type of connector. For Tachyon, you can select from the following, each corresponds to an instruction, which run in sequence for a duration of 15 minutes (by default). The exception is Device, which does not run an instruction, but instead gets device data directly from the TachyonMaster database.  

  • Device
  • Installed Software
  • Processor
  • User
  • Patch
  • Software Usage

When you schedule the Sync Data - Tachyon action to run automatically instead of manually, ensure you do not schedule to run more frequently than the duration for the 1E Inventory instructions. To understand why, please refer to How Tachyon Powered Inventory works.

You can review the results as they come in by reviewing the instruction history.

  1. Switch to the Explorer application.
  2. Navigate to the Instructions→History page.
  3. Observe that all 5 instructions are running with a duration of 15 minutes. Any devices coming online during that period will respond.
  4. Click on any of the 5 instructions to review the response content and status.

If you want to review in detail the data that was imported into the inventory repository, navigate to the Tachyon→Inventory Application pages:

  1. The Inventory→Hardware→Hardware Inventory page shows software details retrieved from the devices that have Tachyon clients.
  2. The Inventory→Hardware→Device page shows hardware and OS details for devices that have Tachyon clients. 
  3. The Inventory→Software Inventory→Product Usage page shows the software product usage that has been retrieved from devices that have Tachyon clients.

The above data from Tachyon clients may be consolidated with data from other inventory sources using their inventory connectors.

How Management Group Synchronization works

The SLA components are responsible for storing information about management groups, including group definitions and membership in the SLA databases. Tachyon maintains a synchronized copy in the Tachyon Master databases. Whenever SLA Engine evaluates group membership and it detects changes it notifies Tachyon by initiating a sync. Tachyon Coordinator service receives the sync, fetches the changes, and updates the Tachyon Master database. To contact Tachyon, the SLA Engine uses the URL of the Consumer defined in the Tachyon Connector and the Network Service account is a member of the Tachyon system role Management Group Sync Initiators role.

Membership evaluations occur whenever an inventory repository is updated by a manual or scheduled Connector Sync Data action, or the Evaluate button is pressed, as described in the Management groups page.

How Tachyon Powered Inventory works

1E Inventory instructions

The Tachyon connector works differently compared with other connectors. Other connectors import data in a single operation, whereas a Tachyon connector sync issues a set of instructions, and then runs a two-phase process to gather the data. The default gather period behavior is controlled using settings for the inventory repository in the SLA-Data database. These must not be changed unless otherwise instructed by 1E.

When a Tachyon connector sync is actioned, either manually using Create a new action, or as a scheduled sync, the following happens.

  1. The SLA Engine polls Tachyon to retrieve the information that is routinely sent back by the connected devices
  2. The SLA Engine asks Tachyon to run each instruction
    • Each instruction runs for 15 minutes, known as a  gather period
    • Tachyon sends each instruction to all devices at the same time
    • Devices respond immediately if they are online, or catch-up shortly after coming online
    • Each device will respond only once to each instruction during the gather period
    • Each instruction has a short random delay before the device sends its response back to the Tachyon server
    • Responses are stored in the Tachyon database and only deleted at the end of the gather period plus a 60-minute keep period
  3. The SLA Engine polls Tachyon 
    • The poll is 15 minutes after starting the instruction run, and fetches all the responses gathered so far
    • Data is stored in the inventory repository, and kept after the Tachyon deletes its copy of the data.

Devices only appear in the inventory repository if they respond, or if they have previously responded to a previous sync.

Tachyon has minimal impact on the network and client devices when the instructions are run and responses are sent back to the Tachyon server. The low impact is further reduced by the random delay used by each instruction.

During each poll there is a small performance impact on the Tachyon server (master stack) and SLA components, when the initial responses are processed, and when the deltas are processed for subsequent polls, for other machines coming online.

How to schedule your Tachyon connector syncs

This is not a precise science, but here are some points you might want to consider when deciding what schedule you want to set for your Tachyon connector syncs:

  • As we've described under 1E Inventory instructions, the Tachyon instructions run for 15 minutes and poll all the devices that are connected to Tachyon during that time.
  • You must avoid creating overlapping schedules, but that's not difficult when there is only a 15 minute window where that can occur.
  • You should aim to run the Tachyon connector sync when most of your devices are online and connected.
  • If you have a global organization you need to consider the best time to synchronize in all the time zones covered by the devices in your network. 

For example, you might consider that 2PM in the afternoon is a good time when most of the devices in each timezone are connected to Tachyon. If you had an organization with offices in Noida India, London UK and New York USA you could set a daily schedule for each that ran the Tachyon connector sync at 2PM local time. As the schedules run on UTC time that would lead to the following:

  • Noida (IST) = UTC + 5, so 2PM IST is 9AM UTC 
  • London (GMT) = UTC + 0, so 2PM GMT is 2PM UTC 
  • New York (EST) = UTC - 5, so 2PM EST is 7PM UTC

So three daily schedules would be needed at 9AM, 2PM and 7PM respectively.  You should also set the schedules to  not perform a Clean Sync  so that the data from the 3 sites accumulates. You may have your own estimations for the times when the most devices are connected to your network but you can see how the example is a reasonable place to start planning your schedules to maximize the amount of coverage for the devices in your network. For more information on configuring schedules please refer to the Schedules page.

Tachyon client configuration

Process and User usage capture is available only on Windows devices.

Tachyon Agent for Windows version 3.2 or later, or 1E Client 4.1 or later is required, with the following Tachyon client features enabled:

  • Module.Inventory.Enabled=true (default, and this setting is visible in the 1E Client configuration file)
  • Module.Inventory.ProcessUsage.Enabled=true (default - in 3.3 this was also true by default, but in 4.0 it was false by default)
  • Module.Inventory.UserUsage.Enabled=true (default)

For more detail about configuring these and other settings in 1E Client, please refer to Tachyon client settings: Inventory module settings.

Tachyon License details

Ensure your Tachyon License file has the Inventory consumer enabled and includes the pattern for 1E-Inventory-*

You can view your Tachyon license details using either of the following methods:

  • in the Tachyon Admin web portal, under License info, look in the Products section and expand Features and instruction items
  • in the license file Tachyon.LIC found in C:\ProgramData\1E\Licensing

If the pattern does not exist, then the 1E-Inventory instructions will not run. You may have an old version of Tachyon, or your license needs to be updated.

   <Features>
      <Feature name="TachyonPlatform">
        <Consumer name="Inventory" enable="on"></Consumer>
        <Instructions signersha="F08386A5318A8187D79B0A58253C65CB4E442570" pattern="1E-Inventory-*"> </Instructions>
        ...
      </Feature>
      ...
      ...
      ...
    </Features>