Summary

What you will need to prepare in advance of implementing a Tachyon Server in your network. Typically these are tasks that may take some time to organize, depending on how your organization works. A more complete checklist of tasks is provided in Requirements.

Implementation Overview

Please review all tasks to decide how you wish to proceed, and record all configuration details.

Implementation of Tachyon can be extremely quick if all necessary preparations have taken place, and is typically performed in this order:

  1. Obtain the Tachyon License file
  2. Provision the Tachyon Web and SQL server hardware
  3. Optionally pre-create the Tachyon databases (you can allow the Tachyon Server installer to create the databases using default settings)
  4. Prepare the Mail Server
  5. Identify and create AD Accounts and Groups
  6. Review Requirements
  7. Run Tachyon Setup
  8. Manually install Tachyon Agents on a few test devices
  9. Use the Tachyon Verification Product Pack to verify the installation
  10. Install other Instruction Definitions - from the Tachyon Platform zip, and from Tachyon Exchange (https://tachyonexchange.1e.com) 
  11. Add the Instruction Definitions to Instruction Sets to determine their permissions
  12. Install Tachyon Consumers (documentation not provided here)
  13. Package the Tachyon Agent as required by your software deployment tool (see note)
  14. Deploy the Tachyon Agent to more pilot devices
  15. Pilot testing
  16. Start rollout of Agents
  17. Use the SDK to begin developing your own instructions and testing your use-cases

If your organization requires the Agent to be packaged, then you can do this once you know the DNS Name(s). Then you can prepare for deploying the Agent in parallel to preparing and installing the Server.

Details required when using Tachyon Setup to install a Tachyon Server

The table below lists details required on each of the Tachyon Setup screens. You can review screens in the Tachyon Setup page. Items marked * can wait until after installation.

Select configurationDocumentation ReferenceAll components installed on a single serverMaster StackResponse StackDMZ Server
Check Prerequisites

IIS Configuration

SQL BCP *

All prerequisites must be checked.All prerequisites must be checked.All prerequisites must be checked.

All prerequisites must be checked.

The list does not include "IP Address and Domain Restrictions" and "BCP".

CertificateWeb Server Certificate

A web server certificate is required for:

  • Website (including Explorer, Consumer API, Core and Background Channel)
  • Switch(es)

A web server certificate is required for:

  • Website (including Explorer and Consumer API)

A web server certificate is required for:

  • Website (Core and Background Channel)
  • Switch(es)

A web server certificate is required for:

  • Website (Background Channel)
  • Switch(es)
Manage trusted authoritiesWeb Server Certificate *Import the certificates of any trust authorities used by devices and remote servers that do not match the trust authority used by the Server certificate.Import the certificates of any trust authorities used by devices and remote servers that do not match the trust authority used by the Server certificate.Import the certificates of any trust authorities used by devices and remote servers that do not match the trust authority used by the Server certificate.Import the certificates of any trust authorities used by devices and remote servers that do not match the trust authority used by the Server certificate.
License file

License file

Code Signing Certificates *

The Tachyon license file is required to complete Setup, and confirm internet access to the 1E licensing service.

The Tachyon license file is required to complete Setup, and confirm internet access to the 1E licensing service.The Tachyon license file is required to complete Setup, and to cross-check number of devices supported by this server.The Tachyon license file is required to complete Setup, and to cross-check number of devices supported by this server.
Database servers

SQL Databases

Name of the SQL Server instance that will host the new TachyonMaster database.

Name of the SQL Server instance that will host the new TachyonResponses database.

Keep old DB or not (n/a for new installation).

If using a remote SQL Server, please refer to Network interfaces.

Name of the SQL Server instance that will host the new TachyonMaster database.

Keep old DB or not (n/a for new installation).

Name of the SQL Server instance that hosts the existing TachyonMaster database.

Name of the SQL Server instance that will host the new TachyonResponses database.

Keep old DB or not (n/a for new installation).

If using a remote SQL Server, please refer to Network interfaces.

This page is greyed out.

The DMZ Server does not have direct access to SQL Servers. Access to databases is via the Core API on the internal Response Stack. Manual steps are required to configure access to the Core API, as described in Implementing a Tachyon DMZ Server.

Number of devices

Design Considerations - Architecture page

Specify the number of devices supported by this server in order to calculate number of Switches required.The number is only used to cross-check against the number in the license file.Specify the number of devices supported by this server in order to calculate number of Switches required.Specify the number of devices supported by this server in order to calculate number of Switches required.
Switch configurationNetwork interfaces

Select an IP Address for each Switch. All Switch IP Addresses will typically use the same DNS Name.

Confirm that when the Responses database is remote from the server, and the number of devices is more than 500, that SQL traffic uses a different IP address to the Switch(es).

This page is greyed out.

The Master Stack does not require Switch configuration.

Select an IP Address for each Switch. All Switch IP Addresses will typically use the same DNS Name.

Confirm that when the Responses database is remote from the server, and the number of devices is more than 500, that SQL traffic uses a different IP address to the Switch(es).

Select an IP Address for each Switch. All Switch IP Addresses will typically use the same DNS Name.

Website configurationIIS ConfigurationRequired for web-site.Required for web-siteRequired for web-site.

Required for web-site.

Specify names for the internal facing network interface.

The HTTPS binding for the external facing network interface is created manually after installation.

Active Directory and email

Requirements - Email Requirements

Requirements - Two-factor Authentication Requirements

Required for Master Stack components.Required for Master Stack components.

n/a

(Uncheck Enable SMTP)

n/a

(Uncheck Enable SMTP)

Other requirements

Post-installation requirements

On this page:

License file

You will need to obtain a valid license file from 1E. For more details please refer to the License file heading on the Requirements page.

Whitelisting for license activation and validation

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.

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 below in 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. The Tachyon Coordinator uses Internet Explorer proxy settings and these may need to be updated on the Tachyon (Master Stack) Server. Proxy settings are updated using a proxy-auto config (PAC) file with rules that allow the server to connect to https://license.1e.com/ either directly or via the proxy server. Your web proxy administrator should already be familiar with deploying PAC files via Group Policy (GPO).

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

Server Provisioning

An IIS Web Server should be provisioned. SQL Server can be installed on the same server or the databases can be hosted on remote SQL Server instance(s).

Please refer to Requirements regarding hardware and software specifications for on-premises and cloud servers.

In addition, the Tachyon Server requires the following, which require more thought and preparation, described below.

Network interfaces

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

Number and speed of server network interfaces

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

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

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

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

Cloud implementations have special configuration requirements for SQL Server and network interfaces described in Requirements: Server sizing for AWS and Azure.

Configuring a persistent route for SQL traffic

The following example steps can be used to configure IPv4 network routing so that a specific network interface is used for all traffic going to the specified SQL Server. The example is for a Response Stack and SQL Server on different subnets but also works if both servers are on the same subnet.

If you add a new interface for SQL traffic after installing Tachyon, then ensure the interface is not registered in DNS using the same DNS Name that devices use to connect to Switches or Background Channel. If you intend using the new interface to support inbound HTTP traffic from remote Response Stacks then you will also need to configure the Tachyon website to include the IP Address of the new interface as described in Implementation issues: IP address and domain restrictions. In our example below we would add 10.0.10.31. Installation and upgrades will automatically configure IP Address and Domain restrictions.

  1. On the Tachyon Server (single-server or Response Stack) open a PowerShell command prompt


  2. The following command should resolve the name and IP Address of the SQL Server, and show the existing network route. In our example the  10.0.20.20.

    pathping ACME-SQL02
  3. If not already installed on the server, add a new interface. Configure its properties as follows:

    • Disable IPv6
    • Configure IPv4 properties and assign a static IP Address and subnet mask. In our example these are 10.0.10.31 and 255.255.255.0.
    • You do not need to configure a default gateway. You can if required, but you will receive a warning later about multiple default gateways and redundancy. However, you do need to know the default gateway for the route to the SQL Server, in our example this is 10.0.10.1.
    • Click Advanced... and click on the DNS tab. Uncheck Register this connection's addresses in DNS so that the interface IP Address is NOT registered in DNS.
    • Click OK twice to save, and then Close
    • You can give the interface a name to help distinguish it from Switch interfaces. In our example this is SQL interface

    This interface must not be registered in DNS if the DNS Name of the server is a CNAME Alias for (A) Host records registered by Switch interfaces, because Agents need to use the DNS Name to connect to Switches. If you need this interface to be registered in DNS then do this with a (A) Host record.

  4.  Enter the following PowerShell command, which provides all the details you need to confirm interfaces have been configured correctly.

    Get-NetIPConfiguration              
  5. This provides output similar to the following, and tells us the interface index for the new interface. In our example this is 7.

    InterfaceAlias       : Interface used for SQL
    InterfaceIndex       : 7
    InterfaceDescription : Microsoft Hyper-V Network Adapter #4
    NetProfile.Name      : ACME.local
    IPv4Address          : 10.0.10.31
    IPv4DefaultGateway   : 10.0.10.1
    DNSServer            : 10.0.1.2
                           10.0.1.3
    
    InterfaceAlias       : Interface used for Switch 1
    InterfaceIndex       : 5
    InterfaceDescription : Microsoft Hyper-V Network Adapter #3
    NetProfile.Name      : ACME.local
    IPv4Address          : 10.0.10.32
    IPv4DefaultGateway   : 10.0.10.1
    DNSServer            : 10.0.1.2
                           10.0.1.3
  6. Use the route command to add a persistent route. The mask must be  255.255.255.255 and NOT the same as the interface mask configured earlier, because the persistent route to the SQL Server is for its IP Address and not its subnet.

    route -p add <SQL Server IP Address> mask 255.255.255.255 <Interface used for SQL IPv4DefaultGateway> metric 1 if <Interface used for SQL InterfaceIndex>
    

    In our example:

    route -p add 10.0.20.20 mask 255.255.255.255 10.0.10.1 metric 1 if 7

    In a lab, where you might have only one subnet with no routing, you would need to specify the IP address <Interface used for SQL IPv4Address> instead of a real gateway < Interface used for SQL IPv4DefaultGateway >. In our example, you would use 10.0.10.31 instead of 10.0.10.1.

    route -p add 10.0.20.20 mask 255.255.255.255 10.0.31.1 metric 1 if 7

    If your lab has no routing then you should ensure other means for your Tachyon Server to connect to the 1E license service via the Internet.

  7. Enter the following command to confirm that the <SQL Server IP Address> has a persistent route with the details specified. In our example this is 10.0.20.20.

    route print
  8. Enter the following command to verify the route works and uses the correct interface.

    pathping ACME-SQL02

    The first line (hop 0) must show the name of the Tachyon Server and the IP Address of the interface. This IP Address will then be selected as used for SQL in the Switch configuration screen of Tachyon Setup. In our example this would be:

    0  ACME-TCN01.ACME.local [10.0.10.31]

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 Tachyon Portal, therefore, it helps users if it has a recognizable and convenient DNS Name such as tachyon.

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

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

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

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

Where possible the Tachyon Server DNS Name should be a CNAME Alias which references the (A) Host records for each of the Switch network interfaces registered in DNS.

Ensure network interfaces used for anything other than Switches, for example the SQL interface, are not registered in DNS. If they are registered ensure the DNS Name used by Switches only have Switch IP Addresses assigned.

For multiple Switches to share the same DNS Name, the load balancing options include:

  • DNS round-robin. Create a CNAME record which references the (A) Host records for each of the Switch network interfaces registered in DNS.
  • Network Load Balance (NLB) and register the Tachyon Server's DNS Name as the NLB Name, and configure the NLB to forward to each of the Switch IP Addresses.

DNS round-robin provides reasonable load balancing, so that devices should be evenly spread across all Switches. Each device will cache the IP Address given it by DNS and keep using that, even if the Switch using that IP Address is not available, until the TTL expires or the DNS cache is flushed. A Network Load Balancer (NLB) allows all the Switches to share the same DNS Name which is actually the IP Address of the NLB Cluster, which can then intelligently route the connection to a Switch interface.

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.

If an SPN is not created the you will see "401 Not authenticated" errors in the browser and/or log files.

SPNs are not required for DNS Names used to connect to Switches and Background Channel, because they do not use Windows Authentication.

Service Principal Names (SPN) are attributes of AD accounts. A domain administrator will need to create an HTTP class SPN for the Tachyon web server service account, by using one of the following methods:

  • by editing the ServicePrincipalName attribute of the web server's computer account
  • using the SETSPN commands below substituting your DNS Name, server and service account
setspn -l ACME\ACME-TCN01$
setspn -s http/acme-tcn01.acme.local ACME\ACME-TCN01$
setspn -s http/tachyon.acme.local ACME\ACME-TCN01$

The above example assumes :

  • Tachyon web application pools are using Network Service
  • The Tachyon server name is ACME-TCN01 with a computer account in the ACME domain, which means the service account is ACME\ACME-TCN01$
  • The DNS Name for the server is tachyon.acme.local

If in doubt, create both SPNs.

The above commands achieve the following:

  1. Lists existing SPNs for the service account. Run this to record details before you request for any new SPN(s) to be created. Re-run this after creation, ensuring you wait sufficient time for AD replication to occur.
  2. Creates an SPN for a CNAME record.
  3. Creates an SPN for a (A) Host record.

To determine which type of record a DNS Name is, run the following command:

nslookup tachyon.acme.local
  • If the command returns Name:  acme-tcn01.acmelocal  and alias tachyon.acme.local then tachyon.acme.local is a CNAME record.
  • If the command returns Name: tachyon.acme.local and no aliases then tachyon.acme.local is a (A) Host record.

More complex scenarios can be configured which requires in-depth knowledge of IIS, SPN and DNS configuration and are beyond the scope of this documentation.

Web Server Certificate

What do I need to begin?

You will need to have requested a Web Server certificate from your Certificate Authority, using the specification below.

To get the certificate in your organization you will have either:

  • Submitted a CSR and received a password protected .pfx file.
  • Used the Certificate Enrollment wizard to request a suitable Web Server certificate.

Import the Web Server certificate

Once the Web Server certificate has been provided it must be imported into the Tachyon Server's local computer Personal Certificates store.

After importing, you should give the certificate a Friendly Name, so that you can easily identify it for the post-installation task Confirming the Tachyon website HTTPS binding.

  1. On the Tachyon Server, start certlm.msc (or start mmc and add the certificates snap-in for the local machine) 
  2. Navigate to the Personal Certificates store
  3. Locate the Web Server certificate you have just imported
  4. Right-click on the certificate and select Properties
  5. In the General tab enter a Friendly name, for example Tachyon
  6. Click OK to save

Web Server certificate specification

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

Switch certificate files

The following three files are used by the Switch to validate secure communications between it and other Tachyon components and Tachyon agents. You can manually create these files or use Tachyon Setup to create them. Tachyon Setup automatically detects the presence of these files in an existing installation Switch SSL folder, or if they do not exist there it will also look in the setup folder.

FileDescription
<computername>.cer

Where <computername> is the hostname of the server where the Tachyon Web Server and Switch is installed.

This file contains:

  • The public key of the Tachyon Web Server certificate, which will be used by the Switch.
<computername>.key

Where <computername> is the hostname of the server where the Tachyon Web Server and Switch is installed.

This file contains:

  • The private key of the Tachyon Web Server certificate, which will be used by the Switch.

The key is not encrypted with a passphrase (it does not have a password). Therefore this file should be protected as described in Services and NTFS Security.

cacert.pem

The Switch uses this file to validate the certification paths (trust chains) for all the components it communicates with.

This file contains a list of CA public keys:

  • For the Tachyon Web Server:
      • The public keys for all the intermediate CAs, up to and including the Root CA, in the Tachyon Web Server certificate’s certification path.
  • For the Tachyon Agent devices:
      • All the public keys for all the intermediate CAs, up to and including the Root CAs, for each of the Tachyon Agent device certificate’s certification paths.
      • Should also include the old keys of any CA in any of the certification paths that has had its certificate renewed or re-issued, because Agent devices may still be using the old trust certificates.

CNG certificates

Tachyon Server supports using a Cryptographic New Generation (CNG) certificate, however Tachyon Setup is unable to process all types of CNG certificates.  If Tachyon Setup has a problem with a CNG certificate then you will need to manually create the three Switch certificate using instructions in Creating Switch Certificate Files using openSSL.

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 PowerShell commands can be used to install relevant IIS roles and features, and record the server configuration in a file.

Download...

Configure IIS using PowerShell
Import-Module ServerManager

Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-1.txt -Append
Install-WindowsFeature Web-Server,
Web-Dyn-Compression,
# Web-Basic-Auth,
Web-IP-Security,
Web-Windows-Auth,
Web-Asp-Net45,
Web-Mgmt-Console,
Net-Framework-45-Core,
Net-Framework-45-ASPNET

Uninstall-WindowsFeature Web-DAV-Publishing
   
Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-2.txt -Append
Include Web-Basic-Auth if you will be installing 1E ITSM Connect.


If TLS 1.0 is disabled

Web server registry settings

If TLS 1.0 is disabled on the Web server, you must add the following two registry entries, in order for the 1E Catalog Update Service to successfully connect to the 1E Cloud Catalog.

Download...

Import registry entries
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001


SQL Server 2012 Native Client

Tachyon Setup requires SQL Server 2012 Native Client to be installed in order for some of its installers to connect to and validate SQL Server instances. If SQL Server is local then it is probably already installed, but if SQL Server is remote, then you will need to install the SQL Server 2012 Native Client on the web server. You can download the installer (sqlncli.msi) from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=50402, and then install the Client Components feature. This download supports SQL Server 2012, 2014, 2016 and 2017.

The requirement is only for installation because the installers require ODBC (OLE DB) drivers provided by SQL Server 2012 Native Client when TLS 1.0 is disabled, and Tachyon Setup assumes TLS 1.0 is disabled. The requirement is not necessary for running because all Tachyon components use .NET Framework which contains the necessary drivers.

You can confirm SQL Server 2012 Native Client is installed by using the ODBC Data Sources utility and looking for SQL Server Native Client 11.0 or by looking in Programs and Features for SQL Server 2012 Native Client.

If SQL Server 2012 Native Client is not installed then installers will fail with Error 27502. Could not connect to Microsoft SQL Server ... SSL Security error.

Services and NTFS Security

Tachyon and SLA PLatform services, including web application pools, use built-in accounts Local System (SYSTEM) and Network Service (NETWORK SERVICE) by default, and 1E recommends this configuration.

You must ensure these built-in accounts have the necessary NTFS security permissions on the Tachyon and SLA Platform installation and log folders.

If you are using default installation settings for Tachyon server on a default configuration of Windows Server, then Local System has the necessary permissions by default, but Network Service requires some additional steps. The simplest method is to add Network Service to the Administrators localgroup, which allows the default installation and logs folders to be created during installation.

However adding Network Service to the Administrators localgroup is not considered best practice, therefore alternative methods are described below.

The table below lists the Tachyon services and their default service accounts.

Tachyon serviceService account nameDescriptionSID
1E Tachyon Switch Host service.NT AUTHORITY\SYSTEMLocal SystemS-1-5-18

1E Tachyon Coordinator service.

1E SLA PLatform services (3).

>Web application pools: Catalog (1), Tachyon (5) and SLAPlatform (3).

NT AUTHORITY\NETWORK SERVICENetwork ServiceS-1-5-20
1E Catalog Update Service and web application pool.<domain account>

The table below lists the default folder locations which must have NTFS security permissions configured for all service accounts. The Tachyon installation process does not modify permissions.

FolderDefault locationService accountNTFS security
Installation folders

%ProgramFiles%\1E\Catalog\

<domain account>Minimum of read & execute permission (folder, subfolders and files).

%ProgramFiles%\1E\Tachyon\

%ProgramFiles%\1E\SLA Platform\

Network Service
Logs folders%ProgramData%\1E\Catalog\<domain account>Minimum of Full Control permission (folder, subfolders and files).

%ProgramData%\1E\Licensing\

%ProgramData%\1E\Platform Consumer\

%ProgramData%\1E\SLA Platform\

%ProgramData%\1E\Tachyon\

Network Service

For a default installation of Tachyon on a default configuration of Windows Server, Local System has the necessary permissions by default, but Network Service requires some additional steps.

You have a choice of how to configure NTFS security for Network Service, using one of the following options, according to your organization's policies.

You can pre-create the Tachyon installation and logs folders prior to installation and apply NTFS permissions on these instead of their parent folders.

ChoiceMethod
Administrators localgroup

Add NETWORK SERVICE to the Administrators localgroup (this is simplest method but not best practice).

Users localgroup

Add NETWORK SERVICE to the Users localgroup, and grant this group permissions on the folders.

  • Default INSTALLDIR does not need to be modified because Users localgroup has inherited read & execute permission
  • Default LOGPATH requires the inherited Users  localgroup to be modified to give Full Control  permission
Direct permissions

As above, but grant NETWORK SERVICE direct rights on the folders

The Server Installation Account should be a member of the Administrators localgroup, so that it has full rights on the server.

Using a non-default location for the Installation Folder

If you are installing in a non-default installation folder, or the default installation folder has non-standard NTFS security, then before installation, you must ensure the installation folder is pre-created with suitable NTFS security applied. If this is not done, some services will fail to start, or users will not be able to access the website.

The NTFS security for the service accounts described above, must be explicitly applied.

In addition, the Users or Authenticated Users localgroup must have a minimum of read & execute permission on each of the Web application folders (folder, subfolders and files).  This is simplest to achieve by granting permission on the INSTALLDIR folder.

The example screenshot shows

  • A non-default installation INSTALLDIR=D:\Program Files\1E\Tachyon\
  • RX permissions for the Users group is applied to the 1E folder
  • Other permissions are inherited from the root of the D: drive
  • INSTALLDIR permissions are inherited from the 1E folder
  • NETWORK SERVICE is a member of the Users localgroup

Using non-default permissions for the Switch SSL folder

The NTFS permissions on the SSL folder can be locked down after installation in order to protect the certificate files. The SSL folder exists in the Switch installation folder and inherits its NTFS permissions, which are inherited from the Tachyon installation folder.

If permissions are modified the minimum requirement is for the SYSTEM account to have read & execute permission on the SSL folder and files, assuming that the 1E Tachyon Switch Host service uses the Local System account, which is the default.

The example screenshot shows the same non-default installation described above and the SSL folder has had inheritance removed and the Users local group has been removed.

Using a non-default location for the Logs Folder

The accounts used by Tachyon services and application pools must have a minimum of Full Control permission on the logs folder (folder, subfolders and files.

The example screenshot shows a default installation. For a default installation the only permissions necessary are SYSTEM and Administrators, both Full Control.

SQL Databases

There are two databases with default names TachyonMaster and TachyonResponses, which can be on the same or separate SQL Server instances.  A SQL Server instance can be on the Tachyon Server (local) or on a remote SQL Server. If you want to select the location and sizes of the Tachyon Master and Responses databases these can be created before installation with appropriate permissions, or you can allow the Tachyon Server installer to create the databases.

For a new installation, and for upgrades, the Server Installation Account requires a SQL Login with appropriate permissions.

Default configuration of databases

If you allow the installer to create new databases they each have the following default settings. Databases will grow automatically to the sizes estimated in Server Sizing.

PropertyValue
Owner

If the Installer is used to create the databases, this will be the Server Installation Account.

Best practice is to change owner to 'sa' as described below.

CollationSQL_Latin1_General_CP1_CI_AS
PathDefault SQL location
Initial Size MDF128MB
Autogrowth MDFBy 128MB
Initial Size LDF128MB
Autogrowth LDF10%
Recovery ModelSimple

If the model system database has been changed to have a larger size than the values specified in the table above, then the Tachyon Server installer may report an error executing 'Bootstrap.sql' on MasterDatabase. Rebooting the SQL Server may cure the error.

Creating your own databases

You may be required to create the Tachyon databases by hand before installation. This is also known as pre-creating databases. Below are some of the reasons why your SQL administrator may require you to do this:

  • the Server Installation Account is only allowed rights on existing databases and not allowed rights to create them
  • the locations of the database files need to be different to the defaults used on the SQL Server instance(s)
  • the initial size of the database files need to be set to their estimated full size given in Server Sizing.

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.

Example SQL scripts for creating a SQL Login and granting roles

The following examples assume ACME\TCNinstaller01 is the Server Installation Account.

When the account is not permitted to have the sysadmin SQL Server role, then a sysadmin can use the following script to create a SQL Login and grant it rights.

Create SQL Login and grant ALTER ANY LOGIN
USE [master]
GO
CREATE LOGIN [ACME\TCNinstaller01] FROM WINDOWS
GO
GRANT ALTER ANY LOGIN TO [ACME\TCNinstaller01]
GO

If the installation account is permitted to create the databases, then a sysadmin can use the following script to add the SQL Login to the dbcreator role.

Grant dbcreator
USE [master]
GO
ALTER SERVER ROLE [dbcreator] ADD MEMBER [ACME\TCNinstaller01]
GO

If the databases have been pre-created, then a sysadmin can use the following script to add the SQL Login to the db_owner role on each pre-created database.

Grant db_owner
USE [TachyonMaster]
GO
CREATE USER [ACME\TCNinstaller01] FOR LOGIN [ACME\TCNinstaller01];
ALTER ROLE [db_owner] ADD member [ACME\TCNinstaller01];
GO
USE [TachyonResponses]
GO
CREATE USER [ACME\TCNinstaller01] FOR LOGIN [ACME\TCNinstaller01];
ALTER ROLE [db_owner] ADD member [ACME\TCNinstaller01];
GO

After the databases have been created, best practice is to change the owner of each database to sa, to avoid issues if the owner's Windows account is deleted in future.

The following script can be used to change the owner of each Tachyon database to sa. This will work even if the sa login has been disabled, which is also best practice.

Change owner to 'sa'
ALTER AUTHORIZATION ON DATABASE::TachyonMaster To "sa"
GO
ALTER AUTHORIZATION ON DATABASE::TachyonResponses To "sa"
GO

Ensure the  server installation account retains the db_owner role on the database to support re-configuration and upgrades. If the account is removed from being owner, then it will also be removed from the db_owner role and will need to be re-assigned, for example by using the Grant db_owner SQL script.

The owner user and db_owner role are both mapped to the database dbo user. It is preferable for the account to be a member of the db_owner role, instead of being the owner user.

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.

Keeping databases during re-installation and upgrade

If re-installing or upgrading Tachyon you need to decide if you will keep the existing databases or create new ones.

The Tachyon Master database contains all the configuration data of the Tachyon system.  If new settings are used during re-installation these will be updated in the database.

The Tachyon Responses database contains transient responses and can be kept or a new database created without loss of system integrity.

Backup First!

Before doing a re-installation or upgrade of the Tachyon Server, make a backup of the following:

  • TachyonMaster database

    Backing up the Tachyon Responses database is not usually needed, unless there are instruction responses that you need to keep. Tachyon responses are not permanently held data and will naturally expire according to the settings specified when an instruction was run, typically in hours or possibly days. If in doubt, there is no harm in backing up the Tachyon Responses database as well.

  • Tachyon Server installation directory
    • including the config files, which may have been manually updated in the previous installation
    • Switch certificate files
  • Earlier versions of Product Packs that have been modified

    You will not be able to load pre-3.1 Product Packs into Tachyon 4.0. From version 3.1 onwards, Product Packs completely changed both in format and licensing.

    Product Packs from version 3.1 onwards can be loaded directly into Tachyon 4.0.

SQL BCP

To enable Tachyon users with the appropriate permissions to use the Export all feature you must ensure that the Microsoft Bulk Copy Program (BCP) is installed on each Tachyon Response Stack server, specifically where the Core component is hosted.

  • If Microsoft SQL Server is installed on the same server as the Tachyon Response Stack then BCP will normally be present.
  • If the TachyonResponses database is remote to the Tachyon Response Stack and there is no local copy of Microsoft SQL Server then you will need to install BCP.

You can confirm BCP is installed by starting a command prompt and typing bcp and usage information is displayed. The command bcp -v displays the version.

Two methods for installing BCP are:

  1. Use SQL Server installation media.
    • For SQL Server 2014 and earlier versions, use SQL Server setup. Install the Management Tools - Basic feature of Microsoft SQL Server. This feature includes the BCP component, and also includes SQL Server Management Studio. See https://docs.microsoft.com/en-us/sql/sql-server/install/feature-selection?view=sql-server-2014.
    • For SQL Server 2016 and later versions, use SQL Server Installation Center and select Install SQL Server Management Tools, which will need an Internet connection
  2. Install SQL Server Feature Pack components. Go to the Microsoft Download Center and search for the Microsoft SQL Server Feature Pack that corresponds to the version and Service Pack of the version of SQL Server that is hosting the Tachyon Responses database. For example https://www.microsoft.com/en-us/download/details.aspx?id=54279 for SQL Server 2016 SP1. The components from the feature pack, required to support BCP, are downloaded and installed separately:
    • ENU\x64\msodbcsql.msi (ODBC)
    • ENU\x64\MsSqlCmdLnUtils.msi (Command-line utilities)

Email

Tachyon users and approvers require AD accounts with email addresses to support approval workflow and notifications.

Mail Server

For details about mail server requirements, please refer to Requirements: SMTP Server.

Active Directory

Tachyon Server must be installed on a domain-joined server. Agents do not have to be installed on domain-joined devices, but must have a certificate.

Installation Accounts

Tachyon Server Installation Account

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.

In addition, the server installation account requires SQL rights as described in SQL Databases above.

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

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.

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

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

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

AD security groups must be Universal, not Global.

Anti-Virus and Malware

1E log files should be excluded from scans in order to prevent potential file locking.

See Log files for details of Tachyon Server and Agent logs. 

Tachyon Agent devices preparation

Please ensure devices that will be used to validate and test the Tachyon installation have the following.

Nomad integration on Windows devices

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)

Agent certificate requirements

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

In organisations that have an established PKI, the Agent devices will probably have a suitable certificate already, along with relevant Trusted Root CA certificates.

For non-Windows devices, the certificate files must be included in the Agent installation folder structure, as described below in Configuring the Non-Windows Tachyon certificate using OpenSSL.

CA public keys

Agents need to authenticate Switches and Switches need to authenticate Agents.  In each case, one end needs to have the public key for each CA in the other end's certificate certification path (trust chain).

The Agent needs the public key of each CA in the Switch's certification path. These public keys are stored differently on the Agent device depending on the type of OS.

  • For Windows devices, CA public keys are normally stored in the Windows Trusted Root Certification Authorities store. 
  • For non-Windows devices, CA public keys are stored in a cacert.pem located in the Agent installation folder. The Agent's cacert.pem file is copy of the basic cacert.pem file created for the Switch, described in Switch certificate files above.

The following points should be noted for Windows Agent devices:

  • If each Agent device has an identical certification path as the Switch then its CA certificates (public keys) will probably already exist in the Windows Trusted Root Certification Authorities store. This is a typical situation in a small scale lab with a simple PKI.
  • If any Agent device has a different certification path then the certificates (public keys) of the different CAs will need to be added to the Windows Trusted Root Certification Authorities store on devices.
  • In each of the above cases, the CA certificates (public keys) may have been deployed by Group Policy.

The Switch needs the public key of each CA that exists in each Agent's certification path.  As described in Switch certificate files, in preparation for installing the Tachyon Server and its Switch, a basic PEM was created containing the public keys of the CAs used by the Tachyon Web Server's certification path. The following points should be noted for the cacert.pem file used by the Switch:

  • If each Agent device has an identical certification path as the Switch then the basic .pem file will be sufficient. This is a typical situation in a small scale lab with a simple PKI.
  • If any Agent device has a different certification path then the public keys of the different CAs will need to be appended to the basic .pem file.
  • The PEM should include old keys of any CA in any of the certification paths that has had its certificate renewed or re-issued, because Agent devices may still be using the old trust certificates.

If any of these CAs has its certificate renewed or re-issued then

  • the Windows Trusted Root Certification Authorities store will need to be updated on the Tachyon Server and Windows Agent devices. Most organisations have automated processes for this task.
  • an updated .pem file must be distributed to non-Windows devices. This should include old and new keys to aid with the transition.
  • the .pem file will need to be updated on the Switch. This should include old and new keys to aid with the transition.

Configuring the Non-Windows Tachyon certificate using OpenSSL

Each non-Windows devices requires its own certificate. Below is a guide for using a Microsoft CA to issue a certificate; then exporting it and using OpenSSL to prepare it before installing it on the device.

First, you will need to have created a new Certificate template on your Certificate Authority by making a duplicate of either the Computer or Workstation template and configuring it with at least the following properties.

  • General - use a suitable name such as Tachyon Devices and validity period.
  • Request Handling - Allow private keys to be exported
  • Subject Name - Allow information to be supplied in the certificate request, rather than being built from Active Directory information.
  • Extensions - Application Policies should contain only Client Authentication
  • Security - ensure relevant users and computers will be able to request certificates

Once the new template is created on the CA, issue it.

Using the issued template, request a certificate for a target device, and export it in .pfx form and remember the password. 

The target device requires a copy of the basic cacert.pem and the .pfx file with its password removed. You can do this using the following steps. Use the relevant OpenSSL version for the OS. OpenSSL is normally available by default on Linux and Mac devices. If you want to follow these steps on Windows you will need to download the open source version appropriate to your OS.

  1. First, extract the certificate:

    openssl pkcs12 -clcerts -nokeys -in <YourPKCSFile> -out certificate.crt
  2. Second, the CA key: 

    openssl pkcs12 -cacerts -nokeys -in <YourPKCSFile> -out ca-cert.ca
  3. Now, the private key: 

    openssl pkcs12 -nocerts -in <YourPKCSFile> -out private.key -passout pass:TemporaryPassword
  4. Remove the passphrase: 

    openssl rsa -in private.key -out new.key -passin pass:TemporaryPassword
  5. Put things together for the new PKCS-File (on Windows, type can be used instead of cat): 

    cat new.key > PEM.pem
    cat certificate.crt >> PEM.pem
    cat ca-cert.ca >> PEM.pem
  6. And create the new .pfx file, when prompted for a password ensure that you enter an empty password (that is press enter when prompted for the password and confirmation without entering any text): 

    openssl pkcs12 -export -nodes -CAfile ca-cert.ca -in PEM.pem -out Tachyon.pfx
  7. Now you have a new PKCS12 key file without passphrase on the private key part. This Tachyon.pfx file and the cacert.pem file (a copy of the basic .pem file created for the switch, as described in Switch certificate files), must be placed in one of the following locations - depending on the OS. These are hidden folders.

    On Linux and Solaris:

    /etc/1E/Tachyon/Agent/.sslcerts

    On Mac:

    /Library/Application Support/1E/Tachyon/Agent/.sslcerts