Introducing Tachyon Platform
An overview of Tachyon Platform is presented; what it does and how it can benefit your organization.
Tachyon real-time features
Introduction
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 Platform.
Broadly speaking, installing Tachyon is done in two steps:
Install Tachyon Server onto an appropriate Windows server with IIS installed.
Install a Tachyon client onto each of the devices you want to manage.
Add Instruction Definitions to Tachyon Server
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, 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 (https://tachyonexchange.1e.com). Each Product Pack contains a related collection of Instruction Definitions.
Full details of adding Instruction Definitions into Tachyon 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 -Guaranteed State 8.1 - Uploading Integrated Product Packs.
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 in the Users and Groups page and the Roles page.
Sending instructions - asking questions and performing actions
Using the Tachyon Explorer questions can be asked of the 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 Tachyon Explorer 8.1: Explorer Home page, questions and responses.
Using the Tachyon Explorer, actions can be performed on the 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 Tachyon Explorer 8.1: The action approval 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 the Tachyon users. Tachyon provides coverage, question filters and view filters.
Coverage is applied before a question is asked and reduces how many Tachyon client devices get asked the question. Coverage uses the device properties that are sent by a Tachyon client when it connects to Tachyon.
Question filters are applied at the Tachyon client after the question has been asked and use the attributes from the question responses to determine whether the Tachyon 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 Tachyon Explorer 8.1: Coverage, question filters and view 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 in the picture opposite.
For more information see Tachyon Explorer 8.1: Refining responses with follow-up questions and Tachyon Explorer 8.1: Performing an action - tutorial.
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 Tachyon Explorer 8.1: Explorer Home page, questions and responses.
Basic Instruction flow
The picture opposite shows the basic flow of Tachyon Instructions between the Tachyon components. For simplicity the workflow section, where the Instruction is authenticated and verified, has been omitted.
The basic Instruction flow is:
A Tachyon Consumer initiates an Instruction via a request to the Consumer API.
The Consumer API stores the Instruction in the Tachyon Master database.
The Instruction is authenticated and verified by the Workflow and becomes ready for processing by the Core.
The Core relays the Instruction to the Switch.
The Switch transmits the Instruction to the appropriate connected Tachyon clients.
The Tachyon clients process the Instruction on their devices and produce responses in real-time.
The Tachyon clients pass the responses to the Switch, intelligently minimizing bandwidth utilization.
The Switch relays the responses to the Core.
The Core stores the responses in the Tachyon Responses database while intelligently minimizing the amount of data and maximizing speed of retrieval.
The Consumer API fetches the responses from the Tachyon Responses database and makes them available to the Consumer.
The Tachyon architecture has been designed to 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 the Tachyon 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 via an alternative mechanism using the Tachyon 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:
A Tachyon Instruction Set Administrator loads an Instruction definition with an associated script, or other sizable resource, into Tachyon using Tachyon Explorer.
The Consumer API copies the script or resource to the Background Channel.
The Consumer API stores the Instruction and resource in the Tachyon Master database.
After the Instruction has been loaded into Tachyon:
A suitably permissioned Tachyon Questioner or Actioner requests the Instruction.
The Instruction request flows through the Tachyon components as normal.
This time, when the Instruction gets to the Tachyon clients, they know that they need to download the Instruction's script or resource in order to process the Instruction.
The script or resource is downloaded from the Background Channel using HTTPS.
If 1E Nomad is installed on the Tachyon client device it will be used for the download, providing all its download optimization features to speed up the process.
Once the script or resource file has been downloaded to the Tachyon client device it processes the Instruction and returns the responses made as a result of using the script or resource.
The responses flow back through the Tachyon components as normal.
Tachyon Inventory and Catalog features
Introduction
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.
The Inventory app captures data from different sources, then consolidates, normalizes and stores it in Inventory repositories.
Describes the AI Powered Auto-curation feature that improves software inventory results.
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. The Tachyon platform uses a standard format of Vendor, Title, Version and Edition 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 Application Migration 8.1 and reclaim rules in AppClarity 8.1.
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.