Summary

Information that will help you design and plan the implementation of Tachyon in your organization.

This page is part of the design phase of implementation.

Deploying Tachyon Agents without the full Tachyon infrastructure

If you are deploying Tachyon Agents to only support one or more of the following 1E products then you do not need a Tachyon license or any Tachyon servers:

  • Shopping 5.5
    • Tachyon Agent includes a Shopping module which must be enabled on all users's computers in order for them to use the 1E Shopping self-service solution
    • The Shopping module also include Windows Servicing Assistant (WSA) which guides users through the preparation and execution of an OS deployment
    • WSA has a further dependency on 1E Nomad 6.3.201 or later, and optionally requires 1E Application Migration (including SLA Platform) if you want to enable the WSA to migrate applications
  • WakeUp 7.2
    • Tachyon Agent includes a WakeUp module which must be deployed to computers as part of a 1E NightWatchman solution to support Wake-on-LAN

If you only require the above Agent features then you do not need to read the remainder of this page. Instead please review the relevant documentation for each of the highlighted 1E solutions.

If you also want to implement Tachyon real-time features and applications then you will need a full Tachyon infrastructure. The key design considerations for implementing Tachyon are explained on this page.


On this page:

Tachyon Architecture

You need to decide which architectures your Tachyon system will use, and which configuration options. You can install Tachyon Servers on physical or virtual servers, on-premises or in the AWS or Azure cloud.

The pictures below show the most common architectural implementations of Tachyon that are supported by Tachyon Setup. Organizations with less than 50000 devices will typically have a single-server system with one Switch, but there may be reasons why a more complex configuration would be required. Key factors are the location of servers and how devices and users will connect to them.

A Tachyon system consists of a single Master Stack and one or more Response Stacks, with optional DMZ Servers. Each Response Stack has a Tachyon Core component that supports an associated set of up to five Tachyon Switches, which is the primary mechanism for rapidly requesting and retrieving responses from the Tachyon Agents. As each Switch can handle up to 50000 devices there is a limit of 250000 devices per Response Stack.

The Tachyon Switches may be local or remote to the other components in the Response Stack. Tachyon, Catalog, SLA and BI databases are installed on SQL Server database instance(s) that may also be local or remote to their respective Master or Response Stacks. It is also possible for multiple Response Stacks to share the same Responses database. The BI cube is installed on a local or remote SQL Server Analysis Services (SSAS) instance.

The pictures of the single-server and internet-facing configurations each show a system with a single Response Stack. The internet-facing system is special because the components of its Response Stack are split over two servers. Splitting a stack across multiple servers is not usually necessary except in special circumstances such as in a DMZ. The DMZ picture shows a dual firewall design, but single firewall is also supported.

The databases for Tachyon Master and Response Stacks can exist on local or remote installations of SQL Server. Local is the simplest implementation. A local Responses database offers best performance, whereas a remote Responses database requires an additional network interface and network routing explained in Network interfaces below.

Tachyon can be installed on-premises on physical and virtual servers, and also on AWS and Azure cloud servers.

Click on a picture to enlarge. Click on a link to take you to the relevant part of the Tachyon Architecture page for more detail along with a description of the various components.

Tachyon Setup configuration choices

Tachyon Setup is a configuration wizard which must be run on each server in your architecture, to install the required components. Tachyon Setup supports the following types of installation:

  • All components on a single server - a single-server installation comprises Master Stack and Response Stack, and is the most common choice for a system of any size.
  • Master Stack - you would not normally install a Master Stack on its own, unless there are multiple Response Stacks sharing the same DNS Name, explained in DNS Names section below.
  • Response Stack - this choice allows you to install additional Response Stacks after you have completed a single-server installation or installed a Master Stack.
  • DMZ Server - this choice is used on when installing a DMZ Server. For design and configuration steps, please refer to the Implementing a Tachyon DMZ Server page.

The number of devices you need to support influences the number of Switches and Response Stacks you will need, and their server specifications. Each Switch can handle up to 50000 devices, and you can have up to five Switches on a single Response Stack server, handling a maximum of 250000 devices. 

For guidance on server sizing of on-premises and cloud based servers, supported server platforms, and software requirements, please refer to the Requirements page. 

Multiple Response Stacks provide a degree of high availability but are not intended for that purpose. Instead, Response Stacks are required for security, geographic or other network reasons. For example, because your organization covers multiple geographies and you do not want Agent traffic to go beyond the boundaries of each region, or because you have Internet-facing devices and need a Tachyon DMZ Server.

For an explanation of Tachyon components, please refer to Tachyon Architecture: Tachyon components.

There is also a custom installation option. Please contact 1E if you need a different setup to the ones described above.

Please contact 1E if you need use SQL Cluster, SQL Always On and other high availability solutions.

Applications and Tools

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

Tachyon Applications

The following are applications included in Tachyon 4.0.

  • Explorer - used to investigate, remediate issues and manage operations across all your endpoints in real-time.
  • Guaranteed State - ensures endpoint compliance to enterprise IT policies.
  • Patch Success -  reports on and ensures successful patching of your enterprise.
  • Settings - used to configure Tachyon system and application settings.

A typical Tachyon license will include these applications.

Tachyon Tools

The following are tools included in Tachyon 4.0.

  • 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, tah 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 by right-click extensions for the Microsoft System Center Configuration Manager console to run specific Tachyon instructions, and can also be used independantly as a command-line tool to execute API calls.
  • Tachyon Policy Tool - used to import Policy objects into the Guaranteed State application.

A typical Tachyon license will include these tools.

License requirements for consumer applications

For an application, tool or feature to work, the relevant consumer and prefix patterns must be registered in your license. The table below shows the consumers and prefix patterns that are typically included in a Tachyon license.

Application or FeatureConsumer namePrefix patternsWhere to obtain product pack instructionsNotes
Tachyon - ExplorerExplorer
  • 1E-Exchange-*
  • 1E-TachyonPlatform-*
  • 1E-Explorer-*
  • Third party and customer prefix patterns
  • Exchange product packs are available on the Tachyon Exchange.
  • The 1E-TachyonPlatform and 1E-Explorer-TachyonAgent product packs are included in the Tachyon Platform zip available on the Support Portal.

Explorer provides functionality to run, approve and schedule instructions, view Tachyon managed devices. Used to investigate, remediate issues and manage operations across all your endpoints in real-time.

If you want to use instructions developed by third parties, your own developers, or 1E developers on your behalf, then you must ask 1E to register the third party and customer prefixes in your license. Please refer to Developing your own instructions.
Tachyon - Guaranteed StateGuaranteedStateN/AN/AGuaranteed State ensures endpoint compliance to enterprise IT policies. The application allows you to manage rules and policies, and report on complaince.

NightWatchman - Online Status

NightWatchman
  • 1E-NWM-*
N/AThe Online Status feature does not require instructions. There are no product packs or instructions available yet for NightWatchman.
Nomad - Nomad Download PauseNomad
  • 1E-Nomad-*
  • The NomadBranchAdminUIExt.msi installer automatically installs these instructions if the installer account has relevent permissions.

The NomadBranchAdminUIExt.msi installer also automatically registers the Nomad consumer if the installer account has relevent permissions.

Tachyon - Patch SuccessPatchSuccess
  • 1E-PatchSuccess-*
  • The 1E-PatchSuccess product pack is included in the Tachyon Platform zip available on the Support Portal.

Patch Success provides a view of patching state of the estate as well as enabling users to deploy patches.

Required instructions need to be licensed as well. Three instructions are available in the Patch Success product pack and another one in the Tachyon Inventory product pack.

1E ITSM Connect
ServiceNowN/AN/A

1E ITSM Connect allows ServiceNow users to use any instruction that is permissioned for the 1E ITSM Connect app user role.

Tachyon - Settings
PlatformN/AN/AThe Settings app provides administration functionality of both SLA and Tachyon platforms. For example, permissions management, instruction set management, connector management, repository management, sync scheduling etc.
Tachyon Powered Inventory (Tachyon connector)Inventory
  • 1E-Inventory-*
  • The 1E-Inventory-ProductPacks product pack is included in the SLA Platform installation installed by Tachyon Setup. Note this also inscludes a PatchSuccess instruction.

This is not a new application rather an old SLA consumer that synchronizes inventory data from Tachyon.

Four instructions are available in the Tachyon Inventory product pack.

Tachyon - Configuration Manager UI extensions

CmConsoleExtensions

RunInstructionUI

  • 1E-ConfigMgrConsoleExtensions-*
  • The 1E-ConfigMgrConsoleExtensions product pack is included in the Tachyon Platform zip available on the Support Portal.
The Configuration Manager UI extensions is installed as part of The Tachyon Toolkit.
Additional consumers and tools can be developed by third parties, your developers, or 1E developers on your behalf. 1E must register their consumer names in the Tachyon license.

Infrastructure dependencies

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

All other communications from external devices use HTTPS, including Agent 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 Switch certificate - usually a exported version of the website certificate.
  • Agent certificate - each Agent uses the device's client certificate to authenticate itself to Tachyon Switches.
  • Certificate Revocation Lists (CRLs) - Tachyon Agents 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.

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

  • DNS - each Tachyon Server requires a DNS Name.
  • Active Directory - for installation and user accounts; Tachyon can be configured to use LDAP but uses GC by default.
  • IIS - a standard configuration required on each Tachyon Server.
  • SQL Server - for Tachyon Master and Response Stack databases.
  • 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

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.

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 you 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.

Please contact 1E if you require Microsoft SQL Clustering to be used.

Active Directory

Tachyon Servers must be domain-joined.

All Tachyon users require accounts in Active Directory. AD accounts must have their userPrincipalName (UPN) attribute populated. This 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.

Tachyon does not require any Active Directory security groups, however assigning AD security groups to System Roles is strongly recommended, and for any custom roles as explained in the Roles page. This is especially useful for the Server installation account which is a system role that cannot be modified. If the installation account needs additional roles then these can be assigned to an AD security group.

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

AD security groups must be Universal, not Global.

Please contact 1E if you require a DMZ Server that is not domain-joined.

Networking and DNS requirements

Network interfaces

A Tachyon single-server installation with one Switch, requires only one network interface (IP Address) to handle all incoming and outgoing traffic. Each additional Switch also requires its own network interface. If the Tachyon Responses database is not local, and the server supports more than 500 devices, then it is recommended to have an additional network interface in order to keep incoming Switch and outgoing SQL traffic apart for performance reasons. The network traffic for a Master Stack is significantly less than a Response Stack therefore the Master Stack does not have any additional network requirements.

Number and speed of server network interfaces

The following conditions apply to network interfaces, which must be configured before installing Tachyon on a server.

  • One network interface is required for each Switch, with a minimum speed of 1Gbps. Switch interfaces can be on the same or different subnets.
  • An additional network interface is recommended to ensure optimum performance of a Response Stack if it serves more than 500 devices and the TachyonResponses database is on a remote SQL Server. It should have a minimum speed of 1Gbps, or 10Gbps if the Response Stack has 3 or more Switches. Network routing on the Response Stack server must be configured so that SQL traffic is routed over this interface. This interface should not register its IP Address in DNS.
  • An additional network interface is recommended on a DMZ Server, so that an external facing interface is used for incoming response traffic from Tachyon Agents to Switches, and an internal facing interface is used for outgoing response traffic from Switches to the Core on the internal Tachyon Response Stack. The simplest way to ensure the internal interface is used for outgoing response and other traffic is for both interfaces to be on different subnets with no routing between them. All network interfaces on a DMZ Server should have a minimum speed of 1Gbps.

Each network interface must be assigned a static IP Address. Tachyon Setup supports installation using IPv4.

If you have a working IPv6 environment, then please contact 1E for advice on using that.

For the remote SQL Server requirement, please refer to Preparation: Configuring a persistent route for SQL traffic. However please ensure you also consult your server, firewall and networking teams.

Network impact

Most of the network traffic experienced by a Tachyon system is compressed responses from Agents to Switches. Responses to Tachyon instructions are returned by online Agents 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.

Agents also download content from a Background Channel, which is a website hosted on the same server as Switches. Agents deliberately delay their download for up to 5 mins (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 Agent Resources and Nomad Integration below.

WAN caching

Communications between Agents 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 Agents and the Background Channel can be cached, however please refer to Downloading Agent Resources and Nomad Integration as an alternative to WAN caching.

Isolated Networks

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

Each Tachyon Agent device must have a network connection to a Switch and Background Channel, with the necessary network firewall ports open. If Agents 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:

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 Server components installed requires its own DNS Name. The Master Stack enables Tachyon users, approvers and administrators to connect to the Tachyon Portal, therefore, it helps users if it has a recognizable and convenient DNS Name such as tachyon.

Tachyon Agents need to connect to Switches and the Background Channel using a DNS Name FQDN defined in the Agent's configuration file. A single-server installation only needs one DNS Name. A Master Stack and Response Stack can only share the same DNS Name if both are installed on the same server. If the server has multiple Switches, and therefore multiple network interfaces, then the same DNS Name can be shared by all Switches, the Background Channel and Master Stack.

The same DNS Name would be used by all the Switches on a Response Stack, but it can also be shared across multiple Response Stacks provided the Name is not also shared with the Master Stack. For this reason, a datacenter serving more than 300000 devices would have two Response Stack servers using the same DNS Name (eg. tachyonrs), and a dedicated Master Stack server using a different DNS Name (eg. tachyon).

A DMZ Server is a special case which needs two DNS Names, an internal DNS Name for the internal network interface, and an external facing DNS Name which may be shared by multiple external facing Switch network interfaces.

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

Each DNS Name used to access a Tachyon Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the Tachyon Server service account in Active Directory. This allows Tachyon web applications that use Windows Authentication to authenticate clients.

Downloading Agent Resources and Nomad Integration

Agents download resources from the Background Channel. These resources are modules, providers, scripts, and other dependencies. In most cases, these resources are version controlled.

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

1E Nomad is normally used with Microsoft System Center Configuration Manager to speed up deployment of software and updates to Windows PCs and reduce the number of Distribution Point servers without impacting the network. Nomad Agent is installed on PCs and they automatically elect an Agent to download content from a Distribution Point over the WAN and then peer-share the content with other PCs at that location. The downloaded content is cached locally on each PC in case it is needed again.

Tachyon can use Nomad to download content from Tachyon Background Channel servers irrespective of whether Nomad is integrated with Configuration Manager or using advanced Nomad features that use ActiveEfficiency.

Nomad Integration disabled

If Nomad integration is not used, then Tachyon Agent waits a randomized stagger period defined by its DefaultStaggerRangeSeconds setting, and then downloads content (Agent resources) from the specified Background Channel.

Tachyon Agent 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 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 Tachyon Agent.

With the Nomad integration feature enabled, Tachyon Agent will detect if Nomad v6.0.100 or later version is running on the device.Tachyon Agent immediately requests Nomad to download content ( Agent resources) from the specified HTTP source such as the Agent's Background Channel. Nomad behaves in the same way as it does with ConfigMgr 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 (Agent resources) is not provided within the timeout period, the Agent 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 Tachyon Agent configuration file and is specified during installation of the Agent. The Agent 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 ConfigMgr Distribution Points that are configured to validate device certificates).

With 1E Nomad v6.0.100 and .200 Tachyon uses Nomad to download directories only, and can only download some Agent module folders.

With 1E Nomad v6.1.100 and later, Tachyon uses Nomad to download both directories and files, and therefore supports download of all Agent resources.

Agent deployment

You will need to plan the deployment of Tachyon Agents using whichever software deployment tools you have. For details of interactive and command-line installation, please refer to Deploying Tachyon Agents.

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

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

The Tachyon Agent is supported on the following Windows OS:

Windows

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows 10 CB 1903
  • Windows 10 CB 1809
  • Windows 10 CB 1803
  • Windows 10 CB 1709
  • Windows 10 CB 1703
  • Windows 8.1

Professional and Enterprise editions of Windows 10 are supported.

All versions are provided with 32-bit & 64-installers.

Can be installed on physical and virtual computers.

A service is installed called 1E Tachyon Agent with a small footprint.

The Tachyon Agent is supported on the following non-Windows OS:

macOS

  • macOS Mojave 10.14
  • macOS High Sierra 10.13

Linux

  • CentOS 7
  • Red Hat Enterprise Linux 7.1
  • SUSE Linux Enterprise (SLES) 12
  • Ubuntu 14.04

Solaris

  • Solaris 11.3

Android

  • Android Pie 9.0
  • Android Oreo 8.1
  • Android Oreo 8.0

Other versions of these Operating Systems should work but have not been tested by 1E.

The Tachyon Agent is available for download from the 1E Support Portal, for the following architectures:

  • Linux variations on Intel 64-bit platforms
  • Solaris on Intel 64-bit and SPARC platforms
  • Android ARM

Also included in the download are Tachyon Agents for the following legacy Linux distributions:

  • Fedora 21
  • openSUSE Leap 42.1

Tachyon Agents for other Linux distributions can be requested, including Raspbian for Raspberry Pi, and Debian.

Developing your own instructions

If you want to develop your own custom Tachyon instructions, or modify those of other authors, then you will need to sign them using your own code signing certificate so that they can be licensed, imported and run in your Tachyon system. You don't need to do this for instructions that are provided with the product or that have been downloaded from the Tachyon Exchange as they've already been code signed and licensed using the Platform and Exchange certificates from 1E.

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 organisations 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.