Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.





Information that will help you design and plan the implementation of Tachyon in your organization. This includes all the prerequisites and dependencies, which are necessary to install Tachyon.

 This page is part of the design phase of implementation.


Please use the table of contents on the right as a checklist before installing Tachyon on your servers.

Review Design Considerations first if you need to design and plan the implementation of Tachyon in your organization.

Server sizing
Server sizing

Server requirements

Server sizing for on-premises, Amazon AWS and Microsoft Azure

Below is the table of contents for the Server sizing page, which provides comprehensive guidance for CPU, RAM, disk volumes, and network connections.



Advanced Panelboxes for Confluence
Multiexcerpt include
PageWithExcerptServer sizing


Advanced Panelboxes for Confluence
titleOn this page:

Table of Contents
excludeSummary|On this page|In this section...

Server software

Multiexcerpt include
PageWithExcerptSupported Platforms



The computername of a Tachyon Server must comply with Microsoft NetBIOS naming standards, which includes having a length of 15 characters or less.

Microsoft's guidance can be found here:

DNS Names

MultiExcerptNameDNS Names

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

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:

  • ActiveEfficiency Server, used by Nomad clients
  • 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.

If ActiveEfficiency Server is installed, it can share the same DNS Name provided the server supports less than 5,000 clients. ActiveEfficiency requires its own network interface and DNS Name if the server supports more than 5,000 clients, as described under

Multiple client-facing DNS Names

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.

Only one client-facing DNS Name can be specified during installation, other HTTPS bindings are added manually after installation. If Master and Response Stack are on the same server and you want them to have different DNS Names, then specify the DNS Name for the Response Stack during installation, and manually add the HTTPS binding for the Response Stack after installation. You will need to seek guidance from 1E on how to configure Switches to use the second DNS Name. 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 for ActiveEfficiency Server, AppClarity Software Reclaimer or Application Migration.

You can optionally have additional DNS Name(s) on the Master Stack server for other services such as ActiveEfficiency Server, AppClarity Software Reclaimer and Application Migration. These bindings would be added manually after installation, and do not require any further complex configuration.

ActiveEfficiency Server requires its own network interface and DNS Name if it is installed on the same server as a Response Stack and supports more than 5,000 clients:

  • All Response Stacks interfaces share a DNS Name used by Tachyon clients, for example tachyonrs
  • You can choose one of the following options for the ActiveEfficiency Server and the Master Stack:
    • both share the same interface and DNS Name, for example tachyon - specified In Tachyon Setup during installation
    • ActiveEfficiency Server has its own DNS Name, for example aeserver - added as a binding after installation - this may be the appropriate choice when upgrading an existing ActiveEfficiency Server and you do not want to reconfigure clients, and you want a different DNS Name for Tachyon

Internal DNS Names

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

  • an internal facing DNS Name for the internal network - for example tachyondmz - manually added after installation
  • a client (external) facing DNS Name - for example tachyonrs or tachyonext - which is shared between the Switch network interfaces and Background Channel on the DMZ Server - this is specified during Tachyon Setup

Both DNS Names must be included in the web server certificate.

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

If you expect to use multiple external DNS Names then you must specify the DNS Name for the Master Stack in Tachyon Setup during the first installation.

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.

Service Principal Names


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


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.

Windows Server roles and features


Items in bold are included in the PowerShell script available for download from Preparation: Windows Server roles and features.


Tachyon Setup will create a website named Tachyon with the necessary bindings, therefore please do not pre-create a website of the same name.


The following roles, role services and features must be installed/enabled as a minimum. The Name column is the reference used in PowerShell commands.

In the case of .NET Framework features we refer to 4.X in the Display Name, as X may be different depending on the server OS. The PowerShell Name always uses 45 instead of the actual version.

Role or FeatureDisplay NameNameNotes
Web ServerWeb Server (IIS)Web-Server
Web Server Common HTTP FeaturesDefault DocumentWeb-Default-DocIncluded in Web-Server.
Directory BrowsingWeb-Dir-BrowsingIncluded in Web-Server.
HTTP ErrorsWeb-Http-ErrorsIncluded in Web-Server.
Static ContentWeb-Static-ContentIncluded in Web-Server.
HTTP RedirectionWeb-Http-Redirect Only required to support legacy Nomad clients after upgrading ActiveEfficiency.
Web Server Health and DiagnosticsHTTP LoggingWeb-Http-LoggingIncluded in Web-Server.
Web Server PerformanceStatic Content CompressionWeb-Stat-CompressionIncluded in Web-Server.
Dynamic Content CompressionWeb-Dyn-Compression
Web Server SecurityRequest FilteringWeb-FilteringIncluded in Web-Server.
Basic AuthenticationWeb-Basic-Auth

Only required if using 1E ITSM Connect or 1E Core for integrating ServiceNow and Tachyon.

IP Address and Domain RestrictionsWeb-IP-SecuritySee note below.
Windows AuthenticationWeb-Windows-Auth
Web Server Application Development.NET Extensibility 4.XWeb-Net-Ext45Included in Web-Asp-Net45.
ASP.NET 4.XWeb-Asp-Net45
ISAPI ExtensionsWeb-ISAPI-ExtIncluded in Web-Asp-Net45.
ISAPI FiltersWeb-ISAPI-FilterIncluded in Web-Asp-Net45.
Web Server Management ToolsIIS Management ConsoleWeb-Mgmt-Console
.NET Framework 4.X Features.NET Framework 4.XNet-Framework-45-Core
ASP.NET 4.XNet-Framework-45-ASPNET

The following roles, role services and features must be removed/disabled.

ParentDisplay NameName
Web Server Common HTTP FeaturesWebDAV PublishingWeb-DAV-Publishing

titleIIS Features Configuration

Core web applications use IP and Domain Restrictions so that only specific servers can access it. Other web applications cannot be accessed using HTTP because their SSL Settings are configured with Require SSL.

The web applications for the Consumer API and Explorer use Tachyon role-based security and therefore have Windows Authentication enabled. The other web applications have Anonymous Authentication enabled.

HTTP Redirection (Web-Http-Redirect) is only required to support legacy Nomad clients after an In-place upgrade of ActiveEfficiency Server for Nomad

Basic Authentication (Web-Basic-Auth) is only required if you will be installing 1E ITSM Connect or 1E Core for integrating ServiceNow and Tachyon.



Microsoft Message Queuing (MSMQ) is not required. Prior to Tachyon Platform 5.2, MSMQ was required by ActiveEfficiency for the Nomad integration with WakeUp feature, which is not supported by Tachyon Platform 5.2. The feature is under consideration for re-design and may be available in future versions of Nomad. MSMQ is not required by the Nomad app and Content Distribution, which has replaced ActiveEfficiency in Tachyon Platform 5.2 onwards.

Anti-Virus and Malware


The following should be excluded from scans to prevent file locking and resource deletion.

  • 1E log files. See Log files for details of Tachyon Server and 1E Client logs
  • The Background channel virtual directories (Agent, Content, Installers, PolicyDocuments, and Updates, which by default are in %programdata%\1E\Tachyon)

SQL Server requirements


Below is a list of SQL Server requirements covered in other sections on this page:

Please refer to the Server sizing page for details of SQL Server hardware and database sizing.


Multiexcerpt include
PageWithExcerptSupported Platforms

Active Directory requirements

Service accounts


All Tachyon web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE, except for the BI SSAS User account which must be a domain user account.


Prior to Tachyon 5.0 a domain user account was required by the 1E Catalog Update Service and the CatalogWeb application pool, but for Tachyon Platform 5.0 and later they now all use Network Service.



The BI SSAS User account has the following requirements:

  • The account name and its password will be specified in the Tachyon Setup: BI SSAS database settings screen.
  • Must be a domain user account 
    • configured with Password never expires
    • although this user might be referred to as a service account, it does not require Logon as a service on the server

  • The SLA BI installer (used by Tachyon Setup) automatically grants rights to this user during installation, and stores its credentials encrypted in the following places:
    • a linked server connection for the BI database to access the BI cube
    • in the configuration file used by the MDX API to query the BI cube

SQL Login for the Network Service account



The SQL Login that is used by the Tachyon Server web applications and services depends on whether the SQL Server is remote from the Tachyon Server or is local, as described in the following table:

Installation scenarioService account SQL Login
Tachyon Server is remote from SQLThe computer account of the remote Tachyon Server. For example ACME\ACME-TCN01$
Tachyon Server and SQL are localThe local network service account, NT AUTHORITY\NETWORK SERVICE


Before upgrading Tachyon, or installing or upgrading Consumer applications like Application Migration or AppClarity, the SQL Login must be granted the following rights to support Database Snapshot of the Catalog and SLA databases, to restore them if an error occurs:

  • dbcreator rights on the SQL database instance hosting the 1E Catalog database
  • dbcreator rights on the SQL database instance hosting the SLA databases

During installation, the Tachyon Setup will always:

  • attempt to create the SQL Login
  • grant it db_owner permission on each of the Tachyon databases
  • remove the db_owner permissions when installation is completed.

User accounts


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.


Users are added to the Tachyon system and assigned roles by any Tachyon user assigned to the Permissions Administrators system role. A permissions administrator manages Tachyon users and roles using the Permissions Menu in the Tachyon Portal Settings application.


Tachyon is supported in multi-domain, multi-forest environments. You have a choice of how Tachyon queries Active Directory, specified during installation.

Multiexcerpt include
PageWithExcerptTachyon Server installer properties

Active Directory Security Groups


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.


AD distribution groups are not supported.

Tachyon sends emails to users and approvers of Tachyon instructions. Permissions are assigned to instruction sets, and AD security groups can be assigned permissions. Tachyon will use the email address of an AD security group if it has been configured, and relies on the Mail system to forward emails to the members of the AD security group. If the AD security group is not configured with an email address, then Tachyon sends an email to each member that has an email address. AD distribution groups are not supported.

Active Directory in the cloud

The Tachyon software must be installed on a Windows Server that is part of an Active Directory domain. Companies do not always have their on-premises Active Directory extended into their cloud environment - there are security concerns that must be taken into account and there must be some mechanism for either a secure network connection between the customer's on-premises systems and the cloud environment (usually via VPN connection) or a way of synchronizing the cloud based Active Directory implementation with the on-premises one (through a directory synchronization of some sort).

Both AWS and Azure provide the following 'cloud' based versions of Active Directory:

  1. AWS Directory Service for Microsoft Active Directory (Enterprise Edition) - This is a full implementation of Active Directory, but it requires a VPN and a trust relationship set up with any existing on-premises Active Directory to be able to use on-premises based accounts. This makes it quite a complex solution to implement and maintain. 


    1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.

  2. AWS AD Connector - This is a mechanism for redirecting domain queries from the local network to an on-premises Domain Controller using a VPN instead of needing a domain controller in the cloud.


    1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.

  3. AWS Simple AD - This is an implementation of Active Directory based upon Samba 4 and provides a limited subset of a full Active Directory. 


    1E do not support Tachyon running in this environment.

  4. Azure Active Directory - Although this provides cloud based identity, it cannot be used for direct active directory connectivity from an Azure virtual machine, for that you need Azure Active Directory Services (next).
  5. Azure Active Directory Services - This provides the ability to domain join Azure Virtual Machines to your Azure Active Directory, however, it is not a full AD as you cannot have domain admin or enterprise admin privileges.


    1E do not support Tachyon running in this environment.

The following is the only cloud solution that is fully supported by 1E, and is what we call Extended AD. It doesn't use any of the above, but has the following requirements, which provide an Active Directory presence in the cloud and brings the full capabilities of Active Directory to bear. 

  • Virtual machines located in the customer's cloud network installed with Windows Server as hosts for:
    • Domain Controller(s) in the existing enterprise domain, which can be Read-Only domain controllers (RODC).
    • Other member server(s) which host the Tachyon Server components, including Microsoft SQL Server, must be joined to the same enterprise domain.
  • A permanent site-to-site VPN connection from cloud to the corporate on-premises network.


1E fully support the Extended AD solution for AWS and Azure, which do not change any of the Active Directory requirements described above.

Server installation account

Local admin rights


The server installation account has the following requirements on the server.

  • Local admin rights on the Tachyon Server. It must be an Active Directory domain user account that is a direct or indirect member of the Administrators local group on the server where Tachyon Server will be installed.
  • Can be disabled (not deleted) in Active Directory after additional Tachyon admin users have been created in Tachyon, and installation has been verified.

Tachyon user permissions


This is the account used to run Tachyon Setup (and the MSI installer) when installing or upgrading a Tachyon Server. The account is automatically defined as a Tachyon admin user with limited rights which cannot be edited (called a system principal). The installation account only has sufficient rights to add other Tachyon users, assign them to Tachyon roles (including the Permissions Administrator role), and install Tachyon applications. The users and roles created by the installation account are then used for ongoing use and management of Tachyon.

If you need the installation account to have additional Tachyon roles or be a Global Administrator, then the recommended approach is:

  • first create a role-based AD Security group, and add the installation and other accounts to this group
  • then, the installation account 
    • logs into Tachyon and navigates to Settings → Permissions → Users
    • creates a new Tachyon user for the role-based AD Security Group
    • assigns the relevant system role(s) to the new Tachyon user - this can be Global Administrators


You can disable the installation account in AD after the Tachyon system is operational and other Tachyon users have been set up. You can then re-enable it whenever required for ongoing configuration changes and upgrades.


Do not delete the server installation account from Tachyon after installation.


The server installation account is granted the following permissions as a Tachyon user, configured during installation of the Tachyon Server.

SQL Logins for the server installation account


The server installation account requires SQL permissions during installation and upgrade, which can be temporary or permanent. The level of SQL permissions required by the installation account depends on which Tachyon components it is installing.

Master Stacks

For master stacks sysadmin is required as follows:

  • to install 1E Catalog
  • to create Linked Servers for SLA, which requires sysadmin for the SQL database instances for both SLA and 1E Catalog databases
  • to create Linked Servers for BI, which requires sysadmin for the SQL database instances for both SLA and BI databases, and the SSAS instance for the BI cube (required only by Patch Success)
  • to create a Linked Server for Content Distribution, which requires sysadmin for the SQL database instance for the ContentDistribution database (required only by Nomad)

Response Stacks

Sysadmin availability on SQL instance(s)SQL Login permissions
sysadmin SQL Server role is permitted

The server installation account requires the sysadmin SQL Server role on the SQL Server instance(s) that host the TachyonMaster and/or TachyonResponses database(s).

This can be used for a new installation, or for an upgrade.

sysadmin SQL Server role is not permitted
The SQL Login permissions required by the server installation account vary depending on which choice is implemented, as described in the following table:

Choice implemented

Role required for the installation account's SQL Login

Database(s) created by the Tachyon Server installer during installation.dbcreator SQL Server role on the SQL instance

Database(s) created before installation - a common scenario if you want to select database location and size.

Also required when upgrading Tachyon.

db_owner database role on the pre-created databases:

Multiexcerpt include
PageWithExcerptSupported Platforms


In addition to the permissions given in the table above, the server installation account also needs ALTER ANY LOGIN Securables permission in order to allow creation of the SQL Login for the Network Service account, used by the Tachyon Server web applications and services.

Example scripts are provided below to create a SQL Login and grant roles.

During installation, the Tachyon Server installer will always attempt to grant db_owner permission to the server installation account on each of the Tachyon databases.


Databases must be configured in multi-user mode.

Please refer to Preparation: Example SQL scripts for creating a SQL Login and granting roles for example SQL scripts.

License file


1E will provide you with a Tachyon.lic license file that defines the products and features your Tachyon System is able to use, for how long, and how many devices it supports, this may be an evaluation or subscription license.

  • The license must be activated. Once activated, it may be used only by the Tachyon System that activated it.
  • Licenses can be renewed or updated, but if allowed to expire, then the affected products or features will not be usable.
  • For a new installation, the Tachyon Setup program will let you select the license file from any folder on disk.
  • For an existing installation, the license file is copied into the folder: %PROGRAMDATA%\1E\Licensing on your Tachyon Server.

For details of what the license file needs to contain, please refer to Design Considerations: License requirements for consumer applications.



If you want to develop your own instructions, or modify downloaded instructions, you will need to contact 1E to add a code signing certificate to your license file, for more details please refer to Code signing certificates below.


Public Key Infrastructure



You need to have a PKI in your environment with at least one Issuing CA.

Tachyon requires each Issuing CA has:

  • Certificate Revocation List (CRL) Distribution Point (CDP) that uses HTTP/S 
  • this HTTP/S CDP information is included in certificates issued to Tachyon Server and client devices


titlePKI notes

If you have an existing PKI and have just added a new CDP to support HTTP/S then you will need to re-issue certificates to your servers and devices.

Tachyon deliberately does not work with self-signed certificates for security reasons. Therefore, Tachyon Server cannot be installed on the same server as a Root CA, because its certificate is self-signed. For the same reason, Tachyon client cannot be installed on a DC unless the client's Switch is configured to not require client certificates.

Tachyon uses TLSv1.2. If your PKI is using SHA512 then please ensure that your environment has relevant updates applied, as described in KB2973337. See Client issues: Enabling SHA-512 to work with TLSv1.2.

If you want Tachyon to manage legacy OSs that Microsoft no longer supports there may be issues with encrypted certificates described in Requirements - Constraints of Legacy OS.

Tachyon Web Server certificate


Each server that has Tachyon Server components installed requires its own Web Server certificate (except for a remote SQL Server). This certificate is also used by the Tachyon Switch and the Tachyon Coordinator. Therefore, a single-server installation requires only one Web Server certificate. This certificate must be provided on the server prior to installation of Tachyon.

The Web Server certificate requires the minimum of the following:

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the server
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the server
    • The above CA certificates must exist on the Tachyon Web Server and Windows client devices
    • Most organizations have automated distribution of these CA certificates to servers and clients, using Group Policy for example.
  2. Has at least the following Key Usage:
    • Digital signature
    • Key encipherment
  3. Has at least the following Enhanced Key Usages:
    • Server Authentication
  4. Revocation information is included
    • References at least one CRL Distribution point that uses HTTP
  5. Must have a private key available

Tachyon server certificates
Tachyon server certificates

The default template Web Server available with a Microsoft PKI is suitable for requesting a Tachyon Web Server certificate.


Tachyon systems that have DMZ Servers may have additional requirements, please refer to Implementing a Tachyon DMZ Server.


Tachyon clients and Switches use OpenSSL and its validation process to verify certificates.



Web Server certificates used by a Tachyon Servers must be issued with their fields set as follows:

FieldsExample Option 3 type certificate
Subject Common Name Field (subject:commonName)Subject can be any valid name, and is no longer mandatory as required by previous versions of Tachyon.
Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The Tachyon Server DNS Name FQDN (DNS Alias) of the server. This is mandatory, same as required by previous versions of Tachyon.


On a Master Stack, this is used by browsers, consumers, remote Tachyon Servers, and clients using ActiveEfficiency, Application Migration, or AppClarity Software Reclaimer.

On a Response Stack or DMZ Server, this is used by Tachyon clients.

Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

An Alternate DNS Name FQDN (DNS Alias) of the server. This is a new requirement for Tachyon 5.0 and later.



An Alternate DNS Name is required for any server hosting a Switch (Response Stack or DMZ Server) if the server has multiple IP Addresses. It is used for internal Tachyon communications between Switches and other Tachyon components.

An Alternate DNS Name is optional for a server hosting a Master Stack if you want an alternate DNS Name for clients using ActiveEfficiency, Application Migration, or AppClarity Software Reclaimer.

For more detail about setting up a DMZ Server, please refer to Implementing a Tachyon DMZ Server.



Earlier versions of Tachyon required the certificate to have a CN and used SAN fields differently. If you are upgrading your Tachyon server from an earlier version it may still be using this type of certificate. When upgrading Tachyon, you can issue a replacement certificate, or continue using the old style certificate (because the new-style certificate requires only a SAN DNS Name that matches the DNS Alias, which are provided by the old style certificates).

titleClick here to see examples of old-style certificates...

FieldsExample old Option 2 type certificate
Subject Common Name Field (subject:commonName)

The computername FQDN of the server


Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The DNS Alias FQDN of the server


Add any additional DNS Names here.

Example certificate request


Option 2 type certificates required the CN to be the computername FQDN, and the list of Subject Alternate Names (SAN) to contain the DNS Alias.

Also, prior to Tachyon 5.0 the certificate required its private key to be exportable.

Tachyon 5.0 and later is able to use this type of certificate when upgrading from an earlier version of Tachyon.

FieldsExample of old Option 1 type certificate
Subject Common Name Field (subject:commonName)

The DNS Alias FQDN of the server


Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The DNS Alias FQDN of the server


The computername FQDN of the server


Example certificate request


Option 1 type certificates required the CN to be the DNS Alias, and the list of Subject Alternate Names (SAN) to contain the computername FQDN.

Also, prior to Tachyon 5.0 the certificate required its private key to be exportable.

Tachyon 5.0 and later is able to use this type of certificate when upgrading from an earlier version of Tachyon.


The following need to be considered when requesting this type of certificate.

  • The certificate can be used only on the server it was intended, that has the correct computername FQDN and DNS Alias FQDN.
  • It is not possible to use the Create Certificate Request method in IIS Manager Server Certificates, because it does not support all the above requirements.
  • If you have a Microsoft CA, and a suitable Web Server template has been issued and enabled in the Active Directory Enrollment Policy, then it is possible to Request New Certificate in the Certificates (Local Computer) mmc snap-in and use the Certificate Enrollment wizard.
  • Many organizations have their own process for submitting a Certificate Signing Request (CSR). Please ensure all the above requirements are specified. Security administrators sometimes have difficulty providing a certificate with one or more Subject Alternative Names (SAN), and it helps to explain these are type DNS.

If you have a Microsoft CA then it is simplest to use the Certificate Enrollment wizard available in the mmc certificates snap-in, to request a Web Server certificate and fill in the details.

Tachyon server Client Authentication certificate


A new requirement for Tachyon Platform 5.2 - when the Nomad app and Content Distribution is installed - is for any server hosting a Background Channel to have a Client Authentication certificate. This can be the same certificate as a Tachyon client certificate if you have 1E Client installed (with Tachyon enabled), or it can be the same certificate as the Tachyon Web Server certificate if your organization security policy allows your Web Server certificates to be used for both Server Authentication and Client Authentication.

This certificate is used by the Background Channel proxy to be authenticated by the Content Distribution Web API, and must be available on the server do that it can be selected on the Tachyon Setup: Nomad screen during installation.

Tachyon client certificates


If you have configured Tachyon Server to require client certificates (Tachyon Setup: Client certificates) then each device requires a certificate with the following properties so the Tachyon client be authenticated by the Tachyon Switch.

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the client
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the client
    • If either of these CA certificates are different to those used by the Tachyon Web Server, they will need to be exported and imported on the Tachyon Web Server
    • Most organizations have automated distribution of these CA certificates to clients and servers, using Group Policy for example.
  2. Has at least the following Enhanced Key Usage
    • Client Authentication
  3. Has at least the following Key Usage
    • Digital Signature
    • Key encipherment
  4. Has a private key
    • For workgroup and non-Windows devices, the private key must be exportable
  5. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  6. Has a Subject Name of type Common Name (CN=<computername>) or Subject Alternative Name (DNS Name=<computername>) where <computername> depends on the type of device:
    • On domain-joined Windows PCs this must be the computername FQDN of the computer, for example W701.ACME.LOCAL
    • On workgroup Windows PCs and non-Windows devices, this must be the computername of the computer - as returned by the hostname command, for example on Windows PC this could be W701, and on a Mac this could be MAC01.local

Tachyon clients and Switches use OpenSSL and its validation process to verify certificates.


The client device's certificate is stored differently depending on the type of OS.

  • For Windows devices, the certificate is stored in the Windows Local Computer personal certificates store. 
  • For non-Windows devices, except for the Mac, the Tachyon client does not use proprietary certificate stores. Instead, the client requires the certificate exists as a .pfx file in the client installation folder structure:
  • For macOS, you have a choice of storing the client certificate in the macOS Key Store or using the .pfx file approach required by other non-Windows devices.


If using a Microsoft Enterprise CA then the following should be considered.

  • For domain joined Windows computers:
    • use the Computer template or a duplicate,
    • enable auto-enrollment - so that devices enroll automatically.
  • For workgroup Windows and non-Windows devices:
    • use a duplicate or equivalent of the Computer or Workstation template,
    • the template's Subject Name uses supply in the request - so the hostname can be entered when requesting a certificate,
    • the template must Allow private key to be exported - so a certificate can be requested on a domain joined Windows computer, exported as a .pfx file and then imported on the target device (see non-Windows Device Certificate).

If using a standalone CA, then certificates must be deployed by other means.

Code signing certificates


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


The following points apply to the importing and running of custom Tachyon instructions:

  • Tachyon will only allow instructions to be imported if they have been signed and the code-signing certificate in the Tachyon Server's Trusted Publishers certificate store exists.
  • Tachyon will only allow instructions to be run if their prefix and code-signing certificate have been registered in the Tachyon Server's license file (even if the instruction has been successfully imported, it will be flagged as unlicensed if the license information is not there).


Custom Instructions must be signed by the Tachyon Instruction Management Studio (TIMS) using a code-signing certificate present in the Personal certificate store where TIMS is installed (either local user or machine store). The TIMS user signing the Instruction also needs to have access to the certificate's private key.

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

Digital signing certificates


On Windows computers, the installation MSI files, and binary executable and DLL files of 1E software are digitally signed. The 1E code signing certificate uses a timestamping certificate as its countersignature. 1E occasionally changes its code signing certificate, as shown in the table below, and uses it for new releases and hotfixes for older versions, as shown in the table below.

The signature algorithm of the 1E code signing certificate is SHA256RSA. In most cases, the file digest algorithm of an authenticode signature is SHA256, and the countersignature is a RFC3161 compliant timestamp. The exception is on legacy OS (Windows XP, Vista, Server 2003 and Server 2008) which require the file digest algorithm of an authenticode signature to be SHA1, and a legacy countersignature. 

The root CA certificates (for signing and countersigning) must exist in the Third-Party Root Certification Authorities store (which is replicated in the Trusted Root Certification Authorities store). These root CA certificates are normally automatically provided by Microsoft's Update Root Certificates feature, however, this may not be true for legacy OS computers in a lab environment that are not connected to the Internet.

Multiexcerpt include
PageWithExcerptHLP:Legacy OS

PKI in the cloud

Tachyon relies on both client (device) and server side certificates to ensure secure communication. In order for these certificates to work the computers need to trust the PKI implementation (issuing Certification Authority and chain of trust). In a standard on-premises environment, devices can be enrolled with certificates using Active Directory Group Policy.

It is possible to use a non-Windows based PKI, but it is then left as an exercise for the user as to how to distribute and enrol device certificates to all end-points.

Given the supported Active Directory configuration above, the PKI requirements described above still apply to a cloud based implementation.

Tachyon Web Server certificate

Since clients must be able to access the Tachyon Switch and Background Channel from both the internal corporate network and the Internet, there are some additional considerations when creating the Tachyon web server certificate.

  1. The server must have a consistent external FQDN.

    In AWS, a standard EC2 instance has an external FQDN based upon its externally accessible IP address. However, this IP address will change each time the server restarts, and since the Tachyon Switch relies on an HTTPS certificate that utilizes the FQDN to authenticate the server, this would cause the Switch to stop working. In order to work around this, any AWS implementation MUST use an Elastic IP address associated with the network interface of the Switch to ensure that the IP address never changes, and therefore the external FQDN is always the same. Alternatively, you can create a CNAME entry in your external DNS to point to the external FQDN of the AWS instance and use the CNAME as the subject name of the server certificate.

  2. The web server certificate must incorporate all DNS Names that will be used to access the server in the certificate SAN.

    Clients can be configured to connect to multiple Switches for resilience and geographic load balancing. In many cases a cloud based virtual machine may be able to be accessed through both an internal VPN network, and an external Internet connection. These connections can be made using the same DNS name (via a CNAME entry as specified in the main documentation) or by different DNS names (where there are separate internal and external DNS domains in use).

    The certificate crafted for the Tachyon Switch  must contain all  DNS Names that will be used to contact the server in the Subject Alternate Name (SAN) entry within the certificate.

Client certificates

Any devices that will connect to the Tachyon implementation must have a client certificate from a PKI infrastructure trusted by the Tachyon server. In a Windows domain environment, this is usually provided through an Enterprise Certificate Authority and the use of Group Policy. It is also possible to provide certificates through SCEP, which 1E has tested and support the use of the Microsoft Device Enrollment Service (MDES) for this purpose. Use of other SCEP solutions will be supported on a best-efforts basis.

Email requirements

SMTP server


The Tachyon SMTP feature can optionally be enabled to send the following types of emails to Tachyon users.

  • Approval request emails to approvers about pending action requests
  • Notification emails to users about responses that will expire shortly
  • One-time authentication code emails if the two-factor authentication feature is enabled.

Emails are HTML format, without any attachments, and have a typical size of approximately 70KBytes. You can choose to modify the email banner header.


Emails are sent by the Coordinator service (workflow module) which by default uses the built-in Network Service (NT AUTHORITY\NETWORK SERVICE).

If the Tachyon SMTP feature is enabled, your SMTP relay/gateway may require the following to be configured.

  • Add the Tachyon Server name or IP address to a new or existing white-list policy
  • Disable require SMTP authentication (allow anonymous) - see note below
  • Assign the "mail-from" address to an AD account - see Mail-From Address below - if it has a SPF (Sender Policy Framework) or Sender ID policy.


In this version of Tachyon, SMTP Authentication is notconfigurable using the Server installer. The default is anonymous authentication. However, it can be changed post-installation. For details of changing the SMTP configuration and disabling email notifications, please refer to Tachyon Server post-installation tasks: Changing the SMTP Host configuration.

Mail-From address


If the Tachyon SMTP feature is enabled, then a Mail-From address is required as the Sender of Tachyon emails.

Tachyon does not require the Mail-From address to belong to a real AD account or have a real mailbox, however, your SMTP relay/gateway might have these requirements, therefore you may need to create an additional AD account.

Choose a suitable email address, especially if there is no mailbox, for example no_reply@acme.local.

Email for Users and Approvers


Each Tachyon user and approver should have an email address, otherwise they will not receive emails when actions require authentication or approval. Email addresses are mandatory if two-factor authentication is enabled.


If an AD Security Group is assigned rights in Tachyon to approve actions, and the Group has an email address, then Tachyon will use that. However, a group member will receive emails only if your organization's mail system supports group emails and the member has an email address. If the Group does not have an email address, then Tachyon will look up group members and send emails to any member that has an email address. Irrespective of whether the Group has an email address, members must have emails addresses in order to receive emails.


If your organization uses separate AD accounts for user and administration tasks, then you should consider the impact of using admin accounts for Tachyon if they do not have associated email addresses. 

Two-factor Authentication requirements


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.

Feature dependencies

1E companion products

The following tables show the 1E products that combine to support particular features.

Multiexcerpt include
PageWithExcerpt1E Companion Products

Multiexcerpt include
PageWithExcerpt1E Companion Products


Multiexcerpt include
PageWithExcerptConnectors page

Please refer to the relevant connector page to identify security and other requirements for a specific connector.

Multiexcerpt include
PageWithExcerptPS13:Configuring Patch Success

Patch Success also requires a Tachyon connector.

Multiexcerpt include
PageWithExcerptSupported Platforms

Product Packs and Security Roles


Classic Product Packs:

  • include instructions
  • are uploaded using either of the following methods:
  • once the instructions are uploaded you must organize them manually into Instruction Sets, although the Tool will use the name of the zip file as the basis for the Instruction set name 
  • Instruction Sets are the basis for assigning custom roles that determine who can do what with the instructions in each Set

Integrated Product Packs:

  • include policies and/or instructions
  • are uploaded using the Tachyon Product Pack deployment tool as described in Guaranteed State 1.5 - Uploading Integrated Product Packs
  • if the pack contains instructions, each one is automatically uploaded into an Instruction Set using the folder name as the basis for the Instruction set name
  • policies are uploaded into Guaranteed State

The Guaranteed State 1.5 - Integrated Product Packs provided by 1E include ready-made Policies, and any instructions included in the packs are intended to augment the policies, but can be used independently.

You may want to create AD security groups to use custom roles to control access to:

  • Instructions Sets - you should think about groups of people who will need to view, question, action, and approve instructions
  • Policies - you must decide who needs access to the Guaranteed State application - in this version of Tachyon, you cannot grant access to individual Policies.

Export all feature


The Export all feature is available on the responses page for a question once it has finished retrieving all its responses. To enable Tachyon users with the appropriate permissions to use this feature, you must ensure that the Microsoft Bulk Copy Program (BCP) is installed on the same Response Stack server(s) where the Tachyon Core component has been installed.

Please refer to Tachyon Server post-installation tasks: Configure the Tachyon Server to support the Export all responses feature for more details on configuring SQL BCP and setting up a suitable share.

Nomad integration


Downloading Agent Resources
Downloading Agent Resources

Nomad integration is available on Windows PC devices and is enabled by default (NomadContentDownloadEnabled=true), and can be disabled during or after installation of the 1E Client.

With the Nomad integration feature enabled, the Tachyon client will detect if the Nomad client module of the 1E Client is enabled, or if Nomad v6.0.100 or later version is running on the device, and automatically use it to download content from Tachyon Background Channel servers, and any other HTTP/S content source that Tachyon client may use.

Tachyon's use of Nomad works irrespective of whether Nomad is integrated with Configuration Manager or using advanced Nomad features that use ActiveEfficiency.

Configuration Manager is not a prerequisite for Nomad integration with Tachyon, but you will need to consider the following:


Configuration Manager present

You do not need to make any configuration changes to Nomad for it to integrate with Tachyon. Please refer to the Nomad documentation for guidance on designing and deploying Nomad.

Configuration Manager not present

You can deploy Nomad to Windows devices where the Configuration Manager client is not present. You will need to enable the following bits in relevant installer properties:

  • CompatibilityFlags bit 1 - enable long hashes
  • SpecialNetShare bit 13 - enable HTTP(S)

These are enabled by default in the Nomad client module of the 1E Client.

Configuration Manager integration

Tachyon is able to integrate into the Configuration Manager console to provide a right-click context menu that can be invoked from Configuration Manager computer collections. Tachyon can then use the members of the computer collections as the coverage for any Tachyon instruction selected from the menu. The Configuration Manager extensions are part of the Tachyon Toolkit. For more details please refer to Preparing for the Tachyon Configuration Manager Console extensions.

Tachyon scripting requirements


You must ensure the appropriate scripting environment is present on Tachyon client devices. Tachyon SCALE - Simple Cross-platform Agent Language for Extensibility - supports running native PowerShell on Windows and bash on non-Windows devices, which can be script files downloaded when an instruction runs, or command text.

  • Windows Tachyon clients can use PowerShell scripts. Ensure your client devices have an appropriate version of PowerShell installed to support any custom scripts you may develop. See PowerShell on Windows OS.
  • Non-Windows Tachyon clients use bash as their scripting medium. This should be present on all non-Windows Tachyon client devices. See Bash on non-WindowsOS.

PowerShell on Windows OS

Multiexcerpt include
PageWithExcerpt1EC52:Supported Platforms

Bash on non-Windows OS

Multiexcerpt include
PageWithExcerpt1EC52:Supported Platforms

Whitelisting connections to 1E Cloud

The simplest method is to whitelist *

The following sections briefly describe Tachyon features which connect to the 1E Cloud.

Whitelisting connections to 1E
Whitelisting connections to 1E
For guidance on whitelisting and configuring Internet Explorer proxy settings, please refer to Preparation: Whitelisting for license activation and validation.

1E license service URL


Ensure the following URL is whitelisted:

This URL must be accessible from the Tachyon Server during setup and running of Tachyon.

The Tachyon license must be validated on a regular basis via internet contact with the 1E license service. The regular validation period is set when the license is requested.

For whitelisting purposes, the Tachyon Server (specifically the Coordinator Workflow module in the Master Stack) requires an Internet connection to the 1E license service, as defined in the license file itself. If activation fails, then the system will install but not be usable until activation is completed.


Tachyon Setup will report a warning in the Tachyon Setup - License File screen if it is unable to connect to the 1E license service. This is important only on the Tachyon Master Stack Server, not on other types of Tachyon Server. You can test the connection using Tachyon Setup or using Internet Explorer.


If you are whitelisting an IP address and your server has multiple network interfaces, then you can configure a persistent route using a similar process described in Preparation: Configuring a persistent route for SQL traffic.

Your Tachyon Server may not be able to connect to the 1E license service if your environment is using web proxy servers. Contact 1E for advice in case you have this type of setup.

1E Catalog service URL


Ensure the following URL is whitelisted:

This URL must be accessible from the Tachyon Server during setup and running of 1E Catalog. This enables the Catalog Update service to connect to the 1E Cloud Catalog and download the latest catalog entries.


1E Catalog may need additional configuration to support proxy servers, but this depends on the configuration you have in your current environment. Please contact 1E Support if you need help doing this.

1E Analytics URL


Ensure the following URL are whitelisted:


Or simply * or *

Multiexcerpt include
PageWithExcerptDesign Considerations

For more information, please refer to Design Considerations: Telemetry.

Firewall Ports

The following are extracts from the Communication Ports reference page.

Multiexcerpt include
PageWithExcerptCommunication Ports

Multiexcerpt include
MultiExcerptNamePort Tables
PageWithExcerptCommunication Ports

Multiexcerpt include
PageWithExcerptCommunication Ports

Browser support for the Tachyon Portal

Tachyon Explorer and Admin Portal
Tachyon Explorer and Admin Portal
 The table below shows Browser requirements for accessing the Tachyon Portal and its applications.

Multiexcerpt include
PageWithExcerptSupported Platforms

Deploying Tachyon clients

Tachyon client Windows installation account

Multiexcerpt include
PageWithExcerpt1EC52:Deploying 1E Client on Windows

Tachyon client non-Windows installation account

Multiexcerpt include
PageWithExcerpt1EC52:Common client requirements


Multiexcerpt include
MultiExcerptNameDeployment Choices
PageWithExcerpt1EC52:Deploying 1E Client on Windows

Supported Device Platforms

Multiexcerpt include
PageWithExcerpt1EC52:Supported Platforms

Requirements for verifying the Tachyon installation

The Verifying page provides detailed steps for verifying a new or upgraded infrastructure, including firsts steps for uploading and running instructions. Below is a list of requirements to perform verification testing.

Multiexcerpt include

Constraints of Legacy OS

Multiexcerpt include
PageWithExcerptSupported Platforms

Multiexcerpt include
PageWithExcerpt1EC52:Supported Platforms