Question & Answer
Question
Answer
First of all, it's simply not possible to archive up ITNCM, extract it on another machine, and start it up. We do not test or support this approach. Furthermore, there are dependencies or required products we cannot speak for, for instance WebSphere and JazzSM.
The way to move from server A to server B is a side-by-side installation, where server B is gotten up-and-running, verified, promoted to production, and then server A is switched off.
This migration needs to be done in three discrete steps: cloning the existing server, upgrading the new clone to the planned fix pack level, and then upgrading the production database.
Since we are talking about a side-by-side installation, the host names and IP addresses have to differ on the new Server B.
The upgrade process:
Assumptions:
There is just *one* ITNCM server with all server components (presentation, worker, compliance) present on that.
When we say "install ITNCM", be aware there are prerequisite products that need to be installed first.
Nomenclature:
"Server A" is the current ITNCM server on RHEL 5.x
"Version A" is the version of ITNCM this server is running.
"DB-A" is the production database that Server A is talking to.
"Server B" is the new ITNCM server running RHEL 7.x
"DB-B" is a new database that Server B will use during upgrade.
Clone the existing ITNCM server:
1 Install Version A of ITNCM on Server B. Configure to talk to DB-A. Note that DB-A is a production database and any action performed on it affects production data.
2 Copy the .intelliden.keystore and .intelliden.user files from Server A to Server B
3 Copy the drivers directory from Server A to Server B.
4 On Server B remotely mount the Server A configuration directory as read only.
5 Execute a diff between the Server B configuration and the remotely mounted Server A configuration.
6 Determine which files have customizations and apply these customizations to Server B.
7 Start Server B and verify Server B works as expected. At this point Server B is pointing at the same database as Server A. You may wish to stop ITNCM on Server A while you verify Server B.
=== at this point clone is complete ===
Upgrade Server B:
8 Stop Server B.
9 Create a DB-A backup and from this backup create a clone of DB-A called DB-B.
10 Modify Server B configuration to point to DB-B.
11 Upgrade Server B to the desired version (we recommend 6.4.2.9). Apply Fix Pack upgrade scripts to DB-B so that it is up to the correct version (e.g. 6.4.2.9).
12 Start Server B and verify that it works as expected.
=== at this point upgrade of Server B is complete ===
Upgrade DB-A and point Server B at it:
13 Back up DB-A.
14 Stop Server A. If there are any other servers or processes talking to DB-A, stop these also.
15 Apply Fix Pack upgrade scripts to DB-A so that it is up to the correct version (e.g. 6.4.2.9).
16 (Re-)Point Server B to DB-A.
17 Start Server B.
=== production database DB-A upgrade complete and Server B now pointing at it ===
Was this topic helpful?
Document Information
Modified date:
13 April 2020
UID
ibm16007120