[ Bottom of Page | Previous Page | Next Page | Contents ]
The migration requires you to migrate the administration server database to V2.1, and install a V2.1 administration server to
replace the old version.
- Choice: do you want to use new computers or reinstall the components
on the same computers?
- The advantage of using new computers is that not only do you get the
benefit of features like the more powerful processors, faster clock speed,
and larger disk, but also you can install the V2.1 components and test them
without interrupting the functioning of your existing V1.1.1 installation.
The advantage of re-using the existing computers is that not only do you save
on computer resources, but also the migration procedure is a little simpler.
The differences are illustrated in the following scenarios:
- Step 5 Scenario 1: all new computers
- In this scenario you install the V2.1 components on new computers. You
would take the following steps:
- Install new administration components: Install the
new administration server and database on the new computers you have chosen for this purpose.
This will be the permanent home for your administration server components.
Either before or during this process you install the prerequisite version
of DB2 on all computers, and the prerequisite version of WebSphere Application Server on the computer
where the administration server is going to be.
- Test the configuration: Install a runtime server and database
and deploy a couple of agents. Test that the administration server is working
correctly and that you have configured it correctly, for example, for SSL.
The runtime server can either be a production runtime server that you will
want to use in the completed configuration, or it can be a test runtime server
that you will uninstall after the testing is completed.
- Stop the administration servers: Stop both the V1.1.1 and V2.1 administration
servers, and drop the test administration server database.
- Migrate the administration database: Migrate the V1.1.1 administration
server database on the computer where it is installed.
- Copy the database: Copy the migrated database to
the computer where you had installed the new administration server database.
- Choice: retain use data recorded at the runtime servers
after the V1.1.1 administration server was stopped? You now have to reconnect the runtime servers
to the administration server. The alternatives are:
- Reconfigure runtime servers:
- Change the runtime server's communications configuration files to point to the
new administration server. This involves stopping the V1.1.1 runtime servers, reconfiguring them
and restarting them. Inventory data from the agents is saved in the runtime servers'
databases, but any use data in the runtime servers' memory is not saved.
- Recycle administration server's host name
- If you want to retain the continuity of this data, one way would be
to disconnect the V1.1.1 administration server from the network, and give the V2.1 administration
server the same host name as the V1.1.1 administration server had.
- Start V2.1 administration server: Restart the administration server. The next time,
according to its schedule or its requirements, that a runtime server connects to the administration server,
the mismatch between its catalog and the administration server's catalog causes the new catalog
to be downloaded, but no other changes are made until the runtime servers themselves
are migrated.
See Scenario 4.1: all new computers for full details of this procedure.
- Step 5 Scenario 2: same computers
- The second scenario assumes that you have the administration server
and its database on separate computers, and you want to maintain them on those
computers.
Take the following steps:
- Stop the V1.1.1 administration server:
- Uninstall V1.1.1 administration server database: Uninstall
the administration server database, being careful not to drop the database
when requested.
- Migrate the administration server database: Migrate
the V1.1.1 administration server database on the old administration database
computer.
- Upgrade the hardware and operating system: You will
almost certainly want to upgrade the memory of the administration server database's
computer, and maybe the operating system as well.
- Upgrade DB2. The version of DB2 that was supported
by V1.1.1 (version 7.2.0 with fix pack 7) is not supported by V2.1. You will
need to upgrade DB2 on the administration server database computer. You
have two choices: apply a fix pack to bring DB2 up to the V2.1 supported level (fix pack
10a) or upgrade to version 8.1.4. If you choose the former, you need only
apply the fix pack to the existing version of DB2; if you decide to upgrade you will need
to export the Tivoli License Manager database or databases involved, and uninstall the
old version before installing version 8.1.4 If you decide to migrate to version
8.1.4, you can use either the bundled prerequisite version or your own version
(see the discussion in the Planning chapter of the IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1). The migration procedure described below explains
when to do this upgrade, but for detailed instructions you must refer to the
original documentation for DB2.
- Uninstall V1.1.1 administration server.
- Upgrade the hardware and operating system: You will
almost certainly want to upgrade the memory of the administration server's
computer, and maybe the operating system as well.
- Upgrade WebSphere Application Server: None of the versions of WebSphere Application Server that
were supported by V1.1.1 are supported by V2.1. You will need to upgrade WebSphere Application Server on
the administration server computer. You can use either the bundled prerequisite
version or your own version (see the discussion in the Planning chapter of
the IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1). The migration procedure described below explains
when to do this upgrade, but for detailed instructions on how to upgrade,
you must refer to the original documentation for WebSphere Application Server.
- Upgrade DB2: The version of DB2 that was supported
by V1.1.1 (version 7.2.0 with fix pack 7) is not supported by V2.1. You will
need to upgrade DB2 on the administration server computer. You have two
choices: apply a fix pack to bring DB2 up to the V2.1 supported level (fix pack
10a) or upgrade to version 8.1.4. If you choose the former, you need only
apply the fix pack to the existing version of DB2; if you decide to upgrade you will need
to export the Tivoli License Manager database or databases involved, and uninstall the
old version before installing version 8.1.4 If you decide to migrate to version
8.1.4, you can use either the bundled prerequisite version or your own version
(see the discussion in the Planning chapter of the IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1). The migration procedure described below explains
when to do this upgrade, but for detailed instructions you must refer to the
original documentation for DB2.
- Install V2.1 administration server: Install the V2.1 administration
server, identifying the migrated administration server database when requested.
- Start V2.1 administration server: When you restart the administration server, the runtime servers
plug in. The mismatch between their catalog and the administration server's catalog causes
the new catalog to be downloaded, but no other changes are made until the runtime servers
themselves are migrated.
Note:
If both administration server and
database are on the same computer you follow the same basic procedure, but
you can uninstall the components together.
See Scenario 4.2: same computers for full details of this procedure.
Whichever choice you make, at the end you will have a new V2.1 administration
server and its migrated database, using the required prerequisite software.
The runtime servers of V1.1.1 are compatible with the administration server of V2.1,
so you can recommence license monitoring immediately after this step.
Attention: The following restrictions to functionality should be noted while
a runtime server is at V1.1.1 while its administration server is at V2.1:
- If you want to create and distribute licences from a V2.1 administration
server to a V1.1.1 runtime server and agents, the created license needs to be defined
at release level and can be associated only to a single product (multi-product
association is not supported by V1.1.1).
- When software use is monitored by a V1.1.1 runtime server, in the Software Use reports
on the V2.1 administration server the "Licence" field in the report contains "No information
available".
- The runtime wake-up service does not work for V1.1.1 runtime servers. The wake-up
service is a means by which the administration server alerts runtime servers to changes in
information that are available for download. If the wake-up service is not
in use, the download of information must wait until the next scheduled download.
By default, information is downloaded from the administration server as documented in the configuration
parameters for the system.properties file in an appendix to IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1. This system.properties file setting (adminDownloadPeriod)
is configurable for each runtime server.
You can keep this configuration with no runtime servers migrated for an indefinite
period, but during that period you will not be able to take advantage of the
new facilities in the V2.1 administration server.
Note:
If you have any agents at
versions prior to 1.1.1, a warning message about them will be issued by the
migration procedure.
[ Top of Page | Previous Page | Next Page | Contents ]