Upgrade and Installation Instructions
The process for upgrading One Identity Management Console for Unix from an older version is similar to installing it for the first time. The installer detects an older version of the management console and automatically upgrades the components.
Please see the One Identity Management Console for Unix Administration Guide for detailed installation and configuration instructions.
NOTE: When installing both One Identity Management Console for Unix AND One Identity Authentication Services, there is no requirement as to which product must be installed first.
Before you begin the upgrade procedure:
- Delete your browser cache (Temporary Internet Files and Cookies).
- Close One Identity Management Console for Unix and make a backup of your database.
- Previous releases of Management Console for Unix supported installations on macOS, but the 2.5.2 release has discontinued this support, both for upgrades and for fresh installations.
- However, the 2.5.2 release still supports the use of macOS in other roles, such as profiling, installation of One Identity Authentication Services, and as a browser client.
For the server:
Previous releases required Java 6, and the 32-bit installer for Windows included a Java 6 implementation (JRE 1.6.0_35).
This release requires Java 8, and none of the installers include a Java implementation. A Java 8 implementation must be installed before any 2.5.2 installer can be executed, either for an upgrade or for a fresh installation.
For the client:
Previous releases used Java Applet functionality to provide some parts of the user interface, so they expected a Java installation and browser plug-in on the client.
This release does not use Java Applet functionality, so it no longer needs nor uses client-side Java.
- Previous releases included an SSH client implemented as a Java Applet, but this release does not.
This release uses Jetty 9.4.* on Java 8, whereas the 2.5.1 and previous releases used Jetty 7.* on Java 6. The new Jetty and Java combine to provide much better HTTPS security (particularly newer TLS ciphersuites and newer versions of the TLS protocol) by default, without requiring security-related SSL/TLS customizations that had been recommended for previous releases.
If you are upgrading from a previous release and had customized its configuration, please note the following:
- If you customized the jetty.xml file:
- Management Console for Unix 2.5.2 will not use any of the jetty.xml customizations from the previous release. The new Jetty release uses a newer, more maintainable modular configuration system that avoids modifying its jetty.xml file.
- When the installer detects that you are upgrading and have customized the jetty.xml file, it will ask whether to continue or to cancel the installation.
- If you choose to continue, the customized jetty.xml file will be preserved as jetty.xml.bak so that you can review it (and compare it with a jetty.xml.baseline file that has no customizations) after the installation completes. This allows you to determine whether the previous customizations are unnecessary for 2.5.2 or whether they are still relevant and should be applied manually to the new configuration.
- In general, previous jetty.xml customizations of the SSL/TLS protocol versions or ciphersuites will no longer be needed, but jetty.xml customizations for other reasons may still be pertinent to the upgraded Jetty release.
- If you customized the jetty.keystorePath system property (in the custom.cfg file):
- Previous releases specified the keystore location as an absolute pathname, and the jetty.keystorePath system property could specify any directory name and filename. By contrast, the Jetty 9.4 configuration design expects the keystore location to be a relative pathname, resolved against the new jetty-base directory tree, with a default of etc/keystore.
- The upgrade installer does not attempt to convert old absolute keystore pathnames to new relative keystore pathnames — instead it relocates (moves and renames) the keystore from the location specified by jetty.keystorePath to the new default location, and then comments out the jetty.keystorePath setting in the custom.cfg file to indicate that it is no longer used.
- If the upgrade installer sees that jetty.keystorePath has not been customized (that is, it specifies the default keystore path for the previous release, such as /var/opt/quest/mcu/resources/keystore on Unix/Linux) then the keystore is relocated from its old default location to the new default location.
If the upgrade installer finds that jetty.keystorePath has been customized, then by default it will still relocate the keystore to the new default location, but it provides an "opt-out" check box on the installer screen that displays the TCP ports. This check box is selected by default but may be explicitly cleared to indicate that the keystore should not be relocated.
NOTE: If this check box is cleared then the upgrade installation will proceed without relocating the keystore, and the resulting configuration will not start successfully until the keystore configuration has been manually adjusted.
After an upgrade:
After an upgrade from any version of the management console, it is important to re-profile all hosts.