Upgrading to version

Select the options that apply to your environment to generate a customized guide to upgrade from a version 6 to version .

README FIRST: See Upgrading tab in Jazz Foundation Downloads page.

Upgrading from a version 5 release to version : Upgrading from a version 5 release to version is a two-step process. You must first upgrade your server to the latest fix pack of the version 6 release, start the server, ensure that the version 6 upgrade was successful, and then upgrade to version .

For instructions on upgrading from a version 5 release to the latest version 6 release, see the latest version 6 documentation.

upgrade: For information about upgrading the applications on , see Planning to upgrade on .

Attention: When you select the options to generate the upgrade instructions, if you want to change your selection again, it is recommended that you refresh the browser and then select your options.

Note: You can upgrade any applications in your environment; however, clustering is only supported for the and applications in this release.

Note: After you successfully upgrade to 7.0.2, retain the upgrade logs for a year. IBM Support might need these logs if you open a support case.

Are you upgrading a cluster of applications?

Are you upgrading a cluster of applications?

Select the operating system for your application server:

Select the product version you are upgrading from:

Attention: After you have made your selections, if you want to change the product version, it is recommended to refresh the browser and start with your selections again to generate the content.

Select the applications to upgrade:

Note: You must upgrade first. In a distributed topology where and other applications are installed on separate servers, upgrade first, and then upgrade other applications one at a time.

Note: If multiple applications connect to a common database server at the same time, the database server might crash or cause connection issues. To avoid database related issues, it is recommended to upgrade the applications one by one.

Important: In this release, the application upgrade is only supported from version 6.0.2 and later. If your current application is at a different version and you are planning to upgrade to version , you must first upgrade it to one of these supported versions and apply the latest interim fix for that version, before you upgrade .

  • Optional applications (separate license)

  • Design Management

  • (/dm)
  • Architecture Management

  • Supporting applications

  • Note: The Reporting applications must be at the same level as . If you upgrade at this time and leave the Reporting applications at previous version, the will not work until it is upgraded to the same level as .

Did you use a custom context root in your previous deployment?

Select your database server:

The complete instructions to upgrade your () applications to version are generated based on the selections and inputs that you provided on the previous page.

Deployment topology
  • One-server topology
  • Multiple-server topology
  • Can mount drives
  • Cannot mount drives
  • IBM i server
Applications to upgrade
  • /
  • /
  • /
  • /
  • /
    • Migrating link validity
    • Not migrating link validity
  • /
  • /
  • /
  • /
  • /
  • /
Custom context root
  • No
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
Previous installation path
  • Your previous installation path is:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
New installation path
  • Your new installation path is:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
  • /:
Upgrade method
  • By using the upgrade script
  • By using the upgrade script in silent mode
  • Manual upgrade by using individual repotools commands
  • IBM i script
Previous product version
  • You are upgrading from version 6.0
  • You are upgrading from version 6.0.1
  • You are upgrading from version 6.0.2
  • You are upgrading from version 6.0.3
  • You are upgrading from version 6.0.4
  • You are upgrading from version 6.0.5
  • You are upgrading from version 6.0.6
  • You are upgrading from version 6.0.6.1
  • You are upgrading from version 7.0
  • You are upgrading from version 7.0.1
Operating system
  • Microsoft Windows
  • IBM AIX
  • Linux
  • Linux for System z
  • Linux on Power
  • IBM i
Application server
  • WebSphere Liberty
  • IBM WebSphere Application Server - Integrated Solutions Console
  • Your WebSphere Application Server profile directory is:
  • IBM WebSphere Application Server - Jython scripts
  • Your WebSphere Application Server profile directory is:
Database server
  • Apache Derby
  • IBM Db2
  • IBM Db2i
  • IBM Db2 for z/OS
  • Oracle
  • Your Oracle JDBC driver location is:
  • Microsoft SQL Server
  • Your SQL Server JDBC driver location is:
Configured data warehouse
  • No, you will configure it in this release
  • Yes
  • No, you don't use data warehouse
Installing Jazz Authorization Server
  • Yes
  • No

 

Important: Before you upgrade, read these important notes.

Complete the planning checklist

Use this planning checklist to ensure that you are ready to upgrade.

  Planning task More information
Use the software product compatibility reports: On this page, you can search and generate reports for a specific product. The information includes prerequisites, product translation into a specific language, end of service, server virtualization environments, and more. Software product compatibility reports
Gather required information: Before starting the upgrade process, you must gather and record specific data that is required during the upgrade process, such as URLs, user IDs and passwords, database locations, name of databases installed, and so on.  
Verify that your hardware and software meet the minimum system requirements: New requirements exist for version , and a few older versions might be deprecated. To learn about the new requirements and to see whether your system meets the minimum requirements, click the System requirements link. System requirements
Get the product installation media: For a local repository download, you need approximately 5 GB of hard drive space to download and extract your product installation media. You can download the server installation files from jazz.net or Passport Advantage.
Review an upgrade topology example.
Synchronize the clocks on all servers: In a distributed environment, ensure that the clocks on all servers are synchronized by using the Network Time Protocol (NTP). For more information about NTP, visit ntp.org
Understand the upgrade process: Learn about the upgrade process and how the upgrade might affect your deployment. Understanding the deployment and upgrade process
Plan for your applications to be unavailable: Your applications will be unavailable for a brief period while you back up everything and update your applications to version . All of the applications that are connected to will be offline while is offline. Be sure to provide time to completely back up your existing applications.  
Meet your database prerequisites:
  • You can access the previous release database and copy the derby/repositoryDB directory.
  • You have the correct user name and password.
    • On UNIX systems, use the password for the Db2 instance owner, which is typically the db2inst1 user.
  • Before you start the upgrade process:
    1. For each application that you are upgrading, make sure you have applied the latest iFix for the version you are upgrading from.
    2. For each application that you are upgrading, verify the integrity of its database by running the corresponding repotools -verify command with level=4. For example, repotools_xx -verify level=4 where xx is the repotools command for the application. If any problems are reported, run the corresponding repotools repair tool before proceding with the upgrade.
    3. Verify the integrity of the repository databases by running the Online Verify tool.
  • You backed up your database before you started the upgrade process.
  • It is recommended to discuss with your database administrator (DBA) to determine what values are appropriate within the context of your Enterprise setup. When altering the BUFFERPOOL, make sure you reset to the original value when you run db2 get db cfg after the upgrade.
IBM Db2i® database is preconfigured on your IBM® i system.
Creat a backup of your IBM Db2 for z/OS® database before the upgrade.
  • You have the correct user name and password.
  • Before you start the upgrade process:
    1. Verify the integrity of the database by running the -verify repotools command.
    2. Verify the integrity of the repository databases by running the Online Verify tool.
  • Change the COMPATIBE setting for the database to 12.2.0 or later by running:

    alter system set COMPATIBLE='12.2.0' scope=spfile;
    shutdown immediate
    startup mount
    ALTER DATABASE OPEN;

  • You backed up your database before you started the upgrade process. For more information about backing up databases, see your database vendor documentation.
  • The required Java Database Connectivity (JDBC) driver is ojdbc8.jar.
  • You backed up your database before you started the upgrade process. For more information about backing up databases, see your database vendor documentation.
  • The required Java Database Connectivity (JDBC) driver is ojdbc8.jar.
  • Restriction: Because of a defect in Oracle JDBC driver 12.1.0.2.0, this version of the driver cannot be used. For details, see repotools -createTables command fails with ORA-01000 on Oracle 12 on the IBM Support portal page.

  • You created an environment variable named ORACLE_JDBC_DRIVER_FILE and pointed to the JDBC driver.
  • To avoid performance issues, ensure that Oracle Bug ID 13077335.8 is applied and enabled on the Oracle system hosting . See the Oracle documentation for details.
  • Make sure you have sufficient TEMP tablespaces with the ability to auto-extend if necessary. If you do not have enough TEMP space, the upgrade might fail with the following message: ORA-01652: unable to extend temp segment by 128 in tablespace TEMP.
  • You have the correct user name and password.
  • Before you start the upgrade process:
    1. Verify the integrity of the database by running the -verify repotools command.
    2. Verify the integrity of the repository databases by running the Online Verify tool.
  • If the current database version is not supported, perform the following steps:
    1. Perform the pre-requisite steps to upgrade.
    2. Backup the current database. For information about backing up databases, see your database vendor documentation.
    3. Upgrade the backend database to the supported version.
    4. Run the repotools upgrade commands in the newer version
  • You backed up your database before you started the upgrade process. For information about backing up databases, see your database vendor documentation.
  • You ensured that the Java Database Connectivity (JDBC) driver is installed, and you are using sqljdbc42.jar.
  • You created an environment variable named SQLSERVER_JDBC_DRIVER_FILE and pointed to the JDBC driver.
  • In previous versions, the Requirements Management data was stored as RDF text in the database. In the new release, the data is directly stored in the backing database without deleting the old RDF data. As a result, the database requires double the space. Ensure that you have adequate disk space on your database server for this data growth.

Important: Before you start the Quality Management - application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website. For information about the Oracle database DBMS_STATS command, see the Oracle website. For information about the SQL Server database Update Statistics command, see the SQL Server website.

For information on setting up an Oracle datase, see Setting up an Oracle database

For information on setting up a SQL datase, see Setting up an SQL Server database

For information about the verify command, see Repository tools command to verify the integrity of a database

For information about the online verify tool, see Online Verify tool

For information on managing Db2, see Managing Db2 for z/OS databases before upgrading

Learn about licensing: Click the link to learn about licenses in this release.

Important: If you use Authorized User Term, Floating Term, or Token licenses, you must obtain new licenses from the License Key Center and update your current licenses. See the "Obtain licenses" step for details.

Managing licensing
Check the browser compatibility:
  • Enable JavaScript in your web browsers so that wizards can be displayed.
  • For web browsers that are used for migrations, make sure that pop-up blockers are disabled.
 
Check the client and server compatibility:

must be at the same level as or newer than the applications that are registered with it, but the applications cannot have a newer version than .

For more information, see Client and server version compatibility
Check your Java Virtual Machine options: Make sure that the Java Virtual Machine has the appropriate heap size setting. If you are installing all applications on one server for trial or demo, ensure you have enough memory installed. The JVM settings for the server can be adjusted in the server.startup file.
  1. To set these properties in WebSphere Integrated Solutions Console, click Servers > Server Types > WebSphere application servers > server1.
  2. Under Server Infrastructure, click Java and Process Management > Process definition.
  3. Under Additional Properties, click Java Virtual Machine.
  4. In the Generic JVM arguments field, check that the following lines exist:

    -Xmx4g -Xms4g -Xmn1g
    -Xgcpolicy:gencon -Xnocompressedrefs

    -Xmx4g -Xms4g -Xmn1g
    -Xgcpolicy:gencon -Xcompressedrefs
    -Xgc:preferredHeapBase=0x100000000

    Tip: If you need more heap size, then you can use the following setting, replacing {N} with the amount of memory to be used and {N/4} with 1/4 of the total memory. For example, if -Xmx is set to 8g, -Xmn should be set to 2g.

    -Xmx{N} -Xms{N} -Xmn{N/4}

    For Lifecycle Query Engine only: If Lifecycle Query Engine application pages become unresponsive as a result of memory issues, see this technote for troubleshooting.

For only: The -Xmn value should be 33% of the -Xmx value. For example, if the -Xmx size is 4gb, the -Xmn should be 1365m.

In addition, for large deployments you should increase the Xmx value in the repotools files from the default 1500M to 8192M or higher. This increase in the Xmx value is necessary to improve performance and avoid out of memory errors during the execution of repotools -reindex all command. For more information on how to adjust the repotools command, see the technote link in the More information column.

Before you upgrade the application, make sure you verify the Jena index. Validate the indexes using the repotool_rm verifyJFSIndexes command. If the Index verification reports an error, rebuild the Jena indexes using the repotools-rm -reindex all command.

 

 

 

 

Stage a test environment for the upgrade process

 

Special instructions for upgrading on IBM i

 

Record server name, profile name, node name, heap size values, and previously installed application names

During the upgrade you need to know some information about your current environment. Make sure you record the following information.

  1. Log on to WebSphere Application Server Integrated Solutions Console.
  2. Expand Servers > Server types, and then click WebSphere Application Servers.
  3. Record the server name and node name.
  4. Click server1, expand Java and Process Management and then click Process definition > Java Virtual Machine.
  5. Record the values under Generic JVM arguments.
  6. Expand Applications > Application types, and then click WebSphere Enterprise Application.
  7. Record the names of the following installed applications:
    • (jts_war)
    • Help (clmhelp_war)
    • (ccm_war)
    • IBM Engineering Test Management (qm_war)
    • (rm_war)
    • (relm_war)
    • Global Configuration Management (gc_war)
    • Link Index Provider (ldx_war)
    • Report Builder (rs_war)
    • Lifecycle Query Engine (lqe_war)
    • Data Collection Component (dcc_war)

Repair multiple versions of an artifact marked as current in the configuration

If you used Configuration Management in 6.0.2 or earlier versions of IBM Engineering Requirements Management DOORS Next or IBM Engineering Test Management applications, if multiple users updated an artifact in a configuration at the same time, inconsistent versions of the artifact might be displayed in the configuration. This problem occurs because multiple versions of the artifact are internally marked as the current version. For example, you might experience the following issues:

  • Different views show different versions of an artifact for the same configuration.
  • An artifact cannot be found.

This issue no longer occurs in version 6.0.3 and later, but might be present in those versions if you upgraded from an earlier release. You can run the following query to detect if a configuration has more than one current version of an artifact:

SELECT DISTINCT CONFIGURATION_ITEM_ID FROM VVCMODEL.VERSION WHERE CURRENT_COL = 1 GROUP BY CONFIGURATION_ITEM_ID, CONCEPT HAVING COUNT(CONCEPT) > 1

SELECT DISTINCT CONFIGURATION_ITEM_ID FROM VVCMODEL_VERSION WHERE CURRENT_COL = 1 GROUP BY CONFIGURATION_ITEM_ID, CONCEPT HAVING COUNT(CONCEPT) > 1

If the query finds more than one current version, open a command windowshell and enter the following commands:

Important: The -repairMultipleVersionsMarkedAsCurrent repository tools command is available in the latest Interim Fix of each release. You must apply the latest iFix before you can use the command. If you run the query and there are more than one current version of an artifact but the -repairMultipleVersionsMarkedAsCurrent repository tools command is not available, do not upgrade to version .

For IBM Engineering Requirements Management DOORS Next

cd \/server
repotools-rm.bat./repotools-rm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/rm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For IBM Engineering Test Management

cd \/server
repotools-qm.bat./repotools-qm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/qm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For

cd \/server
repotools-rm.bat./repotools-rm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/rm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For IBM Engineering Test Management

cd \/server
repotools-qm.bat./repotools-qm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/qm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For more information about the repairMultipleVersionsMarkedAsCurrent repository tools command, see Repository tools command to repair multiple versions of an artifact marked as current.

Depending on the size of your database, the utility might take a while to scan the entire database. The server must be running when you run the repository tools command and no restart is required after the command is complete.

If you are prompted for the following message, you can safely ignore it:

repair: YYYY-MM-DD HH:MM:SS,### [Number of configurations] Configurations Modified. Please shutdown the server and run the reindex command.

Move the or application to a new location

In order to perform the migration of the or applications that are installed into the same group, two instances of the application must be installed into a target folder. However, does not allow to install two or more instances of the same application into the same group. You can use server rename to move either the or application into a separate installation folder.

If you are using a reverse proxy in your deployment, see the following resources:

In order to perform a server rename procedure, you must install a separate application along with your old installation. There are two options for installing the application:

Examples:

In the following examples, the installation folder corresponding to the existing 6.x is referred to as old_install_dir, and the new 6.x that you will be installing for server rename is referred to as new_install_dir.

The application is deployed in

The following procedure is for the basic registry to manage users. For LDAP, see Configuring an LDAP or an LDAP/SDBM connection.

Example of the application deployed in as part of a distributed topology

The following scenario is for the installation of multiple applications installed into different groups on different servers.

  • Server 1: , ,
  • Server 2:
  • Server 3:

The goal is to move the application from server 1 into a new server 4 along with the application and in a new instance of .

  1. Install the version 6.x application on server 4.
  2. Install and configure on server 4.
  3. Install 6.x (the same version as the existing installation) into a new folder (new_install_dir). Ensure to select Install with WAS Liberty Profile.
  4. Prepare a mapping file for the server rename procedure:
    1. Ensure the existing server is up and running.
    2. Open a command window and enter the following commands:

      cd old_install_dir (Server 1)\server
      repotools-jts.bat -generateURLMappings toFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://hostname:port/jts

      cd old_install_dir (Server 1)/server
      ./repotools-jts.sh -generateURLMappings toFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://hostname:port/jts

    3. Update the generated MAPPINGS.TXT file: Comment out or remove the source and target lines for applications that should not be renamed and keep only one pair related to the application:

      source=https://hostname:old_https_port/am
      target=https://hostname:new_https_port/am

      Note: new_https_port is a random port number that should manually be changed since it is not automatically added to the generated mapping file.

    4. Update the generated MAPPINGS.TXT file: Comment out or remove the source and target lines for applications that should not be renamed and keep only one pair related to the application:

      source=https://old_hostname:port/am
      target=https://new_hostname:port/am

      Note: new_hostname corresponds to the host name of server 4.

  5. Veify the MAPPINGS.TXT file by entering the following command:

    repotools-jts.bat./repotools-jts.sh -verifyURLMappings mappingFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://old_hostname:port/jts

  6. version 6.x does not contribute to and . This step should be performed if required by other applications. For the and applications, ensure that you completed the "Preparing for server rename" section of Impact of server rename on and .
  7. For , ensure that you performed all the required actions described in Impact of server rename on the .
  8. Log into on server 1 and undeploy the am.war application.
  9. Stop on servers 1, 2, and 3.
  10. Go to the old_host/server and stop the server.
  11. Back up the existing source environment.
  12. Go to the new_install_dir/server and enter the following command to create the server.

    repotools-am -help

    This command creates the new_install_dir/server/liberty/servers/clm/ folder.

  13. Copy the application indices and configuration files into the new installation folder:

    xcopy /s old_install_dir\server\conf\am\indices new_install_dir\server\conf\am\indices

    xcopy old_install_dir\server\conf\am\teamserver*.properties new_install_dir\server\conf\am

    xcopy old_install_dir\server\conf\am\am.properties new_install_dir\server\conf\am

    cp -R old_install_dir/server/conf/am/indices new_install_dir/server/conf/am/indices

    cp old_install_dir/server/conf/am/teamserver*.properties new_install_dir/server/conf/am

    cp old_install_dir/server/conf/am/am.properties new_install_dir/server/conf/am

  14. Copy the Apache Derby database:

    First, enter the following command to delete the new_install_dir Apache Derby database:

    del /s /f new_install_dir\server\conf\am\derby\repositoryDB

    Enter Y to confirm the delete operation.

    rm -rf new_install_dir/server/conf/am/derby/repositoryDB

    Then, enter the following command to copy the Apache Derby database:

    xcopy /s old_install_dir\server\conf\am\derby\repositoryDB new_install_dir\server\conf\am\derby\repositoryDB

    cp -R old_install_dir/server/conf/am/derby/repositoryDB new_install_dir/server/conf/am/derby/repositoryDB

  15. Copy the basicUserRegistry.xml file:

    xcopy old_install_dir\server\liberty\servers\clm\conf\basicUserRegistry.xml new_install_dir\server\liberty\servers\clm\conf

    cp old_install_dir/server/liberty/servers/clm/conf/basicUserRegistry.xml new_install_dir/server/liberty/servers/clm/conf

  16. Copy the ltpa.keys file:

    First, make a backup and delete the ltpa.keys file from the old_install_dir server:

    del old_install_dir\server\liberty\servers\clm\resources\security\ltpa.keys

    rm old_install_dir/server/liberty/servers/clm/resources/security/ltpa.keys

    Then copy the ltpa.keys file to the new server:

    xcopy old_install_dir\server\liberty\servers\clm\resources\security\ltpa.keys new_install_dir\server\liberty\servers\clm\resources\security

    cp old_install_dir/server/liberty/servers/clm/resources/security/ltpa.keys new_install_dir/server/liberty/servers/clm/resources/security

  17. Go to the new_install_dir/server/liberty/servers/clmnew_install_dir\server\liberty\servers\clm folder and open the server.xml file for editing.
  18. Modify the HTTP and HTTPS ports:

    <httpEndpoint id="defaultHttpEndpoint"
    host="*"
    httpPort="<new_http_port>"
    httpsPort="<new_https_port>" />

    Note: <new_http_port> is a random port number for HTTP protocol.

  19. Uninstall the application form the old_install_dir. Ensure that am.war and am.war.zip files are deleted from the following folders:

    old_install_dir/server/liberty/servers/clm/appsold_install_dir\server\liberty\servers\clm\apps
    old_install_dir/server/liberty/clmServerTemplate/appsold_install_dir\server\liberty\clmServerTemplate\apps

  20. Go to the old_install_dir/serverold_install_dir\server folder and create a file called serverConf.txt with the following content:

    #RMM
    new_install_dir/server/conf

  21. Copy the ImportUMLMappings.activate file to the old_install_dir/server/confold_install_dir\server\conf folder.
  22. Open a command window and enter the following commands:

    cd old_install_dir\server
    repotools-jts.bat -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt

    cd old_install_dir/server
    ./repotools-jts.sh -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt

  23. version 6.x does not contribute to and . This step should be performed if required by other applications. For the and applications, ensure that you completed the "During server rename" section of Impact of server rename on and .
  24. If you can map the network drives from the host, follow these steps:
    1. Map a network drom from the host to each of the application hosts.
    2. Go to the old_install_dir/serverold_install_dir\server folder and create a file called serverConf.txt that contains a liat of remote server/conf directories:

      #Remote DCC
      D:/JazzTeamServer/server/conf
      #Remote RMM
      R:/JazzTeamServer/server/conf

    3. Open a command window and enter the following command:

      repotools-jts.bat -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt

      ./repotools-jts.sh -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt

  25. If you cannot map the network drives from the host, follow these steps:
    1. Open a command window and enter the following command:

      repotools-jts.bat -importURLMappings fromFile=MAPPINGS.TXT

      ./repotools-jts.sh -importURLMappings fromFile=MAPPINGS.TXT

    2. Copy the server/conf/jts/.mappingEvent file to the remote applications configuration directories that participated in server rename.
    3. Note: The event file is generated when you import the mappings. You must copy the .mappingEvent file after you import the mapping file but before you start the server.

  26. Start on server1, 2, 3, and 4.
  27. Verify that the rename is successful by checking the console output and the jazz_install_dir/server/\server\repotools-jts_importURLMappings.log file.
  28. Start both servers:

    cd old_install_dir\server
    server.startup.bat

    cd old_install_dir/server
    ./server.startup

    cd new_install_dir\server
    server.startup.bat

    cd new_install_dir/server
    ./server.startup

  29. Log in to and open the following URL in a browser:

    https://hostname:old_https_port/jts/serverRenameStatus

  30. Log in to and open the following URL in a browser:

    https://old_hostname:port/jts/serverRenameStatus

  31. Verify that the Rename process completed successfully by going through all the project areas that are in read only mode. Check that all application friend URLs are correct.
  32. After verifying everything, select the checkbox to remove the read only mode and complete the rename process.
  33. version 6.x does not contribute to and . This step should be performed if required by other applications. For the and applications, ensure that you completed the "After server rename" section of Impact of server rename on and .
  34. For , ensure that you performed all the required actions described in Impact of server rename on the .
  35. Follow the next step and install and on server 4.

Install the new version applications

Install the new version applications into a new package group, but do not run the setup wizard after the installation. For distributed configurations, install the version applications that correspond to the previously installed applications.

At this point, you can also install the new applications that you did not have in your previous deployment, such as Jazz Reporting Service, Global Configuration Management, and so on. After the upgrade is complete, run the setup wizard to register these new applications with .

For information about installing the server, see Installing by using IBM Installation Manager or Installing by using command-line commands.

Install the version applications, but do not run the setup wizard after the installation. For distributed configurations, install the version applications that correspond to the previously installed applications. For information about installing the server, see Installing on IBM i using licensed programs.

Note: You must also install the trial license keys if you use the Enterprise Extension builds.

The extension can be installed in two modes: Model Management Server and Model and Code Management Server. When you are prompted to select the Rhapsody Model Management Deployment mode, choose the mode applicable to your deployment topology. To understand the difference between these two modes as well as to define a list of required licenses, see Client access license management. Select Model and Code Management Server mode, if you use the functionalities provided by application that are not listed for inclusion in Model Management Server mode in your current deployment.

Note: In a clustered environment, you can install a new () application on each node and modify the properties files, or install a new application on the first node and, after modifying the files, copy the entire installation directory to the other nodes and change the node ID.

For the application:

  • Ensure to install with the application.
  • When you are prompted to select a context root option, choose Use your own context root values (advanced) and enter your previous application context root. For example: /am.
  • The extension can be installed in two modes: Model Management Server and Model and Code Management Server. When you are prompted to select the Rhapsody Model Management Deployment mode, choose the mode applicable to your deployment topology. To understand the difference between these two modes as well as to define a list of required licenses, see Client access license management. Select Model and Code Management Server mode, if you use the functionalities provided by application that are not listed for inclusion in Model Management Server mode in your current deployment.

Important: Before upgrading, make sure you apply the latest interim fix to your current installation. After you install version , apply the latest interim fix for version if any. This ensures that your new version applications are up-to-date. Make sure you run the repotools-clean command after the application is updated with the patch and restarted before running the addTables command. To check if there are any interim fixes available for your product, visit Fix list for IBM Rational Collaborative Lifecycle Management.

Important: If you use SameSite-enabled browsers, you must edit the server.xml file to add the samesite tag. See Customize the WebSphere Liberty server for SameSite for more details.

Increase temporary tablespace in Oracle for large repository

If you have a large IBM Engineering Test Management application repository with millions of artifacts, the default temporary tablespace QM_TEMP is not enough to handle the temporary files. You must add an additional temporary tablespace to avoid issues. To create an additional temporary tablespace, open a SQL *Plus window and log in as SYSTEM or SYSDBA and enter the following command:

alter tablespace QM_TEMP add tempfile 'ORACLE_BASE/oradata/CLMDB/QM_TEMP2.DBF' size 20m reuse autoextend on next 1m maxsize unlimited;

Where QM_TEMP is the temporary tablespace name, ORACLE_BASE is the absolute path where Oracle is installed, CLMDB is the database name, and QM_TEMP2.DBF is the additional temporary file name that you want to create.

Optional: Increase Db2 configuration settings for large repositories

If you have a large IBM Engineering Test Management application repository with millions of artifacts, you can increase some of the Db2 configuration settings to ensure that a successful data migration is achieved. The examples given here are for a repository of about ten million artifacts. Adjust the values according to the size of your data repository. Open a Db2 command window and enter the following commands to increase the configuration settings:

db2 update db cfg for QM using APPLHEAPSZ 60000
db2 update db cfg for QM using LOGFILSIZ 4096
db2 update db cfg for QM using LOGPRIMARY 50
db2 update db cfg for QM using LOGSECOND 100

Optional: Maximize the IBM Engineering Test Management application upgrade performance and execution

If you have a large IBM Engineering Test Management application repository with millions of artifacts, you can minimize the upgrade time and maximize the upgrade performance by adding the following Java system variables to the repotools-qm script file:

Optional: Online migration of quality management data

The IBM Engineering Test Management application online migration is an optional upgrade step that is done while the old server is still running. It migrates data in the live repository to reduce the amount of downtime incurred during normal migration. The data is migrated in such a way as to not affect users on the existing server.

Procedure

  1. Before you start the IBM Engineering Test Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

    Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

    DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

    EXEC sp_updatestats

    EXEC DBMS_STATS.GATHER_DATABASE_STATS

    For information about the Db2 database REORGCHK command, see the Db2 website.

    For information about the Oracle database DBMS_STATS command, see the Oracle website.

    For information about the SQL Server database Update Statistics command, see the SQL Server website.

  2. On the server on which you installed the new version of the IBM Engineering Test Management application, open a command window and enter the following command to estimate the data to migrate and to evaluate whether the online migration is appropriate for the repository.

    The teamserver.properties parameter must point to an absolute path on the old server.

    cd \server\
    repotools-qm.bat -onlineMigrateEstimate teamserver.properties=\server\conf\qm\teamserver.properties logFile=repotools_onlineMigrateEstimate.log

    cd /server
    ./repotools-qm.sh -onlineMigrateEstimate teamserver.properties=/server/conf/qm/teamserver.properties logFile=repotools_onlineMigrateEstimate.log

    For more information about the -onlineMigrateEstimate command and its parameters, see Repository tools command for evaluating the online migration process.

  3. To start the online migration enter the following command:

    The teamserver.properties parameter must point to an absolute path on the old server.

    cd \server\
    repotools-qm.bat -onlineMigrate teamserver.properties=\server\conf\qm\teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

    cd /server/
    ./repotools-qm.sh -onlineMigrate teamserver.properties=/server/conf/qm/teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

    For more information about the -onlineMigrate command and its parameters, see Repository tools command for online migration.

You can stop the online migration or revert to a previous state by using other repository tools commands.

To safely stop the online migration at any time, use the -onlineMigrateStop command. For more information, see Repository tools command for stopping online migration.

To revert the database to a previous state, use the -onlineMigrateRevert command. For more information, see Repository tools command for reverting online migration.

Optional: Online migration of data

The application online migration is an optional upgrade step that is done while the old server is still running. It migrates data in the live repository to reduce the amount of downtime incurred during normal migration. The data is migrated in such a way as to not affect users on the existing server.

Note: In a clustered environment, do this procedure only on the first node. You will replicate this node to other nodes in a later step.

Procedure

  1. Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

    Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

    DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

    EXEC sp_updatestats

    EXEC DBMS_STATS.GATHER_DATABASE_STATS

    For information about the Db2 database REORGCHK command, see the Db2 website.

    For information about the Oracle database DBMS_STATS command, see the Oracle website.

    For information about the SQL Server database Update Statistics command, see the SQL Server website.

  2. On the server on which you installed the new version of the application, open a command window and enter the following command to estimate the data to migrate and to evaluate whether the online migration is appropriate for the repository.

    The teamserver.properties parameter must point to an absolute path on the old server.

    cd \server\
    repotools-ccm.bat -onlineMigrateEstimate teamserver.properties=\server\conf\ccm\teamserver.properties logFile=repotools_onlineMigrateEstimate.log

    cd /server/
    ./repotools-ccm.sh -onlineMigrateEstimate teamserver.properties=/server/conf/ccm/teamserver.properties logFile=repotools_onlineMigrateEstimate.log

    For more information about the -onlineMigrateEstimate command and its parameters, see Repository tools command for evaluating the online migration process.

  3. To start the online migration enter the following command:

    The teamserver.properties parameter must point to an absolute path on the old server.

    cd \server\
    repotools-ccm.bat -onlineMigrate teamserver.properties=\server\conf\ccm\teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

    cd /server/
    ./repotools-ccm.sh -onlineMigrate teamserver.properties=/server/conf/ccm/teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

    For more information about the -onlineMigrate command and its parameters, see Repository tools command for online migration.

You can stop the online migration or revert to a previous state by using other repository tools commands.

To safely stop the online migration at any time, use the -onlineMigrateStop command. For more information, see Repository tools command for stopping online migration.

To revert the database to a previous state, use the -onlineMigrateRevert command. For more information, see Repository tools command for reverting online migration.

Improve the application upgrade performance and execution

If you have an AM application repository with a large number of artifacts, you can reduce the server downtime during migration by running the database migration tasks, while keeping the existing server active.

Note: You can use the onlineMigrateEstimate repotools command to retrieve the number of item states that the online migration command, onlineMigrate, processes. It is recommended that you use the onlineMigrate command if the number of states for “Type “ID Mappings (168)”:” exceeds 3,000,000.

The average estimated time needed to perform the online migration can be calculated using the following formula:
Online migration time (in hours) = (number of item states) / 500000

For more details about evaluating the online migration process and running online migration, see onlineMigrateEstimate repotools command and onlineMigrate repotools command.

Important: Additional steps are required before you execute the onlineMigrate repotools command. See onlineMigrate repotools command for more details.

To perform online migration keeping the existing server active, open a command prompt with administrative privileges and enter the following commands:

cd <path to EWM/RMM 7.0.2 installation folder specified by user>/server
repotools-ccm -onlineMigrate teamserver.properties=<path to AM 6.0.x/7.0.x Installation folder specified by user>/server/conf/<RMM context root specified by user>/teamserver.properties

To perform online migration without executing the onlineMigrate command, perform the following steps:
  • Open the existing file or create a new file named OnlineMigrateSettings.cfg in <path to EWM/RMM installation folder specified by user>/server folder and make sure it contains the following line:

    numStatesPerRun=400

  • (Optional) For DB2 only: Open a DB2 command window and enter the following command to increase the APPLHEAPSZ configuration setting:

    db2 update db cfg for <RMM DB name> using APPLHEAPSZ <original value * 2>

Optional: Back up the WebSphere Application Server profile

Create a backup of your WebSphere Application Server profile. If the upgrade fails, you can use the backup to restore the profile.

In a distributed topology, you must complete this step on each application server that hosts the applications.

Note: The command shuts down the server before starting the backup process.

  1. Open a command prompt and change to the bin folder of the WebSphere Application Server profiles directory. For example, cd \bin.
  2. Enter the following command. If WebSphere Application Server security is turned on, you must also supply the user name and password. Make sure that the directory path to the compressed file exists.
  3. backupConfig.bat Path_to_a_new_compressed_file_to_create_backup_of_profile -username WAS_primary_administrative_user_name -password WAS_administrative_password

    For example:

    backupConfig.bat C:\WAS_backup\version_6.0.x_profile.zip -username WAS admin -password WAS admin password

    Tip: You can restore the backed-up profile by running the restoreConfig.bat command. For example, restoreConfig.bat C:\WAS_backup\version_6.0.x_profile.zip

  1. Open a command shell and change to the bin folder of the WebSphere Application Server profiles directory. For example, cd /bin
  2. Enter the following command. If WebSphere Application Server security is turned on, you must also supply the user name and password. Make sure that the directory path to the compressed file exists.
  3. ./backupConfig.sh Path_to_a_new_compressed_file_to_create_backup_of_profile -username WAS_primary_administrative_user_name -password WAS_administrative_password

    For example:

    ./backupConfig.sh /root/WAS_backup/version_6.0.x_profile.zip -username admin -password password

    Note: The directory path to the compressed file must exist before running the backup command.

    Tip: You can restore the backed-up profile by running the ./restoreConfig.sh command. For example, ./restoreConfig.sh /root/WAS_backup/version_6.0.x_profile.zip

Stop and uninstall the previously installed applications from WebSphere Application Server

In a distributed topology, you must complete this step on each application server that hosts the applications.

  1. Make sure the server is started and then log on to the WebSphere Application Server Integrated Solutions Console at https://hostname:9043/ibm/console/logon.jsp.
  2. Click Applications > Application Types > WebSphere enterprise applications.
  3. Click jts_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for jts_war application. You will use this information to remap the application for its version counterpart.
  4. Click ccm_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for ccm_war application. You will use this information to remap the application for its version counterpart.
  5. Click am_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for am_war application. You will use this information to remap the application for its version counterpart.
  6. Click qm_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for qm_war application. You will use this information to remap the application for its version counterpart.
  7. Click the Enterprise Applications link and then stop and uninstall the following installed applications:
    • jts_war
    • clmhelp_war
    • ccm_war
    • am_war
    • qm_war
    • rm_war
    • converter_war
    • relm_war
    • lqe_war
    • ldx_war
    • dcc_war
    • rs_war
    • gc_war
  8. When you are prompted to save the changes to the master configuration, save them.

Uninstall the previously installed applications from WebSphere Application Server

You can use the clm_undeploy.py script to remove all application WAR files that are installed on a single WebShpere Application Server.

You can use the clm_undeploy_distributed.py script to remove all application WAR files that you specify in your command argument as a comma-separated value.

  1. Start the server by opening a command windowshell and entering the following commands. Replace server1 with the name of your server:
  2. cd \bin
    startServer.bat server1

    cd /bin
    ./startServer.sh server1

Continue with the following steps to remove previous installed applications.

  1. If you backed up your WebSphere Application Server profile in the previous step, the command shut down the server. Restart the server by opening a command windowshell and entering the following commands. Replace server1 with the name of your server:
  2. cd \bin
    startServer.bat server1

    cd /bin
    ./startServer.sh server1

  3. Enter the following command to remove the application WAR files. The clm_undeploy.py script removes all application WAR files that are installed in the profile. You must also provide the location of WAR files. The default directory for the WAR files during the installation is webapps. If you used a different directory, provide that location in the command syntax.
  4. Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script.

    wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy.py /server/webapps JazzInstallDirOldVersion/server/webapps

    Enter the following command to remove the application WAR files. The clm_undeploy_distributed.py script removes all application WAR files that you specify as a comma-separated value in the command argument. Ensure there are no spaces between the application names.

  5. On the server that hosts / Link Index Provider enter the following command:
  6. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py jts,clmhelp,ldx

  7. On the server that hosts the application, enter the following command:
  8. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py ccm

  9. On the server that hosts the application, enter the following command:
  10. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py am

  11. On the server that hosts the IBM Engineering Test Management application, enter the following command:
  12. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py qm

  13. On the server that hosts the application, enter the following command:
  14. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py rm,converter

  15. On the server that hosts the application, enter the following command:
  16. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py relm

  17. On the server that hosts the Data Collection Component application, enter the following command:
  18. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py dcc

  19. On the server that hosts the Report Builder application, enter the following command:
  20. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py rs

  21. On the server that hosts the Lifecycle Query Engine application, enter the following command:
  22. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py lqe

  23. On the server that hosts the Global Configuration Management application, enter the following command:
  24. wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py gc

Update the JAZZ_HOME and configuration location custom properties

You can use the clm_was_config.py script to update JAZZ_HOME and configuration location custom properties.

Before you begin

  1. If your is installed on a Windows platform, but you are using the Db2 for z/OS database server, open the JazzInstallDir/server/was/config.py for editing.
  2. Search for db2zDriverPath=None and replace None with the file path to the location of the Db2z JDBC driver. For example: db2zDriverPath="JazzInstallDir/server/db2z". Note the forward slash and also ensure that the driver path is enclosed in quotation marks.
  3. To configure the Oracle JDBC driver location open the JazzInstallDir/server/was/config.py for editing.
  4. Search for oracleDriverPath=None and replace None with the file path to the location of the Oracle JDBC driver. For example: oracleDriverPath="". Ensure that the driver path is enclosed in quotation marks.
  5. To configure the SQL Server JDBC driver location open the JazzInstallDir/server/was/config.py for editing.
  6. Search for sqlDriverPath=None and replace None with the file path to the location of the SQL Server JDBC driver. For example: sqlDriverPath="". Ensure that the driver path is enclosed in quotation marks.
  7. Save and close the config.py file.

Procedure

  1. Open a command window as administrator and enter the following commands:
  2. Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the conf directory.

    cd \bin
    wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f C:/JazzInstallDir/server/was/clm_was_config.py C:/JazzInstallDir/server/conf -config C:/JazzInstallDir/server/was

  3. Open a command shell as administrator and enter the following commands:

    cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  4. Open a command window as administrator and enter the following commands:
  5. Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the conf directory.

    cd \bin
    wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f C:/JazzInstallDir/server/was/clm_was_config.py C:/JazzInstallDir/server/conf -config C:/JazzInstallDir/server/was

  6. On the server that host / Link Index Provider enter the following commands:
  7. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  8. On the server that host the application, enter the following commands:
  9. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  10. On the server that host the application, enter the following commands:
  11. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  12. On the server that host the IBM Engineering Test Management application, enter the following commands:
  13. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  14. On the server that host the application, enter the following commands:
  15. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  16. On the server that host the application, enter the following commands:
  17. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  18. On the server that host the Data Collection Component application, enter the following commands:
  19. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  20. On the server that host the Report Builder application, enter the following commands:
  21. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  22. On the server that host the Lifecycle Query Engine application, enter the following commands:
  23. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

  24. On the server that host the Global Configuration Management application, enter the following commands:
  25. cd /bin
    ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_was_config.py /server/conf -config /server/was

Update the JAZZ_HOME and configuration location custom properties

In a distributed topology, you must update JAZZ_HOME and configuration location custom properties on each application server that hosts the applications.

  1. Log on to the WebSphere Application Server Integrated Solutions Console at https://hostname:9043/ibm/console/logon.jsp.
  2. Click Servers > Server Types > WebSphere application servers.
  3. Click the server name to open it. The default server name is server1.
  4. Under Server Infrastructure section, click Java and Process Management > Process definition.
  5. Under Additional Properties, click Java Virtual Machine.
  6. Under Additional Properties, click Custom properties.
  7. Click JAZZ_HOME and update its value to file:///_install_dir/server/conf. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conffile:///opt/IBM/JazzTeamServer_/server/conffile:///usr/IBM/JazzTeamServer_/server/conf.
  8. Click log4j.configuration and update its value to file:///_install_dir/server/conf/startup_log4j.properties. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conf/startup_log4j.propertiesfile:///opt/IBM/JazzTeamServer_/server/conf/startup_log4j.propertiesfile:///usr/IBM/JazzTeamServer_/server/conf/startup_log4j.properties.
  9. Click lqe.config.location and update its value to file:///_install_dir/server/conf/lqe. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conf/lqefile:///opt/IBM/JazzTeamServer_/server/conf/lqefile:///usr/IBM/JazzTeamServer_/server/conf/lqe.
  10. Click ldx.config.location and update its value to file:///_install_dir/server/conf/ldx. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conf/ldxfile:///opt/IBM/JazzTeamServer_/server/conf/ldxfile:///usr/IBM/JazzTeamServer_/server/conf/ldx.
  11. If you are connecting to an Oracle database, ensure that ORACLE_JDBC_DRIVER_FILE is pointing to the correct JDBC driver file in .
  12. If you are connecting to SQL Server database, ensure that SQLSERVER_JDBC_DRIVER_FILE is pointing to the correct JDBC driver file in .
  13. Save the changes to the master configuration when prompted.

Update the JRS shared library classpath

  1. In WebSphere Integrated Solutions Console navigation pane click Environment > Shared libraries.
  2. Click the JRS shared library name in the list to open it.
  3. In the Classpath field, update the path to the new installation directory. For example:
  4. \server\conf\rs\WAS_SharedLibrary/server/conf/rs/WAS_SharedLibrary

  5. Click Apply and then Save directly to the master configuration.

Stop WebSphere Application Server

In a distributed topology, you must complete this step on each application server that hosts the applications.

  1. Open a command prompt and change to the \bin directory.
  2. Enter the following command:
  3. stopServer.bat server1 -user admin_userid -password admin_password

  1. Open a command prompt and change to the /bin directory.
  2. Enter the following command:
  3. ./stopServer.sh server1 -user admin_userid -password admin_password

  1. In QShell, navigate to the old configuration directory, for example, /QIBM/UserData/Old_JazzTeamServer/server
  2. Enter the following command:
  3. ./serverShutdown.sh profileName wasVersion wasOption adminId adminPwd

In addition to QShell, you can use the CL command. Enter QJTS50/STPJAZZSVR on the 5250 command prompt, then press PF4 to prompt for parameters. The following table shows the default values:

Command name Default value Possible values
WAS PROFILE NAME JTS Name
WAS VERSION V85 V8, V85
WAS OPTION BASE Name
WAS ADMIN USER ID JTSADMIN Name
WAS ADMIN PASSWORD None Name

Clean up the WebSphere Application Server temp directories

In a distributed topology, you must complete this step on each application server that hosts the applications.

Remove the application-related contents from the following directories in the profile:

Node_Name is the application server node name, for example, ADMINIB-SAQDV6VNode01.

  • \temp\Node_Name\server1
  • \temp\wscache
  • /temp/Node_Name/server1
  • /temp/wscache

Depending on which applications were installed, these directories might be in the profile and can be removed:

  • jts_war
  • ccm_war
  • am_war
  • qm_war
  • rm_war
  • converter_war
  • clmhelp_war
  • relm_war
  • lqe_war
  • ldx_war
  • dcc_war
  • rs_war
  • gc_war

Note: If the temp directories have files that are deeper than your MAX_PATH characters, usually 100 characters long, when you try to delete the directories, you might get an Access Denied error. For instructions to delete the directories, see the documentation for your operating system.

Clean up the logs directory

In a distributed topology, you must complete this step on each application server that hosts the applications.

Remove the application-related log files from the following logs directory in the profile:

  • \logs
  • /logs

Clear the WebSphere Application Server class cache

In a distributed topology, you must complete this step on each application server that hosts the applications.

You must clear the WebSphere Application Server class cache to ensure that after the upgrade, the server is not using the previous versions of the classes. There are two types of class cache that must be cleared, the JVM's cache and the OSGi cache. Complete the following steps to clear these caches:

  1. Stop WebSphere Application Server if it is running.
  2. To clear the OSGi class cache, open a command windowshell and enter the following command:

    cd \bin
    osgiCfgInit.bat
    /bin
    ./osgiCfgInit.sh

  3. To clear the JVM's class cache, enter the following command:

    cd \bin
    clearClassCache.bat
    /bin
    ./clearClassCache.sh

  4. Note: If you are using the Windows service to start WebSphere Application Server, the command to clear the class cache might not work. In this case you must manually empty the content of the javasharedresources directory. Make sure the service is stopped before attempting to delete the files. Here is an example of the location of the javasharedresources directory: C:\Users\USER_NAME\AppData\Local\javasharedresources. Also note that AppData might be a hidden directory.

Stop the servers

Open a command prompt and enter the following commands:

cd \server
server.shutdown.bat

Open a command shell and enter the following command:

cd /server
./server.shutdown

In a distributed topology, you must complete this step on each application server that hosts the applications.

Stop all applications first before stopping .

On the server, open a command prompt and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd \server
server.shutdown.bat

On the AM server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the QM server, open a command prompt and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd \server
server.shutdown.bat

On the RM server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the LQE server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the DCC server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the JRS server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the GC server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On , open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the server, open a command shell and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd /server
./server.shutdown

On the AM server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the QM server, open a command shell and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd /server
./server.shutdown

On the RM server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the LQE server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the DCC server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the JRS server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the GC server, open a command shell and enter the following command:

cd /server
./server.shutdown

On , open a command shell and enter the following command:

cd /server
./server.shutdown

Stop the Distributed Cache Microservice (DCM)

To stop the microservice, open a command windowshell and enter the following commands:

cd Path_To_DCM_Folder
distributedCache.stop.bat JRE_Bin_Path

cd Path_To_DCM_Folder
./distributedCache.stop.sh JRE_Bin_Path

In these commands, Path_To_DCM_Folder is the location where the Distributed Cache Microservice is installed and JRE_Bin_Path is the location of the JRE/Bin folder. The path to the Bin folder is optional. If you do not specify a path, the system uses the default location for the microservice and uses the JRE that is provided by the application.

Delete persisted data

Starting in version 6.0.6, persistence is enabled by default for the Distributed Cache Microservice. When persistence is enabled, the microservice backs up in-memory distributed caches to disk. This persisted backup is used to initialize local caches on a node that is brought online after going offline in an unplanned manner. The persisted backup enables the node to initialize to the current state.

Also, in version 6.0.6 and later, the Distributed Cache Microservice monitors the online status of the applications' nodes. When a server on a node is shut down, a signal is sent to the microservice. After all nodes of a cluster are offline, the microservice clears all persisted distributed data for that cluster.

Cluster-specific data is stored in a subfolder of the clustering folder, which is specified in the configuration file as shown in the following example:

[Cache]

# Relative or absolute location on the file system to save cache data when the microservice is offline.
# This persisted data is only needed if DCM is restarted while clustered applications are running.
# When a planned shutdown of a clustered application using the cache is underway, it is advisable to delete the persisted data.
-persistentStore = $E{PERSISTENT_STORE, distributedData}

By default, the subfolder is called distributedData. The subfolder contains a directory for each cluster with data on the Distributed Cache Microservice.

After a planned shutdown of ALL nodes in a cluster occurs, delete the folder at this location: server/clustering/cache/<distributedData>/<clusterName>. This deletion allows distributed objects to reinitialize as expected when the nodes come back online.

Copy the Lifecycle Query Engine (LQE) configuration files

  1. Before copying the LQE configuration files, go to the directory where you just installed the version application and delete the following directories if they exist. In a fresh installation, these directories should not exist. Alternatively, you can open a command prompt and enter the following commands to delete the directories.
  2. del /s /frm -rf \server\conf\lqe\indexTdb
    Enter Y to confirm the delete operation
    /server/conf/lqe/indexTdb
    del /s /frm -rf \server\conf\lqe\textIndex
    Enter Y to confirm the delete operation
    /server/conf/lqe/textIndex
    del /s /frm -rf \server\conf\lqe\shapeText
    Enter Y to confirm the delete operation
    /server/conf/lqe/shapeText
    del /s /frm -rf \server\conf\lqe\shapeTdb
    Enter Y to confirm the delete operation
    /server/conf/lqe/shapeTdb
    del /s /frm -rf \server\conf\lqe\historyText
    Enter Y to confirm the delete operation
    /server/conf/lqe/historyText
    del /s /frm -rf \server\conf\lqe\historyTdb
    Enter Y to confirm the delete operation
    /server/conf/lqe/historyTdb
  3. Enter the following commands to copy the configuration files to the new installation directory:
  4. xcopy /scp -R \server\conf\lqe\indexTdb/server/conf/lqe/indexTdb \server\conf\lqe\indexTdb
    If prompted, enter D to copy the directory structure
    /server/conf/lqe/indexTdb
    xcopy /scp -R \server\conf\lqe\textIndex/server/conf/lqe/textIndex \server\conf\lqe\textIndex
    If prompted, enter D to copy the directory structure
    /server/conf/lqe/textIndex
    xcopy /scp -R \server\conf\lqe\shapeText/server/conf/lqe/shapeText \server\conf\lqe\shapeText
    If prompted, enter D to copy the directory structure
    /server/conf/lqe/shapeText
    xcopy /scp -R \server\conf\lqe\shapeTdb/server/conf/lqe/shapeTdb \server\conf\lqe\shapeTdb
    If prompted, enter D to copy the directory structure
    /server/conf/lqe/shapeTdb
    xcopy /scp -R \server\conf\lqe\historyText/server/conf/lqe/historyText \server\conf\lqe\historyText
    If prompted, enter D to copy the directory structure
    /server/conf/lqe/historyText
    xcopy /scp -R \server\conf\lqe\historyTdb/server/conf/lqe/historyTdb \server\conf\lqe\historyTdb
    If prompted, enter D to copy the directory structure
    /server/conf/lqe/historyTdb
    copy cp \server\conf\lqe\lqe.properties/server/conf/lqe/lqe.properties \server\conf\lqe
    Enter Y to overwrite the existing file
    /server/conf/lqe
    copy cp \server\conf\lqe\lqe.node.id/server/conf/lqe/lqe.node.id \server\conf\lqe
    Enter Y to overwrite the existing file
    /server/conf/lqe
    copy cp \server\conf\lqe\lqe.key/server/conf/lqe/lqe.key \server\conf\lqe
    Enter Y to overwrite the existing file
    /server/conf/lqe
    copy cp \server\conf\lqe\dbconnection.properties/server/conf/lqe/dbconnection.properties \server\conf\lqe
    Enter Y to overwrite the existing file
    /server/conf/lqe
    If prompted, confirm that you want to overwrite the files.

Copy the Link Index Provider (LDX) configuration files

  1. Before copying the LDX configuration files, go to the directory where you just installed the version application and delete the following directories if they exist. In a fresh installation, these directories should not exist. Alternatively, you can open a command prompt and enter the following commands to delete the directories.
  2. del /s /frm -rf \server\conf\ldx\indexTdb
    Enter Y to confirm the delete operation
    /server/conf/ldx/indexTdb
    del /s /frm -rf \server\conf\ldx\textIndex
    Enter Y to confirm the delete operation
    /server/conf/ldx/textIndex
  3. Enter the following commands to copy the configuration files to the new installation directory:
  4. xcopy /scp -R \server\conf\ldx\indexTdb/server/conf/ldx/indexTdb \server\conf\ldx\indexTdb
    If prompted, enter D to copy the directory structure
    /server/conf/ldx/indexTdb
    xcopy /scp -R \server\conf\ldx\textIndex/server/conf/ldx/textIndex \server\conf\ldx\textIndex
    If prompted, enter D to copy the directory structure
    /server/conf/ldx/textIndex
    copy cp \server\conf\ldx\lqe.properties/server/conf/ldx/lqe.properties \server\conf\ldx
    Enter Y to overwrite the existing file
    /server/conf/ldx
    copy cp \server\conf\ldx\lqe.node.id/server/conf/ldx/lqe.node.id \server\conf\ldx
    Enter Y to overwrite the existing file
    /server/conf/ldx
    copy cp \server\conf\ldx\lqe.key/server/conf/ldx/lqe.key \server\conf\ldx
    Enter Y to overwrite the existing file
    /server/conf/ldx
    copy cp \server\conf\ldx\dbconnection.properties/server/conf/ldx/dbconnection.properties \server\conf\ldx
    Enter Y to overwrite the existing file
    /server/conf/ldx
    If prompted, confirm that you want to overwrite the files.

Copy the Derby database from previous installation directory to the new installation directory

  1. Before copying the Derby database, go to the directory where you just installed the version application and delete the content of Derby directory if exist. Alternatively, you can open a command prompt and enter the following commands to clear the default version Derby directory.
  2. Note: In a fresh installation, there is no derbyDB under the lqe directory. But if you have already started the server, there might be a derbyDB directory that should be deleted.

    Enter the following command to delete the Lifecycle Query Engine Derby database if exists:

    del /s /f \server\conf\lqe\derbyDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Lifecycle Query Engine Derby database if exists:

    rm -rf /server/conf/lqe/derbyDB

  3. Go to the directory where you previously installed the application, copy the Derby database, and paste it in the equivalent directory for version . You can also open a command prompt and enter the following commands to copy the Derby database.
  4. Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.

    Enter the following command to copy the database:

    xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
    If prompted, enter D to choose directory.

    Enter the following command to copy the Lifecycle Query Engine database:

    xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
    If prompted, enter D to choose directory.

    Enter the following command to copy the Lifecycle Query Engine database:

    cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB

    Enter the following command to copy the Lifecycle Query Engine database:

    cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB

Copy the Derby databases from the previous installation directory to the new installation directory

  1. Before copying the Derby database, go to the directory where you just installed the version applications and delete the content of Derby directory. Alternatively, you can open a command prompt and enter the following commands to clear the default version Derby directories.
  2. Note: In a fresh installation, there is no derbyDB under the ldx directory. But if you have already started the server, there might be a derbyDB directory that should be deleted.

    Enter the following command to delete the Derby database:

    del /s /f \server\conf\jts\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to copy the Derby database:

    Note: Since AM is an extension of CCM, no separate command is required for AM.

    del /s /f \server\conf\ccm\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Derby database:

    del /s /f \server\conf\am\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the IBM Engineering Test Management Derby database:

    del /s /f \server\conf\qm\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Derby database:

    del /s /f \server\conf\rm\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Derby database:

    del /s /f \server\conf\relm\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Global Configuration Management Derby database:

    del /s /f \server\conf\gc\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Data Collection Component Derby database:

    del /s /f \server\conf\dcc\derby\repositoryDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Link Index Provider Derby database if exists:

    del /s /f \server\conf\ldx\derbyDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Link Index Provider Derby database if exists:

    del /s /f \server\conf\ldx\derbyDB
    Enter Y to confirm the delete operation

    Enter the following command to delete the Derby database:

    rm -rf /server/conf/jts/derby/repositoryDB

    Enter the following command to copy the Derby database:

    Note: Since AM is an extension of CCM, no separate command is required for AM.

    rm -rf /server/conf/ccm/derby/repositoryDB

    Enter the following command to delete the Derby database:

    rm -rf /server/conf/am/derby/repositoryDB

    Enter the following command to delete the IBM Engineering Test Management Derby database:

    rm -rf /server/conf/qm/derby/repositoryDB

    Enter the following command to delete the Derby database:

    rm -rf /server/conf/rm/derby/repositoryDB

    Enter the following command to delete the Derby database:

    rm -rf /server/conf/relm/derby/repositoryDB

    Enter the following command to delete the Global Configuration Management Derby database:

    rm -rf /server/conf/gc/derby/repositoryDB

    Enter the following command to delete the Data Collection Component Derby database:

    rm -rf /server/conf/dcc/derby/repositoryDB

    Enter the following command to delete the Link Index Provider Derby database if exists:

    rm -rf /server/conf/ldx/derbyDB

  3. Go to the directory where you previously installed the applications, copy the Derby database, and paste it in the equivalent directory for version . You can also open a command prompt and enter the following commands to copy the Derby database.
  4. Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.

    Enter the following command to copy the database:

    xcopy /s \server\conf\jts\derby\repositoryDB \server\conf\jts\derby\repositoryDB

    Enter the following command to copy the database:

    Note: Since AM is an extension of CCM, no separate command is required for AM.

    xcopy /s \server\conf\ccm\derby\repositoryDB \server\conf\ccm\derby\repositoryDB

    Enter the following command to copy the database:

    xcopy /s \server\conf\am\derby\repositoryDB \server\conf\am\derby\repositoryDB

    Enter the following command to copy the IBM Engineering Test Management database:

    xcopy /s \server\conf\qm\derby\repositoryDB \server\conf\qm\derby\repositoryDB

    Enter the following command to copy the database:

    xcopy /s \server\conf\rm\derby\repositoryDB \server\conf\rm\derby\repositoryDB

    Enter the following command to copy the database:

    xcopy /s \server\conf\relm\derby\repositoryDB \server\conf\relm\derby\repositoryDB

    Enter the following command to copy the Global Configuration Management database:

    xcopy /s \server\conf\gc\derby\repositoryDB \server\conf\gc\derby\repositoryDB

    Enter the following command to copy the Data Collection Component database:

    xcopy /s \server\conf\dcc\derby\repositoryDB \server\conf\dcc\derby\repositoryDB

    Enter the following command to copy the Lifecycle Query Engine database:

    xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
    If prompted, enter D to choose directory.

    Enter the following command to copy the Link Index Provider database:

    xcopy /s \server\conf\ldx\derbyDB \server\conf\ldx\derbyDB
    If prompted, enter D to choose directory.

    The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:

    cd \server
    server.startup -create

    Enter the following command to copy the Data Warehouse database:

    xcopy /s \server\conf\jts\derby\warehouseDB\server\liberty\servers\clm\conf\jts\derby\warehouseDB \server\liberty\servers\clm\conf\jts\derby\warehouseDB

    Enter D for directory.

    Enter the following command to copy the database:

    xcopy /s \server\conf\jts\derby\repositoryDB \server\conf\jts\derby\repositoryDB

    Enter the following command to copy the database:

    xcopy /s \server\conf\rm\derby\repositoryDB \server\conf\rm\derby\repositoryDB

    Enter the following command to copy the database:

    Note: Since AM is an extension of CCM, no separate command is required for AM.

    xcopy /s \server\conf\ccm\derby\repositoryDB \server\conf\ccm\derby\repositoryDB

    Enter the following command to copy the database:

    xcopy /s \server\conf\am\derby\repositoryDB \server\conf\am\derby\repositoryDB

    Enter the following command to copy the IBM Engineering Test Management database:

    xcopy /s \server\conf\qm\derby\repositoryDB \server\conf\qm\derby\repositoryDB

    Enter the following command to copy the database:

    xcopy /s \server\conf\relm\derby\repositoryDB \server\conf\relm\derby\repositoryDB

    Enter the following command to copy the Global Configuration Management database:

    xcopy /s \server\conf\gc\derby\repositoryDB \server\conf\gc\derby\repositoryDB

    Enter the following command to copy the Data Collection Component database:

    xcopy /s \server\conf\dcc\derby\repositoryDB \server\conf\dcc\derby\repositoryDB

    Enter the following command to copy the Lifecycle Query Engine database:

    xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
    If prompted, enter D to choose directory.

    Enter the following command to copy the Link Index Provider database:

    xcopy /s \server\conf\ldx\derbyDB \server\conf\ldx\derbyDB
    If prompted, enter D to choose directory.

    The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:

    cd \server
    server.startup -create

    Enter the following command to copy the Data Warehouse database:

    xcopy /s \server\conf\jts\derby\warehouseDB\server\liberty\servers\clm\conf\jts\derby\warehouseDB \server\liberty\servers\clm\conf\jts\derby\warehouseDB

    Enter D for directory.

    In a WebSphere Application Sever deployment, the default data warehouse database location is under WebSphere installation directory.

    Enter the following command to copy the Data Warehouse database:

    xcopy /s WAS_install_dir\OldAppServerHostIntall\jts\derby\conf\warehouseDB WAS_install_dir\AppServerHost6Intall\jts\derby\conf\warehouseDB

    Enter D for directory.

    Enter the following command to copy the database:

    cp -R /server/conf/jts/derby/repositoryDB /server/conf/jts/derby/repositoryDB

    Enter the following command to copy the database:

    Note: Since AM is an extension of CCM, no separate command is required for AM.

    cp -R /server/conf/ccm/derby/repositoryDB /server/conf/ccm/derby/repositoryDB

    Enter the following command to copy the database:

    cp -R /server/conf/am/derby/repositoryDB /server/conf/am/derby/repositoryDB

    Enter the following command to copy the IBM Engineering Test Management database:

    cp -R /server/conf/qm/derby/repositoryDB /server/conf/qm/derby/repositoryDB

    Enter the following command to copy the database:

    cp -R /server/conf/rm/derby/repositoryDB /server/conf/rm/derby/repositoryDB

    Enter the following command to copy the database:

    cp -R /server/conf/relm/derby/repositoryDB /server/conf/relm/derby/repositoryDB

    Enter the following command to copy the Global Configuration Management database:

    cp -R /server/conf/gc/derby/repositoryDB /server/conf/gc/derby/repositoryDB

    Enter the following command to copy the Data Collection Component database:

    cp -R /server/conf/dcc/derby/repositoryDB /server/conf/dcc/derby/repositoryDB

    Enter the following command to copy the Lifecycle Query Engine database:

    cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB

    Enter the following command to copy the Link Index Provider database:

    cp -R /server/conf/ldx/derbyDB /server/conf/ldx/derbyDB

    The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:

    cd /server
    ./server.startup -create

    Enter the following command to copy the Data Warehouse database:

    cp -R /server/conf/jts/derby/warehouseDB/server/liberty/servers/clm/conf/jts/derby/warehouseDB /server/liberty/servers/clm/conf/jts/derby/warehouseDB

    Enter the following command to copy the database:

    cp -R /server/conf/jts/derby/repositoryDB /server/conf/jts/derby/repositoryDB

    Enter the following command to copy the database:

    cp -R /server/conf/rm/derby/repositoryDB /server/conf/rm/derby/repositoryDB

    Enter the following command to copy the database:

    Note: Since AM is an extension of CCM, no separate command is required for AM.

    cp -R /server/conf/ccm/derby/repositoryDB /server/conf/ccm/derby/repositoryDB

    Enter the following command to copy the database:

    cp -R /server/conf/am/derby/repositoryDB /server/conf/am/derby/repositoryDB

    Enter the following command to copy the IBM Engineering Test Management database:

    cp -R /server/conf/qm/derby/repositoryDB /server/conf/qm/derby/repositoryDB

    Enter the following command to copy the database:

    cp -R /server/conf/relm/derby/repositoryDB /server/conf/relm/derby/repositoryDB

    Enter the following command to copy the Global Configuration Management database:

    cp -R /server/conf/gc/derby/repositoryDB /server/conf/gc/derby/repositoryDB

    Enter the following command to copy the Data Collection Component database:

    cp -R /server/conf/dcc/derby/repositoryDB /server/conf/dcc/derby/repositoryDB

    Enter the following command to copy the Lifecycle Query Engine database:

    cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB

    Enter the following command to copy the Link Index Provider database:

    cp -R /server/conf/ldx/derbyDB /server/conf/ldx/derbyDB

    The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:

    cd /server
    ./server.startup -create

    Enter the following command to copy the Data Warehouse database:

    cp -R /server/conf/jts/derby/warehouseDB/server/liberty/servers/clm/conf/jts/derby/warehouseDB /server/liberty/servers/clm/conf/jts/derby/warehouseDB

    In a WebSphere Application Sever deployment, the default data warehouse database location is under WebSphere installation.

    Enter the following command to copy the Data Warehouse database:

    cp -R WAS_install_dir/OldAppServerHostIntall/jts/derby/conf/warehouseDB WAS_install_dir/AppServerHost6Intall/jts/derby/conf/warehouseDB

Copy the index files

Attention: Do these steps only if the index files in the teamserver.properties files are located on relative paths or on absolute paths to unstable directories. An example of an unstable directory is old_install_dir. If the index files are in that directory and the directory is uninstalled, you will lose your index files.

Important: This upgrade requires all existing full-text search indexes to be rebuilt. By default, the workitemindex folder contains the full-text index files and is located under JazzInstallDir/server/conf/app/indices. If the workitemindex folder is configured in a different location, such as the WebSphere Application Server profile directory, do not copy the old files. If the workitemindex folder is located at the default location under JazzInstallDir/server/conf/app/indices, after copying the JFS index files, make sure you delete all files in the workitemindex folder. For more details, see this workaround document.

Copy your JFS/text indices from previous installation directory to . For distributed systems go to the appropriate server and copy the files.

  1. Open a command prompt and enter this command to clear the default version indices directory:
    del /s /f \server\conf\jts\indices
    del /s /f \server\conf\ccm\indices
    del /s /f \server\conf\am\indices
    del /s /f \server\conf\qm\indices
    del /s /f \server\conf\dcc\indices
    del /s /f \server\conf\relm\indices
    del /s /f \server\conf\gc\indices

    Enter Y to confirm the delete operation
    rm -rf /server/conf/jts/indices
    rm -rf /server/conf/ccm/indices
    rm -rf /server/conf/am/indices
    rm -rf /server/conf/qm/indices
    rm -rf /server/conf/dcc/indices
    rm -rf /server/conf/relm/indices
    rm -rf /server/conf/gc/indices
  2. Open a command prompt and enter this command to copy the indices from the previous installation to version :
    xcopy /s \server\conf\jts\indices \server\conf\jts\indices
    xcopy /s \server\conf\ccm\indices \server\conf\ccm\indices
    xcopy /s \server\conf\am\indices \server\conf\am\indices
    xcopy /s \server\conf\qm\indices \server\conf\qm\indices
    xcopy /s \server\conf\dcc\indices \server\conf\dcc\indices
    xcopy /s \server\conf\relm\indices \server\conf\relm\indices
    xcopy /s \server\conf\gc\indices \server\conf\gc\indices
    cp -R /server/conf/jts/indices /server/conf/jts/indices
    cp -R /server/conf/ccm/indices /server/conf/ccm/indices
    cp -R /server/conf/am/indices /server/conf/am/indices
    cp -R /server/conf/qm/indices /server/conf/qm/indices
    cp -R /server/conf/dcc/indices /server/conf/dcc/indices
    cp -R /server/conf/relm/indices /server/conf/relm/indices
    cp -R /server/conf/gc/indices /server/conf/gc/indices
  3. Ensure to delete the content of the workitemindex folder.

To copy your JFS/text indices from a previous installation to version , follow these steps. For distributed systems, go to the appropriate server and copy the files.

  1. Open a command prompt and enter this command to clear the default version indices directory:
    Del /s /f \server\conf\jts\indices
    Del /s /f \server\conf\ccm\indices
    Del /s /f \server\conf\am\indices
    Del /s /f \server\conf\qm\indices
    Del /s /f \server\conf\dcc\indices
    Del /s /f \server\conf\relm\indices
    Del /s /f \server\conf\gc\indices
    rm -rf /server/conf/jts/indices
    rm -rf /server/conf/ccm/indices
    rm -rf /server/conf/am/indices
    rm -rf /server/conf/qm/indices
    rm -rf /server/conf/dcc/indices
    rm -rf /server/conf/relm/indices
    rm -rf /server/conf/gc/indices
  2. In the following location open the teamserver.properties file and search for com.ibm.team.fulltext.indexlocation and com.ibm.team.jfs.index.root.directory:
    • \server\conf\jts\/server/conf/jts/teamserver.properties
    • \server\conf\qm\/server/conf/qm/teamserver.properties
    • \server\conf\ccm\/server/conf/ccm/teamserver.properties
    • \server\conf\am\/server/conf/am/teamserver.properties
    • \server\conf\dcc\/server/conf/dcc/teamserver.properties
    • \server\conf\relm\/server/conf/relm/teamserver.properties
    • \server\conf\gc\/server/conf/gc/teamserver.properties
  3. If the com.ibm.team.fulltext.indexLocation and com.ibm.team.jfs.index.root.directory properties are pointing to a relative path, for example, com.ibm.team.fulltext.indexLocation=conf/application_context_root/indices/workitemindex, depending on how the previous version of the application was installed or customized, the work item index and JFS index root might be located relative to the WebSphere Application Server profile hosting the applications. For example: , or relative to the application's installation directory.

    Change this relative path to an absolute path to a stable location. An example of absolute stable location for work item index looks like this: com.ibm.team.fulltext.indexLocation=_install_dir/server/conf/application_context_root/indices/workitemindex where _install_dir is the location where application is installed. An example of absolute stable location for JFS index root looks like this: com.ibm.team.jfs.index.root.directory=_install_dir/server/conf/application_context_root/indices where _install_dir is the location where application is installed.

    If the com.ibm.team.fulltext.indexLocation or com.ibm.team.jfs.index.root.directory properties are pointing to an unstable absolute path, such as path to the old_install_dir directory that might be uninstalled and deleted, change the path to an absolute path that points to a stable location as mentioned previously.

  4. Open a command prompt and enter the following command to copy the full text indices from previous version to . Change the source directory according to the location of the index files:

  5. xcopy /s \server\conf\jts\indices \server\conf\jts\indices
    xcopy /s \server\conf\ccm\indices \server\conf\ccm\indices
    xcopy /s \server\conf\am\indices \server\conf\am\indices
    xcopy /s \server\conf\qm\indices \server\conf\qm\indices
    xcopy /s \server\conf\dcc\indices \server\conf\dcc\indices
    xcopy /s \server\conf\relm\indices \server\conf\relm\indices
    xcopy /s \server\conf\gc\indices \server\conf\gc\indices
    cp -R /server/conf/jts/indices /server/conf/jts/indices
    cp -R /server/conf/ccm/indices /server/conf/ccm/indices
    cp -R /server/conf/am/indices /server/conf/am/indices
    cp -R /server/conf/qm/indices /server/conf/qm/indices
    cp -R /server/conf/dcc/indices /server/conf/dcc/indices
    cp -R /server/conf/relm/indices /server/conf/relm/indices
    cp -R /server/conf/gc/indices /server/conf/gc/indices
  6. Make sure you delete the content of the workitemindex folder.

Undo custom performance optimization

A performance optimization for SQL Server was introduced in version 6.0 for the database which might result in a failed upgrade if left in place. Open a sqlcmd command line tool and enter the following commands to return the database to an expected state before running the upgrade scripts.

DROP INDEX VERSION_CONCEPT_DX ON VVCMODEL.VERSION
DROP INDEX VERSION_STORAGE_DX ON VVCMODEL.VERSION

Note: You might be prompted for the following error message if the optimization has never been applied before, or you do not have permission to drop index on the database. If you do have permission and you are prompted for the error, you can skip the DROP INDEX command.

"Msg 3701, Level 11, State 7, Line 1
Cannot drop the index 'VVCMODEL.VERSION.VERSION_CONCEPT_DX', because it does not exist or you do not have permission.
Msg 3701, Level 11, State 7, Line 2
Cannot drop the index 'VVCMODEL.VERSION.VERSION_STORAGE_DX', because it does not exist or you do not have permission."

ALTER TABLE VVCMODEL.VERSION ALTER COLUMN CONCEPT NVARCHAR(1000)
ALTER TABLE VVCMODEL.VERSION ALTER COLUMN STORAGE NVARCHAR(1000)

Run the upgrade commands

In a distributed environment where applications are installed on separate servers and you want to upgrade all applications from one server (to use either the Upgrade script or Upgrade script in silent mode options), you must be able to access the drive or file system where other applications are installed. The mounted drive must be configured with read-write-execute privileges for the administrator account. chmod -R 777 /opt/IBM/JazzTeamServer. If you cannot access the shared drives from one server, then select Manual Upgrade optionand physically go to each server and perform the upgrade. If using network shares on Windows systems for example, the mount must be in this format: mounted drive letter:\server\conf. An absolute path, such as \\computer name\JTS__install_dir\server\conf, will not work.On UNIX systems for example, the mount must be in this format: mount -t nfs IP Address of the server:/opt/IBM/JazzTeamServer.

Upgrading

To upgrade configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-jts.bat -migration_jts_updateConfigurationFiles oldJTSHome=\server\conf updateAppServerFiles=no jtsContextRoot=repositoryURL=https://hostname.example.com:port/jts
repotools-jts.bat -addTables
repotools-jts.bat -upgradeWarehouse repotools-jts.bat -updateLPASampleTemplates

To upgrade configuration files, open a command shell and enter the following commands:

cd /server
./repotools-jts.sh -migration_jts_updateConfigurationFiles oldJTSHome=/server/conf updateAppServerFiles=no jtsContextRoot=
./repotools-jts.sh -addTables ./repotools-jts.sh -upgradeWarehouse ./repotools-jts.sh -updateLPASampleTemplates

Communicate Tomcat users temporary passwords

Tomcat user registry only: If you used a Tomcat user registry in your previous installation, the migration command creates a file named passwords.txt in the /\server directory that contains all repository users from the tomcat-users.xml file. Because the tomcat-users.xml file stores one-way-encrypted passwords, it is not possible to migrate these user passwords. Instead, the passwords.txt file contains temporary passwords for each user, which the server administrator must communicate to the users. After the server is started, users can change their temporary passwords.

Upgrading the Global Configuration Management application

To upgrade the GC application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-gc.bat -migration_gc_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-gc.bat -addTables

To upgrade the GC application configuration files, open a command shell and enter the following commands:

cd /server
./repotools-gc.sh -migration_gc_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-gc.sh -addTables

Upgrading Report Builder

You can use the rs_upgrade wrapper script to upgrade the Report Builder application in this configuration with the -ignoreJTSVersionCheck flag so that the script does not try to connect to to check its version. You must make sure that is already upgraded before you attempt to upgrade the Report Builder application. Open a command prompt and enter the following commands. Note that wrapper script command arguments are different from repotools commands. You do not need an equal sign (=) for -oldApplicationHome, but you need to add a dash sign (-) before each argument, such as -oldApplicationHome or -ignoreJTSVersionCheck:

cd \/server
upgrade\rs\rs_upgrade.batupgrade/rs/rs_upgrade.sh -oldApplicationHome \server\conf/server/conf -ignoreJTSVersionCheck -applicationContextRoot -jtsContextRoot

Upgrading the application

To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-am.bat -migration_ccm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-am.bat -addTables

To upgrade the application configuration files, open a command shell and enter the following commands:

cd /server
./repotools-am.sh -migration_ccm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-am.sh -addTables

Upgrading the application

Note: Starting with version 7.x, application is provided as an extension to ; therefore, it is automatically upgraded along with the application.

To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-ccm.bat -migration_ccm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-ccm.bat -addTables

To upgrade the application configuration files, open a command shell and enter the following commands:

cd /server
./repotools-ccm.sh -migration_ccm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-ccm.sh -addTables

Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.

Upgrading the () application

To upgrade the application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-relm.bat -migration_relm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-relm.bat -addTables

To upgrade the application configuration files, open a command shell and enter the following commands:

cd /server
./repotools-relm.sh -migration_relm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-relm.sh -addTables

Upgrading the Data Collection Component application

Note: If you are not upgrading your application at this time, you must have one of the following versions installed for the ETLs to run successfully:

version 6.0.2 or later with the latest interim fix

To upgrade the DCC application configuration files, open a command window and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-dcc.bat -migration_dcc_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-dcc.bat -addTables

To upgrade the DCC application configuration files, open a command shell and enter the following commands:

cd /server
./repotools-dcc.sh -migration_dcc_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-dcc.sh -addTables

Upgrading the IBM Engineering Test Management application

Before you start the IBM Engineering Test Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.

For information about the Oracle database DBMS_STATS command, see the Oracle documentation.

For information about the SQL Server database Update Statistics command, see the SQL Server documentation.

To upgrade the QM application configuration files, open a command prompt and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

cd \server
repotools-qm.bat -migration_qm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
repotools-qm.bat -addTables
cd /server
./repotools-qm.sh -migration_qm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= jtsContextRoot=
./repotools-qm.sh -addTables

Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.

Upgrading the application

Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.

For information about the Oracle database DBMS_STATS command, see the Oracle documentation.

For information about the SQL Server database Update Statistics command, see the SQL Server documentation.

To upgrade the RM application configuration files and to migrate the link validity data, open a command window and enter the following commands. If the path contains spaces, make sure that the path is enclosed in double-quotation marks:

Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

cd \server
repotools-rm.bat -migration_rm_updateConfigurationFiles oldApplicationHome=\server\conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot= newJTSContextRoot=

repotools-rm.bat -rmExportLinkValidity repositoryURL=https://host_name:port/jts adminUserId=admin_user_id adminPassword=admin_password

repotools-rm.bat -addTables
repotools-rm.bat -rmImportLinkValidity repositoryURL=https://host_name:port/jts adminUserId=admin_user_id adminPassword=admin_password

To upgrade the RM application configuration files and to migrate the link validity data, open a command shell and enter the following commands:

Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

cd /server
./repotools-rm.sh -migration_rm_updateConfigurationFiles oldApplicationHome=/server/conf ignoreJTSVersionCheck updateAppServerFiles=no applicationContextRoot=newJTSContextRoot=

./repotools-rm.sh -rmExportLinkValidity repositoryURL=https://host_name:port/jts adminUserId=admin_user_id adminPassword=admin_password

./repotools-rm.sh -addTables
./repotools-rm.sh -rmImportLinkValidity repositoryURL=https://host_name:port/jts adminUserId=admin_user_id adminPassword=admin_password

Optional: Create an environment variable to change the default verification level

There is a migration verification done for after the upgrade that generates a report in the server directory. By default, this report contains 10% (value of 1) of the migration verification. You can create an environment variable and set the verification to the level that you want. A value of 0 does not validate anything and no report is generated. A value of 10 produces a report with all data validation. The higher the percentage of the data to be validated, the more time is required to complete the upgrade.

To create an environment variable follow these steps:

  1. Open Control Panel and click System.
  2. Click Advanced system settings and then click Environment Variables.
  3. Under System variables click New.
  4. In the Variable name field enter validateData and in the Variable value field enter a number between 0 and 10.

    Note: The variable name must be typed exactly as shown.

  5. Restart your system for the environment variable to take effect.
  6. The report generation is automatic and a report named MigrationValidation.html is created in the _install_dir\server directory. Subsequent generated reports will have a time stamped after the file name.

  1. Open a command shell and enter:
  2. export validateData=a number between 0 and 10

    Note: The variable name must be typed exactly as shown.

    The report generation is automatic and a report named MigrationValidation.html is created in the _install_dir/server directory. Subsequent generated reports will have a time stamped after the file name.

Run the upgrade script

This script uses Repository Tools commands to update the configuration files and update the databases and data warehouse schemas to version . Follow the on-screen prompts to upgrade your application. For more information, see Upgrade script files.

In a distributed environment where applications are installed on separate servers and you want to upgrade all applications from one server (to use either the Upgrade script or Upgrade script in silent mode options), you must be able to access the drive or file system where other applications are installed. The mounted drive must be configured with read-write-execute privileges for the administrator account. chmod -R 777 /opt/IBM/JazzTeamServer. If you cannot access the shared drives from one server, then select Manual Upgrade option and physically go to each server and perform the upgrade. If using network shares on Windows systems for example, the mount must be in this format: mounted drive letter:\server\conf. An absolute path, such as \\computer name\JTS__install_dir\server\conf, will not work.On UNIX systems for example, the mount must be in this format: mount -t nfs IP Address of the server:/opt/IBM/JazzTeamServer.

Important: Although the script file is in the upgrade/application context root directory, the file must be run from the server directory. Also if your path includes spaces, ensure that is enclosed in double quotation marks.

Before you Begin: Ensure that you have a JDBC environment variable that points to the ojdbc8.jar located in the directory. For more information, see Setting up an Oracle database.

Upgrading

To upgrade open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\jts\jts_upgrade.bat -oldJTSHome "\server\conf" -updateAppServerFiles no -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt
cd \server
upgrade\jts\jts_upgrade.bat -oldJTSHome "\server\conf" -updateAppServerFiles no -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, a window opens in which you can check the teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.

An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=JTS__install_dir/server/conf/jts/indices/workitemindex, where JTS__install_dir is the location where is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Communicate Tomcat users temporary passwords

Tomcat user registry only: If you used a Tomcat user registry in your previous installation, the migration command creates a file named passwords.txt in the \server directory that contains all repository users from the tomcat-users.xml file. Because the tomcat-users.xml file stores one-way-encrypted passwords, it is not possible to migrate these user passwords. Instead, the passwords.txt file contains temporary passwords for each user, which the server administrator must communicate to the users. After the server is started, users can change their temporary passwords.

Upgrading the Global Configuration Management application

To upgrade the Global Configuration Management application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\gc\gc_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\gc\gc_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, a window opens in which you can check the Global Configuration Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.

An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=GC__install_dir/server/conf/gc/indices/workitemindex where GC__install_dir is the location where the Global Configuration Management application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the application

To upgrade application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\am\ccm_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\am\ccm_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, a window opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.

An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/am/indices/workitemindex where CCM__install_dir is the location where is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the application

Note: Starting with version 7.x, application is provided as an extension to ; therefore, it is automatically upgraded along with the application.

To upgrade application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\ccm\ccm_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\ccm\ccm_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, a window opens in which you can check the Change and Configuration teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.

An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/ccm/indices/workitemindex where CCM__install_dir is the location where application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.

Upgrading the application

To upgrade the application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\relm\relm_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\relm\relm_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, a window opens in which you can check the teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.

An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=__install_dir/server/conf/relm/indices/workitemindex where __install_dir is the location where the application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the Data Collection Component application

Note: If you are not upgrading your application at this time, you must have one of the following versions installed for the ETLs to run successfully:

version 6.0.2 or later with the latest interim fix

To upgrade the Data Collection Component application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\dcc\dcc_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\dcc\dcc_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

During the upgrade, after the configuration files are merged, a window opens in which you can check the Data Collection Component teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled.

An absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=DCC__install_dir/server/conf/dcc/indices/workitemindex where DCC__install_dir is the location where the Data Collection Component application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the Report Builder application

To upgrade the Report Builder application open a command prompt with administrative privileges and enter the following commands:

If you used any ready-to-use reports in the previous release and want to import them during the upgrade, use the importReportsOnStartup parameter.

cd \server
upgrade\rs\rs_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\rs\rs_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

During the upgrade, after the configuration files are merged, a window opens in which you can check the Report Builder app.properties file.

Upgrading the Lifecycle Query Engine application

To upgrade the Lifecycle Query Engine application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\lqe\lqe_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\lqe\lqe_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

During the upgrade, after the configuration files are merged, a window opens in which you can check the Lifecycle Query Engine lqe.properties file.

Upgrading the Link Index Provider application

To upgrade the Link Index Provider application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\ldx\ldx_upgrade.bat -oldApplicationHome "\server\conf" -newApplicationHome "\server\conf" -applicationContextRoot -jtsContextRoot
cd \server
upgrade\ldx\ldx_upgrade.bat -oldApplicationHome "\server\conf" -newApplicationHome "\server\conf" -applicationContextRoot -jtsContextRoot

Upgrading the IBM Engineering Test Management application

Before you start the IBM Engineering Test Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.

For information about the Oracle database DBMS_STATS command, see the Oracle documentation.

For information about the SQL Server database Update Statistics command, see the SQL Server documentation.

To upgrade IBM Engineering Test Management application open a command prompt with administrative privileges and enter the following commands:

cd \server
upgrade\qm\qm_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd \server
upgrade\qm\qm_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, a window opens in which you can check the IBM Engineering Test Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=QM__install_dir/server/conf/qm/indices/workitemindex where QM__install_dir is the location where IBM Engineering Test Management application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the application

Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.

For information about the Oracle database DBMS_STATS command, see the Oracle documentation.

For information about the SQL Server database Update Statistics command, see the SQL Server documentation.

To upgrade the application open a command window with administrative privileges and enter the following commands:

cd \server
upgrade\rm\rm_upgrade.bat -oldApplicationHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

To upgrade the application that is installed on the same server as and migrate the link validity data, see this deployment wiki document.

To upgrade application open a command prompt with administrative privileges and enter the following commands:

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

Important: It is assumed that you have upgraded and deployed and all other applications except for the application and performed all the necessary pre-upgrade steps. To learn about link validity data migration and its options, see the rm_upgrade script topic.

Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.

cd \server
upgrade\rm\rm_upgrade.bat -oldApplicationHome "\server\conf" -newJTSHome "\server\conf" -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt -jtsRepositoryUrl https://host_name:port/jts -adminUserId admin_user_id -adminPassword admin_password

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading

To upgrade open a command shell and enter the following commands:

cd /server
upgrade/jts/jts_upgrade.sh -oldJTSHome /server/conf -updateAppServerFiles no -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt
cd /server
upgrade/jts/jts_upgrade.sh -oldJTSHome /server/conf -updateAppServerFiles no -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=JTS__install_dir/server/conf/jts/indices/workitemindex where JTS__install_dir is the location where is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Communicate Tomcat users temporary passwords

Tomcat user registry only: If you used a Tomcat user registry in your previous installation, the migration command creates a file named passwords.txt in the /server directory that contains all repository users from the tomcat-users.xml file. Because the tomcat-users.xml file stores one-way-encrypted passwords, it is not possible to migrate these user passwords. Instead, the passwords.txt file contains temporary passwords for each user, which the server administrator must communicate to the users. After the server is started, users can change their temporary passwords.

Upgrading the Global Configuration Management application

To upgrade the Global Configuration Management application open a command shell and enter the following commands:

cd /server
upgrade/gc/gc_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/gc/gc_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, an editor opens in which you can check the Global Configuration Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=GC__install_dir/server/conf/gc/indices/workitemindex where GC__install_dir is the location where Global Configuration Management application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the application

To upgrade the application open a command shell and enter the following commands:

cd /server
upgrade/am/ccm_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/am/ccm_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/am/indices/workitemindex where CCM__install_dir is the location where is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the application

Note: Starting with version 7.x, application is provided as an extension to ; therefore, it is automatically upgraded along with the application.

To upgrade the application open a command shell and enter the following commands:

cd /server
upgrade/ccm/ccm_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/ccm/ccm_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=CCM__install_dir/server/conf/ccm/indices/workitemindex where CCM__install_dir is the location where application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Note: In a clustered environment, upgrade only the first node. You will replicate this node in a later step.

Upgrading the application

To upgrade the application open a command shell and enter the following commands:

cd /server
upgrade/relm/relm_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/relm/relm_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=__install_dir/server/conf/relm/indices/workitemindex where __install_dir is the location where the application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the Data Collection Component application

Note: If you are not upgrading your application at this time, you must have one of the following versions installed for the ETLs to run successfully:

version 6.0.2 or later with the latest interim fix

To upgrade the Data Collection Component application open a command shell and enter the following commands:

cd /server
upgrade/dcc/dcc_upgrade.sh -oldApplicationHome /server/conf no -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/dcc/dcc_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

During the upgrade, after the configuration files are merged, an editor opens in which you can check the Data Collection Component teamserver.properties file. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=DCC__install_dir/server/conf/dcc/indices/workitemindex where DCC__install_dir is the location where Data Collection Component application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the Report Builder application

Copy the Report Builder report results data from the previous web server's working directory to new web server's working directory.
For example, in case of WASLiberty Profile:
Previous Location: <previous JTS Install dir>/server/liberty/servers/clm/ExportResults
New Location: <new JTS Install dir>/server/liberty/servers/clm/ExportResults


To upgrade the Report Builder application open a command shell and enter the following commands:

If you used any ready-to-use reports in the previous release and want to import them during the upgrade, use the importReportsOnStartup parameter.

cd /server
upgrade/rs/rs_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/rs/rs_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

During the upgrade, after the configuration files are merged, a window opens in which you can check the Report Builder app.properties file.

Upgrading the Lifecycle Query Engine application

To upgrade the Lifecycle Query Engine application open a command prompt with administrative privileges and enter the following commands:

cd /server
upgrade/lqe/lqe_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/lqe/lqe_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor

During the upgrade, after the configuration files are merged, a window opens in which you can check the Lifecycle Query Engine lqe.properties file.

Upgrading the Link Index Provider application

To upgrade the Link Index Provider application open a command prompt with administrative privileges and enter the following commands:

cd /server
upgrade/ldx/ldx_upgrade.sh -oldApplicationHome /server/conf -newApplicationHome /server/conf -applicationContextRoot -jtsContextRoot
cd /server
upgrade/ldx/ldx_upgrade.sh -oldApplicationHome /server/conf -newApplicationHome /server/conf -applicationContextRoot -jtsContextRoot

Upgrading the IBM Engineering Test Management application

Before you start the IBM Engineering Test Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.

For information about the Oracle database DBMS_STATS command, see the Oracle documentation.

For information about the SQL Server database Update Statistics command, see the SQL Server documentation.

To upgrade IBM Engineering Test Management application open a command shell and enter the following commands:

cd /server
upgrade/qm/qm_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

Ensure that you can connect to with the network path you use in the -newJTSHome argument.

cd /server
upgrade/qm/qm_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

During the upgrade, after the configuration files are merged, an editor opens in which you can check the IBM Engineering Test Management teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review. If the location of the com.ibm.team.fulltext.indexLocation property is relative path, you do not need to change the path. If the location is absolute path, make sure the directory is stable and will not be deleted if an application is uninstalled. The absolute stable location should look like this example: com.ibm.team.fulltext.indexLocation=QM__install_dir/server/conf/qm/indices/workitemindex where QM__install_dir is the location where IBM Engineering Test Management application is installed.

If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

Upgrading the application

Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.

Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.

For information about the Oracle database DBMS_STATS command, see the Oracle documentation.

For information about the SQL Server database Update Statistics command, see the SQL Server documentation.

To upgrade the application that is installed on the same server as and migrate the link validity data, see this deployment wiki document.

  • Open a command shell and enter the following commands:
  • cd /server
    upgrade/rm/rm_upgrade.sh -oldApplicationHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt

    To upgrade application open a command shell and enter the following commands:

    Ensure that you can connect to with the network path you use in the -newJTSHome argument.

    Important: It is assumed that you have upgraded and deployed and all other applications except for the application and performed all the necessary pre-upgrade steps. To learn about link validity data migration and its options, see the rm_upgrade script topic.

    Important: For a multi-JTS environment, the text https://host_name:port/jts should be replaced with the URL specified in the Advanced Admin property, Shared Validity Provider URL, of the JTS that the RM is registered with. If no URL is defined, then use the URL of the JTS that the RM application is registered with. This JTS should already be upgraded to 7.x and running. The Shared Validity Provider URL is usually set to the URL of the JTS that the LQE is registered with, but use the URL specified in the Advanced Admin property for the upgrade commands.

    cd /server
    upgrade/rm/rm_upgrade.sh -oldApplicationHome /server/conf -newJTSHome /server/conf -updateAppServerFiles no -applicationContextRoot -jtsContextRoot -noPrompt -noVerify -noStepPrompt -noEditor -noResumePrompt -jtsRepositoryUrl https://host_name:port/jts -adminUserId admin_user_id -adminPassword admin_password

    During the upgrade, after the configuration files are merged, an editor opens in which you can check the teamserver.properties file. Note that first the teamserver.properties file opens, and then the application teamserver.properties opens for review.

    If the com.ibm.team.repository.minimumClientCompatibilityVersion property exists in the teamserver.properties file, review if the value is a supported version. If it is not, update the value or delete the entire property.

    Note: The log4j configuration files are not merged. If you customized these files in previous versions, you must manually migrate your customized settings over to the new log4j.properties files. Log4j libraries were upgraded in ELM 7.0.1 SR1 iFix018 and ELM 7.0.2 SR1 iFix015. If you are upgrading from an older version, you must migrate your customized settings from the log4j.properties file to the new log4j2.xml files. See, Updated instructions for Engineering Lifecycle Management Interactive Upgrade Guide when upgrading to 7.0.2 SR1 release.

    Run the upgrade script on IBM i

    1. Log on to IBM i operating system using a user ID that has QSECOFR authority.
    2. In QShell, navigate to the configuration directory /QIBM/UserData/JazzTeamServer70/server.
    3. Enter this command to upgrade :

      upgrade/jts/jts_upgrade.sh -oldJTSHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    4. Enter this command to upgrade the application:

      upgrade/ccm/ccm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    5. Enter this command to upgrade the IBM Engineering Test Management application:

      upgrade/qm/qm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    6. To upgrade the application: Enter the following command:

      upgrade/rm/rm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

      Perform the steps mentioned in section Migrating the link validity data in a single-server topology using upgrade script with interaction provided in the Deployment wiki. Although the Deployment wiki provides steps for a server with RM and JTS installed on the same application server, the steps will work for a distributed server as well.
    7. Enter this command to upgrade the application:

      upgrade/relm/relm_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    8. Enter this command to upgrade the Global Configuration Management application:

      upgrade/gc/gc_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    9. Enter this command to upgrade the Report Builder application:

      upgrade/rs/rs_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    10. Enter this command to upgrade the Lifecycle Query Engine application:

      upgrade/lqe/lqe_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    11. Enter this command to upgrade the Link Index Provider application:

      upgrade/ldx/ldx_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    12. Enter this command to upgrade the Data Collection Component application:

      upgrade/dcc/dcc_upgrade.sh -oldApplicationHome /QIBM/UserData/JazzTeamServer<old_version>/server/conf

    13. Note: As an alternative, you can run the QJTS70/UPGJAZZSVR CL command to upgrade the server.

    14. Review the index file locations. Adjust the locations and copy index files if you prefer.
    15. Note: After running the update configuration files repository tools commands for and applications, some of the directory references in the teamserver.properties files point to the prior version work directory. You can keep the indices in the prior version directory, if you do not plan to delete or clean up that directory.

      You could also copy the indices to a new location in the new work directory and modify the teamserver.properties file. For example, suppose the updated teamserver.properties file includes com.ibm.team.jfs.index.root.directory=/QIBM/UserData/JazzTeamServer502/server/conf/jts/indices but your new work directory is /QIBM/UserData/JazzTeamServer70/server/conf. You can recursively copy these files to a new location and modify the teamserver.properites file. This is not required.

    16. Run the next command to update the previous version Application Server and deploy the .war files for the version applications. The command also does a backup, updates the JVM settings, updates the environment variable settings, deletes the temp directories, and restarts the server:
      • If you are using WebSphere Application Server, enter the following command:

        upgrade/was_upgrade.sh profileName serverName nodeName wasVersion wasOption maxHeapSize adminId adminPwd jvmVersion jazzAppName jtsAppName clmHelpAppName qmAppName rmAppName gcAppName jrsAppName dccAppName lqeAppName ldxAppName relmAppName

        Where:

        • profileName is the previous version profile name.
        • serverName is the previous version server name.
        • nodeName is the previous version server node name.
        • wasVersion is the WebSphere Application Server version.
        • wasOption is the WebSphere Application Server option (Base, ND, or Express) you chose for the previous on IBM i.
        • maxHeapSize is the maximum heap size you need for the application server.
        • adminId and adminPwd are the ID and password you used to secure the WebSphere Application Server on IBM i.
        • jvmVersion is the Java Virtual Machine (JVM) version (std64 for V6R1 /V7R1).
        • jazzAppName is the name of application.
        • jtsAppName is the name of .
        • clmHelpAppName is the name of the help application.
        • qmAppName is the name of IBM Engineering Test Management application.
        • rmAppName is the name of application.
        • gcAppName is the name of Global Configuration Management application.
        • jrsAppName is the name of Report Builder application.
        • dccAppName is the name of Data Collection Component application.
        • lqeAppName is the name of Lifecycle Query Engine application.
        • ldxAppName is the name of Link Index Provider application.
        • relmAppName is the name of application.

      • If you are upgrading WebSphere Liberty server (option 20), enter this command:

        upgrade/liberty_upgrade.sh serverName /QIBM/UserData/JazzTeamServer<old_version>/server/conf

      • If you are switching from WebSphere Application Server to Liberty or from Liberty to WebSphere Application Server, run the QJTS70/CFGJAZZSVR command and specify the same port number it was used in your previous installation. For more information, see Configuring the server on IBM i systems.

    Optional: Copy the IBM Engineering Test Management application custom adapters

    If you have any custom adapters in your IBM Engineering Test Management application such as the, NI Test Integration Adapter, MGEN CANoe Adapter, or the HP Unified Functional Testing (UFT) Adapter, you must manually copy these adapters to the new installation directory after the upgrade.

    For example, to manually copy the HP Unified Functional Testing (UFT) Adapter, go to \server\conf\qm\provision_profiles/server/conf/qm/provision_profiles and copy the com.ibm.rqm.adapter.qtp.web.ini file to the \server\conf\qm\provision_profiles/server/conf/qm/provision_profiles directory.

    Start the WebSphere Application Server

    In a distributed topology, you must complete this step on each application server that hosts the applications.

    Note: On Linux systems, an error might occur when you start the (RM) server from a command line (headless mode). For troubleshooting, see Fixing a converter issue while using the server in headless mode on a Linux system.

    Before you Begin: Ensure that you have a JDBC environment variable that points to the ojdbc8.jar located in the directory. For more information, see Setting up an Oracle database.

    Before you begin: Ensure that you have a JDBC environment variable to point to the JRE8 JDBC driver located in the directory. For more information, see Setting up an SQL Server database.

    1. Open a command prompt and enter the following commands:
    2. cd \bin
      startServer.bat server1

    1. Open a command shell and enter the following commands:
    2. cd /bin
      ./startServer.sh server1

    Deploy web application (WAR files) by using the Jython script

    You can use clm_deploy.pyclm_deploy_distributed.py deploy application WAR files. This script also maps the security roles for the appropriate applications for non-external user registries.

    If you are using LDAP, complete the following steps to map the security roles to your LDAP groups. Note that the groups must be setup on the LDAP server prior to completing this mapping.

    1. Open the JazzInstallDir/server/was/config.py script in a text editor for editing.
    2. Go to the RoleMapping section of the script and replace default with your application name, such as jts, ccm, qm. Replace None with your user or repository group. When replacing None with the group mapping, ensure that the value is enclosed in quotation marks. See the following example for the JTS application:
    3. RoleMapping = {
      'jts' : {
      'JazzAdmins' : {
      'mappedUser': None,
      'mappedGroup': "cn=JazzAdmins,cn=members,o=ldap.server.com",
      'AllowAccessToEveryone':'No',
      'AllowAccessToAllAuthenticatedUsers':'No'
      },
      'JazzUsers' : {
      'mappedUser': None,
      'mappedGroup': "cn=JazzUsers,cn=members,o=ldap.server.com",
      'AllowAccessToEveryone':'No',
      'AllowAccessToAllAuthenticatedUsers':'No'
      },
      'JazzGuests' : {
      'mappedUser':None,
      'mappedGroup': "cn=JazzGuests,cn=members,o=ldap.server.com",
      'AllowAccessToEveryone':'No',
      'AllowAccessToAllAuthenticatedUsers':'No'
      },
      'JazzProjectAdmins' : {
      'mappedUser': None,
      'mappedGroup': "cn=JazzProjectAdmins,cn=members,o=ldap.server.com",
      'AllowAccessToEveryone':'No',
      'AllowAccessToAllAuthenticatedUsers':'No'
      }
      },

    4. Save and close the file.

    About this task

    The clm_deploy.py script installs all application WAR files that are available in the webapps directory into a single WebSphere Application Server node.

    The clm_deploy_distributed.py script can be used to install any application WAR files that are available in the webapps directory, if you specify them in your command argument as a comma-separated list.

    Note: The web archive applications must have a .war extension.

    Procedure

    To deploy applications on a single WebSphere Application Server, complete this step:

    1. Open a command window as administrator and enter the following commands. Replace nodeName and server1 with your WebSphere Application Server node name and server name:
    2. Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the webapps directory.

      cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy.py nodeName server1 JazzInstallDir/server/webapps -config JazzInstallDir/server/was

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f /server/was/clm_deploy.py nodeName server1 /server/webapps -config /server/was

    To deploy applications in a distributed WebSphere Application Server environment, complete these steps. Replace nodeName and server1 with your WebSphere Application Server node name and server name:

    Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script and the webapps directory.

    1. On the server that hosts / Link Index Provider, open a command window and enter these commands:
    2. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps jts,clmhelp,ldx -config JazzInstallDir/server/was

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps jts,clmhelp,ldx -config /server/was

    3. On the server that hosts the application, open a command window and enter these commands:
    4. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps ccm -config JazzInstallDir/server/was

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps ccm -config /server/was

    5. On the server that hosts the , open a command window and enter these commands:
    6. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps am -config JazzInstallDir/server/was

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps am -config /server/was

    7. On the server that hosts the IBM Engineering Test Management application, open a command window and enter these commands:
    8. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps qm -config JazzInstallDir/server/was

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps qm -config /server/was

    9. On the server that hosts the application, open a command window and enter these commands:
    10. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps rm,converter

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps rm,converter

    11. On the server that hosts the application, open a command window and enter these commands:
    12. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps relm

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps relm

    13. On the server that hosts the Data Collection Component application, open a command window and enter these commands:
    14. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps dcc

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps dcc

    15. On the server that hosts the Report Builder application, open a command window and enter these commands:
    16. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps rs

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps rs

    17. On the server that hosts the Lifecycle Query Engine application, open a command window and enter these commands:
    18. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps lqe

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps lqe

    19. On the server that hosts the Global Configuration Management application, open a command window and enter these commands:
    20. cd \bin
      wsadmin.bat -lang jython -user WAS_USER -password WAS_PASSWORD -f JazzInstallDir/server/was/clm_deploy_distributed.py nodeName server1 JazzInstallDir/server/webapps gc

      cd /bin
      ./wsadmin.sh -lang jython -user WAS_USER -password WAS_PASSWORD -f nodeName server1 /server/was/clm_deploy_distributed.py /server/webapps gc

    21. To start the deployed applications, restart the application server. Replace server1 with the name of your application server:
    22. cd WAS_Profile_Dir\bin
      stopServer.bat server1 -user WAS_USER -password WAS_PASSWORD
      startServer.bat server1

      cd WAS_Profile_Dir/bin
      ./stopServer.sh server1 -user WAS_USER -password WAS_PASSWORD
      ./startServer.sh server1

    Deploy the version WAR files in WebSphere Application Server

    In a distributed topology, you must complete this step on each application server that hosts the applications.

    WAR file locations: By default, the WAR files are copied into the _install_dir/server/webapps directory by Installation Manager, unless you specified a different directory.

    1. Open a browser and login to WebSphere Integrated Solutions Console at https://hostname.example.com:9043/ibm/console/logon.jsp.
    2. Click Applications > New Application > New Enterprise Application.
    3. On the Path to the new application page, select Local file system and browse for the application.war file. Click Next.

      Depending on the applications that you installed, the following web applications might be available for deployment:

      • jts.war
      • clmhelp.war
      • ccm.war
      • am.war
      • relm.war
      • qm.war
      • rm.war
      • dcc.war
      • lqe.war
      • ldx.war
      • rs.war
      • gc.war

    4. Select Fast Path, and then click Next.
    5. For the Lifecycle Query Engine module, expand Choose to generate default bindings and mappings, and then select the Generate Default Bindings check box.
    6. For the Link Index Provider module, expand Choose to generate default bindings and mappings, and then select the Generate Default Bindings check box.
    7. On the Map modules to servers page, select the check box next to lqe to specify the target scope on the server for the lqe module.
    8. On the Map modules to servers page, select the check box next to ldx to specify the target scope on the server for the ldx module.
    9. Click Next to accept all default options until you reach the Map context roots for web modules page.
    10. In the Map context roots for web modules, set the following Context Root for applications:
      • to /jts
      • IBM Knowledge Center to /clmhelp
      • to /ccm
      • to /am
      • to /relm
      • IBM Engineering Test Management to /qm
      • to /rm
      • Converter application to /converter
      • Data Collection Component to /dcc
      • Report Builder to /rs
      • Lifecycle Query Engine to /lqe
      • Link Index Provider to /ldx
      • Global Configuration to /gc
    11. Click Finish.
    12. Verify that your application was installed correctly and then click Save directly to the master configuration.

    Important: If you work in an environment such as AIX that does not support converter, you must install the version of the converter.war on the dedicated converter server. For detailed information, see the Delegated Configuration section of the Converter Application Configuration and Troubleshooting Guide.

    Note: If you want to install the version of the converter.war file on the dedicated converter server, see the Delegated Configuration section of the Converter Application Configuration and Troubleshooting Guide.

    Map security roles to a user or repository group

    The jts_war, am_war, qm_war, and ccm_war applications must have the same authentication methods for their users and use the same security group mapping.

    1. In WebSphere Integrated Solutions Console click Applications > Application Types > WebSphere enterprise applications.
    2. For , click the jts_war application to open it for editing.
    3. For , click the ccm_war application to open it for editing.
    4. For , click the am_war application to open it for editing.
    5. For IBM Engineering Test Management, click the qm_war application to open it for editing.
    6. In the Detail Properties section, click Security role to user/group mapping.
    7. Select a specific repository group, such as JazzAdmins or JazzUsers, and click Map groups.

      These repository groups are associated with every Jazz implementation and must be mapped to a particular group that contains the authorized users. If you are using LDAP, these groups must be set up on the LDAP server prior to completing this mapping. If you are mapping these repository groups to individual users, select the repository group and click Map Users.

    8. Enter a search string to return your users or group names. Click Search to run the query.
    9. From the list of available users or groups that is returned, select the particular user or group and move it to the Selected column.
    10. Click OK to map the users or groups to the Jazz repository groups.
    11. Save the changes.

    Note: In future, if there are changes to the LDAP configuration level, you must remap the security roles to the user or repository group for JTS and other installed applications.

    Configure the Report Builder application

    1. In WebSphere Integrated Solutions Console click Applications > Application Types > WebSphere enterprise applications.
    2. On the Enterprise Applications page, in the list of resources, click rs_war.
    3. On the Configuration page, in the References section, click Shared library references.
    4. Select the rs_war check box and click Reference shared libraries.
    5. In the Available list, select JRS Shared Library and click the right arrow.
    6. Click OK. Click OK again and then click Save.
    7. In the list of resources, click rs_war.
    8. On the Configuration page, under Detail Properties, click Class loading and update detection.
    9. In the Class loader order group, ensure that Classes loaded with local class loader first (parent last) is selected. Click Apply and then click Save.

    Configure the Lifecycle Query Engine application

    1. In WebSphere Integrated Solutions Console click Applications > Application Types > WebSphere enterprise applications.
    2. Click lqe_war to open it and then click Manage Modules.
    3. Click lqe, locate the Class loader order field and select Classes loaded with local class loader first (parent last).
    4. Click OK and save your changes.
    5. Go back to the lqe_war application and click Class loading and update detection.
    6. On the Class loader page, select Classes loaded with local class loader first (parent last).
    7. Click Apply and Save directly to the master configuration.

    Configure the Link Index Provider application

    1. In WebSphere Integrated Solutions Console click Applications > Application Types > WebSphere enterprise applications.
    2. Click ldx_war to open it and then click Manage Modules.
    3. Click ldx, locate the Class loader order field and select Classes loaded with local class loader first (parent last).
    4. Click OK and save your changes.
    5. Go back to the ldx_war application and click Class loading and update detection.
    6. On the Class loader page, select Classes loaded with local class loader first (parent last).
    7. Click Apply and Save directly to the master configuration.

    Start the applications

    On the Enterprise Applications page, start these applications:

    In a distributed topology, you must complete this step on each application server that hosts the applications.

    Log on to the Integrated Solutions Console and start these applications:

    • jts_war
    • ccm_war
    • am_war
    • qm_war
    • rm_war
    • dcc_war
    • rs_war
    • relm_war
    • gc_war
    • lqe_war
    • ldx_war
    • clmhelp_war

    Upgrading the Distributed Cache Microservice (DCM)

    The Distributed Cache Microservice was first introduced in version 6.0.5. If you are upgrading your clustered environment from version 6.0.4, follow the procedures in the Interactive Installation Guide to install and register a new DCM.

    When you install the new version of the application, a new version of Distributed Cache Microservice is installed at the default location, JazzInstallDir/server/clustering/cache.

    • If your DCM is at the default location, you must merge all your configuration settings you had in the old distributedCache.cfg file with the new distributedCache.cfg file in the new installation directory.
    • If your DCM was moved to a dedicated server in the previous installation, make a backup copy of the entire clustering/cache directory. Move the new version of DCM from JazzInstallDir/server/clustering/cache to its dedicated server, and then make sure to merge all your configuration settings.

    In particular, ensure the following configuration properties in the distributedCache.cfg file are merged:

    • Ensure the path to the keystore file in the keyStorePath property is correct.
    • Check the [REST] section and update the properties if necessary.
    • Ensure to update the [AuthServer] properties if authentication is set to OIDC for DCM. The URL you use in the as_trusted_url, must match the URL you specified in the Advanced Properties of the server. Do not append the context root (/dcm) to this property.
    • If authentication is done through an LDAP server, ensure to update the [UserRegistry] properties.
    • If you plan to monitor the performance counters that the microservice publishes, under [Counters], set the Enabled property to true and provide an MQTT broker URL in the broker property. DCM publishes its counters via an MQTT Broker. When this is enabled, counters can be seen in the cluster application's administrative UI internal Counters Page. Alternatively, when counters are enabled in the configuration file, the http://DCM_HOST_NAME:10001/dcm/counters URL displays counter data on demand, (port is applicable only if it is not masked). Publishing frequency is controlled by snapshotFrequency property under the [Logging] section. It is also possible to locally log the usage statistics of DCM. To do this, set logSnapshotStats to true.

    Note: Starting in version 6.0.6.1, the version of Jetty that is used for DCM has changed. As a result, the allowRenegotiate property in the distributedCache.cfg file changed to renegotiationAllowed with the default value still being false.

    Replicate the upgraded application to all other nodes

    To replicate the upgraded application to all other nodes in the clustered environment:

    Note: Copying the entire installation directory works if an HAProxy is used. If you use IBM HTTP Server for load balancing, to avoid problems only copy the conf directory.

    1. Copy the entire installation directory from the first node to the other nodes.
    2. Important: The upgrade command does not upgrade the server.startup file. If you customized this file in your previous installation, you must manually merge your customized settings.

    3. Ensure that the server/conf/ccm/teamserver.properties file has the following property:

      com.ibm.team.repository.servlet.sso_clientId

    4. Ensure that the server/server.startup file has the following properties:

      JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.cluster.nodeId="ccm1""
      JAVA_OPTS="$JAVA_OPTS -Dcom.ibm.team.repository.service.internal.db.allowConcurrentAccess=true"
      JAVA_OPTS="$JAVA_OPTS -Dretry.count=0"
      JAVA_OPTS="$JAVA_OPTS -Dretry.wait=10"

    5. Replace ccm1 example with the name or ID of the node. This name must be unique across all the nodes. When you copy the installation directory to the other nodes, if you are using HAProxy as a load balancer, you must open each server/server.startup file and change the ID to a unique node ID, for example, ccm2, ccm3, and so on. If you are using IBM HTTP Server as a load balancer, in addition to node ID in the server/server.startup file, cloneId in the /server/liberty/servers/clm/server.xml file must also be unique.

    Important: Examine the /server/clustering/cache/distributedCache.cfg file and merge any customized settings that you made in the previous instance of the file. Do not use the microservice from a previous release with a newer version of . Always merge customized settings from an existing instance of the Distributed Cache Microservice into the new instance that you install with .

    Restart the IBM Watson IoT Platform - Message Gateway

    Before starting the servers in your clustered environment, restart IBM Watson IoT Platform - Message Gateway by using the CleanStore button. The CleanStore button ensures that the store is cleaned as part of the shutdown process.

    Start the servers

    Note: If you customized your server.startup script in the previous installation, you must manually MERGE your customized settings into the new server.startup file. Ensure to have a backup of the new server.startup file before customizing it.

    In a distributed topology, you must complete this step on each application server that hosts the applications.

    Note: In a clustered environment, start the Distributed Cache Microservice and first, verify that they are working properly by logging in to the servers, and then start all the other application nodes.

    Before you Begin: Ensure that you have a JDBC environment variable that points to the ojdbc8.jar located in the directory. For more information, see Setting up an Oracle database.

    Before you begin: Ensure that you have a JDBC environment variable to point to the JRE8 JDBC driver located in the directory. For more information, see Setting up an SQL Server database.

    Start all of the version application servers:

    Start the version application server:

    1. Run the following command:

      repotools-relm -reindex all

      Open a command prompt and enter:

      cd \server
      server.startup.bat

    2. On the computer that hosts /Link Index Provider, open a command prompt and enter:

      cd \server
      server.startup.bat

    3. On the computer that hosts the Global Configuration Management application, open a command prompt and enter:

      cd \server
      server.startup.bat

    4. On the computer that hosts the application, open a command prompt and enter:

      cd \server
      server.startup.bat

    5. On the computer that hosts the , open a command prompt and enter:

      cd \server
      server.startup.bat

    6. On the computer that hosts the Quality Management application, open a command prompt and enter:

      cd \server
      server.startup.bat

    7. On the computer that hosts the application, open a command prompt and enter:

      cd \server
      server.startup.bat

    8. On the computer that hosts the Data Collection Component application, open a command prompt and enter:

      cd \server
      server.startup.bat

    9. On the computer that hosts the Report Builder application, open a command prompt and enter:

      cd \server
      server.startup.bat

    10. On the computer that hosts the application:
      1. Run the following command:

        repotools-relm -reindex all

      2. Open a command prompt and enter:


        cd \server
        server.startup.bat

    11. On the computer that hosts the Lifecycle Query Engine application, open a command prompt and enter:

      cd \server
      server.startup.bat

    1. Run the following command:

      repotools-relm -reindex all

      Open a command shell and enter:

      cd /server
      ./server.startup

    2. On the computer that hosts /Link Index Provider, open a command shell and enter:

      cd /server
      ./server.startup

    3. On the computer that hosts the Global Configuration Management application, open a command shell and enter:

      cd /server
      ./server.startup

    4. On the computer that hosts the application, open a command shell and enter:

      cd /server
      ./server.startup

    5. On the computer that hosts the , open a command shell and enter:

      cd /server
      ./server.startup

    6. On the computer that hosts the Quality Management application, open a command shell and enter:

      cd /server
      ./server.startup

    7. On the computer that hosts the application, open a command shell and enter:

      cd /server
      ./server.startup

    8. On the computer that hosts the Data Collection Components application, open a command shell and enter:

      cd /server
      ./server.startup

    9. On the computer that hosts the Report Builder application, open a command shell and enter:

      cd /server
      ./server.startup

    10. On the computer that hosts the application:
      1. Run the following command

        repotools-relm -reindex all

      2. Open a command shell and enter:


        cd /server
        ./server.startup

    11. On the computer that hosts the Lifecycle Query Engine application, open a command shell and enter:

      cd /server
      ./server.startup

    Optional: Migrate your certificates

    You can migrate your certificate from your previous Tomcat Liberty installation to import and use those certificates with your new WebSphere Liberty server.

    Before you begin

    You must at least start and stop the server one time before you can complete this procedure.

    Procedure

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the :

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the IBM Engineering Test Management application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the Data Collection Component application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the Report Builder application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the Lifecycle Query Engine application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    Complete these steps on the Global Configuration Management application server:

    1. Copy the keystore file you were using with Tomcat in previous version to the /server/liberty/servers/clm/resources/security\server\liberty\servers\clm\resources\security directory.
    2. Go to the /server/liberty/servers/clm\server\liberty\servers\clm directory and open server.xml file for editing.
    3. Update the <keyStore> element in the following line with your keystore information:

      <keyStore id="defaultKeyStore" location="ibm-team-ssl.keystore" type="JCEKS" password="{xor}Nj0ycis6PjI="/>

    For more information, see Enabling SSL communication for the Liberty profile.

    Import the ready-to-use reports

    If you used ready-to-use reports in your , you must reimport them after you upgrade to version .

    Note: The following steps are not required if you used the importReportsOnStartup parameter during the upgrade. The reports will be imported after the server is started.

    Procedure

    1. Open a browser and login to https://host.example.com:port/rs/setup.
    2. Click Import ready-to-use reports.

    Migrating the application

    When the application is started after the upgrade, a migration takes place in the background. Open a browser and go to the admin page at https://host.example.com:port/lqe/web. If the server migration has completed, you will be redirected to the home page. If the migration is still in progress, the migration status page opens. In this case, wait for the migration to complete and then you will be redirected to the home page.

    Note: RMM version 6.x did not contribute to LQE and LDX. However during the upgrade, RMM is converted to CCM with AM Extension for CCM application which supports the Tracked Resource Set (TRS) specification. Therefore, it is recommended to register corresponding TRS feeds as data sources in both LQE and LDX applications. If LQE or LDX are installed on a separate JTS from the CCM application, perform the steps described in Connecting Lifecycle Query Engine to applications that use a different Jazz Team Server, else perform the steps described in Connecting Lifecycle Query Engine to applications that use the same Jazz Team Server.


    You must register the corresponding TRS feeds to fetch details of OSLC links established between EWM artifacts owned by the upgraded server and artifacts owned by other EWM or ETM applications. Details of such OSLC links are fetched from LQE when generating JRS reports, where LDX is used to display data in Web Clients.

    Configure data warehouse

    If you did not configure the data warehouse in your previous installation and want to configure a data warehouse for version , follow these steps:

    1. Create a database to use as your data warehouse. For more information, see Setting up the database.
    2. Run the setup wizard, skip to the configuring the data warehouse step, and configure the data warehouse. For more information, see Configuring or changing the data warehouse after you have configured the .

      Note: You do not have to run the setup wizard to set up the version server. The setup wizard is needed only if you did not configure the data warehouse in the previous installation and now want to configure it.

    Obtain licenses

    You must obtain new licenses for version 7.x applications if you are upgrading from any release of version 6.x. Version 7.x applications do not work with version 6.x licenses. However, version 6.x applications work with version 7.x licenses.

    If you previously used floating, token, or authorized user single install licenses, install their version 7.x counterparts. Your existing user license assignments are retained during installation of version 7.x licenses.

    You can obtain your permanent licenses from Passport Advantage when downloading your version 7.x eAssembly.

    To update your token licenses:

    1. Log into https://hostname.example.com:port/jts/admin and click Server > License Key Management.
    2. In the Floating License Server section, click Add and upload your version 7 license file.
    3. After the upload is complete, two entries are displayed in the Floating License Server section. Hover the mouse pointer over the version 6.x license entry and click the red X icon to delete the entry. If a warning message is displayed, click OK.
    4. Go to Users > Client Access License Management, select a token license, and confirm that the list of users that had the version 6.x licenses is present.

    For more information about licenses, see Managing licenses.

    Note: You must obtain a new license for Architecture Management application. The license for version 7.0 will not work with version 7.0.2.

    Rebase TRS and reindex data sources

    If you are using Lifecycle Query Engine, complete the following steps after you upgrade your application. Note that these steps might take some time to complete depending on the size of your repository.

    1. Do TRS 2.0 full rebase:
      1. Open a web browser and navigate to https://RM_Server:port/rm/admin#action=com.ibm.rdm.fronting.server.web.trs.
      2. Click TRS 2.0 Full Rebase. Wait for the operation to complete before proceeding to the next step. It may take some time depending on the data size.
    2. Replace the DNG TRS 1.0 data source with the TRS 2.0 data source in Lifecycle Query Engine:

      Note: If the DNG TRS 2.0 data sources already exist in Lifecycle Query Engine, you do not need to remove and add them back again. You can just reindex the data sources.

      1. Open a web browser and navigate to https://LQE_Server:port/lqe/web/admin/data-sources.
      2. If the DNG TRS 1.0 data source exists, remove it. The DNG TRS 1.0 data source is usually named DOORS Next Generation TRS and points to https://RM_Server:port/rm/trs. To remove the data source, select it and then click Remove.
      3. Click Add Data Source, and in the wizard that opens select the DNG Process Resources (TRS 2.0) data source. Click Finish.
      4. Repeat the previous step and add the DNG Resources (TRS 2.0) data source.
      5. The URL for DNG Process Resources (TRS 2.0) is https://RM_Server:port/rm/process-trs2 and the URL for DNG Resources (TRS 2.0) is https://RM_Server:port/rm/trs2. After the data sources are added, Lifecycle Query Engine starts building the initial indices.

      6. Click DNG Process Resources (TRS 2.0) and DNG Resources (TRS 2.0) and then click Reindex and in the dialog that opens, click Reindex again.
      7. Click OK to confirm the reindex operation.

    Reindex data sources

    If you are using Lifecycle Query Engine, complete the following steps after you upgrade your application. Note that these steps might take some time to complete depending on the size of your repository.

    1. Open a web browser and navigate to https://LQE_Server:port/lqe/web/admin/data-sources.
    2. If the TRS 1.0 for Resources exists, remove it. The TRS 1.0 data source is called and the URL is https://localhost:port/ccm/oslc/workitems/trs. To remove the data source, select it and then click Remove.
    3. Click Add Data Source, and in the wizard that opens select the RTC Process Resources (TRS 2.0) data source. Click Finish.
    4. If you encounter an invalid update issue (see work item 469658), repeat the above steps and add the following data source:
      • RTC SCM Change Sets (TRS 2.0)
    5. If you encounter out-of-sync resources issue (see work item 472058), repeat the above steps and add the following data source. This is applicable only if the link archiving is enabled:
      • RTC SCM Change Set Link Resources (TRS 2.0)
    6. Under Data Source, click each data source you just added.
    7. Click Reindex and in the dialog that opens, click Reindex again.
    8. Click OK to confirm the reindex operation.

    Reindex CCM/AM data sources

    In version 6.x, the RMM application did not contribute to LQE or LDX. However, because you are migrating your RMM application to , the native CCM data source must be reindexed in LQE. Note that these steps might take some time to complete depending on the size of your repository.

    1. Open a web browser and navigate to https://LQE_Server:port/lqe/web/admin/data-sources.
    2. If the TRS 1.0 for Resources exists, remove it. The TRS 1.0 data source is called and the URL is https://localhost:port/am/oslc/workitems/trs. To remove the data source, select it and then click Remove.
    3. Click Add Data Source, and in the wizard that opens select the RTC Process Resources (TRS 2.0) data source. Click Finish.
    4. If you encounter an invalid update issue (see work item 469658), repeat the above steps and add the following data source:
      • RTC SCM Change Sets (TRS 2.0)
    5. If you encounter out-of-sync resources issue (see work item 472058), repeat the above steps and add the following data source. This is applicable only if the link archiving is enabled:
      • RTC SCM Change Set Link Resources (TRS 2.0)
    6. Under Data Source, click each data source you just added.
    7. Click Reindex and in the dialog that opens, click Reindex again.
    8. Click OK to confirm the reindex operation.

    Rebuild and reindex IBM Engineering Test Management data sources

    If you are using Lifecycle Query Engine, complete the following steps after you upgrade your IBM Engineering Test Management application. Note that these steps might take some time to complete depending on the size of your repository.

    1. To rebuild the TRS base, open a browser and log into the IBM Engineering Test Management application at https://QM_Server:port/qm/admin.
    2. Click Application > Advanced Properties and then search for Audit History Component.
    3. Click the current value of the TRS Base Lifetime property and change it from 1440 to 1.
    4. Scroll up the page and click Save.
    5. Wait > 1 minute.
    6. Complete a full reindex of the RQM Resources (TRS 2.0) data source:
      1. Open a web browser and navigate to https://LQE_Server:port/lqe/web/admin/data-sources.
      2. If the TRS 1.0 for QM Resources exists, remove it. To remove the data source, select it and then click Remove.
      3. If the RQM Resources (TRS 2.0) does not exist, add it. To add the data source, click Add Data Source, and in the wizard that opens select the RQM Resources (TRS 2.0) data source. Click Finish.
      4. Under Data Source, click RQM Resources (TRS 2.0).
      5. Click Reindex and in the dialog that opens, click Reindex again.
      6. Click OK to confirm the reindex operation.
    7. Now reset the setting back to the default value of 1440 for the TRS Base Lifetime property in the Audit History Component section of the QM server. Save your changes.

    Reindex Global Configuration Management data sources

    If you are using Lifecycle Query Engine, complete the following steps after you upgrade your Global Configuration Management application. Note that these steps might take some time to complete depending on the size of your repository.

    1. Open a web browser and navigate to https://LQE_Server:port/lqe/web/admin/data-sources.
    2. Under Data Source, click GCM Resources (TRS 2.0) and GCM Process Resources (TRS 2.0).
    3. Click Reindex and in the dialog that opens, click Reindex again.
    4. Click OK to confirm the reindex operation.

    Upgrade and enable Jazz Authorization Server

    If you used IBM Installation Manager to install Jazz Authorization Server, you can use the Update feature of Installation Manager to upgrade your Jazz Authorization Server.

    Before you begin

    1. Stop the Jazz Authorization Server before performing the update.
    2. Make a backup copy of the entire Jazz Authorization Server installation directory and rename it to C:\JazzAuthorizationServer_OLD/opt/JazzAuthorizationServer_OLD.
    3. Ensure that you have a discoverable repository location set in the Installation Manager Preferences window.
      1. In Installation Manager go to File > Preferences and click Add Repository.
      2. Browse for a local .zip file or online link that contains the Jazz Authorization Server offerings repository.config file.
      3. Click Test Connections to ensure you can connect to the repository location.
      4. Click Apply and then OK to close the Preferences window.

    Procedure

    1. In IBM Installation Manager click Update.
    2. Select the Jazz Authorization Server package and click Next on all panels until you reach the Summary page.
    3. Review the summary information and click Update to start the upgrade process.
    4. If you have used the Apache Derby® for Jazz Authorization Server, copy the asDB folder from the backup you created earlier C:\JazzAuthorizationServer_OLD\derby\asDB /opt/JazzAuthorizationServer_OLD/derby/asDB and place it in the C:\JazzAuthorizationServer\derby\asDB /opt/JazzAuthorizationServer/derby/asDB replacing the existing asDB folder.
    5. Copy the IBM WebSphere Liberty configuration files from the previous Jazz Authorization Server install location to the new Jazz Authorization Server install location.

      These configuration files include server.xml, LdapUserRegistry.xml, ibm-team.keystore, localUserRegistry.xml, and appConfig.xml which are available in the JASInstall\wlp\usr\servers\jazzop directory.

    6. Restart the Jazz Authorization Server.

    To use Jazz Security Architecture single sign-on (SSO) authentication for existing deployments, it must first be enabled in all Jazz applications.

    There are different procedures for enabling different types of applications for Jazz Security Architecture SSO. All applications do not need to be enabled at the same time. However, the login experience is not single sign-on until all applications are enabled.

    For more information and related task topic, see Enabling applications for Jazz Security Architecture single sign-on.

    Reindex all data sources

    If you are upgrading your Global Configuration Management server from version 6.0.1 and earlier, after the upgrade is complete you must reindex all data sources.

    1. Make sure the server is started and then log in as an administrator.
    2. On the Server Administrator page under Manage Application Artifacts > Lifecycle Query Engine, click Manage data sources.
    3. On the Lifecycle Query Engine Data Sources page, click Reindex All.
    4. On the dialog box that opens, click Reindex All.
    5. Click OK to confirm the reindexing process.

    Deploy predefined templates

    To ensure you have the latest project and process templates available on your server, after the upgrade is complete do the following steps to import the predefined templates.

    To deploy the predefined project templates:

    1. Ensure the server is started and then log in as an administrator.
    2. On the Server Administrator page, click Manage Lifecycle Projects.
    3. On the Lifecycle Project Administration page, click Templates and then click Deploy Predefined Templates.
    4. Click OK at the prompt to overwrite any existing templates with the same identifiers.
    5. After a few moments a message is displayed that the predefined templates were deployed successfully.

    Add or specific data sources to LQE and LDX applications

    application version 6.x did not contribute to LQE and LDX. However; during the upgrade, this application is converted to with AM Extension for application which supports Tracked Resource Set (TRS) specification. Therefore, you must register the corresponding TRS feeds as data sources in both LQE and LDX applications. If LQE/LDX are installed on a separate JTS from the CCM application, then perform the steps described in Connecting Lifecycle Query Engine to applications that use a different Jazz Team Server, else perform the steps described in Connecting Lifecycle Query Engine to applications that use the same Jazz Team Server.
    If you do not register the corresponding TRS feeds, you will not be able to fetch details of OSLC links established between EWM artifacts owned by the upgraded server and artifacts owned by other EWM or ETM applications. Details of such OSLC links are fetched from LQE when generating JRS reports, where LDX is used to display data in Web Clients.

    Clear browser cache

    After you upgrade the Report Builder application, you must clear your browser cache including the cookies in order for the dashboard widgets to display correctly.

    Disable the CleanupUnusedIndexesVersionsTask on the server

    The CleanupUnusedIndexesVersionsTask must be disabled in this release of the IBM Engineering Requirements Management DOORS Next application. If you are upgrading from an older version of the application, the CleanupUnusedIndexesVersionsTask might be disabled by default. Follow the steps in this task to ensure the CleanupUnusedIndexesVersionsTask is disabled.

    1. Ensure the server is started.
    2. Open a browser and log in to the application administrative page at https://host.example.com:port/rm/admin.
    3. Click Application > Advanced Properties and search for CleanupUnusedIndexesVersionsTask.
    4. Ensure that the hour when the task is run is set to -1 to disable the task. A number between 0 and 23 that represents the hour of the day will enable the task.
    5. After making changes, scroll up the page and click Save to save your changes.
    6. Restart the server for changes to take effect.

    Registering with

    If you installed a new version in your upgraded environment, you must complete the following steps before you can register the application with . If you upgraded to this release, the following steps are not required.

    1. Stop .
    2. Go to the Jazz_Install_Dir/server/liberty/servers/clm/conf directory and open the application.xml file for editing.
    3. Add the following content under <!--Applications that rely on container authentication-->.
    4. <application type="war" id="am" name="am" location="${server.config.dir}/apps/am.war">
      <application-bnd>
      <security-role name="JazzAdmins">
      <group name="JazzAdmins" />
      </security-role>
      <security-role name="JazzProjectAdmins">
      <group name="JazzProjectAdmins" />
      </security-role>
      <security-role name="JazzUsers">
      <group name="JazzUsers" />
      </security-role>
      <security-role name="JazzGuests">
      <group name="JazzGuests" />
      </security-role>
      </application-bnd>
      </application>

      Note: The line <application type="war" id="am" name="am" location="${server.config.dir}/apps/am.war"> contains the default application name. If during the installation you changed the application context root, replace am in the id, name, and am.war attributes accordingly.

    5. Save and close the application.xml file.
    6. Restart the server.
    7. Log into and register and configure the application.

    Remote help settings after the upgrade

    After you upgrade your applications to , the upgrade procedure sets the remote help settings to use the version of the knowledge center. If in your previous installation you customized your remote help settings, you must manually update the settings. To learn about remote help configuration see, Installing help on your computer and Changing help content connections.

    Run statistics on the Db2 database

    The runstats utility in Db2 updates statistics about the physical characteristics of a table and the associated indexes. These characteristics include the number of records, the number of pages, and the average record length. The optimizer uses these statistics when determining access paths to the data. Call this utility when a table has had many updates or after reorganizing a table in a large scale IBM Engineering Test Management application database.

    To run the runstats utility, open a Db2 command window and enter the following commands:

    db2 connect to qm
    db2 runstats on table "REPOSITORY"."VERSION" with distribution and detailed indexes all
    db2 disconnect qm

    Optional: Enable database table partitioning

    To determine whether you need to enable database table partitioning, see Leveraging Database Partitioning in RQM for Data Growth on the Deployment wiki.

    In version 6.0.6.1 and later, you can use the partitioning repotools command to partition a non-partitioned REPOSITORY.VERSIONREPOSITORY_VERSION<SchemaPrefix>_REPOSITORY.VERSIONRPSTR_VRSN table in a configuration-enabled system. The command partitions by range based on item types. Database table partitioning helps manage the performance, availability, and scalability of large amounts of data (millions of artifacts) in a repository. To use the partitioning features, you must install an Enterprise edition of a Db2 (or Advanced edition if using Db2 11.5)Db2 for z/OSDb2 for iOracleSQL Server database. Standard, Workgroup, Personal, or Express editions of the database, or the default Apache Derby database, do not support partitioning. The command fails if the underlying database does not support partitioning.

    Important: Back up the database before you use this command. After the successful completion of this command, database administrators should collect statistics for the REPOSITORY.VERSIONREPOSITORY_VERSION<SchemaPrefix>_REPOSITORY.VERSIONRPSTR_VRSN table and its indexes to help improve the performance of the database.

    During data migration, the original table is duplicated until the end of the migration process, when the old table is dropped. Ensure that you have adequate disk space for data migration and for growing partitions after the initial copy and cleanup.

    To enable the IBM Engineering Test Management application database table partitioning, open a command window and enter the following commands:

    cd /server
    ./repotools-qm.sh -partitioning teamserver.properties=conf/qm/teamserver.properties enable

    cd \server
    repotools-qm.bat -partitioning teamserver.properties=conf\qm\teamserver.properties enable

    For details about the partitioning repotools command, see Repository tools command to partition a database table.

    Resolving the CRJAZ1431E error message

    If during the upgrade you encounter the following error message: CRJAZ1431E - The model COMPONENT_ID_IDX was illegally changed to be unique, you can use the SQL Server Management Studio to resolve the issue.

    1. Log into SQL Server Management Studio.
    2. Set the indices property to Unique for both VVCMODEL_CHANGE_SET_ID_IDX and VVC_MODEL_COMPONENT_ID_IDX.

    Verify the upgrade

    After the upgrade process is complete, use this checklist to determine whether each step was successful.

      Verification task More information
    Verify that these application configuration files are copied from previous installation to version :
    • For : JTS__install_dir/server/conf/jts/teamserver.properties
    • For the application: CCM__install_dir/server/conf/ccm/teamserver.properties
    • For the application: AM__install_dir/server/conf/am/teamserver.properties
    • For the IBM Engineering Test Management application: QM__install_dir/server/conf/qm/teamserver.properties
    • For the application: RM__install_dir/server/conf/rm/teamserver.properties
    • For the application: __install_dir/server/conf/relm/teamserver.properties
    • For the Global Configuration Management application: GC__install_dir/server/conf/gc/teamserver.properties
    • For the Data Collection Component application: DCC__install_dir/server/conf/dcc/teamserver.properties
    • For the Report Builder application: JRS__install_dir/server/conf/rs/app.properties
    • For the Lifecycle Query Engine application: LQE__install_dir/server/conf/lqe/lqe.properties
    • For the Link Index Provider application: JTS__install_dir/server/conf/ldx/lqe.properties
    Verify that the application configuration files are copied from previous configuration directory to version :
    • /QIBM/UserData/JazzTeamServer70/server/conf/teamserver.properties
     
    Verify that each teamserver.properties file contains this information:
    • The properties that were copied from the previous version of the teamserver.properties file.
    • A valid, distinct URL in the com.ibm.team.repository.server.webapp.url property. The URL for the version application must be the same as the one that was used in the previous version.
    • Valid database vendor entries. Ensure the database that is specified in each application's teamserver.properties file exists.
     
    Verify the application servers:
    • Ensure that these applications are deployed and started:
      • jts.war
      • clmhelp.war
      • ccm.war
      • am.war
      • qm.war
      • rm.war
      • relm.war
      • dcc.war
      • rs.war
      • gc.war
      • lqe.war
      • ldx.war
    Deploying and starting the server
     
    Check the server log files: Check the server log files to verify that they contain the post-upgrade information:
    • If you are using a WebSphere Liberty server, the log files are in the _install_dir/server/logs directory.
    • If you are using a WebSphere Application Server, the log files are in the /logs\logs directory.
     
    Regenerate your self-signed keystore: Your previous version self-signed certificate might not work after you upgrade because of the potential cypher changes in the new version. If you are not able to login to the server after the upgrade with the following error: ssl_error_no_cypher_overlap, you might just need to regenerate your self-signed keystore by using the newer JDK that is bundled with the product.

    Installing a security certificate

    Check the public URLs: If you upgraded , or any of the applications, make sure that the public URL on the application's status summary page is the same as the URL that was used in the previous version.  
    Check the links on the Administration page: In a web browser, go to the Administration page of at https://hostname.example.com:port/jts/admin and make sure that no errors are displayed. administrative web interface
    Check the links on the application's Administration page: In a web browser, go to the Administration page of the application at https://hostname.example.com:port/application context root/admin and make sure that no errors are displayed.

    For Report Builder, go to https://hostname.example.com:port/application context root/setup and make sure that no errors are displayed.

    For Lifecycle Query Engine, go to https://hostname.example.com:port/application context root/web/admin/home and make sure that no errors are displayed.

    Application administrative web interface
    Run diagnostics on each server and verify that the diagnostics completed successfully:
    1. Open a browser and log on to the admin page, for example, https://host.example.com:port/jts/admin
    2. Click the Diagnostics link.

    It is also a good practice to run the database statistics after the upgrade to help with server performance. For more information about the database stats command, see the planning checklist table in this document.

    Note: Lifecycle Query Engine and Report Builder do not have a diagnostics section.

     
    Check users, licenses, and link artifacts:
    • Inspect users and licenses
    • Check linked artifacts
    • Check the web client
    • Check indexing by using search
    • Check Eclipse or Visual Studio clients
    Verifying users, licenses, and link artifacts
    Check application artifacts:
    • Check all projects are listed and can be navigated to
    • Check that all dashboards are available and widgets are working
    • Find and view existing artifacts and verify that the editors open properly
    • In application, verify work items and release plans
    • In IBM Engineering Test Management application, verify test plans, test cases, test suites, and test scripts
    • In application, verify requirements, collections, folders, and graphical artifacts
    • In application, verify that you can display and edit graphical artifacts
    • The application requires the following Windows server dependency package installed on the server to be able to display the file previews correctly. If you are prompted for "CRSSS0980W A preview of the file is not available because of a server-side configuration issue." error message, you must obtain the Visual C++ Redistributable Packages for Visual Studio 2013 from Microsoft website and install it on your Windows server.
    • In Report Builder, check that any pre-existing reports are present. Run a couple of the reports to verify that they show the expected data.
    • Initialize the publish services
    Initialize the publish services