Summary

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.

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

Server requirements

Server sizing for on-premises

The specifications in the tables below are for an on-premises single-server installation supporting up to a maximum of 50000 Agent devices. A single server can have up to five Tachyon Switches to support up to 250000 devices. Each additional Switch requires an additional 6GB RAM and an additional network interface for (IP Address) with a minimum of 1Gbps.  Please see the Server Sizing reference page for more detailed sizing information for up to 250000 devices. 

Tachyon Server is recommended to be installed on a dedicated server, and can be installed on physical or virtual hardware. Best performance is achieved using a local SQL Server installation. Extra care is required to ensure performance when implementing SQL Server in a virtual environment.  

If SQL Server is shared with databases for other applications, then it must be remote (split SQL) and its CPU and RAM should be increased accordingly.

CPU cores are logical cores (physical or virtual).

Local SQL configuration

When Tachyon Server and SQL Server are installed on the same server, then the SQL Server setting maximum server memory must be set to match the value required for SQL in the table below.

Local SQLLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon Server CPU cores22335612
Tachyon Server RAM (GB)481016182232
SQL Server maximum memory1112248
Tachyon Server Network Interfaces1111111

Remote SQL configuration

When using remote (split) SQL Server(s) then the Tachyon Server is recommended to have an additional network interface for SQL traffic as explained below.

Split SQLLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon Server CPU cores1122348
Tachyon Server RAM (GB)26812141624
Tachyon Server Network Interfaces1122222
SQL Server CPU cores1111224
SQL Server RAM (GB)244668

12

SQL Server maximum memory1112248

For other SQL Server requirements, please see SQL Server requirements below.

Server sizing for AWS and Azure

The following tables describe the supported instance sizing for various numbers of supported clients for both single server and split server implementations, as per on-premises sizing.

When compared with the on-premise sizing guidelines these instance sizes will generally provide a greater number of CPU cores and/or memory. There is an overhead inherent in commodity virtualized cloud computing solutions which prevents them from providing exactly the same level of performance as dedicated on-premise virtualization solutions. In some cases it is also necessary to provide more of a particular resource type than required in order to get sufficient levels of another resource type due to the limited number of instance configurations offered by the cloud provider.

Instance sizing is subject to change, and may not be available in all geographic regions.

AWSLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon with local SQL Servert2.mediumm5.largem5.xlargem5.xlargem5.2xlargem5.2xlargem5.4xlarge
Tachyon Servert2.smallm5.largem5.largem5.xlargem5.xlargem5.xlargem5.2xlarge
Remote SQL Servert3.mediumr5.larger5.larger5.larger5.larger5.xlarger5.2xlarge
AzureLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon with local SQL ServerA2_V2A4_V2D3_V3DS12_V2DS4_V2DS4_V2F16S
Tachyon ServerA1_V2D2_V3D11_V2D11_V2D4_V3D12_V2DS4_V2
Remote SQL ServerA2_V2DS2_V2DS2_V2DS2_V2DS2_V2DS2_V2DS3_V2

On this page:

AWS Network Configuration

For a split server installation it is necessary to configure an additional network interface into each server to guarantee a dedicated 1Gbps network channel between the core and the database. Enhanced networking (SR-IOV) must be enabled on both of these NICs which should be the default. Detailed steps on how to verify this are given here - http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/sriov-networking.html. Also increase the transmit (TX) and receive (RX) buffer sizes to their maximum under the network adaptor advanced properties.

Azure Network Configuration

For a split server installation it is necessary to configure an additional network interface into each server to guarantee a dedicated 1Gbps network channel between the core and the database. Enhanced networking (SR-IOV) must be enabled on both of these NICs where this is available (only on instances with 8cores or more) and must be enabled during instance creation. The additional NIC must also have accelerated networking enabled using Azure Powershell or Azure CLI. Detailed steps on how to configure this are given here - https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-create-vm-accelerated-networking. Also increase the transmit (TX) and receive (RX) buffer sizes to their maximum under the network adaptor advanced properties within the guest OS.

If connecting to an Azure based Tachyon switch via external public Azure IP addresses or Azure Load Balancers you will need to extend the default TCP timeout from 4 seconds to 15 seconds - Detailed steps on how to do this can be found here -  https://azure.microsoft.com/en-us/blog/new-configurable-idle-timeout-for-azure-load-balancer/

AWS Database Storage Configuration

Database instances (either combined or the database server in a split implementation) should use an additional Throughput Optimized SSD (ST1) EBS volume to guarantee sufficient disk performance. This is used for all database storage - data, log and tempdb. The specified instances do not support any more than one EBS volume. If you wish to separate data, log and tempdb onto separate volumes (as per Microsoft recommendations) you will need a higher spec instance for the DB server, one that will allow you to attach more volumes and allow higher throughput to disk.

For any implementation other than Lab the Elastic Block Storage (EBS) optimization must be enabled, either when the instance is originally launched or afterwards. Details on how to do this can be found here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

Azure Database Storage Configuration

Database instances (either combined or the database server in a split implementation) should have a minimum of 2 SSDs for database files. One for the Tachyon data files and tempdb and the other for the log files.

Disable caching on the volume used for the SQL log drive. This is done on the Azure console and not within the guest. Remember to restart the DB server VM once this is changed.

Do not use geo-redundant storage for any of the SQL drives.

A full list of optimizations for running SQL on Azure is available here:  https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-performance

Server software

CategoryProductNotes

Server OS

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2

For more detail, please refer to Requirements: Server requirements.

The server must be domain-joined.

This version of Tachyon requires the server to be US-English because of a known issue with certain regional settings.

SQL Server

  • SQL Server 2017
  • SQL Server 2016 SP2
  • SQL Server 2014 SP2

For more detail, please refer to Requirements: SQL Server requirements.

Databases must be configured to use a case-insensitive, accent-sensitive collation. The preferred collation is SQL_Latin1_General_CP1_CI_AS, which is also the default.

If installing SQL Server locally, note:

  • SQL Server 2014 requires .NET 3.5 SP1 and .NET 4.x - supported Server OS include both which will need to be enabled in Server Manager roles and features
  • SQL Server 2016 and 2017 require .NET 4.6 which requires KB2919355 on Windows Server 2012 R2
  • SQL Server setup requires PowerShell 2.0.

For latest information about SQL Server prerequisites, please refer to MSDN: Hardware and Software Requirements for Installing SQL Server.

SQL Server 2016 RTM is not supported due to some issues, which are resolved by SP1.

Please contact 1E if you require Microsoft SQL Cluster or SQL Always On to be used.

Microsoft System Center Configuration Manager

Not applicable.

Tachyon Server components have no dependencies on Configuration Manager.

Instead, see Tachyon Toolkit and Microsoft System Center Configuration Manager Console Extensions.

Web Server
  • IIS 10
  • IIS 8.5

See Preparation: Windows Server roles and features for details about required IIS roles and features.

Other Software

  • Visual C++ 2013 Redistributable
  • .NET Framework 4.7
  • .NET Framework 4.6.2
  • .NET Framework 4.6.1
  • .NET Framework 4.5.2
  • .NET Framework 3.5 SP1

See Preparation: Windows Server roles and features for details about required .NET Framework roles and features.

Windows Server 2012 R2 has .NET Framework 4.5.1 installed by default. You will need to upgrade to 4.6.1 or 4.6.2.

Windows Server 2016 has .NET Framework 4.6.1 installed by default.

Tachyon Server installer includes the redistributable package for Visual C++ 2013. The Tachyon Switch is written in C++ using Visual Studio 2013 and therefore requires the C++ 2013 runtime (x64); other server components use .NET.

PowerShell is required by the installer during installation.

Browsers

Latest version of:

  • Google Chrome
  • Internet Explorer 11
  • Microsoft Edge
  • Mozilla Firefox
A browser is not a prerequisite for installation of Tachyon Server, but is required to use and administer it. Administration is performed via the Tachyon Explorer Portal and can be on a remote computer.

Disk Space

Tachyon Server installation folder is approx. 70 MB.

Tachyon Server logs folder (see Tachyon Log Files) is approx. 210 MB.

For details of SQL database file sizes, please refer to the Server Sizing reference page.

Network interfaces

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

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

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

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

The table below summarizes the network interface requirements for a Response Stack's database and Switches, where n is the number of Switches on the server up to a maximum of five. 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.

DevicesSwitchesLocal SQLRemote SQL
Up to 50011 x 1Gbps1 x 1Gbps
Up to 50,00011 x 1Gbps1 x 1Gbps (SQL) + 1 x 1Gbps (Switch)
Up to 100,00022 x 1Gbps1 x 1Gbps (SQL) + 2 x 1Gbps (Switches)
Over 100,000n (3 or more, up to 5)n x 1Gbps1 x 10Gbps (SQL) + n x 1Gbps (Switches)

A Background Channel is normally installed on the same server as Switches so that devices can connect to both using the same DNS Name FQDN.

Computername

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: https://docs.microsoft.com/en-us/windows/desktop/SysInfo/computer-names

DNS Names

Each server that has Tachyon Server components installed requires its own DNS Name. The Master Stack enables Tachyon users, approvers and administrators to connect to the Explorer and Admin portals, therefore, it helps users if it has a recognizable and convenient DNS Name such as tachyon.

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

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

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

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

Service Principal Names

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

Windows Server roles and features

The following roles, role services and features must be installed/enabled as a minimum.

The Name column is the reference used in PowerShell commands; and for .NET Framework 4.X features the PowerShell name includes 45 instead of the actual version.

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.
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
Web Server Health and DiagnosticsHTTP LoggingWeb-Http-LoggingIncluded in Web-Server
Web Server PerformanceStatic Content CompressionWeb-Stat-CompressionIncluded in Web-Server
Web Server SecurityRequest FilteringWeb-FilteringIncluded in Web-Server
Basic AuthenticationWeb-Basic-AuthRequired only if using 1E ITSM Connect.
IP Address and Domain Restrictions (see note below)Web-IP-Security 
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-ASPNETIncluded in Web-Asp-Net45

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

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

IIS Features Configuration

Switches achieve high speed local communication with the Core by using HTTP instead of HTTPS. For this reason you will see HTTP as well as HTTPS bindings on the Tachyon web site. However, the Core web applications are locked down using IP and Domain Restrictions so that only local processes can access it. The other web applications cannot be accessed using HTTP because their SSL Settings are configured with Require SSL.

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

SQL Server requirements

Requirements for SQL Server are covered in other sections on this page:

Active Directory requirements

A Tachyon user can be either a domain account or a security group. 

Access to Tachyon features can be controlled in Tachyon Admin portal Permissions page as follows:

  • Adding individual Active Directory user accounts and assigning to roles. The Admin portal is used to manage these users and their assigned roles.
  • Adding Active Directory security groups and assigning to roles. Group membership is managed in Active Directory. 
  • A combination of the above.

Tachyon is able to operate in a multi-domain, multi-forest environment. If multiple forests are used then ensure trusts are in place that ensure all in-scope user accounts and groups are present in the Global Catalog of the forest in which the Tachyon Server resides. You have a choice of how Tachyon queries Active Directory, specified during installation.

GC method

Required if Tachyon users or groups exist in multiple domains or multiple trusted forests.

Supports only Universal security groups.

LDAP method

All Tachyon users and groups must exist within a single domain.

Supports Universal and Global security groups.

Required if a Global Catalog (GC) server does not exist in any trusted domain, or if Global AD Security groups must be used.

In either case, any domain(s) which contain Tachyon users and groups must be:

  • trusted by the domain in which the Tachyon Server exists
  • resolvable using DNS from the Tachyon Server

User accounts

All Tachyon users require accounts in Active Directory. AD accounts must have their userPrincipalName (UPN) attribute populated. This is normal, but may be missing if users accounts have been created using scripts.

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

Users are added to the Tachyon system and assigned roles by a Tachyon Security administrator using the Tachyon Explorer Admin portal.

See The Permissions page for an explanation of how to add users to the Tachyon system.

Active Directory Security Groups

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

Universal groups are recommended because these will be compatible with any potential future changes to the AD infrastructure.

AD Distribution groups are not supported.  An AD security group can be configured with an email address. 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 does not have an email address then Tachyon will send an email to each member that has an email address.

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

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. If you need this account to have additional Tachyon roles, then you will need to use an AD Security Group instead. The installation account has sufficient rights to add other Tachyon users, assign them to Tachyon roles, including the Permissions Administrator role, which should then be used for ongoing use and management of Tachyon.

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.

SQL Login 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 depends on the following:

  • whether or not company policy allows the sysadmin SQL Server role to be granted on the SQL instance(s) that will host the Tachyon Master and Responses databases,
  • whether the databases are created by hand before installation or created by the Tachyon Server installer during installation.
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 instances

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

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 Tachyon service account, used by the Tachyon Server web applications and services.

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

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

Databases must be configured in multi-user mode.

After installation, the SQL Login for the installation account must retain db_owner role on the databases, and ALTER ANY LOGIN, to support re-configurations and upgrades. If this is considered a security risk, then the server installation account can be disabled after the Tachyon system is operational, and re-enabled when required.

Tachyon user permissions

The server installation account has the following rights as a Tachyon user, configured during installation of the Tachyon Server.

Tachyon service account

Tachyon Server web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE. This version of Tachyon does not support using a domain user account.

SQL Login for the Tachyon 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

During installation, the Tachyon Server installer will always attempt to create the SQL Login and grant it db_owner permission on each of the Tachyon databases.

To replace db_owner with lower permissions based on least privilege, please refer to Tachyon Server post-installation tasks: Replace db_owner.


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.
  • Licences 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 license file must exist in the folder required by the Server Installer.
  • For an existing installation the license file is copied into the folder: %PROGRAMDATA%\1E\Licensing on your Tachyon Server.

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.

Whitelisting the 1E license service URL

The Tachyon license must be validated on a regular basis via internet contact with the 1E license service https://license.1e.com/ , which needs to be whitelisted in your organization - so that it's accessible during setup and running of Tachyon. 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.

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

Certificates

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 Agent devices

PKI 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 Agent or Server cannot be installed on the same server as a Root CA, because its certificate is self-signed.

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 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 Constraints of Legacy OS.

Tachyon Server Certificates

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

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
    • 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
    • The above CA certificates must exist on the Tachyon Web Server and Windows Agent devices
    • The above CA certificates will be exported and included in the PEM file used by the Switch and any non-Windows Agent devices
  2. Has at least the following Key Usage.
    • Digital signature
    • Key encipherment
  3. Has at least the following Enhanced Key Usages.
    • Server Authentication
  4. Private key must be available.
    • In Microsoft terminology, this means that the certificate allows the private key to be exported. The exported certificate is used by the Switch.
  5. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  6. The certificate is issued with its fields set to one of the following options. Option 2 is typical.
The default template Web Server available with a Microsoft PKI is suitable for requesting a Tachyon Web Server certificate provided you enable Make private key exportable.
FieldsOption 1Option 2

Subject Common Name Field (subject:commonName)

The DNS Alias FQDN of the server

Example: CN=TACHYON.ACME.LOCAL

The hostname FQDN of the server

Example: CN=ACME-TCN01.ACME.LOCAL

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

The DNS Alias FQDN of the server

Example: DNS Name=TACHYON.ACME.LOCAL

The DNS Alias FQDN of the server

Example: DNS Name=TACHYON.ACME.LOCAL

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

The hostname FQDN of the server

Example: DNS Name=ACME-TCN01.ACME.LOCAL


Example

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 hostname FQDN and DNS Alias FQDN.
  • It is not possible 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.

Example certificate request (using Option 2 type certificate)

 

Tachyon Agent Certificates

Each device requires a certificate with the following properties, in order for the Tachyon Agent to 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
    • 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
    • If the above CA certificates are different to those used by the Tachyon Web Server, they will need to be exported and then
      1. imported on the Tachyon Web Server
      2. included in the PEM file used by the Tachyon Switch
  2. Has at least the following Enhanced Key Usage
    • Client Authentication
  3. Has a private key
    • For a non-Windows device, this must be exportable
  4. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  5. Has a Subject Name of type Common Name (CN=<hostname>) or Subject Alternative Name (DNS Name=<hostname>) where <hostname> depends on the type of device:
    • On domain-joined Windows PCs this must be the hostname FQDN of the computer, for example W701.ACME.LOCAL
    • On workgroup Windows PCs and non-Windows devices, this must be the hostname 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

The Agent 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, the Tachyon Agent does not use proprietary certificate stores. Instead the Agent requires the certificate exists as a PFX in the Agent installation folder structure (see non-Windows Device Certificate).

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

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

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

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

Tachyon executables

On Windows computers, the installation MSIs, executables and DLLs of the Tachyon Server and Agent are digitally signed by 1E using the 1E Limited SHA1 and SHA256 signature certificates.

These signing certificates are issued by the Symantec Class 3 SHA256 Code Signing CA, which in turn is issued by the root CA VeriSign Class 3 Public Primary Certification Authority - G5

For Tachyon 3.2, the SHA1 and SHA256 signature certificates are each countersigned with the same Timestamp signature certificate:

  • Starfield Timestamp Authority - G2 , itself issued by Starfield Secure Certificate Authority - G2, in turn issued by the root CA  Starfield Root Certificate Authority – G2.

For Tachyon 3.1, the SHA1 and SHA256 signature certificates are countersigned with different Timestamp signatures:

  • SHA1 - Starfield Services Timestamp Authority - G1, issued by the root CA  Starfield Services Root Certificate Authority
  • SHA256 - Starfield Services Timestamp Authority - G2, issued by the root CA  Starfield Root Certificate Authority – G2

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 for legacy OS computers in a lab environment that are not connected to the Internet, see Constraints of 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 70KB. You can choose to modify the email banner header.

Emails are sent by the Workflow service and Authentication web application pools, which by default use 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 not configurable using the Server installer. The default is anonymous authentication. However, it can be changed post-installation. See Changing the SMTP Host configuration in Tachyon Server post-installation tasks for details of changing the SMTP configuration and disabling email notifications.

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

Tachyon users and approvers require email addresses 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 lookup 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.

Deprecated feature

An optional feature allows users to register a mobile device to receive authentication codes in addition to their emails. Users who wish to register a mobile device need to install the Tachyon App. A Tachyon Administrator must approve the mobile device registration, which sends an email to the user with a registration code to complete the registration process.

Supported mobile devices

CategoryProductNotes

Mobile OS

  • Android Nougat 7.0 and later
  • iOS 9 and later

The Tachyon App, also known as Tachyon Auth mobile app, is deprecated and will be removed in a future release of Tachyon. As a consequence, the Registered mobile phones administration page is also deprecated.



Feature Dependencies

1E companion products

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

Supported versions of 1E companion products with features that depend on Tachyon 3.3.

Products and features that depend on TachyonSupported versions of companion products
1E ITSM Connect1E ITSM Connect for ServiceNow requires a full Tachyon infrastructure.
  • 1E ITSM Connect 1.0
AppClarityTachyon powered inventory using the Tachyon connector and full Tachyon infrastructure. This is an optional feature of SLA Platform which AppClarity can use.
  • AppClarity 6.1.100 and SLA Platform 3.3
  • AppClarity 6.1 and SLA Platform 3.2
NightWatchmanConsole live status of NightWatchman clients. This is an optional feature of NightWatchman.
  • NightWatchman 7.2
NomadNomad Download Pause. This is an optional feature of Nomad.
  • Nomad 6.3.100
Shopping

Tachyon Agent Shopping Module is required for Shopping. This replaces the legacy Shopping Agent. Only the Tachyon Agent is required, not the full Tachyon infrastructure.

  • Shopping 5.5.100
  • Shopping 5.5
Shopping

Windows Servicing Assistant (WSA). This is an optional feature of Shopping.

  • Nomad 6.3.200
  • Shopping 5.5.100
  • Shopping 5.5
WakeUp

Tachyon Agent WakeUp Module is required for WakeUp. This replaces the WakeUp component of the 1E Agent. Only the Tachyon Agent is required, not the full Tachyon infrastructure.

  • WakeUp 7.2.500

Supported versions of 1E companion products that Tachyon 3.3 features depend on.

Products and features that Tachyon depends onSupported versions of companion products
NomadTachyon integration with Nomad, used by the Tachyon Agent for downloading resources. This is an optional feature of Tachyon if the Nomad Branch Agent is installed on clients.
  • Nomad 6.3

Product Packs and Security Roles

Product Packs are the means of installing a pack of instructions. Once the instructions are in Tachyon you need to organize them into Instruction Sets which are used as the basis for assigning custom roles that determine who can do what with the instructions in each Set.

You may want to create AD security groups to assign to custom roles instead of assigning users. You should think about groups of people who will view, question, action and approve packs of instructions.

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 server where the Tachyon Core 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

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

With the Nomad integration feature enabled, Tachyon Agent will detect if Nomad v6.0.100 or later version is running on the device, and automatically use it to download content from Tachyon Background Channel servers.

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)

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 Configuring the Tachyon Configuration Manager extensions.

 

PowerShell on Windows OS

PowerShell is used by some Tachyon instructions (that have PowerShell commands embedded or scripts that are downloaded) and some of these require PowerShell 3.0 or later, although some scripts will support PowerShell 2.0. PowerShell scripts are supported only on Windows OS. 

To see if an instruction requires PowerShell, look in its Instruction Definition XML file for PowerShell resources defined under the <Resources> tag.

If installing or upgrading PowerShell, it is best to install the latest version available. However, do not expect full forward or backward compatibility between PowerShell versions.

The table below shows which versions of PowerShell are supported on each OS version and Service Pack, and if it is built-in or needs to be installed.

OS VersionPowerShell VersionNotes
1.02.0 (Note 3)3.04.05.05.1
Windows Server 2016, 2019    RTM (Note 9)RTM (Notes 12, 13)Note 4
Windows 10



RTM (built-in)Anniversary Update (built-in)
Windows Server 2012 R2   RTM (built-in)RTM (Note 9)RTM (Note 12)Note 4
Windows 8.1   RTM (built-in)RTM (Note 9)RTM (Note 12) 
Windows Server 2012 *  RTM (built-in)RTM (Note 7)RTM (Note 9)RTM (Note 12)Note 4
Windows 8 *  RTM (built-in)    
Windows Server 2008 R2 * RTM (built-in)SP1 (Note 6)SP1 (Note 7)SP1 (Note 8)SP1 (Note 10)Note 4
Windows 7 RTM (built-in)SP1 (Note 6)SP1 (Note 7)SP1 (Note 8)SP1 (Note 10) 
Windows Server 2008 *RTM (built-in) SP1 & SP2 (Note 2)    
Windows Server 2003 *RTM & SP1R2 & SP2    Notes 1, 2
Windows Vista *RTMSP1 & SP2    Notes 1, 2
Windows XP *RTM, SP1 & SP2SP3
   Notes 1, 2

* These OS are regarded as Legacy OS.

  1. PowerShell is not built-in for these OS. These OS do not support 3.0 or later. See Constraints of Legacy OS.
  2. If PowerShell 1.0 is installed it must be removed in order to install a later version.
  3. Support for PowerShell 2.0 is included in PowerShell 3.0 and later.
  4. PowerShell is not installed by default on these OS but is an optional feature that should be enabled using Server Manager.
  5. PowerShell 2.0 is part of WMF Core package (KB968930) with prerequisite of .NET Framework 3.51 (which includes .NET 2.0 SP1).
  6. PowerShell 3.0 is part of WMF 3.0 with prerequisite of .NET Framework 4.0 or later. Refer https://www.microsoft.com/en-us/download/details.aspx?id=34595
  7. PowerShell 4.0 is part of WMF 4.0 with prerequisite of .NET Framework 4.5 or later. Refer https://www.microsoft.com/en-us/download/details.aspx?id=40855
  8. PowerShell 5.0 is part of WMF 5.0 with prerequisites of .NET Framework 4.5 or later and WMF 4.0. Refer https://www.microsoft.com/en-us/download/details.aspx?id=50395
  9. PowerShell 5.0 is part of WMF 5.0 without any other prerequisites. Refer https://www.microsoft.com/en-us/download/details.aspx?id=50395
  10. PowerShell 5.1 is part of WMF 5.1 with prerequisites of .NET Framework 4.6 or later, WMF 4.0 and SHA-2 Code Signing. Refer https://msdn.microsoft.com/en-us/powershell/wmf/5.1/install-configure
  11. PowerShell 5.1 is part of WMF 5.1 with prerequisites of .NET Framework 4.6 or later and WMF 4.0. Refer https://msdn.microsoft.com/en-us/powershell/wmf/5.1/install-configure
  12. PowerShell 5.1 is part of WMF 5.1 with prerequisite of .NET Framework 4.6 or later. Refer https://msdn.microsoft.com/en-us/powershell/wmf/5.1/install-configure
  13. In these Server OS, PowerShell 5.1 is referred to as the Desktop Experience. You can use the PowerShell Core version if you prefer.

Bash on non-Windows OS

Bash and perl are required for installation of all non-Windows Agents, with the exception of the Agent for Android which is available from the Google Playstore.

Tachyon instructions support the use of Bash scripts on all supported non-Windows OS.

To see if an Instruction requires a Bash script, look in its Instruction Definition XML file for Bash script resources defined under the <Resources> tag. Bash is the preferred choice when developing custom Instructions for non-Windows OS.

There are slight differences between OS implementations of Bash, particularly on the Mac. Therefore 1E recommends testing custom Bash scripts on each supported OS.

Agent scripting requirements

Tachyon Agent language SCALE directly supports running PowerShell on Windows and bash on non-Windows devices, which can be scripts that must be downloaded by SCALE when an instruction runs, or actual command text. You will very probably want to use this feature in your own instructions and ones that you download from 1E. Therefore you must ensure the appropriate scripting environment is present on Agent devices.

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

Firewall Ports

The following are extracts from the Communication Ports reference page.

The following table lists firewall requirements for a single-server installation where Tachyon Master Stack and Response Stack are installed on the same server. The table assumes a remote SQL Server hosting TachyonMaster and TachyonResponses databases.Each Tachyon component described in the table has at least one output and/or input. For each Tachyon component with an output there is a matching input.

Firewalls normally protect against incoming traffic from remote devices, however the table below also includes outgoing connections. The table does not include internal communications within the Server.

In addition to but not included in the table are various ports that Tachyon uses to communicate with Microsoft services, including Certificate Services and Active Directory. The Authentication service and Coordinator Workflow service query AD for email details; the Authentication service and the Consumer API query AD for security details.

If 1E Nomad Agent is being used by Tachyon Agent on Windows computers, it has additional port requirements of its own, which are not changed by Tachyon. Nomad connects to the Tachyon Background Channel.

Port requirements are not provided here for Tachyon Agent Shopping and WakeUp modules.

There may be additional requirements if the environment has had default security settings changed.

DevicePortProtocolDirectionUsageConfigurable

Tachyon Server (Master Stack)

TCP 443HTTPSIncoming

Yes, during installation. In the Website Configuration panel in Tachyon Setup.

See Server installer property HTTPSIISPORT

The Tachyon App, also known as Tachyon Auth mobile app, is deprecated and will be removed in a future release of Tachyon. As a consequence, the Registered mobile phones administration page is also deprecated.

Tachyon Server (Response Stack)

TCP 443HTTPSIncoming

Yes, during installation. In the Website Configuration panel in Tachyon Setup.

See Server installer property HTTPSIISPORT

Tachyon Server (Master Stack)

TCP 443HTTPSOutgoing

The Tachyon App, also known as Tachyon Auth mobile app, is deprecated and will be removed in a future release of Tachyon. As a consequence, the Registered mobile phones administration page is also deprecated.

The push messaging port is determined by relevant Push Messaging Services.

Optional. Required only if users of supported mobile devices have installed the Tachyon App. After installation, the App is used to register the mobile device for the user, which needs to be approved by a Tachyon Permissions AdministratorThe user will receive an authentication code as a push notification each time that user attempts to run an action.

The port used to connect to the 1E Cloud License Service is not configurable.

Tachyon Server (Response Stack)

TCP 4000WebSocketSecure (wss)Incoming

Switch ports are not configurable using the Server installer.

A Switch port can be changed post-installation, by configuring the value in the Port column for the relevant Switch in the SwitchConfiguration table in the Tachyon Master database.

If the Switch port is changed after deploying Agents then the corresponding Switch port must be updated in each Agent's configuration file.

Additional Switches can be installed using different ports, but this is a Complex Configuration.

Agents initiate and maintain a WebSocket Secure connection to a Switch, which the Switch uses to communicate back to the Agent.

Tachyon Server (Master Stack)

TCP 25SMTPOutgoing

Yes.

In this version of Tachyon, SMTP Authentication is not configurable using the Server installer. The default is anonymous authentication. However, it can be changed post-installation. See Changing the SMTP Host configuration in Tachyon Server post-installation tasks for details of changing the SMTP configuration and disabling email notifications.

Tachyon Server (Master Stack)

TCP 1433TDSOutgoing

Yes. In the Database Servers panels in Tachyon Setup. A SQL Server instance can be installed using a non-standard port.

See Server installer property SQLSERVER_MASTER.

Tachyon Server (Response Stack)

TCP 1433TDSOutgoing
  • Tachyon Web Site application pools (Core and Core Internal) communicating with SQL Server (mainly uncompressed responses).

Yes. In the Database Servers panels in Tachyon Setup. A SQL Server instance can be installed using a non-standard port.

See Server installer property SQLSERVER_RESPONSES.

SQL Server (TachyonMaster database)

TCP 1433TDSIncoming

Yes. In the Database Servers panels in Tachyon Setup . A SQL Server instance can be installed using a non-standard port.

See Server installer property SQLSERVER_MASTER .

SQL Server (TachyonResponses database)

TCP 1433TDSIncoming
  • Tachyon Web Site application. pools (Core and Core Internal) communicating with SQL Server (mainly uncompressed responses).

Yes. In the Database Servers panels in Tachyon Setup. A SQL Server instance can be installed using a non-standard port.

See Server installer property SQLSERVER_RESPONSES.

Tachyon Agents

TCP 4000WebSocket Secure (wss)Outgoing

Yes. See Agent installer property SWITCH.

Anything other than port 4000 requires a Tachyon Server with a Switch using the same port number.

Agents initiate and maintain a WebSocket Secure connection to a Switch, which the Switch uses to communicate back to the Agent.

Tachyon Agents

TCP 443HTTPSOutgoing

Yes, during installation. See Agent installer property BACKGROUNDCHANNELURL.

Tachyon Consoles

TCP 443HTTPSOutgoingAnything other than port 443 requires the port number to be included in the browser URL when connecting to the Tachyon Explorer and Admin portal.

Tachyon App

TCP 443HTTPSOutgoing

The Tachyon App, also known as Tachyon Auth mobile app, is deprecated and will be removed in a future release of Tachyon. As a consequence, the Registered mobile phones administration page is also deprecated.

The following table lists firewall requirements when using Response Stacks that are remote from the Master Stack, that are additional to the ports required for a Single-Server.

DevicePortProtocolDirectionUsageConfigurable

Tachyon Server (Master Stack)

TCP 443HTTPSOutgoing

Yes, during installation of the Response Stack. In the Website Configuration panel in Tachyon Setup.

See Server installer property HTTPSIISPORT

The Consumer API connection to the Core is only used for remote Response Stacks.

Tachyon Server (Response Stack)

TCP 443HTTPSIncoming
  • Tachyon Coordinator Workflow service on the remote Master Stack connecting to the Core on a remote Response Stack
  • Consumer API on the remote Master Stack connecting to the remote Background Channel on a remote Response Stack
  • Consumer API on the remote Master Stack connecting to the Core on a remote Response Stack

Yes, during installation of the Response Stack. In the Website Configuration panel in Tachyon Setup.

See Server installer property HTTPSIISPORT.

The Consumer API connection to the Core is only used for remote Response Stacks.

Tachyon Server (Master Stack)

TCP 3901WebSocket (ws)Incoming
  • Tachyon Switches sending instrumentation data to the Instrumentation module in the Coordinator on the Master Stack
  • Tachyon Web Site Core application pool sending instrumentation data to the Instrumentation module in the Coordinator on the Master Stack

Yes, but please contact 1E for advice.

Tachyon Server (Response Stack)

TCP 3901WebSocket (ws)Outgoing
  • Tachyon Switches sending instrumentation data to the Instrumentation module in the Coordinator on the Master Stack
  • Tachyon Web Site Core application pool sending instrumentation data to the Instrumentation module in the Coordinator on the Master Stack
Yes, but please contact 1E for advice.

SQL Server (TachyonMaster database)

TCP 1433TDSIncoming
  • Tachyon Web Site Core application pool on a remote Response Stack communicating directly with the Tachyon Master database

Yes. In the Database Servers panels in Tachyon Setup. A SQL Server instance can be installed using a non-standard port.

See Server installer property SQLSERVER_MASTER.

Tachyon Server (Response Stack)

TCP 1433TDSOutgoing
  • Tachyon Web Site Core application pool communicating directly with the remote Tachyon Master database

Yes. In the Database Servers panels in Tachyon Setup. A SQL Server instance can be installed using a non-standard port.

See Server installer property SQLSERVER_MASTER.

Tachyon Explorer and Admin Portal

The table below shows platform requirements for accessing the Tachyon Explorer and Admin Portal.

CategoryProductNotes

Browsers

Latest version of:

  • Google Chrome
  • Internet Explorer 11
  • Microsoft Edge
  • Mozilla Firefox

These browsers are supported on all OS platforms which the browser vendor supports.

Please review Known issues: Using Tachyon.

Deploying Tachyon Agents

Tachyon Agent Windows Installation Account

The Tachyon Agent installer installs a service as local system, therefore the installation account for Windows clients must be capable of being elevated in order to run the installer. The simplest way of achieving this is for the account to have the following properties:

  • Full local administrator rights (as a member of the localgroup administrators, either directly or indirectly)

Tachyon Agent non-Windows Installation Account

To install the Tachyon Agent on a non-Windows client the installation account must have privileges to run the sudo command.

Deployment

You must decide how you will configure the Tachyon Agent and deploy to devices. The configuration properties that depend on the configuration of the Tachyon Server are mandatory and set during installation, with other properties configurable post-installation.

For more information about configuring the Agent properties during and after installation, please refer to Tachyon Agent installer and configuration properties.

Deploying the Agent is normally achieved using your existing software deployment tool, for example Microsoft System Center Configuration Manager. Some organizations may require the Agent to be packaged.

Supported Device Platforms

CategoryProductNotes

Windows OS

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

Professional and Enterprise editions of Windows 10 are supported.

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

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

Please refer to sections on Legacy OS regarding Windows XP, Vista, Server 2003, 2008 and 2012, and PowerShell on Windows OS.

For installation guidance on Windows, please refer to Deploying Tachyon Agents: Deploying on Windows platforms.

Other Windows Software
  • Visual C++ 2013 Redistributable
  • PowerShell 3.0 (or later)
  • Nomad 6.2 (or later)

Tachyon Agent installer includes the redistributable package for Visual C++ 2013.

PowerShell is not a prerequisite for installation of the Agent. PowerShell is used only by Tachyon instructions that have PowerShell commands embedded or scripts that are downloaded.

1E Nomad Branch service is not a prerequisite for installation of the Agent. Nomad is only used to download instruction resource files if it is installed and the Tachyon Agent integration with Nomad feature is enabled.

For more details about PowerShell requirements, please refer to PowerShell on Windows OS below.

For more details please refer to Design Considerations: Downloading Agent Resources and Nomad Integration.

Non-Windows OS

macOS

  • macOS High Sierra 10.13

Linux

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

Solaris

  • Solaris 11.3

Android

  • Android Oreo 8.1
  • Android Oreo 8.0

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

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

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

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

  • Fedora 21
  • openSUSE Leap 42.1

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

For Solaris, the following specific libraries are required, but are usually installed by default:

  • libcurl
  • zlib

For installation guidance on the following OS, please refer to:

For installation guidance on other non-Windows OS, please contact 1E.

Other Non-Windows Software

  • Bash
  • Perl

Bash and perl are required for installation of all non-Windows Agents, with the exception of the Agent for Android.

Tachyon instructions support the use of Bash scripts on all supported non-Windows OS.

For more details please refer to Bash on non-Windows OS below.

Microsoft System Center Configuration Manager Client

Not applicable at this time.

Configuration Manager is not a prerequisite for installation of the Tachyon Agent, and the Tachyon Agent has no built-in providers or modules that depend on Configuration Manager.

Tachyon provides Configuration Manager Console extensions, which is part of the Tachyon Toolkit.

For more details please refer to Microsoft System Center Configuration Manager Console Extensions.

(Microsoft System Center Configuration Manager is also known as Configuration Manager, ConfigMgr and SCCM among other names. Version names include 2012 and Current Branch or CB.)

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.

  1. Tachyon Server installed
  2. Remote workstation with a supported browser
  3. The name and password for the server installation account 
    1. the AD account must be enabled
    2. the account may already be assigned to other Tachyon roles either directly or via membership of an AD group role.
  4. Two AD User accounts, Test User 1 and 2 
    1. must not be existing Tachyon users because they will be assigned specific roles for the purpose of these tests.
    2. must have email addresses and be able to read emails.
  5. The 1E-TachyonPlatform.zip product pack file containing the Tachyon Verification instructions, if not already installed. In these tests this file is referred to as the Tachyon Verification product pack.
  6. At least one test device on which the Tachyon Agent will be installed
  7. Tachyon Agent installation source files and configuration details required by your Tachyon implementation

Constraints of Legacy OS

In this documentation, the following are referred to as legacy OS. Below are described some known issues for these OS.

  • Windows XP
  • Windows Vista
  • Windows 8
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012

Support

1E does not provide support for the Tachyon Agent on the following OS. This is because Microsoft has withdrawn support for these OS or they are not significantly used by business organizations.

  • Windows XP
  • Windows Vista
  • Windows 8
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012

Please contact 1E if you require support for these legacy OS.

If you experience an issue on these OS, then please try replicating the issue on a supported OS.

PowerShell limitations

Some Tachyon instructions use PowerShell and some of those expect PowerShell version 3.0, which is not supported by the legacy OS listed above. However, PowerShell 2.0 is supported on the following OS versions:

  • Windows XP SP3
  • Vista SP1 & SP2
  • Windows Server 2003 R2 & SP2

Certificate limitations - encrypted certificate requests

Windows XP and Server 2003 are unable to encrypt certificate requests, whereas later OS are able to support higher more secure RPC authentication levels. If you are using a Microsoft CA and expect these clients to request (enrol) certificates then the CA must have its IF_ENFORCEENCRYPTICERTREQUEST flag disabled. It is disabled by default on Windows 2003 and 2008 CA, but is enabled by default on Windows 2012 CA.

To determine which InterfaceFlags are set, execute the following command on the CA server:

	certutil -getreg CA\InterfaceFlags

If the following is specified then it means the flag is enabled.

	IF_ENFORCEENCRYPTICERTREQUEST -- 200 (512)

To disable the encrypt certificate requests flag, execute the following commands on the CA server:

	certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST
sc stop certsvc
sc start certsvc

Certificate limitations - SHA2

When installing Tachyon Agent on Windows XP and Server 2003 you may also require a hotfix as described in KB968730. This hotfix is required if your PKI has CAs configured to use SHA2 256 or higher encryption.

Certificate limitations - expired root certificates

Ensure that your Root Certificates are up-to-date. The Update Root Certificates feature is enabled by default on these OS but its configuration may have been changed or restricted by Group Policy. You may see DisableRootAutoUpdate = 1 (dword) in HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot.

Certificate limitations - signing certificates missing

As described in Requirements: Digital Signing Certificates the root VeriSign Class 3 Public Primary Certification Authority - G5 certificate must exist in the Third-Party Root Certification Authorities store (which is replicated in the Trusted Root Certification Authorities store). This root certificate is normally automatically provided by Microsoft's Update Root Certificates feature, however this may not be present for legacy OS. To verify if you affected by this issue see Implementation issues: 1E Digital Signing Certificate.