IBM Tivoli Software IBM Tivoli Software

[ Bottom of Page | Previous Page | Next Page | Contents ]


Administration server GUI

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:
  • E-mail addresses must satisfy the requirements of the ARPA Internet address standard RFC822
  • Phone/fax numbers can contain the following characters 0-9, (, ), -, +, space

    However, the non-numeric characters cannot be combined in sequence with each other, without at least one numeric character or a space intervening.

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 ]