[ Bottom of Page | Previous Page | Next Page | Contents ]
The changes that have taken place to the administration server GUI are described by their
main portfolio headings.
- Software usage and inventory tasks
-
- GUI correspondence
-
V1.1.1 Portfolio option |
V2.1 Portfolio |
Snapshot |
Produce Reports > Use
Snapshot |
Trend Analysis |
Produce Reports > Use
Trend |
Level Analysis |
Produce Reports > Use
Level |
Report |
Produce Reports > Installs
Snapshot |
Scheduling |
Schedule Software scans |
- New GUI tasks
-
The following tasks have been added:
- Installs Snapshot
- Unlicensed Use
- License Compliance
- Migration notes
-
- Historical data:
- Old historical installation and use data are migrated to the new structure.
New data to populate the new aggregated tables are not calculated, so the
new reports based on aggregated data are not available with respect to the
historical data. The reports affected are the following:
- License Compliance Report
- Unlicensed Use Report
- Historical aggregated use table:
- The old historical aggregated use table present in V1.1.1 is dropped.
If this data is of use to you outside Tivoli License Manager you should copy it to a table
outside the product structure before commencing the migration.
- Products found by scans:
- All products found by inventory scans in V1.1.1 (the contents of the table
AGENT_INV prior to migration) are considered unlicensed, as the license type "install" did not exist in V1.1.1. They will thus not be linked
to any license, the corresponding table in V2.1 AGENT_INV_LIC will be empty.
- To do, after the migration
- After the migration is complete, you should examine these products and
decide whether to create licenses for them.
- Software entitlement tasks
-
- GUI correspondence
-
V1.1.1 Portfolio option |
V2.1 Portfolio |
Define Software Entitlement Settings |
- Manage Procurement> Licenses
- Manage Procurement> Contracts
- Assign Licenses
- Define Monitoring
|
- Migration notes
-
- Procured licenses:
- For each V1.1.1 license a V2.1 procured license is created and distributed.
- Capacity type: (see List of all licenses in Define Software
Entitlement Settings)
- In V2.1 capacity type "configured processors"
and "online processors" are no longer supported. For licenses with either
of theses values for capacity type the value
is changed to "processors".
- License type:
- In V2.1 there are a new set of values for license type. Each migrated license is given a license type of "Concurrent Network".
- To do, after the migration
- After the migration is complete you should examine each license and
ensure that the license type is correct.
- Purchase type:
- The field purchase type, which did not exist in V1.1.1, is set up with
the value 0 (Unknown).
- License pool information:
- Migrated licenses will have the following license pool information:
If Target type is ... |
Organization |
Division |
User |
License pool parameter is ... |
Values
set by migration tool |
Distribute to all targets |
Yes |
No |
No |
Distribute to all users |
Yes |
Yes |
No |
- Product monitoring:
- In V1.1.1 the enablement option Software monitoring in the Define Software Entitlement Settings task has changed meaning and location. It is now called Product monitoring in the Define monitoring task, and it now only applies to use monitoring. Inventory scanning
is always enabled.
Migrated products are created with Product monitoring disabled. However, once you start up the administration
server a background task starts that examines each product and if it finds
at least one use license assigned to a release, version or product in the
catalog, the task sets Product monitoring to
enabled for all product releases.
- To do, after the migration
- If you do not want this task to run, because you want to enable product
use monitoring on an individual product basis, you should edit the system.properties file of the administration server before starting the server, and change
the value of the parameter activateProductsEnabled to
"false".
- Topology
-
- GUI correspondence
-
V1.1.1 Portfolio option |
V2.1 Portfolio |
Agents |
Manage Components >
Agents |
Nodes |
Manage Resources >
Nodes |
Server |
Manage Components >
Servers |
Divisions |
Manage Resources >
Divisions |
Users |
Manage Resources >
Application Users |
- Administration
-
- GUI correspondence
-
V1.1.1 Portfolio option |
V2.1 Portfolio |
Customers |
Manage Organizations |
Accounts |
Manage Access |
- Migration notes
-
- Organizations (Customers)
-
- Country codes:
- The country code in the CUSTOMER table
in V1.1.1 was a free-format text field. In V2.1 it has to be one of a set of
specific values defined in the COUNTRY table. The migration will attempt to
map the value in the table with the preset values in the COUNTRY table. It
will only make a match if the country code value
is one of the standard two or three-letter alphabetic ISO country codes (for
example, US, UK, JP; IT).
Where a match is not made the field will be blanked
out, and you should re-enter it using the V2.1 administration server GUI, which has a drop-down
list of country codes from which to select. The country code is for information
only, and its absence on migrated data will not create any processing problems.
- To do, before or after the migration
- Correct any country codes which are not in the standard two or three-letter
alphabetic ISO country codes (for example, US, UK, JP; IT).
- Accounts
-
- User authentication
- If you want to retain the user authentication data from V1.1.1 you can
do so. However, it may not be worth doing so, depending on the authentication
option you want to use in V2.1, as follows:
- If you want to use the XML option the users will not need to change their
passwords after the migration
- If you want to use the DB option the users will need to change their passwords
after the migration
- If you want to use the LDAP option, you will almost certainly have to
recreate all user accounts
More details about authentication can be found in the Configuration chapter
of IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1. Full instructions on how to retain the user
account data are given in the migration procedures.
- Account profiles
- In V2.1 there are new profiles with different names and different rights
to access different facilities in the GUI. Thus, the migration needs to map
the V1.1.1 profiles to the V2.1 profiles, as follows:
V1.1.1 Profile |
Becomes V2.1 Profile |
Administrator |
Administrator |
Licensing manager |
Procurement & Licensing Manager |
Software resources manager |
System Resources Manager |
- To do, after the migration
- Assign new profiles to your users, covering the tasks that you want
them to be able to have access to.
- Account details
- In V1.1.1 there was no validation for phone/fax numbers or e-mail addresses.
In V2.1 the following validation applies:
After the migration, if any of the e-mail addresses and phone/fax numbers
are not valid, you will be prompted to correct them whenever you open the
accounts containing the non-valid data.
- Duplicate logon names:
- V2.1 does not support having the same logon names in different accounts,
except where the logon names have the value <null>. Any such duplicates
will be given the logon name of MIGRATION_<id>,
where <id> is a unique numeric value supplied by
the migration tool.
- To do, after the migration
- After the migration is completed you should check for this situation,
as you may wish to assign more meaningful logon names to these accounts. The
user details are recorded in the database table ENDUSER.
[ Top of Page | Previous Page | Next Page | Contents ]