Contents
AWS Network Configuration
For a split server installation it is necessary to configure an additional network interface into each server to guarantee a dedicated 1Gbps network channel between the core and the database. Enhanced networking (SR-IOV) must be enabled on both of these NICs which should be the default. Detailed steps on how to verify this are given here - http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/sriov-networking.html. Also increase the transmit (TX) and receive (RX) buffer sizes to their maximum under the network adaptor advanced properties.
Azure Network Configuration
For a split server installation it is necessary to configure an additional network interface into each server to guarantee a dedicated 1Gbps network channel between the core and the database. Enhanced networking (SR-IOV) must be enabled on both of these NICs where this is available (only on instances with 8cores or more) and must be enabled during instance creation. The additional NIC must also have accelerated networking enabled using Azure Powershell or Azure CLI. Detailed steps on how to configure this are given here - https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-create-vm-accelerated-networking. Also increase the transmit (TX) and receive (RX) buffer sizes to their maximum under the network adaptor advanced properties within the guest OS.
If connecting to an Azure based Tachyon switch via external public Azure IP addresses or Azure Load Balancers you will need to extend the default TCP timeout from 4 seconds to 15 seconds. Detailed steps on how to do this can be found here - https://azure.microsoft.com/en-us/blog/new-configurable-idle-timeout-for-azure-load-balancer/.
AWS Database Storage Configuration
Database instances (either combined or the database server in a split implementation) should use an additional Throughput Optimized SSD (ST1) EBS volume to guarantee sufficient disk performance. This is used for all database storage - data, log and tempdb. The specified instances do not support any more than one EBS volume. If you wish to separate data, log and tempdb onto separate volumes (as per Microsoft recommendations) you will need a higher spec instance for the DB server, one that will allow you to attach more volumes and allow higher throughput to disk.
For any implementation other than Lab the Elastic Block Storage (EBS) optimization must be enabled, either when the instance is originally launched or afterwards. here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html.
Azure Database Storage Configuration
Database instances (either combined or the database server in a split implementation) should have a minimum of 2 SSDs for database files. One for the Tachyon data files and tempdb and the other for the log files.
Disable caching on the volume used for the SQL log drive. This is done on the Azure console and not within the guest. Remember to restart the DB server VM once this is changed.
Do not use geo-redundant storage for any of the SQL drives.
A full list of optimizations for running SQL on Azure is available here: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-performance .
AI Powered Auto-curation
Using the AI Powered Auto-curation feature you'll be able to increase the total amount of normalized software in your Inventory repositories. This is done using AI that integrates with the inventory consolidation process. By using AI your organization will benefit from significant numbers of normalized software and a reduced manual effort needed to normalize software.
Before you enable AI Powered Auto-curation, ensure you've met the Tachyon 5.1 - Requirements and completed the Tachyon 5.1 - Preparation steps, in particular the additional disk and memory requirements on the Tachyon web server.
The minimum total disk space required for the downloaded AI Package ZIP is approximately 12.5 GB at installation. This includes:
- Binary and support files for AI and the directory structure is 8 GB
- AIPackage ZIP file is 4 GB
While the downloaded AI Package is 5 GB, the unzipped contents are approximately 12.5 GB and are extracted to C:\ProgramData\1E\SLA Platform\AI\
Please note, the required disk space reduces to 8.2 GB after the first Catalog sync with the cloud. During the sync a check is made for any newer AI packages. If there is one, it's downloaded and a hash check of the ZIP file is made to make sure it's not corrupted. Once all checks are complete, the AI Package ZIP is deleted from C:\ProgramData\1E\SLA Platform\AI\ leaving an 8 GB disk space requirement.
1E Catalog 2.0 or later is required for the AI to work. 1E Catalog is included in the Tachyon Platform zip, and installed by Tachyon Setup.
Distinct Software Titles | Extra GB RAM for AI engine |
---|---|
1 to 5000 | 17 |
10000 | 19 |
20000 | 21 |
30000 | 24 |
40000 | 26 |
50000 | 29 |
60000 | 32 |
70000 | 35 |
80000 | 39 |
90000 | 42 |
100000 | 46 |
110000 | 50 |
120000 | 54 |
130000 | 58 |
140000 | 62 |
150000 | 66 |
160000 | 71 |
170000 | 76 |
Values last updated .
The physical memory required for AI Powered Auto-curation is based on the number of distinct software titles in your source data, that AI has to process that do not already have a match in the 1E Catalog. Use the accompanying table as a quick reference for the memory requirements needed by the AI.
For virtual machines, the AI Engine action will not work if you're using a dynamic memory configuration. You'll need to allocate dedicated memory.
If you're only using a System Center Configuration Manager (SCCM) connector for your source data, then use the below SCCM database query as a guide for how much extra RAM you need on the Tachyon web server before installing Tachyon.
After installation, we recommend you use the below SLA-Data database query to double-check memory requirements. You will need to use the SLA query anyway, if you use a Tachyon connector (for Inventory or Patch Success) either on its own, or with other connectors including SCCM. In this case, use the SLA-Data database query after installation and you have collected your source data.
Server software
Category | Product | Notes |
---|---|---|
Server OS |
| 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:
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 and SQL Server Analysis Services (SSAS) |
| For more detail, please refer to Requirements: SQL Server requirements. Standard and Enterprise editions of these versions of SQL Server and SQL Server Analysis Services (SSAS) are supported. SQL Server 2016 RTM is not supported due to some issues, which are resolved by SP1. Microsoft requires you to use the Enterprise edition of SSAS if you use third-party business intelligence products such as Power BI to connect directly to the cube. You would normally only do this if you want to build a dashboard with the exact preset dimensions that are in the cube, which provides faster UI navigation. However, you can use any edition of SSAS if you want to create a custom dashboard by connecting to the database instead. A SQL Server database instance is required for the following databases:
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:
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:
All SQL Server instances must be configured with the following:
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:
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:
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 |
| See Preparation: Windows Server roles and features for details about required Web Server roles and features. |
Other Software |
| 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.
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:
| 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. These browsers are supported on all OS platforms which the browser vendor supports. Please review Known issues: Using Tachyon. Microsoft legacy browsersSupport 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. |
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.
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:
|
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.
Devices | Switches | Interfaces when SQL is local | Interfaces when SQL is remote | Master Stack with ActiveEfficiency |
---|---|---|---|---|
Up to 500 | 1 | 1 | 1 (Switch and SQL) | share the Switch network interface |
Up to 5,000 | 1 | 1 | 1 (Switch) + 1 (SQL) | share the Switch network interface |
Up to 50,000 | 1 | 1 | 1 (Switch) + 1 (SQL) | + 1 interface for non-Tachyon clients |
Up to 100,000 | 2 | 2 | 2 (Switches) + 1 (SQL) | + 1 interface for non-Tachyon clients |
Over 100,000 | n (3 or more, up to 5) | n | n (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.
Computername
The computername of a Tachyon Server must comply with Microsoft NetBIOS naming standards, which includes having a length of 15 characters or less.
Microsoft's guidance can be found here: https://docs.microsoft.com/en-us/windows/desktop/SysInfo/computer-names.
DNS Names
Each server that has Tachyon platform components installed requires its own DNS Name.
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.
Platform services also reside on the Master Stack, which non-Tachyon clients connect to, for example:
|
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:
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:
|
Internal DNS Names | A DMZ Server is a special example of a Response Stack. The DMZ Server itself requires two DNS Names:
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.
Each DNS Name used to access a Tachyon Server must be included as a DNS Name in the Subject Alternate Name (SAN) entry of the web server certificate, and the Switch certificate files.
A DNS Name can be a DNS alias, CNAME or Host (A) record.
Service Principal Names
Tachyon Platform and applications use underlying IIS and SQL Server technology, and only require HTTP or MSSQLSvc class SPNs if your company security policy has configured IIS or SQL Server to use Kerberos authentication.
If your IIS server is using Kerberos, then each DNS Name used to access a Tachyon Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the relevant service account in Active Directory, which is computer$ by default. This allows Tachyon web applications to authenticate clients using Windows Authentication where Kerberos is an authentication provider (primary, fallback or negotiated).
If your IIS server is using Kerberos then HTTP SPNs are required for web applications that use Windows Authentication, and are created using:
- the web application pool's service account, which is Network Service for all of Tachyon's application pools, and therefore is the computer$ account
- each (A) Host record used to access the web application. If the server is accessed using a CNAME record then you need to register an SPN for each (A) Host record used by the CNAME. A CNAME will have multiple (A) Host records when using round-robin or NLB to access the web server.
SPNs are not required for DNS Names used to connect to Switches and Background Channel, because they do not use Windows Authentication. However, the same DNS Name may be used to access other web applications.
Windows Server roles and features
Items in bold are included in the PowerShell script available for download from Preparation: Windows Server roles and features.
Tachyon Setup will create a website named Tachyon with the necessary bindings, therefore please do not pre-create a website of the same name.
The following roles, role services and features must be installed/enabled as a minimum. The Name column is the reference used in PowerShell commands.
In the case of .NET Framework features we refer to 4.X in the Display Name, as X may be different depending on the server OS. The PowerShell Name always uses 45 instead of the actual version.
Role or Feature | Display Name | Name | Notes |
---|---|---|---|
Web Server | Web Server (IIS) | Web-Server | |
Web Server Common HTTP Features | Default Document | Web-Default-Doc | Included in Web-Server. |
Directory Browsing | Web-Dir-Browsing | Included in Web-Server. | |
HTTP Errors | Web-Http-Errors | Included in Web-Server. | |
Static Content | Web-Static-Content | Included in Web-Server. | |
Web Server Health and Diagnostics | HTTP Logging | Web-Http-Logging | Included in Web-Server. |
Web Server Performance | Static Content Compression | Web-Stat-Compression | Included in Web-Server. |
Dynamic Content Compression | Web-Dyn-Compression | ||
Web Server Security | Request Filtering | Web-Filtering | Included in Web-Server. |
Basic Authentication | Web-Basic-Auth | Only required if using 1E ITSM Connect . | |
IP Address and Domain Restrictions | Web-IP-Security | See note below. | |
Windows Authentication | Web-Windows-Auth | ||
Web Server Application Development | .NET Extensibility 4.X | Web-Net-Ext45 | Included in Web-Asp-Net45. |
ASP.NET 4.X | Web-Asp-Net45 | ||
ISAPI Extensions | Web-ISAPI-Ext | Included in Web-Asp-Net45. | |
ISAPI Filters | Web-ISAPI-Filter | Included in Web-Asp-Net45. | |
Web Server Management Tools | IIS Management Console | Web-Mgmt-Console | |
.NET Framework 4.X Features | .NET Framework 4.X | Net-Framework-45-Core | |
ASP.NET 4.X | Net-Framework-45-ASPNET | ||
Message Queuing | Message Queuing | MSMQ | Only required for ActiveEfficiency server. |
The following roles, role services and features must be removed/disabled.
Parent | Display Name | Name |
---|---|---|
Web Server Common HTTP Features | WebDAV Publishing | Web-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).
Anti-Virus and Malware
The following should be excluded from scans to prevent file locking and resource deletion.
- 1E log files. See Log files for details of Tachyon Server and 1E Client logs
- The Background channel virtual directories (Agent, Content, Installers, PolicyDocuments, and Updates, which by default are in %programdata%\1E\Tachyon)
SQL Server requirements
Below is a list of SQL Server requirements covered in other sections on this page:
- 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
The server installation account requires SQL permissions during installation and upgrade, which can be temporary or permanent. The level of SQL permissions required by the installation account depends on which Tachyon components it is installing.
Master Stacks
For master stacks sysadmin is required as follows:
- to install 1E Catalog
- to create Linked Servers for SLA, which requires sysadmin for the SQL database instances for both SLA and 1E Catalog databases
- to create Linked Servers for BI, which requires sysadmin for the SQL database instances for both SLA and BI databases, and the SSAS instance for the BI cube (required only by Patch Success)
- to create a Linked Server for ActiveEfficiency, which requires sysadmin for the SQL database instance for the ActiveEfficiency database (required only by Nomad)
Response Stacks
Sysadmin availability on SQL instance(s) | SQL Login permissions | ||||||
---|---|---|---|---|---|---|---|
sysadmin SQL Server role is permitted | The server installation account requires the sysadmin SQL Server role on the SQL Server instance(s) that host the TachyonMaster and/or TachyonResponses database(s). This can be used for a new installation, or for an upgrade. | ||||||
sysadmin SQL Server role is not permitted | The SQL Login permissions required by the server installation account vary depending on which choice is implemented, as described in the following table:
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. |
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
Service accounts
Tachyon Server web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE.
Prior to Tachyon 5.0 a domain user account was required by the 1E Catalog Update Service and the CatalogWeb application pool, but now they use Network Service.
The BI SSAS User account has the following requirements:
- The account name and its password will be specified in the Tachyon Setup: BI SSAS database settings screen.
- Must be a domain user account
- configured with Password never expires
although this user might be referred to as a service account, it does not require Logon as a service on the server
- The SLA BI installer (used by Tachyon Setup) automatically grants rights to this user during installation, and stores its credentials encrypted in the following places:
- a linked server connection for the BI database to access the BI cube
- in the configuration file used by the MDX API to query the BI cube
SQL Login for the Network Service account
The SQL Login that is used by the Tachyon Server web applications and services depends on whether the SQL Server is remote from the Tachyon Server or is local, as described in the following table:
Installation scenario | Service account SQL Login |
---|---|
Tachyon Server is remote from SQL | The computer account of the remote Tachyon Server. For example ACME\ACME-TCN01$ |
Tachyon Server and SQL are local | The local network service account, NT AUTHORITY\NETWORK SERVICE |
Before upgrading Tachyon, or installing or upgrading Consumer applications like Application Migration or AppClarity, the SQL Login must be granted the following rights to support Database Snapshot of the Catalog and SLA databases, to restore them if an error occurs:
- dbcreator rights on the SQL database instance hosting the 1E Catalog database
- dbcreator rights on the SQL database instance hosting the SLA databases
During installation, the Tachyon Setup will always:
- attempt to create the SQL Login
- grant it db_owner permission on each of the Tachyon databases
- remove the db_owner permissions when installation is completed.
User accounts
Each Tachyon user requires an account in Active Directory. AD accounts must have their userPrincipalName (UPN) attribute populated, which is normal, but may be missing if users accounts have been created using scripts.
Tachyon users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-factor Authentication is enabled.
Users are added to the Tachyon system and assigned roles by any Tachyon user assigned to the Permissions Administrators system role. A permissions administrator manages Tachyon users and roles using the Permissions Menu in the Tachyon Portal Settings application.Tachyon is supported in multi-domain, multi-forest environments. You have a choice of how Tachyon queries Active Directory, specified during installation.
Tachyon services locate users and computers and membership of security groups by querying a semi-colon delimited list of Active Directory GC and/or LDAP URLs.
GC URL | This is the quickest and simplest method of resolving users and group membership. A single GC URL will normally resolve all users and groups within a single forest. Supports only Universal security groups. |
LDAP URL | A single LDAP URL will normally resolve all users and groups within a single domain. Supports Universal and Global security groups. Required if a Global Catalog (GC) server does not exist in a trusted forest, or if Global security groups must be used. |
Any domain which contains Tachyon servers, users or groups must:
- be resolvable from the Tachyon Server using DNS - that is, the server must be able to resolve domain names using DNS
- have a two-way trust with the domain in which the Tachyon (Master Stack) Server exists - so that users trust the server, and the server trusts users
- allow the Tachyon Server to read computer, user and security group objects in each domain
The default GC:// is sufficient for a Tachyon Server in a simple Active Directory environment of one forest which has a Global Catalog. You can include, but it is not required, the name of the server's local domain or root domain, for example: GC://acme.local
To add support for a remote forest which has its own GC, you would for example have GC://acme.local;GC://nadir.local and so forth adding the root domain of any other forests to the list of GC URLs.
If you prefer to use LDAP, or there are difficulties with trusts between forest domains, then you would create a list of LDAP URLs including all domains that have Tachyon users and groups, as well as domains in which a Tachyon server resides. For example:
LDAP://acme.local;LDAP://pop.acme.local;LDAP://rock.acme.local;LDAP://country.acme.local;LDAP://nadir.local;LDAP://disco.nadir.local
You can mix GC and LDAP URLs, but you should avoid mixing LDAP URLs that are also resolved by a GC URL. For example: GC://;LDAP://nadir.local;LDAP://disco.nadir.local
Active Directory Security Groups
Active Directory security groups are strongly recommended for role-based access control (RBAC) but are not mandatory. AD security groups can be assigned to Tachyon roles after installation, they are not required during installation. They are added as Tachyon users and configured in the same way as AD user accounts. A Tachyon user can therefore be a domain user account or a security group. Groups are not mandatory because users can be assigned to roles and managed within Tachyon instead of AD, or a combination.
Tachyon Setup assigns a limited set of permissions to the server installation account, as described in Tachyon user permissions, which cannot be edited. However, the installation account's permissions can be extended if the account is a member of one or more AD Groups configured as Tachyon users.
An AD security group is also useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog.
AD distribution groups are not supported.
Active Directory in the cloud
The Tachyon software must be installed on a Windows Server that is part of an Active Directory domain. Companies do not always have their on-premises Active Directory extended into their cloud environment - there are security concerns that must be taken into account and there must be some mechanism for either a secure network connection between the customer's on-premises systems and the cloud environment (usually via VPN connection) or a way of synchronizing the cloud based Active Directory implementation with the on-premises one (through a directory synchronization of some sort).
Both AWS and Azure provide the following 'cloud' based versions of Active Directory:
AWS Directory Service for Microsoft Active Directory (Enterprise Edition) - This is a full implementation of Active Directory, but it requires a VPN and a trust relationship set up with any existing on-premises Active Directory to be able to use on-premises based accounts. This makes it quite a complex solution to implement and maintain.
1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.
AWS AD Connector - This is a mechanism for redirecting domain queries from the local network to an on-premises Domain Controller using a VPN instead of needing a domain controller in the cloud.
1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.
AWS Simple AD - This is an implementation of Active Directory based upon Samba 4 and provides a limited subset of a full Active Directory.
1E do not support Tachyon running in this environment.
- Azure Active Directory - Although this provides cloud based identity, it cannot be used for direct active directory connectivity from an Azure virtual machine, for that you need Azure Active Directory Services (next).
Azure Active Directory Services - This provides the ability to domain join Azure Virtual Machines to your Azure Active Directory, however, it is not a full AD as you cannot have domain admin or enterprise admin privileges.
1E do not support Tachyon running in this environment.
The following is the only cloud solution that is fully supported by 1E, and is what we call Extended AD. It doesn't use any of the above, but has the following requirements, which provide an Active Directory presence in the cloud and brings the full capabilities of Active Directory to bear.
- Virtual machines located in the customer's cloud network installed with Windows Server as hosts for:
- Domain Controller(s) in the existing enterprise domain, which can be Read-Only domain controllers (RODC).
- Other member server(s) which host the Tachyon Server components, including Microsoft SQL Server, must be joined to the same enterprise domain.
- A permanent site-to-site VPN connection from cloud to the corporate on-premises network.
1E fully support the Extended AD solution for AWS and Azure, which do not change any of the Active Directory requirements described above.
Server Installation Account
Tachyon user permissions
This is the account used to run Tachyon Setup (and the MSI installer) when installing or upgrading a Tachyon Server. The account is automatically defined as a Tachyon admin user with limited rights which cannot be edited (called a system principal). The installation account only has sufficient rights to add other Tachyon users, assign them to Tachyon roles (including the Permissions Administrator role), and install Tachyon applications. The users and roles created by the installation account are then used for ongoing use and management of Tachyon.
If you need the installation account to have additional Tachyon roles or be a Global Administrator, then the recommended approach is:
- 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
You can disable the installation account in AD after the Tachyon system is operational and other Tachyon users have been setup. You can then re-enable it whenever required for ongoing configuration changes and upgrades.
Do not delete the server installation account from Tachyon after installation.
The server installation account is granted the following permissions as a Tachyon user, configured during installation of the Tachyon Server.
- It is the first Tachyon user account and is a System Principal which means it cannot be deleted or assigned any other rights.
- It is assigned to the Tachyon system roles of:
- It should be used to add additional Tachyon users and administrators, assign them to Tachyon roles, including the Permissions Administrators role, which should then be used for ongoing use and management of Tachyon.
- It may be included in any AD security group assigned to a Tachyon system or custom role.
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 as follows:
- to install 1E Catalog
- to create Linked Servers for SLA, which requires sysadmin for the SQL database instances for both SLA and 1E Catalog databases
- to create Linked Servers for BI, which requires sysadmin for the SQL database instances for both SLA and BI databases, and the SSAS instance for the BI cube (required only by Patch Success)
- to create a Linked Server for ActiveEfficiency, which requires sysadmin for the SQL database instance for the ActiveEfficiency database (required only by Nomad)
Response Stacks
Sysadmin availability on SQL instance(s) | SQL Login permissions | ||||||
---|---|---|---|---|---|---|---|
sysadmin SQL Server role is permitted | The server installation account requires the sysadmin SQL Server role on the SQL Server instance(s) that host the TachyonMaster and/or TachyonResponses database(s). This can be used for a new installation, or for an upgrade. | ||||||
sysadmin SQL Server role is not permitted | The SQL Login permissions required by the server installation account vary depending on which choice is implemented, as described in the following table:
In addition to the permissions given in the table above, the server installation account also needs ALTER ANY LOGIN Securables permission in order to allow creation of the SQL Login for the Network Service account, used by the Tachyon Server web applications and services. Example scripts are provided below to create a SQL Login and grant roles. During installation, the Tachyon Server installer will always attempt to grant db_owner permission to the server installation account on each of the Tachyon databases. Databases must be configured in multi-user mode. |
Please refer to Preparation: Example SQL scripts for creating a SQL Login and granting roles for example SQL scripts.
License file
1E will provide you with a Tachyon.lic license file that defines the products and features your Tachyon System is able to use, for how long, and how many devices it supports, this may be an evaluation or subscription license.
- The license must be activated. Once activated, it may be used only by the Tachyon System that activated it.
- Licenses can be renewed or updated, but if allowed to expire then the affected products or features will not be usable.
- For a new installation, the Tachyon Setup program will let you select the license file from any folder on disk.
- For an existing installation the license file is copied into the folder: %PROGRAMDATA%\1E\Licensing on your Tachyon Server.
For details of what the license file needs to contain, please refer to Design Considerations: License requirements for consumer applications.
If you want to develop your own instructions, or modify downloaded instructions, you will need to contact 1E to add a code signing certificate to your license file, for more details please refer to Code signing certificates below.
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:
- a 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). Tachyon Setup uses this certificate for all web site HTTPS bindings, API and web services, and Switches (if any) on the server. Tachyon Setup also provides a maintenance feature to update After installation, it is possible to manually create or modify web site HTTPS bindings to use a different certificate. but this is not binding binTherefore, a single-server installation requires only one Web Server certificate. This certificate must be provided prior to installation of Tachyon on the server.
The Web Server certificate requires the minimum of the following:
- 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.
- Has at least the following Key Usage:
- Digital signature
- Key encipherment
- Has at least the following Enhanced Key Usages:
- Server Authentication
- Revocation information is included
- References at least one CRL Distribution point that uses HTTP
- Must have a private key available
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:
Fields | Example Option 3 type certificate |
---|---|
Subject Common Name Field (subject:commonName) | Subject can be any valid name, and is no longer mandatory as required by previous versions of Tachyon. |
Subject Alternative Name Extension (extensions:subjectAltName), type dnsName | The Tachyon Server DNS Name FQDN (DNS Alias) of the server. This is mandatory, same as required by previous versions of Tachyon. 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. This is a new requirement for Tachyon 5.0 and later. 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 |
The following need to be considered when requesting this type of certificate.
- The certificate can be used only on the server it was intended, that has the correct hostname FQDN and DNS Alias FQDN.
- It is not possible use the Create Certificate Request method in IIS Manager Server Certificates, because it does not support all the above requirements.
- If you have a Microsoft CA, and a suitable Web Server template has been issued and enabled in the Active Directory Enrollment Policy, then it is possible to Request New Certificate in the Certificates (Local Computer) mmc snap-in and use the Certificate Enrollment wizard.
- Many organizations have their own process for submitting a Certificate Signing Request (CSR). Please ensure all the above requirements are specified. Security administrators sometimes have difficulty providing a certificate with one or more Subject Alternative Names (SAN), and it helps to explain these are type DNS.
If you have a Microsoft CA then it is simplest to use the Certificate Enrollment wizard available in the mmc certificates snap-in, to request a Web Server certificate and fill in the details.
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.
- 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
- imported on the Tachyon Web Server
- included in the PEM file used by the Tachyon Switch
- Has at least the following Enhanced Key Usage
- Client Authentication
- Has a private key
- For a non-Windows device, the private key must be exportable
- Revocation information is included.
- References at least one CRL Distribution point that uses HTTP.
- 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.
2020 | Signing certificate | Timestamping certificates |
---|---|---|
Certificate | 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 |
PKI in the Cloud
Tachyon relies on both client (device) and server side certificates to ensure secure communication. In order for these certificates to work the computers need to trust the PKI implementation (issuing Certification Authority and chain of trust). In a standard on-premises environment devices can be enrolled with certificates using Active Directory Group Policy.
It is possible to use a non-Windows based PKI, but it is then left as an exercise for the user as to how to distribute and enrol device certificates to all end-points.
Given the supported Active Directory configuration above, the PKI requirements described above still apply to a cloud based implementation.
Tachyon Web Server certificate
Since clients must be able to access the Tachyon Switch and Background Channel from both the internal corporate network and the Internet, there are some additional considerations when creating the Tachyon web server certificate.
- The server must have a consistent external FQDN.
In AWS a standard EC2 instance has an external FQDN based upon its externally accessible IP address. However, this IP address will change each time the server restarts, and since the Tachyon Switch relies on an HTTPS certificate that utilizes the FQDN to authenticate the server, this would cause the Switch to stop working. In order to work around this, any AWS implementation MUST use an Elastic IP address associated with the network interface of the Switch to ensure that the IP address never changes, and therefore the external FQDN is always the same. Alternatively you can create a CNAME entry in your external DNS to point to the external FQDN of the AWS instance and use the CNAME as the subject name of the server certificate.
- The web server certificate must incorporate all DNS Names that will be used to access the server in the certificate SAN.
Clients can be configured to connect to multiple Switches for resilience and geographic load balancing. In many cases a cloud based virtual machine may be able to be accessed through both an internal VPN network, and an external Internet connection. These connections can be made using the same DNS name (via a CNAME entry as specified in the main documentation) or by different DNS names (where there are separate internal and external DNS domains in use).
The certificate crafted for the Tachyon Switch must contain all DNS Names that will be used to contact the server in the Subject Alternate Name (SAN) entry within the certificate.
Client certificates
Any devices that will connect to the Tachyon implementation must have a client certificate from a PKI infrastructure trusted by the Tachyon server. In a Windows domain environment this is usually provided through an Enterprise Certificate Authority and the use of Group Policy. It is also possible to provide certificates through SCEP, which 1E has tested and support the use of the Microsoft Device Enrollment Service (MDES) for this purpose. Use of other SCEP solutions will be supported on a best-efforts basis.
Email requirements
SMTP server
The Tachyon SMTP feature can optionally be enabled to send the following types of emails to Tachyon users.
- Approval request emails to approvers about pending action requests
- Notification emails to users about responses that will expire shortly
- One-time authentication code emails if the two-factor authentication feature is enabled.
Emails are HTML format, without any attachments, and have a typical size of approximately 70KBytes. You can choose to modify the email banner header.
Emails are sent by the Coordinator service (workflow module) which by default uses the built-in Network Service (NT AUTHORITY\NETWORK SERVICE).
If the Tachyon SMTP feature is enabled, your SMTP relay/gateway may require the following to be configured.
- Add the Tachyon Server name or IP address to a new or existing white-list policy
- Disable require SMTP authentication (allow anonymous) - see note below
- Assign the "mail-from" address to an AD account - see Mail-From Address below - if it has a SPF (Sender Policy Framework) or Sender ID policy.
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.
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.1.
(For products that depend on the 1E Client, please refer to 1E Companion Products that depend on 1E Client 5.1)
Products and features that depend on Tachyon | Supported versions of companion products | |
---|---|---|
1E Experience | Experience 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 during installation of Tachyon using Tachyon Setup. |
|
AppClarity | AppClarity is a consumer application of the Tachyon Platform and requires a full Tachyon infrastructure. It is installed during or after an installation or upgrade of Tachyon using Tachyon Setup, and has its own MSI installer. |
|
Application Migration | Application Migration is a consumer application of the Tachyon Platform and requires a full Tachyon infrastructure. It is installed during or after installation of Tachyon using Tachyon Setup, and has its own MSI installer. |
|
NightWatchman | Console live status of NightWatchman clients is an optional feature of NightWatchman and requires a full Tachyon infrastructure. |
|
Nomad | Nomad Download Pause feature is an optional feature of Nomad and requires a full Tachyon infrastructure, including ActiveEfficiency. |
|
Patch Success | Patch 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 during an installation or upgrade of Tachyon using Tachyon Setup. |
|
In addition to the consumer applications listed above, Tachyon Setup is also used to install Explorer, Guaranteed State, Inventory and Setting applications.
Supported versions of 1E companion products that Tachyon 5.1 features depend on.
Products and features that Tachyon depends on | Supported versions of companion products | |
---|---|---|
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:
Tachyon clients can optionally use the Nomad client module of 1E Client to more efficiently download content. |
|
ActiveEfficiency | ActiveEfficiency Server is included in Tachyon Setup in order to support Nomad features that require ActiveEfficiency. ActiveEfficiency is not required by Tachyon infrastructure. |
|
Nomad | Tachyon clients can optionally use Nomad (1E Client with Nomad client features enabled) to provide more efficient downloading of Tachyon content. |
|
Connectors
Connectors are used to connect to other 1E and third party systems, retrieve their data and populate repositories. Tachyon provides the following inventory connectors to populate the Tachyon inventory repository:
- BigFix connector — Connects to a BigFix Inventory database server.
- BigFixInv connector — Connects to a BigFix Inventory database.
- File Upload connector — Uploads inventory data from a folder containing tab (TSV) and comma (CSV) separated value file(s).
- InTune connector — Connects to an InTune application and pulls in inventory and usage data.
- Oracle LMS connector — Connects to Oracle LMS and queries it for inventory information.
- ServiceNow connector — Connects to a ServiceNow instance to import basic inventory data into SLA Platform.
- System Center Configuration Manager connector — Connects to a Configuration Manager database and pulls in inventory and usage data.
- Tachyon connector — Connects the Tachyon and SLA components to support Management group and Tachyon Powered Inventory features. The Tachyon Powered Inventory feature uses instructions to fetch inventory data from Tachyon clients, and is a prerequisite for Patch Success.
- vCenter connector — Connects to a vCenter server and pulls in inventory data.
- Windows Server Update Services connector — Connects to a WSUS database and pulls in patch data.
Use the links above to find more information about each type of connector. Please refer to Using Inventory for more information about viewing and exporting inventory repositories.
Please refer to the relevant connector page to identify security and other requirements for a specific connector.
Patch Success needs to get meta-data for patches. Ensure you add a connector for whichever one of the following sources that you use to approve patches:
- Configuration Manager (SCCM) if it is configured to manage WSUS
- Windows Server Update Services (WSUS)
If you are using Configuration Manager then you must add a Tachyon 5.1 - System Center Configuration Manager connector.
If you are using WSUS then you must add a Tachyon 5.1 - Windows Server Update Services connector.
Patch Success also requires a Tachyon connector.
The following table shows the supported versions of software used by the Tachyon out-of-box connectors.
Connector | Product | Notes |
---|---|---|
ServiceNow |
| Please refer to the ServiceNow connector page for prerequisites. |
SCCM (Microsoft System Center Configuration Manager) |
| Please refer to the System Center Configuration Manager connector page for prerequisites. |
Tachyon |
| Please refer to the Tachyon connector page for prerequisites. |
vCenter |
| VMware PowerCLI 11.1.0 (code.vmware.com/web/dp/tool/vmware-powercli/11.1.0) must be installed on the Tachyon Master server (where the SLA Integrate Services Agent service is hosted) before you can configure and use the vCenter connector. Earlier or later versions of PowerCLI are not supported and may cause errors. VMware PowerCLI is freeware and was previously known as vSphere PowerCLI. VMware PowerCLI supports multiple versions of VMware vCenter Server. For details, please refer to the VMware compatibility matrix using the following link: https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&2=&106= Please refer to the vCenter connector page for configuration details. |
Product Packs and Security Roles
Classic Product Packs:
- include instructions
- are uploaded using either of the following methods:
- the Tachyon Product Pack deployment tool as described in Uploading Integrated Product Packs
- the Upload button on the Settings - Instructions sets page, as described in Instruction sets page
- once the instructions are uploaded you must organize them manually into Instruction Sets, although the Tool will use the name of the zip file as the basis for the Instruction set name
- Instruction Sets are the basis for assigning custom roles that determine who can do what with the instructions in each Set
Integrated Product Packs:
- include policies and/or instructions
- are uploaded using the Tachyon Product Pack deployment tool as described in Uploading Integrated Product Packs
- if the pack contains instructions, each one is automatically uploaded into an Instruction Set using the folder name as the basis for the Instruction set name
- policies are uploaded into Guaranteed State
The 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.
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 Version | PowerShell Version | Notes | |||||
---|---|---|---|---|---|---|---|
1.0 | 2.0 (Note 3) | 3.0 | 4.0 | 5.0 | 5.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 & SP1 | R2 & SP2 | Notes 1, 2 | ||||
Windows Vista * | RTM | SP1 & SP2 | Notes 1, 2 | ||||
Windows XP * | RTM, SP1 & SP2 | SP3 | Notes 1, 2 |
* These OS are regarded as legacy OS:
- PowerShell is not built-in for these OS. These OS do not support 3.0 or later. See Constraints of Legacy OS
- If PowerShell 1.0 is installed it must be removed in order to install a later version.
- Support for PowerShell 2.0 is included in PowerShell 3.0 and later.
- PowerShell is not installed by default on these OS but is an optional feature that should be enabled using Server Manager.
- PowerShell 2.0 is part of WMF Core package (KB968930) with prerequisite of .NET Framework 3.51 (which includes .NET 2.0 SP1).
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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.
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.
Whitelisting connections to 1E Cloud
For guidance on whitelisting and configuring Internet Explorer proxy settings, please refer to Preparation: Whitelisting for license activation and validation.
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.
Tachyon Setup will report a warning in the Tachyon Setup - License File screen if it is unable to connect to the 1E license service. This is important only on the Tachyon Master Stack Server, not on other types of Tachyon Server. You can test the connection using Tachyon Setup or using Internet Explorer.
If you are whitelisting an IP address and your server has multiple network interfaces, then you can configure a persistent route using a similar process described in Preparation: Configuring a persistent route for SQL traffic.
Your Tachyon Server may not be able to connect to the 1E license service if your environment is using web proxy servers. Contact 1E for advice in case you have this type of setup.
The 1E Catalog service URL
Ensure the following URL is whitelisted:
This URL must be accessible during setup and running of 1E Catalog. This enables the Catalog Update service to connect to the 1E Cloud Catalog and download the latest catalog entries.
1E Catalog may need additional configuration to support proxy servers, but this depends on the configuration you have in your current environment. Please contact 1E Support if you need help doing this.
Firewall Ports
The following are extracts from the Communication Ports reference page.
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
Device | Port | Protocol | Direction | Usage | Configurable |
---|---|---|---|---|---|
Tachyon Server (Master Stack) | TCP 443 | HTTPS | Incoming |
| Yes, during installation. In the Website Configuration panel in Tachyon Setup. See Tachyon Server installer properties: HTTPSIISPORT. Tachyon Setup installs other components using the same settings as Tachyon Server. |
Tachyon Server (Master Stack) | TCP 80 | HTTP | Incoming |
| Yes, during installation. In the Website Configuration panel in Tachyon Setup. See Tachyon Server installer properties: HTTPSIISPORT. Tachyon Setup installs other components using the same settings as Tachyon Server. |
Tachyon Server (Response Stack) | TCP 443 | HTTPS | Incoming |
| Yes, during installation. In the Website Configuration panel in Tachyon Setup. |
Tachyon Server (Master Stack) | TCP 443 | HTTPS | Outgoing |
| The port used to connect to the 1E Cloud Services is not configurable. |
Tachyon Server (Master Stack) | TCP 6002 | WebSocket (ws) | Incoming Outgoing |
| 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 4000 | WebSocketSecure (wss) | Incoming |
| Switch ports are not configurable using the Server installer. A Switch port can be changed post-installation, by configuring the value in the Port column for the relevant Switch in the SwitchConfiguration table in the Tachyon Master database. If the Switch port is changed after deploying 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 25 | SMTP | Outgoing |
| 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 1433 | TDS | Outgoing |
| 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. |
Tachyon Server (Response Stack) | TCP 1433 | TDS | Outgoing |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack). See Tachyon Server installer properties: SQLSERVER_RESPONSES. |
SQL Server (Master Stack) | TCP 1433 | TDS | Incoming |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack). |
SQL Server (Response Stack) | TCP 1433 | TDS | Incoming |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack). See Tachyon Server installer properties: SQLSERVER_RESPONSES. |
SSAS Server (Master Stack) | TCP 1433 | TDS | Outgoing |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack). |
Tachyon Server (Master Stack) | TCP 2382/3 | ADOMD | Outgoing |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack). |
SQL Server (Master Stack) | TCP 2382/3 | ADOMD | Outgoing |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master Stack). |
SSAS Server (Master Stack) | TCP 2382/3 | ADOMD | Incoming |
| Not configurable from Setup. See the comments above for the Tachyon Server (Master 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.
Device | Port | Protocol | Direction | Usage | Configurable |
---|---|---|---|---|---|
Tachyon Server (Master Stack) | TCP 443 | HTTPS | Outgoing |
| 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 443 | HTTPS | Incoming |
| 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 3901 | WebSocket (ws) | Incoming |
| Yes, but please contact 1E for advice. |
Tachyon Server (Response Stack) | TCP 3901 | WebSocket (ws) | Outgoing |
| Yes, but please contact 1E for advice. |
SQL Server (Master Stack) | TCP 1433 | TDS | Incoming |
| 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 1433 | TDS | Outgoing |
| Not configurable from Setup. See the comments above for SQL Server (TachyonMaster database). See Server installer property SQLSERVER_MASTER. |
Browser support for the Tachyon Portal
The table below shows Browser requirements for accessing the Tachyon Portal and its applications.
Category | Product | Notes |
---|---|---|
Browsers | Latest version of:
| These browsers are supported on all OS platforms which the browser vendor supports. Please review Known issues: Using Tachyon. Microsoft legacy browsersSupport 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. |
Deploying Tachyon clients
Tachyon client Windows Installation Account
The 1E Client installer installs a service as local system, therefore the installation account for Windows clients must be capable of being elevated in order to run the installer. The simplest way of achieving this is for the account to have full local administrator rights (as a member of the localgroup administrators, either directly or indirectly).
Tachyon client non-Windows Installation Account
To install the 1E Client on a non-Windows client the installation account must have privileges to run the sudo command.
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
Category | Product | Notes |
---|---|---|
Windows OS |
| The zip for 1E Client for Windows is available for download from the 1E Support Portal . Professional and Enterprise editions of Windows 10 are supported. 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.1. However the following OS continue to be supported as exceptions to help customers during their migration to the latest OS:
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:
|
Runtime libraries
|
| .NET Framework is required only for the following features of 1E Client:
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.1. For Microsoft product lifecycle details, please refer to https://support.microsoft.com/en-us/lifecycle/search. |
Other Windows Software |
| Visual C++ 2013 - 1E Client installer includes the redistributable package for Visual C++ 2013. PowerShell - PowerShell is not a prerequisite for installation of the 1E Client. PowerShell 3.0 or later (included in Windows 8.0 and later) is required if you are using Tachyon real-time features. Some Tachyon instructions use PowerShell (commands are embedded or scripts are downloaded). PowerShell 4.0 or later (included in Windows 8.1 and later) is required if you are using Application Migration. The Application Migration Task Sequence step executes in a Configuration Manager OS deployment task sequence after the new OS is installed. If you are deploying Windows 7 images, upgrade PowerShell in the image or install it using a task sequence step before executing the Application Migration step. Nomad - 1E Client includes the Nomad client module (disabled by default) which optionally replaces the legacy Nomad Branch client. Tachyon real-time features can optionally use Nomad to download content (feature enabled by default). For more details please refer to Design Considerations: Downloading Tachyon client content and Nomad integration . |
Non-Windows OS
| macOS
Linux
Solaris
| 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:
Also included in the download are 1E Client packages for the following legacy Linux distributions:
1E Client packages for other Linux distributions can be requested, including Raspbian for Raspberry Pi. For Solaris, the following specific libraries are required, but are usually installed by default:
For installation guidance on the following OS, please refer to:
For installation guidance on other non-Windows OS, please contact 1E. |
Other Non-Windows Software |
| Bash and perl are required for installation of 1E Client on all non-Windows OS. 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 |
| The following client features work with these versions of Configuration Manager on Windows computers:
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.1. 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.) |
Requirements for verifying the Tachyon installation
The Verifying page provides detailed steps for verifying a new or upgraded infrastructure, including firsts steps for uploading and running instructions. Below is a list of requirements to perform verification testing.
- Tachyon Server installed
- Remote workstation with a supported browser
- The name and password for the server installation account
- the AD account must be enabled
- the account may already be assigned to other Tachyon roles either directly or via membership of an AD group role.
- Two AD User accounts, Test User 1 and 2
- must not be existing Tachyon users because they will be assigned specific roles for the purpose of these tests
- must have email addresses and be able to read emails.
- The 1E Tachyon Platform instruction set with two Verification instructions
- the verification steps describe how to create this instruction set by uploading the 1E Tachyon Platform Product Pack
- you may have already uploaded this Product Pack using the Product Pack Deployment Tool, either during Setup or after
- the 1E Tachyon Platform Product Pack is included in the TachyonPlatform zip file that you can download from the 1E Support Portal (1eportal.force.com/s/tachyontopicdetail).
- At least one test device on which the 1E Client will be installed
- 1E Client installation source files and configuration details required by your Tachyon implementation.
Constraints of Legacy OS
In this documentation, the following are referred to as legacy OS. Below are described some known issues for these OS.
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.
|
|
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 - 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.
2020 | Signing certificate | Timestamping certificates |
---|---|---|
Certificate | 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 |
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, 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.
PowerShell limitations
PowerShell version 3.0 (required by some Tachyon instructions) is not supported on Windows XP, Vista and Server 2003. However, PowerShell 2.0 is supported on the following OS versions:
- Windows XP SP3
- Vista SP1 & SP2
- Windows Server 2003 R2 & SP2