Business Service Management

Home > Installation Scenarios > Migrating Realtime Active Dashboard 2.0 to Tivoli Business Service Manager 4.1.1

Migrating Realtime Active Dashboard 2.0 to Tivoli Business Service Manager 4.1.1

This paper includes information about migrating Realtime Active Dashboard 2.0 to IBM® Tivoli® Business Service Manager 4.1.1.

Overview

In March, 2007, IBM® announced the availability of the IBM Tivoli® Business Service Manager (TBSM) Version 4.1 and followed this with TBSM Version 4.1.1 in October, 2007. This is a follow-on product to the existing Netcool® Realtime Active Dashboard (RAD) product developed by Micromuse, and now owned by IBM.

The TBSM 4.1.1 Installation Guide describes the process for migrating RAD 3.0 Fix Pack 1 to TBSM 4.1.1. It lists the possible configurations and scenarios for migrating the RAD data and the procedures for migrating the prerequisite applications such as Netcool Security Manager and Netcool OMNIbus. RAD 2.0 customers can migrate to RAD 3.0 Fix Pack 1, and then follow this supported migration process.

This paper is for those customers that are running RAD 2.0, and want to migrate directly to TBSM 4.1.1 without first upgrading to RAD 3.0 Fix Pack 1.

Attachments

In addition to this paper, several attachments are available. These attachments are needed for some of the steps included in this paper. You should be sure to download the following attachments from the same location as this paper:

migrateUsers.xml: Sample script that can be used to add migrated users to TBSM groups.

scriptedAPIStartup.bsh_Migrate: Source script used by the rad_radshell utility on TBSM 4.1.1 to import data from RAD 2.0.

scriptedAPIStartup.bsh_RAD20: Source script used by the rad_radshell utility on RAD 2.0 to export data that is compatible for import into 4.1.1.

Before You Start

The following information should be noted prior to getting started:

This paper refers to several environment variables used with RAD 2.0 or TBSM 4.1.1. They include NCHOME, RAD_HOME, OMNIHOME, and NCLICENSE. They have slightly different formats when used on Windows® versus UNIX® or Linux® systems. For example, %NCHOME% is used on Windows systems and $NCHOME on UNIX and Linux systems. For the purpose of this paper, the variable name is used without any system- indicating special characters.

Directory specifications in the migration instructions use the UNIX style forward slash separator . For Windows systems, be sure to replace all forward slashes with the backward slash ().

Always make a backup copy of any file being updated or replaced by these migration instructions.

Differences between RAD 2.0 and TBSM 4.1.1

The following section describes some of the differences between RAD 2.0 and TBSM 4.1.1. Note that many of these features are included in RAD 3.0 also. This is not a comprehensive list of functional differences between RAD 2.0 and TBSM. This is provided as a brief introduction to TBSM 4.1.1.

For detailed documentation of TBSM 4.1.1, do the following steps:

In a Web browser, go to http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc/welcome.htm
In the Contents pane (on the left), click Previous versions > Version 4.1.1

New Functions in TBSM 4.1.1

TBSM 4.1.1 includes features not found in RAD 2.0:

DataFetcher
External Service Dependency Adaptor (ESDA)
Use of Impact Policies
Support for Impact Expressions
DataSource connection to most popular databases etc.

New Environmental Features

Netcool GUI Foundation (NGF): TBSM 4.1.1 (and RAD 3.0) are both deployed in the NGF GUI container. All products that are deployed in the NGF container can be accessed from the same GUI if they are installed in the same NCHOME directory.

RAD_HOME: The RAD_HOME environment variable, used by RAD 2.0, is not required by TBSM 4.1.1. NCHOM is the root installation directory, and the TBSM 4.1.1 installer sets this variable for you.

Directory structure: Due to the NGF container, there are some changes in the directory structure from RAD 2.0 to TBSM 4.1.1, including these:

Files in RAD_HOME/etc are now in the NCHOME/etc/rad directory.
Files in RAD_HOME/log are now in the NCHOME/log directory.
Some of the other subdirectories previously under RAD_HOME are now in the NCHOME/guifoundation/webapps/sla directory.

Preparation

Planning

The migration from RAD 2.0 to TBSM 4.1.1 must be performed manually. This paper describes the required steps.

The following sections outline the environments and configurations that are supported for migration and explains how to perform the migration. In each case, instructions are provided to assist you in migrating items. Information is also provided to assist with optional migration steps for the TBSM 4.1.1 prerequisite products. It is important that you review this entire paper before proceeding with the migration.

Goals for RAD 2.0 to TBSM 4.1.1 migration:

No loss of services and templates, and custom canvases that are defined in RAD 2.0
Provide options for manually recovering events and security data
Minimal outage during transition, and thus minimal impact to state data

Prerequisite products that can be migrated:

License Server
Netcool Security Manager
Netcool OMNIbus object server

RAD 2.0 data elements that can be migrated:

RAD 2.0 services and templates
Static canvases
Maintenance schedules
Custom display icons
Property files in the etc directory

Items that are not migrated:

SLA tracking data

See the TBSM 4.1.1 Installation Guide for instructions to install TBSM 4.1.1and information for supported hardware platforms and prerequisites. Follow the steps in section 1.3 to see the TBSM 4.1.1 documentation.

Migration Scenarios

The following migration scenarios, or use cases, are possible between Netcool RAD 2.0 and TBSM 4.1.1. Note that in all cases, you must plan the type of configuration that you prefer, based on the intent of the system. These options are explained in more detail in the TBSM 4.1.1 Installation Guide. The following issues should be considered:

Is this a simple, single-server environment for Proof-of-Concept, or does it require the greater performance capability of a multi-server environment for actual production?

Will any of the prerequisite components currently in use be preserved for use with the new TBSM 4.1.1 configuration, or will new copies be installed?

Is a failover configuration required for this environment?

To migrate an existing Netcool RAD 2.0 configuration to a new TBSM 4.1.1 installation, consider the following points about the four primary TBSM 4.1.1 components:

TBSM 4.1.1: The TBSM 4.1.1 component is not supported on the same system as the RAD 2.0 component. The bulk of this paper describes how to copy the data from the RAD 2.0 system to the TBSM 4.1.1 server.
License Server: TBSM 4.1.1 provides a new license file that covers the TBSM 4.1.1 installation. If you still want to migrate your existing License server files to a new License Server, see section 3.1 Migrating License Server for additional information.
Security Manager: TBSM 4.1.1 does not support the lower levels of Security Manager that were supported by RAD 2.0. Therefore, the Security Manager component must be independently upgraded to level 1.3 or 1.4, or it can be a new installation as part of the TBSM 4.1.1 installation. You need to determine whether the existing security data (for example, user IDs, roles, and so on) will be copied to the new server or newly created. See section 3.2 Migrating Netcool Security Manager for additional information.
OMNIbus object server: Custom schema changes that were made to your existing RAD 2.0 installation can be manually imported into the new OMNIbus object server. TBSM 4.1.1 automatically picks up the schema changes by performing a rediscovery when it is started. See section 3.3 Migrating Netcool OMNIbus for additional information.

Simple installation: RAD 2.0 to TBSM 4.1.1, single server

Given the assumption that a single-server, simple installation of TBSM 4.1.1 is intended to provide a proof-of-concept rather than a production environment, for simplicity, this configuration should be a new installation without any migration of data from RAD 2.0.

However, if you want to preserve any data in an existing RAD 2.0 environment, follow the instructions in the TBSM 4.1.1 Installation Guide for a Simple Installation on a single server, and then follow the steps for copying the data from the relevant components as spelled out in the rest of this paper.

Advanced installation: RAD 2.0 to TBSM 4.1.1, Multi-server

To migrate an existing Netcool RAD 2.0 configuration to a new TBSM 4.1.1 multi-server installation, you must first determine if in addition to the new TBSM 4.1.1 component, you will install new instances of the prerequisite software.

Note that Security Manager must be independently upgraded to 1.3 or 1.4 or newly installed as part of the TBSM 4.1.1 installation.

If all new instances of prerequisite components will be used, follow the instructions in the TBSM 4.1.1 Installation Guide for Advanced Installation on a multi-server environment, selecting all the required components to be installed. Then, follow the steps in the rest of this paper for copying the data that you want from the RAD 2.0 components.

If some existing components will be reused in the TBSM 4.1.1 environment, follow the instructions in the TBSM 4.1.1 Installation Guide for Advanced Installation on a multi-server environment, selecting only the required replacement components to be installed. Then, follow the steps in the rest of this paper for copying the data that you want from the RAD 2.0 components.

Advanced: RAD 2.0 to TBSM 4.1.1, Multi-server, Failover environment

If you intend to run your environment with failover, note that you need to select this option during the installation of TBSM 4.1.1. Follow the instructions in the TBSM 4.1.1 Installation Guide for Advanced Installation on a multi-server environment, selecting the appropriate required components, and selecting whether the new servers will be Primary or Backup. Then follow the steps in the rest of this paper for copying the data that you want from the RAD 2.0 components.

After completing the migration to the primary TBSM 4.1.1 server, refer to the TBSM 4.1.1 Administrator's Guide section titled "TBSM failover" for additional information about configuring for failover. Standard failover processing does the required synchronization between the primary and backup object servers, security managers, and TBSM 4.1.1 servers.

Gather the Data that You Need

Gather the following information before beginning the migration:

Existing RAD 2.0 configuration details
1. The following host names and IP addresses:
  - RAD server
  - OMNIbus object server
  - Security Manager
  - License server
2. The following User IDs and passwords:
  - OMNIbus Object server
  - RAD 2.0 PostgreSQL
  - Security Manager
3. Home directory for the RAD 2.0 installation - RAD_HOME
4. Home directory for the OMNIbus installation used by RAD 2.0 - OMNIHOME
Target TBSM 4.1.1 configuration details
1. The following host names and IP addresses:
  - TBSM 4.1.1 server
  - OMNIbus object server, if a new target server is to be used
  - Security Manager, if a new target server is to be used
  - License server, if a new target server is to be used
2. The following port numbers:
  - TBSM console (8080 is the default port with default URL http://yourmachine:8080/)
  - OMNIbus Object Server (4100 is the default)
3. The following User IDs and passwords:
  - OMNIbus Object server.
  - TBSM 4.1.1 PostgreSQL.
  - Security Manager: Note that all Security Manager updates are done through the TBSM 4.1.1 Console on Administration page. Therefore, you need the user ID and password for using the TBSM 4.1.1 Console.
4. Home directory for the TBSM 4.1.1 installation: NCHOME
5. Home directory for the OMNIbus installation: OMNIHOME

Scheduling the Migration

Careful consideration must be given when choosing a time to perform the RAD 2.0 to TBSM 4.1.1 migration. The RAD 2.0 system will be out of service for some period of time, with a goal to minimize the outage as much as possible.

To effectively migrate the RAD 2.0 database information, the RAD 2.0 server needs to be quiesced so that no new services, templates, or other elements are created while the migration is in process.

You should take the following actions:

Ensure all console users remain logged off during the migration. User modification of the system during these migration steps might not be properly reflected into the TBSM 4.1.1 system.
Where possible, stop event flows to OMNIbus, especially for events that can result in the automatic population of service instances.

The migration process consists of copying several pieces of data from RAD 2.0 to TBSM 4.1.1. Activity can resume on the RAD 2.0 server after all data is copied, but new services or templates that are added to RAD 2.0 after the migration will not be reflected in the TBSM 4.1.1 environment.

SLA Tracking

It is important to note that SLA tracking is interrupted during the migration. The SLA definitions are migrated as part of the migration of the service templates, but outage durations, cumulative durations, and incident and violation counts are not migrated.

When the TBSM 4.1.1 server is operational and receiving events from the object server, SLA tracking resumes, but without the cumulative information that was available to the RAD 2.0 server. You might find it useful to clear the SLA engine data for each template, thus dictating when your SLA tracking resumes.

To clear the SLA data for a template:

Login to the TBSM 4.1.1 console and access the Service Administration page.
On the Templates tab, select the template that you want to modify.
From the Edit Template pane in the Service Viewer area, select the SLA tab.
Scroll to the bottom of the SLA tab and click the Clear button that is located next to the Clear SLA Engine State label.
Repeat Steps 2 - 4 for each template for which the SLA data is to be cleared.

Instance IDs

RAD 2.0 supports the ability to assign access privileges to service instances and to templates. The information for the privileges is stored in the Security Manager database, and this information includes the internal numeric instance ID that RAD 2.0 assigns to each service and template.

In addition, custom canvas views are defined by several files placed on the server file system. These file names include internal service IDs.

This paper documents a method for preserving the internal IDs when migrating to TBSM 4.1.1. If service instances and templates are already in the TBSM 4.1.1 database, there is a high probability that importing the migrated services and templates will result in conflicts with the internal IDs

Thus, the following factors must be considered when deciding if the instance IDs from RAD 2.0 must be preserved:

Because TBSM 4.1.1 requires Security Manager 1.3 or 1.4, will this component be upgraded independently or installed fresh?
Have you assigned security privileges that you want to maintain?
- If Yes, then you must preserve the instance IDs from RAD 2.0.
  Important: This means that you must do the following things:
  - Have an empty TBSM 4.1.1 database when you import the services and templates.
    Take the additional steps to preserve the instance IDs
  - Migrate your security database to the 1.3 or 1.4 instance running for TBSM 4.1.1
- If No, then there is no reason to migrate the security database if only static canvases are a consideration (not security privileges).
Do you have custom static canvases that you want to keep?
- If Yes, then you must preserve the instance IDs from RAD 2.0.
  Important: This means that you must do the following things:
  - Have an empty TBSM 4.1.1 database when you import the services and templates
  - Take the additional steps to preserve the instance IDs

In any of the cases where the RAD 2.0 internal IDs must be included in the migration, the TBSM 4.1.1 database must be empty before the migration is started. It is important to note that, by default, a TBSM 4.1.1 server that is installed using the Simple installation type will have templates and instances already defined during installation.

Possible Scenarios

The following scenarios are possible, depending on whether the existing RAD 2.0 security privileges for templates and services are to be migrated. Also, the presence of custom canvases on RAD 2.0 that must be migrated is a factor. Each of these cases requires that the RAD 2.0 internal IDs for services and templates be migrated to TBSM 4.1.

Table 1: Possible Scenarios

Maintain Security Customizations	Preparation
No security privileges or custom canvases that require migration.	This is the simplest case. The TBSM 4.1.1 database can be populated with services and templates and does not have to be emptied.
There are security privileges or custom canvases (or both) that require migration.	The TBSM 4.1.1 database must be emptied before migration is started. See section 4.1.3 Emptying the TBSM 4.1.1 database. The database for the Security Manager used for RAD 2.0 must be exported and then imported into the new Security Manager instance being used by TBSM 4.1.1.

Additional considerations

Due to differences in TBSM 4.1.1 and in the underlying Impact component, there might be changes needed to some of the elements defined in RAD 2.0 before they will work successfully in TBSM 4.1.1. The following items have been identified as possible problem areas:

The use of certain special characters in rule names

The use of certain Impact policy expression syntax in advanced threshold filter expressions that are defined in incoming status rules

Special characters in rule names

TBSM 4.1.1 does not allow spaces or special characters, other than the underscore character (_), in the names of the following types of template rules:

Incoming status rules
Numerical aggregation rules
Numerical formula rules

Migrated rule names from the RAD 2.0 environment containing spaces or special characters must be renamed, removing spaces and special characters (underscores are acceptable). Rule name changes can be made in RAD 2.0, prior to the migration for services and templates, or in TBSM 4.1.1, after the migration of services and templates.

If migrated rule names with spaces and special characters are used in TBSM 4.1.1, the rules might be ignored when determining the general state of services or aggregating rule-output values for services, likely resulting in expected status changes not occurring for some services.

Advanced threshold filters

If advanced threshold filters on incoming status rules are migrated from RAD 2.0, events might not match their targeted services in TBSM 4.1.1 due to differences in the Impact Policy Language parsers between RAD 2.0 and TBSM 4.1.1. Advanced threshold filters in RAD 2.0 might have exploited shortcomings in the IPL parser capabilities or might have generated IPL Parser Exceptions that were either ignored or not noticed as events matched other threshold filters. In TBSM 4.1.1, generated IPL Parser Exceptions will stop the threshold filter processing for the event, likely resulting in expected status changes not occurring for targeted services.

Refer to the IBM Tivoli Netcool/Impact Policy Reference Guide for information about the current language syntax, data types, operators, and functions. Correct any syntax that is no longer supported prior to migration, or if possible, check the syntax of the expressions using a policy editor in the TBSM 4.1.1 console.

If these expressions are not corrected prior to migration, check the 4.1.1 logs on the migrated system for IPL Parser Exceptions for particular templates. Then, use the TBSM 4.1.1 console to evaluate the advanced threshold filters in these templates for syntax errors.

Migrating Data for Prerequisite Software

These are the prerequisite products required for RAD 2.0 and TBSM 4.1.1, and the levels supported with each release.

Table 2: Prerequisites

Pre-requisite	RAD 2.0	TBSM 4.1.1
Netcool Security Manager	1.1, 1.2	1.3, 1.4
Netcool OMNIbus	3.5, 3.6, 7	3.6, 7
Netcool License Server	1.0 +	1.0.31

If you already have required versions of prerequisite software, you can reuse them for TBSM 4.1.1. The TBSM 4.1.1 installation process does not upgrade existing prerequisite products. It only installs the prerequisites if they do not already exist and if you selected to install them. TBSM 4.1.1 is packaged with these required prerequisites for your convenience.

For more information on migrating prerequisite software, see the documentation for the specific Netcool products at http://publib.boulder.ibm.com/tividd/td/link/tdprodlist.html#N

Migrating License Server

TBSM 4.1.1 is installed with two License Server files in the NCHOME/license/etc/ directory, (netcool_omni_anyhost.lic and netcool_tbsm_anyhost.lic) that grant sufficient authority for TBSM 4.1.1 OMNIbus. OMNIbus is the only component of the TBSM 4.1.1 solution that still requires the License Server.

If you are reusing an existing License Server for your TBSM 4.1.1 configuration, no further action is required.

If you installed a new License Server with TBSM 4.1.1, and you want to move license files not related to RAD 2.0 to the new server, copy the license files from the old license server to the new server.

Migrating Netcool Security Manager

TBSM 4.1.1 requires Security Manager 1.3 or 1.4, which is a newer level than the levels supported by RAD 2.0. Thus, a different instance of the Security Manager must be running for TBSM 4.1.1 than was being used for the RAD 2.0 system.

If you have defined custom user IDs, roles, and groups that were being used by RAD 2.0 or you have assigned specific security privileges to your RAD 2.0 services and templates, then you might want to consider migrating your existing Security Manager database. It should be noted that this upgrade involves several manual steps and might require some assistance from IBM Software support in order to achieve all your goals for the migration of security data.

If the amount of security data to be migrated is relatively small, you should consider using the TBSM 4.1.1 console (Administration page) to manually recreate the users, groups, and roles. This has the added advantage of providing you with the opportunity to assign the roles required for the migrated users to use the NGF based TBSM 4.1.1 console. See the TBSM 4.1.1 Administrator's Guide for information about users, groups, and roles required for TBSM 4.1.1.

After the users and groups have been added back to the new Security Manager database, you can use the TBSM 4.1.1 console to reapply the security assignments to your migrated services and templates. See the TBSM 4.1.1 Service Configuration Guide for detailed information on setting security privileges for service instances and templates.
Should you choose to attempt the migration of your existing Security Manager database, the following sections describe planning information and the instructions required to complete the task.

Planning the migration of the Security Manager database

In this paper, the term security data is used to represent users, groups, roles, and the mappings between these elements. Note that there might also be mappings for users and groups to tags that identify objects that are used by clients of the Security Manager.

The first consideration in planning for the migration of the Security Manager database is the version of the existing Security Manager that is being used by the RAD 2.0 system.

Security Manager Version1.1: Security Manager 1.1 used a PostgreSQL database to store the security data. This database must be upgraded to Security Manager 1.2 before attempting to migrate to the required Security Manager 1.3 or 1.4.

Security Manager Version 1.2: The Security Manager 1.2 upgrade to 1.3 or 1.4 is a much simpler process, as these versions have the same type of database.

The second consideration in migrating the Security Manager database involves the timing of the database upgrade. To minimize the steps that are required to complete the migration, it is best to have a fresh Security Manager 1.3 or 1.4 instance. All security data that has been added to the Security Manager 1.3 or 1.4 database is lost when the database is replaced by the Security Manager 1.2 security database.

For TBSM 4.1.1, consider installing only the prerequisite software initially (License Server, Omnibus, Security Manager), which provides a fresh Security Manager 1.4 instance on which to apply the database upgrade. After the database upgrade, install the TBSM 4.1.1 server, which adds more users, groups, and roles. If the TBSM 4.1.1 server is already installed when you perform the database upgrade, additional steps are required to restore the TBSM 4.1.1 security data defined during the installation of the product.

If you have data other than TBSM 4.1.1 data in the Security Manager database, this data has to be recreated manually after the upgrade of the database is complete.
Ultimately, you must make your decision on upgrading Security Manager's database based on a tradeoff between preserving existing security data versus the amount of recovery required for data that is already added to the new Security Manager 1.3 or 1.4 database.

After the security database migration is complete, and the TBSM 4.1.1 security data has been reapplied, you must update the migrated users to have the required roles for using the TBSM 4.1.1 console. This is required due to the additional roles created in TBSM 4.1.1 for using NGF, which was not a consideration for RAD 2.0.

Migrating the security database

To migrate the security database, complete the following steps:

Make a backup of the Security Manager 1.3 or 1.4 database before going any further.
If you are currently using Security Manager 1.1, see the Netcool/Security Manager 1.2 Administration Guide for information on upgrading from Security Manager 1.1. to 1.2.
If you are currently using Security Manager 1.2 or have completed the upgrade from 1.1 to 1.2, see the Netcool Security Manager 1.3 or 1.4 Installation Guide for information on upgrading from Security Manager 1.2. to 1.3 or 1.4.
If there was any security data in the older versions of Security Manager, see the Netcool Security Manager 1.3 or 1.4 Installation Guide for information on migrating this data to Security Manager 1.3 or 1.4. The steps are listed here for your convenience
1. Shut down the version 1.2 Security Manager. This creates a database script that contains all the information stored in the Security Manager database. This script is: security.script located in the NCSM_HOME/db directory.
2. Copy this script to the corresponding directory in Security Manager 1.3 or 1.4:
  
  NCHOME/security/db/security.script
3. When you next start up the version 1.3 or 1.4 instance of Netcool Security Manager, the stored information will be loaded into the Security Manager database.
To reapply the default TBSM 4.1.1 security data, run the following commands. Note that you must be in the NCHOME directory on the TBSM 4.1.1 system.
1. cd NCHOME
2. bin/ngf_api NCHOME/etc/guifoundation/antonce/machant_rad.xml.processed
3. bin/ngf_api NCHOME/etc/guifoundation/antonce/00_smprovision_init.xml.processed
To apply the roles required by TBSM 4.1.1 for the migrated users, do one of the following steps:
1. Use the TBSM 4.1.1 console and an administrative user ID to update the migrated users using the Administration page. Refer to the TBSM 4.1.1 Administrator's Guide for more information on roles required by TBSM 4.1.1. This is the preferred approach, but might not be practical depending on the number of migrated users.
2. See Appendix B for a sample script (also included in the attachments) that can be customized and used to add the migrated users to TBSM 4.1.1 groups. The script must be run from the NCHOME directory as follows, where directory specifies the path where you have placed the customized migrateUsers.xml file.
  1. cd NCHOME
  2. bin/ngf_api directory/migrateUsers.xml
Important: If there was any non-TBSM 4.1.1 security data in the Security Manager 1.3 or 1.4 database, you can manually add this data back at any time.

Migrating Netcool OMNIbus

The following scenarios must be considered for the migration of the OMNIbus Object Server (hereafter referred to as object server):

Current object server is Version 3.5

TBSM 4.1.1 requires object server Version 3.6 or Version 7. The object server that is installed with TBSM 4.1.1 cannot be installed on the same system as the current object server, because this would create conflicts between the two servers.

If you intend to replace the current Version 3.5 object server with a newer object server, you must do this upgrade manually. Refer to the appropriate section in the Netcool OMNIbus Version 7 Installation and Deployment Guide for information about upgrading your object server. After you upgrade the object server, continue with the scenario for using an existing object server Version 3.6 or Version 7.

Current object server is Version 3.6 or Version 7, and is to be reused for TBSM 4.1.1

To use an existing object server in your TBSM 4.1.1 environment, you must update the object server schema with the TBSM 4.1.1 customizations. See section 3.3.5 Installing the TBSM 4.1.1 object server schema into an existing object server for additional information.

A new object server is installed for TBSM 4.1.1

When installing a new object server for the TBSM 4.1.1 environment, none of the data in the existing object server is automatically migrated. The following data must be considered for manual migration:

Custom schema changes
Event data
Users defined for modifying Active Event Lists in TBSM 4.1.1

Using existing object server data

The following two sections describe options for using the existing object server data.

Object server data is not migrated:

The simplest and preferred approach for the existing object server data is not to attempt to move the data to the new object server. In this scenario, the expectation is that when the new object server becomes active, the resulting event flow will gradually return the TBSM 4.1.1 server state to its RAD 2.0, pre-migration state.

Depending on the results that you want for the TBSM 4.1.1 configuration, the following manual steps are required:

User customizations for modifying Active Event Lists must be reapplied.

Custom schema updates must be reapplied to the new object server. For details on how to use the nco_sql and isql utilities to apply the schema updates, refer to the section in the Netcool/OMNIbus Version 7 Administration Guide that discusses using the SQL interactive interface.

Object server data is migrated:

An alternative for preserving the object server data is to backup the database from the existing object server and restore it to the new TBSM 4.1.1 object server. This approach is more complex, but reduces the data loss and could result in a quicker recovery of the required TBSM server state.

Important: Data should only be migrated between object servers that are both of the same version. For example, both object servers are Version 3.6 or both are Version 7. Both servers must be of the same operating system architecture.

The System and Session SQL Commands section of The Netcool/OMNIbus Version 7 Administrator Guide documents an ALTER SYSTEM command that supports the backup of the Object Server database. The following commands will call the SQL command processor.

Run these on the object server being used by the RAD 2.0 server.

Windows systems: %RAD_HOME%\omnibus\bin\isql.bat -S NCOMS -U <username> -P <password>

UNIX or Linux systems: $RAD_HOME/omnibus/bin/nco_sql -server NCOMS -user <username> -password <password>

At the SQLl prompt complete the following steps:

Type ALTER SYSTEM BACKUP 'directory_name' and press Enter.
Type go and press Enter.
Type exit and press Enter.

The backup is created in the directory specified by 'directory_name'. The directory specification must be enclosed in single quotation marks. It is created within the current directory unless preceded by forward slashes ( / ).

The TBSM 4.1.1 Object Server and other dependent services must be stopped before copying the backup files. Also, be sure to backup any files that are being replaced.

The backup files (.tab files) in the directory that you specified can now be copied to the new TBSM 4.1.1 object server. The target directory on the TBSM 4.1.1 system is:

OMNIHOME/db/<servername>: (default servername is NCOMS)

At this point, additional manual actions are required to complete the object server data migration:

The TBSM 4.1.1 schema updates must be applied to the restored object server database. See section 3.3.5 Installing the TBSM 4.1.1 object server schema into an existing object server.
Do one of the following actions with the restored event data:
- Delete all the events in the object server. As the new event feeds come online with the new, restored object server, the TBSM 4.1.1 server state is gradually restored.
- Ignore the events in the restored object server. This essentially has the same effect as option 1, as TBSM 4.1.1 does not process the historical events automatically.
- Modify the existing events in OMNIbus so that TBSM 4.1.1 processes the events again. If you select this option, do this after completing the rest of the RAD 2.0 migration steps in chapter 4. You need to restore the services, templates and instance IDs before processing events.
  
  The following commands start the SQL command processor:
  
  Windows systems: %NCHOME%\omnibus\bin\isql.bat -S NCOMS -U <username> -P <password>
  
  UNIX or Linux systems: $NCHOME/omnibus/bin/nco_sql -server NCOMS -user <username> -password <password>
  
  At the Sql prompt complete the following steps:
- Type "UPDATE alerts.status SET RAD_FilterIDList = '', RAD_RawInputLastValue = 6;" and press Enter.
- Type "go" and press Enter.
- Type "exit" and press Enter.

Installing the TBSM 4.1.1 object server schema into an existing object server:

To update an existing object server so that a new TBSM 4.1.1 installation can use it, complete the following steps:

Locate the schema update file on the new TBSM 4.1.1 installation:

NCHOME/InstallTBSM/sql/tbsm_db_update.sql
Copy it to a local directory on the existing object server used by RAD 2.0.
Use the following command to import the schema on your current object server. Make sure the object server is running before executing these steps.

Run this command from local directory which has tbsm_db_update.sql

Windows systems : isql.bat -S NCOMS -U <username> -P <password> -i tbsm_db_update.sql

UNIX or Linux systems: cat tbsm_db_update.sql | $NCHOME/omnibus/bin/nco_sql -server NCOMS -user <username> -password <password>

Migrating Netcool RAD 2.0

Migrating your Services and Templates

This section describes how to import your services and templates from RAD 2.0 into TBSM 4.1.1. It is assumed that you already installed TBSM 4.1.1 on a separate system from RAD 2.0.

You should also have verified that the TBSM 4.1.1 system can be started and that you can log in to the console.

The following sections describe two types of migration for services and templates:

Simple migration of services and templates - No consideration is given to preserving the internal identifiers assigned by RAD 2.0 to the services and instances. If this is your scenario, follow the steps in section 4.1.1 Simple migration of services and templates.
Preserving RAD 2.0 internal IDs: Migration that includes preserving the internal IDs of the services and templates. If this is your scenario, follow the steps in 4.1.2 Preserving RAD 2.0 internal IDs.

See section 2 Preparation for information to help you decide which migration path you need to use.

Simple migration of services and templates

Make sure that your RAD 2.0 system is up and running, but that all GUI operations are stopped.
Back up your original scriptedAPIStartup.bsh file by renaming RAD_HOME/etc/scriptedAPIStartup.bsh to RAD_HOME/scriptedAPIStartup.bsh.save.
Copy the attachment file scriptedAPIStartup.bsh_RAD20 as RAD_HOME/etc/scriptedAPIStartup.bsh.
Start radshell in your RAD 2.0 system and then issue the following export command. This creates the RAD_HOME/export.radsh file.
1. RAD_HOME/bin/rad_radshell
2. radshell> export();
  
  If you intend to continue to run the RAD 2.0 system, you should restore the scriptedAPIStartup.bsh file to the saved version.
You now transfer the export file to your TBSM 4.1.1 installation environment.
Ensure that TBSM is up and running.
Import your services into TBSM 4.1.1. Run this command from the directory where you placed the export.radsh file.
- UNIX or Linux systems: cat export.radsh | $NCHOME/bin/rad_radshell
- Windows systems: type export.radsh | %NCHOME%\bin\rad_radshell
Log in to the GUI and check that your services and templates were properly imported.

Preserving RAD 2.0 internal IDs

You need to determine whether your TBSM 4.1.1 system has any services and templates before you migrate from RAD 2.0. If you conducted a simple installation, TBSM 4.1.1 might have automatically imported some templates and services. These services and templates need to be removed. To remove everything in your TBSM 4.1.1 database, see 4.1.3 Emptying the TBSM 4.1.1 database.

Important: Run those steps and then return to this section and continue with step 2.
Make sure that your RAD 2.0 system is up and running, but that all GUI operations are stopped.
Back up your original scriptedAPIStartup.bsh file by renaming RAD_HOME/etc/scriptedAPIStartup.bsh to RAD_HOME/scriptedAPIStartup.bsh.save.
Copy the attachment file scriptedAPIStartup.bsh_RAD20 as RAD_HOME/etc/scriptedAPIStartup.bsh.
Start radshell in your RAD 2.0 system and then issue the following export command. It creates the RAD_HOME/export.radsh file.
1. RAD_HOME/bin/rad_radshell
2. radshell> export(); \
  If you intend to continue to run the RAD 2.0 system, you should restore the scriptedAPIStartup.bsh file to the saved version.
This step creates one file that contains each service name with its corresponding internal ID from the RAD 2.0 database, and a second file with the name and ID for each template. These files are used to recreate the services and templates with their original RAD 2.0 internal ID.

Run the following commands. For each command, substitute a valid PostgreSQL database user ID for the userid parameter,and the correct port number for pppp. Enter a password if prompted by psql.

The serviceinstanceid and servicetypeid files contain the name and ID mapping information required for the migration to TBSM 4.1.1. Note that <platform> indicates the specific platform being used, such as 'win32', 'linux2x86', or 'aix'.

Run the following commands:
1. cd RAD_HOME/platform/<platform>/pgsql/bin
2. psql -d rad -U userid -t -p pppp -o serviceinstanceid -c "SELECT serviceinstancename, serviceinstanceid FROM serviceinstance;"
3. psql -d rad -U userid -t -p pppp -o servicetypeid -c "SELECT servicetypename, servicetypeid FROM servicetype;"
Transfer the export.radsh export file from your RAD 2.0 system to your TBSM 4.1.1 installation environment. You should also copy the serviceinstanceid and servicetypeid files to the TBSM 4.1.1 system. These files should all be placed in the same directory.
1. cd NCHOME/etc/rad
2. mkdir migration
3. cd migration
4. Copy export.radsh from <RAD 2.0 server>/RAD_HOME
5. Copy serviceinstanceid and servicetypeid from <RAD 2.0 server>/RAD_HOME/platform/<platform>/pgsql/bin
Ensure that TBSM is up and running.
Back up your original scriptedAPIStartup.bsh file by renaming NCHOME/etc/rad/scriptedAPIStartup.bsh to NCHOME/etc/rad/scriptedAPIStartup.bsh.save.
Copy the attachment file scriptedAPIStartup.bsh_Migrate as NCHOME/etc/scriptedAPIStartup.bsh.
Import your services into TBSM 4.1.1.
- cd NCHOME/etc/rad/migration

UNIX or Linux systems: cat export.radsh | $NCHOME/bin/rad_radshell
Windows systems: type export.radsh | %NCHOME%\bin\rad_radshell

Log in to the GUI and check that your services and templates were properly imported. Check that security privileges were preserved for services and templates and that the static canvases are available and can be viewed.

Restore the scriptedAPIStartup.bsh file to the saved version.

Emptying the TBSM 4.1.1 database

These steps empty the TBSM 4.1.1 database so that RAD 2.0 instance IDs can be migrated. Before using either of these methods, make a backup copy of your existing TBSM 4.1.1 database. You can find information on backing up the TBSM database in the TBSM 4.1.1 Administrator's Guide, under Backing up and Restoring TBSM.
After you complete importing of services and templates from RAD 2.0, you need to restore the TBSM 4.1.1 templates. See section 4.7 Restore the TBSM 4.1.1 Templates

Method 1

If templates or instances are defined on the TBSM 4.1.1 server, perform the following steps on the TBSM 4.1.1 system before running the migration utility:

Delete templates:

Open a Web browser and sign into TBSM 4.1.1.
Go to the Service Administration page.
In the Service Navigation frame, click the Templates tab.
Click the Delete Templates button ()
In the Service Viewer under Delete Templates, click the Select All button ().
In the Service Viewer under Delete Templates, click the Delete Selected button ().

Delete Instances:

Open a Web browser and sign into TBSM 4.1.1.
Go to the Service Administration page.
In the Service Navigation frame, click the Services tab.
Click the Delete Services button ().
In the Service Viewer under Delete Instances, click the Select All button ().
In the Service Viewer under Delete Instances, click the Delete Selected button ().

You can now resume the steps for preserving the RAD 2.0 internal IDs in section 4.1.2 Preserving RAD 2.0 internal IDs.

Method 2

This method is simpler to reset the TBSM 4.1.1 database. Make sure to make a backup copy in case you need to restore it.

Run the following step to delete the database data:

NCHOME/bin/rad_db setupinit

You can now resume the steps for preserving the RAD 2.0 internal IDs in section 4.1.2 Preserving RAD 2.0 internal IDs.

Custom canvas

Although the following process performs most of the migration, special cases might exist that need additional attention. Make backup copies of any files that you intend to modify, in case you need to restore them.

Before migrating Custom Canvases, be sure that you have imported the exact RAD service hierarchy from your 2.0 installation.

Copy the canvas files:
- cd RAD_HOME (on RAD 2.0 server)
- If you created custom canvases, you will have a directory called RAD_HOME/av. Copy the av directory and all the underlying files and directories to the TBSM 4.1.1 server, into the NCHOME/guifoundation/webapps/sla/ directory. The av directory will already exist on TBSM 4.1.1, but you will be adding files to it.
For UNIX and Linux systems, run the migration script (on the TBSM 4.1.1 server):

$NCHOME/guifoundation/webapps/sla/contrib/migrate_custom_canvases
For Windows systems, run the following manual steps (on the TBSM 4.1.1 server):
- cd %NCHOME%\guifoundation\webapps\sla\av\canvas\users\<username>\
- Edit all the props files and replace all occurrences of "vespa_relationship_view" with "custom_view"
- Repeat this for all the user names in the users directory.
Edit the following file:
- NCHOME/guifoundation/webapps/sla/av/xmlconfig/customEntityTemplates.xml
- The new entityTemplates that you created in RAD_HOME/customEntityTemplates.xml must be copied to the above file.
- Search for "<entityTemplate name="MyNewTemplate">
- Replace the entire contents of this section, which ends with </entityTemplate>
Edit the following file:
- NCHOME/guifoundation/webapps/sla/av/xmlconfig/ViewDefinition_CustomView.xml
- The selectors you created in RAD_HOME/customCanvasTemplates.xml must be copied to the same location in the above file.
- Search for "<-- CONFIGURE: ADD SELECTOR DEFINITION HERE -->".
- Replace the entire contents of this section, which ends with "<-- END OF SELECTOR DEFINITION -->".
Similarly, in the same file (ViewDefinition_CustomView.xml) replace entity template mappings that you created in RAD 2.0
- Search for "<-- CONFIGURE: ADD ENTITY TEMPLATE MAPPING HERE -->".
- Replace the entire contents of this section, which ends with "<-- END OF ENTITY TEMPLATE MAPPING -->".
Move any additional files (images) that you might have added. In the new directory structure:
- NCHOME/guifoundation/webapps/sla/ is equivalent to RAD_HOME/www/RAD_ROOT/
Restart the server.

Maintenance schedules

The maintenance schedule name for each service is included when you migrate services from RAD 2.0 to TBSM 4.1.1. To complete the migration of maintenance schedules, you must transfer the contents of the scheduleTime.xml file from RAD 2.0 to TBSM 4.1.1. This moves the schedules that you have defined on your RAD 2.0 system, and makes them available for assigning to individual services.

Note that if you have existing schedules on your TBSM 4.1.1 system, and you want to maintain them, you need to manually add data from the RAD 2.0 XML file into the TBSM 4.1.1 file. If you do not have any existing schedules in TBSM 4.1, you can simply copy the XMLl file from RAD 2.0.

Back up your NCHOME/guifoundation/webapps/sla/xml/scheduleTime.xml file before doing the copy.

Copy the scheduleTime.xml file from the RAD_HOME directory in RAD 2.0. The destination directory in TBSM 4.1.1 is NCHOME/guifoundation/webapps/sla/xml

Custom display icons

User supplied and modified icons must be migrated manually. Copy any added or modified .gif and .svg files from the RAD 2.0 server to the appropriate directories on the TBSM 4.1.1 server. Refer to the TBSM 4.1.1 Administrator's Guide for more information on adding and modifying display icons. Make backup copies of any files you intend to modify in case you need to restore them.

Move the added and modified icons from the following source directories:

RAD_HOME/www/RAD_ROOT/icons

RAD_HOME/www/RAD_ROOT/icons/svg

The following directories are the destination directories on TBSM 4.1.1:

NCHOME/guifoundation/webapps/sla/icons

NCHOME/guifoundation/webapps/sla/icons/svg

Property Files in the etc directory

The following files should be migrated from the RAD 2.0 environment into TBSM 4.1.1. Back up the installed versions of these files on the TBSM 4.1.1 Server before performing this step.

Additionally, after making a comparison of each file from the old RAD 2.0 copy against the new TBSM 4.1.1 copy, copy your preferred differences into the new TBSM 4.1.1 levels. Contact IBM Tivoli Level 2 if you need any assistance performing this step.

RAD_HOME/etc/rad/RAD_av.props

RAD_HOME/etc/rad/RAD_chart.props

RAD_HOME/etc/rad/RAD_sla.props

The destination directory on TBSM 4.1.1 is NCHOME/etc/rad/

Other customization

There could be other customization that has been made to your RAD 2.0 system that was not migrated by the manual steps described previously.

For any customization that was made to your system, you must make the same customization to the TBSM 4.1.1 system. Refer to the TBSM 4.1.1 Customization Guide to ensure that the modifications are supported in TBSM 4.1.1, and that you have the up-to-date procedure for making the changes.

Restore the TBSM 4.1.1 Templates

The following step needs to be run if you ran one of the two methods to empty the database. The empty step deleted all default templates within TBSM 4.1.1 and allowed you to copy the appropriate files from RAD 2.0. After you complete importing the services and templates from RAD 2.0, you need to restore the TBSM 4.1.1 templates.

To restore the templates for the database:

Windows systems: cd %NCHOME%\guifoundation\webapps\sla\install
type BSM_Templates.radsh | %NCHOME%\bin\rad_radshell.bat

UNIX or Linux systems: cd $NCHOME/guifoundation/webapps/sla/install
cat BSM_Templates.radsh | $NCHOME/bin/rad_radshell

Appendex A. MIGRATE_CUSTOM_CANVASES

#!/bin/sh
# Usage: migrate_custom_canvases

if [ "$1" = "-help"  ]; then
        echo "usage: migrate_custom_canvases"
        exit 1
fi

for i in $NCHOME/guifoundation/webapps/sla/av/canvas/*/*/*props ; \
    do \
      cat $i | sed s/vespa_relationship_view/custom_view/g > /tmp/rad_temp.$$
      cp /tmp/rad_temp.$$ $i
done

Appendix B. migrateUsers.xml

The following xml script can be modified and used to add migrated RAD 2.0 users to the groups required for access to the TBSM 4.1.1 console. Follow the instructions in the comments. This file is included as an attachment to this paper.

<?xml version="1.0"?>
<project name="RAD add users to groups" default="main" basedir=".">

	<!-- Must create taskdefs in order to use machant tasks. See
		$NCHOME/guifoundation/webapps/desktop/xml/machsample.xml
		for a sample of all machant tasks and related taskdefs. -->
    <taskdef name="initAdminUserAndPasswordTask" classpath="%CLASSPATH%" classname="com.micromuse.ncgf.security.anttask.InitAdminUserAndPasswordTask"/>
	<taskdef name="usergrouproletask" classpath="%CLASSPATH%" classname="com.micromuse.ncgf.security.anttask.UserGroupRoleAntTask"/>



	<!-- Global properties for this build. Note: Values of the form __XXX__ are
		variables. They are replaced with actual values by the post-install
		script. -->
	<property name="server" value="localhost:8080"/>
	<property name="default_ngf_user_role" value="user"/>
	<property name="user_role" value="rad_user"/>
	<property name="ncw_user_role" value="ncw_user"/>
	<property name="chart_user_role" value="rad_sla_chart_is_visible"/>
	<property name="psml_file" value="C:\IBM\Netcool/etc/rad/installer/rad.psml"/>
	<property name="slachart_psml_file" value="C:\IBM\Netcool/etc/rad/installer/RADSLAReport.psml"/>
	<property name="default_readonly_serviceview_psml_file" value="C:\IBM\Netcool/etc/rad/installer/RADDefaultDesktopServiceView.psml"/>

	 <target name="main" depends="init,radUserGroupRoleTaskTarget"
         description="Main task to call all other tasks."/>

      <target name="init" description="Initialize username and password for admin user">
	    <initAdminUserAndPasswordTask/>
      </target>


  <target name="radUserGroupRoleTaskTarget" description="usergrouproletask">

    <!--  usergrouproletask comments
          - general:
            - accountpassword is mandatory
            - verbose is optional. default is set to true
            - for role and group subtasks, a name and action must
              be provided for each subtask
     -->

    <!--  Repeat the following 2 blocks as often as needed for the number of userids.
          Replace "uuuuuu" with a migrated userid for each pair of tasks.
          This will add the users to groups Desktop (to access NGF) and RADUsers to
          access the TBSM 4.1.1 pages. 
      -->

    <usergrouproletask
      accountusername="uuuuuu"
      verbose="true"

      username="${username}"
      password="${password}"
      server="${server}">

      <group name="Desktop" action="add"/>
    </usergrouproletask>

    <usergrouproletask
      accountusername="uuuuuu"
      verbose="true"

      username="${username}"
      password="${password}"
      server="${server}">

      <role name="rad_user" action="add"/>
      <group name="RADUsers" action="add"/>
    </usergrouproletask>

  </target>

References

TBSM 4.1.1 Documentation http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc/welcome.htm. In the Contents pane (on the left), click Previous versions > Version 4.1.1.

Prerequisite software
http://publib.boulder.ibm.com/tividd/td/link/tdprodlist.html#N

IBM Open Process and Automation (OPAL)
http://catalog.lotus.com/wps/portal/topal