A summary of Design Considerations and Requirements for Tachyon 5.0 and 1E Client 5.0. It is comprehensive but may not contain everything that is in those pages.

This document describes requirements for an on‑premises installation of Tachyon 5.0.

Tachyon version 5.0
Document Version 1.0

Design Considerations

You need to decide which architecture your Tachyon system will use, and which configuration options. You can install Tachyon on physical or virtual servers, on-premises or in the AWS or Azure cloud. This document covers on-premises.

Architecture

The pictures opposite and below show the most common architectural implementations of Tachyon that are supported by Tachyon Setup. Organizations with less than 50000 devices will typically have a single-server system with one Switch, but there may be reasons why a more complex configuration would be required. Key factors are the location of servers and how devices and users will connect to them.

Every Tachyon system has a single Master Stack, which provides web services for Tachyon applications.

Tachyon Real-time features requires Response Stacks, and optional DMZ Servers. Each Response Stack has a Tachyon Core component that supports an associated set of up to five Tachyon Switches, which is the primary mechanism for rapidly requesting and retrieving responses from the Tachyon clients. As each Switch can handle up to 50,000 devices there is a limit of 250,000 devices per Response Stack.

The Tachyon Switches may be local or remote to the other components in the Response Stack. Tachyon, Catalog, SLA and BI databases are installed on SQL Server database instance(s) that may also be local or remote to their respective Master or Response Stacks. It is also possible for multiple Response Stacks to share the same Responses database. The Experience and BI cubes are installed on a local or remote SQL Server Analysis Services (SSAS) instance.

The pictures of the single-server and internet-facing configurations each show a system with a single Response Stack. The internet-facing system is special because the components of its Response Stack are split over two servers. Splitting a stack across multiple servers is not usually necessary except in special circumstances, for example the Switch and Background Channel on a DMZ Server is remote from its Core. The DMZ picture shows a dual firewall design, but single firewall is also supported.

The databases for Tachyon Master and Response Stacks can exist on local or remote installations of SQL Server. Local is the simplest implementation. A local Responses database offers the best performance, whereas a remote Responses database requires an additional network interface and network routing explained in Network interfaces below.

Tachyon can be installed on-premises on physical and virtual servers, and also on AWS and Azure cloud servers.

Tachyon Setup configuration choices

Tachyon Setup is a configuration wizard which must be run on each server in your architecture, to install the required components. Tachyon Setup supports the following types of installation:

  • All components on a single server - a single-server installation comprises Master Stack and Response Stack, which is the most common choice for a system of any size supporting Tachyon Real-time features.
  • Master Stack - you would install a Master Stack on its own if you do not require Tachyon Real-time features, or you want one or more remote Response Stacks.
  • Response Stack - this choice allows you to install a Response Stack after you have completed a single-server installation or installed a Master Stack, and is required to support Tachyon Real-time features.
  • DMZ Server - this choice is used on when installing a DMZ Server to provide Tachyon Real-time features for Internet-facing clients. For design and configuration steps, please refer to the Implementing a Tachyon DMZ Server page.

The number of devices you need to support influences the number of Switches and Response Stacks you will need, and their server specifications. Each Switch can handle up to 50000 devices, and you can have up to five Switches on a single Response Stack server, handling a maximum of 250000 devices. 

For guidance on server sizing of on-premises and cloud based servers, supported server platforms, and software requirements, please refer to the Requirements page. 

Multiple Response Stacks provide a degree of high availability but are not intended for that purpose. Instead, Response Stacks are required for security, geographic or other network reasons. For example, because your organization covers multiple geographies and you do not want Tachyon client traffic to go beyond the boundaries of each region, or because you have Internet-facing devices and need a Tachyon DMZ Server.

For an explanation of Tachyon components, please refer to Tachyon Architecture: Tachyon components.

There is also a custom installation option. Please contact 1E if you need a different setup to the ones described above.

Please contact 1E if you need use high availability solutions, including SQL Cluster or SQL Always On.

Tachyon Setup supports installation of 1E Catalog on the Tachyon Master Stack server. For customers that want to continue using an existing installation of 1E Catalog 2.0 then Tachyon Setup supports using a remote Catalog server as a custom setup option. Please contact 1E for details of how to use custom setup options.

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

Applications and Tools

Tachyon applications and tools are consumers, and all consumers connect to the Tachyon Consumer API. 

Tachyon Applications

The following are applications that work with Tachyon 5.0 and are installed using Tachyon Setup:

  • Explorer - used to investigate, remediate issues and manage operations across all your endpoints in real-time
  • Guaranteed State - ensures endpoint compliance to enterprise IT policies
  • Inventory - used to view and export inventory, and manage associations (new in 5.0)
  • Settings - used to configure Tachyon system and application settings
  • Experience 1.0 - a separately licensed application that measures performance, stability and responsiveness for applications and devices to assess user experience across your enterprise
  • Patch Success 1.2 - reports on and ensures successful patching of your enterprise

A typical Tachyon license will include all these applications except for Experience, which must be licensed separately.

All the above require 1E Client to be deployed to all in-scope devices, with Tachyon features enabled.

Patch Success requires SLA Business Intelligence to be installed, as described in Business Intelligence above. It also needs to get meta-data for patches from whichever of the following that you use to approve patches:

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

The following applications can be installed on the Tachyon platform. These applications have their own installers and are not installed using Tachyon Setup. You will need to ask for the application to be added to your license.

  • AppClarity 7.0 - used to manage software license compliance, License Demand Calculations, license entitlements, and for reclaiming unused software
  • Application Migration 3.0 - used to intelligently automate the migration of applications during a Configuration Manager OS deployment

The AI Powered Auto-curation feature provides automatic curation of new products which avoids having to manually add products or waiting for 1E Catalog to be updated. This optional feature requires additional memory on the Tachyon Server (Master Stack). Please refer to AI Powered Auto-curation: Internal memory requirements for SLA for details.

1E Catalog is used by the following Tachyon applications, and can therefore use AI Powered Auto-curation:

Tachyon Tools

The following are tools included in Tachyon 5.0. These tools are not installed using Tachyon Setup. They have either their own installers or are included in download zips.

  • Tachyon Configuration Manager UI extensions  - installed as part of the Tachyon Toolkit, this is a right-click extension for the Microsoft System Center Configuration Manager console that provides a graphical user interface for the user to browse and run an instruction on devices in a specified Collection
  • Tachyon Run Instruction command-line tool - installed as part of the Tachyon Toolkit, it is used for sending instructions to the Tachyon server from a script or from a command prompt
  • Tachyon Product Pack Deployment Tool  - included in the Tachyon Platform zip ProductPacks folder
  • Tachyon Instruction Management Studio (TIMS)  - used for development of Tachyon instructions using the Tachyon SDK.

A typical Tachyon license allows use of all these tools.

License requirements for consumer applications

For any application, tool or feature to use instructions, its consumer and prefix pattern must be registered in your license. The table below shows the consumers and prefix patterns that are typically included in a Tachyon license. The table also includes other applications where instructions - and therefore licensing - is not applicable. Tachyon expects to find the license file in: %PROGRAMDATA%\1E\Licensing on your Tachyon (Master Stack) Server.

Application or FeatureConsumer namePrefix patternsWhere to obtain the Product PackNotes
ExplorerExplorer

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

Included in the Tachyon license are:

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

Explorer application provides functionality to run, approve and schedule instructions, view Tachyon managed devices. Used to investigate, remediate issues and manage operations across all your endpoints in real-time.

If you want to use instructions developed by third parties, your own developers, or 1E developers on your behalf, then you must ask 1E to register the third party and customer prefixes in your license. Please refer to Developing your own instructions.

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

Guaranteed StateGuaranteedState
  • 1E-Explorer-*

(only required for instructions included in the Integrated Product Packs - this pattern is not required to use Guaranteed State)

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

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

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

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

SettingsPlatformN/AN/AThe Settings application is used to administer Tachyon. For example, permissions management, instruction set management, connector management, repository management, sync scheduling etc.
ExperienceExperienceN/AN/A

The Experience application allows you to measure performance, stability and responsiveness for applications and devices to assess user experience across your enterprise.

Experience derives a score based on 44 metrics across three categories:

  • Stability
  • Responsiveness
  • Performance.

AppClarity AppClarityN/AN/A

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

The main benefits of using AppClarity are:

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

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

Application MigrationApplicationMigrationN/AN/A

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

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

Patch Success

PatchSuccess
  • 1E-PatchSuccess-*

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

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

Tachyon Configuration Manager UI extensions

CmConsoleExtensions

RunInstructionUI

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

Tachyon Run Instruction (command-line tool)

TachyonRunInstruction

Unable to render {multiexcerpt-include} A multiexcerpt-include cannot reference a multiexcerpt which embeds it. Page:Design Considerations


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

Unable to render {multiexcerpt-include} A multiexcerpt-include cannot reference a multiexcerpt which embeds it. Page:Design Considerations

N/A

1E ITSM Connect (with 1E Core) allows ServiceNow users to use any instruction that is permissioned for the 1E ITSM Connect app user role.

Nomad Download PauseNomad
  • 1E-Nomad-*
  • Nomad zip available on the Support Portal contains:
    • NomadBranchAdminUIExt.msi installer. If the installer account has relevant permissions in Tachyon the 1E-Nomad Product Pack is automatically uploaded to provide two Tachyon instructions for the Nomad Download Pause feature

The NomadBranchAdminUIExt.msi installer also automatically registers the Nomad consumer, and creates the Nomad Core Instructions instruction set, if the installer account has relevant permissions.

Nomad Download Pause feature requires an installation of ActiveEfficiency Server.

Additional consumers and tools can be developed by third parties, your developers, or 1E developers on your behalf. 1E must register their consumer names in the Tachyon license.

Infrastructure dependencies

PKI and certificates

Client-Switch communication uses WebSocket Secure protocol, whereby each Tachyon client establishes a secure link to the Switch which is then used by the Switch to send instructions to the Tachyon client. This is shown as a dotted line in the pictures in the Communication Ports page.

All other communications from external devices use HTTPS, including Tachyon client connecting to the Background Channel in order to download resources that may be required by instructions, and using the Tachyon Portal to administer and use the system.

All communication is encrypted, which requires a Public Key Infrastructure (PKI). More specifically, PKI is required for:

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

Miscellaneous

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

  • DNS - each Tachyon Server requires a DNS Name, this is also useful for ActiveEfficiency Server if it is installed
  • Active Directory - for installation and user accounts; Tachyon can be configured to use LDAP but uses GC by default
  • IIS - a standard configuration required on each Tachyon Server
  • SQL Server - for Tachyon Master and Response Stack databases, Catalog SLA and BI databases, and ActiveEfficiency if installed
  • SQL Analysis Services - must be installed in multi-dimensional mode, for Business Intelligence (SLA BI cube) required by Patch Success
  • Email - optional for approval and notification emails, but required if using two-factor authentication (2FA)
  • Internet access - the Master Stack requires access to the 1E license service via the Internet in order to keep the Tachyon license activated, and 1E Catalog requires access to the 1E Catalog Cloud service to download Catalog updates

Email and two-factor authentication

You will need to decide if you want to use the Email and two-factor authentication features.

If the 2FA feature is enabled, Tachyon users are prompted to enter a one-time authentication code in addition to their password in order to confirm they want to submit an action instruction. 

The one-time authentication code is sent to the user by email. The two-factor authentication feature requires email.

Please refer to Tachyon Server post-installation tasks: Enabling or disabling Two-factor Authentication.

SQL Server

You will need to decide if Tachyon databases are installed locally or on remote SQL Server instance(s).

Databases that are remote from their Tachyon Servers increase the complexity of design and installation in the following ways:

  • Tachyon Server installation depends on the server installation account having appropriate rights on the SQL Server instance. Remote SQL Servers are typically run on farms managed by other teams who may not want to grant permissions to your installation account.
  • If a Response Stack serves over 500 devices then you will require an additional network interface, which requires network routing as described in Network interfaces below.

You will need to regularly backup the Tachyon Master database. The Tachyon Server can be re-installed from scratch using the existing database or a restored backup.

There is no requirement to backup the Tachyon Responses database because it only contains transient data. You can backup and restore the Responses database if that is your organization's preference for recovery.

Microsoft SQL Server Express is not supported for either Master or Responses databases, due to its limitations.

For details about configuration and sizing of Tachyon databases please refer to Requirements: SQL Server requirements.

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

Active Directory

Tachyon Servers must be domain-joined.

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

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

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

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

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

AD distribution groups are not supported.

Please contact 1E if you require a DMZ Server that is not domain-joined.

Networking and DNS requirements

Network interfaces

A server that hosts Response Stack components requires additional network interfaces depending on the number of client devices it needs to support:

  • Each Switch requires its own network interface for incoming Response traffic. These interfaces can be shared with a Background Channel. Each interface can have its own DNS Name or share the same DNS Name as explained in DNS Names below.
  • If the Tachyon Responses database is not local, and the server supports more than 500 devices, then for performance reasons you should have an additional network interface for outgoing SQL traffic to keep it apart from incoming Switch traffic.
  • If the server hosting the Tachyon Master Stack is also required to host a non-Tachyon client-facing service such as ActiveEfficiency Server for Nomad, or Application Migration, and the number of clients is more than 5,000 then for performance reasons you should do one of the following:
    • install the Tachyon Response Stack on a dedicated server, which should have an additional network interface for connection with the Master Stack, but this is not mandatory. If an additional network interface is used then it requires its own DNS Name and a website binding manually added after installation. The additional DNS Name should be included in the server's web certificate, or a separate web certificate can be used.
    • install the Tachyon Response Stack on the same server as the Master Stack and use an additional network interface for non-Tachyon client traffic and give it its own DNS Name and a website binding manually added after installation. If an HTTPS binding is required, then this additional DNS Name should be included in the server's web certificate, or a separate web certificate can be used.

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

Number and speed of server network interfaces

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

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.

Response Stack serving 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.

ActiveEfficiency Server and Response Stack installed on the same server and more than 50000 devices

Tachyon Setup can install ActiveEfficiency Server. However, systems that support over 50000 clients require separation of Tachyon and Nomad client traffic to ensure optimum performance. Therefore, you must choose one of the following installation options for ActiveEfficiency Server:

  • Tachyon Master Stack and Response Stack on one server, and ActiveEfficiency Server on a remote server
  • Tachyon Master Stack including ActiveEfficiency Server on one server, and the Tachyon Response Stack installed on a remote server
  • A single-server with Tachyon Master Stack and ActiveEfficiency Server using one network interface, and the Tachyon Response Stack using its own network interface(s). This effectively separates traffic for Master and Response Stacks. Each Stack has its own DNS Name, which also makes it easier to relocate the Response Stack if required, or add further Response Stacks using the same DNS Name

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 be on a different subnet to the external interface(s) with no routing between them.

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

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

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

Network impact

Most of the network traffic experienced by a Tachyon system is compressed responses from Tachyon clients to Switches. Responses to Tachyon instructions are returned by online Tachyon clients in a matter of a few seconds. Tachyon is designed for speed without impacting your network.

The Response Stack's Core then processes and stores uncompressed responses in the Tachyon Responses database. If the database is remote then this will create significant network traffic when saving responses, but normally this will be within a datacenter. Even so, a dedicated interface is recommended on each Response Stack for connection to a remote SQL Server in order to prevent network contention between incoming and outgoing response traffic.

Other network traffic generated by Tachyon is low by comparison. Tachyon Explorer is a single page application which uses paging to view responses.

Tachyon clients also download content from a Background Channel, which is a website hosted on the same server as Switches. They deliberately stagger the delay of their download for up to 5 minutes (configurable). By using 1E Nomad you can avoid the staggered delay on Windows PCs without impacting your network. For further information about 1E Nomad please refer to Downloading content and Nomad integration below.

WAN caching

Communications between Tachyon clients and Switches should not be cached or delayed, which can be prevented by excluding the Switch port(s) or the IP Addresses of Switch interfaces on caching devices.

Communications between Tachyon clients and the Background Channel can be cached, however, please refer to Downloading content and Nomad integration as an alternative to WAN caching.

Isolated Networks

Tachyon can operate in a multi-domain, multi-forest environment with Tachyon client devices on internal and external networks, supporting internal and external Certificate Authorities.

Each Tachyon client device must have a network connection to a Switch and Background Channel, with the necessary network firewall ports open. If Tachyon clients are unable to connect to the Tachyon Server on the corporate network, then it is necessary to install additional Tachyon Servers.

Firewall ports

For details of firewall ports and different types of network traffic, please refer to the Communication Ports page where you can find the following:

DNS Names

The correct choice of DNS Name(s) for your Tachyon Servers is perhaps the most fundamental decision you will make. 

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

Master Stack

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

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

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

  • ActiveEfficiency Server, used by Nomad clients
  • Application Migration, used by Windows Self-Service task sequences
  • AppClarity, used by AppClarity Software Reclaimer

DMZ Server

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

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

Response Stack

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

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

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

Single DNS Name

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

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

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

Multiple client-facing DNS Names

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

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

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

Only one client-facing DNS Name can be specified during installation, other HTTPS bindings are added manually after installation. If Master and Response Stack are on the same server and you want them to have different DNS Names, then specify the DNS Name for the Response Stack during installation, and manually add the HTTPS binding for the Response Stack after installation. You will need to seek guidance from 1E on how to configure Switches to use the second DNS Name. A simpler option is to put the Response Stack on its own server. Remote Response Stacks are recommended if the Master Stack is also hosting services for ActiveEfficiency Server, AppClarity Software Reclaimer or Application Migration.

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

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

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

Internal DNS Names

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

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

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

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

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

Tachyon Setup supports installation of one HTTP and one HTTPS binding, but you can manually add more bindings after installation. HTTPS bindings can share a web server certificate provided it includes all DNS Names, or each HTTPS binding can have its own certificate.

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

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

A DNS Name can be a DNS alias, CNAME or Host (A) record.

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

SPNs are only required for web applications that use Windows Authentication, and are created using:

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

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

Downloading content and Nomad integration

Tachyon client downloads content from the Tachyon Background Channel. Content is mainly scripts and other files required by Tachyon instructions. It also includes client resources such as extensible modules, providers, and other dependencies to maintain the 1E Client. In most cases, client resources are version controlled to prevent repeated downloads. Tachyon instructions always request a download even if they have run an instruction before, unless the content for that instruction has been cached in memory.

You may need to consider the impact on the network if there is a large amount of content included in an instruction. This is more of an operational consideration instead of a design consideration.

1E Nomad is an optionally licensed component of the 1E Client. It makes software deployment, patching and downloading content more efficient and reduces the impact on the network. It removes the need for remote Distribution Point servers in Microsoft System Center Configuration Manager systems. When Nomad is installed on computers it automatically elects a peer to download content from a server over the WAN and then peer-shares the content with other PCs at the same location. The downloaded content is cached locally on each PC in case it is needed again.

Tachyon can optionally use Nomad to download content from servers irrespective of whether Nomad is integrated with Configuration Manager or not, and also uses advanced Nomad features which use ActiveEfficiency.

Nomad integration disabled

If Nomad integration is not used, then 

  • Tachyon client waits a randomized stagger period defined by its DefaultStaggerRangeSeconds setting, and then downloads content from the specified Background Channel.
  • Tachyon client retains modules and extensibles that it has downloaded, but does not retain instruction scripts after they have been run. Any instruction that requires a script or other file will download the latest version each time the instruction is run.

Nomad integration enabled

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

With the Nomad integration feature enabled, Tachyon client will detect if Nomad v6.0.100 or later version is running on the device.

  • Tachyon client immediately requests Nomad to download content from the specified HTTP source such as the Background Channel. Nomad behaves in the same way as it does with Configuration Manager by ensuring the latest version of content is obtained and electing a master to perform the actual download.
  • Nomad maintains its own cache of downloaded content which avoids the need for repeat downloads over the WAN, and provides content to peers that require the same resources which avoids peer devices having to download over the WAN.

  • If the Nomad integration feature is enabled, and requested content is not provided within the timeout period, the Tachyon client will fall back to downloading directly from the HTTP source. The most likely reason for a timeout is if Nomad is busy downloading other content.

To use Nomad, there is no special configuration of Tachyon Servers. The Background Channel is a web application on the Tachyon Server which uses HTTPS and default port is 443. The URL for the Background Channel is defined in the 1E Client configuration file and is specified during installation of the 1E Client if Tachyon features are enabled. The Tachyon client passes this URL to Nomad when it requests content to be downloaded. Instructions can also specify other HTTP sources.

Nomad does not need to be configured to use certificates in order to communicate with the Background Channel (the Nomad CertIssuer and CertSubject settings are used only with Configuration Manager Distribution Points that are configured to validate device certificates).

1E Client deployment

You will need to plan the deployment of 1E Client using whichever software deployment tools you have. 1E Client includes clients for Tachyon, Nomad, Shopping and WakeUp. For details of interactive and command-line installation, please refer to Deploying Tachyon clients.

Tachyon clients require client certificates. For more detail, please refer to Requirements: Tachyon client certificates.

Below are lists of supported OS Platforms, but please also refer to Constraints of Legacy OS

Supported Platforms

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

Windows

  • Windows Server 2019
  • Windows Server 2016
  • Windows 10 CB 2004
  • Windows 10 CB 1909
  • Windows 10 CB 1903
  • Windows 10 CB 1809
  • Windows 10 CB 1803
  • Windows 10 CB 1709
  • Windows 8.1

Professional and Enterprise editions of Windows 10 are supported.

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

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

This list is automatically updated to show only those OS versions in mainstream support by Microsoft, and therefore supported by 1E, and by 1E Client 5.0. However the following OS continue to be supported as exceptions to help customers during their migration to the latest OS:

  • Windows Server 2012 R2
  • Windows 7 SP1

Please refer to Constraints of Legacy OS regarding end of mainstream support.

For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search.

Please refer to https://1eportal.force.com/s/support-for-msft-rapid-release-cycle for details of which Current Branch versions are supported by 1E products, and known issues regarding specific versions.

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

macOS

  • MacOS Catalina 10.15.1
  • macOS Mojave 10.14
  • macOS High Sierra 10.13

Linux

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

Solaris

  • Solaris 11.3

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

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

The 1E Client for non-Windows zip is available for download from the 1E Support Portal, and includes 1E Client packages for the following architectures:

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

Also included in the download are 1E Client packages for the following legacy Linux distributions:

  • Fedora 21
  • openSUSE Leap 42.1

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

The Tachyon client features of 1E Client are supported on the following mobile OS:

Android

  • Android Pie 9.0
  • Android Oreo 8.1
  • Android Oreo 8.0

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

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

The 1E Client for Android zip is available for download from the 1E Support Portal, and includes 1E Client packages for the following architectures:

  • Android ARM

Developing your own instructions

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

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

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

The Tachyon SDK is where you can find comprehensive resources for developing your instructions.

You can also download product packs containing more instructions from the Tachyon Exchange, and ask questions in Tachyon Forum.

Requirements

Server requirements

Server sizing for on-premises

The tables below are minimum specifications for on-premises installations. Tachyon is recommended to be installed on a dedicated server, and can be installed on physical or virtual hardware. 

A Tachyon system comprises a single Master Stack and one or more Response Stacks. The tables and diagrams show details for a single server which combines Tachyon Master and Response Stacks with either local or remote SQL Servers. Use the same specifications for separated Master and Response Stack servers.

Each Response Stack can have up to five Tachyon Switches and one Background Channel. Each Switch can support up to 50,000 devices therefore a single server with 5 Switches and one Background Channel can support up to 250,000 devices.

Best performance is achieved using a local SQL Server installation but you can install Tachyon and SQL Server on separate (split) servers. A separate SQL Server is required if it is to be shared with other customer applications, and its CPU and RAM should be increased accordingly. Please refer to SQL Server requirements for other detailed requirements.

For medium and large configurations, separate disk volumes are required for SQL databases, logs, and tempDB. When Tachyon and SQL Server are installed on the same server, then the SQL Server setting maximum server memory must be set to match the value in the table.

The tables below include ActiveEfficiency Server to support Nomad features only. ActiveEfficiency can be installed on the Tachyon server for small systems. Medium and large systems (over 50000) require separation of incoming network traffic from Nomad and Tachyon clients. Therefore, either ActiveEfficiency or the Response Stack is installed on a separate server, or if both are installed on the same server there are additional networking and DNS requirements, as described in Design Considerations: ActiveEfficiency Server.

For guidance on installing ActiveEfficiency on a separate web server, please refer to ActiveEfficiency Server 1.10 - Implementation.

Additional hardware is required when using ActiveEfficiency Server to support AppClarity 5.2 or Shopping, which require an ActiveEfficiency Scout, please refer to:

AppClarity 5.2 and Shopping 5.6 use ActiveEfficiency Scout to get data from Configuration Manager. This version of ActiveEfficiency does not get data via Tachyon or SLA.

CPU cores listed in the tables below are logical cores (physical or virtual). For deployment on a virtual machine, the CPU cores should be assigned at 100% virtual machine reserve.

Local SQL configuration


Small 1Small 2
Maximum number of devices5005,000

Tachyon Server and SQL Server

CPU cores212
RAM10 GB32 GB
SQL Instance Max Memory2 GB10 GB
Number of Tachyon Switches11
Network interfaces (Tachyon)11
Disk space required for databases1 GB60 GB
Logs
30 GB
TempDB
20 GB
ActiveEfficiency Server (Nomad) - see note above
CPU Coresincluded aboveincluded above
RAM
Network interfaces (ActiveEfficiency)

Remote SQL configuration


Medium 1Medium 2Large 1Large 2Large 3
Maximum number of devices25,00050,000100,000200,000500,000
Tachyon Server
CPU Cores812162448
RAM24 GB36 GB48 GB56 GB128 GB
Number of Tachyon Switches112410
Network interfaces (incoming to Switches plus outgoing to SQL Server)223511
Remote SQL Server
CPU Cores68121632
RAM16 GB24 GB32 GB48 GB96 GB
Disk space required for Database200 GB400 GB800 GB1,600 GB4,000 GB
Logs100 GB200 GB300 GB600 GB1,400 GB
TempDB100 GB150 GB200 GB400 GB800 GB
ActiveEfficiency Server (Nomad) - see note above
CPU Coresincluded aboveincluded aboveincluded aboveincluded above
please refer to Nomad,

RAM
Network interfaces (incoming to ActiveEfficiency)

A server hosting a Tachyon Response Stack requires a dedicated network interface (MAC Address and IP Address) for each Switch, and for the connection to the remote SQL Server instance used for the Responses database to keep incoming traffic from clients separate from the outgoing traffic to the Response database. This dedicated SQL connection must be at least 1Gbps for environments (up to 50,000) and at least 10Gbps for environments (over 50,000). For more detail please refer to Design Considerations: Network interfaces.

For larger or more complex configurations please contact 1E.

Server software

CategoryProductNotes

Server OS

  • Windows Server 2019
  • Windows Server 2016

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

Only 64-bit server OS are supported. The server must be domain-joined.

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

This list is automatically updated to show only those OS versions in mainstream support by Microsoft, and therefore supported by 1E. However, the following OS continue to be supported as exceptions to help customers with their migration to the latest OS:

  • Windows Server 2012 R2.

Please refer to Constraints of Legacy OS regarding end of mainstream support.

For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search.

Please refer to https://1eportal.force.com/s/support-for-msft-rapid-release-cycle for details of which Current Branch versions are supported by 1E products, and known issues regarding specific versions.


SQL Server

  • SQL Server 2019
  • SQL Server 2017
  • SQL Server 2016 SP2

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

Standard and Enterprise editions of these SQL Server versions are supported.

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

If you intend to integrate with third-party business intelligence products such as Power BI, you must install the Enterprise edition of SQL Server Analysis Services (SSAS) as per their requirements.

A SQL Server database instance is required for the following databases:

  • 1ECatalog
  • ActiveEfficiency (optional)
  • SLA-BI (only required for Patch Success)
  • SLA-Data
  • SLA-Integrate
  • SLA-Shared
  • TachyonExperience (only required for 1E Experience)
  • TachyonMaster
  • TachyonResponses

SLA databases

Tachyon Setup can install the above databases on separate SQL Server instances, however SLA-Data, SLA-Integrate, and SLA-Shared must exist on the same instance.

A SQL Server Analysis Services (SSAS) instance installed in Multidimensional mode is required for SLA Business Intelligence and 1E Experience.

SLA Business Intelligence

SLA Business Intelligence (BI) is required for the Patch Success application.

The BI installer creates the following:

  • A BI database called SLA-BI on the SQL Server database instance.
  • A BI cube called SLA-BI on the SSAS instance. This is a MOLAP cube.
  • A linked server for the SLA Platform databases to get data from the BI database and then from the BI cube.
  • A linked server for the BI database to get data from the SLA Platform databases.
  • A datasource definition used by the BI cube to connect to the BI database.

If the SLA databases, BI database, or SSAS instance for BI, are on different SQL Servers then the BI installer enforces the use of a SQL login on each instance. If they are on the same SQL Server then the installer gives you a choice of using integrated security (domain user account) or a SQL login.

However, if you are installing all the components from Tachyon Setup instead of their individual installers, then you are not given the choice. Tachyon Setup always uses integrated security. Contact 1E for support if your scenario requires the above mentioned databases to be on different SQL Servers. This affect different servers, not different instances.

1E Experience

1E Experience creates the following:

  • TachyonExperience database on the SQL Server database instance
  • TachyonExperience cube on the SQL Server Analysis Server instance

All SQL Server instances must be configured with the following:

  • A case-insensitive, accent-sensitive collation which is SQL_Latin1_General_CP1_CI_AS by default,
  • Allow remote connections to this server enabled.

All SQL Servers should be configured with the SQL Server Browser service running in order for the BI installer to select from a list of instances.

All SQL Servers must have SQL Server 2012 Native Client installed, in order to support linked server and datasource connections. This is included in the Client Tools Connectivity feature that SQL Server Setup normally installs by default. See Preparation: If TLS 1.0 is disabled.

SQL Server Management Studio is required to review the configuration and edit settings in 1E database tables.

If installing SQL Server locally, note:

  • SQL Server 2016 and 2017 require .NET Framework 4.6 which requires KB2919355 on Windows Server 2012 R2
  • SQL Server setup requires PowerShell 2.0.

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

ActiveEfficiency Server requires Distributed Transaction Coordinator (MSDTC) to be enabled and configured on each of the SQL Servers used by:

  • ActiveEfficiency database
  • Configuration Manager site database - specified in the Nomad Sync settings during installation of ActiveEfficiency. This would normally be the CAS in a multi-site hierarchy, or the Primary Site in a single-site hierarchy.

MSDTC is a feature of Windows Server and is used to track of transactional processes, usually over multiple resource managers on multiple computers. MSDTC ensures that the transactions are completed and can be rolled-back if any part of the process fails. Nomad Sync uses MSDTC to perform complex queries on Configuration Manager and ActiveEfficiency data. For example, to retrieve computers targeted with Nomad Pre-cache policies and Nomad Dashboard data.

For details of how to configure MSDTC on SQL Servers, please refer to Preparation: MSDTC for ActiveEfficiency.

Microsoft System Center Configuration Manager

Not applicable.

Tachyon Server components have no dependencies on Configuration Manager, other than the SCCM Connector as described in Connectors below.

Use the links below for other components that use Configuration Manager::

Web Server
  • IIS 10
  • IIS 8.5

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

Other Software

  • Visual C++ 2013 Redistributable
  • .NET Framework 4.8
  • .NET Framework 4.7.2
  • .NET Framework 4.7.1
  • .NET Framework 4.7
  • .NET Framework 4.6.2
  • .NET Framework 4.6.1
  • .NET Framework 4.6

See Preparation: Windows Server roles and features for details about required .NET Framework roles and features. To know supported combinations of OS and .NET Framework, please refer to: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies.

  • Windows Server 2012 R2 has .NET Framework 4.5.1 installed by default. You will need to upgrade to one of these supported versions.
  • Windows Server 2016 has .NET Framework 4.6.2 installed by default.
  • Windows Server 2019 has .NET Framework 4.7.2 installed by default.

Tachyon Server installer includes and automatically installs the redistributable package for Visual C++ 2013. The Tachyon Coordinator (licensing module on the Master Stack), and Tachyon Switch (on Response Stack) are written in C++ using Visual Studio 2013 and therefore require Visual C++ 2013 runtime (x64); other server components use .NET Framework.

SQL BCP is required by the Export All feature described in Exporting data from Tachyon Explorer, and must be installed on each Tachyon Response Stack server (specifically the servers which have the Tachyon Core installed). BCP uses ODBC, which requires Microsoft ODBC Driver versions 13.1 and 17 and Visual C++ 2017 Redistributable to be installed first. Please refer to Preparation: SQL BCP for more detail.

PowerShell is required by Tachyon installer during installation.

Browsers

Latest version of:

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

Disk space

Tachyon Server installation folder is approx. 70 MB.

Tachyon Server logs folder is approx. 210 MB. For more details about logs please refer to the Log files page.

For details of SQL database file sizes, please refer to Server requirements above.

Databases, Log and TempDB must be on separate disks for medium and large configurations.

Network interfaces

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

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.

Response Stack serving 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.

ActiveEfficiency Server and Response Stack installed on the same server and more than 50000 devices

Tachyon Setup can install ActiveEfficiency Server. However, systems that support over 50000 clients require separation of Tachyon and Nomad client traffic to ensure optimum performance. Therefore, you must choose one of the following installation options for ActiveEfficiency Server:

  • Tachyon Master Stack and Response Stack on one server, and ActiveEfficiency Server on a remote server
  • Tachyon Master Stack including ActiveEfficiency Server on one server, and the Tachyon Response Stack installed on a remote server
  • A single-server with Tachyon Master Stack and ActiveEfficiency Server using one network interface, and the Tachyon Response Stack using its own network interface(s). This effectively separates traffic for Master and Response Stacks. Each Stack has its own DNS Name, which also makes it easier to relocate the Response Stack if required, or add further Response Stacks using the same DNS Name

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 be on a different subnet to the external interface(s) with no routing between them.

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

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

The table below summarizes the network interface requirements for a Response Stack's database and Switches, where n is the number of Switches on the server up to a maximum of five. 

The ActiveEfficiency column shows the additional network interface required if the Response Stack is installed on the same server as the Master Stack, that also has ActiveEfficiency installed. The interface can be added before or after installation.

DevicesSwitchesInterfaces when SQL is localInterfaces when SQL is remoteMaster Stack with ActiveEfficiency
Up to 500111 (Switch and SQL)share the Switch network interface
Up to 5,000111 (Switch) + 1 (SQL)share the Switch network interface
Up to 50,000111 (Switch) + 1 (SQL)+ 1 interface for non-Tachyon clients
Up to 100,000222 (Switches) + 1 (SQL)+ 1 interface for non-Tachyon clients
Over 100,000n (3 or more, up to 5)nn (Switches) + 1 (SQL 10Gbps)+ 1 interface for non-Tachyon clients

Unless otherwise stated, all network interfaces must be a minimum of 1Gbps.

When a Response Stack uses an additional network interface for remote SQL, it needs a persistent route to be configured, to prevent outgoing SQL traffic using any other network interface. Please refer to Preparation: Configuring a persistent route for SQL traffic. Please ensure you also consult your server, firewall and networking teams.

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

DNS Names

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

Master Stack

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

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

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

  • ActiveEfficiency Server, used by Nomad clients
  • Application Migration, used by Windows Self-Service task sequences
  • AppClarity, used by AppClarity Software Reclaimer

DMZ Server

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

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

Response Stack

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

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

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

Single DNS Name

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

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

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

Multiple client-facing DNS Names

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

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

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

Only one client-facing DNS Name can be specified during installation, other HTTPS bindings are added manually after installation. If Master and Response Stack are on the same server and you want them to have different DNS Names, then specify the DNS Name for the Response Stack during installation, and manually add the HTTPS binding for the Response Stack after installation. You will need to seek guidance from 1E on how to configure Switches to use the second DNS Name. A simpler option is to put the Response Stack on its own server. Remote Response Stacks are recommended if the Master Stack is also hosting services for ActiveEfficiency Server, AppClarity Software Reclaimer or Application Migration.

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

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

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

Internal DNS Names

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

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

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

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

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

Tachyon Setup supports installation of one HTTP and one HTTPS binding, but you can manually add more bindings after installation. HTTPS bindings can share a web server certificate provided it includes all DNS Names, or each HTTPS binding can have its own certificate.

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

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

A DNS Name can be a DNS alias, CNAME or Host (A) record.

Service Principal Names

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

SPNs are only required for web applications that use Windows Authentication, and are created using:

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

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

Windows Server roles and features

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

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

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

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

Role or FeatureDisplay NameNameNotes
Web ServerWeb Server (IIS)Web-Server
Web Server Common HTTP FeaturesDefault DocumentWeb-Default-DocIncluded in Web-Server.
Directory BrowsingWeb-Dir-BrowsingIncluded in Web-Server.
HTTP ErrorsWeb-Http-ErrorsIncluded in Web-Server.
Static ContentWeb-Static-ContentIncluded in Web-Server.
Web Server Health and DiagnosticsHTTP LoggingWeb-Http-LoggingIncluded in Web-Server.
Web Server PerformanceStatic Content CompressionWeb-Stat-CompressionIncluded in Web-Server.
Dynamic Content CompressionWeb-Dyn-Compression
Web Server SecurityRequest FilteringWeb-FilteringIncluded in Web-Server.
Basic AuthenticationWeb-Basic-AuthOnly required if using 1E ITSM Connect .
IP Address and Domain RestrictionsWeb-IP-SecuritySee note below.
Windows AuthenticationWeb-Windows-Auth
Web Server Application Development.NET Extensibility 4.XWeb-Net-Ext45Included in Web-Asp-Net45.
ASP.NET 4.XWeb-Asp-Net45
ISAPI ExtensionsWeb-ISAPI-ExtIncluded in Web-Asp-Net45.
ISAPI FiltersWeb-ISAPI-FilterIncluded in Web-Asp-Net45.
Web Server Management ToolsIIS Management ConsoleWeb-Mgmt-Console
.NET Framework 4.X Features.NET Framework 4.XNet-Framework-45-Core
ASP.NET 4.XNet-Framework-45-ASPNET
Message QueuingMessage QueuingMSMQOnly required for ActiveEfficiency server.
The following roles, role services and features must be removed/disabled.

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

IIS Features Configuration

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

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

Basic Authentication is required on the Master Stack if 1E ITSM Connect for ServiceNow is to be used.

MSMQ

Microsoft Message Queuing (MSMQ) Windows feature must be enabled in order to install the 1E ActiveEfficiency service component. This service is required by:

  • Nomad Sync (dashboard and pre-cache features) even though it does not use MSMQ it is required for installation
  • Nomad integration with WakeUp feature, which does use MSMQ and requires MSMQ to also be enabled on the NightWatchman Management Center server

MSMQ is only required to support the above features, and is no longer required by other 1E companion products that use ActiveEfficiency Server (AppClarity 5.x and Shopping 5.x).


SQL Server requirements

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

  • SQL Server editions and configuration - see Server software section - a SQL Server database instance is required for databases, and also a SQL Server Analysis Server (SSAS) instance for the SLA-BI Cube.
  • Network interface for remote SQL Server - see Network interfaces section
  • SQL database sizing - see Server Sizing reference page


Unable to render {multiexcerpt-include} A multiexcerpt-include cannot reference a multiexcerpt which embeds it. Page:Requirements

The above information is also provided in SQL Login for the server installation account below.

Microsoft Bulk Copy Program (BCP) installed on the Response Stack server(s) where the Tachyon Core component is installed, as described in Export all feature below

MSDTC enabled and configured on the SQL database server for both ActiveEfficiency, and the Configuration Manager specified in the Nomad Sync settings during installation of ActiveEfficiency.

MSDTC

The following is relevant only if you are installing ActiveEfficiency to support Nomad Sync which is used for Nomad dashboard and pre-cache features.

ActiveEfficiency Server requires Distributed Transaction Coordinator (MSDTC) to be enabled and configured on each of the SQL Servers used by:

  • ActiveEfficiency database
  • Configuration Manager site database - specified in the Nomad Sync settings during installation of ActiveEfficiency. This would normally be the CAS in a multi-site hierarchy, or the Primary Site in a single-site hierarchy.

MSDTC is a feature of Windows Server and is used to track of transactional processes, usually over multiple resource managers on multiple computers. MSDTC ensures that the transactions are completed and can be rolled-back if any part of the process fails. Nomad Sync uses MSDTC to perform complex queries on Configuration Manager and ActiveEfficiency data. For example, to retrieve computers targeted with Nomad Pre-cache policies and Nomad Dashboard data.

Active Directory requirements

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

GC method

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

Supports only Universal security groups.

LDAP method

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

Supports Universal and Global security groups.

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

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

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

Service accounts

Tachyon Server web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE.

The BI SSAS User account has the following requirements:

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

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

SQL Login for the Network Service account

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

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

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

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

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

User accounts

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

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

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

Active Directory Security Groups

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

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

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

AD distribution groups are not supported.

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

Server installation account

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

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

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

Local admin rights

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

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

SQL Login for the server installation account

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

Master Stacks

For master stacks sysadmin is required for installation:

  • to install 1E Catalog
  • to create Linked Servers for SLA, which requires sysadmin for the database instances for both SLA and 1E Catalog
  • to create Linked Servers for BI, which requires sysadmin for the database instances for both SLA and BI, and the SSAS instance for the BI cube.

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.

Tachyon user permissions

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

License file

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

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

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

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

Whitelisting the 1E license service URL

Ensure the following URL is whitelisted:

This URL must be accessible 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.

Certificates

Public Key Infrastructure

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

Tachyon requires each Issuing CA has:

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

PKI notes

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

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

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

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

Tachyon server certificates

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 prior to installation of Tachyon on the server.

Certificate requirements for standard servers

The Web Server certificate requires the minimum of the following:

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

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

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

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

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

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

The Tachyon Server DNS Name FQDN (DNS Alias) of the server.

Example: DNS Name=TACHYON.ACME.LOCAL

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

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

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

An Alternate DNS Name FQDN (DNS Alias) of the server.

Example: DNS Name=TACHYONALT.ACME.LOCAL

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

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

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

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 hostname FQDN of the server

Example: CN=ACME-TCN01.ACME.LOCAL

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

The DNS Alias FQDN of the server

Example: DNS Name=TACHYON.ACME.LOCAL

Add any additional DNS Names here.
Example certificate request

Option 2 type certificates required the CN to be the hostname 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 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 hostname 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 hostname FQDN.

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

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

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

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

Tachyon client certificates

If you have configured Tachyon Server to require client certificates, then each device requires a certificate with the following properties, in order for the Tachyon client to be authenticated by the Tachyon Switch.

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

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

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

  • For Windows devices, the certificate is stored in the Windows Local Computer personal certificates store. 
  • For non-Windows devices, except for the Mac, the Tachyon client does not use proprietary certificate stores. Instead, the client requires the certificate to exist as a PFX in the client installation folder structure (see non-Windows Device Certificate).

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

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

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

Code signing certificates

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

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

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

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

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

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

Digital signing certificates

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

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

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

The table below applies to software and hotfixes released in 2020.


Signing certificate

Timestamping certificates

2020

1E Limited

TIMESTAMP-SHA256-2019-10-15 and DigiCert Timestamp Responder

Issuing CA

DigiCert EV Code Signing CA (SHA2)

Thumbprint: 60ee3fc53d4bdfd1697ae5beae1cab1c0f3ad4e3

DigiCert SHA2 Assured ID Timestamping CA

Thumbprint: 3ba63a6e4841355772debef9cdcf4d5af353a297

and  DigiCert Assured ID CA-1

Thumbprint: 19a09b5a36f4dd99727df783c17a51231a56c117

Root CA

DigiCert High Assurance EV Root CA

Thumbprint: 5fb7ee0633e259dbad0c4c9ae6d38f1a61c7dc25

DigiCert Assured ID Root CA

Thumbprint: 0563b8630d62d75abbc8ab1e4bdfb5a899b24d43

The table below applies to software and hotfixes released in 2019.


Signing certificate

Timestamping certificates

2019

1E Limited

Symantec SHA256 TimeStamping Signer - G3

Issuing CA

Symantec Class 3 SHA256 Code Signing CA

Thumbprint: 007790f6561dad89b0bcd85585762495e358f8a5

Symantec SHA256 TimeStamping CA

Thumbprint: 6fc9edb5e00ab64151c1cdfcac74ad2c7b7e3be4

Root CA

VeriSign Class 3 Public Primary Certification Authority - G5

Thumbprint: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5

VeriSign Universal Root Certification Authority

Thumbprint: 3679ca35668772304d30a5fb873b0fa77bb70d54

Email requirements

SMTP server

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

  • approval request emails to approvers about pending action requests
  • notification emails to users about responses that will expire shortly
  • one-time authentication code emails if the two-factor authentication feature is enabled

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

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

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

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

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

Mail-from address

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

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

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

Email for Users and Approvers

Tachyon users and approvers require email addresses otherwise they will not receive emails when actions require authentication or approval. Email addresses are mandatory if two-factor authentication is enabled.

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

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

Two-factor Authentication requirements

If the 2FA feature is enabled, Tachyon users are prompted to enter a one-time authentication code in addition to their password in order to confirm they want to submit an action instruction. 

The one-time authentication code is sent to the user by email. The two-factor authentication feature requires email.

Please refer to Tachyon Server post-installation tasks: Enabling or disabling Two-factor Authentication.

The Authentication App available in previous versions of Tachyon is now obsolete and no longer supported.

Feature dependencies

1E companion products

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

Supported versions of 1E companion products with features that depend on Tachyon 5.0. For products that depend on the 1E Client, please refer to 1E Companion Products that depend on 1E Client 5.0.

Products and features that depend on TachyonSupported versions of companion products
1E ITSM Connect1E ITSM Connect for ServiceNow requires a full Tachyon infrastructure. The 1E ITSM Connect app is available on the ServiceNow app store and is installed onto your ServiceNow instance.
  • 1E ITSM Connect 2.0
1E ExperienceExperience is a consumer application of the Tachyon Platform, installed on the Tachyon Server (Master Stack) and requires a full Tachyon infrastructure. It also requires a SQL Server Analysis Server (SSAS) instance. 1E Experience is installed using Tachyon Setup.
  • 1E Experience 1.0
AppClarityAppClarity is a consumer application of the Tachyon Platform and requires a full Tachyon infrastructure. It is installed using its own MSI installer on the Tachyon Server (Master-stack)
  • AppClarity 7.0
Application MigrationApplication Migration is a consumer application of the Tachyon Platform and requires a full Tachyon infrastructure. It is installed using its own MSI installer on the Tachyon Server (Master-stack).
  • Application Migration 3.0
NightWatchmanConsole live status of NightWatchman clients. This is an optional feature of NightWatchman and requires a full Tachyon infrastructure.
  • NightWatchman Enterprise 7.3
  • NightWatchman Enterprise 7.2.500
NomadNomad Download Pause feature. This is an optional feature of Nomad and requires a full Tachyon infrastructure, including ActiveEfficiency.
  • Nomad 7.0.100
  • Nomad 7.0
  • Nomad 6.3.201
Patch SuccessPatch Success is a consumer application of the Tachyon Platform, installed on the Tachyon Server (Master Stack) and requires a full Tachyon infrastructure. It also requires 1E SLA Platform Business Intelligence to be installed and a SQL Server Analysis Server (SSAS) instance. Patch Success and Business Intelligence are installed using Tachyon Setup.
  • Patch Success 1.2

The following Tachyon Portal applications are installed on Tachyon using Tachyon Setup: Explorer, Guaranteed State, Inventory, Settings, 1E Experience, and Patch Success.

The following Tachyon Portal applications are installed on Tachyon using their own installers: AppClarity and Application Migration.

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

Products and features that Tachyon depends onSupported versions of companion products
1E Catalog

Required by Tachyon and included in Tachyon Setup options for single-server and Master-stack.

  • 1E Catalog 2.0
1E Client

Tachyon requires the 1E Client (with Tachyon client features enabled) to be installed on all client computers. This replaces the legacy Tachyon Agent.

Tachyon client features:

  • Real-time response to instructions, which supports the retrieval of information using questions, and running actions
  • Device tags (freeform and coverage), Criticality and Location
  • Inventory, including process usage, to support:
    • the Tachyon Activity Record feature
    • the Inventory and other consumer applications (new in 5.0)
  • Performance metrics features to support the Experience application (new in 5.0)
  • Policy feature to support the Guaranteed State application
  • Modules to support:
    • the Patch Success application
    • content distribution
    • command and script execution
    • device criticality
    • manipulation of registry, WMI, files and processes
    • security
    • software uninstallation.

Tachyon clients can optionally use the Nomad client module of 1E Client to more efficiently download content.

  • 1E Client 5.0 (with Tachyon client enabled)
  • 1E Client 4.1 (with Tachyon client enabled)
ActiveEfficiencyActiveEfficiency Server is included in Tachyon Setup in order to support Nomad features that require ActiveEfficiency. ActiveEfficiency is not required by Tachyon infrastructure.
  • ActiveEfficiency 1.10
Nomad

Tachyon clients can optionally use Nomad (1E Client with Nomad client features enabled) to provide more efficient downloading of content. Alternatively use Nomad Branch 6.3 client if installed.

  • 1E Client 5.0 (with Nomad client enabled)
  • 1E Client 4.1 (with Nomad client enabled)
  • Nomad 6.3 (legacy client)

Product Packs and Security Roles

Classic Product Packs:

  • include instructions
  • are uploaded manually, as described in Instruction sets page
  • once the instructions are uploaded you must organize them manually into Instruction Sets
  • Instruction Sets are the basis for assigning custom roles that determine who can do what with the instructions in each Set
  • available

Integrated Product Packs:

  • include policies and/or instructions
  • are uploaded using the Tachyon Product Pack deployment tool, as described in Uploading the Integrated Product Packs
  • policies are uploaded into Guaranteed State
  • instructions are automatically uploaded into an Instruction Set defined in the pack
  • available

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

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

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

Export all feature

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

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

Nomad integration

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

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

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

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

Configuration Manager present

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

Configuration Manager not present

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

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

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

Configuration Manager integration

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

Tachyon scripting requirements

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

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

PowerShell on Windows OS

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

To see if an instruction requires PowerShell, look in its Instruction Definition XML file for the Scripting.Run method.

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

To determine the version of PowerShell on a computer, start PowerShell (command prompt or ISE) and enter one of the following commands: $PSVersionTable.PSVersion or $PSVersionTable for more detail.

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

OS VersionPowerShell VersionNotes
1.02.0 (Note 3)3.04.05.05.1
Windows Server 2016, 2019



RTM (Note 9)RTM (Notes 12, 13)Note 4
Windows 10



RTM (built-in)Anniversary Update (built-in)
Windows Server 2012 R2


RTM (built-in)RTM (Note 9)RTM (Note 12)Note 4
Windows 8.1


RTM (built-in)RTM (Note 9)RTM (Note 12)
Windows Server 2012 *

RTM (built-in)RTM (Note 7)RTM (Note 9)RTM (Note 12)Note 4
Windows 8 *

RTM (built-in)



Windows Server 2008 R2 *
RTM (built-in)SP1 (Note 6)SP1 (Note 7)SP1 (Note 8)SP1 (Note 10)Note 4
Windows 7
RTM (built-in)SP1 (Note 6)SP1 (Note 7)SP1 (Note 8)SP1 (Note 10)
Windows Server 2008 *RTM (built-in)
SP1 & SP2 (Note 2)



Windows Server 2003 *RTM & SP1R2 & SP2



Notes 1, 2
Windows Vista *RTMSP1 & SP2



Notes 1, 2
Windows XP *RTM, SP1 & SP2SP3



Notes 1, 2

* These OS are regarded as Legacy OS.

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

Microsoft ended support for .NET Framework 4, 4.5, and 4.5.1 on January 12, 2016. Please refer to https://support.microsoft.com/en-gb/help/17455/lifecycle-faq-net-framework.

Bash on non-Windows OS

Bash and perl are required for installation of all non-Windows 1E Clients, with the exception of the 1E Client for Android which is installed through the Google Play Store and configured using UI screens.

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

To see if an Instruction requires a Bash script, look in its Instruction Definition XML file for the Scripting.Run method. Bash is the preferred choice when developing custom Instructions for non-Windows OS.

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

Firewall Ports

The following are extracts from the Communication Ports reference page.

Firewall requirements for a Single-Server

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

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

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

Port requirements are not provided here for Nomad, Shopping and WakeUp modules of the 1E Client.  Only the ports used by the Tachyon client feature of the 1E Client are listed.

If 1E Nomad module is being used by the Tachyon client on Windows computers, it has additional port requirements of its own, which are not changed by Tachyon.

Additional ports may be required if Tachyon instructions need to connect to non-Tachyon content sources.

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

Tachyon Servers

DevicePortProtocolDirectionUsageConfigurable

Tachyon Server (Master Stack)

TCP 443HTTPSIncoming
  • Console browser connections to the Tachyon Portal UI
  • Console browser connections to the SLA Platform UI

  • Consumer connections to the Consumer API
  • Consumer connections to the SLA Platform API

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

See Tachyon Server installer properties: HTTPSIISPORT.

See SLA Platform installer properties: IIS_HTTPS_PORT.

Tachyon Server (Master Stack)

TCP 80HTTPIncoming
  • Console browser connections to the 1E Catalog UI
  • Consumer connections to the Catalog API 
  • Consumer connections to the SLA Platform API

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

See 1E Catalog installer properties: IISPORT.


Tachyon Server (Response Stack)

TCP 443HTTPSIncoming
  • Tachyon client retrieving content from the Background Channel.

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

See Tachyon Server installer properties: HTTPSIISPORT.

Tachyon Server (Master Stack)

TCP 443HTTPSOutgoing
  • Tachyon Coordinator service contacting the 1E Cloud License Service via Internet connection.
  • 1E Catalog Update service contacting the 1E Cloud Catalog Service via Internet connection.
The port used to connect to the 1E Cloud Services is not configurable.

Tachyon Server (Master Stack)

TCP 6002WebSocket (ws)Incoming Outgoing
  • Integrate Agent service connecting to the Integrate Manager Web API to get connector jobs

Yes, configurable after installation.

Integrate Agent component is not shown on the diagram, and installation on remote systems is not supported.

Tachyon Server (Response Stack)

TCP 4000WebSocketSecure (wss)Incoming
  • Tachyon client (feature of 1E Client) receiving instructions from and sending compressed responses to the Tachyon Switch.

Switch ports are not configurable using the Server installer.

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

If the Switch port is changed after deploying 1E Clients (with Tachyon features enabled) then the corresponding Switch port must be updated in each Client's configuration file.

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

Tachyon Server (Master Stack)

TCP 25SMTPOutgoing
  • Tachyon Coordinator service sending two-factor authentication emails.
  • Tachyon Coordinator service sending workflow emails.

Yes.

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

Tachyon Server (Master Stack)

TCP 1433TDSOutgoing
  • Tachyon Web Site application pools (Portal, Consumer API) communicating with SQL Server.
  • SLA Platform Web Site application pools (Admin, CoreExternal, Platform) communicating with SQL Server.
  • Tachyon Coordinator service communicating with SQL Server.
  • Catalog services and application pool communicating with SQL Server.
  • 1E Catalog Update service communicating with SQL Server.

Not configurable from Setup.

In the Database Servers panel in Tachyon Setup you can select a SQL Server instance. The instance can be installed using a non-standard port.

However, selecting an instance that uses a non-standard port will not change the port used by the Tachyon Installer, and installation will fail. If you require the use of a non-standard port on a Default SQL Server instance, contact 1E for guidance on a manual workaround.

If using a Named Instance that is set to its default configuration where the server automatically chooses a random port (or if you manually configured the instance to use a fixed port), then the SQL Browser service needs to be enabled to let the Tachyon Server determine the port in use. You will need to open UDP port 1434 used by the SQL Browser.

See Tachyon Server installer properties: SQLSERVER_MASTER.

Tachyon Server (Response Stack)

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

Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack).

See Tachyon Server installer properties: SQLSERVER_RESPONSES.

SQL Server (TachyonMaster database)

TCP 1433TDSIncoming
  • Tachyon Web Site application pools (Consumer API, Portal) communicating with SQL Server.
  • Tachyon Coordinator service communicating with SQL Server.
  • Tachyon Web Site application pools (Core) communicating with SQL Server.

Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack).

See Tachyon Server installer properties: SQLSERVER_MASTER.

SQL Server (TachyonResponses database)

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

Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack).

See Tachyon Server installer properties: SQLSERVER_RESPONSES.

 

Firewall requirements for a remote Tachyon Response Stack

The following table lists firewall requirements when using a Tachyon Response Stack that is remote from the Tachyon Master Stack, that are additional to the ports required for a Single-Server. Each Tachyon component described in the table has at least one output and/or input. For each Tachyon component with an output there is a matching input.

DevicePortProtocolDirectionUsageConfigurable

Tachyon Server (Master Stack)

TCP 443HTTPSOutgoing
  • Tachyon Coordinator Workflow service connections to the Core on a remote Response Stack
  • Consumer API connections to the remote Background Channel on a remote Response Stack
  • Consumer API connections to the Core on a remote Response Stack

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

See Server installer property HTTPSIISPORT

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

Tachyon Server (Response Stack)

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

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

See Server installer property HTTPSIISPORT.

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

Tachyon Server (Master Stack)

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

Tachyon Server (Response Stack)

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

SQL Server (TachyonMaster database)

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

Not configurable from Setup.

In the Database Servers panel in Tachyon Setup you can select a SQL Server instance. The instance can be installed using a non-standard port.

However, selecting an instance that uses a non-standard port will not change the port used by the Tachyon Installer, and installation will fail. If you require the use of a non-standard port on a Default SQL Server instance, contact 1E for guidance on a manual workaround.

If using a Named Instance that is set to its default configuration where the server automatically chooses a random port (or if you manually configured the instance to use a fixed port), then the SQL Browser service needs to be enabled to let the Tachyon Server determine the port in use. You will need to open UDP port 1434 used by the SQL Browser.

See Server installer property SQLSERVER_MASTER.

Tachyon Server (Response Stack)

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

Not configurable from Setup. See the comments above for SQL Server (TachyonMaster database).

See Server installer property SQLSERVER_MASTER.

Firewall requirements for a Tachyon DMZ Server

The following table lists the subset of ports needed when hosting Tachyon Switch and Background Channel components on a DMZ Server to support devices external to the network. Each Tachyon component described in the table has at least one output and/or input. For each Tachyon component with an output there is a matching input.

If the server is a domain joined server it needs to be able to access Microsoft services, including Certificate Services and Active Directory. If the server is not domain joined (a workgroup server) you will need to manually install its Web Server certificate.

In both cases you will also need to ensure that the server is able to validate the certificate, including accessing the certificate's remote CRL Distribution Point.

The following table does not cover port requirements when using ADFS and SAML tokens to authenticate clients. In this documentation we just provide details of the simplest option, which uses certificates for client authentication. For details of how to configure Tachyon to support the more complex implementations, please contact 1E.

DevicePortProtocolDirectionUsageConfigurable

DMZ Server

TCP 443HTTPSIncoming
  • Internet-facing Tachyon client retrieving content from the Background Channel
  • Background Channel receiving content from the Consumer API on the Master Stack

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

See Server installer property HTTPSIISPORT

DMZ Server

TCP 443HTTPSOutgoing
  • The Switch forwards compressed responses from the Internet-facing Tachyon client devices to the Core on the Response Stack

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

See Server installer property HTTPSIISPORT

DMZ Server

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

DMZ Server

TCP 4001TCPIncoming
  • A prompt from the Core on the Response Stack to each Switch on the DMZ Server

If the value for the Switch Port has been changed, the Port you need to open should be the Switch Port + 1.

DMZ Server

TCP 4000WebSocket Secure (wss)Incoming
  • Internet-facing Tachyon client requesting instructions from and sending compressed responses to the Tachyon Switch

Switch ports are not configurable using the Server installer.

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

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

DMZ Server

TCP 80HTTPOutgoing
  • See note above about accessing the certificate's remote CRL Distribution Point.

Tachyon Server (Response Stack)

TCP 443HTTPSIncoming
  • The Core receives compressed responses forwarded by the Switch

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

See Server installer property HTTPSIISPORT

Tachyon Server (Master Stack)

TCP 443HTTPSOutgoing
  • The Consumer API on the Master Stack sends content to the Background Channel

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

See Server installer property HTTPSIISPORT

Tachyon Server (Response Stack)

TCP 4001TCPOutgoing
  • The Core on the Response Stack prompts each Switch on the DMZ Server

Switch ports are not configurable using the Server installer.

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

If the value for the Switch Port has been changed the Port you need to open should be the Switch Port + 1.

Tachyon Server (Master Stack)

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

Internet-facing Tachyon clients

TCP 443HTTPSOutgoing
  • Internet-facing Tachyon client retrieves content from the Background Channel
Yes, during installation. See Tachyon client settings: BACKGROUNDCHANNELURL.

Internet-facing Tachyon clients

TCP 4000WebSocket Secure (wss)Outgoing
  • Internet-facing Tachyon client requests instructions from and sends compressed responses to the Tachyon Switch

Yes. See Tachyon client settings: SWITCH.

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

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

Tachyon Portal

The table below shows client platform requirements for accessing the consumer applications in the Tachyon Portal.

CategoryProductNotes

Browsers

Latest version of:

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


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

Please review Known issues: Using Tachyon.

Deploying 1E Client

1E Client has replaced the Tachyon Agent, and incudes clients for Tachyon, Nomad, Shopping and WakeUp products. For more information about the 1E Client, please refer to 1E Client 5.0.

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

1E Client non-Windows installation account

    MultiExcerpt named 'TachyonNonWindowsInstallationAccount' was not found
The page: Deploying 1E Client on macOS was found, but the multiexcerpt named 'TachyonNonWindowsInstallationAccount' was not found. Please check/update the page name used in the 'multiexcerpt-include macro.

Deployment

You must decide how you will configure the 1E Client and deploy to devices. For more information about configuring the 1E Client properties during and after installation, please refer to 1E Client configuration settings and installer properties.

Supported Device Platforms

CategoryProductNotes

Windows OS

  • Windows Server 2019
  • Windows Server 2016
  • Windows 10 CB 2004
  • Windows 10 CB 1909
  • Windows 10 CB 1903
  • Windows 10 CB 1809
  • Windows 10 CB 1803
  • Windows 10 CB 1709
  • Windows 8.1

Professional and Enterprise editions of Windows 10 are supported.

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

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

This list is automatically updated to show only those OS versions in mainstream support by Microsoft, and therefore supported by 1E, and by 1E Client 5.0. However the following OS continue to be supported as exceptions to help customers during their migration to the latest OS:

  • Windows Server 2012 R2
  • Windows 7 SP1

Please refer to Constraints of Legacy OS regarding end of mainstream support.

For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search.

Please refer to https://1eportal.force.com/s/support-for-msft-rapid-release-cycle for details of which Current Branch versions are supported by 1E products, and known issues regarding specific versions.

For installation guidance on Windows, please refer to Deploying 1E Client on Windows.

The following 1E Client features and modules are supported on Windows OS:

  • Tachyon client
  • Shopping client
  • Shopping WSA (workstation OS only, not server OS)
  • WakeUp client
  • Nomad client

Runtime libraries

  • .NET Framework 4.8
  • .NET Framework 4.7.2
  • .NET Framework 4.7.1
  • .NET Framework 4.7
  • .NET Framework 4.6.2
  • .NET Framework 4.6.1
  • .NET Framework 4.6


One of these versions of .NET Framework is required, but only by the WSA executable in the Shopping module. It is not required by any other 1E Client features or modules.

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

For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search.

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

1E Client installer includes the redistributable package for Visual C++ 2013.

PowerShell is not a prerequisite for installation of the 1E Client. PowerShell is used by some Tachyon instructions (that have PowerShell commands embedded or scripts that are downloaded) and some of these require PowerShell 3.0 or later.

1E Client provides Tachyon client features. It also includes the Nomad client module which replaces the legacy Nomad Branch client. Tachyon client features can optionally use Nomad to download content (feature enabled by default) if the Nomad client module in 1E Client is enabled (module disabled by default) or Nomad Branch 6.3.100 or later is running.

For more details please refer to Design Considerations: Downloading Tachyon client content and Nomad integration. 

Non-Windows OS

macOS

  • MacOS Catalina 10.15.1
  • macOS Mojave 10.14
  • macOS High Sierra 10.13

Linux

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

Solaris

  • Solaris 11.3

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

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

The 1E Client for non-Windows zip is available for download from the 1E Support Portal, and includes 1E Client packages for the following architectures:

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

Also included in the download are 1E Client packages for the following legacy Linux distributions:

  • Fedora 21
  • openSUSE Leap 42.1

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

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

  • libcurl
  • zlib

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

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

Mobile OS

Android

  • Android Pie 9.0
  • Android Oreo 8.1
  • Android Oreo 8.0

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

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

The 1E Client for Android zip is available for download from the 1E Support Portal, and includes 1E Client packages for the following architectures:

  • Android ARM


Other Non-Windows Software

  • Bash
  • Perl

Bash and perl are required for installation of 1E Client on all non-Windows OS, with the exception of the 1E Client for Android which is available from the Google Play Store.

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

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

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

Microsoft System Center Configuration Manager Client

  • SCCM CB 2002
  • SCCM CB 1910
  • SCCM CB 1906
  • SCCM CB 1902
  • SCCM CB 1810
  • SCCM CB 1806

The following client features work with these versions of Configuration Manager on Windows computers:

  • Nomad client - all Nomad features
  • Shopping client - N/A
  • Tachyon client - instructions used by Tachyon Configuration Manager Console extensions
  • Wakeup client - 1E WakeUp Policy Refresh and REFRESHONSUBNETCHANGE

Configuration Manager is not a prerequisite for installation of the 1E Client, and except for above features, the 1E Client, its features and modules, have no dependency on Configuration Manager.

Tachyon, Nomad, WakeUp and Application Migration have Configuration Manager Console extensions which are available separately.

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

For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search.

Please refer to https://1eportal.force.com/s/support-for-msft-rapid-release-cycle for details of which Current Branch versions are supported by 1E products, and known issues regarding specific versions.

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

Constraints of Legacy OS

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

1E does not provide support for 1E products on the following OS unless the OS is explicitly listed as being supported for a specific 1E product or product feature. This is because Microsoft has ended mainstream support for these OS or they are not significantly used by business organizations.

  • Windows XP
  • Windows Vista
  • Windows 7
  • Windows 8.0
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2

Please contact 1E if you require support for these legacy OS. If you experience an issue on these OS, then please try replicating the issue on a supported OS.

For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search.

Microsoft legacy browsers

Support has been withdrawn for Internet Explorer 11 and legacy Microsoft Edge (non-Chromium version). 1E has taken this decision for new releases that are expected to remain in support by 1E beyond March 2021 when Microsoft Edge goes end of life and August 2021 when Internet Explorer 11 goes end of life. We recommend you use Google Chrome, Firefox or Microsoft Edge Chromium browser.

Certificate limitations - SHA2

Like most software vendors, 1E software requires the OS to support SHA2. If your organization has a PKI configured to use SHA2 256 or higher encryption, then your legacy OS may have already been updated to support it.

Windows XP and Server 2003 require an update as described in KB968730.  Microsoft no longer provides this hotfix as a download. You must contact Microsoft Support if you need it.

Windows 7 and Server 2008 R2 require an update as described in KB3033929. This update is not available for Vista and Server 2008.

Windows 8, 8.1, Server 2012, Server 2012 R2 and later OS already support SHA2.

Certificate limitations - encrypted certificate requests

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

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

	certutil -getreg CA\InterfaceFlags

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

	IF_ENFORCEENCRYPTICERTREQUEST -- 200 (512)

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

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

Certificate limitations - expired root certificates

Ensure that your Root CA Certificates are up-to-date on clients and servers. The Automatic Root Certificates Update feature is enabled by default on these legacy OS but its configuration may have been changed or restricted by Group Policy Turn off Automatic Root Certificates Update.

If this GPO is enabled then you will see DisableRootAutoUpdate = 1 (dword) in HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot.

Certificate limitations - signing certificates missing

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

Root Certificate Authorities are implicitly trusted to validate certificates, and their certificates must be correctly installed to do this. Your computers should already have the necessary root CA certificates installed, however this may have been prevented by your organization's security policies, or inability to connect to the Internet, or they are legacy OS. In general this is not an issue because by default Windows allows software to be installed and run without validation, although you may see a warning or experience a delay. However, you must have relevant CA certificates installed if you are using 1E Client (which self-validates its own files), or your organization has applied more secure polices (for example UAC, AppLocker or SmartScreen).

Typical reasons for issues with signing certificate are:

  • If your organization has disabled Automatic Root Certificates Update then you must ensure the relevant root CA certificates are correctly installed on each computer
  • If computers do not have access to the Internet then you must ensure the relevant root and issuing CA certificates are correctly installed on each computer, numbered in the table(s) below. 

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

The table below applies to software and hotfixes released in 2020.


Signing certificate

Timestamping certificates

2020

1E Limited

TIMESTAMP-SHA256-2019-10-15 and DigiCert Timestamp Responder

Issuing CA

DigiCert EV Code Signing CA (SHA2)

Thumbprint: 60ee3fc53d4bdfd1697ae5beae1cab1c0f3ad4e3

DigiCert SHA2 Assured ID Timestamping CA

Thumbprint: 3ba63a6e4841355772debef9cdcf4d5af353a297

and  DigiCert Assured ID CA-1

Thumbprint: 19a09b5a36f4dd99727df783c17a51231a56c117

Root CA

DigiCert High Assurance EV Root CA

Thumbprint: 5fb7ee0633e259dbad0c4c9ae6d38f1a61c7dc25

DigiCert Assured ID Root CA

Thumbprint: 0563b8630d62d75abbc8ab1e4bdfb5a899b24d43

The table below applies to software and hotfixes released in 2019.


Signing certificate

Timestamping certificates

2019

1E Limited

Symantec SHA256 TimeStamping Signer - G3

Issuing CA

Symantec Class 3 SHA256 Code Signing CA

Thumbprint: 007790f6561dad89b0bcd85585762495e358f8a5

Symantec SHA256 TimeStamping CA

Thumbprint: 6fc9edb5e00ab64151c1cdfcac74ad2c7b7e3be4

Root CA

VeriSign Class 3 Public Primary Certification Authority - G5

Thumbprint: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5

VeriSign Universal Root Certification Authority

Thumbprint: 3679ca35668772304d30a5fb873b0fa77bb70d54

This is described in Requirements: Digital Signing Certificates. To verify if you affected by this issue see Client issues: 1E Digital Signing Certificates.

Copyright and Trademark Notices

All rights reserved. No part of this document or of the software ("the software") to which it relates shall be reproduced, adapted, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without permission from 1E Ltd. It is the responsibility of the user to use the software in accordance with this document and 1E Ltd shall not be responsible if the user fails to do so. Although every precaution has been taken in the preparation of this document, 1E Ltd and the authors assume no responsibility for errors or omissions, nor shall they be liable for damages resulting from any information in it.

Trademarks

1E, the 1E device, ACTIVEEFFICIENCY, APPCLARITY, NIGHTWATCHMAN, NOMAD 2012, DROWSY and DROWSY SERVER are trademarks belonging to 1E Ltd. 1E is registered in the UK, EU and the US. The 1E device is registered in the UK, EU, Australia and the US. NIGHTWATCHMAN is registered in the EU and the US. NOMAD BRANCH is registered in the EU and the US. DROWSY is registered in the UK. DROWSY SERVER is registered in the US. MICROSOFT, WINDOWS 7, WINDOWS VISTA, WINDOWS XP, SMS, CONFIGURATION MANAGER, INTERNET EXPLORER, SQL SERVER are all trademarks of Microsoft Corporation in the United States and other countries. Macintosh is a trademark of Apple Inc., registered in the U.S. and other countries. VMWARE is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions.