Upgrading Tachyon Platform
Guidance for upgrading Tachyon, SLA, and ActiveEfficiency platforms to Tachyon Platform.
Before you attempt an upgrade, please ensure you thoroughly read all sections that apply to you. Combine the steps if your system matches multiple upgrade scenarios. If you cannot find a complete match, please contact 1E.
Tachyon Setup will upgrade ActiveEfficiency Server to Content Distribution if it detects the ActiveEfficiency website is installed on the server.
ActiveEfficiency Server is now deprecated, and is not required by the latest versions of products that previously used it: Nomad 7.1 & 8.x, AppClarity 7.0, 7.1 & 8.x, nor Shopping 6.1
ActiveEfficiency Version 1.10.100 was released on March 2020 and is used by Nomad 7.0 and Shopping 6.0 which are still in support
ActiveEfficiency Version 1.10 was released in November 2018 and was required by older versions of Nomad, Shopping, and AppClarity which are now out of support.
Tachyon Setup does not upgrade the following 1E server products:
PXE Everywhere Central - please refer to Upgrading PXE Everywhere
Shopping (Central or Receiver) - please refer to Shopping - Upgrading to Shopping
NightWatchman Management Center - please refer to NightWatchman Enterprise - Upgrading NightWatchman Enterprise
WakeUp Server - please refer to NightWatchman Enterprise - Upgrading NightWatchman Enterprise
ActiveEfficiency Scout.
For upgrading clients, please read below first, then refer to Upgrading 1E Client.
Note
When upgrading to Tachyon Platform 8.1, you will need a new license. Please contact your 1E Sales account manager for license inquiries.
If you are upgrading from SLA Platform 3.3, Tachyon 3.3, or Tachyon 4.x, you must first upgrade to Tachyon 5.2.
Preparing for upgrade
SQL Server AlwaysOn Availability Group
If you are using an Availability Group (AG) then you must temporarily remove the Tachyon databases from the AG during the upgrade.
Please refer to high availability options for SQL Server:
Backup first
Note
Before doing a re-installation or upgrade of the Tachyon Platform, make a backup of the following (but first see the note below about automatic backups):
Tachyon Master database
Note
Backing up the Tachyon Responses database is not usually needed, unless there are instruction responses that you need to keep. Tachyon responses are not permanently held data and will naturally expire according to the settings specified when an instruction was run, typically in hours or possibly days. If in doubt, there is no harm in backing up the Tachyon Responses database as well.
Tachyon Server installation directory.
including the config files, which may have been manually updated in the previous installation.
Switch certificate files.
Earlier versions of Product Packs that have been modified.
Note
Tachyon Setup will automatically perform a backup of the following items:
Tachyon Server installation directory. This is backed up to a subfolder named Tachyon.bak under the root installation folder for Tachyon . All files, including the .config files and certificate files, will be copied.
IIS configuration. This is done by taking a copy of the applicationhost.config file from the Windows system folders. The backup file is placed at the same location and is named like the original file with a suffix that indicates the date and time when the copy was taken.
The following databases are backed up to the default location for backups that is configured in the database server. By default, this points to a subfolder named "Backups" under the folder where the executable for SQL Server is installed. Unless you are installing a small lab or proof-of-concept, this is usually not a good location for the backups, so make sure that you configure the backup location in SQL Server to an adequate folder before starting the Tachyon upgrade:
1ECatalog
ContentDistribution (optional, required by Nomad )
SLA-Data
SLA-Shared
SLA-Integrate
TachyonMaster
TachyonResponses
TachyonExperience (optional, required for Experience ).
The Product packs are not copied by themselves, but they are kept in a table within the TachyonMaster database, which is backed up.
In-place upgrade of Tachyon
This scenario is for upgrading from an older version of Tachyon.
If your current Tachyon server already has ActiveEfficiency Server installed then please also read the following according to what it is currently used for.
Tachyon Setup is used to upgrade the following versions of Tachyon and its applications.
Version | Features |
---|---|
Tachyon Platform 5.2, 8.0 | Real-time and inventory features. Applications: Explorer, Guaranteed State, Patch Success, Application Migration, AppClarity, Experience, and Nomad. |
Tachyon Platform 5.0, 5.1 | Real-time and inventory features. Applications: Explorer, Guaranteed State, Patch Success, Application Migration, AppClarity, Experience, and ActiveEfficiency. |
Tachyon includes real-time and inventory features. Applications: Guaranteed State, Patch Success, Application Migration, AppClarity, Experience, and Nomad.
Tachyon Setup assumes you will keep existing applications when upgrading and optionally install additional applications. However, your Tachyon license ultimately determines which applications you can install and what you are able to use when you connect to the portal.
Upgrading from older versions
When upgrading to Tachyon Platform 8.1, you will need a new license. Please contact your 1E Sales account manager for license inquiries.
If you are upgrading from SLA Platform 3.3, Tachyon 3.3, or 4.x, you must first upgrade to Tachyon Platform 5.2. There are additional notes, which can be found in the Tachyon Platform 5.2 - Upgrading to Tachyon Platform pages.
Steps for in-place upgrade of Tachyon Platform
Upgrade server hardware as required - please refer to ???.
Run Tachyon Setup on the Tachyon Master Stack server to upgrade to Tachyon Platform.
Run Tachyon Setup on remote Tachyon Response Stack servers (if used).
Verify existing clients.
Run Tachyon Setup on remote Tachyon DMZ Server (if used).
Verify existing Internet based clients.
Upgrade existing Product Packs, and install new ones.
Deploy new 1E Client to devices (with Tachyon enabled) and verify.
Review Role name changes and rationalize your existing roles if necessary.
Changing the Platform configuration when reinstalling or upgrading
Keep the DNS Names
Each server that has Tachyon platform components installed requires its own DNS Name. A DNS Name can be a DNS alias, CNAME or Host (A) record.
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:
| |
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. | |
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.
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. | |||||||||
The following client-facing components can each have their own DNS Name:
NoteMaster 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 Master Stack, it will normally share the same DNS Name as Master Stack as described under Single DNS Name. However, if you have multiple Response Stacks and want them to share the same DNS Name, then the Master Stack must use a different DNS Name. This approach of all Response Stacks sharing the same DNS Name simplifies adding further Response Stacks at a later date. During installation - using Website configuration - you need to consider the following:
If Master and Response Stacks are on the same server and you want them to have different DNS Names, then use the main binding for client connections to the Response Stack (because it is client-facing) and use the Alternate binding for other connections to the Master Stack. A simpler option is to put the Response Stack on its own server. Remote Response Stacks are recommended if the Master Stack is also hosting services AppClarity Software Reclaimer or Application Migration. If you want to configure Switches on the same server to use multiple DNS Names, you will need to seek guidance from 1E. In most cases this is not required or recommended. | |||||||||
A DMZ Server is a special example of a Response Stack. The DMZ Server itself requires two DNS Names:
NoteBoth DNS Names must be included in the web server certificate. You can manually replace the external/client facing certificate after installation, to comply with best practice not to expose internal names in an external facing certificate. The internal Response Stack also requires an additional DNS Name - for example tachyonalt - for internal communications with the DMZ Server. Please refer to Implementing a Tachyon DMZ Server for more detail about DMZ Servers. |
Note
Tachyon Setup supports installation of one HTTP and up to two HTTPS bindings, but you can manually add more bindings after installation.
Tachyon Setup currently supports only one Web server certificate, which must contain all the DNS Names used by the HTTPS bindings on that server. Each DNS Name must be included as a DNS Name in the Subject Alternate Name (SAN) entry of the web server certificate.
You can manually add more certificates, and change bindings. Please refer to Certificate requirements . Please note that Tachyon Setup helps maintain the main and alternate HTTPS bindings using one certificate.
Moving Server
Agents use the DNS Name FQDN to connect to the Switch and Background Channel. Provided the DNS Name FQDN remains the same, the server can be renamed or moved without having to re-configure clients.
If the server hosting a Tachyon Server is renamed or moved, then it will need a new certificate and Tachyon Server must be re-installed. The database can be kept. There is also a known issue where new website URLs do not get updated in the database tables.
Please contact 1E for advice if a new configuration is required when re-installing or upgrading a server.
Upgrading to Tachyon Platform
Note
Partial Upgrades
You may still be asked at some intermediate steps about configuration information for the components that will not be installed. You should still provide it, because it may be relevant for Tachyon Setup at the time of configuring other components that are being installed so that they can interact with the components that are not being installed but are already present in the system.
Use the following process when upgrading Tachyon to Tachyon Platform, and keep the same configuration and the TachyonMaster database. Keeping the same configuration means using the same installer properties as the previous installation.
If changing the configuration, please refer to Changing the Platform configuration when reinstalling or upgrading.
Ref | Step | Notes |
---|---|---|
1 | Ensure you have prerequisites ready for installation of the new version.
Review Known issues. | Preparation for an in-place upgrade is not as complex compared to a new installation, provided the configuration remains the same. If changing the configuration, please refer below to Changing the Platform configuration when reinstalling or upgrading . Determine if you will re-use the existing Web certificate or a new one. If re-using the certificate and upgrading from a version of prior to 5.0 then ensure you make a copy of the certificate files in the Switch SSL folder. If using a new certificate, then follow the guidance in Server Provisioning. If you are upgrading from Tachyon 5.x, the certificates will already be in the local Windows Computer Certificate Store so there is no need to backup. If in doubt about your configuration, review each of the configurations in the Tachyon installation folder. A later step in this process asks you to make a backup copy of the installation folder. This allows you to review configuration settings and also retain a backup of the Switch certificate files. 1E recommends using the same server installation account as the original installation, but this is not mandatory provided the account is an existing Tachyon administrator user. You can check which is the original installation account by looking in the Permissions page and finding the user which does not have an edit or delete icon. NoteWhen upgrading to Tachyon Platform 8.1, you will need a new license. Please contact your 1E Sales account manager for license inquiries. If you are upgrading from SLA Platform 3.3, Tachyon 3.3, or Tachyon 4.x, you must first upgrade to Tachyon 5.2. |
2 | Inform Tachyon users when you plan to upgrade the system. | You should notify Tachyon users about the impending upgrade. This includes users of external consumers such as the extension described in Using Tachyon in Configuration Manager. To help identify the users of the Tachyon system, you can review the Tachyon Permissions. You can also review the Tachyon Consumers in order to remind yourself of any 3rd party systems that will be affected by the upgrade. Any instructions that are running or pending approval prior to the Platform and Agent upgrade will not be affected, other than be delayed by services being temporarily down. |
3 | Shutdown the existing Tachyon system.
| If you want to keep any instruction responses, review the notes in the next step before shutting down the system. Shutting down the system gracefully ensures there are no instructions in process and prevents access. The installer will internally shut down the services if you do not stop them manually. Stopping them manually gives you greater control over when they are stopped. The services will be restarted automatically after the upgrade. NoteBoth the Tachyon Switch Host and the Coordinator can take some time to stop their services. No other services for the applications associated with Tachyon need to be stopped. WarningDo not stop or disable the Tachyon website or application pools. The installer needs them to be active in order to complete all installation tasks. |
4 | Close all active connections to the Tachyon databases. | To avoid Known issues when upgrading, you must ensure there are no active connections to the databases. You can use the following SQL script to identify which programs have active connections to the Tachyon databases. SELECT DB_NAME(dbid) as [database], loginame, hostname, program_name FROM sys.sysprocesses WHERE DB_NAME(dbid) LIKE 'Tachyon%' AND program_name LIKE 'Tachyon%' ORDER BY DB_NAME(dbid), loginame, hostname, program_name; With the Tachyon services stopped, any open connections to the database, such as Tachyon Consumer and Tachyon Portal, should not cause the upgrade to fail and can be safely ignored. |
5 | Backup the databases. | If you use Tachyon Setup to perform the upgrade, it backs up the following databases:
The following notes apply to the Responses database and whether you would need to create a backup of that database too: NoteBacking up the Tachyon Responses database is not usually needed, unless there are instruction responses that you need to keep. Tachyon responses are not permanently held data and will naturally expire according to the settings specified when an instruction was run, typically in hours or possibly days. If in doubt, there is no harm in backing up the Tachyon Responses database as well. |
6 | Make a copy of the Tachyon Server installation folder. | The installation folder contains the following non-default files:
|
7 | Install Tachyon Server. | Install Tachyon Server using the same configuration as before. Do not drop the databases. Please refer to Tachyon Setup for more details. |
8 | Post-install tasks. | Repeat any Tachyon Server post-installation tasks that are relevant for an upgrade installation and are not performed automatically by Tachyon Setup. |
9 | Customizations. | Re-instate non-default settings.
|
10 | Verify. | See Verifying page. |
After upgrading to Tachyon Platform
All versions
Verify the installation - see Verifying page.
After upgrading, you should perform a sync for all configured Connectors, followed by the Basic Inventory Consolidation report.
After upgrading from Tachyon Platform 8.0 or earlier
Tachyon Platform 8.1 (and later) no longer requires SQL Analysis Services (SSAS) for Tachyon Experience.
The following points should be considered if you have upgraded from Tachyon 8.0 or earlier version, and you previously used Tachyon Experience.
You can delete the TachyonExperience database from your SSAS instance
If you are not using Patch Success, you can decommission your SSAS instance - Patch Success uses the SLA-BI database on the SSAS instance
Please review Device Deduplication page. Deduplication is basically the same as before, but has some minor changes because the Experience Cube no longer exists.
After upgrading from Tachyon Platform 5.0 or earlier
Tachyon Platform 5.1 (and later) uses UTC for Schedules.
The following points should be considered if you have upgraded from Tachyon 5.0 or earlier version.
If you have previously configured any Schedules for Instructions, these will be converted to using UTC time. You will need to revisit these to ensure the time you want the Schedules to run is still correctly configured
If you have previously configured any Schedules for Tachyon or Configuration Manager Connector syncs, these will need to be deleted and re-created - as the sync process for both of these types of connector has been redefined. Please refer to Tachyon connector and System Center Configuration Manager connector for more details.
Upgrading and updating Instructions
Tachyon Instructions are designed as far as possible to be backwards compatible, but as a general rule we recommend that you update your Tachyon Product Packs to the latest version so that you can gain the benefit of newer features.
When upgrading you should be able to safely keep your existing Instructions. We recommend that newer versions of Instructions are verified in a test environment to ensure that they still behave as expected before updating in your production environment.
Note
An instruction is not upgraded if it is the same version, or is currently in use. You will be notified if any instructions are not upgraded because they are in use. You can upload the product pack again later, after the instruction has completed, or cancelled.
Your license should retain any code signing certificates you may have registered. This means your custom instructions should continue to be licensed as normal following an upgrade of Tachyon. You may want to check the Writing instructions in the TachyonSDK pages to check for any changes to the SCALE language.