Skip to main content

1E 8.1 (on-premises)

Introducing Tachyon

An overview of the Tachyon is presented; what it does and how it can benefit your organization.

Tachyon real-time features


Tachyon is a systems management tool that turns the traditional systems management model on its head. It is based on the concept that a device is aware of its own current state more accurately than any centrally held repository. Also, if you can query the device directly then the need to store masses of data becomes unnecessary.

Implement Tachyon

To implement Tachyon you need to design, install and verify your installation. Full details can be found in Planning for Tachyon.

Broadly speaking, installation is done in two steps:

  1. Install Tachyon onto an appropriate Windows server with IIS installed.

  2. Install a 1E Client onto each of the devices you want to manage.

Intro - Install Tachyon
Add Instruction Definitions to Tachyon

Using the Tachyon administration console, import Instruction Definitions into Tachyon. An Instruction Set Administrator can load Instructions by dragging and dropping one or more Instruction Definition files onto the interface. The Instruction Definitions may also be grouped together in a zip file, known as a Product Pack, and added in a single operation.

When uploaded, the administrator then assigns the instructions to one or more Instruction Sets. The administrator also assigns permissions to Instruction Sets to control who can ask questions, and perform and approve actions, as well as assigning Management Groups to control which devices the instructions can be sent to.

1E provides a number of Product Pack zip files available in the Tachyon Platform Product Packs zip (available on the 1E Support Portal) and from the Tachyon Exchange ( Each Product Pack contains a related collection of Instruction Definitions.

Full details of adding Instruction Definitions can be found in Instruction sets page.

Integrated Product Packs provide ready-made policies for Guaranteed State but also include instructions. To upload these, please refer to -Uploading Integrated Product Packs.

Intro - Add Instruction Definitions
Assign permissions for Tachyon administrators and users

Following on from installation you then assign permissions to particular users corresponding to the Tachyon administration roles and instruction set questioner, actioner, approver, and viewer roles.

Full details of assigning permissions for Tachyon administrators and users can be found on the Users and Groups page and the Roles page.

Intro - Assign Permissions
Sending instructions - asking questions and performing actions

Using Tachyon Explorer questions can be asked of Tachyon client devices by users with the questioner or actioner roles. The responses can be viewed by viewers, questioners and actioners.

Details on asking questions can be found in ExplorerHome page, questions and responses.

Intro - Asking Questions

Using Tachyon Explorer, actions can be performed on Tachyon client devices by users with the actioner role on an instruction set, subject to the following:

  • They will need to enter their password

  • If the action has been configured to use two-factor authentication, they will need to enter the authentication code

  • They will need the approval of someone other than themselves with an approver role.

Details on performing actions and the approval workflow can be found in The action approval workflow.

Intro - Actions Workflow
Coverage and filters

You can use coverage and filters to reduce the amount of network traffic caused by asking a question. They are also useful in reducing the amount of data that is presented to Tachyon users. Tachyon provides coverage, question filters, and view filters.

  • Coverage is applied before a question is asked and reduces how many client devices get asked the question. Coverage uses the device properties that are sent by a client when it connects to Tachyon.

  • Question filters are applied to the client after the question has been asked and use the attributes from the question responses to determine whether the client should send the response.

  • View filters are applied in the Tachyon Explorer after the responses have been sent and reduce the responses that are displayed.

For more information see Coverage, question filters and view filters.

Intro - Coverage and Filters
Performing follow-up questions and actions

You can perform a follow-up question or action after a previous question has been asked. Each follow-up causes the previous questions to be re-asked to detect any real-time changes. Any coverage, question, and view filters are applied to the responses, as shown.

For more information see Refining responses with follow-up questions and Performing an action - tutorial.

Intro - Performing a follow-up action
Real-time Tachyon

Tachyon works in real-time, so not all the devices may be connected at the time a question is asked. Tachyon questions have a configurable duration that they will gather data for - allowing devices that connect later, within the gather data for duration, to respond.

Questions also have a configurable keep answers for duration - given that the answers from a live network can potentially get stale quickly, and Tachyon questions are fast enough that you can simply ask again rather than relying on old answers.

Details on asking questions can be found in ExplorerHome page, questions and responses.

Intro - Real-time Tachyon
Basic Instruction flow

The picture shows the basic flow of Tachyon Instructions between its components. For simplicity, the workflow section, where the Instruction is authenticated and verified, has been omitted.

The basic Instruction flow is:

  1. A Tachyon Consumer initiates an Instruction using a request to the Consumer API.

  2. The Consumer API stores the Instruction in the Tachyon Master database.

  3. The Instruction is authenticated and verified by the Workflow and becomes ready for processing by the Core.

  4. The Core relays the Instruction to the Switch.

  5. The Switch transmits the Instruction to the appropriate connected Tachyon clients.

  6. The Tachyon clients process the Instruction on their devices and produce responses in real-time.

  7. The Tachyon clients pass the responses to the Switch, intelligently minimizing bandwidth utilization.

  8. The Switch relays the responses to the Core.

  9. The Core stores the responses in the Responses database while intelligently minimizing the amount of data and maximizing the speed of retrieval.

  10. The Consumer API fetches the responses from the Responses database and makes them available to the Consumer.

Tachyon architecture has been designed for the sending of Instructions and gathering of responses for thousands of devices in seconds.

Content delivery

To maximize the speed of Instruction delivery and gathering responses from its clients, Tachyon keeps the size of Instructions to a minimum fixed size. If you want to run an Instruction that requires a script or other sizable resource in order to carry out its functionality, this is made available using an alternative mechanism using the Background Channel.

The first step in the content delivery process actually occurs before the Instruction is used when the Instruction containing the resource is first loaded into Tachyon:

  1. An Instruction Set Administrator loads an Instruction definition with an associated script, or other sizable resource, into Tachyon using Explorer.

  2. The Consumer API copies the script or resource to the Background Channel.

  3. The Consumer API stores the Instruction and resource in the Tachyon Master database.

After the Instruction has been loaded into Tachyon:

  1. A suitably permissioned Tachyon Questioner or Actioner requests the Instruction.

  2. The Instruction request flows through the Tachyon components as normal.

  3. This time, when the Instruction gets to clients, they know that they need to download the Instruction's script or resource in order to process the Instruction.

  4. The script or resource is downloaded from the Background Channel using HTTPS.

  5. If Nomad is installed on the client device it will be used for the download, providing all its download optimization features to speed up the process.

  6. Once the script or resource file has been downloaded to the client device it processes the Instruction and returns the responses made as a result of using the script or resource.

  7. The responses flow back through the Tachyon components as normal.

Tachyon Inventory and Catalog features


Tachyon is a systems management tool that turns the traditional systems management model on its head. It is based on the concept that a device is aware of its own current state more accurately than any centrally held repository. Also if you can query the device directly then the need to store masses of data becomes unnecessary.

Inventory features

Inventory captures data from different sources, then consolidates, normalizes, and stores it in Inventory repositories.

AI Powered Auto-curation

Describes the AI Powered Auto-curation feature that improves software inventory results.

Manage associations

Applications and Packages in Configuration Manager are identified by a name and optionally publisher and version arbitrarily determined by the Configuration Manager administrator that created them. Tachyon uses a standard Vendor, Title, Version, and Edition format to identify applications.

The Manage Associations section of Inventory enables an administrator to effectively normalize the Applications and Packages imported from Configuration Manager by associating them with a Vendor, Title, Version, and Edition defined in the 1E Catalog. These associations are then used to define migration rules in Introducing Application Migration and reclaim rules in Introducing AppClarity.

1E Catalog is a prerequisite for installing the SLA components of Tachyon. SLA uses 1E Catalog to normalize or match source inventory information, for example, software devices and processors.

1E Catalog allows you to:

  • Have a consistent view of your estate

  • Uniquely identify software deployed in your estate

  • Identify device types (laptop, desktop, virtual machine), operating system, device family, device manufacturer, and maximum number of processors

  • Normalize processor information like processor model, processor family, vendor name, and number of cores of processors running on your devices

  • Define and apply bundling rules to identify suites and their components

  • Define and apply entitlement rights, such as version upgrade/downgrade, edition downgrade, and software assurance rights which are used during license demand and compliance calculations

  • Apply autofill entitlement information using software SKU.