securetransport 5.5 upgrade guide - docs.axway.com

My DocumentUpgrade Guide
Axway SecureTransport 5.5
No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.
This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.
Axway recognizes the rights of the holders of all trademarks used in its publications.
The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.
Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.
Revision history The following changes are added to the SecureTransport 5.5 Upgrade Guide:
SecureTransport version
Topics updated
l Upgrade SecureTransport on Windows on page 21 updated
l Upgrade SecureTransport on a UNIX-based platform on page 19 updated
l Post-upgrade tasks on page 26 updated
l Recover your previous SecureTransport installation on Windows on page 29 updated
5.5 October 2021 Update
l Upgrade paths on page 10 updated
l Pre-upgrade tasks on page 14 updated
5.5 April 2021 Update Upgrade steps for Oracle databases on page 25 added
5.5 March 2021 Update
5.5 February 2021 Update
l New topic added: Recover your previous SecureTransport installation on Unix-like systems on page 27
l Recover your previous SecureTransport installation on Windows on page 29 updated
l Back up the existing installation before upgrading on page 16 updated
5.5 December 2020 Update
Recover your previous SecureTransport installation on Windows on page 29 updated
5.5 October 2020 Update
Post-upgrade tasks on page 26 updated
5.5 June 2020 Update Upgrade paths on page 10 updated for clarity and consistency
Axway SecureTransport 5.5 Upgrade Guide 3
Contents
Preface 6 Who should read this guide 6 Available documentation 6 Get more help 7 Training 8
1 Upgrade planning and preparation 9 Should I upgrade? 9 Minimum version requirement 9 Upgrade methods 9 Product downtime considerations 10 Acquire a license 10 Download the upgrade pack 10 Upgrade paths 10
2 Pre-upgrade tasks 14 Back up the existing installation before upgrading 16 Procedure for Unix-like systems 16 Procedure for Windows 17
3 Upgrade procedures 19 Upgrade SecureTransport on a UNIX-based platform 19 Upgrade SecureTransport on Windows 21 Upgrade from SecureTransport 5.4 using the console 21 Upgrade from SecureTransport 5.4 using the GUI 23
Upgrade in Streaming, Standard Cluster, and Enterprise Cluster environments 24 Streaming 24 Standard Cluster 24 Enterprise Cluster 25
Upgrade steps for Oracle databases 25 Export data from old Audit log and import it to the new one 25
4 Post-upgrade tasks 26
4 Recover your previous SecureTransport installation on Unix-like systems 27
5 Recover your previous SecureTransport installation on Windows 29
5 Update Amazon S3 and SharePoint transfer sites 31
5 ICAP legacy system import and upgrade 33
6 Migrate Windows Server 2012 R2 to a later OS version 36 Standalone installation with embedded database 36 Prerequisites 37 Migration procedure 37
Standalone with External Database 40 Prerequisites 40 Migration procedure 40
Standard Cluster environment with embedded database 42 Prerequisites 42 Migration procedure 42
Enterprise Cluster environment with external database 46 Prerequisites 46 Migration procedure 46
Edge installation with Embedded Database 48 Prerequisites 48 Migration procedure 49
Edge installation with Embedded Database when part of a synchronized cluster 51 Prerequisites 51 Migration procedure 52
Preface
This guide provides instructions for upgrading the SecureTransport software and provides information on the following topics:
l Upgrade tasks and upgrade prerequisites
l Upgrading SecureTransport from previous versions of SecureTransport
These tasks are covered for all supported platforms: Axway Appliances, IBM AIX, Microsoft Windows, Oracle Linux, Red Hat Enterprise Linux (RHEL), and SUSE Linux Enterprise Server (SLES).
This chapter provides general information about SecureTransport, a description of the documentation set, and contact information for obtaining technical support for SecureTransport.
Who should read this guide This guide is intended for system administrators who upgrade SecureTransport. As a person responsible for upgrading SecureTransport, you must have a working knowledge of system platforms and networks used by your SecureTransport instances. You must have administrative privileges on the computers where you will upgrade SecureTransport and appropriate access to systems that SecureTransport depends on, such as an external database and file system. This guide is also intended for enterprise personnel involved in upgrading software and Axway Professional Services personnel. Familiarity with Axway products is recommended.
This guide presumes you have knowledge of:
l Your company’s business processes and practices
l Your company’s hardware, software, and IT policies
l The Internet, including use of a browser
Others who may find parts of this guide useful include network or systems administrators and other technical or business users.
Available documentation The following documentation is available for SecureTransport 5.5:
l SecureTransport Administrator's Guide – Describes how to use the SecureTransport Administration Tool to configure and administer your SecureTransport Server. The content of this guide is also available in the Administration Tool online help.
l SecureTransport Appliance Guide - provides the SecureTransport Appliance installation, configuration, and operation instructions. It also provides SecureTransport installation and upgrade instructions on Axway Appliances.
Preface
l SecureTransport Capacity Planning Guide – provides useful information when planning your production environment for SecureTransport.
l SecureTransport Containerized Deployment Guide – describes how to deploy SecureTransport as a Linux Container.
l SecureTransport Developer's Guide – provides descriptions and usage instructions for implementing custom pluggable components in SecureTransport.
l SecureTransport Getting Started Guide – explains the initial setup and configuration of SecureTransport using the SecureTransport Administrator setup interface.
l SecureTransport Installation Guide – provides instructions for installing and uninstalling SecureTransport on UNIX-based platforms and Microsoft Windows.
l SecureTransport on AWS Setup Guide – provides a detailed overview and detailed instructions for setting up SecureTransport in the Amazon Web Services (AWS) Virtual Private Cloud (VPC).
l SecureTransport on Azure Setup Guide – provides a detailed overview and detailed instructions for setting up SecureTransport in the Microsoft Azure portal.
l SecureTransport Upgrade Guide – provides instructions for upgrading SecureTransport on UNIX- based platforms and Microsoft Windows.
l SecureTransport Security Guide – provides security information necessary for the secure operation of the SecureTransport product.
l ST Web Client Configuration Guide - describes how to configure and customize the ST Web Client user interface.
l ST Web Client User Guide – describes how to use the ST Web Client for end users.
l SecureTransport Release Notes – contains information about new features and enhancements in the current version of SecureTransport, as well as a comprehensive list of fixes and known issues.
l SecureTransport Software Development Kit (SDK) – a set of software development tools and examples that allow extending SecureTransport by consuming and implementing available APIs.
l SecureTransport REST API documentation – the portal published API documentation derived from the API swagger documents. To access the administrator and the end-user API documentation, go to docs.axway.com/category/api.
Visit docs.axway.com to view or download documentation.
Get more help Go to Axway Support at support.axway.com to get technical support, download software, documentation and knowledgbase articles. The website requires login credentials and is for customers with active support contracts.
The following support services are available:
l Official documentation
l Information about supported platforms
l Access to your cases
When you contact Axway Support with a problem, be prepared to provide the following information for more efficient service:
l Product version and build number
l Database type and version
l Operating system type and version
l Service packs and patches applied
l Description of the sequence of actions and events that led to the problem
l Symptoms of the problem
l Text of any error or warning messages
l Description of any attempts you have made to fix the problem and the results
Training Axway offers training across the globe, including on-site instructor-led classes and self-paced online learning. For details, go to training.axway.com
If you are responsible for upgrading an existing SecureTransport installation to SecureTransport 5.5, read this section to help you plan your upgrade activities.
Should I upgrade? Before you upgrade, determine if upgrading is appropriate for your environment and production requirements:
l Review the SecureTransport Release Notes for:
o New features
o Fixed issues
o Known limitations
l Evaluate the effort required for this upgrade. You should consider:
o Length and impact of product down time
o Basic upgrade effort
o Specific actions that might be required due to incompatibilities or limitations. See Upgrade paths on page 10.
o Initial validation and non-regression testing
o Upgrading your different operating environments, for example, test, and preproduction
Minimum version requirement To upgrade directly to SecureTransport 5.5, you must have SecureTransport 5.4 with the latest patch installed. See Upgrade paths on page 10 for a complete list of supported upgrade paths.
Upgrade methods There is currently one method for upgrading to SecureTransport 5.5 from an earlier version:
l Apply an upgrade pack – When you apply the upgrade pack, the upgrade logic auto-detects and configures settings and prepares the upgraded installation for use without any additional configuration. This includes the upgrading of clustered implementations. For upgrade instructions using an upgrade pack, refer to Upgrade procedures on page 19.
1 Upgrade planning and preparation
See Upgrade paths on page 10 to learn about incompatibilities between earlier versions of SecureTransport and this version.
Product downtime considerations This section lists considerations and provides strategies for performing upgrades with the minimal disruption of your production processes.
Considerations:
l What scheduling constraints exist?
l How long will it take to check the upgrade results?
l How long will it take to roll back to the previous state if the upgrade fails?
Strategies to reduce downtime:
l Review the upgrade prerequisites. Refer to Pre-upgrade tasks on page 14.
l Upgrade during a low volume time period.
Acquire a license A new license is not required when upgrading SecureTransport .
Download the upgrade pack After reviewing Upgrade paths on page 10, go to the Axway support site and download the upgrade pack for your operating system.
Upgrade paths This section describes the upgrade paths and incompatibilities and between SecureTransport5.5 and:
l Other products that you may be using with previous versions.
l Earlier versions of SecureTransport.
The supported upgrade paths are:
Upgrade path
none 1. Remove ST 5.2.1 SP9
2. ST 5.3.0 GA (AP 6.7.1)
3. ST 5.3.0 Patch 14 (AP 6.7.1)
4. ST 5.3.1 GA (AP 7.0.1)
5. ST 5.3.3 GA (AP 7.0.1)
6. ST 5.3.6 GA (AP 7.1.1)
7. ST 5.4 GA (AP 7.1.1)
8. ST 5.4 latest cumulative patch (AP 7.2.0)
9. ST 5.5 GA (ST 5.5 Virtual Appliance)
ST 5.2.1 any SP up to SP8 (AP 6.7.0)
Upgrade to ST 5.2.1 SP 8 (AP 6.7.0)
1. ST 5.3.0 GA (AP 6.7.1)
2. ST 5.3.0 Patch 14 (AP 6.7.1)
3. ST 5.3.1 GA (AP 7.0.1)
4. ST 5.3.3 GA (AP 7.0.1)
5. ST 5.3.6 GA (AP 7.1.1)
6. ST 5.4 GA (AP 7.1.1)
ST 5.3.0 any patch level (AP 6.7.1)
Upgrade to ST 5.3.0 latest patch (AP 6.7.1)
1. ST 5.3.1 GA (AP 7.0.1)
2. ST 5.3.3 GA (AP 7.0.1)
3. ST 5.3.6 GA (AP 7.1.1)
4. ST 5.4 GA (AP 7.1.1)
SecureTransport version (Appliance Platform version)
Upgrade path
1. ST 5.3.3 GA (AP 7.0.1)
2. ST 5.3.6 GA (AP 7.1.1)
3. ST 5.4 GA (AP 7.1.1)
1. ST 5.3.6 GA (AP 7.1.1)
2. ST 5.4 GA (AP 7.1.1)
Upgrade to ST 5.3.5 RA latest patch (AP 7.0.3)
1. ST 5.3.6 GA (AP 7.1.1)
2. ST 5.4 GA (AP 7.1.1)
1. ST 5.4 GA (AP 7.1.1)
ST 5.4 any patch level (AP 7.1.1)
Upgrade to ST 5.4 latest cumulative patch (AP 7.2.0)
ST 5.5 GA (ST 5.5 Virtual Appliance)
Review the upgrade information for older SecureTransport versions in Axway Support at SecureTransport documentation. Upgrade from ST 5.2.1 SP 9 to 5.4 (and any version) is not possible, as it would result in data loss. In case of questions, contact Axway Global Support at support.axway.com.
Notes:
l For a complete list of supported software, refer to Axway and third-party software support in the in the SecureTransport Administrator's Guide.
l On upgrade to SecureTransport 5.5, ciphers are added to and removed from the existing cipher sets. For the SecureTransport 5.5 list of ciphers, refer to SecureTransport cipher suites in the SecureTransport Security Guide.
l After upgrade to SecureTransport 5.5, when a proxy is configured, direct connections from the SecureTransport Backend are not permitted even when the proxy is unreachable. To change the default behavior, set the Direct.Connection.When.Proxy.Down server configuration parameter to true. For information on changing server configuration parameters, refer to View and change server configuration parameters in the SecureTransport Administrator's Guide.
l In SecureTransport 5.3.3 there is a structural change of database tables related to File Tracking. The data related to file transfers made before upgrade, should be migrated to the new tables created after upgrade to SecureTransport 5.3.3 for them to be visible in File Tracking for SecureTransport 5.3.3 and above. If the migration is skipped, all the details related to the file transfers made before the upgrade will NOT be visible on the Administration Tool File Tracking page. For more information, refer to Migration of File Tracking entries after upgrade in the SecureTransport 5.4 Installation Guide.
2 Pre-upgrade tasks
l Review the SecureTransport Installation Guide to ensure your system meets all the pre- installation requirements and you have all the required information.
l Back up your existing SecureTransport installation. To back up your current SecureTransport deployment, follow a backup procedure applicable for your environment and make sure the backup is created at a time when all SecureTransport services are stopped. In the rare case of an upgrade procedure failure resulting in system instability of any kind, follow the upgrade recovery procedure. For more information, refer to Back up the existing installation before upgrading on page 16
o Security settings must also be backed up and reapplied after upgrade. The jdk.certpath.disabledAlgorithms and jdk.tls.disabledAlgorithms parameters in the [jre]/conf/security/java.security file must be backed up and reapplied.
o Transaction Manager rules and the <FILEDRIVEHOME>/brules/conf/brules.xml settings file must be backed and reapplied after upgrade.
o Backup the <FILEDRIVEHOME>/bin/start_* files. The modifications made to the scripts in <FILEDRIVEHOME>/bin/start_* are not preserved on upgrade. To avoid manually editing the start scripts after each update, do the following: before upgrading to 5.5, in the FILEDRIVEHOME/conf directory, create a file called STStartScriptsConfig and place in it the existing start scripts configuration. The format of the file should be as described in Advanced protocol server configuration. The content of the STStartScriptsConfig file is not overwritten on upgrade; the values set there are applied after each successful upgrade.
l If your SecureTransport installation uses an external database, you need to backup and upgrade the database before upgrading SecureTransport.
Note You MUST upgrade Oracle 12.1.x to version 12.2 or later before you upgrade SecureTransport.
Note The Microsoft SQL Server collation must be defined as case insensitive (SQL_ Latin1_General_CP1_CI_AS).
l SecureTransport requires at least 40 GB of available storage to upgrade. For an instance that uses an embedded database, more free space may be required, depending on the number and size of the data files.
l Make sure the port number for Tomcat JK2 is greater than 1024. (The default value is 8009.)
Check the following locations for the port numbers:
In <FILEDRIVEHOME>/tomcat/admin/conf/server.xml, find Connector port= and jmvRoute.
2 Pre-upgrade tasks
If the Tomcat JK2 port number shown is less than or equal to 1024, change all occurrences to a number greater than 1024.
l To ensure your previous version of SecureTransport is not running, execute the following command to stop all services:
<FILEDRIVEHOME>/bin/stop_all
l Check for leftover running processes and .pid files in the <FILEDRIVEHOME>/var/run folder.
l If you have made modifications to the start scripts and changed any parameter, including min/max memory, you should add those modifications to the <FILEDRIVEHOME>/conf/STStartScriptsConfig file before upgrading to SecureTransport 5.5. The content of the STStartScriptsConfig file is not modified during the upgrade, and the services will use the values set there when they automatically start after a successful upgrade.
l During a chained upgrade, remove the <AxwayHome>/Installer/xercesImpl- 2.6.2.jar file before launching the SecureTransport 5.5 upgrade.
l Move all folders and folders in the <FILEDRIVEHOME>/var/db/hist/* directory to outside the <FILEDRIVEHOME> path. The high volume of files in the history folders could significantly slow down the upgrade process.
l For instructions on how to upgrade systems with Account Retention or File Retention Add-on, refer to the Axway Support knowledge base.
For IBM AIX upgrade, also perform the following:
l Log onto the IBM AIX appliance as a superuser and execute the following commands:
no -o udp_recvspace=65000
no -o udp_sendspace=65000
For Windows upgrade, also perform the following:
l Make sure the Cygwin console and all Cygwin tools installed with your previous SecureTransport installation, including the Cygwin cron service, are closed. Check the Users tab in the Windows Task Manager to make sure no one else is using Cygwin. If necessary, close the Cygwin console and tools manually.
Caution If any Cygwin or Cygwin-environment related processes are running after all SecureTransport services have been stopped, they must be killed before starting the upgrade procedure. Failure to do so will result in a corrupted environment.
l Make sure that no folder in <FILEDRIVEHOME> or <FILEDRIVEHOME>\..\cygwin is in use or open in Windows Explorer or in a command window and that no file in those folders is in use or open in any application. Close Windows Explorer and any other application accessing the folders in question. Make sure no SecureTransport services, including Cygwin, are running.
2 Pre-upgrade tasks
l Make sure you have installed the Microsoft Visual C++ 2010 SP1 Redistributable Package (x64). Download the package here.
l While it is not recommended to have antivirus software running on the same deployment as SecureTransport, in case you are running as such, please make sure the antivirus software is stopped and disabled during the upgrade. Leaving the antivirus software running can cause the upgrade to fail.
Back up the existing installation before upgrading
Use your corporate backup solution or follow the procedures bellow to perform a backup of SecureTransport. Create the backup right before you upgrade. Do not install any software in the meantime between the backup and upgrade.
Procedure for Unix-like systems You can use the following procedure as a way to perform your backup on Unix-like systems.
1. Stop all the SecureTransport services.
2. Verify the all services are stopped by checking for running processes and .pid files in the <FILEDRIVEHOME>/var/run directory. In order to assure no processes are left running even in the rare case of missing files, check the process tree with the appropriate OS tools for running processes before proceeding.
3. Back up the SecureTransport directory by tarring the files or using another backup method. Name the backup archive SecureTransport.tar.
Your backup must include the following files:
l All files in <FILEDRIVEHOME>
l For root installation on Linux: the rc.stransportSecureTransport<XX> init script in /etc/rc.d/init.d and *stransportSecureTransport<XX> files in all rc<X>.d subdirectories
l For non-root installation running as a Linux service: the rc.stranport script in /etc/rc.d/init.d and the <xx>rc.stransport files in all rc<X>.d subdirectories. Skip this step, if you use a non-root installation that is not a Linux service.
l For root installation on AIX: the rc.stransportSecureTransport<XX> in the /etc directory
l For non-root installation running as service of AIX: the rc.stransport script in the /etc directory
2 Pre-upgrade tasks
l The files in the /etc directory that end with the installation name. (You can use the find /etc -name "*<installation name>*" -print command to find those files.) The result of this command may be empty if you are using non-root deployment, please proceed if this is the case.
l The /etc/synchronycomponents file for root installation, or /home/<user name>/.synchronycomponents for non-root installation.
l The SecureTransport crontab events that reside in the /var/spool/cron directory for Linux and in /var/spool/cron/crontabs for AIX. For example, for non-root installation, the events in the /var/spool/cron/<user name> file. This applies only when you upgrade from 5.4 to version 5.5. It does not apply when you're installing a 5.5 update.
l Back up the Axway Installer directory by tarring the files or using another backup method. Name the backup archive Axway Installer.tar.
4. If an external database is used, it must be backed up according to the database vendor's instructions.
Procedure for Windows You can use the following procedure as a way to perform your backup on Windows Server.
1. Stop all the SecureTransport services.
<FILEDRIVEHOME>\bin\stop_all
You can also open CMD as an administrator and run stop_all.
2. Verify the all services are stopped by checking for running processes and .pid files in the <FILEDRIVEHOME>\var\run directory. In order to assure no processes are left running even in the rare case of missing files, check the process tree with the appropriate OS tools for running processes before proceeding.
3. Back up Windows registry entries. Run regedit.exe.
a. Select each of the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Axway Software
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Axway_ Installer_4.8.0 SecureTransport01
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\cygwin_cron (Select only if you're upgrading from version 5.4 to 5.5. Do not select if you're installing a 5.5 update.)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AxwaySecureTransport*
where AxwaySecureTransport* represents all the registry entries that start with AxwaySecureTransport.
b. Right click each entry, select Export > Export Registry File, and save the registry
2 Pre-upgrade tasks
entry to a safe location.
c. When you are finished backing up the registry entries, exit regedit.
4. Back up files of the existing SecureTransport installation and installation information by copying the contents of the following directories, preserving the subdirectory structure, to a ZIP file or some other backup. Name the backup archive SecureTransport.zip.
C:\Axway\SecureTransport
5. Back up the Axway home directory. Name the backup archive Axway Installer.zip.
6. If an external database is used, it must be backed up according to the database vendor's instructions.
3 Upgrade procedures
This topic describes the upgrade procedures for SecureTransport 5.5.
The upgrade procedure will require downtime, so make sure you plan for it.
The following topics describe the upgrade procedures:
l Pre-upgrade tasks on page 14 - Lists the SecureTransport upgrade prerequisites.
l Upgrade SecureTransport on a UNIX-based platform on page 19 - Provides how-to instructions for upgrading SecureTransport on a UNIX-based platform or virtual appliance.
l Upgrade SecureTransport on Windows on page 21 - Provides how-to instructions for upgrading SecureTransport on Windows.
l Upgrade in Streaming, Standard Cluster, and Enterprise Cluster environments on page 24 - Provides how-to instructions for upgrading in Streaming, Standard Cluster, and EC environments.
l Post-upgrade tasks on page 26 - Provides cleanup and access instructions after you upgrade SecureTransport.
Upgrade SecureTransport on a UNIX-based platform
Note If you are using an external database, it must be upgraded to a supported version prior to upgrading SecureTransport to version 5.5 or a new instance of the respective database should be deployed and you should migrate the existing SecureTransport data to the new instance. Refer to the documentation for your database for the upgrade or migration procedure. If additional information is needed, contact your database vendor’s support.
For ROOT installation, run the upgrade with ROOT user. After the upgrade finishes all binaries (both SecureTransport and Axway Installer) should be owned by the ROOT user.
For NON-ROOT installation, run the upgrade with NON-ROOT user. Attempts to run the upgrade with root user will be successful and no error message will be returned. However after the upgrade the permissions on installation files will be wrong and your installation will be corrupt. Also, make sure that the non-root user has a created home folder with the proper permissions:
l useradd stuser
l mkdir /home/stuser (default)
l chown -R stuser: /home/stuser
Note If you are upgrading an Axway Appliance, refer to the SecureTransport Appliance Guide.
1. Log on with the user that owns SecureTransport services.
2. Download the upgrade pack for your operating system.
where the variables represent the following:
l <OS> is the operating system: aix (for IBM AIX) or linux (for RHEL and SUSE).
l <processor> is the type of processor running the operating system: power or x86- 64.
l <BuildNumber> is the actual build number listed in the installer executable file.
Note Do not place the binaries in the same folder where Axway Installer is installed
3. Copy it into a temporary directory and unzip it.
It contains two folders:
l UpgradeStep1 contains an update file for AxwayInstaller
l UpgradeStep2 contains an update file for SecureTransport
4. Navigate to the Axway Installer directory in your existing SecureTransport installation and run the following command to update the installer:
./update.sh -i <full path to the upgrade file in the UpgradeStep1 directory>
Note Do not run more than one instance of the SecureTransport installer on a system at one time. The upgrade fails when more than one instance is running.
5. Run the following command to update SecureTransport:
./update.sh -i <full path to the upgrade file in the
UpgradeStep2 directory>
The installer first checks to verify that your SecureTransport instance has the required 40 GB of free space available to complete the upgrade. If there is not enough space, it will stop and not let you continue. You will see a message showing you how much space is needed before you can attempt the upgrade again.
If you want to skip the free space check when upgrading to SecureTransport 5.5, use the -DskipRequiredSpaceCheck java argument as shown in the example:
./update.sh -javaargument "-DskipRequiredSpaceCheck=true" -i
<full path to the upgrade file in the UpgradeStep2
directory>>
Caution Oracle users, whose system privileges were granted through a role, should run the update.sh script with an additional argument:
./update.sh -javaargument "-DskipDBProcedure=true" -i <full
path to the upgrade file in the UpgradeStep2 directory>
When -javaargument "-DskipDBProcedure=true" is used, the UPDATES_DB_LOG table is not populated. If the argument is skipped or used with a value different than true, the upgrade will fail.
After the installation completes, all services except for TM will be started automatically. You need to restart the TM and enable all custom TM rules manually.
The Axway Installer log file called install.log is located in <AxwayHome>.
After you upgrade SecureTransport, complete the required post-upgrade tasks.
Upgrade SecureTransport on Windows If you are using an external database, it must be upgraded to a supported version prior to upgrading SecureTransport to version 5.5 or a new instance of the respective database should be deployed and you should migrate the existing SecureTransport data to the new instance. Refer to the documentation for your database for the upgrade or migration procedure. If additional information is needed, contact your database vendor’s support.
Oracle users whose system privileges were granted through a role can update SecureTransport to version 5.5 only using the console.
The following topics provide instructions for upgrading an existing SecureTransport installation:
l Upgrade from SecureTransport 5.4 using the console on page 21 - Provides how-to instructions for upgrading from SecureTransport 5.4 using the console.
l Upgrade from SecureTransport 5.4 using the GUI on page 23 - Provides how-to instructions for upgrading from SecureTransport 5.4 using the GUI.
l Recover your previous SecureTransport installation on Windows on page 29 - Provides how-to instructions for recovering your previous SecureTransport installation.
Upgrade from SecureTransport 5.4 using the console On Microsoft Windows using the console mode:
1. Execute the following command to stop all services:
stop_all
2. Verify that the Cygwin console and all Cygwin tools, including the Cygwin cron service, are closed.
It contains two folders:
l UpgradeStep1 contains an update file for AxwayInstaller
l UpgradeStep2 contains an update file for SecureTransport
4. Navigate to the Axway Installer directory from your existing SecureTransport installation and run the following command to update the installer:
update64.exe -i <full path to the update file in the UpgradeStep1
directory>
5. In the <AxwayHome> directory, delete the update64.exe file and rename "update64.exe.new" to "update64.exe".
6. Run the following command to install the SecureTransport update:
update64.exe -i <full path to the update file in the UpgradeStep2
directory>
The installer first checks to verify that your SecureTransport instance has the required 40 GB of free space available to complete the upgrade. If there is not enough space, it will stop and not let you continue. You will see a message showing you how much space is needed before you can attempt the upgrade again.
If you want to skip the free space check when upgrading to SecureTransport 5.5, use the -DskipRequiredSpaceCheck java argument as shown in the example:
update64.exe -javaargument "-DskipRequiredSpaceCheck=true" -i <full
path to the upgrade file in the UpgradeStep2 directory>
Caution Oracle users whose system privileges were granted through a role, should run the update command with an additional argument:
update64.exe -javaargument "-DskipDBProcedure=true" -i <full path to
the upgrade file in the UpgradeStep2 directory>
When -javaargument "-DskipDBProcedure=true" is used, the UPDATES_DB_LOG table is not populated. If the argument is skipped or used with a value different than true, the upgrade will fail.
After the installation completes, all services except for TM will be started automatically. You need to restart the TM and enable all custom TM rules manually.
The Axway Installer log file called install.log is located in <AxwayHome>.
After you upgrade SecureTransport, complete the required post-upgrade tasks.
Upgrade from SecureTransport 5.4 using the GUI For Microsoft Windows using GUI mode:
1. Execute the following command to stop all services:
stop_all
2. Verify that the Cygwin console and all Cygwin tools, including the Cygwin cron service, are closed.
3. Download the following upgrade package and unzip it.
SecureTransport_5.5_UP3-from-5.4_win-x86-64_<BuildNumber>.zip
4. Select Start > All Programs > Axway Software > Axway <installation_name> > Update.
The Axway Installer starts in update mode and displays the Welcome page.
5. Click Next.
6. On the Updates management page, click Select file.
7. Browse to select the update file in the UpgradeStep1 folder and click Open.
8. Click Next, then click Update to begin the update process.
The installer displays a confirmation window.
9. If you have stopped all SecureTransport processes, click Yes.
10. When the update is completed, click Finish.
11. Go to the Axway Installer directory, and delete the update64.exe file.
12. Rename "update64.exe.new" file to "update64.exe".
13. Run update64.exe.
14. Click Next.
15. Browse to select the update file in the UpgradeStep2 folder and click Open.
16. Click Next, then click Update, and again Next.
The Axway Installer starts updating SecureTransport to version 5.5.
17. When the update is completed, click Finish to exit the installer.
Note When the installer completes the installation, it will start all services except for TM. TM will need to be manually restarted. Also, all custom TM rules are disabled and need to be manually enabled.
The log file will be the <AxwayHome>/install.log of the Axway Installer.
This section describes the options for upgrading in Streaming, Standard Cluster, and Enterprise Cluster (EC) environments.
Note If you are using an external database, it must be upgraded to a supported version before upgrading SecureTransport to version 5.5 or a new instance of the respective database should be deployed and you should migrate the existing SecureTransport data to the new instance.
Note On upgrade from an older SecureTransport version with SQL Server edition different than Enterprise to 5.5, the database partitioning feature will not be used by SecureTransport.
Streaming In a streaming environment, stop all of the protocol servers and services on all of the SecureTransport Edges before you start upgrading. Update the SecureTransport Server (backend) first and then update the SecureTransport Edges. Once the upgrades are completed, restart all servers and edges.
Note Verify that an edge and server on different versions are never started together.
Standard Cluster In a Standard Cluster environment, stop all of the protocol servers and services on all of the nodes before you start updating.
For Standard Clusters the following two options for upgrade are supported:
l Option 1 (recommended)
o Stop the nodes and upgrade the nodes one at a time. After a node is upgraded, stop all SecureTransport services on the node and proceed with the upgrade of the next node in the cluster. Start all SecureTransport services only after the upgrade is applied on all the nodes in the cluster.
o After all node upgrades are finished, do a manual sync. Only after you have completed a manual sync will you have functional and operating cluster.
l Option 2:
o Dis-join the cluster before the upgrade by changing the cluster mode and deleting the node entries in the servers file. For details, refer to the Remove a server from an active/active cluster section in the SecureTransport Administrator's Guide.
o Then upgrade all the nodes as standalone installations.
o Once the upgrades are completed, join the cluster back together and do a manual sync. The cluster is considered upgraded and running only after the successful manual sync. For details, refer to the Remove a server from an active/active cluster section in the SecureTransport Administrator's Guide.
Enterprise Cluster The upgrade of an Enterprise Cluster (EC) consists of upgrading the nodes.
The following Enterprise Cluster upgrade option is supported:
l Stop the nodes and upgrade the nodes one at a time. After a node is upgraded, stop all SecureTransport services on the node and proceed with the upgrade of the next node in the cluster. Start all SecureTransport services only after the upgrade is applied on all the nodes in the cluster.
Upgrade steps for Oracle databases The following upgrade steps are optional and pertain to Oracle databases only.
Export data from old Audit log and import it to the new one The recommended method of migrating old data from the old Audit log table (AUDITLOG_OLD in the example) to the new Audit log table (AUDITLOG in the example) is to use Oracle Data Pump.
Run the following commands as a user with DATA_PUMP privileges:
expdp [db_user]/[PASSWORD] tables=<ST_SCHEMA>.AUDITLOG_OLD content=all dumpfile=AUDITLOG_OLD.dmp directory=[DB_DIRECTORY]
impdp [db_user]/[PASSWORD] directory=[DB_DIRECTORY] remap_table=auditlog_ old:auditlog dumpfile=AUDITLOG_OLD.dmp table_exists_action=append

4 Post-upgrade tasks
l If the Administration tool is not loading after upgrading to 5.5 GA, it is likely that the admin service fails to start normally. Check the corresponding catalina.out file (FILEDRIVEHOME/tomcat/admin/logs) for the following log message: "java.lang.NoClassDefFoundError: org/apache/tomcat/JarScanFilter". If it is present, the issue can be resolved in two ways:
o Stop the Administration Tool and AS2 servers and delete both tomcat-util- scan.jar and tomcat-websocket.jar from FILEDRIVEHOME/tomcat/lib folder. Then, start the services again.
o Apply the latest SecureTransport 5.5 Update.
Axway recommends checking also the catalina.out log file for the AS2 server (FILEDRIVEHOME/tomcat/as2/logs) for the error stated above. If it is present, you can fix it in the same way.
l Start the protocol servers and services on the SecureTransport Edges to establish the Transaction Manager protocol and proxy server communication. For additional information, refer to the SecureTransport Administrator's Guide.
l On Windows systems, go to the <AxwayHome>/Java/<OS> directory and delete the jre8_ u231_64 folder.
l After you upgrade, the Apache Tomcat server, used in SecureTransport, will be downgraded to version 7.0.103. Tomcat 7.0.x and Tomcat 8.0.x have reached end of life and are no longer supported. To avoid vulnerabilities and system failure, install the SecureTransport latest update to upgrade to Tomcat 9.
Note During the upgrade to version 5.5, all SecureTransport cronjobs along with their schedules will be migrated to the monitord configuration and then deleted from cron. All non- SecureTransport related cronjobs will be preserved. This goes for all operating systems you install and run SecureTransport on.
4 Recover your previous SecureTransport installation on Unix-like systems
Note After a successful upgrade to SecureTransport 5.5, there is no revert / downgrade path: the only way to roll back to a previous SecureTransport version deployment is to restore it from backup.
If the upgrade fails, you can recover your backed-up SecureTransport 5.4 installation.
Complete the following steps to restore your SecureTransport installation from a backup on a UNIX or AIX system. If you use a non-root installation, execute all steps for restoring by using your non-root user.
1. Stop all SecureTransport services.
2. Verify that all services are stopped. You can check if a process is still running by verifying if the PID exists the <FILEDRIVEHOME>/var/run directory.
3. On Linux, list all services in systemd by running systemctl --all and look for SecureTransport services. If present, stop and disable the SecureTransport services by using the following commands: systemctl stop <service name>.serviceand systemctl disable <service name>.service.
4. On Linux, verify there are no SecureTransport service files and symlinks to them in /etc/systemd/system and /usr/lib/systemd/system. If there are any, stop and disable the services and remove the symlinks.
5. On Linux, reload and reset the unit files by running systemctl daemon-reload and systemctl reset-failed.
6. On Linux, copy the backup init scripts to /etc/rc.d and its respective subdirectories, and ensure that the rc.d/init.d/rc.stransportSecureTransport<xx> script is executable.
7. On AIX, copy the backup init script to the /etc directory, and verify that rc.stransportSecureTransport<xx> or rc.stransport, respectively, is executable.
8. For root installation, replace the /etc/synchronycomponents file with the backup synchronycomponents file. For non-root, replace the /<user's home>/.synchronycomponents file with the backup synchronycomponents file.
9. Copy the SecureTransport cron jobs from the backup cron file to crontab by using the crontab -e.
Caution This step applies only when you revert from 5.5 to version 5.4. Skip this step, if you're reverting a 5.5 update to a previous 5.5 release.
10. Remove the Axway installation directory and extract the Axway backup.
11. Remove the SecureTransport installation directory and extract the SecureTransport backup.
12. If you use an external database, restore it according to the database vendor's instructions.
13. Execute all the steps for restoring SecureTransport on all instances.
14. Reboot your machines.
5 Recover your previous SecureTransport installation on Windows
Note After a successful upgrade to SecureTransport 5.5, there is no revert / downgrade path: the only way to roll back to a previous SecureTransport version deployment is to restore it from backup.
If the upgrade fails, you can recover your backed-up SecureTransport 5.4 installation. Make sure you uninstall SecureTransport 5.5 before you attempt to recover.
Complete the following steps to restore your SecureTransport installation from a backup on Windows Server.
1. For a SecureTransport Server using an external Oracle database, restore the database using standard Oracle procedures. For a SecureTransport Server using an external Microsoft SQL Server database, restore the database using standard Microsoft procedures.
2. Expand the SecureTransport.zip file created during the backup procedure and extract the files into the original installation folder of your previous SecureTransport installation.
3. Expand the Axway Installer.zip file created during the backup procedure and extract the files into the original installer folder of your previous installation.
4. Run regedit.exe to start the Windows registry, and delete the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Axway Software
Uninstall\Axway_Installer_4.10.7 SecureTransport1
5. Restore the registry entries that you backed up. To import a registry entry into the Windows registry, double-click the name of the respective .reg files you saved when you backed up your installation.
6. Make sure the file cygwin1.dll is included in your PATH environment variable. For example:
C:\Axway\SecureTransport\cygwin\bin
7. Make sure the folder STServer\bin is included in your PATH environment variable. For example:
C:\Axway\SecureTransport\STServer\bin
5 Recover your previous SecureTransport installation on Windows
8. Install the SecureTransport services:
l To install the services on a SecureTransport Server installation, navigate to the folder STServer\bin, located in the SecureTransport installation folder, and double-click the following files:
install_ftpd_service.com install_httpd_service.com install_sshd_service.com install_tm_service.com install_admin_service.com install_as2d_service.com install_pesitd_service.com
l To install SecureTransport services on a SecureTransport Edge installation, navigate to the folder STServer\bin, located in the SecureTransport installation folder, and double-click the following files:
install_ftpd_service.com
install_httpd_service.com
install_sshd_service.com
install_admin_service.com
install_as2d_service.com
9. Install Cygwin cron following the instructions below.
Caution This step applies only when you revert from 5.5 to version 5.4. Skip this step, if you're reverting a 5.5 update to a previous 5.5 release.
a. Navigate to the cygwin\bin folder in the SecureTransport installation folder and double-click the cygwin.bat file to start the Cygwin shell.
b. In the Cygwin shell, execute the following command:
cygrunsrv -I cygwin_cron -d \"Cygwin cron\" -p /usr/sbin/cron \
-a -D -f \"Cygwin Cron\"
10. Reboot your system and start all SecureTransport services. For more information, refer to the SecureTransport Administrator's Guide.
5 Update Amazon S3 and SharePoint transfer sites
5 Update Amazon S3 and SharePoint transfer sites
Starting with SecureTransport 5.5, the Amazon S3 and MS SharePoint connectors are released separately from the GA release. Their latest versions that are compatible with SecureTransport 5.5 are available for download from AMPLIFY Repository.
For a full list of connectors that are supported with SecureTransport, see Axway and third-party software support.
If you have an Amazon S3 or a SharePoint transfer site configured on your SecureTransport 5.4 installation, after upgrading to 5.5, you need to update the corresponding connectors.
To update a connector, follow the procedure, where <FILEDRIVEHOME> is the SecureTransport installation directory:
1. Download the connector from AMPLIFY Repository.
l Amazon S3 Connector for Axway SecureTransport
l MS SharePoint Connector for Axway SecureTransport
2. Execute the following commands to remove the old binaries.
l for Amazon S3
rm -rf <FILEDRIVEHOME>/plugins/transferSites/axway-site-s3
rm -f FILEDRIVEHOME>/plugins/transferSites/axway-site-s3.jar
l for MS SharePoint
rm -rf <FILEDRIVEHOME>/plugins/transferSites/sharepoint
3. Extract the connector's zip file.
l for Amazon S3
<FILEDRIVEHOME>/bin/start_all
5 ICAP legacy system import and upgrade
Mapping between old ICAP options and new ICAP server during legacy system import and upgrade from 5.3.6 GA to 5.4:
ICAP Server Old Configuration option
icapServer.connection
Timeout
icap.First/SecondServer.ConnectTimeout
icapServer.enabledCip
hers
icap.First/SecondServer.EnabledCipherSui
tes
icapServer.enabledPro
tocols
icap.First/SecondServer.EnabledProtocols
icapServer.enabled icap.First/SecondServer.ScanEnabled
icapServer.scanOnlyIf
PartnerRecipient
icapServer.type INCOMING
On legacy system import:
l If the value of configuration option FirstServer.Url_ is not empty, the new ICAP server entity with name FirstServer _ will be created, if an ICAP server with the same name exists - the legacy system import will fail.
l If the value of configuration option SecondServer.Url_ is not empty, the new ICAP server entity with name SecondServer_ will be created, if an ICAP server with same name exist - the legacy system import will fail.
On upgrade from 5.3.6 GA:
l If the value of configuration option icap.FirstServer.Url is not empty, the new ICAP server entity with name FirstServe

securetransport 5.5 upgrade guide - docs.axway.com

Documents