Summary

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 latest versions of products that previously used it: Nomad 7.1 & 8.0, AppClarity 7.0, 7.1 & 8.0, 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 that 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:

For upgrading clients please read below first, then refer to 1E Client 8.0 - Upgrading to 1E Client.

On this page:

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 to Tachyon Platform 8.0.

VersionFeatures
Tachyon Platform 5.0, 5.1Real-time and inventory features. Applications: Explorer, Guaranteed State, Patch Success, Application Migration, AppClarity, Experience, and ActiveEfficiency.
Tachyon Platform 5.2Real-time and inventory features. Applications: Explorer, Guaranteed State, Patch Success, Application Migration, AppClarity, Experience, and Nomad.

Tachyon Platform 8.0 includes real-time and inventory features. Applications: Explorer, 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 Tachyon Portal.   

Upgrading from older versions

If you need to upgrade to Tachyon Platform 8.0 from SLA Platform 3.3, Tachyon 3.3, or Tachyon 4.x, then you can use the same process described here. However, 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

  1. Upgrade server hardware as required - please refer to Server sizing
  2. Run Tachyon Setup on the Tachyon Master Stack server to upgrade to Tachyon Platform
  3. Run Tachyon Setup on remote Tachyon Response Stack servers (if used)
  4. Verify existing clients
  5. Run Tachyon Setup on remote Tachyon DMZ Server (if used)
  6. Verify existing Internet based clients
  7. Upgrade existing product packs, and install new ones
  8. Deploy new 1E Client to devices (with Tachyon enabled) and verify
  9. Review Role name changes and rationalize your existing roles if necessary.

Role name changes

For a full list of role names, please refer to:

  • Roles and Securables reference page, which contains a copy of the notes below, details about renamed roles, and roles that are recommended to replace the ones that have been retired
  • Roles page, which contains guidance on how to configure custom roles

The upgrade process makes the following changes:

  1. New roles are created, if they do not exist already:

    New system roles

    • Group Administrator
    • Guaranteed State Policy Assigner
    • Installer
    • Tachyon System

    New Custom roles

    • Experience Administrator
    • Experience Engagement Assigner
    • Patch Success Administrator


  2. The Tachyon user doing the upgrade is automatically assigned to the Installer role. The user is also unassigned from the following roles, if assigned before the upgrade:

    • Applications Administrators
    • Consumer Administrators
    • Event Subscription Administrators
    • Instruction Set Administrators
    • Permissions Administrators


  3. Tachyon users associated with the NT AUTHORITY/NETWORK SERVICE and machine accounts, are assigned to the Tachyon System role. These users will also be unassigned from the following roles, if assigned before the upgrade:

    • Applications Administrators
    • Consumer Viewers
    • Engagement Administrator
    • Management Group Sync Initiators
    • Offloaders
    • Permissions Viewers
    • Survey Administrators


  4. Several old roles are renamed
    1. Some are renamed from plural to singular, for example if the  Nomad Administrators role exists it is renamed to Nomad Administrator 
    2. An exception is in the unlikely event that the Nomad Admins role exists, it is renamed to Nomad Administrator unless that role already exists, in which case it is renamed to Nomad Administrators instead
    3. Global Questioner, Global Actioner, Global Viewer, and Global Approver roles have been renamed with Global... replaced by All instructions...
    4. Inventory Viewers, Experience Viewers, Patch Success Viewers, have been renamed with ...Viewers changed to ...User

      System roles renamed from

      • Global Actioners
      • Global Administrators
      • Global Approvers
      • Global Questioners
      • Global Viewers
      • Guaranteed State Administrators
      • Guaranteed State Viewers
      • Inventory Administrators
      • Inventory Viewers
      • Survey Administrators
      • Survey Viewers

      System roles renamed to

      • All Instructions Actioner
      • Full Administrator
      • All Instructions Approver
      • All Instructions Questioner
      • All Instructions Viewer
      • Guaranteed State Administrator
      • Guaranteed State User
      • Inventory Administrator
      • Inventory User
      • Experience Engagement Administrator *
      • Experience Engagement Viewer *

      * These roles are retired, and will only be kept if a user or group is assigned to it.

      Custom roles renamed from

      • AppClarity Administrators
      • Application Migration Administrators
      • Compliance Administrators
      • Compliance Viewers
      • Entitlement Administrators
      • Experience Viewers
      • Nomad Administrators
      • Patch Success Viewers
      • Reclaim Administrators
      • Reclaim Viewers


      Custom roles renamed to

      • AppClarity Administrator
      • Application Migration Administrator
      • Compliance Administrator
      • Compliance Viewer
      • Entitlement Administrator
      • Experience Viewer
      • Nomad Administrator
      • Patch Success User
      • Reclaim Administrator
      • Reclaim Viewer


  5. Other system and custom roles are deleted. A role is kept only if it is (a) on the list of roles to be kept, or (b) the role has a user or group assigned to it

    System roles that are kept

    • All Instructions Actioner
    • All Instructions Approver
    • All Instructions Questioner
    • All Instructions Viewer
    • Full Administrator
    • Group Administrator
    • Guaranteed State Administrator
    • Guaranteed State Policy Assigner
    • Guaranteed State User
    • Installer
    • Inventory Administrator
    • Inventory User
    • Tachyon System

    Custom roles that are kept

    • 1E ITSM Connect Actioner
    • AppClarity Administrator
    • Application Migration Administrator
    • Compliance Administrator
    • Compliance Viewer
    • Entitlement Administrator
    • Experience Administrator
    • Experience Engagement Assigner
    • Experience User
    • Nomad Administrator
    • Patch Success Administrator
    • Patch Success User
    • Reclaim Administrator
    • Reclaim Viewer

    System roles that have been retired

    • 1E Client Deployment Administrators
    • 1E Client Installer Administrators
    • Applications Administrators
    • Component Administrators
    • Connector Administrators
    • Consumer Administrators
    • Consumer Viewers
    • Custom Properties Administrators
    • Event Subscription Administrators
    • Event Subscription Viewers
    • Infrastructure Administrators
    • Instruction Set Administrators
    • Log Viewers
    • Management Group Administrators
    • Management Group Sync Initiators
    • Offloaders
    • Permissions Administrators
    • Permissions Viewers
    • Policy Administrators
    • Provider Configuration Administrators
    • Schedule Administrators
    • Survey Administrators (Experience Engagement Administrator)
    • Survey Viewers (Experience Engagement Viewer)
    • VDI Administrators

    Custom roles that have been retired

    • Any custom role created by Tachyon administrators 

    A retired role is kept if it has a user or group assigned to it.


Role names

Tachyon Platform 5.2 onwards no longer allows the use of dots in role names, for example Questioners.Core, and roles will no longer work after an upgrade. Therefore, please review your custom role names before upgrading.

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.

Master Stack

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

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

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

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

DMZ Server

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

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

Response Stack

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

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

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

Single DNS Name

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

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

Multiple client-facing DNS Names

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

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

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

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

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

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

HTTP binding

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

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

HTTPS binding

Required. This is the main binding.

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

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

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

Alternate HTTPS binding

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

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

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

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

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

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

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

Internal DNS Names

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

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

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

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


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

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

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

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.

In-place upgrade of ActiveEfficiency Server for Nomad

This scenario is for upgrading a server that has ActiveEfficiency Server installed and used by Nomad. If ActiveEfficiency is also being used for Shopping then please also read In-place upgrade of ActiveEfficiency Server for Shopping.

Tachyon Setup will do the following automatically, but only if your Tachyon license includes Nomad, and you choose to install Nomad, and a local installation of ActiveEfficiency Server is detected.

  • replace ActiveEfficiency Server with Content Distribution to support to new Nomad clients
  • create a virtual directory in the Tachyon website and use HTTP redirection to support legacy Nomad clients
  • rename the ActiveEfficiency database as ContentDistribution if it exists on the SQL Server instance you selected for the ContentDistribution database (the database is renamed, but the database mdf and ldf filenames are not changed) 

The last point means ActiveEfficiency data will be retained in the ContentDistribution database, to provide the following:

  • Existing pre-cache jobs, and paused collections, are migrated so they are shared by old and new Nomad clients, and can be managed by upgraded installations of the Nomad Configuration Manager Console Extensions
  • Locations and Single-site content registrations are not migrated, but retained in legacy database tables so they continue to be used by legacy Nomad clients - content registrations for new Nomad clients are created in new database tables, so that legacy and new clients function independently.

The ActiveEfficiency database will be retained, and no data migrated, if it is on a different SQL Server instance than the one you specified for your ContentDistribution database. To automatically migrate data during upgrade, you will need to copy the ActiveEfficiency database to the new location, and reconfigure ActiveEfficiency Server to use the copied database. Alternatively, you can Manually migrate data as described below.

If the installation of Content Distribution fails for whatever reason, the database changes are rolled back.

Although ActiveEfficiency Server is replaced by Content Distribution, the Nomad client in 1E Client 5.2 (and later) does not connect directly to it. Instead, it connects to the same Tachyon Switch and Background Channel as the Tachyon client - the 5.2 and later versions of the Background Channel contain a reverse proxy which forwards API requests to Content Distribution. The Tachyon Switch and Background Channel may be on the same server as the Tachyon Master stack, or on a remote Response Stack. This means any remote Tachyon Response Stacks or DMZ Server (if used) must be upgraded also, before your Tachyon infrastructure can support new Nomad clients.

When upgrading Nomad clients, the new Nomad clients will no longer require an HTTP connection to the server that previously hosted ActiveEfficiency Server. However, if you are upgrading from a Tachyon or SLA server, then other 1E software (Application Migration and AppClarity Software Reclaimer) may still use HTTP to connect to SLA services on the server.

If you are currently using Nomad with ActiveEfficiency, you must upgrade both Nomad clients and ActiveEfficiency. You should only upgrade to Tachyon Platform 8.0 if you are prepared to upgrade Nomad clients to 1E Client 8.0 (with Tachyon and Nomad clients enabled) and replace ActiveEfficiency with Nomad and Content Distribution on Tachyon Platform.

Steps for in-place upgrade of ActiveEfficiency

  1. Review your requirements to determine which features you need of 1E Client and Tachyon Platform, please refer to Design ConsiderationsRequirements and Preparation pages
  2. Upgrade your server hardware as required- please refer to Server sizing
  3. Reconfigure Shopping Central (if used)
  4. Uninstall ActiveEfficiency Scout (if used) and disable associated Windows Task Scheduler job(s)
  5. Run Tachyon Setup on the ActiveEfficiency server to upgrade it to Tachyon Platform - please refer to Tachyon Setup
  6. Run Tachyon Setup on remote Tachyon Response Stack servers (if used) - please refer to Tachyon Setup
  7. Verify existing clients, to confirm Tachyon continues to function as before, with Nomad clients using HTTP redirection as described above
  8. Run Tachyon Setup on remote Tachyon DMZ Server (if used) - please refer to Implementing a Tachyon DMZ Server
  9. Verify existing Internet based clients
  10. Deploy new 1E Client to some test devices (with Tachyon and Nomad client enabled)
  11. Verify the test devices
  12. Upgrade Nomad tools - please refer to Nomad 8.0 - Upgrading Nomad
    1. Upgrade Nomad Admin Tools and server components
    2. Update OS Deployment Task Sequence actions to use the Tachyon Platform
    3. Review Automatically migrated data and configure Nomad Sites
  13. Deploy new 1E Client to remaining devices.

Do not reinstall ActiveEfficiency on the Tachyon Platform server.

Automatically migrated data

As stated above, the upgrade of ActiveEfficiency Server to Tachyon Platform automatically migrates details of pre-cache jobs, and paused collections, so they can be managed by upgraded installations of the Nomad Configuration Manager Console Extensions. You can review these in the Nomad app.

Locations, Single-site data, and content registrations are not migrated, but are retained in legacy database tables so they continue to be used by legacy Nomad clients. This data is not shared with new clients, so that legacy and new clients function independently. New clients will re-register their content automatically up to 24 hours later, or can be forced by using the NomadBranch command-line parameter -cdssync as described in NomadBranch.exe command-line switches. Old and new clients will perform master elections and peer-share content if they are the same subnet, but they will only use SSD with their own set of clients.

You will continue to maintain Nomad Sites (previously known as Locations) using one of the new versions of the example PowerShell scripts provided with the Nomad Admin Tools. Alternatively, you can use the examples to modify your existing script to use Content Distribution instead of ActiveEfficiency.

Side-by-side upgrade of ActiveEfficiency Server for Nomad

This scenario is for an existing Nomad and ActiveEfficiency installation, where Tachyon Platform is on a different server, either newly installed or upgraded from on earlier version of SLA Platform or Tachyon. The old ActiveEfficiency Server is eventually decommissioned. There is no requirement for HTTP redirection on the Tachyon server, because old Nomad clients will continue to use the ActiveEfficiency server, and new Nomad clients will use Content Distribution on the upgraded Tachyon Platform. Each set of clients functions independently. Some data is manually migrated from the ActiveEfficiency server, as described below.

If your Tachyon license includes Nomad, and you choose to install Nomad, and a local installation of ActiveEfficiency Server is detected, then you are doing an In-place upgrade of ActiveEfficiency Server for Nomad.

If a local installation of ActiveEfficiency Server is not detected, the ActiveEfficiency database is retained even if it is on the same SQL instance you specified for the ContentDistribution database. 

Steps for side-by-side upgrade of ActiveEfficiency

  1. Review your requirements to determine which features you need of 1E Client and Tachyon Platform, please refer to Design ConsiderationsRequirements, and Preparation pages
  2. Upgrade your server hardware as required- please refer to Server sizing
  3. Run Tachyon Setup on the existing SLA Platform or Tachyon server to upgrade it to Tachyon Platform - please refer to Tachyon Setup 
  4. Run Tachyon Setup on remote Tachyon Response Stack servers (if used) - please refer to Tachyon Setup
  5. Verify existing clients (if upgrading SLA Platform or Tachyon)
  6. Run Tachyon Setup on remote Tachyon DMZ Server (if used) - please refer to Implementing a Tachyon DMZ Server
  7. Verify existing Internet based clients (if upgrading Tachyon)
  8. Deploy new 1E Client to some test devices (with Tachyon and Nomad client enabled)
  9. Verify the test devices
  10. Upgrade Nomad Admin Tools and server components - please refer to Nomad 8.0 - Upgrading Nomad
    1. Upgrade Nomad Admin Tools and server components
    2. Update OS Deployment Task Sequence actions to use the Tachyon Platform
    3. Manually migrate data from ActiveEfficiency Server
    4. Configure Nomad Sites
  11. Deploy new 1E Client to remaining devices
  12. When all Nomad clients have been upgraded, then you can decommission the old ActiveEfficiency Server (unless you need to retain it for Shopping). 

Manually migrate data

Use the following migration scripts to manually migrate sites, pre-cache jobs, and paused collections, from ActiveEfficiency, so they can be managed by upgraded installations of the Nomad Configuration Manager Console Extensions. After migration, you can review these in the Nomad app.

Locations, Single-site data, and content registrations are not migrated, but are copied to legacy database tables for reference only. This data is not shared with new clients, so that legacy and new clients function independently. New clients will re-register their content automatically up to 24 hours later, or can be forced by using the NomadBranch command-line parameter -cdssync as described in NomadBranch.exe command-line switches. Old and new clients will perform master elections and peer-share content if they are the same subnet, but they will only use SSD with their own set of clients.

You will maintain Nomad Sites (previously known as Locations) using the one of the new versions of the example PowerShell scripts provided with the Nomad Admin Tools. Alternatively, you can use the examples to modify your existing script to use Content Distribution instead of ActiveEfficiency.

You may continue to maintain Locations in ActiveEfficiency as before, to continue supporting old clients.

Click here to download - AE-CD Data Migration Scripts.zip

  1. ExportData.ps1 - run on any computer that has read access to the ActiveEfficiency database
  2. CreateTables.sql - run on the SQL Server instance that hosts the ContentDistribution database created by Tachyon Setup
  3. ImportData.ps1 - run on any computer that has write access to the ContentDistribution database.

Prerequisites

  • The ability to run PowerShell scripts and SQL script
  • A SQL Login on each SQL Server instance for the user running the scripts
  • db_datareader rights on the ActiveEfficiency database
  • db_datawriter rights on the ContentDistribution database

Before running the scripts you will need to prevent clients, administrators, and scheduled jobs from updating ActiveEfficiency and Nomad.

  1. Stop IIS on the Tachyon Master Stack server (where Content Distribution is installed)
    1. Open command prompt in administrator mode and run iisreset /stop
  2. Stop IIS on the server where ActiveEfficiency Server is installed
    1. Open command prompt in administrator mode and run iisreset /stop
  3. Temporarily disable any Task Scheduler jobs related to ActiveEfficiency
    1. From the Start screen, start typing Task Scheduler then click on Task Scheduler in the search results
    2. Expand Task Scheduler Library → ActiveEfficiency
    3. Right-click on each job and select Disable
  4. If you have any custom jobs to run import scripts for Sites and Subnets then also disable these temporarily.

Create Tables

Open SQL Management Studio and connect to ContentDistribution database. Execute SQL script CreateTables.sql. This will create all the required legacy tables in the ContentDistribution database.

This script only needs to be executed once.

Export Data

Run the ExportData.ps1 script in a PowerShell admin command prompt using a command line similar to below.

.\ExportData.ps1 -AEServerName "AEServer" -AEDBName "ActiveEfficiency" -CDServerName "CDServer" -CDDBName "ContentDistribution" -folderPath "C:\migration" -logsPath "C:\migration\logs"

This command will create a series of CSV files that we will later import into the ContentDistribution database.

Import Data

Run the ImportData.ps1 script in a PowerShell admin command prompt using a command line similar to below.

.\importData.ps1 -CDServerName "CDServer" -CDDBName "ContentDistribution" -folderPath "C:\migration" -logsPath "C:\migration\logs"

This command will populate the tables from the CSV files exported earlier.

Restart IIS

  1. Restart IIS on the ActiveEfficiency Server and Tachyon Master Stack server (where Content Distribution is installed)
    1. Open command prompt in administrator mode and run iisreset /start
  2. Enable the Task Scheduler jobs again on the ActievEfficiency Server

Script parameters

ParameterDescription
AEServerNameName of the SQL Server hosting ActiveEfficiency database. If the server is not running on the default instance, enter the server name and instance name separated by backslash, for example DBServer\DB
AEDBNameName of the ActiveEfficiency database.
CDServerNameName of the server hosting ContentDistribution database. If the sever is not running on the default instance, enter the server name and instance name separated by backslash, for example DBServer\DB
CDDBNameName of the ContentDistribution database.
folderPathFolder location to save CSV files. If the path doesn't exist, it will be created by the script. 
logsPathFolder location to save log files. If the path doesn't exist, it will be created by the script. 

In-place upgrade of ActiveEfficiency Server for Shopping

This scenario is for upgrading a server that has ActiveEfficiency Server installed and used by 1E Shopping versions prior to Shopping 6.1. If ActiveEfficiency is also being used for Nomad then please also read In-place upgrade of ActiveEfficiency Server for Nomad.

If your installation of ActiveEfficiency is being used by 1E Shopping, then before you replace ActiveEfficiency with Content Distribution, you will need to do one of the following:

  • upgrade to Shopping 6.1 - this version does not use ActiveEfficiency
  • reconfigure your existing Shopping 6.0 server to synchronize directly with Configuration Manager - this method of synchronization is provided out-of-the-box in Shopping 6.1 onwards - to do this, please refer to the steps below 
  • install another instance of ActiveEfficiency Server and Scout, and reconfigure your existing Shopping server to use that - this process is not described here

Shopping is not a Tachyon Platform application, and has no direct dependency on it, therefore it is not affected by Tachyon Setup, other than ActiveEfficiency being removed. Whilst Shopping has no direct dependency on Tachyon Platform, it can optionally integrate with Application Migration 8.0 which is a Tachyon application. The Shopping/WSA client is a module of the 1E Client. If this is interesting to you please refer to Shopping 6.1 - Integrating with Application Migration.

Reconfigure Shopping to synchronize directly with Configuration Manager

The process is for Shopping 6.0 only.

Execute the following SQL script on the Shopping database, then restart the Shopping Central service. A few minutes later, the Central service will perform its usual synchronization processes with AD, and also synchronize with CM. You can monitor this process in C:\ProgramData\1E\ShoppingCentral\ShoppingCentral.log

The script changes preference settings for Shopping 6.0 - Shopping Admin Console settings: Central Service as shown in the table opposite. It changes the description of the sync interval, it does not change its value, which is 1 day by default. If you change the value later it should be set to longer than the time it takes to complete all the syncs. You should not need to change the value of the sync interval because the SCCM sync should be approximately the same as your current ActiveEfficiency Scout sync.

Click here to download - ReplaceActiveEfficiencySyncWithConfigMgrSync.sql

 ReplaceActiveEfficiencySyncWithConfigMgrSync.sql Expand source...

-- Disclaimer:
-- Your use of this script is at your sole risk. This script is provided "as-is", without any warranty,
-- whether express or implied, of accuracy, completeness, fitness for a particular purpose, title or
-- non-infringement, and is not supported or guaranteed by 1E. 1E shall not be liable for any damages
-- you may sustain by using this script, whether direct, indirect, special, incidental or consequential,
-- even if it has been advised of the possibility of such damages.

UPDATE dbo.tb_Preference
SET
Description = 'Sets the interval for synchronizing the members in Computer Category groups held in the Shopping database with Active Directory. Also used for the ConfigMgr, Intune Machine sync and the ConfigMgr, Intune user sync. The value for the interval uses the units defined in the Active Directory Sync Units parameter.'
WHERE
preferencename = 'Users and Machines, AD Sync Interval'
GO

UPDATE dbo.tb_Preference
SET
Description = 'The unit is used by the AD, ConfigMgr, Intune Machine and User Sync Interval setting. This may be set to one of the following values: Days, Hours or Minutes.'
WHERE
preferencename = 'Users and Machines, AD Sync Units'
GO

UPDATE dbo.tb_Preference
SET
PreferenceValue = 'False'
WHERE
preferencename = 'Sync Machines and Users From Active Efficiency'
GO

UPDATE dbo.tb_Preference
SET
Hidden = 1
WHERE
preferencename = 'Sync Machines From Old Sccm'
GO

UPDATE dbo.tb_Preference
SET
Hidden = 1
WHERE
preferencename = 'ActiveEfficiency ServerName'
GO

Preference nameChange made by the SQL script
Users and Machines, AD Sync IntervalChange description
Users and Machines, AD Sync UnitsChange description
Sync Machines and Users From Active EfficiencySet to 'False' (enables sync from SCCM instead)
Sync Machines From Old SccmHide as no longer required
ActiveEfficiency ServerNameHide as no longer required

Preparing for upgrade

Backup first!

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

  • TachyonMaster database

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

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

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

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

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

Upgrading to Tachyon Platform

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 5.x to Tachyon Platform 8.0 and keeping 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 below to Changing the Platform configuration when re-installing or upgrading.

RefStepNotes
1

Ensure you have prerequisites ready for installation of the new version.

Review Known Issues for Upgrades.

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 Tachyon Server configuration when re-installing 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 Tachyon 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 configuration 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.

If you are upgrading from Tachyon Platform 5.0 or earlier version to Tachyon Platform 8.0, you will need a new license, because of the format change. Please contact your 1E Sales account manager for license inquires. 

If you are upgrading from SLA Platform 3.3, Tachyon 3.3, or Tachyon 4.x, there are additional notes, which can be found in the  Tachyon Platform 5.2 - Upgrading to Tachyon Platform pages.

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.

  1. Stop or uninstall external or third-party Consumers (if any)
  2. Stop the Tachyon services
    • 1E Tachyon Switch Host
    • 1E Tachyon Coordinator

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 shutdown the services if you do not stop them manually. Stopping them manually gives you a greater control about when they are stopped. The services will be restarted automatically after the upgrade.

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

Do not stop or disable the Tachyon website or application pools. The installer needs them to be active in order to complete all installation tasks.

4Close all active connections to the Tachyon databases.

To avoid a particular known issue 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.

5Backup the databases.

If you use Tachyon Setup to perform the upgrade, it backs up the following databases:

  • TachyonMaster
  • TachyonExperience (if installed)
  • SLA-Data
  • SLA-Shared
  • SLA-Integrate
  • SLA-BI
  • ContentDistribution (if installed)
  • ActiveEfficiency (if installed)
  • 1ECatalog

The following notes apply to the Responses database and whether you would need to create a backup of that database too:

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.

6Make a copy of the Tachyon Server installation folder.

The installation folder contains the following non-default files:

  • Switch certificate files in the SSL folder, these are required during the upgrade and should be copied to the directory with the TachyonServer.msi.
  • Configuration files for the website, web applications, services and Switch (*.config files)
  • Other customizations
  • Content in the Background folders (these are the Content and Updates folder in %ALLUSERSPROFILE%\1E\Tachyon).
7Install Tachyon Server.

Install Tachyon Server using the same configuration as before. Do not drop the databases.

Please refer to Tachyon Setup for more details.

8Post-install tasks.

Repeat any Tachyon Server post-installation tasks that are relevant for an upgrade installation and are not performed automatically by Tachyon Setup.

9Customizations.

Re-instate non-default settings.

  • Configuration files for the website, web applications, services and Switch (*.config files)

    Tachyon Setup will automatically backup and restore any entries in the .config files that it modifies during installation. Do not simply replace config files. Instead, compare the old and new versions and consider which changes can or need to be re-instated. In some cases, new versions may contain fixes for workarounds included in the old files. Please contact 1E if you have any difficulties.

  • Other customizations

    The Tachyon Setup installer will backup and restore customized mail headers.

  • Content in the Background folders (these are the Content and Updates folder in %ALLUSERSPROFILE%\1E\Tachyon)
10Verify.See Verifying page.

After upgrading to Tachyon Platform

After upgrading, you should perform a sync for all configured Connectors followed by the Basic Inventory Consolidation report. 

The following points should be considered after upgrading from Tachyon 5.0 to Tachyon Platform 8.0:

  • If you have previously configured any Schedules 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.

You do not need to make any changes when upgrading from Tachyon Platform 5.1 (and later) because they already use UTC for Schedules.

Upgrading Instructions and Product Packs

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.

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 Tachyon 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 Tachyon Instructions in the Tachyon SDK pages to check for any changes to the Tachyon SCALE language.