Information that will help you design and plan implementing Tachyon in your organization.

This page is part of the design phase of implementing.

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.

Components colored green are optional when installing a Tachyon system.

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 opposite and 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.

Every Tachyon system has a single Master Stack, which provides web services for Tachyon applications. Master Stack components are typically all installed on a single Master Server.

Tachyon real-time features require Response Stacks, which are made up of one or more Response Servers. A DMZ Server is an example of a Response Server. Each Response Stack has at least one Background Channel for sharing resources, and a single Core component that supports an associated set of up to five Switches. Switches are the primary mechanism for rapidly requesting and retrieving responses from the Tachyon clients. As each Switch can handle up to 50,000 devices there is a limit of 250,000 devices per Response Stack. Higher numbers can be achieved if you contact 1E for guidance. Switches may be local or remote to the other components in the Response Stack.

Databases for Tachyon, Catalog, Content Distribution, Experience, SLA and BI, are installed on SQL Server database instance(s) that may also be local or remote to their respective Master and Response servers. It is also possible for multiple Response Stacks to share the same Responses database. Cubes used by Experience and BI are 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, for example the Switch and Background Channel on a DMZ Server is remote from its Core. 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 the 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.

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, which is the most common choice for a system of any size supporting Tachyon real-time features.
  • Master Stack - you would install a Master Stack on its own if you do not require Tachyon real-time features, or you want one or more remote Response Stacks.
  • Response Stack - this choice allows you to install a Response Stack after you have completed a single-server installation or installed a Master Stack, and is required to support Tachyon real-time features.
  • DMZ Server - this choice is used on when installing a DMZ Server to provide Tachyon real-time features for Internet-facing clients. 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 Tachyon client 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 to use high availability solutions, including SQL Cluster or SQL Always On.

1E Business Intelligence

Business Intelligence is an optional component installed by Tachyon Setup on the Master Stack, and requires SQL Server Analysis Services (SSAS). Business Intelligence is a prerequisite for the Patch Success application to support efficient presentation of visualizations on a large scale.


Tachyon Setup supports optional installation of Content Distribution to support Nomad. Content Distribution replaces the ActiveEfficiency Server and provides the following features (introduced for Nomad client in 1E Client 5.2) but continues to support legacy Nomad clients (before Nomad 7.1) that have not yet been upgraded to 1E Client 8.0.

For Tachyon 4.1 onward Tachyon Setup optionally supports platform features for Nomad.

For Tachyon Platform 5.2 onwards this is Content Distribution, and the Nomad app, both installed using Tachyon Setup. In the earlier versions of Tachyon, this was ActiveEfficiency, which is replaced by Content Distribution.

Nomad uses Content Distribution for the following features:

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 Design Considerations: License requirements for consumer applications.

Inventory 8.0View and export inventory, and manage associations.Inventory, configuration
Settings 8.0Configure and monitor platform features.Configuration
AppClarity 8.0Manage software license compliance, License Demand Calculations, license entitlements, and for reclaiming unused software.Inventory
Application Migration 8.0Intelligently automate the migration of applications during a Configuration Manager OS deployment.Inventory
Experience 8.0Measure performance, stability and responsiveness for applications and devices to assess user experience across your enterprise.Client

Explorer 8.0

Investigate, remediate issues and manage operations across all your endpoints in real-time.Client
Guaranteed State 8.0Ensure endpoint compliance to enterprise IT policies.Client
Nomad 8.0

Manage content distribution across your organization using a centralized dashboard.

1E Client requires Tachyon and Nomad features to be enabled on all clients.

Patch Success 8.0

Reports on and ensures successful patching of your enterprise.

Requires SLA Business Intelligence to be installed by Tachyon Setup, as described in Design Considerations: Business Intelligence. It also needs connectors to get meta-data for patches from whichever of the following that you use to approve patches:

  • Configuration Manager (SCCM) if it is configured to manage WSUS
  • Windows Server Update Services (WSUS).

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.

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 8.0. These tools are not installed using Tachyon Setup. They have either their own installers or are included in download zips.

  • Tachyon ConfigMgr UI Extensions - installed as part of the Tachyon Toolkit, this is a right-click extension for the Configuration Manager console that providing the option 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 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.

Server telemetry (introduced in Tachyon Platform 5.1) reports how the platform is used and data is compressed, encrypted and sent to 1E through email on a configurable schedule. Full details of the Server telemetry data sent to 1E is provided in Server telemetry data.

User Interface telemetry (introduced in Tachyon Platform 5.2) reports how the user interface is used and data is sent directly from administrator browsers to the 1E Cloud.

Please refer to Requirements: Whitelisting connections to1E Cloud for details of URL that must be whitelisted for administrator browsers.

Telemetry features are configurable 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.

Please also refer to Tachyon Server post-installation tasks: Enabling or disabling Telemetry features.

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.

Application or FeatureConsumer namePrefix patternsWhere to obtain the Product PackNotes

You will need prefixes for any Tachyon instructions and you want to use, including custom prefixes for your own and/or third party.

Included in the base Tachyon license are:

  • 1E-Exchange-*
  • 1E-Explorer-*
  • 1E-TachyonPlatform-*

Explorer application 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.

You cannot create or update instructions using other prefixes because they must be signed by others.

Guaranteed StateGuaranteedState

You will need prefixes for any Guaranteed State fragments you want to use, including custom prefixes for your own and/or third party.

Included in the base Guaranteed State license are:

  • 1E-Explorer-*
  • 1E-GuaranteedState-*

Guaranteed State requires licensing for its instruction fragments from v5.1 onwards.

  • Tachyon Platform zip available on the Support Portal includes the following Integrated Product Packs (which contain Policies for Guaranteed State):

    There is no content with the specified labels

Guaranteed State application ensures endpoint compliance to enterprise IT policies. The application allows you to manage rules and policies, and report on compliance.
  • 1E-Inventory-*
  • Tachyon Platform zip available on the Support Portal includes the following classic Product Pack and instruction set:
    • 1E Inventory includes 1E Inventory instructions for Tachyon Powered Inventory

Inventory application is used to view and export inventory, and manage associations (new in 5.0).

Inventory data can be captured from various sources using connectors. Data is consolidated, normalized and stored in inventory repositories. The Tachyon connector is one method of collecting data, and this uses four inventory instructions which are available in the 1E Inventory Product Pack. This pack also includes another instruction used by Patch Success.

The 1E-Inventory Product Pack replaces 1E-Inventory-ProductPacks previously included in the installation of the SLA component of the Tachyon platform.

SettingsPlatformN/AN/AThe Settings application is used to administer Tachyon. For example, permissions management, instruction set management, connector management, repository management, sync scheduling etc.
  • Tachyon Platform zip available on the 1E Support Portal includes the following classic Product Packs and instruction sets:

Tachyon Experience helps you visualize your end-users' experience of IT service delivery across your enterprise.

It is centered around the experience score, which is based on metrics that cover four categories:

  • Stability - derived from the frequency of operating system and software crashes, hangs and service failures.
  • Responsiveness - based on the speed of operating system startup, system resource creation and availability.
  • Performance - a weighted indication of load and throughput for device processor, memory and disk resources.
  • Sentiment - an aggregated measurement of users feelings or opinions of their device's performance, stability and responsiveness based on user surveys.


AppClarity is a Tachyon application aimed at Software Asset Management (SAM) users, helping you get to grips with software waste, take control of license compliance and manage application portfolios easily. It offers an immediate reduction in software costs by helping you manage your software assets on desktops more effectively and maintain software license compliance.

The main benefits of using AppClarity are:

  • Software license compliance – provides at a summary on whether a particular product is license compliant or not
  • Efficient management of entitlements and agreements for an organisation
  • Software waste identification – shows unused or rarely used software which are probably the two largest form of software waste and enables to reclaim
  • License Demand based on different metrics for vendors
  • Efficient application management – identifies version sprawl where there are many versions of the same product in use.

Now, you can financially quantify all software waste by identifying and controlling unused software across your enterprise and improve your compliance status.

Patch Success

  • 1E-PatchSuccess-*

Patch Success is a Tachyon application that lets you maximize success of enterprise-wide patch deployment. It provides a view of patch state of your estate, as well as supplementing your existing patch deployment methods.

Required instructions need to be licensed as well as the consumer. Three instructions are available in the 1E Patch Success Product Pack and another one in the 1E Inventory Product Pack.

Tachyon ConfigMgr UI Extensions



  • 1E-ConfigMgrConsoleExtensions-*
The Configuration Manager Console extensions is installed as part of The 1E Tachyon Toolkit.

Tachyon Run Instruction (command-line tool)


You will need prefixes for any Tachyon instructions you want to use, including custom prefixes for your own and/or third party.

The Tachyon Run Instruction command-line tool is installed as part of The 1E Tachyon Toolkit.
1E ITSM ConnectServiceNowCore

You will need prefixes for any Tachyon instructions you want to use, including custom prefixes for your own and/or third party.

N/A1E ITSM Connect (with 1E Core) provides a User Interface in ServiceNow similar to Tachyon Explorer, that allows ServiceNow users to use any instruction that is permissioned for the 1E ITSM Connect app user role.

1E Service Catalog Connect

ServiceNowCoreYou will need prefixes for any Tachyon instructions you want to use, including custom prefixes for your own and/or third party.
1E Service Catalog Connect (with 1E Core) provides a User Interface in ServiceNow similar to the 1E Shopping app portal, that allows ServiceNow users to use any instruction that is permissioned for the 1E ITSM Connect app user role.
Application Migration and WSSNomadN/AN/A

Application Migration intelligently automates the migration of applications during a Configuration Manager OS deployment. Using migration rules (defined by an administrator), previously installed applications can be reinstalled, upgraded or replaced with an alternative during an OS deployment task sequence.

These rules can include usage criteria, allowing you to choose to only install previously installed applications if they were being used, or perhaps replace a rarely used application with a less costly alternative. This functionality enables applications to be actively rationalized during an OS migration exercise, standardizing on products and versions and reclaiming unused software.

  • 1E-Nomad-*

Nomad Download Pause is a feature of Nomad and requires an installation of the Content Distribution service on Tachyon Platform. The feature is available as:

  • a right-click option in the Nomad Admin tools for the Configuration Manager Console
  • instructions in Tachyon Explorer

Nomad Admin tools for the Configuration Manager are installed using the NomadBranchAdminUIExt.msi installer.

  • 1E-GuaranteedState-Check-MEMCM*
  • 1E-GuaranteedState-Check-Network*
  • 1E-GuaranteedState-Check-Service*
  • 1E-GuaranteedState-Check-Software*
  • 1E-GuaranteedState-Check-WindowsUpdate*
  • 1E-GuaranteedState-Check-Wmi*
  • 1E-GuaranteedState-Fix-MEMCM*
  • 1E-GuaranteedState-Fix-Service*
  • 1E-GuaranteedState-Fix-WindowsUpdate*
  • 1E-GuaranteedState-Fix-Wmi*
  • 1E-GuaranteedState-Precondition*

Many businesses rely on Microsoft Endpoint Manager Configuration Manager (MEMCM) to deploy software, patches and updates across their company networks. It is crucial that Configuration Manager is working effectively.

The MEMCM Client Health policy monitors Configuration Manager client health and performance. It checks for cache availability, inventory cycles, service availability and Configuration Manager WMI integrity - common causes of Configuration Manager client problems on devices.

The MEMCM Client Health policy replaces the previous SCCM Client Health policy and covers the following:

  • Ensure the correct version of the CM client is installed and running and assigned to the correct site
  • Ensure the CM client is not stuck in provisioning mode
  • Ensure that heartbeat discovery, inventory and state messages are being sent regularly
  • Ensures the CM client cache is set to the correct size
  • Ensure the CM client log settings are correct
  • Ensure the BITS service exists, configured to start up automatically  and is running
  • Ensure the Windows Time service exists with correct startup settings
  • Ensure the Windows Management Instrumentation (WMI) service exists, configured to start automatically and is running 
  • Ensure WMI is healthy, the core CIMv2 and ccm namespaces and classes exist and that the WMI repository is consistent 
  • Ensure the Windows Update service exists with correct startup settings, is configured to use the correct source (CM, WSUS or Microsoft Update) and that the service can connect to the source

This policy is intended for deployment to Windows devices only.

  • 1E-Explorer-NomadClientHealth-*
  • 1E-GuaranteedState-Nomad*

Nomad is included as part of the 1E Client, and as part of that integration, we offer a Nomad client health compliance policy in Guaranteed State. This verifies common Nomad requirements such as ACP registration, disk availability, firewall exceptions, crash notifications and cache monitoring.

The Nomad client health policy replaces the client health tile in the Nomad dashboard plus additional remediation steps:

  • Keeps content distribution services up and running on Nomad clients, so that users are secure and productive
  • Ensures Alternative Content Provider (ACP) registration configuration is set
  • Maintains optimal disk availability and monitors cache size for storage capacity planning
  • Enforces Firewall exceptions.

This policy is intended for deployment to Windows devices only.

  • 1E-Explorer-MSSCCMClientHealth-*
  • 1E-Explorer-NomadClientHealth-*
  • 1E-Explorer-WindowsClientHealth-*
  • 1E-GuaranteedState-ClientHealth*
  • 1E-GuaranteedState-General-Check-ServiceState*
  • 1E-GuaranteedState-MSSCCMClientHealth-*

NightWatchman Online StatusNightWatchmanN/AN/AThe NightWatchman console uses Tachyon to display traffic lights live status of its clients – indicating whether they are currently online or offline (or unknown). You can also check the status of groups within the NightWatchman client hierarchy.
Third party and customer integration software See notesN/AN/A

You must ask 1E to add consumer names to your license if you intend to use third party or your own custom software to integrate with Tachyon and leverage its real-time client-based features. Examples:

  • Splunk
  • QRadar
  • Rapdid7
  • LogRhythm
  • EUCDashboard

You will probably also require your own custom prefixes for instructions and/or Guaranteed State fragments used by these Consumers, theefore you will need to ask 1E to add these perfixes too, as decribed the top of this table.

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

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:

You can use Tachyon Setup to install Tachyon Server so it does not require Tachyon clients to present certificates to the Tachyon Switch. The Platform can be reconfigured later to re-enable use of client certificates when your environment is ready. The Tachyon Server requires a Web Server certificate. If this is an issue for you, then please contact 1E.


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

  • DNS - each Tachyon Server requires at least one DNS Name
  • 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 - databases for Tachyon Master and Response Stacks, Catalog, SLA, BI, Experience and Content Distribution
  • SQL Analysis Services - must be installed in multi-dimensional mode, for Experience, and Business Intelligence (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.

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

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. The exception is a Tachyon DMZ Server where domain-joined is optional.

Each Tachyon user requires an account in 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.

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.

AD distribution groups are not supported.

Networking and DNS requirements

Network interfaces

The following conditions apply to network interfaces, which must be configured before installing Tachyon on a server. Each network interface must be assigned a static IP Address.


Each Switch supports up to 50,000 devices and requires its own network interface, with a minimum speed of 1Gbps.

Switch interfaces can be on the same or different subnets. Each interface can have its own DNS Name or share the same DNS Name as explained in DNS Names below.

If necessary, these interfaces can be shared with a Background Channel or other Tachyon services, which may share the same DNS Name or have their own names.

Response Stack with a Core component using a remote SQL Server instance and more than 500 devices

In addition to the Switch interfaces, another interface is required for outgoing response traffic from the Response Stack Core to its remote SQL Server. This should have a minimum speed of 1Gbps, or 10Gbps if the Response Stack has 3 or more Switches. This is required to ensure optimum performance when SQL Server is remote.

Network routing on the Response Stack server must be configured so that SQL traffic is routed over this interface. The simplest method is to route all outgoing traffic.

The interface used for SQL traffic should not register its IP Address in DNS to avoid unnecessary incoming traffic and accidentally becoming part of a round-robin DNS Name used for Switches.

DMZ Server

An additional internal facing interface is required for outgoing response traffic from Switches on the DMZ Server to the Core on the internal Tachyon Response Stack. This should have a minimum speed of 1Gbps.

As stated above, each Switch must have it own external facing interface, used for incoming response traffic from Tachyon clients to Switches. The external facing interface(s) can also be used for Tachyon clients to the Background Channel.

The simplest way to ensure the internal interface is used for outgoing traffic is for it to be on a different subnet to the external interface(s) with no routing between them - this is normal in a DMZ.

Administration traffic for a Tachyon Master Stack does not have any additional network requirements.

 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 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 Design Considerations: 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 Design Considerations: 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:

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. A DNS Name can be a DNS alias, CNAME or Host (A) record.

Master Stack

The Master Stack is used by the following, therefore it helps users if it has a recognizable and convenient DNS Name such as tachyon - this is specified during installation of the Tachyon Server using Tachyon Setup.

  • Tachyon users, approvers and administrators connecting to the Tachyon Portal and Consumer API
  • Remote tools and Consumer applications connecting to the Consumer API
  • Remote Response Stacks and DMZ Server connecting to the Coordinator service

Platform services also reside on the Master Stack, which non-Tachyon clients connect to, for example:

  • Application Migration, used by Windows Self-Service task sequences
  • AppClarity, used by AppClarity Software Reclaimer

DMZ Server

The DMZ Server is a type of Response Stack used to provide Tachyon Real-time and Inventory services to Internet-based clients. It requires an external DNS Name - for example tachyonext - this is specified during installation of the DMZ Server using Tachyon Setup.

The DNS Name is shared between the Switch network interfaces and Background Channel on the DMZ Server, and specified during installation of Tachyon clients, and stored in their configuration file.

Response Stack

A Response Stack is used to provide Tachyon Real-time and Inventory services to clients on the internal (corporate) network. The choice of DNS Name is discussed in the table below.

The DNS Name is shared between the Switch network interfaces and Background Channel on the Response Stack, and specified during installation of Tachyon clients, and stored in their configuration file.

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

Single DNS Name

A Tachyon system can have a single DNS Name if all components are installed on the same server, for example tachyon - this is specified during installation of the Tachyon Server using Tachyon Setup.

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.

Multiple client-facing DNS Names

The following client-facing components can each have their own DNS Name:

  • Tachyon Switch and Background Channel on Response Stack servers, including DMZ Server
  • Tachyon Platform services on the Master Stack, used by clients of A pplication Migration and/or AppClarity software reclaim
  • Tachyon Portal, and Consumer API, on the Master Stack, used by administrators.

Master and Response Stacks must have different DNS Names if they exist on different servers:

  • The Master Stack has its own DNS Name, for example tachyon
  • Each Response Stack can have its own client-facing DNS Name, or they can share a common client-facing DNS Name, for example tachyonrs

When a Response Stack is installed on the same server as the Master Stack, it will normally share the same DNS Name as the Master Stack as described under Single DNS Name above. However, if you have multiple Response Stacks and want them to share the same DNS Name, then the Master Stack must use a different DNS Name. This approach of all Response Stacks sharing the same DNS Name simplifies adding further Response Stacks at a later date.

During installation - using  Tachyon Setup: Website configuration - you need to consider the following:

HTTP binding

Required for installation, but can be manually removed later - please refer to  Tachyon Server post-installation tasks: Removing the HTTP binding from the Tachyon website.

This binding is not used by Tachyon clients or administrators, but can optionally be used for Application Migration and/or AppClarity reclaim clients. Example name acme-tcn01.

HTTPS binding

Required. This is the main binding.

On a Master Stack server (that has no Response Stack components) it is used by administrators to connect to the Tachyon Portal. It can optionally be used for Application Migration and/or AppClarity reclaim clients.  Example name tachyon .

On a Response Stack server, it is used by clients to connect to Switches and/or Background Channel. Example name tachyon or tachyonrs. See panel above about making the right choice.

On a DMZ Server, it is used by Internet-based clients to connect to Switches and/or Background Channel. Example name tachyonext. See below.

Alternate HTTPS binding

Required, except in the simplest (single server) configurations, described above.

It is typically used by other Tachyon Platform servers to connect to each other, but there are other scenarios.

  • required on a Response Stack server if it will have a DMZ Server connected to it. Example name tachyonalt.
  • required on a DMZ Server - used by internal servers to connect to the DMZ Server - see below. Example name tachyondmz. See below.
  • required on a Master Stack if you have local and remote Response Stack(s) - used for inter-server communications. Example name tachyonalt.
  • required on a Master Stack if the main HTTPS binding is used by client-facing components, and you want a different name for the Portal. Used by administrators to connect to the Tachyon Portal. Example name tachyon.
  • required on a Master Stack if you need a different HTTPS port for Application Migration and/or AppClarity reclaim clients. This can be by choice, or if you have upgraded from an original SLA Platform installation that used different ports.
Manual bindings

You can manually add further HTTP and HTTPS bindings after installation, to help differentiate the services which client devices and administrators connect to.

If you are upgrading ActiveEfficiency to Tachyon Platform then you might have had a HTTPS binding described as aeserver in previous documentation.  

If Master and Response Stacks are on the same server and you want them to have different DNS Names, then use the main binding for client connections to the Response Stack (because it is client-facing) and use the Alternate binding for other connections to the Master Stack. A simpler option is to put the Response Stack on its own server. Remote Response Stacks are recommended if the Master Stack is also hosting services AppClarity Software Reclaimer or Application Migration.

If you want to configure Switches on the same server to use multiple DNS Names, you will need to seek guidance from 1E. In most cases this is not required or recommended.

Internal DNS Names

A DMZ Server is a special example of a Response Stack. The DMZ Server itself requires two DNS Names:

  • a client (external) facing DNS Name - for example tachyonext - which is shared between the Switch network interfaces and Background Channel on the DMZ Server - this is specified during Tachyon Setup as the main HTTPS binding
  • an internal facing DNS Name for the internal network - for example tachyondmz - this is specified during Tachyon Setup as the alternate main HTTPS binding
Both DNS Names must be included in the web server certificate. You can manually replace the external/client facing certificate after installation, to comply with best practice not to expose internal names in an external facing certificate.

The internal Response Stack also requires an additional DNS Name - for example tachyonalt - for internal communications with the DMZ Server.

Please refer to Implementing a Tachyon DMZ Server for more detail about DMZ Servers.

Tachyon Setup supports installation of one HTTP and up to two HTTPS bindings, but you can manually add more bindings after installation.

Tachyon Setup currently supports only one Web server certificate, which must contain all the DNS Names used by the HTTPS bindings on that server. Each DNS Name must be included as a DNS Name in the Subject Alternate Name (SAN) entry of the web server certificate.

You can manually add more certificates, and change bindings. P lease refer to  Certificates . Please note that Tachyon Setup helps maintain the main and alternate HTTPS bindings using one certificate.

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

If your IIS server is using Kerberos then HTTP SPNs are required for web applications that use Windows Authentication, and are created using:

  • the web application pool's service account, which is Network Service for all of Tachyon's application pools, and therefore is the computer$ account
  • each (A) Host record used to access the web application. If the server is accessed using a CNAME record then you need to register an SPN for each (A) Host record used by the CNAME. A CNAME will have multiple (A) Host records when using round-robin or NLB to access the web server.

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.

Tachyon client integration with Nomad 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.

Tachyon client integration with Nomad 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).

The Nomad Single-Site Download (SSD) feature, which uses Content Distribution, further reduces the impact of 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

Supported Platforms

All 1E Client features are supported on the following Windows OS:


  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016
  • Windows 10 CB 22H2
  • Windows 11 CB 22H2
  • Windows 10 CB 21H2
  • Windows 11 CB 21H2

The zip for 1E Client for Windows is available for download from the 1E Support Portal.

Professional and Enterprise editions of Windows 10 are supported.

All versions are provided with 32-bit & 64-installers, and can be installed on physical and virtual computers.

This list is automatically updated to show only those OS versions in mainstream support by Microsoft, and therefore supported by 1E, and by 1E Client 8.0.

Please refer to Constraints of Legacy OSregarding end of mainstream support.

For Microsoft product lifecycle details, please refer to

Please refer to for details of which Current Branch versions are supported by 1E products, and known issues regarding specific versions.

The Tachyon client features of 1E Client are supported on the following non-Windows OS:


  • macOS Big Sur 11.0
  • macOS Catalina 10.15
  • macOS Mojave 10.14


  • CentOS 8.1
  • Debian 10.4
  • Fedora 34
  • openSUSE Leap 15.2
  • Red Hat Enterprise Linux 7.9
  • Red Hat Enterprise Linux 8.3
  • SUSE Linux Enterprise 15.2
  • Ubuntu 18.04


  • Please use 1E Client 5.2

Other versions of these non-Windows OS should work but have not been tested by 1E.

1E Client packages for other Linux distributions can be requested, including Raspbian for Raspberry Pi.

The 1E Client for Linux supports the following architectures:

  • Linux variations on Intel 64-bit platforms

1E Client packages for Linux are included in the non-Windows zip available for download from the 1E Support Portal.

1E Client supports only Tachyon features on non-Windows devices. 

1E Client 8.0 is not available for Solaris, please use 1E Client 5.2 instead. 

The 1E Client 5.2 for Solaris supports for the following architectures:

  • Solaris on Intel 64-bit and SPARC platforms

1E Client 5.2 package for Solaris is included in the non-Windows zip available for download from the 1E Support Portal.

1E Client supports only Tachyon features on non-Windows devices.

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.