Preparation for Tachyon Explorer is the same as for Tachyon Platform, as described on Tachyon Platform 8.0 - Preparation and reproduced below:

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 - ensure it includes entries for the consumer applications you have purchased
  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 clients 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 client as required by your software deployment tool (see note)
  14. Deploy the Tachyon client to more pilot devices
  15. Pilot testing
  16. Start rollout of Tachyon clients
  17. Use the SDK to begin developing your own instructions and testing your use-cases

If your organization requires the Tachyon client to be packaged, then you can do this once you know the DNS Name(s). Then you can prepare for deploying the Tachyon client 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.

Tachyon Setup

Documentation Reference

All components installed on a single server

Master Stack

Response Stack

DMZ Server

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 the number of devices supported by this server.

The Tachyon license file is required to complete Setup, and to cross-check the number of devices supported by this server.

Configuration


Decide which applications you want to install from the following list:

  • Experience

  • Nomad

  • Business Intelligence (required for Patch Success)

  • AppClarity

  • Application Migration

Decide which applications you want to install from the following list:

  • Experience

  • Nomad

  • Business Intelligence (required for Patch Success)

  • AppClarity

  • Application Migration

Select Nomad if you are using, or plan to use Nomad.

Select Nomad if you are using, or plan to use Nomad.

Check prerequisites

Web Server Certificate

IIS Configuration

All prerequisites must be checked, including:

All prerequisites must be checked, including:

All prerequisites must be checked, including:

All prerequisites must be checked.

Server certificate

Web Server Certificate (server)

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)

Client certificates

Web Server Certificate (clients) *

Decide whether you will require certificates to be presented by the clients.

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.

Decide whether you will require certificates to be presented by the clients.

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.

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.

Names of the SQL Server instances that will host the additional databases used by any bundled components that are selected for installation.

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.

Names of the SQL Server instances that will host the additional databases used by any bundled components that are selected for installation.

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.

SSAS servers


SSAS Databases

BI SSAS user - only if the BI component is selected for installation

Name(s) of the SQL Server SSAS instance(s) that will host each multidimensional data cube for Experience and BI (for Patch Success).

Account credentials that will be used for the BI services.

Name(s) of the SQL Server SSAS instance(s) that will host each multidimensional data cube for Experience and BI (for Patch Success).

Account credentials that will be used for the BI services.

n/a

n/a

Number of devices

Design Considerations:  Architecture page

Specify the number of devices supported by this server in order to calculate number of Switches required, as well as the number of Workers and Slots used by the Switches.

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 configuration

Network interfaces

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

If the TachyonResponses database is remote from the server, and the number of devices is more than 500, provide an additional interface so that SQL traffic uses a different IP address to the Switch(es), and see and Configuring a persistent route for SQL traffic.

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.

If the TachyonResponses database is remote from the server, and the number of devices is more than 500, provide  an additional interface so that SQL traffic uses a different IP address to the Switch(es), and see and Configuring a persistent route for SQL traffic.

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

Provide an additional interface so that internal traffic uses a different IP address to the Switch(es), and see and Configuring a persistent route for SQL traffic.

Website configuration

IIS Configuration

Required for website.

Required for website.

Required for website.

Required for website.

Specify names for the internal facing network interface.

The HTTPS binding for the external facing network interlace 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)

Telemetry

Design Considerations: Telemetry

Optional.

Optional.

n/a

n/a

SLA and 1E Catalog

1E Catalog

Confirm internet access to the 1E Cloud Catalog.

Confirm internet access to the 1E Cloud Catalog.

n/a

n/a

Nomad

Nomad 

(Only if installing Nomad)

If Nomad is enabled:

  • Name of the Configuration Manager site server that will be queried to locate its SQL database 

  • The synchronization interval in minutes

  • Client authentication certificate for the Background Channel to communicate with Content Distribution API.

If Nomad is enabled:

  • Name of the Configuration Manager site server that will be queried to locate its SQL database 

  • The synchronization interval in minutes.

If Nomad is enabled:

  • Client authentication certificate for the Background Channel to communicate with Content Distribution API.

If Nomad is enabled:

  • Client authentication certificate for the Background Channel to communicate with Content Distribution API.

Other requirements

Post-installation requirements


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

Ensure the following URL is whitelisted:

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

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

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

Other URL must also be whitelisted, please refer to Requirements: Whitelisting connections to 1E Cloud.

Code Signing Certificates

You will need your own code signing certificate, and have it registered in your Tachyon license, if you want to develop your own custom Tachyon instructions, or modify those of other authors. Instructions that are provided in the Tachyon Platform zip or downloaded from the Tachyon Exchange have already been code signed using the Platform and Exchange certificates from 1E. Your Tachyon license controls whether you can use these instructions.

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


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

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

Switches

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

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

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

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

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

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

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

DMZ Server

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

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

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

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

 Tachyon Setup supports installation using IPv4. If you have a working IPv6 environment, then please contact 1E for advice on using that.

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

Cloud implementations have special configuration requirements for SQL Server and network interfaces described in Server sizing

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 Interface used for SQL

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

    For networks with no routing, such as a lab, the default gateway is 0.0.0.0. Therefore, <Interface used for SQL IPv4DefaultGateway> must be specified as 0.0.0.0. In our example:

    route -p add 10.0.20.20 mask 255.255.255.255 0.0.0.0 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 platform components installed requires its own DNS Name. A DNS Name can be a DNS alias, CNAME or Host (A) record.

Master Stack

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

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

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

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

DMZ Server

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

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

Response Stack

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

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

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

Single DNS Name

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

If the server has multiple Switches, and therefore multiple network interfaces, then the same DNS Name can be shared by all Switches, the Background Channel and Master Stack.

Multiple client-facing DNS Names

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

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

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

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

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

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

HTTP binding

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

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

HTTPS binding

Required. This is the main binding.

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

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

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

Alternate HTTPS binding

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

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

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

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

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

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

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

Internal DNS Names

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

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

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

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


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

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

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

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

Tachyon Platform and applications use underlying IIS and SQL Server technology, and only require HTTP or MSSQLSvc class SPNs if your company security policy has configured IIS or SQL Server to use Kerberos authentication. 

If your IIS server is using Kerberos, then each DNS Name used to access a Tachyon Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the relevant service account in Directory, which is computer$ by default. This allows Tachyon web applications to authenticate clients using Windows Authentication where Kerberos is an authentication provider (primary, fallback or negotiated).

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

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

SPNs are not required for DNS Names used to connect to Switches and Background Channel, because they do not use Windows Authentication. However, the same DNS Name may be used to access other web applications.

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

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 following SETSPN commands, 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$

Use each command as follows:

  1. List 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. Use this if tachyon.acme.local is a CNAME record and its (A) Host record is acme-tcn01.acme.local
  3. Use this if tachyon.acme.local is a (A) Host record.

The above example assumes:

  • The service account for all Tachyon web application pools is 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, it does no harm to create an SPN for each DNS Name used to access the Tachyon Server, including its CNAMEs and (A) Host records using: setspn -s http/<DNS Name> ACME\ACME-TCN01$

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.acme.local 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

In previous version of Tachyon the private key had to be exportable to create certificate files for Tachyon Switches, but this is no longer required for Tachyon 5.0 onwards.

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 (except for a remote SQL Server). This certificate is also used by the Tachyon Switch and the Tachyon Coordinator. Therefore, a single-server installation requires only one Web Server certificate. This certificate must be provided on the server prior to installation of Tachyon.

The Web Server certificate requires the minimum of the following:

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

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

DMZ Server

Please ensure you note the additional certificate requirements described below, when installing any server in a system that also contains a DMZ Server. Internal Master and Response Stack servers, and DMZ Server, each require two HTTPS bindings, as described in DNS Names. For even more detail, please refer  Implementing a Tachyon DMZ Server .  

Also note the requirement for server certificates to reference at least one CRL Distribution point that uses HTTP. These CRL DPs are likely to be in the internal network, and the firewall will need to allow the DMZ server to access these internal servers.

Web Server certificates used by a Tachyon Servers must be issued with their fields set as follows. Example DNS Names are discussed in DNS Names.

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

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

On a Master Stack - example: DNS Name=TACHYON.ACME.LOCAL

On a Response Stack - example: DNS Name=TACHYONRS.ACME.LOCAL

On a DMZ Server - example: DNS Name=TACHYONEXT.ACME.COM

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

An Alternate DNS Name FQDN (DNS Alias) of the server. This is usually mandatory, for example if there is more than one server in your Tachyon system, as discussed in DNS Names.

On a Master Stack, example: DNS Name=TACHYONALT.ACME.LOCAL or DNS Name=TACHYON.ACME.LOCAL

On a Response Stack - example: DNS Name=TACHYONALT.ACME.LOCAL

On a DMZ Server - example: DNS Name=TACHYONDMZ.ACME.LOCAL

Example

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

The computername FQDN of the server

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

Add any additional DNS Names here.
Example certificate request

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

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

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

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

The DNS Alias FQDN of the server

Example: CN=TACHYON.ACME.LOCAL

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

The DNS Alias FQDN of the server

Example: DNS Name=TACHYON.ACME.LOCAL

The computername FQDN of the server

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

Example certificate request

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

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

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

Switch certificate files

Tachyon Switches use certificates in the Windows Certificate Store. From version 5.0 onwards they no longer use Switch Certificate files.

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.

When you run Tachyon Setup, you may choose to let the Setup perform this operation for you instead of downloading and running the script manually. Just click on the Install missing prerequisites button after you have run the checks in the Check prerequisites page.


Click here to download - RolesInstall.ps1

RolesInstall.ps1 - Configure IIS using PowerShell
Import-Module ServerManager

Get-WindowsFeature | Out-file $PSScriptRoot\ServerManager-1.txt -Append
Install-WindowsFeature Web-Server,
Web-Http-Redirect,
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

When running the above command, if you receive an error that contains The source files could not be downloaded you will need to supply the source path to your Windows Server OS installation media \Sources\sxs folder.

Append -source X:\Sources\sxs or -source \\Server\Path\Source\sxs to the command line, adjusted for your drive letter or UNC path.

PowerShell always uses 45 in the names of .NET Framework features irrespective of the actual version of .NET Framework 4.X installed on the server. That is 4.6.2 in Windows Server 2016 and 4.7.2 in Windows Server 2019. You can install later versions manually either before or after enabling features.

For details of .NET Framework versions, please refer to https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements#supported-server-operating-systems.

If you prefer to use the Add Roles and Features Wizard to manually enable features then you can use the Display Names listed in the table Requirements: Windows Server roles and features.

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

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


ASP.NET Core Hosting Bundle

This is required on the Tachyon Master Stack server if you are installing Nomad and Content Distribution features.

If it is not already installed, Tachyon Setup will attempt to automatically download and install version 3.1.11. However, this supposes your installation account and the server is whitelisted to allow download from https://download.visualstudio.microsoft.com/download/pr/d8b046b7-c812-4200-905d-d2e0242be9d5/53d5698d79013be0232152ae1b43c86b/dotnet-hosting-3.1.11-win.exe.

If you want to download it yourself, or a later version, then go to https://dotnet.microsoft.com/download/dotnet and then install it using a command similar to the following:

dotnet-hosting-3.1.11-win.exe OPT_NO_X86=1 /install

The parameter  OPT_NO_X86=1 causes the installer to only install the 64-bit version, which is what Tachyon requires. 

You may experience an error if some bundle components are already installed. If this happens, then re-run using /repair instead of /install .

You can run the following command to list the installed versions of .NET 

%ProgramFiles%\dotnet\dotnet.exe --list-runtimes


If TLS1.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, for the 1E Catalog Update Service to successfully connect to the 1E Cloud Catalog.

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 BCP

The Export all feature is described in Tachyon Explorer 8.0 - Exporting data from Tachyon Explorer. To enable Tachyon users with the appropriate permissions to use the Export all feature you must ensure that Microsoft Bulk Copy Program (BCP) is installed on each Tachyon Response Stack, specifically the Response server 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.

The information here applies regardless of which version of SQL Server is being used. This does not imply that Tachyon itself is supported under every possible version of SQL Server that falls within those ranges. See Requirements for the supported versions and required Service Packs.

Install the following components to get BCP working:

Installer file nameProduct NameWhere to get it from
vc_redist.x64.exeVisual C++ 2017 Redistributablehttps://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads
msodbcsql.msi Microsoft® ODBC Driver 13.1 for SQL Server®

https://www.microsoft.com/en-us/download/details.aspx?id=53339

This needs to be installed because of a known issue in the Microsoft Command Line Utilities 15 for SQL Server.

msodbcsql.msi Microsoft® ODBC Driver 17 for SQL Server®https://www.microsoft.com/en-us/download/details.aspx?id=56567

MsSqlCmdLnUtils.msi

Microsoft Command Line Utilities 15 for SQL Server

https://docs.microsoft.com/en-us/sql/tools/bcp-utility

The msi includes BCP and SQLCMD.

To verify the components have been installed, you can use AppWiz.cpl and check for the Product Name.

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 serviceNT AUTHORITY\SYSTEMLocal SystemS-1-5-18

1E Catalog Update Service

1E SLA Platform services (3)

1E Tachyon Coordinator service

Web application pools:

  • Catalog (1)
  • SLAPlatform (3)
  • Tachyon (5)
NT AUTHORITY\NETWORK SERVICENetwork ServiceS-1-5-20

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, except for the %ProgramData%\1E\Licensing\ folder which does receive full permissions for Network Service.

FolderDefault locationService accountNTFS security
Installation folders

%ProgramFiles%\1E\Catalog\

%ProgramFiles%\1E\SLA Platform\

%ProgramFiles%\1E\Tachyon\

Network Service

SYSTEM

Minimum of read & execute permission (folder, subfolders and files).
Logs folders

%ProgramData%\1E\Catalog\

%ProgramData%\1E\DatabaseUpgrade\

%ProgramData%\1E\Licensing\

%ProgramData%\1E\Platform Consumer\

%ProgramData%\1E\SLA Platform\

%ProgramData%\1E\Tachyon\

Network Service

SYSTEM

Minimum of Full Control permission (folder, subfolders and files).

For a default installation of Tachyon on a default configuration of Windows Server, Local System (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 the 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 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

For a basic Tachyon installation with no additional components selected, 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.

If additional components such as 1E Catalog are selected for installation, then they will deploy their own databases, which are described in each product's specific documentation.

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

The following is a list of databases used by Tachyon Platform. In the Tachyon Setup: Database servers screen, you can select the name of the SQL Server instance, but it does not let you change the database names.

  • TachyonMaster
  • TachyonResponses
  • 1ECatalog
  • SLA databases must be installed on the same instance:
    • SLA-Data
    • SLA-Shared
    • SLA-Integrate
  • ContentDistribution (required for Nomad)
  • SLA-BI (this is the Business Intelligence database required for Patch Success)
  • TachyonExperience (required for Experience)

The following is a list of database cubes used by Tachyon Platform. In the Tachyon Setup: SSAS servers screen, you can select the name of the SQL Server instance, but it does not let you change the database names.

  • SLA-BI (this is the Business Intelligence cube required for Patch Success)
  • TachyonExperience (required for Experience)

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 required by the installation account depends on which Tachyon components it is installing.

Master Stacks

For master stacks sysadmin is required as follows:

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

Response Stacks

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

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

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

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


Choice implemented

Role required for the installation account's SQL Login

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

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

Also required when upgrading Tachyon.

db_owner database role on the pre-created databases:

  • TachyonResponses

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

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

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

Databases must be configured in multi-user mode.

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

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

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

During installation, the Tachyon Setup will always:

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


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.

Before doing a re-installation or upgrade of the Tachyon Platfrom, make a backup of the following (but first see the note below about automatic backups):

  • 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

Tachyon Setup will automatically perform a backup of the following items:

  • Tachyon Server installation directory. This is backed up to a subfolder named Tachyon.bak under the root installation folder for Tachyon. All files, including the .config files and certificate files, will be copied.
  • IIS configuration. This is done by taking a copy of the applicationhost.config file from the Windows system folders. The backup file is placed at the same location, and is named like the original file with a suffix that indicates the date and time when the copy was taken.
  • The following databases are backed up to the default location for backups that is configured in the database server. By default, this points to a subfolder named "Backups" under the folder where the executable for SQL Server is installed. Unless you are installing a small lab or proof-of-concept, this is usually not a good location for the backups, so make sure that you configure the backup location in SQL Server to an adequate folder before starting the Tachyon upgrade:
    • 1ECatalog
    • ActiveEfficiency (optional, previously required for Nomad)
    • ContentDistribution (optional, required by Nomad)
    • SLA-Data
    • SLA-Shared
    • SLA-Integrate
    • SLA-BI (optional, required for Patch Success)
    • TachyonMaster
    • TachyonResponses
    • TachyonExperience (optional, required for Experience)

The Product packs are not copied by themselves, but they are kept in a table within the TachyonMaster database, which is backed-up.


SSAS Databases

If Experience or Business Intelligence is selected for installation, then you will need to provide an instance of SQL Server Analysis Services (SSAS) configured in Multidimensional (not Tabular) mode.

Make sure that the SSAS instance is enabled, reachable, configured in Multidimensional mode, and the Server Installation Account has sufficient permissions. The Setup program is not able to perform a full validation of the SSAS server, so you need to ensure a proper configuration during the preparation phase.

Business Intelligence is a component required by Patch Success, and requires a BI SSAS user.

The BI SSAS User account has the following requirements:

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

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


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, except for a DMZ Server, where this is optional. Tachyon clients 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 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 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 and SSAS Databases above.

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

  • It is the first Tachyon user account and is a System Principal, which means it cannot be deleted or assigned any other rights
  • It is assigned to the Tachyon system role of Installer
  • It should be used to add additional Tachyon users and administrators, assign them to Tachyon roles, which should then be used for ongoing use and management of Tachyon.
  • It may be included in any AD security group assigned to a Tachyon system or custom role.

Refer to Roles and Securables for a complete reference of Tachyon system roles, custom roles, securables and operations.

Tachyon client Windows Installation Account

The 1E Client 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 full local administrator rights (as a member of the localgroup administrators, either directly or indirectly).

Tachyon client Non-Windows Installation Account

To install the 1E Client on a non-Windows client the installation account must have privileges to run the sudo command.

Tachyon Users Accounts

Each Tachyon user requires an account in Directory. AD accounts must have their userPrincipalName (UPN) attribute populated, which is normal, but may be missing if users accounts have been created using scripts.

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

Directory security groups are strongly recommended for role-based access control (RBAC) but are not mandatory. AD security groups can be assigned to Tachyon roles after installation, they are not required during installation. They are added as Tachyon users and configured in the same way as AD user accounts. A Tachyon user can therefore be a domain user account or a security group. Groups are not mandatory because users can be assigned to roles and managed within Tachyon instead of AD, or a combination.

Tachyon Setup assigns a limited set of permissions to the server installation account, as described in Tachyon user permissions, which cannot be edited. However, the installation account's permissions can be extended if the account is a member of one or more AD Groups configured as Tachyon users.

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

AD distribution groups are not supported.

Service accounts

Tachyon Platform uses either Network Service or Local system for all its services and web application pools.

Please refer to the following sections regarding any rights these accounts may require:


Microsoft Endpoint Configuration Manager preparation

Tachyon Platform requires permission to access various features of Configuration Manager when you implement any of the following optional features.

Configuring SQL rights in the Configuration Manager database

The Network Service account of the Tachyon Master Stack server requires a SQL Login, with all the following rights in the Configuration Manager site database.

  • db_datareader database role
  • Explicit Execute permissions to the scalar value function fn_GetAppState
  • Explicit Execute permissions to the scalar value function fnGetSiteNumber
  1. If the connector is using Windows Authentication, then you can use one of the following:
    1. Create a SQL Login for the Tachyon server's computer$ account, and explicitly grant it the above rights.
    2. Add the  Tachyon server's computer$ account to the ConfigMgr_DViewAccess localgroup on the Configuration Manager database server - this is the preferred method

      You may already be familiar with configuring ConfigMgr_DViewAccess if you have previously set up Configuration Manager access for older versions of Nomad Dashboard which used ActiveEfficiency Server, or the ActiveEfficiency Scout, as used for AppClarity 5.x or Shopping 5.x and 6.0

      The existence of the ConfigMgr_DViewAccess localgroup depends on the version of Configuration Manager. It should exist for a Primary Site, but may not exist for a CAS. If it does not already exist, it is safe for you to manually create the localgroup on the SQL Server used by the Configuration Manager database. If it already exists, you will need to confirm it has a SQL Login and all the necessary rights, as Configuration Manager setup does not always configure this group correctly.

      The following SQL script can be used to create a SQL Login for ConfigMgr_DViewAccess and grant it permissions on the Configuration Manager database. Before you run the SQL script, you must first:

      • manually create the localgroup on the SQL Server
      • add the Tachyon server's computer$ account to the localgroup.

      Click here to download - ConfigMgr_DViewAccess_permissions.SQL

      ConfigMgr_DViewAccess_permissions.SQL
      -- Connect to the SQL instance using an account that has sysadmin rights.
      -- Execute this SQL script on the Configuration Manager database.
      -- The script creates a SQL Login on the instance for [hostname\ConfigMgr_DViewAccess]
      -- and grants it the following rights on the Configuration Manager database:
      -- [db_datareader]
      -- EXECUTE on [dbo].[fn_GetAppState]
      -- EXECUTE on [dbo].[fnGetSiteNumber]
       
      DECLARE @SqlLogin nvarchar(2000)
      DECLARE @SqlString nvarchar(max)
       
      SET @SqlLogin = CAST(host_name() AS varchar(512)) + '\ConfigMgr_DViewAccess'
      PRINT 'Granting permissions for ''' + @SqlLogin + ''' on database ' + DB_NAME() + ' ...'
       
      SET @SqlString = '
      IF NOT EXISTS ( SELECT schema_name FROM information_schema.schemata WHERE schema_name = '''+@SqlLogin +''' )
      EXEC (''CREATE SCHEMA [' + @SqlLogin + ']'')
      '
      EXEC sp_executesql @SqlString
       
      SET @SqlString = '
      IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = '''+ @SqlLogin +''')
      CREATE LOGIN [' + @SqlLogin + '] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
      '
      EXEC sp_executesql @SqlString
       
      SET @SqlString = '
      IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = '''+ @SqlLogin +''')
      CREATE USER [' + @SqlLogin + '] FOR LOGIN [' + @SqlLogin + '] WITH DEFAULT_SCHEMA=[' + @SqlLogin + ']
      '
      EXEC sp_executesql @SqlString
      PRINT 'SQL Login created.'
       
      SET @SqlString = '
      ALTER ROLE [db_datareader] ADD MEMBER [' + @SqlLogin + ']
      GRANT EXECUTE ON [dbo].[fn_GetAppState] TO [' + @SqlLogin + '] AS [dbo]
      GRANT EXECUTE ON [dbo].[fnGetSiteNumber] TO [' + @SqlLogin + '] AS [dbo]
      '
      EXEC sp_executesql @SqlString
      PRINT 'Permissions granted.'
      

      When you run Tachyon Setup, the Nomad screen will attempt to validate the existence of the ConfigMgr_DViewAccess localgroup and membership of the Tachyon server's computer$ account. The validation test will fail if the installation account does not have sysadmin rights on the SQL Server instance used by Configuration Manager. This is not a fatal error as long as you are sure the computer$ account is a member of the ConfigMgr_DViewAccess localgroup.

If you opt to use a specific SQL Login for the

  1. If the connector is using a SQL Login, then create the login on the Configuration Manager database and grant it the above rights

To install Nomad features, Tachyon Setup requires your server installation account to have the following rights. Please refer to Tachyon Setup: Nomad.

  • Read-only Analyst rights in Configuration Manager Console - so that Setup can query the Site Server for details of the Configuration Manager database
  • SQL Login (with public role) on the SQL database instance that hosts the Configuration Manager database - so that Setup can run a SQL query to validate that the machine account is a member of the ConfigMgr_DViewAccess localgroup on the SQL Server

If either of the above rights are not provided then Setup will issue a warning to say it was not possible to verify the machine account is a member of the 'ConfigMgr_DViewAccess' group. 

Kerberos delegation of SQL credentials to connect to a remote Configuration Manager database

The following steps to configure Kerberos delegation, are only required if you are using Nomad, and the following are on three separate servers:

  1. Tachyon Platform - specifically the Content Distribution component used by Nomad
  2. Content Distribution database - specifically the Linked Server used by Content Distribution
  3. Configuration Manager database.

Three separate servers is also known as double-hop, which requires Kerberos constrained delegation to allow the Content Distribution web application account on (1), to use the Content Distribution linked server on (2), to connect to the Configuration Manager database on (3). To put it another way, the SQL service account used by the SQL Server instance on (2) must be trusted to present delegated credentials from (1) to the SQL Server instance on (3).

You can configure Kerberos constrained delegation either before or after installation. Without it, you will see Login failed for user NT AUTHORITY\ANONYMOUS LOGON  error messages in the Content Distribution log (located in C:\ProgramData\1E\ContentDistribution).

For more information about Kerberos constrained delegation, please refer to https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj553400(v=ws.11).

The table below shows the account names used in the following examples, for a web server and two SQL Servers in the ACME.LOCAL domain. Kerberos delagation is supported across trusted domains.

ServerServer roleSQL service accountComputer accountSQL port
1Tachyon Platform, Content Distribution app
ACME\TCN01
2Content Distribution database instanceACME\svc_SQL01 or systemACME\SQL011433
3Configuration Manager database instanceACME\svc_SQL02 or systemACME\SQL021433
The SQL service account is either a domain user account or a system account. A system account appears for example as NT Service\MSSQLSERVER, which is also known as a virtual account, and is the computer account in Active Directory.

  1. Ensure both SQL Server database instances (Content Distribution and Configuration Manager database) each use Kerberos authentication.

    Run this SQL query on each SQL Server instance to verify the authentication method:

    select auth_scheme from sys.dm_exec_connections where session_id=@@spid

    This query must be run remotely from the other SQL Server – connect to Content Distribution's SQL Server instance from the remote Configuration Manager SQL Server instance (and vice versa). If you run it against the local SQL Server, it will always return NTLM.

    It returns KERBEROS if the service is already configured correctly. If it returns NTLM, the Service Principal Names (SPN) for the SQL Server service are not configured correctly for Kerberos authentication, and you must create or fix the SPN.

    Below are rudimentary steps for creating SPN. A useful starting point for troubleshooting SPN, with links to other articles, is https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx.

  2. Ensure both SQL Server database instances (Content Distribution and Configuration Manager database) each have registered both their Service Principle Names (SPN).

    Whenever the SQL Server instance service starts, it will attempt to self-register the correct SPN, and will succeed if the SQL service account has permissions in Active Directory. A computer account normally has the necessary permissions to self-register, but a domain user account does not. You must manually create the SPN if self-registration fails.

    To check the correct SPN exist, you can use the setspn -L command described further below. Alternatively, review the SQL Server logs, which are found under the Management node in the SQL Server database instance.

    A self-registration failure is logged as follows:

    The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/<FQDN>:<port> ] for the SQL Server service. Windows return code: 0x200b, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
    

    A self-registration success is logged as follows:

    The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/<FQDN>:<port> ] for the SQL Server service.

    Where <FQDN> is the FQDN of the SQL Server, <instancename> is the name of the SQL Server named instance (blank if using the default instance), and <port> is the port used by the SQL Server database instance.

    There should be two SPN messages logged, one with the port, one without.

    If you are using SQL Server Availability Groups, then each group will have two SPN.

  3. Determine the SQL service account name for each SQL Server database instance (Content Distribution and Configuration Manager database).


  4. If any SPN is missing, then create it for the relevant SQL service account. You will require admin rights in Active Directory.

    You can either configure permissions for the SQL service account to self-register its SPN (please refer to Microsoft documentation for this), or manually create the SPN using the following setspn commands.

    setspn -S MSSQLSvc/<FQDN>:<instancename> <domain\SQL service account>
    setspn -S MSSQLSvc/<FQDN>:<port> <domain\SQL service account>

    Where <FQDN> is the FQDN of the SQL Server, <instancename> is the name of the SQL Server named instance (blank if using the default instance), and <port> is the port used by the SQL Server database instance.

    For example, to register the default instance for one of our example SQL service accounts:

    setspn -S MSSQLSvc/SQL01.ACME.LOCAL ACME\svc_SQL01
    setspn -S MSSQLSvc/SQL01.ACME.LOCAL:1433 ACME\svc_SQL01

    Verify the SPN have been created correctly:

    setspn -L <domain\SQL service account>

    For example, to list the SPN for both of our SQL service accounts:

    setspn -L ACME\svc_SQL01

    In the above example commands, if a SQL service account is a system account instead of a domain user account, the computer account would be specified as ACME\SQL01 or ACME\SQL02.

    Setspn -S is preferable to using -A because it will verify there are no duplicate SPN. You can find duplicates using -X and delete them using -D.

  5. Before continuing, you must complete the above steps for both SQL Server instances - Content Distribution database and Configuration Manager database.

  6. Configure the SQL service account used by Content Distribution's SQL Server instance to be trusted by Configuration Manager's SQL Server services.

    You can use PowerShell commands if you have RSAT modules installed. Use the following examples or combinations depending on whether SQL service accounts are user or system accounts.

    PowerShell commands if SQL services are using domain users accounts
    Import-Module ActiveDirectory
    $svcSqlCD = Get-ADUser -Identity svcSQL01
    $svcSqlCM = 'svcSQL02'
    Set-ADUser -Identity $svcSqlCM PrincipalsAllowedToDelegateToAccount $svcSqlCD
    Get-ADUser -Identity $svcSqlCM -Properties PrincipalsAllowedToDelegateToAccount
    PowerShell commands if SQL services are using system accounts
    Import-Module ActiveDirectory
    $svcSqlCD = Get-ADComputer -Identity SQL01
    $svcSqlCM = 'SQL02'
    Set-ADComputer -Identity $svcSqlCM PrincipalsAllowedToDelegateToAccount $svcSqlCD
    Get-ADComputer -Identity $svcSqlCM -Properties PrincipalsAllowedToDelegateToAccount

    Alternatively, you can use the interactive steps below.

    1. Open Active Directory Users and Computers
    2. Select View and ensure Advanced Features is enabled.

    1. Locate the SQL service account for the Content Distribution SQL Server instance, and view Properties

      If the service is using a system account, locate the computer account for the SQL Server, and open the Computer Properties dialog.

      If the service is using a domain user account, locate the domain user account and open the User Account Properties dialog.

      The number of tabs available is different for computer or user accounts. The example shown here is a computer account.

    2. Click the Delegation tab – this tab is not available unless the account is associated with at least one SPN.

      1. Select Trust this computer/user for delegation to specified services only
      2. Select Use Kerberos only
      3. Click Add...

    1. On the Add Services dialog, click Users or Computers...

    1. On the Select Users or Computers dialog, enter the SQL service account for the Configuration Manager SQL Server instance.

      Ensure you are specifying the correct account.

    2. Click Check Names and then click OK.

    1. The Add Services dialog displays all of the SPN registered for the SQL service account of the Configuration Manager SQL Server instance.

      1. Highlight both of the MSSQLSvc services.
      2. Click OK to save and close the Add Services dialog.
      3. Ensure both the MSSQLSvc services you selected are listed.
      4. Click OK to save and close the Properties dialog.

  1. Verify the Content Distribution web application pool account can be delegated.

    This step is required after installation of the Tachyon Platform, only if the Content Distribution web application pool has been reconfigured to use a domain user account. By default, it uses Network Service which is a domain computer account.
    1. Open Active Directory Users and Computers and locate the domain user account used by the web application pool (this is not required for a domain computer account).
    2. Open the Properties dialog for the domain user account.
    3. Under Account options, ensure that check box for Account is sensitive and cannot be delegated is not checked.

    4. Click OK.
    5. Close Active Directory and Users.

  1. Verify Content Distribution is able to synchronize with Configuration Manager.

    Perform these steps after you have configured Kerberos delegation and installed Nomad as part of Tachyon Platform. 
    1. Review the Content Distribution log located in C:\ProgramData\1E\ContentDistribution
    2. Confirm you do not see  Login failed for user NT AUTHORITY\ANONYMOUS LOGON error messages
    3. Confirm the Content Distribution synchronization process starts and completes successfully.


Tachyon client devices preparation

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

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

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

Tachyon client certificate requirements

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

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

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

In organizations that have an established PKI, the Tachyon client 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 1E Client installation folder structure, as described below in Configuring the Non-Windows Tachyon certificate using OpenSSL.

Certificate Authority (CA) public keys

Tachyon clients need to authenticate Switches and Switches need to authenticate Tachyon clients.  In each case, one end of a secure connection requires the public key for each CA in the other end's certificate certification path (trust chain).

The Tachyon client needs the public key of each CA in the Switch's certification path. These public keys are stored differently on the Tachyon client 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 1E Client installation folder.
  • For macOS devices, you have a choice of storing CA public keys in the macOS KeyStore or using the cacert.pem file approach required by other non-Windows devices.

The following points should be noted for Windows devices:

  • If each Tachyon client 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 Tachyon client device has a different certification path then the certificates (public keys) of the different CAs will need to be added to the corresponding certificate store on Windows devices, either Trusted Root Certification Authorities or Intermediate Certification Authorities.
  • In each of the above cases, the CA certificates (public keys) may have been deployed by Group Policy.

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

  • The appropriate Certification Authorities store will need to be updated on the Tachyon Server and Windows devices. Most organizations have automated processes for this task.
  • An updated cacert.pem file must be distributed to non-Windows devices. 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 (which is the same for Windows computers), then exporting it and using OpenSSL to prepare it before installing it on the non-Windows 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>.pfx -out certificate.crt
  2. Second, the CA key: 

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

    openssl pkcs12 -nocerts -in <YourPKCSFile>.pfx -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

Now you have a new PKCS12 key file without passphrase on the private key part. This Tachyon.pfx file and the cacert.pem file, must be placed in one of the following locations - depending on the OS. These are hidden folders.


On Linux and Solaris:

/etc/1E/Client/.sslcerts

On Mac:

/Library/Application Support/1E/Client/.sslcerts

Configuring the Tachyon certificate for macOS

The 1E Client for macOS devices supports the Configuring the Non-Windows Tachyon certificate using OpenSSL approach described above. Alternatively, the 1E Client for macOS also supports certificates stored within the macOS Key Store.


1E Catalog

Tachyon Setup will install 1E Catalog on the Tachyon server and ensure the server meets the requirements for installation.

Ensure the following URL is whitelisted:

  • https://catalog.1e.com

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

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