Applications and Tools

Tachyon applications and tools are consumers, and all consumers connect to the Tachyon Consumer API. 

Tachyon Applications

The following consumer applications run on Tachyon Platform and are installed using Tachyon Setup. See License requirements for consumer applications.

The following types of application require 1E Client (with Tachyon features enabled) to be deployed to all in-scope devices.

• All Client applications
• Inventory applications if you intend using the Tachyon connector to populate your inventory, because this depends on the Tachyon client features of the 1E Client.

The AI Powered Auto-curation feature is optionally used by Inventory applications to provide automatic curation of new products. This avoids having to manually add products to the 1E Catalog, or wait for it be updated. This optional feature requires additional memory on the Tachyon Server (Master Stack). Please refer to AI Powered Auto-curation: Memory requirements for details.

Some benefits of using AI Powered Auto-curation are that you can:

• Achieve significantly more normalized software from the first sync
• Reduce the manual effort required to normalize software
• Get an expanded SAM offering as more data is available for AppClarity
• Get additional coverage for Application Migration
• Identify more software to review for security threats.

Tachyon Tools

The following are tools included in Tachyon Platform. These tools are not installed using Tachyon Setup. They have either their own installers or are included in download zips.

• Tachyon Configuration Manager UI extensions  - installed as part of the Tachyon Toolkit, this is a right-click extension for the Microsoft System Center Configuration Manager console that provides a graphical user interface for the user to browse and run an instruction on devices in a specified Collection
• Tachyon Run Instruction command-line tool - installed as part of the Tachyon Toolkit, it is used for sending instructions to the Tachyon server from a script or from a command prompt
• Tachyon Product Pack Deployment Tool - included in the Tachyon Platform zip ProductPacks folder
• Tachyon Instruction Management Studio)  - used for development of Tachyon instructions using the Tachyon SDK.

A typical Tachyon license allows use of all these tools.

Telemetry

Telemetry (introduced in Tachyon Platform 5.1) helps 1E to continually improve your experience with Tachyon. Only summarized statistical information is collected which enables 1E to see how customers use features of the application. No personally identifiable data is collected. 1E use this information to:

• Understand how the product is being used to influence future development decisions
• Plan supported platforms (OS, SQL etc. versions) over time
• Deliver a smooth upgrade experience as we can focus testing on implemented scenarios
• Improve system performance
• Identify early warning signs of potential issues such as excessive growth of database tables, instruction failures etc. so we can pro-actively address them.

Full details of the data sent to 1E is provided in Telemetry data. The information is compressed, encrypted and sent to 1E through email on a configurable schedule. 

The feature is enabled by default but may be disabled using Tachyon Setup during installation or upgrade, and can be enabled or disabled as a post-installation task. 1E encourages customers to enable sending telemetry, to help us build better products.

License requirements for consumer applications

For any application, tool or feature to use instructions, its consumer and prefix pattern must be registered in your license. The table below shows the consumers and prefix patterns that are typically included in a Tachyon license. The table also includes other applications where instructions - and therefore licensing - is not applicable. Tachyon expects to find the license file in: %PROGRAMDATA%\1E\Licensing on your Tachyon (Master Stack) Server.

Infrastructure dependencies

PKI and certificates

Client-Switch communication uses WebSocket Secure protocol, whereby each Tachyon client establishes a secure link to the Switch which is then used by the Switch to send instructions to the Tachyon client. This is shown as a dotted line in the pictures in the Communication Ports page.

All other communications from external devices use HTTPS, including Tachyon client connecting to the Background Channel in order to download resources that may be required by instructions, and using the Tachyon Portal to administer and use the system.

All communication is encrypted, which requires a Public Key Infrastructure (PKI). More specifically, PKI is required for:

• Tachyon web server certificate  - prerequisite for each Tachyon Server website, must contain all the DNS Names used for the server
• Tachyon Server certificate  - usually an exported version of the website certificate
• Tachyon client certificates  - each Tachyon client uses the device's client certificate to authenticate itself to Tachyon Switches
• Certificate Revocation Lists (CRLs) - Tachyon clients and Switches use HTTP-based CRL Distribution Points to validate certificates
• Code signing certificates - used for signing custom and modified instructions, so they can be imported into Tachyon and then run
• Digital signing certificates  - used for signing 1E software

Miscellaneous

In addition to PKI and network requirements, other infrastructure dependencies are:

• DNS - each Tachyon Server requires a DNS Name, this is also useful for ActiveEfficiency Server if it is installed
• Active Directory - for installation and user accounts and groups; Tachyon supports multi-domain, multi-forest environments that have two-way trusts
• IIS - a standard configuration required on each Tachyon Server
• SQL Server - for Tachyon Master and Response Stack databases, Catalog SLA and BI databases, and ActiveEfficiency if installed
• SQL Analysis Services - must be installed in multi-dimensional mode, for Business Intelligence (SLA BI cube) required by Patch Success
• Email - optional for approval and notification emails, but required if using two-factor authentication (2FA)
• Internet access - the Master Stack requires access to the 1E license service via the Internet in order to keep the Tachyon license activated, and 1E Catalog requires access to the 1E Catalog Cloud service to download Catalog updates

For more detail on these infrastructure dependencies, please refer to the Requirements page.

Infrastructure dependencies that require design decisions are listed below.

Email and two-factor authentication

You will need to decide if you want to use the Email and two-factor authentication features.

If the 2FA feature is enabled, Tachyon users are prompted to enter a one-time authentication code in addition to their password in order to confirm they want to submit an action instruction. 

The one-time authentication code is sent to the user by email. The two-factor authentication feature requires email.

Please refer to Tachyon Server post-installation tasks: Enabling or disabling Two-factor Authentication.

SQL Server

You will need to decide if Tachyon databases are installed locally or on remote SQL Server instance(s).

Databases that are remote from their Tachyon Servers increase the complexity of design and installation in the following ways:

• Tachyon Server installation depends on the server installation account having appropriate rights on the SQL Server instance. Remote SQL Servers are typically run on farms managed by other teams who may not want to grant permissions to your installation account.
• If a Response Stack serves over 500 devices then you will require an additional network interface, which requires network routing as described in Network interfaces below.

You will need to regularly backup the Tachyon Master database. The Tachyon Server can be re-installed from scratch using the existing database or a restored backup.

There is no requirement to backup the Tachyon Responses database because it only contains transient data. You can backup and restore the Responses database if that is your organization's preference for recovery.

Microsoft SQL Server Express is not supported for either Master or Responses databases, due to its limitations.

For details about configuration and sizing of Tachyon databases please refer to Requirements: SQL Server requirements.

You will also require SQL Server Analysis Services if you are using Experience or Patch Success applications.

Active Directory

Tachyon Servers must be domain-joined.

Each Tachyon user requires an account in Active Directory. AD accounts must have their userPrincipalName (UPN) attribute populated, which is normal, but may be missing if users accounts have been created using scripts.

Tachyon users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-factor Authentication is enabled.

Active Directory security groups are strongly recommended for role-based access control (RBAC) but are not mandatory. AD security groups can be assigned to Tachyon roles after installation, they are not required during installation. They are added as Tachyon users and configured in the same way as AD user accounts. A Tachyon user can therefore be a domain user account or a security group. Groups are not mandatory because users can be assigned to roles and managed within Tachyon instead of AD, or a combination.

Tachyon Setup assigns a limited set of permissions to the server installation account, as described in Tachyon user permissions, which cannot be edited. However, the installation account's permissions can be extended if the account is a member of one or more AD Groups configured as Tachyon users.

An AD security group is also useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog.

Networking and DNS requirements

Network interfaces

Network impact

Most of the network traffic experienced by a Tachyon system is compressed responses from Tachyon clients to Switches. Responses to Tachyon instructions are returned by online Tachyon clients in a matter of a few seconds. Tachyon is designed for speed without impacting your network.

The Response Stack's Core then processes and stores uncompressed responses in the Tachyon Responses database. If the database is remote then this will create significant network traffic when saving responses, but normally this will be within a datacenter. Even so, a dedicated interface is recommended on each Response Stack for connection to a remote SQL Server in order to prevent network contention between incoming and outgoing response traffic.

Other network traffic generated by Tachyon is low by comparison. Tachyon Explorer is a single page application which uses paging to view responses.

Tachyon clients also download content from a Background Channel, which is a website hosted on the same server as Switches. They deliberately stagger the delay of their download for up to 5 minutes (configurable). By using 1E Nomad you can avoid the staggered delay on Windows PCs without impacting your network. For further information about 1E Nomad please refer to Downloading content and Nomad integration below.

WAN caching

Communications between Tachyon clients and Switches should not be cached or delayed, which can be prevented by excluding the Switch port(s) or the IP Addresses of Switch interfaces on caching devices.

Communications between Tachyon clients and the Background Channel can be cached, however, please refer to Downloading content and Nomad integration as an alternative to WAN caching.

Isolated Networks

Tachyon can operate in a multi-domain, multi-forest environment with Tachyon client devices on internal and external networks, supporting internal and external Certificate Authorities.

Each Tachyon client device must have a network connection to a Switch and Background Channel, with the necessary network firewall ports open. If Tachyon clients are unable to connect to the Tachyon Server on the corporate network, then it is necessary to install additional Tachyon Servers.

Firewall ports

For details of firewall ports and different types of network traffic, please refer to the Communication Ports page where you can find the following:

• Communication Ports: Firewall requirements for a Single-Server Installation
• Communication Ports: Firewall requirements between Tachyon Servers
• Communication Ports: Firewall requirements when hosting a Tachyon Switch and Background Channel in a DMZ

DNS Names

The correct choice of DNS Name(s) for your Tachyon Servers is perhaps the most fundamental decision you will make. 

Each server that has Tachyon platform components installed requires its own DNS Name.

The number of DNS Names used by a system depend on the location of Tachyon and other Platform services. The table below describes options.

Tachyon Setup supports installation of one HTTP and one HTTPS binding, but you can manually add more bindings after installation. HTTPS bindings can share a web server certificate provided it includes all DNS Names, or each HTTPS binding can have its own certificate.

Each DNS Name used to access a Tachyon Server must be included as a DNS Name in the Subject Alternate Name (SAN) entry of the web server certificate, and the Switch certificate files.

A DNS Name can be a DNS alias, CNAME or Host (A) record.

Tachyon Platform and applications use underlying IIS and SQL Server technology, and only require HTTP or MSSQLSvc class SPNs if your company security policy has configured IIS or SQL Server to use Kerberos authentication. 

If your IIS server is using Kerberos, then each DNS Name used to access a Tachyon Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the relevant service account in Active Directory, which is computer$ by default. This allows Tachyon web applications to authenticate clients using Windows Authentication where Kerberos is an authentication provider (primary, fallback or negotiated).

SPNs are not required for DNS Names used to connect to Switches and Background Channel, because they do not use Windows Authentication. However, the same DNS Name may be used to access other web applications.

Downloading content and Nomad integration

Tachyon client downloads content from the Tachyon Background Channel. Content is mainly scripts and other files required by Tachyon instructions. It also includes client resources such as extensible modules, providers, and other dependencies to maintain the 1E Client. In most cases, client resources are version controlled to prevent repeated downloads. Tachyon instructions always request a download even if they have run an instruction before, unless the content for that instruction has been cached in memory.

You may need to consider the impact on the network if there is a large amount of content included in an instruction. This is more of an operational consideration instead of a design consideration.

1E Nomad is an optionally licensed component of the 1E Client. It makes software deployment, patching and downloading content more efficient and reduces the impact on the network. It removes the need for remote Distribution Point servers in Microsoft System Center Configuration Manager systems. When Nomad is installed on computers it automatically elects a peer to download content from a server over the WAN and then peer-shares the content with other PCs at the same location. The downloaded content is cached locally on each PC in case it is needed again.

Tachyon can optionally use Nomad to download content from servers irrespective of whether Nomad is integrated with Configuration Manager or not, and also uses advanced Nomad features which use ActiveEfficiency.

Nomad integration disabled

If Nomad integration is not used, the following apply:

• Tachyon client waits a randomized stagger period defined by its DefaultStaggerRangeSeconds setting, and then downloads content from the specified Background Channel.
• Tachyon client retains modules and extensibles that it has downloaded, but does not retain instruction scripts after they have been run. Any instruction that requires a script or other file will download the latest version each time the instruction is run.

Nomad integration enabled

Nomad integration is available on Windows PC devices and is enabled by default, but can be disabled during installation of the 1E Client.

With the Nomad integration feature enabled, Tachyon client will detect if a supported version of Nomad is running on the device.

• Tachyon client immediately requests Nomad to download content from the specified HTTP source such as the Background Channel. Nomad behaves in the same way as it does with Configuration Manager by ensuring the latest version of content is obtained and electing a master to perform the actual download.
• Nomad maintains its own cache of downloaded content which avoids the need for repeat downloads over the WAN, and provides content to peers that require the same resources which avoids peer devices having to download over the WAN.

• If the Nomad integration feature is enabled, and requested content is not provided within the timeout period, the Tachyon client will fall back to downloading directly from the HTTP source. The most likely reason for a timeout is if Nomad is busy downloading other content.

To use Nomad, there is no special configuration of Tachyon Servers. The Background Channel is a web application on the Tachyon Server which uses HTTPS and default port is 443. The URL for the Background Channel is defined in the 1E Client configuration file and is specified during installation of the 1E Client if Tachyon features are enabled. The Tachyon client passes this URL to Nomad when it requests content to be downloaded. Instructions can also specify other HTTP sources.

Nomad does not need to be configured to use certificates in order to communicate with the Background Channel (the Nomad CertIssuer and CertSubject settings are used only with Configuration Manager Distribution Points that are configured to validate device certificates).

Nomad Single-Site Download (SSD) feature uses ActiveEfficiency Server to further reduce the impact downloading content over the WAN.

1E Client deployment

You will need to plan the deployment of 1E Client (with Tachyon features enabled) using whichever software deployment tools you have. For details of interactive and command-line installation, please refer to Deploying Tachyon clients.

Tachyon features require client certificates. For more detail, please refer to Requirements: Tachyon client Certificates.

Below are lists of supported OS Platforms, but please also refer to Requirements: Constraints of Legacy OS. 

Developing your own instructions

You will need your own code signing certificate, and have it registered in your Tachyon license, if you want to develop your own custom Tachyon instructions, or modify those of other authors. Instructions that are provided in the Tachyon Platform zip or downloaded from the Tachyon Exchange have already been code signed using the Platform and Exchange certificates from 1E. Your Tachyon license controls whether you can use these instructions.

Ideally all of your Tachyon instruction developers should share a single code signing certificate between them. Each code signing certificate must be registered in your Tachyon license and associated with your organization's instruction name prefix. When you have chosen your prefix and have your code signing certificate(s) you then need to send details of these to 1E, who will update your Tachyon license. This will then automatically activate on your Tachyon Server (assuming it has connection to the Internet).

For a detailed step-by-step process, please refer to Setting up custom Tachyon Instructions for the first time.

The Tachyon SDK is where you can find comprehensive resources for developing your instructions.

You can also download Product Packs containing more instructions from the Tachyon Exchange, and ask questions in the Tachyon Forum.