Net Cool Administration Guide

Tivoli Netcool/Impact Version 5.1.
Administration Guide
SC23-8829-02
Tivoli Netcool/Impact Version 5.1.1
Administration Guide
SC23-8829-02
Note Before using this information and the product it supports, read the information in Appendix D, Notices, on page 115.
Edition notice This edition applies to version 5.1.1 of IBM Tivoli Netcool/Impact and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright International Business Machines Corporation 2006, 2009. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
About this publication . . . . . . . . vii
Intended audience . . . . . . . . . . . . vii Publications . . . . . . . . . . . . . . vii Tivoli Netcool/Impact library . . . . . . . vii Accessing terminology online . . . . . . . vii Accessing publications online . . . . . . . viii Ordering publications . . . . . . . . . viii Accessibility . . . . . . . . . . . . . . viii Tivoli technical training . . . . . . . . . . viii Support for problem solving . . . . . . . . . ix Using IBM Support Assistant . . . . . . . ix Obtaining fixes . . . . . . . . . . . . x Receiving weekly support updates . . . . . . x Contacting IBM Software Support . . . . . . xi Conventions used in this publication . . . . . xiii Typeface conventions . . . . . . . . . . xiii Operating system-dependent variables and paths . . . . . . . . . . . . . . . xiii Using Impact Server administration scripts . Configuring RMI ports . . . . . . . . Monitoring deployment components . . . . Monitoring server instances . . . . . . Log4j properties file . . . . . . . . Monitoring services. . . . . . . . . Deleting Impact Server instances . . . . . Enabling read-only mode . . . . . . . . Stopping the embedded version of WebSphere Application Server . . . . . . . . . . Starting the embedded version of WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 34 35 35 35 36 36 37
. 37 . 38
Chapter 4. Managing the GUI Server . . 39

Overview of the GUI Server . . . GUI Server components . . . . GUI engine . . . . . . . Name Server . . . . . . . Running the GUI Server . . . . Redeploying the GUI Server . . . Enabling HTTPS on the GUI Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 39 39 40 40 40
Chapter 1. Introduction . . . . . . . . 1
Overview of deployments . Deployment components . Impact Server . . . . GUI Server . . . . . Netcool Database Server Deployment types . . . Setting up a deployment . Planning an installation. Installing components . Configuring components Running a deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 2 2 3 3 3 3 4
| Chapter 2. Installing Tivoli | Netcool/Impact . . . . . . . . . . . | System requirements. . . . . . . . . . . | Running the installer in GUI mode . . . . . . | Running the installer in console mode . . . . | Running the installer in silent mode . . . . . | Silent installation response file . . . . . . . | Verifying the deployment. . . . . . . . . | Installation logs . . . . . . . . . . . . | Installing the JRExec server (Windows platforms). | Setting up JDBC for GenericSQL DSA . . . . | Running a deployment . . . . . . . . . | Uninstalling Tivoli Netcool/Impact . . . . . Uninstalling Tivoli Netcool/Impact components | on Windows platforms . . . . . . . . | Uninstalling Tivoli Netcool/Impact components | on UNIX platforms . . . . . . . . . . | | Post installation utility. . . . . . . . . .
. 5
. 5 . 6 . 17 . 23 . 25 . 27 . 28 . 28 . 28 . 29 . 29 . 29 . 29 . 30
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 5. Server clustering . . . . . 41

Server clustering overview . . . . . . . Server cluster components . . . . . . . Name Server cluster components . . . . . Impact Server clustering process . . . . . Name Server clustering process. . . . . . Setting up the server cluster . . . . . . . Runtime analysis . . . . . . . . . . Checking the cluster status in the Name Server Configuring Event Processor service . . . . Connection properties between the Name Server and the Impact Server . . . . . . . . . Connection properties between the Name Server and the GUI Server . . . . . . . . . . Name Server configuration properties . . . Impact Server cluster configuration properties . . . . . . . . . . . . . . . . . . . . . . . 41 41 42 42 43 44 47 47 48
. 49 . 49 . 50 . 52
Chapter 6. Version control . . . . . . 55

Version control overview . Version control process . Configuring version control Version control script . . Checking out files . . Checking in files. . . Adding files . . . . Unchecking out files . Creating a checkpoint . Updating the sandbox . Migrating to Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 55 56 56 57 57 57 58 58 58 59
Chapter 3. Managing the Impact Server 33

Overview of the Impact Server . . Creating Impact Server instances . Running Impact Server instances .
Copyright IBM Corp. 2006, 2009
. . .
. . .
. . .
. . .
. . .
. 33 . 33 . 34
Chapter 7. Netcool Database Server . . 61

Overview of the Netcool Database Server . Setting the database port . . . . . . . . . . . . 61 . 61
iii
Running the Netcool Database Server Starting the database server . . . Stopping the database server . . Managing the Netcool Database Server Viewing the database status . . . Resetting the database . . . . . Connecting to the database with the line client . . . . . . . . . Backing up the database . . . . Restoring the database. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . command . . . . . . . . . . . .
. . . . . .
61 62 62 62 62 62
. 62 . 62 . 63
Chapter 8. JRExec server. . . . . . . 65

Overview of the JRExec server . . . . . . . . 65 Running the JRExec server on UNIX platforms . . 65 Running the JRExec server on Windows platforms 65 Configuring the JRExec server . . . . . . . . 65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 9. Self-monitoring . . . . . . 67
Self-monitoring overview . . . . . . . . . . Self-monitoring in server cluster . . . . . . . Setting up self-monitoring using the GUI . . . . Running self-monitoring using the GUI . . . . . Running self-monitoring using the command line interface . . . . . . . . . . . . . . . Setting the Object Server Data Source for monitoring events . . . . . . . . . . . . . . . . Memory status monitoring . . . . . . . . . Java memory status. . . . . . . . . . . System memory status. . . . . . . . . . Combined memory status . . . . . . . . Memory status severity . . . . . . . . . Memory event fields . . . . . . . . . . Checking if memory status monitoring is enabled Enabling memory status monitoring . . . . . Disabling memory status monitoring . . . . . Viewing current memory status. . . . . . . Viewing memory status history. . . . . . . Viewing the total JVM heap size . . . . . . Viewing the maximum JVM heap size . . . . Viewing the free system memory . . . . . . Checking if memory status events are deduplicated . . . . . . . . . . . . . Disabling memory status event deduplication . . Viewing memory status event intervals . . . . Changing memory status event intervals . . . Queue status monitoring . . . . . . . . . . Queue status severity . . . . . . . . . . Queue status event fields . . . . . . . . . Checking if queue status monitoring is enabled Enabling queue status monitoring . . . . . . Disabling queue status monitoring. . . . . . Viewing the current queue status . . . . . . Viewing the queue status history . . . . . . Checking if queue status event deduplication is enabled. . . . . . . . . . . . . . . Enabling queue status event deduplication . . . Disabling queue status event deduplication. . . Viewing queue status event intervals . . . . . Changing queue status event intervals . . . . Data source status monitoring . . . . . . . . 67 67 68 68 68 69 69 69 70 70 70 71 71 71 72 72 72 72 72 72 72 72 73 73 73 73 74 74 75 75 75 75 75 75 75 75 76 76
Data source status events . . . . . . . . | Data source status event fields . . . . . . | Checking if data source status monitoring is | enabled. . . . . . . . . . . . . . | Enabling data source status monitoring . . . | Disabling data source status monitoring . . . | Viewing the current data source status . . . | Viewing the data source status history . . . | | Cluster Status Monitoring . . . . . . . . Starting self-monitoring on a secondary cluster | member . . . . . . . . . . . . . | Cluster status events . . . . . . . . . | Cluster status event fields . . . . . . . | Checking if cluster status monitoring is enabled | Enabling cluster status monitoring. . . . . | Disabling cluster status monitoring . . . . | Viewing the current cluster status . . . . . | Viewing the cluster status history . . . . . |
. 76 . 77 . . . . . . 78 78 78 78 78 78
. 79 . 79 . 79 80 . 80 . 81 . 81 . 81
Chapter 10. Secure communication in Tivoli Netcool/Impact . . . . . . . . 83

Setting up SSL communication in Tivoli Netcool/Impact . . . . . . . . . . . . . Generating the SSL keystore, server certificate and truststore. . . . . . . . . . . . . Copying the SSL keystore, server certificate and truststore . . . . . . . . . . . . . . Configuring the embedded version of WebSphere Application Server for SSL certificate and key management . . . . . . . . . . . . . Configuring the Name Server for SSL . . . . Configuring Impact Server for SSL . . . . . Configuring the GUI Server for SSL . . . . . Deploying Virtual Member Manager adapter . . . Installing Virtual Member Manager adapter on embedded version of WebSphere Application Server . . . . . . . . . . . . . . . Validating the installation script . . . . . . Mapping roles to users . . . . . . . . . Configuring LDAP or Active Directory . . . . Mapping roles to groups and users managed in LDAP . . . . . . . . . . . . . . . Setting up SSL communication with the Object Server . . . . . . . . . . . . . . . 83 83 84
84 85 85 85 85
86 86 86 87 88 89
| |
Chapter 11. Command-line tools . . . . 91

nci_crypt . . . . . . . . . . . . . . . 91 nci_export . . . . . . . . . . . . . . . 91 nci_import. . . . . . . . . . . . . . . 92 nci_trigger . . . . . . . . . . . . . . . 92 nci_policy . . . . . . . . . . . . . . . 94 Using command line manager . . . . . . . . 94 Event Processor commands . . . . . . . . . 96 Email Reader commands . . . . . . . . . . 97 Email Sender commands . . . . . . . . . . 98 Policy Activator commands . . . . . . . . . 98 Hibernating Policy Activator commands . . . . . 98 Corba Name commands . . . . . . . . . . 99 Policy Logger commands . . . . . . . . . . 99 OMNIbus Event Reader commands . . . . . . 100
| | | | | | | | | |
iv
Netcool/Impact: Administration Guide
| | | | | | | | | |
Database Event Reader commands . Database Event Listener commands . JMS Message Listener commands. .
. . .
. . .
. . .
. . .
. 103 . 105 . 105
| |
Performing the security transition Migrating the reporting data . .
. .
. .
. .
. .
. .
. 112 . 112
Appendix C. Accessibility . . . . . . 113 Appendix A. Migrating from Security Manager to Virtual Member Manager . 109 Appendix B. Migrating Tivoli Netcool/Impact from releases before 5.1 to 5.1.1. . . . . . . . . . . . . 111
Importing the existing configuration into 5.1 installation . . . . . . . . . . . . . . 111
Appendix D. Notices . . . . . . . . 115

Trademarks . . . . . . . . . . . . . . 117
Glossary of terms . . . . . . . . . 119 Index . . . . . . . . . . . . . . . 125
Contents
vi
About this publication

The Tivoli Netcool/Impact Administration Guide contains instructions on installing, configuring, running and monitoring Netcool/Impact. Note: Changes for the 5.1.1 version are marked with vertical change bars in the left margin.
Intended audience
This publication is for users who are responsible for installing, configuring, running and monitoring Netcool/Impact.
Publications
This section lists publications in the Netcool/Impact library and related documents. The section also describes how to access Tivoli publications online and how to order Tivoli publications.
Tivoli Netcool/Impact library

v Quick Start Guide, CZ7USML Provides concise information about installing and running Tivoli Netcool/Impact for the first time. v Administration Guide, SC23882902 Provides information about installing, running and monitoring the product. v User Interface Guide, SC23883002 Provides instructions for using the Graphical User Interface (GUI). v Policy Reference Guide, SC23883102 Contains complete description and reference information for the Impact Policy Language (IPL). v DSA Reference Guide, SC23883202 Provides information about data source adaptors (DSAs). v Operator View Guide, SC23885102 Provides information about creating operator views. v Solutions Guide, SC23883402 Provides end-to-end information about using features of Tivoli Netcool/Impact. v Integrations Guide, SC27283400 Contains instructions for integrating Tivoli Netcool/Impact with other IBM software and other vendor software. v Troubleshooting Guide, GC27283300 Provides information about troubleshooting the installation, customization, starting, and maintaining Tivoli Netcool/Impact.
Accessing terminology online

The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. The Tivoli Software Glossary is available at the following Tivoli software library Web site:
vii
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm The IBM Terminology Web site consolidates the terminology from IBM product libraries in one convenient location. You can access the Terminology Web site at the following Web address: http://www.ibm.com/software/globalization/terminology
Accessing publications online

The Quick Start DVD contains the publications that are in the product library. The format of the publications is PDF, HTML, or both. Refer to the readme file on the DVD for instructions on how to access the documentation. IBM posts publications for this and all other Tivoli products, as they become available and whenever they are updated, to the Tivoli Information Center Web site at http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp. Note: If you print PDF documents on other than letter-sized paper, set the option in the File Print window that allows Adobe Reader to print letter-sized pages on your local paper.
Ordering publications
You can order many Tivoli publications online at http:// www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss. You can also order by telephone by calling one of these numbers: v In the United States: 800-879-2755 v In Canada: 800-426-4968 In other countries, contact your software account representative to order Tivoli publications. To locate the telephone number of your local representative, perform the following steps: 1. Go to http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss. 2. Select your country from the list and click Go. 3. Click About this site in the main panel to see an information page that includes the telephone number of your local representative.
Accessibility
Accessibility features help users with a physical disability, such as restricted mobility or limited vision, to use software products successfully. With this product, you can use assistive technologies to hear and navigate the interface. You can also use the keyboard instead of the mouse to operate all features of the graphical user interface. For additional information, see Appendix C, Accessibility, on page 113.
Tivoli technical training

For Tivoli technical training information, refer to the following IBM Tivoli Education Web site at http://www.ibm.com/software/tivoli/education.
viii
Support for problem solving

If you have a problem with your IBM software, you want to resolve it quickly. This section describes the following options for obtaining support for IBM software products: v v v v Using IBM Support Assistant Obtaining fixes on page x Receiving weekly support updates on page x Contacting IBM Software Support on page xi
Using IBM Support Assistant

The IBM Support Assistant is a free, stand-alone application that you can install on most workstations and also use to perform remote troubleshooting of other workstations. You can enhance the application by installing product-specific add-ons for the IBM products you use. The IBM Support Assistant saves you the time it takes to search the product, support, and educational resources. Several troubleshooting features are provided, including the ability to perform guided troubleshooting to aid in problem resolution, and also the ability to collect diagnostic information. The collected diagnostic information can then be used to self-diagnose the problem, or it can be included in an Electronic Service Request (ESR) submitted to IBM Support engineers. The ESR tool is used to open, update, and report on PMRs (Problem Management Records) online. See http://www.ibm.com/software/support/help.html for assistance in using the ESR tool. For more information, and to download the IBM Support Assistant, see http://www.ibm.com/software/support/isa. Currently, the add-on is supported by IBM Support Assistant V4.1 or later. After you download and install the IBM Support Assistant, follow these steps to install the IBM Support Assistant add-on for your product: 1. Start the IBM Support Assistant application. 2. From the File > Preferences > Updater preferences menu, provide the URL to update the site under Specify an Update Site > Location. 3. Select http from the list. 4. Validate the site and click OK to confirm changes. 5. Run Update > Find new > Product Add-ons. 6. Select the appropriate plug-in 7. Read the license and description, and if you comply, select I accept the terms in the license agreements and click Next. 8. Click Finish to proceed with the installation, and when prompted, restart the IBM Support Assistant to complete the installation. To collect the diagnostic files and include them in an ESR that can be sent to IBM Support engineers, view the Help files from the Help menu bar. To perform the collection of diagnostic files for self-diagnosis only, complete the following steps: 1. Start the IBM Support Assistant application. 2. From the Home screen, select Analyze Problem. 3. In the Select A Collector dialog box, expand the appropriate product name, and select the agent for which you want to collect diagnostic information. Choose Add.
ix
4. After the agent or agents are added to the Collector Queue, choose Collect All to begin the collection. 5. Enter the information requested in the dialog boxes. 6. The final dialog box requests whether or not you want to upload the collection file to IBM Support or another FTP location. If you only want to view the collected files on your computer, choose Do Not FTP the Logs. 7. The collection has finished. You can view the collected files by clicking the compressed file in the Collector Status dialog box.
Obtaining fixes
A product fix might be available to resolve your problem. To determine which fixes are available for your Tivoli software product, follow these steps: 1. Go to the IBM Software Support Web site at http://www.ibm.com/software/ support. 2. Under Select a brand and/or product, select Tivoli. 3. Click the right arrow to view the Tivoli support page. 4. Use the Select a category field to select the product. 5. Select your product and click the right arrow that shows the Go hover text. 6. Under Download, click the name of a fix to read its description and, optionally, to download it. If there is no Download heading for your product, supply a search term, error code, or APAR number in the field provided under Search Support (this product), and click the right arrow that shows the Go hover text. For more information about the types of fixes that are available, see the IBM Software Support Handbook at http://techsupport.services.ibm.com/guides/ handbook.html.
Receiving weekly support updates

To receive weekly e-mail notifications about fixes and other software support news, follow these steps: 1. Go to the IBM Software Support Web site at http://www.ibm.com/software/ support. 2. Click My support in the far upper-right corner of the page under Personalized support. 3. If you have already registered for My support, sign in and skip to the next step. If you have not registered, click register now. Complete the registration form using your e-mail address as your IBM ID and click Submit. 4. The Edit profile tab is displayed. 5. In the first list under Products, select Software. In the second list, select a product category (for example, Systems and Asset Management). In the third list, select a product sub-category (for example, Application Performance & Availability or Systems Performance). A list of applicable products is displayed. 6. Select the products for which you want to receive updates. 7. Click Add products. 8. After selecting all products that are of interest to you, click Subscribe to email on the Edit profile tab. 9. In the Documents list, select Software. 10. Select Please send these documents by weekly email.
11. Update your e-mail address as needed. 12. Select the types of documents you want to receive. 13. Click Update. If you experience problems with the My support feature, you can obtain help in one of the following ways: Online Send an e-mail message to erchelp@ca.ibm.com, describing your problem. By phone Call 1-800-IBM-4You (1-800-426-4968).
Contacting IBM Software Support

IBM Software Support provides assistance with product defects. The easiest way to obtain that assistance is to open a PMR or Electronic Service Request (ESR) directly from the IBM Support Assistant (see Using IBM Support Assistant on page ix). Before contacting IBM Software Support, your company must have an active IBM software maintenance contract, and you must be authorized to submit problems to IBM. The type of software maintenance contract that you need depends on the type of product you have: v For IBM distributed software products (including, but not limited to, Tivoli, Lotus, and Rational products, and DB2 and WebSphere products that run on Windows or UNIX operating systems), enroll in Passport Advantage in one of the following ways: Online Go to the Passport Advantage Web site at http://www-306.ibm.com/ software/howtobuy/passportadvantage/pao_customers.htm . By phone For the phone number to call in your country, go to the IBM Software Support Web site at http://techsupport.services.ibm.com/guides/ contacts.html and click the name of your geographic region. v For customers with Subscription and Support (S & S) contracts, go to the Software Service Request Web site at https://techsupport.services.ibm.com/ssr/ login. v For customers with IBMLink, CATIA, Linux, OS/390, iSeries, pSeries, zSeries, and other support agreements, go to the IBM Support Line Web site at http://www.ibm.com/services/us/index.wss/so/its/a1000030/dt006. v For IBM eServer software products (including, but not limited to, DB2 and WebSphere products that run in zSeries, pSeries, and iSeries environments), you can purchase a software maintenance agreement by working directly with an IBM sales representative or an IBM Business Partner. For more information about support for eServer software products, go to the IBM Technical Support Advantage Web site at http://www.ibm.com/servers/eserver/techsupport.html. If you are not sure what type of software maintenance contract you need, call 1-800-IBMSERV (1-800-426-7378) in the United States. From other countries, go to the contacts page of the IBM Software Support Handbook on the Web at http://techsupport.services.ibm.com/guides/contacts.html and click the name of your geographic region for phone numbers of people who provide support for your location. To contact IBM Software support, follow these steps:
xi
1. Determining the business impact 2. Describing problems and gathering information 3. Submitting problems
Determining the business impact

When you report a problem to IBM, you are asked to supply a severity level. Use the following criteria to understand and assess the business impact of the problem that you are reporting: Severity 1 The problem has a critical business impact. You are unable to use the program, resulting in a critical impact on operations. This condition requires an immediate solution. Severity 2 The problem has a significant business impact. The program is usable, but it is severely limited. Severity 3 The problem has some business impact. The program is usable, but less significant features (not critical to operations) are unavailable. Severity 4 The problem has minimal business impact. The problem causes little impact on operations, or a reasonable circumvention to the problem was implemented.
Describing problems and gathering information

When describing a problem to IBM, be as specific as possible. Include all relevant background information so that IBM Software Support specialists can help you solve the problem efficiently. To save time, know the answers to these questions: v Which software versions were you running when the problem occurred? v Do you have logs, traces, and messages that are related to the problem symptoms? IBM Software Support is likely to ask for this information. v Can you re-create the problem? If so, what steps were performed to re-create the problem? v Did you make any changes to the system? For example, did you make changes to the hardware, operating system, networking software, and so on. v Are you currently using a workaround for the problem? If so, be prepared to explain the workaround when you report the problem.
Submitting problems
You can submit your problem to IBM Software Support in one of two ways: Online Click Submit and track problems on the IBM Software Support site at http://www.ibm.com/software/support/probsub.html. Type your information into the appropriate problem submission form. By phone For the phone number to call in your country, go to the contacts page of the IBM Software Support Handbook at http://techsupport.services.ibm.com/ guides/contacts.html and click the name of your geographic region. If the problem you submit is for a software defect or for missing or inaccurate documentation, IBM Software Support creates an Authorized Program Analysis Report (APAR). The APAR describes the problem in detail. Whenever possible,
xii
IBM Software Support provides a workaround that you can implement until the APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the Software Support Web site daily, so that other users who experience the same problem can benefit from the same resolution.
Conventions used in this publication

This publication uses several conventions for special terms and actions, operating system-dependent commands and paths, and margin graphics.
Typeface conventions
This publication uses the following typeface conventions: Bold v Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text v Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip:, and Operating system considerations:) v Keywords and parameters in text Italic v Citations (examples: titles of publications, diskettes, and CDs v Words defined in text (example: a nonswitched line is called a point-to-point line) v Emphasis of words and letters (words as words example: Use the word that to introduce a restrictive clause.; letters as letters example: The LUN address must start with the letter L.) v New terms in text (except in a definition list): a view is a frame in a workspace that contains data. v Variables and values you must provide: ... where myname represents.... Monospace v Examples and code examples v File names, programming keywords, and other elements that are difficult to distinguish from surrounding text v Message text and prompts addressed to the user v Text that the user must type v Values for arguments or command options
Operating system-dependent variables and paths

This publication uses the UNIX convention for specifying environment variables and for directory notation. When using the Windows command line, replace $variable with % variable% for environment variables and replace each forward slash (/) with a backslash (\) in directory paths. The names of environment variables are not always the same in the Windows and UNIX environments. For example, %TEMP% in Windows environments is equivalent to $TMPDIR in UNIX environments. Note: If you are using the bash shell on a Windows system, you can use the UNIX conventions.
xiii
xiv
Chapter 1. Introduction
A Tivoli Netcool/Impact deployment is an installation of Tivoli Netcool/Impact components in your environment.
Overview of deployments
Tivoli Netcool/Impact can be deployed as a single system installation and a distributed installation. For more information about deployment types, see Deployment types on page 2. To set up the deployment, you run the installer programs on systems in your environment. The installer copies program files to the systems and set the minimal required configuration options. After a successful installation of all the components, you can then customize the configuration according to your needs. For more information about customizing your deployment, see Setting up a deployment on page 3. To run the deployment, you use a set of administration scripts, or services administration tools, depending on your operating system. For more information about running the deployment, see Running a deployment on page 4. A centralized logging feature is provided that is used by both the Impact Server and the GUI Server, to monitor application events and status during application runtime. In addition, you can use application subcomponents, like for example services, to configure them to log their activity to files. For more information about monitoring a deployment, see Monitoring deployment components on page 35. You can use the Object Server as an external authentication and authorization source for your deployment. For more information about authentication and authorization, see Deploying Virtual Member Manager adapter on page 85.
Deployment components
A deployment has the following components: Impact Server The Impact Server is the primary component of a deployment. This component manages the data model, services, and policies that make up your Tivoli Netcool/Impact implementation and runs the policies in real time in response to events that occur in your environment. GUI Server The GUI Server is the component that is responsible for managing the GUI. The GUI Server brokers HTTP requests from users Web browsers and returns the graphical user interface views that you use to work with data model services, and policies.
Impact Server
The Impact Server is the primary component of a deployment. This component manages the data model, services, and policies that make up your Tivoli Netcool/Impact implementation and runs the policies in real time in response to events that occur in your environment.
The Impact Server has a runnable subcomponent called the JRExec server that you can use to run external commands, scripts, and applications from within a policy. The Impact Server runs as an application instance inside a Java application server. By default, the Impact Server runs inside the embedded version of WebSphere Application Server, the application server that is installed automatically as part of the Tivoli Netcool/Impact installation. For information about managing the Impact Server, see Chapter 3, Managing the Impact Server, on page 33.
GUI Server
The GUI Server is the component that is responsible for managing the GUI. The GUI Server brokers HTTP requests from users Web browsers and returns the graphical user interface views that you use to work with data model services, and policies. The GUI Server has a subcomponent called the Name Server that provides application registry functionality for the Tivoli Netcool/Impact components. The components use the Name Server to locate and establish connections to each other. The Impact Server also uses the Name Server for server clustering. Like the Impact Server, the GUI Server runs as a hosted application inside a Java application server. By default, the GUI Server runs inside the embedded version of WebSphere Application Server that is installed automatically as part of the Tivoli Netcool/Impact installation. For more information about the GUI Server, see Chapter 4, Managing the GUI Server, on page 39.
Netcool Database Server

The Netcool Database Server is a specially configured version of an embedded HSQL that has been prepared for use with Tivoli Netcool/Impact and other Netcool products. The database is used to store the underlying data used by the GUI reporting tools. For more information about the Netcool Database Server, see Chapter 7, Netcool Database Server, on page 61.
Deployment types
The following deployment types are supported: Single-system deployment A single-system deployment consists of the Impact Server and the GUI Server installed on a single system in your environment. A single-system deployment is suitable for testing and demonstration purposes. Distributed deployment A distributed deployment consists of one or more instances of the Impact Server and the GUI Server installed across different systems in your environment. A distributed deployment is suitable for most real-world implementations of Tivoli Netcool/Impact.
A typical distributed deployment can consist of two or more instances of the Impact Server installed on separate systems and configured as part of a server cluster, and an instance of the GUI Server installed on a system that is configured to allow users Web browsers to access the GUI. Server clustering provides failover and load-balancing functionality for the Impact Server instances. For more information about server clustering, see Chapter 5, Server clustering, on page 41.
Setting up a deployment
Before you start setting up Tivoli Netcool/Impact, you must have an understanding of how Netcool/OMNIbus and other Netcool products are installed and used in your environment. Specifically, you must know what type of alerts are collected by Netcool probes and monitors, and how the alerts are stored in the Netcool/OMNIbus ObjectServer database. You must also have an understanding of your network topology, including the types of systems, devices, and applications that exist on the network and how they are monitored by Netcool/OMNIbus.
Planning an installation
After you understand how Netcool/OMNIbus and other Netcool products are installed and used in your environment, you can plan your deployment. For testing or demonstration purposes, a good practice is to install Tivoli Netcool/Impact and its components on a single system. This type of deployment requires little planning and is the easiest to create and maintain. For real life production deployments, you must take into account your goals, requirements, and available resources before you install the software. One best practice is to create a diagram of the installation you want to create before you begin. IBM technical support can help you determine what type of hardware you need to run the deployment and how to configure it to fit your requirements.
Installing components
You use the Tivoli Netcool/Impact installer to install the Impact Server and the GUI Server. The installer is a program that can be run in GUI mode, console mode, and silent mode. In GUI mode a series of windows guide you through the installation process. In console mode, the installer prompts you to enter the required information from the command line. If you are running the installers remotely using telnet or another command line application, you must run the installer in console mode. For more information about running the installer, see Chapter 2, Installing Tivoli Netcool/Impact, on page 5
Configuring components
The installer program sets the minimum required configuration properties during installation. You can change the configuration of a component at any time by manually editing the properties files. Depending on the component, you might need to stop and restart after making configuration changes.
Chapter 1. Introduction
Running a deployment
You start and stop the Impact Server and the GUI Server by starting and stopping the Java application server where they reside, by default, the embedded version of WebSphere Application Server. Both servers are automatically loaded and started with the application server. You can also start and stop the Tivoli Netcool/Impact components separately from the application server using the management console tools provided by that application. You must start them in the following order: v Impact Server and GUI Server. For more information about starting these components, see Starting the embedded version of WebSphere Application Server on page 38. v JRExec server (optional). For more information about starting JRExec server, see Chapter 8, JRExec server, on page 65.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 2. Installing Tivoli Netcool/Impact

The Tivoli Netcool/Impact installer is an application that copies the program files to the target system and sets the minimum required configuration properties. The installer also installs the embedded version of WebSphere Application Server, the default Java application server used by Tivoli Netcool/Impact, on the target system. By default, the installer deploys the Impact Server and the GUI Server EAR files into the embedded version of WebSphere Application Server. The next time you start the application server, it automatically detects the EAR files and starts the components. Important: Native 31-bit Linux on System z is not supported because the application server that is installed by Tivoli Netcool/Impact 5.1.1 does not support native 31-bit Linux on System z. For a list of platforms supported on embedded version of WebSphere Application Server see: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27007274 Tivoli Netcool/Impact does support the 31-bit Linux on System z jvms in the 64-bit Linux on system z operating system.
System requirements
Software requirements
The following operating systems are compatible with IBM Tivoli Netcool/Impact version 5.1.1:
Operating System AIX
Version/Release 5.2, 5.3, 6.1 9, 10 (Zones are supported) 11i v2 Server 2003 Std x64, Server 2003 Enterprise x64, Server 2003 DataCenter x64 (no cluster support)
32 bit/64 bit 32 bit/64 bit 32 bit/64 bit 32 bit 64 bit
Solaris HP/UX Windows
Windows
32 bit/64 bit Server 2003 Enterprise, Server 2003 Standard, Server 2003 Datacenter (no cluster support), XP Professional, Server 2008 Enterprise, Server 2008 Standard, Server 2008 DataCenter (R2 and non R2) 9.2,10 4.0, 5.0 - IA32, x86-64, IA64, PPC64, PPC32, zSeries (31 bit, 64 bit) 32 bit/64 bit 32 bit/64 bit
Suse RedHat ES
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Hardware requirements
The following are the minimum hardware requirements for installing and running IBM Tivoli Netcool/Impact version 5.1.1:
System Windows 32 bit UNIX 32 bit Windows 64 bit UNIX 64 bit Linux for System z 64 bit Minimum requirements 3 GB RAM 2 GB Paging space 5 GB hard disk space free 3 GB RAM 2 GB Swap space 5 GB hard disk space free 4 GB RAM 2 GB Paging space 5 GB hard disk space free 4 GB RAM 2 GB Swap space 5 GB hard disk space free 4 GB RAM 2 GB Paging space 8 GB hard disk space free (you need to set IATEMPDIR to the location where your 8 GB hard disk drive space is located before starting your installation)
General Notes
v On all UNIX platforms, if the installer indicates that there is not enough hard disk drive space for the temporary directory then you will need to set IATEMPDIR to a location where you have 8 GB hard disk space free before starting your installation. v Impact 5.1.1 runtime needs a minimum of 2 GB of RAM dedicated on any platform
Running the installer in GUI mode

Before you begin
Make sure that there is sufficient space on the temp volume. The self extractor checks for free disk space 3 times the size of the installer on the volume where the temp directory is located. If there is not enough free space, the installer prompts you for an alternative location for the extraction. The value of the temp directory path is resolved based on the system environment variable, IATEMPDIR on UNIX platforms and TEMP on Windows platforms. Set this environment variable before running the installer to redirect the temporary directories of the installer to the location where there is sufficient disk space.
About this task

On UNIX platforms, you do not run the installer as the root user. You can run the installer as any other user that has read, write, and execute permissions to the target directory.On Windows platforms the userid used for the installation must have administrator permissions because Tivoli Netcool/Impact creates a Windows Service entry. 1. Copy the installation file to your local directory. 2. Depending on your operating system use one of the following methods to launch the installation:
| | | | | | | | | | | | | | |
(UNIX platforms) You can start the installation from any place in the file system by providing the full path to the installation file or you can navigate to the directory to which you have copied it. Use the following command syntax to launch the installation on UNIX:
setup<system><version>.bin
or
/<fullyQualifiedPathToInstallFile>/setup<system><version>.bin
where system is the name of the operating system and version is a 32 bit or 64 bit version of the operating system. Example of the command on a 32-bit version of Linux:
./setupLinux32.bin
(Windows platforms) Double click the installation file or use the command at the command prompt to run it. 3. Choose the installation language.
| | | | Select the language that will be used during the installation and click OK to continue. 4. Read the Introduction and continue with the installation.
| | | |
Click Next to continue. 5. Read and accept the license agreement.
| | | | | | |
Click Next to continue. 6. Choose between a new installation and an upgrade. The installation program checks the file system for previous Tivoli Netcool/Impact installations. When version 5.1 is detected you are asked if you want to update the instance of 5.1 to version 5.1.1. If you select to upgrade you are taken directly to the Pre-Installation Summary.
| | | | | | | | |
When no 5.1 version is auto detected you are asked if you want to run a new clean installation of version 5.1.1 or, if there is an undetected version 5.1, you can select to try an update of the undetected version 5.1. If you select to upgrade a current version 5.1 will take you to the Choose Install Folder stage of the installation, similarly to selecting to install a new instance of version 5.1.1. In the case of upgrade, however, the path will be validated for pointing to a valid instance of 5.1.
| |
7. Choose the installation directory.
| | | | | | | | | | | | | | | | | | |
If you are running a new installation you cannot install into a directory that has an instance of Tivoli Netcool/Impact nor into any directory left behind from an old installation. You can install the server into any directory to which you have write privileges (+755 rights on UNIX platforms). The default location on UNIX platforms is /opt/ibm/netcool but note that even if you have +755 (drwxr-xr-x) permissions to /opt the installer will not create ibm/netcool in it. To be able to use the default directory go to the /opt directory, create the ibm directory and give it permissions of 777 (drwxrwxrwx). After that the installer will be able to install into /opt/ibm/netcool directory. An alternative method, is to add the non-root user to run the installer to an appropriate group that allows them to create the default directory. Note: On UNIX platforms do not use special characters or spaces in the install path name. The default directory on Windows platforms is C:\Program Files\IBM\Netcool. Click Next to continue. 8. Choose install type.
10
| | | | | | | | | |
If you select the Default mode the installer proceeds directly to the Pre-Installation Summary and performs the installation with a default set of values. If you choose the Advanced mode you have an opportunity to customize the Tivoli Netcool/Impact environment and then have to go through a series of advanced configuration steps. Click Next to continue. 9. (Advanced) Select the components to be installed.
| | | |
By default, both the GUI Server and the Impact Server are installed. You can accept this selection or change it and install the GUI Server or the Impact Server alone.
11
| | | |
Click Next to continue. 10. (Advanced) Configure the embedded version of WebSphere Application Server ports.
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
You can accept the default values of the embedded version of WebSphere Application Server ports - 9080 for the HTTP port (GUI Server) and 9060 for the administrator port (administration console) or provide different values if for some reason you cannot use the default ones. You will use the ports that you provide here to access the Tivoli Netcool/Impact administration screen and the GUI Server after the installation. For more information about accessing the administration console and the GUI Server, see Verifying the deployment on page 27. Click Next to continue. 11. (Advanced) Configure the Name Server. The Name Server is a component that provides registration functionality for the GUI Server and the Impact Server. Applications that use the GUI Server register with the Name Server at startup. The GUI Server uses the information stored in the Name Server when brokering HTTP requests between users Web browsers and the applications. The Name Server is also used to store information used in server clustering. For more information about server clustering, see Chapter 5, Server clustering, on page 41. You can define multiple Name Server port pairs and then associate your current installation to multiple Name Servers. Each Name Server port that you provide will be tested to check if it is active. If the port is active you will be taken to the next step of the installation. If the port is not active you will see a message indicating that the port is not active but you will still be able to continue with the installation. For the installation to be successful, however, make sure that the Name Server, port pair as you have defined is available. Note: If you are defining a GUI Server then the current host name and port number must be in the list of Name Servers, if it is not in the list an error is displayed.
12
| | | | | | | | |
To add more than one Name Server select the Select to add more Name Servers check box, click the Next button and another Name Server, port pair that you have provided in the input fields will be verified and added to the list. When you are done click Next to go on to the next installation screen. If you selecti the Select to clear the list of Name Servers option the entire list is removed (deleted) and you can define a new list of Name Server. 12. (Advanced) Configure the Tivoli Netcool/Impact instance.
| | | |
Configure the instance of Impact Server that you are installing. If you are installing a member of a cluster provide the name of the instance and the cluster group to which you want it to belong.
13
| | | | | | | | |
The command-line manager service tool allows you to access the Impact Server from the command-line interface to start and stop services as well as configure their parameters. The default value of the command-line service port is 2000. For more information about the command-line service, see Using command line manager on page 94. The DB port is the port that you can use to access the Tivoli Netcool/Impact database and by default it is 5435. Click Next to continue. 13. (Advanced) Configure the Object Server.
| | | | | | | |
By default the installer uses the current host name of the Object Server host and its default port. You can keep the default values or use a different fully qualified host name of the host that will be used as the Object Server host. You can choose not to use a password as it is valid for an Object Server not to have a password. Click Next to continue. 14. (Advanced) Choose Version Control system.
14
| | | | | | | | | | | | | | | | | | | | | | | |
The version control manager uses Tivoli Netcool/Impact Subversion (SVN) as the default version control which is installed automatically with the Impact Server if you leave the default selection. No additional configuration steps will be required if you decide to go with the default setting and immediately after the installation you will be able to save policies, data sources, data types, and configuration properties as revisions in a source control archive. Choose another option if you want to use a different version control system. Be prepared to provide additional configuration information in the steps to follow. Click Next to continue. 15. (Advanced/Optional) Set the Version Control path. You have to go through this installation step if the Impact Server or both the Impact Server and the GUI Server are selected together from the components to be installed and Subversion, or CVS, or RCS or ClearCase is selected in the version Choose Version Control System step. Click Next to continue. 16. (Advanced/Optional) Set Version Control Repository You have to go through this installation step if the Impact Server or both the Impact Server and the GUI Server are selected together from the components to be installed and Subversion or CVS is selected in the Version Control System step. Click Next to continue. 17. Pre-Installation summary.
15
| | | | |
Make sure that the installation parameters in the pre-installation summary reflect your choices and proceed with the installation. 18. Finish the installation.
| | | | |
Click Done to leave the installation.
What to do next
Perform the following additional configuration steps that are applicable to your installation profile:
16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
v Review the installation logs, especially the logs found in the <installDir>/log directory, to verify that the software has been installed correctly, or to troubleshoot installation errors. For more information, see Installation logs on page 28. v Log on to Netcool/Impact components to verify if they have been successfully installed. For more information about verifying the deployment, see Verifying the deployment on page 27. v If you were installing an Impact Server to be a part of a server cluster follow the steps in Chapter 5, Server clustering, on page 41. v If you want to use SSL for communication with the GUI Server follow the steps in Setting up SSL communication in Tivoli Netcool/Impact on page 83. v (Windows platforms) Install the JRExec server. For more information about installing the JRExec server, see Installing the JRExec server (Windows platforms) on page 28. v If you upgraded from version 5.1 in which you used internal CVS as your version control, run the nci_cvs2svn script. For more information about the script, see Migrating to Subversion on page 59.
Running the installer in console mode

Before you begin
Make sure that there is sufficient space on the temp volume. The self extractor checks for free disk space 3 times the size of the installer on the volume where the temp directory is located. If there is not enough free space, the installer prompts you for an alternative location for the extraction. The value of the temp directory path is resolved based on the system environment variable, IATEMPDIR on UNIX platforms and TEMP on Windows platforms. Set this environment variable before running the installer to redirect the temporary directories of the installer to the location where there is sufficient disk space.
About this task

If you are installing Netcool/Impact remotely using telnet or another command-line application, you must run the installer in console mode. On UNIX platforms, you do not run the installer as the root user. You can run the installer as any other user that has read, write, and execute permissions to the target directory.On Windows platforms the userid used for the installation must have administrator permissions because Tivoli Netcool/Impact creates a Windows Service entry. 1. Copy the installation file to your local directory. 2. Depending on your operating system use one of the following methods to launch the installation: (UNIX platforms) You can start the installation from any place in the file system by providing the full path to the installation file or you can navigate to the directory to which you have copied it. Use the following command syntax to launch the installation on UNIX:
setup<system><version>.bin -i console
or
/<fullyQualifiedPathToInstallFile>/setup<system><version>.bin -i console
17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
./setupLinux32.bin -i console
(Windows platforms) Use the following syntax to start the installation:

<fullyQualifiedPathToInstallFile>/setupwin<version>.exe -i console
where version is a 32 bit or 64 bit version of Windows. Example of the command on a 32 bit version of Windows:
setupwin32.exe -i console
3. Choose the installation language.

=============================================================================== Choose Locale... ---------------1->23456Deutsch English Espaol Franais Italiano Portugus
(Brasil)
CHOOSE LOCALE BY NUMBER:
Select the language that to be used during the installation and press Enter to continue. 4. Read the Introduction and continue with the installation.
=============================================================================== Introduction -----------Welcome to the InstallAnywhere Wizard for Netcool/Impact The InstallAnywhere wizard wil install Netcool/Impact on your computer. To continue, press ENTER. Netcool/Impact IBM http://www.ibm.com PRESS <ENTER> TO CONTINUE:
Press Enter to continue. 5. Read and accept the license agreement.

Press Enter to continue viewing the license agreement, or enter "1" to accept the agreement, "2" to decline it, "3" to print it, or "99" to go back to the previous screen.:
Accept the license agreement by selecting option 1 and press Enter to continue. 6. Choose between a new installation and an upgrade. The installation program checks the file system for previous Tivoli Netcool/Impact installations. When version 5.1 is detected you are asked if you want to update the instance of 5.1 to version 5.1.1. If you select to upgrade you are taken directly to the Pre-Installation Summary. When no 5.1 version is auto detected you are asked if you want to run a new clean installation of version 5.1.1 or, if there is an undetected version 5.1, you can select to try an update of the undetected version 5.1. If you select to upgrade a current version 5.1 will take you to the Choose Install Folder stage
18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
of the installation, similarly to selecting to install a new instance of version 5.1.1. In the case of upgrade, however, the path will be validated for pointing to a valid instance of 5.1. 7. Choose the installation directory.
=============================================================================== Choose Install Folder --------------------Press ENTER to install "Netcool/Impact" to this directory, or type in an absolute path of a directory you want to install to a different directory. ENTER AN ABSOLUTE PATH, OR PRESS <ENTER> TO ACCEPT THE DEFAULT. (DEFAULT: /opt/ibm/netcool):
If you are running a new installation you cannot install into a directory that has an instance of Tivoli Netcool/Impact nor into any directory left behind from an old installation. You can install the server into any directory to which you have write privileges (+755 rights on UNIX platforms). The default location on UNIX platforms is /opt/ibm/netcool but note that even if you have +755 (drwxr-xr-x) permissions to /opt the installer will not create ibm/netcool in it. To be able to use the default directory go to the /opt directory, create the ibm directory and give it permissions of 777 (drwxrwxrwx). After that the installer will be able to install into /opt/ibm/netcool directory. An alternative method, is to add the non-root user to run the installer to an appropriate group that allows them to create the default directory. Note: On UNIX platforms do not use special characters or spaces in the install path name. The default directory on Windows platforms is C:\Program Files\IBM\Netcool. Press Enter to use the default installation directory and continue or enter another directory where you want to install Netcool/Impact and then hit Enter. 8. Choose install type.
=============================================================================== Choose the installation type that best suits your needs. -------------------------------------------------------Default install will install Netcool/Impact and all pre-requisite software onto this machine using default values. NOT RECOMMENDED FOR PRODUCTION ENVIRONMENTS. Advanced install is recommended for Production environments. Allows choice of what pre-requisite software to install as well as the oprion to change default values. ->1- Default 2- Advanced ENTER THE NUMBER FOR YOUR CHOICE, OR PRESS <ENTER> TO ACCEPT THE DEFAULT:
If you select the Default mode the installer proceeds directly to the Pre-Installation Summary and performs the installation with a default set of values. If you choose the Advanced mode you have an opportunity to customize the Tivoli Netcool/Impact environment and then have to go through a series of advanced configuration steps. 9. (Advanced) Select the components to be installed.
19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
=============================================================================== Choose Impact Server Type ------------------------Select the feature for "Netcool/Impact" you would like to install: ->1- GUI Server ->2- Impact Server ENTER A COMMA-SEPARATED LIST OF NUMBERS REPRESENTING THE DESIRED CHOICES, OR PRESS <ENTER> TO ACCEPT THE DEFAULT:
By default, both the GUI Server and the Impact Server are installed. You can accept this selection or change it and install the GUI Server or the Impact Server alone. 10. (Advanced) Configure the embedded version of WebSphere Application Server ports.
=============================================================================== Specify Embedded IBM Websphere HTTP/Admin Ports ----------------------------------------------Netcool/Impact will install a fully functional Embedded version of the IBM Webshpere Application Server. HTTP Port (DEFAULT: 9080): Admin Port (DEFAULT: 9060):
You can accept the default values of the embedded version of WebSphere Application Server ports - 9080 for the HTTP port (GUI Server) and 9060 for the administrator port (administration console) or provide different values if for some reason you cannot use the default ones. Enter the ports values and press Enter to continue. 11. (Advanced) Configure the Name Server. The Name Server is a component that provides registration functionality for the GUI Server and the Impact Server. Applications that use the GUI Server register with the Name Server at startup. The GUI Server uses the information stored in the Name Server when brokering HTTP requests between users Web browsers and the applications. The Name Server is also used to store information used in server clustering. For more information about server clustering, see Chapter 5, Server clustering, on page 41. You can define multiple Name Server port pairs and then associate your current installation to multiple Name Servers. Each Name Server port that you provide will be tested to check if it is active. If the port is active you will be taken to the next step of the installation. If the port is not active you will see a message indicating that the port is not active but you will still be able to continue with the installation. For the installation to be successful, however, make sure that the Name Server, port pair as you have defined is available. Note: If you are defining a GUI Server then the current host name and port number must be in the list of Name Servers, if it is not in the list an error is displayed.
============================================================================== Name Server Configuration ------------------------Impact uses the Netcool Name Server to publish its services. By default the application name server is installed as part ot the Netcool ImpactClient. If yo moved the "nameserver.war" file to a different J2EE server, please enter the correct http host and port below, otherwise use the host and port of your Netcool Impact Server.
20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Name Server Host (DEFAULT: somenameserver): Name Server Port (DEFAULT: 9080): Would you like to define another Name Server and port pair? (Y/N)
To add more than one Name Server select Y(YES) and press Enter and another Name Server, port pair that you have specified is verified and added to the list. When you are done type N (NO) for a summary of the Name Server and port pairs. If you are not happy with the list of Name Servers type back to go back to the Name Server dialog again, if you are happy type Y (YES) to go on to the next installation screen. If you back up to the step before Configure the Name Server and reenter the dialog, the previous list of Name Servers is cleared and you need to define a new list of Name Servers. 12. (Advanced) Configure the Tivoli Netcool/Impact instance.
=============================================================================== Configure Impact Instance ------------------------Netcool/Impact allows you to run multiple instances of the server with different configuration characteristics.The instance name is a unique string that identifies the server instance.The cluster group is used to identify server instances that form a cluster.If you do not want to run in clustering mode, just assign a unique name to every server instance. Instance Name (DEFAULT: NCI): Cluster Group (DEFAULT: NCICLUSTER): Command Line Port (DEFAULT: 2000): DB Port (DEFAULT: 5435):
Configure the instance of Impact Server that you are installing. If you are installing a member of a cluster provide the name of the instance and the cluster group to which you want it to belong. The command-line manager service tool allows you to access the Impact Server from the command-line interface to start and stop services as well as configure their parameters. The default value of the command-line service port is 2000. For more information about the command-line service, see Using command line manager on page 94. The DB port is the port that you can use to access the Tivoli Netcool/Impact database and by default it is 5435. Enter all the required information and press Enter to continue. 13. (Advanced) Configure the Object Server.
=============================================================================== Configure ObjectServer ---------------------Netcool/Impact will need an event source. By default, it will connect to Netcool/OMNIbus.Other types of event sources require manual configuration.Please enter the host and port for your Netcool/OMNIbus server. ObjectServer Host (DEFAULT: xxxx.ie.ibm.com): ObjectServer Port (DEFAULT: 4100): 4100 ObjectServer Password:*
By default the installer uses the current host name of the Object Server host and its default port. You can keep the default values or use a different fully qualified host name of the host that will be used as the Object Server host.
21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
You can choose not to use a password as it is valid for an Object Server not to have a password. Enter all the required information and press Enter to continue. 14. (Advanced) Choose Version Control system.
=============================================================================== Choose Version Control System ----------------------------Netcool/Impact uses version control for its configuration files (property files, data types and policies).You can use an existing version control system or the Subversion (SVN) package bundled with Netcool/Impact. ->12345Impact Subversion Subversion CVS RCS Clearcase
ENTER THE NUMBER FOR YOUR CHOICE, OR PRESS <ENTER> TO ACCEPT THE DEFAULT:
The version control manager uses Tivoli Netcool/Impact Subversion (SVN) as the default version control which is installed automatically with the Impact Server if you leave the default selection. No additional configuration steps will be required if you decide to go with the default setting and immediately after the installation you will be able to save policies, data sources, data types, and configuration properties as revisions in a source control archive. Choose another option if you want to use a different version control system. Be prepared to provide additional configuration information in the steps to follow. 15. (Advanced/Optional) Set the Version Control path. You have to go through this installation step if the Impact Server or both the Impact Server and the GUI Server are selected together from the components to be installed and Subversion, or CVS, or RCS or ClearCase is selected in the version Choose Version Control System step. 16. (Advanced/Optional) Set Version Control Repository You have to go through this installation step if the Impact Server or both the Impact Server and the GUI Server are selected together from the components to be installed and Subversion or CVS is selected in the Version Control System step. 17. Pre-Installation summary.
=============================================================================== Pre-Installation Summary -----------------------Please Review the Following Before Continuing: Product Name: Netcool/Impact Install Folder: /home/netcool_impact/opt/ibm/netcool Install Set: Advanced Disk Space Information (for Installation Target):
22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Required: 682,862,708 bytes Available: 60,439,982,080 bytes PRESS <ENTER> TO CONTINUE:
Make sure that the installation parameters in the pre-installation summary reflect your choices and proceed with the installation. 18. Finish the installation.
=============================================================================== Install Complete ---------------Congratulations. The product has been successfully installed. Product name: Netcool/Impact /home/netcool_impact/opt/ibm/netcool Press "ENTER" to exit the wizard. PRESS <ENTER> TO EXIT THE INSTALLER:
Press Enter to leave the installation.
What to do next
Perform the following additional configuration steps that are applicable to your installation profile: v Review the installation logs, especially the logs found in the <installDir>/log directory, to verify that the software has been installed correctly, or to troubleshoot installation errors. For more information, see Installation logs on page 28. v Log on to Netcool/Impact components to verify if they have been successfully installed. For more information about verifying the deployment, see Verifying the deployment on page 27. v If you were installing an Impact Server to be a part of a server cluster follow the steps in Chapter 5, Server clustering, on page 41. v If you want to use SSL for communication with the GUI Server follow the steps in Setting up SSL communication in Tivoli Netcool/Impact on page 83. v (Windows platforms) Install the JRExec server. For more information about installing the JRExec server, see Installing the JRExec server (Windows platforms) on page 28. v If you upgraded from version 5.1 in which you used internal CVS as your version control, run the nci_cvs2svn script. For more information about the script, see Migrating to Subversion on page 59.
Running the installer in silent mode

Before you begin
Before running the installer in silent mode you need to edit the response file. A template of the response file, installSilent_Response.txt, is provided with the installation file and you can edit it with your favorite text editor. For a list of installation options that you can customize in the response file see Silent installation response file on page 25. The following rules apply to the response file:
23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
v The path to the installer properties file can be either absolute, or relative to the directory in which the installer resides. v Use the response file, installSilent_response.txt, shipped with the installer. You can change the name of the file. v If an installer properties file is specified but does not exist, the default properties file, if present, is used. Otherwise, any supplied command-line options are used, or if no additional options are specified, the installer is run using the default settings. Make sure that there is sufficient space on the temp volume. The self extractor checks for free disk space 3 times the size of the installer on the volume where the temp directory is located. If there is not enough free space, the installer prompts you for an alternative location for the extraction. The value of the temp directory path is resolved based on the system environment variable, IATEMPDIR on UNIX platforms and TEMP on Windows platforms. Set this environment variable before running the installer to redirect the temporary directories of the installer to the location where there is sufficient disk space.
About this task

On UNIX platforms, you do not run the installer as the root user. You can run the installer as any other user that has read, write, and execute permissions to the target directory.On Windows platforms the userid used for the installation must have administrator permissions because Tivoli Netcool/Impact creates a Windows Service entry. 1. Copy the installation file to your local directory. Also copy the response file to a directory on your file system. 2. Depending on your operating system use one of the following methods to launch the installation: (UNIX platforms) You can start the installation from any place in the file system by providing the full path to the installation file or you can navigate to the directory to which you have copied it. Use the following command syntax to launch the installation on UNIX:
setup<system><version>.bin -i silent -f <pathToInstallerPropertiesFile>
or
/<fullyQualifiedPathToInstallFile>/setup<system><version>.bin -i silent -f <pathToInstallerPropertiesFile>
./setupLinux32.bin -i silent -f installer.properties
(Windows platforms) Use the following syntax to start the installation:

<fullyQualifiedPathToInstallFile>/setupwin<version>.exe -i silent -f <pathToInstallerPropertiesFile>
where version is a 32 bit or 64 bit version of Windows. Example of the command on a 32 bit version of Windows:
setupwin32.exe -i silent -f installer.properties
3. (Optional) Follow the installation progress by viewing the installation log. While the installation is running you can follow its progress by viewing the IMPACT5.1.1_install-xx.log.lck file (where xx can be 00 or 01 or 02) and is located in your home directory. When this lock file disappears (is removed at end of the installation) the silent installation is complete.
24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
4. Finish the installation.
What to do next
Perform the following additional configuration steps that are applicable to your installation profile: v Review the installation logs, especially the logs found in the <installDir>/log directory, to verify that the software has been installed correctly, or to troubleshoot installation errors. For more information, see Installation logs on page 28. v Log on to Netcool/Impact components to verify if they have been successfully installed. For more information about verifying the deployment, see Verifying the deployment on page 27. v If you were installing an Impact Server to be a part of a server cluster follow the steps in Chapter 5, Server clustering, on page 41. v If you want to use SSL for communication with the GUI Server follow the steps in Setting up SSL communication in Tivoli Netcool/Impact on page 83. v (Windows platforms) Install the JRExec server. For more information about installing the JRExec server, see Installing the JRExec server (Windows platforms) on page 28. v If you upgraded from version 5.1 in which you used internal CVS as your version control, run the nci_cvs2svn script. For more information about the script, see Migrating to Subversion on page 59.
Silent installation response file

The following table contains the installation parameters that you can customize in the installation response file template, installSilent_Response.txt.
Table 1. Silent installation properties Parameter USER_INSTALL_DIR Description Installation directory. Directory on the system where you install Netcool products. Default is /opt/ibm/netcool on UNIX platforms and C:\Program Files\IBM\Netcool on Windows. Installation type. Default value is default, alternative is advanced. Install GUI Server. Choose 1 to install, default is 1. Install Impact Server. Choose 1 to install, default is 1. Used to set eWAS server initial jvm heap size. The default value is 1200 (1.2 gig initial heap size). For those customers who are installing on machines that can not support 1.2 gig jvm heap use this parameter to reduce the amount of eWAS server initial jvm heap size, a good value to use would be EWAS_HEAP_SIZE=512. HTTP port used by the application server. When you log in to Tivoli Netcool/Impact using a Web browser, you use this HTTP port. Default is 9080. Administration port. The default is 9060.
CHOSEN_INSTALL_SET GUI_SERVER_RESULT IMPACT_SERVER_RESULT EWAS_HEAP_SIZE
EWAS_HTTP_PORT
EWAS_ADMIN_PORT
25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 1. Silent installation properties (continued) Parameter NAMESERVER_HP Description Host name or IP address of the system where the Name Server is running followed by the port where the Name Server is running, separated by a colon. There are no default values for the host name and port, they must be fully qualified. You must provide this information when: GUI_SERVER_RESULT=0 IMPACT_SERVER_RESULT=1 You can specify multiple Name Servers in which case you need to separate them with a comma: NAMESERVER_HP=<HOST_NAME>:<portNumber>, <HOST_NAME>:<portNumber> <HOST_NAME> is the Name Server host name that has no default value, and must be fully qualified and <portNumber> is the port number of the Name Server (no default value either). NCI_INSTANCE_NAME NCI_CLUSTER_NAME Name of the new instance. The default is NCI. Cluster group. Name of the server cluster for the new instance. If you are not using server clustering, accept the default. Otherwise, enter the name of the cluster that the instance will participate in. The default is NCICLUSTER. Command line port. Port used by the command line service for the new instance. The default is 2000. Netcool database port. Port used by the Netcool Database Server. The default is 5435. Host name or IP address for the primary Object Server in your environment. Default, localhost. Port used by the Object Server. The default is 4100. Name of the user account that is used to connect as an Object Server client. The default is root. Password for the Object Server user. The default is blank. Specifies which version control system to use. Default is Tivoli Netcool/Impact Subversion, which is installed automatically with the product. Choose true for your selection, leave false for the rest.
NCI_CMD_LINE_PORT NCI_DB_PORT OBJECTSERV_HOST_NAME OBJECTSERV_PORT OBJECTSERV_USER OBJECTSERV_PASSWORD NCI_VCS_IMPACTSVN NCI_VCS_SYSTEMSVN NCI_VCS_SYSTEMCVS NCI_VCS_RCS NCI_VCS_CLEARCASE
26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 1. Silent installation properties (continued) Parameter UPGRADE_IMPACT_51 Description You set this parameter only if you are running an upgrade. Old Netcool/Impact 5.1 version found upgrade it to new Impact 5.1.1 version. There is a test that is run at the beginning of the installer startup to determine if an old Impact 5.1 version exists on this machine. If an old Impact 5.1 is found the customer has the option to upgrade that version of Impact to the 5.1.1 version. To upgrade the customer sets the UPGRADE_IMPACT_51 parameter to 1. This will then upgrade the Impact 5.1 to Impact 5.1.1. Default is to upgrade Impact 5.1. v 1 - to upgrade the existing 5.1 installation. It is the default setting. v 0 - not to upgrade the existing 5.1 installation Note: If an Impact 5.1 is not found on the current machine the parameter UPGRADE_IMPACT_51 is ignored. UPDATE_REGULAR_INSTALL_TYPE You set this parameter only if you are running an upgrade. Old Netcool/Impact 5.1 version not found. You have an old Netcool/Impact 5.1 but the autodetect did not find it in the ISMP registry. YOu can still upgrade the Netcool/Impact 5.1 installation by coding UPDATE_REGULAR_INSTALL_TYPE=UPDATE and setting the parameter USER_INSTALL_DIR to point to the old Netcool/Impact 5.1 directory. If the Netcool/Impact 5.1 was autodetected this parameter is ignored. You can set one of these values: v REGULAR - to run a clean new installation. It is the default setting. v UPDATE - to run an update from version 5.1 to 5.1.1 VERCTLPATH VERCTL_REPOSITORY Version control path. Default value / Version control repository. Default value /
Verifying the deployment

v Look into the netcool.log file to make sure that the Impact Server started successfully. v Log on to the GUI and see if you can use view and manage services, data models, and policies. 1. Open the following URL in a Web browser:
http://hostname:port/nci
where hostname is the name of the system where the embedded version of WebSphere Application Server is running and port is the HTTP port. The default port is 9080. 2. Enter the administration user name and password in the login page that opens. The default administration user name is admin and the default password is netcool.
27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
If you have deployed the components correctly, you can use the GUI to view and manage services, data models, and policies as described in the User Interface Guide.
Installation logs
Review the following logs to make sure that the installation was successful: IMPACT5.1.1_install-xx.log.lck xx can be 00 or 01 or 02. This log is created while the installation is running the. When this lock file disappears (is removed at the end of the installation) the installation is complete. IMPACT5.1.1_install-xx.log xx can be 00 or 01 or 02. The installer puts this log in the user home directory. This log file contains messages generated during the installation process. You can also use it to troubleshoot installation problems. $NCHOME/log For additional debugging information review the logs found in this directory. These logs will help to troubleshoot installation problems.
Installing the JRExec server (Windows platforms)

The JRExec server is a component used to run external commands, scripts, and applications from within a policy. The JRExec server is automatically installed on the system when you install Tivoli Netcool/Impact. On Windows systems, you must also manually create the JRExec service after installation. To create the JRExec service, enter the following command at a command prompt:
%NCHOME%/impact/bin/nci_jrexec -i nci_jrexec.conf
Setting up JDBC for GenericSQL DSA

The GenericSQL DSA is a built-in component that enables access to information in any database application through a JDBC driver.
About this task

If you need to use the GenericSQL DSA, install a JDBC driver and specify the directories for this driver in the Impact Server properties file. Note: This is only required for GenericSQL DSA and not for other SQL DSAs. For more information about GenericSQL and other DSAs, see the DSA Reference Guide. 1. To install the necessary JDBC driver, follow the instructions supplied with the driver. 2. To specify the directories where the driver was installed, edit the Impact Server properties file. This file is named servername_server.props, where servername is the name of the Impact Server. The file is located in the $NCHOME/impact/etc directory. You must set the impact.server.jdbcDriverDirs property. v On Windows systems, use / or \\ as the path separator and a semicolon (;) between directories:
impact.server.jdbcDriverDirs=C:\\Program Files\\JDBC;C:\\Program Files\\JDBC\\NewSQL
28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
v On UNIX systems, use as the path separator and a colon (:) between directories:
impact.server.jdbcDriverDirs=/opt/ibm/netcool/dir1:/opt/ibm/netcool/dir2
Running a deployment
You start and stop the Impact Server and the GUI Server by starting and stopping the Java application server where they reside, by default, the embedded version of WebSphere Application Server. Both servers are automatically loaded and started with the application server. You can also start and stop the Tivoli Netcool/Impact components separately from the application server using the management console tools provided by that application. You must start them in the following order: v Impact Server and GUI Server. For more information about starting these components, see Starting the embedded version of WebSphere Application Server on page 38. v JRExec server (optional). For more information about starting JRExec server, see Chapter 8, JRExec server, on page 65.
Uninstalling Tivoli Netcool/Impact

You can uninstall both Tivoli Netcool/Impact components, the Impact Server, and the GUI Server using the same system tools. On UNIX platforms, you run the uninstaller script, uninstall which is located in the $NCHOME/_uninst directory. On Windows platforms, you use the Add/Remove Programs tool.
Uninstalling Tivoli Netcool/Impact components on Windows platforms

On Windows platforms, you uninstall Tivoli Netcool/Impact components, the Impact Server or the GUI Server, using the Add/Remove Programs tool. 1. In the Start menu, select Control Panel Add/Remove Programs. 2. In the dialog box that opens, select Netcool/Impact and then select Change/Remove. 3. Follow the on-screen prompts to remove the software. 4. Remove the directories where Tivoli Netcool/Impact components were installed. Use Windows Explorer or the rmdir command at the command prompt.
Uninstalling Tivoli Netcool/Impact components on UNIX platforms

On UNIX platforms, you uninstall Tivoli Netcool/Impact components, the Impact Server or the GUI Server, by running the uninstaller script, uninstall which is located in the $NCHOME/_uninst directory. You can run the uninstaller in GUI mode or in console mode. In GUI mode, it presents a series of graphical windows that guide you through the uninstallation process. In console mode, it prompts you for
29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
required information from the command line. If you are running the uninstaller remotely, using telnet or another command-line application, you must run it in console mode. 1. At a command prompt, change the current directory to $NCHOME/_uninst. 2. Run the uninstaller script. v To run the uninstaller in GUI mode:
./uninstall
v To run the uninstaller in console mode:

./uninstall -console
3. Follow the on-screen prompts to remove the software. 4. Remove the directories where Tivoli Netcool/Impact was installed. Use the rm -r command.
Post installation utility

About this task
The post installation utility, nci_new_server (nci_new_server.exe on Windows platforms) is located in the $NCHOME/impact/install directory. You use the post installation utility to: v v v v Create a new instance of Impact Server. Update the Name Server names for the GUI Server and Impact Servers. Add a new Impact Server to a GUI Server only installation. Reconfigure a currently installed Name Server.
The steps to follow after running the post installation utility are similar to those in the new installation procedure. For more information about the new installation, seeChapter 2, Installing Tivoli Netcool/Impact, on page 5. v Running post install utility in GUI mode. Navigate to the directory that contains the script and run the following command: ./nci_new_server (on UNIX platforms) nci_new_server.exe (on Windows platforms) Select the components that you want to install or configure by following the instructions that are displayed on the screen. v Running post installation utility in the command line. Navigate to the directory that contains the script and run the following command: ./nci_new_server -i console (on UNIX platforms) nci_new_server.exe -i console (on Windows platforms) Select the components that you want to install or configure by following the instructions that are displayed on the screen. v Running post installation utility in silent mode. Before running the post installation utility in silent mode you need to edit the response file. A template of the response file, installSilent_Response.txt, is provided with the installation file and you can edit it with your favorite text editor. For a list of installation options that you can customize in the response file see Silent installation response file on page 25.
30
| | | | | | | |
Navigate to the directory that contains the script and run the following command: ./nci_new_server -i silent f <fullyqualifiedpathtoSilentResponsefile>/ installNewImpactSilent_response.txt (on UNIX platforms) nci_new_server.exe -i silent f <fullyqualifiedpathtoSilentResponsefile>/ installNewImpactSilent_response.txt (on Windows platforms)
31
32
Chapter 3. Managing the Impact Server

The Impact Server contains of a set of subcomponents, called services, that provide the core functionality of the product. The server also provides the means for creating and managing the data model, and for creating and managing the policies.
Overview of the Impact Server

The Impact Server runs as an application instance inside a Java application server. The default application server is the embedded version of WebSphere Application Server, that is installed automatically when you install the Impact Server and the GUI Server components. The best practice is to run a single server instance per system as there is no benefit to running multiple instances on a single system in a production environment. However, it is also possible to run multiple instances for testing and validation purposes. The Impact Server starts and stops automatically when you start or stop the Java application server where it resides but you can also start and stop the component independently of the application server. For more information about starting and stopping the server, see Running Impact Server instances on page 34. In addition to the Impact Server instance that is automatically created during the installation, you can create additional instances of the server after the installation. You can also change its configuration at any time by manually editing the server properties file. For more information, see Creating Impact Server instances. A clustered server configuration is supported in addition to a single server configuration. A clustered server configuration consists of multiple instances of the Impact Server installed on separate systems but configured in such a way that they act as a single server. This type of configurations provides failover, replication, and load balancing functions. For more information about the clustered server configuration, see Chapter 5, Server clustering, on page 41. A centralized logging feature is provided that is used by both the Impact Server and the GUI Server. For more information about monitoring the servers, see Monitoring deployment components on page 35.
Creating Impact Server instances

The Tivoli Netcool/Impact installer automatically creates and deploys an instance of the Impact Server during installation. You can create additional instances of the server using the post installation utility. The post installation utility, nci_new_server (nci_new_server.exe on Windows platforms) is located in the $NCHOME/impact/install directory. Note: You must create a new server under the same user account that you used to install the first instance of the Impact Server. The post installation utility creates an EAR file for the Impact Server and deploys it into the Java application server where Tivoli Netcool/Impact components reside.
33
The application server automatically detects the new EAR file after deployment and starts the instance of the Impact Server. A set of properties files and other supporting files are also created that define the behavior of the server instance. These files are located in $NCHOME/impact/etc. Files related to the server instance have the prefix server_ where server is the name of the Impact Server. For example, NCI_server is the name of the server properties file for the instance named NCI. For more information about running the post installation utility, see Post installation utility on page 30.
Running Impact Server instances

Tivoli Netcool/Impact components start and stop automatically when you start and stop the embedded version of WebSphere Application Server, which is the default Java application server that is installed with Tivoli Netcool/Impact. For more information about starting and stopping the embedded version of WebSphere Application Server, see Starting the embedded version of WebSphere Application Server on page 38 and Stopping the embedded version of WebSphere Application Server on page 37. If required, however, you can also start and stop the components independent of the application server, using the server administration scripts. For more information about using the Impact Server administration scripts, see Using Impact Server administration scripts.
Using Impact Server administration scripts

You can start and stop the Impact Server independent of the embedded version of WebSphere Application Server using two server administration scripts. The scripts, nci_server and nci_shutdown, are located in the $NCHOME/impact/bin directory.
Before you begin

The embedded version of WebSphere Application Server must be running in order for you to start and stop the components. v To start a server instance, enter the following command at a command prompt:
$NCHOME/impact/bin/nci_server server
where server is the name of the Impact Server instance. v To stop a server instance, enter the following command at a command prompt:
$NCHOME/impact/bin/nci_shutdown server
where server is the name of the Impact Server instance.
Configuring RMI ports

The Impact Server opens a number of ports on a machine for Java Remote Method Invocation (RMI) operations. There are a few exposed properties that allow you to control which ports are used. By default, a random port is opened on the host system that is used by the RMI registry.
34
You can control RMI ports where a firewall exists on a network and the exact control of which ports should be opened is necessary. The properties must be specified in the servername_server.props file located in the $NCHOME/impact/etc directory. In order to control which ports are used by Impact when exporting RMI objects, you need to provide values for the following properties: impact.server.rmiport This property specifies the port that Impact uses when starting its RMI registry. impact.rmiPortRangeStart This property specifies the minimum value of the port number that Impact uses for its RMI registry. impact.rmiPortRangeEnd This property specifies the maximum value of the port number that Impact uses for its RMI registry. These values should span a range of approximately 100 ports on your machine and they force Impact to open the ports in this range only. Once specified, Impact uses this range of ports when exporting RMI objects.
Monitoring deployment components

Tivoli Netcool/Impact provides a centralized logging feature that incorporates Apache Log4j logging functionality.
Monitoring server instances

You can monitor and log the status and activity of both the Impact Server and the GUI Server. The server log contains status, debugging, and error messages generated during runtime. The log file, netcool.log, is located in the $NCHOME/log directory. When the log file reaches 10 MB in size the contents of the log are copied to a backup file and a new, empty copy of the file is created. Backup log files are named netcool.log.n, where n is an index number that identifies the file. When the maximum number of backup files is reached (by default, three) the oldest file (for example, netcool.log.3) is deleted and the other two files are renamed so that the oldest copy always has the largest index number of all of the files. You can customize the logging properties by modifying the contents of the Log4j properties file, log4j.properties, that is located in the $NCHOME/eWAS/properties directory. For a list of properties that you can customize in the Log4j properties file, see Log4j properties file.
Log4j properties file

This is a list of the properties that you can modify in the log4j.properties file to change the default logging behavior.
35
Property log4j.appender.NETCOOL. threshold
Default Value DEBUG
Description Specifies that the deployment components must log all messages with a severity of DEBUG or higher. Specifies the path and filename of the Tivoli Netcool/Impact log file. Specifies whether to append to an existing log file at startup. Specifies the maximum number of backup files. Specifies the maximum size of log files.
log4j.appender.NETCOOL. file log4j.appender.NETCOOL. append log4j.appender.NETCOOL. maxBackupIndex log4j.appender.NETCOOL. maxFileSize
$NCHOME/log/netcool.log
true
3 10MB
For even more information about the properties in the log4j.properties file, see the documentation on the Log4j Web site: http://logging.apache.org/log4j.
Monitoring services
Services running in the Impact Server, for example, event readers and the policy logger, can also print their activity and status messages to a log file. You set the maximum number of backup files that can be created by services in the server properties file. The servername_server.props properties file, where servername is the name of the Netcool/Impact server, is located in the $NCHOME/impact/etc directory. To set the maximum number of log files, modify the value of the following property:
impact.server.logging.maxlogfiles=n
where n is the maximum number of log files for each service. The default is 10. The maximum file size for a service log file is 10 MB. You can override this value on a per service basis by specifying the impact.servicename.maxbackupindex property in the individual servicename.props files to set this value for each service.
What to do next
Refer to the User Interface Guide for more information about configuring logging for single services.
Deleting Impact Server instances

The remove server script removes the Impact Server instance from the Tivoli Netcool/Impact installation. The script, nci_removeserver, is located in the $NCHOME/impact/bin directory. 1. Run the remove server script by entering the following command at a command prompt:
36
$NCHOME/impact/bin/nci_removeserver server_name
where server_name is the instance of the server you want to remove. The script checks to see if the server instance is running before removing it from the installation. If the instance is running, the script automatically shuts it down before continuing with operations. 2. (Optional) Run the remove SVN archives script. By default, the remove server script does not delete information about policies, data sources, data types, and services from the version control system. If you are using SVN as your version control system, you can run the remove SVN archives script to completely remove all archives related to a server instance. The remove SVN archives script is named nci_svn_remove and is located in the $NCHOME/impact/bin directory. To run the remove SVN archives script, enter the following command at a command prompt:
$NCHOME/impact/bin/nci_svn_remove server_name
where server_name is the name of the deleted server instance.
Enabling read-only mode

You use read-only mode in production environment to ensure that no changes can be made to the Tivoli Netcool/Impact configuration in real time. In read-only write access to a Impact Server is blocked and users cannot make any changes to data sources, data types, policies, or services. In read-only mode, the server can read, write, update, and delete data stored in data items, including those stored in internal data types. Read-only mode does not interfere with the operation of policies and services during server runtime. Read-only mode only prevents changes to the Tivoli Netcool/Impact configuration. In addition, read-only mode does not affect the ability to change or use operator views.
About this task

You set read-only mode by manually editing the version control properties file. This file is named servername_versioncontrol.props and is located in the $NCHOME/impact/etc directory, where servername is the name of the Impact Server. Follow this procedure to enable read-only mode: 1. Edit the impact.versioncontrol.readonlymode property as follows
impact.versioncontrol.readonlymode=true
2. Restart the Impact Server for the change to take effect.
Results
After you enable read-only mode, users are notified that data sources, data types, policies, and services are locked to a user named read-only when they try to make changes.
Stopping the embedded version of WebSphere Application Server

You often need to stop the embedded version of WebSphere Application Server before running the Tivoli Netcool/Impact components. v Stopping the embedded version of WebSphere Application Server on Windows platforms. 1. In the Start menu, select Control Panel Administrative Tools Services.
37
2. In the Services window that opens, right-click IBM Netcool Impact Server and select Properties. In the Properties dialog box, click Stop and then click OK. There is a version of ewas.sh for Windows platforms called ewas.bat, it works in the same way with the same parameter as ewas.sh, meaning it takes the parameter stop to stop the eWAS server. v Stopping the embedded version of WebSphere Application Server on UNIX platforms. On UNIX platforms, you use the application server administration script, ewas.sh, to start and stop the application server. This script is located in the $NCHOME/bin directory. 1. Enter the following command at a command prompt:
$NCHOME/bin/ewas.sh stop
2. When prompted, provide the user name and password for the embedded version of WebSphere Application Server. The default credentials are wasadmin and netcool.
Starting the embedded version of WebSphere Application Server

You often need to start the embedded version of WebSphere Application Server before running the Tivoli Netcool/Impact components. v Starting the embedded version of WebSphere Application Server on Windows platforms. 1. In the Start menu, select Control Panel Administrative Tools Services. 2. In the Services window that opens, right-click IBM Netcool Impact Server and select Properties. In the Properties dialog box, click Start and then click OK. There is a version of ewas.sh for Windows platforms called ewas.bat, it works in the same way with the same parameter as ewas.sh, meaning it takes the parameter stop to stop the eWAS server. v Starting the embedded version of WebSphere Application Server on UNIX platforms. On UNIX platforms, you use the application server administration script, ewas.sh, to start and stop the application server. This script is located in the $NCHOME/bin directory. Enter the following command at a command prompt:
$NCHOME/bin/ewas.sh start
38
Chapter 4. Managing the GUI Server

The GUI Server is the application that hosts the Web-based graphical user interface for Tivoli Netcool/Impact.
Overview of the GUI Server

The GUI Server runs as an application instance inside a Java application server. The default application server is the embedded version of WebSphere Application Server. The GUI Server has two primary components: the GUI engine, and the Name Server. For more information about these components, see GUI Server components. An instance of the GUI Server is created during the installation. The installer sets all of the default configuration properties for the server. After the installation, you can change the configuration of the GUI Server by manually editing its properties files. The GUI Server starts and stops automatically when you start or stop the embedded version of WebSphere Application Server. For more information about starting and stopping the GUI Server, see Running the GUI Server on page 40. A centralized logging feature is provided for both the Impact Server and the GUI Server. For more information, see Monitoring server instances on page 35.
GUI Server components

The GUI Server has the following components: GUI engine The GUI engine is responsible for generating the dynamic Web-based user interface that you use to create and manage the services, data models, and policies. Name Server The Name Server provides registration functionality for the GUI Server and the Impact Server.
GUI engine
The GUI engine is the application that hosts the Tivoli Netcool/Impact GUI pages and brokers requests between end users Web browsers and Tivoli Netcool/Impact. The GUI engine is responsible for generating the dynamic Web-based user interface that you use to create and manage services, data models, and policies.
Name Server
The Name Server is a component that provides registration functionality for the GUI Server and the Impact Server. Applications that use the GUI Server register with the Name Server at startup. The GUI Server uses the information stored in the Name Server when brokering HTTP requests between users Web browsers and the applications. The Name Server is also used to store information that is used in server clustering.
39
Running the GUI Server

Tivoli Netcool/Impact components start and stop automatically when you start and stop the Java application server where they reside (by default, the embedded version of WebSphere Application Server). For information about starting and stopping the application server, see Starting the embedded version of WebSphere Application Server on page 38 and Stopping the embedded version of WebSphere Application Server on page 37.
Redeploying the GUI Server

1. Make sure the GUI Server is running. 2. At a command prompt, change the current directory to $NCHOME/guiserver/ install. 3. Enter the following command at a command prompt to create a new GUI Server EAR file:
$NCHOME/guiserver/install/ncgui_createear
This script recreates and redeploys the guiserver.ear into your GUI Server.
Enabling HTTPS on the GUI Server

Use this procedure to disable HTTP and enable HTTPS with the GUI Server. 1. Backup the $NCHOME/guiserver/install/ear/NC-guiserver-5.1.1.ear file and $NCHOME/guiserver/install/stage/nci.war file. 2. Create the $NCHOME/tmp/nci_war directory. 3. Copy the $NCHOME/guiserver/install/stage/nci.war file to the $NCHOME/tmp/nci_war/ directory. 4. Navigate to the $NCHOME/tmp/nci_war directory. 5. From the command prompt, run the following command:
$NCHOME/eWAS/java/bin/jar -xf nci.war
6. Open the WEB-INF/web.xml file and add the following tags after the </auth-constraint> tag:
<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint>
7. Run the following command:

$NCHOME/eWAS/java/bin/jar -cf nci.war *
8. Copy nci.war to the $NCHOME/guiserver/install/stage/ directory.

cp nci.war $NCHOME/guiserver/install/stage/
9. Navigate to the $NCHOME/guiserver/install directory. 10. Redeploy the GUI Server. Refer to the procedure in Redeploying the GUI Server.
Results
After the new NC-guiserver-5.1.1.ear file is deployed, HTTP is disabled.
40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 5. Server clustering

In a server cluster, you install a group of related Impact Servers and configure them to operate as a single server instance. You use this feature to add failover and load-balancing functions to a Tivoli Netcool/Impact installation.
Server clustering overview

You can install many instances of the Tivoli Netcool/Impact components and configure them to provide failover capability. Each component can be configured for resiliency. For example the Name Server can be configured as a redundant pair. This way you avoid a scenario when the Name Server acts as a single point of failure in a deployment. The Impact Server can be clustered for both resiliency and scaling processing. A server cluster consists of the primary server, which is responsible for gathering events from various event sources and making it available to secondary servers. Secondary servers do not connect directly to the event sources using the reader and listener services. To set up a server cluster, you install a separate instance of Tivoli Netcool/Impact on each target system. When you run the installer program, you specify the same cluster name for each server in the cluster. You configure cluster members in the same way you configure single servers. Most changes made to the server configuration using the GUI are propagated automatically to other cluster members. Manual changes made to the server properties files are not automatically propagated. Configuration for certain services like event processor, self-monitoring and command-line manager are not replicated to the secondary servers. You need to manually configure these services in the secondary server using the command-line service.
Server cluster components

A server cluster consists of the following components: Primary server The primary server is the cluster member that is responsible for gathering events from various event sources using the reader or listener services and for making events available to the secondary servers for processing, as well as processing events on its own. The primary server also runs any configured instances of services like database event reader, database event listener, OMNIbusEventListener, JMSMessageListener. The first cluster member that registers itself in the primary nameserver becomes the primary server. Secondary servers Secondary servers are cluster members that are responsible for retrieving events from the primary server and for executing policies in response to the incoming events. Secondary servers function solely as event processing services in the cluster.
41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Most services are disabled in the secondary servers. The following services are not disabled: v Event processor v Policy logger v Self-monitoring service v Command line manager By default, each secondary server synchronizes its services, data types, data sources, policies, and configuration settings with the primary server before becoming active. Certain configuration like the number of event processing threads, are not synchronized.
Name Server cluster components

A Name Server cluster consists of a primary Name Server and one or more secondary Name Servers. The primary Name Server is the component responsible for communicating in real time with Netcool components like Impact Server and the GUI Server. It stores information about the primary server of the cluster and where it is located in the network. The secondary name servers are responsible for providing failover functionality for the primary Name Server. They do not communicate with the Netcool applications in real time, except in the case that the primary Name Server fails and a secondary Name Server assumes the role of the primary.
Impact Server clustering process

The Impact Server clustering has the following phases: v Startup v Event Monitoring v Event Processing v Failover v Shutdown
Startup
At startup, each server communicates with the Name Server. If no other cluster member is currently registered, it registers itself as the primary server. If a primary server is already registered, it declares itself a secondary server. By default, each secondary server synchronizes its services, data types, data sources, projects, policies, and configuration settings with the primary server before becoming active.
Event monitoring
During the event monitoring phase, the primary server queries the Object Server at intervals for new and updated events, and (optionally) receives notification from the Object Server when an event is deleted. The primary server places the incoming events in an event queue and waits for requests from the secondary servers for event processing. Secondary servers do not query the Object Server at any time.
42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Event processing
During the event processing phase, each secondary server queries the primary server for events to process. Similarly, the primary server requests events from its own event queue. For each retrieved event, the server runs the corresponding policy, dependent on the filter conditions specified in the event reader or listener.
Failover
The secondary servers ping the primary at intervals during runtime. This assures the secondary servers that the primary is active and functioning. If the primary server fails, the first secondary server to become aware of the failure contacts the nameserver and registers itself as the new primary. When the original primary server is restarted, it becomes another secondary server. If a secondary server fails, there is no impact on the other servers in the cluster.
Shutdown
If the primary server is manually shut down, the first secondary server to become aware of the failure contacts the nameserver and registers itself as the new primary, as in the failover phase above. If a secondary server is shut down, there is no impact on the other servers in the cluster.
Name Server clustering process

Nameserver clustering process has the following phases: v Startup v v v v Runtime Command Replication Failure and Recovery Shutdown
Startup
At startup, each nameserver cluster member reads the cluster member list and its position on that list from its web.xml file. The nameserver stores this information internally and uses it to determine its behavior during runtime.
Runtime
During runtime, the cluster member queries the other cluster members at intervals to determine their status and to synchronize nameserver data between them.
Command replication
When you start and stop Netcool/Impact and other components, they issue registration and un-registration commands to the nameserver cluster members. When a cluster member receives such a command, it performs one of the following actions: v If the member is the primary nameserver instance, it will execute the command and then publish the command to every other nameserver in the cluster. The other nameservers then execute the command and update their registration information. v If the member is not the primary nameserver instance, it forwards the command to the primary without executing it. The primary then executes the command as described above.
43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Failure and recovery

When a cluster member fails, the other members detect the failure during normal runtime operation. Once a failure has been detected, the other members update their clustering information and do not attempt to synchronize data with the failed member. When a cluster member recovers, the other members detect the recovery and notify it that it needs to resynchronize its nameserver data.
Shutdown
When you shut down a cluster member, it determines whether to save its nameserver information to disk by reading the PERSIST_ENABLED property in the web.xml file. If PERSIST_ENABLED is set to true, it saves its nameserver information in the directory specified by the PERSIST_PATH property. This information is then read by the cluster member at startup.
Setting up the server cluster

Before you begin
Before you start setting up a cluster, install separate instances of the Tivoli Netcool/Impact on each target system. When the installer prompts you for the cluster name, which is used to identify the members of the server cluster at startup in the Name Server be sure to provide the same cluster name in each of the servers that you are installing. All servers in a cluster must have the same cluster name. This name can be any unique identifying string. The Name Server is installed automatically with the GUI Server. You can install the GUI Server instances for clustering using the instructions in Chapter 2, Installing Tivoli Netcool/Impact, on page 5 with no special considerations.
About this task

For this procedure we assume a typical cluster, in which there are two Name Server instances and two Impact Server instances, with a clustered Name Server of size 2, the first (primary) Name Server instance on primary.com and the second Name Server instance on secondary.com. 1. Configure the primary GUI Server. Add or update the following lines in the $NCHOME/guiserver/etc/ nameserver.props file:
nameserver.1.host=secondary.com nameserver.1.port=9080 nameserver.1.location=/nameserver/services nameserver.count=2
The nameserver.count property sets the number of Name Servers in the cluster to 2. Now the file should look like this:
nameserver.count=2 nameserver.0.host=primary.com nameserver.0.port=9080 nameserver.0.location=/nameserver/services nameserver.1.host=secondary.com nameserver.1.port=9080 nameserver.1.location=/nameserver/services
For more information about these properties, see Connection properties between the Name Server and the GUI Server on page 49. 2. Configure the primary Impact Server.
44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Add or update the following lines in the $NCHOME/impact/etc/nameserver.props file:

impact.nameserver.1.host=secondary.com impact.nameserver.1.port=9080 impact.nameserver.1.location=/nameserver/services impact.nameserver.count=2
The nameserver.count property sets the number of Impact Servers in the cluster to 2. For more information on these properties see Connection properties between the Name Server and the Impact Server on page 49. So the file should look like this:
impact.nameserver.count=2 impact.nameserver.0.host=primary.com impact.nameserver.0.port=9080 impact.nameserver.0.location=/nameserver/services impact.nameserver.1.host=secondary.com impact.nameserver.1.port=9080 impact.nameserver.1.location=/nameserver/services
3. Configure the primary Name Server. Edit the $NCHOME/guiserver/install/stage/nameserver/WEB-INF/web.xml file. After the changes, the file should look like this:
<context-param> <param-name>REPLICANT.COUNT</param-name> <param-value>2</param-value> </context-param> <context-param> <param-name>REPLICANT.0.HOST</param-name> <param-value>primary.com</param-value> </context-param> <context-param> <param-name>REPLICANT.0.PORT</param-name> <param-value>9080</param-value> </context-param> <context-param> <param-name>REPLICANT.0.LOCATION</param-name> <param-value>/nameserver/services</param-value> </context-param> <context-param> <param-name>REPLICANT.1.HOST</param-name> <param-value>secondary.com</param-value> </context-param> <context-param> <param-name>REPLICANT.1.PORT</param-name> <param-value>9080</param-value> </context-param> <context-param> <param-name>REPLICANT.1.LOCATION</param-name> <param-value>/nameserver/services</param-value> </context-param> <context-param> <param-name>SELFINDEX</param-name> <param-value>0</param-value> </context-param>
45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Note: The value of the SELFINDEX property is 0 because this property file is associated with the first Name Server instance in the cluster. For the second Name Server, you must set this property to 1. For a third Name Server, you would set this property to 2. For more information on these properties see Name Server configuration properties on page 50. 4. Configure the secondary GUI Server. Add or update the following lines in the $NCHOME/guiserver/etc/ nameserver.props file:
nameserver.1.host=secondary.com nameserver.1.port=9080 nameserver.1.location=/nameserver/services nameserver.count=2
The nameserver.count property sets the number of Name Servers in the cluster to 2. Now the file should look like this:
nameserver.count=2 nameserver.0.host=primary.com nameserver.0.port=9080 nameserver.0.location=/nameserver/services nameserver.1.host=secondary.com nameserver.1.port=9080 nameserver.1.location=/nameserver/services
5. Configure the secondary Impact Server. Add or update the following lines in the $NCHOME/impact/etc/nameserver.props file:
impact.nameserver.1.host=secondary.com impact.nameserver.1.port=9080 impact.nameserver.1.location=/nameserver/services impact.nameserver.count=2
The nameserver.count property sets the number of Impact Servers in the cluster to 2. Note: The file should be the same as the nameserver.props file of the primary. 6. Configure the secondary Name Server. Edit the $NCHOME/guiserver/install/stage/nameserver/WEB-INF/web.xml file. The file should be the same as in the primary Name Server except for the SELFINDEX part which for the secondary will have the value of 1, like in the following example:
<context-param> <param-name>SELFINDEX</param-name> <param-value>1</param-value> </context-param>
7. Redeploy the server instances where the Name Servers are located. For most situations, the best practice is to perform redeployment of the GUI Server. To redeploy the GUI Server, follow the instructions in Redeploying the GUI Server on page 40. Note: If you are running the Name Server in a clustered configuration, you must first make any changes to the web.xml configuration file for all Name Server and then redeploy the associated GUI Server at the same time. If you make Name Server configuration changes for only one GUI Server instance and then redeploy that instance without redeploying the others, the clustering function will not synchronize as required.
46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
8. Restart the cluster members. You must restart cluster members for the changes to take effect. You start and stop cluster members in the same way you start and stop any other instances of the Impact Server. For more information, see Running Impact Server instances on page 34.
What to do next
v Verify if the clustering procedure has been successful: Perform runtime analysis. For more information about runtime analysis, see Runtime analysis. Check the cluster status in the Name Server. For more information about checking the cluster status, see Checking the cluster status in the Name Server. v Configuration changes are mostly propagated from the primary server to the secondary servers in the cluster except for the following services: Event processor - you make changes to the event processor service settings on each Impact Server in cluster individually. For more information about configuring the event processor service, see Configuring Event Processor service on page 48. Command line service - if you change the port number in the primary server, it does not affect the port where the secondary server is running. Change these settings on the secondary server using the GUI. For more information about the command line service see, Using command line manager on page 94. Self-monitoring service - in a cluster you might not want to monitor each server. You can enable or disable the monitoring elements per server in a cluster. Change these settings on the secondary server using the GUI. For more information about self-monitoring services, see Chapter 9, Self-monitoring, on page 67.
Runtime analysis
Perform runtime analysis. To get more verbose logging, edit $NCHOME/eWAS/properties/log4j.properties. By default, logging is set to INFO level:
log4j.category.com.micromuse=INFO,NETCOOL
Change the level from INFO to DEBUG to get verbose logs:

log4j.category.com.micromuse=DEBUG,NETCOOL
Checking the cluster status in the Name Server

v To check the status of the Name Server. The GUI Server provides a Web-based tool that you can use to view the status of Name Server instances. This tool displays the currently defined Name Server instances and whether they are running or stopped. It also displays the lasts n operations performed by the Name Server, where n is specified in the HISTORY_LOOPSIZE property in the Name Server web.xml file. The URL of this tool is http://host:port/nameserver/services, where host is the host name of the system where the GUI Server is installed and port is the GUI Server port. (for example, http:/swordfish:9014/nameserver/services) Example of output:
47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Netcool Nameserver is running. Current cluster state table at this location: RPL# | SELF | STATUS | URL -----+------+--------+----------------------------------------------0 | **** | UP | http://localhost.localdomain:9080/nameserver/services LAST 100 COMMANDS RECEIVED:
v Web Interface to query the Name Server:

http:/swordfish:9014/nameserver/interface/form.html
Choose List Bindings from the Action menu, type Impact in the Product field, and the name of the cluster in the Service field (for example, NCICLUSTER). Then click the Send command to Name Server button. You should get an HTML page, similar to the following example:
RESULT 9.162.129.141:47144:NCI
v To make sure the cluster is configured correctly, check that the NCHOME/impact/etc/nameserver.props is identical for member of the cluster, and also that NCHOME/guiserver/etc/nameserver.props is identical for each cluster member. Also the web.xml file should have information for each cluster member and SELFINDEX should be unique for each Name Server.
Configuring Event Processor service

The event processor is the service responsible for managing events coming into Tivoli Netcool/Impact through the event reader, event listener, and e-mail reader services. The event processor manages the incoming event queue and is responsible for sending queued events to the policy engine for processing.You make changes to the event processor service settings on each Impact Server in cluster individually. You can change the event processor service properties through the GUI or by editing the NCI_eventprocessor.props file. If you choose to change the values through the GUI, you must start each Netcool/Impact server in the cluster up by itself, log into the GUI, and make the change. You can also edit the NCI_eventprocessor.props file in $NCHOME/impact/etc on each of your Impact Servers. Note: Changes made to the event processor service through the GUI do not propagate out from the primary Impact Server to the other secondary Impact Servers in the cluster. You make changes to the event processor service settings on each Impact Server in cluster individually. You can change the event processor service properties through the GUI or by editing the NCI_eventprocessor.props file. If you choose to change the values through the GUI, you must start each Impact Server in the cluster up by itself, log into the GUI, and make the change. As an alternative to using the GUI, you can edit the NCI_eventprocessor.props file in $NCHOME/impact/etc on each of your Impact Servers. The Impact Server must be restarted to pick up the changes to the file. If you change the configuration in the GUI, there is no need to restart the server, you must only restart the EventProcessor service.
48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Connection properties between the Name Server and the Impact Server
The following table lists the properties used in the $NCHOME/impact/etc/ nameserver.props file that configure the connection between the Impact Server and the Name Server.
Table 2. Connection properties between the Name Server and the Impact Server Property impact.nameserver.userid impact.nameserver.password Description Nameserver login username. Maintained for backward compatibility only. Default is admin. Nameserver login password. Maintained for backward compatibility only. Default is netcool. Number of nameserver instances in the cluster. If you are not running a nameserver cluster, the value of this property is 1. Host name of the nameserver instance, where # is an index value that identifies the nameserver instance. Port used, where # is an index value that identifies the nameserver instance. This is the HTTP port used by the embedded version of WebSphere Application Server, which is 9080 by default. URL location of the embedded version of WebSphere Application Server where nameserver is installed, where # is an index value that identifies the nameserver instance. Default is /nameserver/services. Specifies that the GUI server connects to the nameserver using SSL. Value can be true or false. Default is false. For more information, see Setting up SSL communication in Tivoli Netcool/Impact on page 83. Number of seconds that the GUI server waits on calls to the nameserver before timing out.
impact.nameserver.count
impact.nameserver.#.host
impact.nameserver.#.port
impact.nameserver.#.location
impact.nameserver.ssl_enabled
impact.nameserver.netcall_timeout
Connection properties between the Name Server and the GUI Server
The following table lists the properties used in the $NCHOME/guiserver/etc/ nameserver.props file that configure the connection between the GUI Server and the Name Server.
Table 3. Connection properties between the Name Server and the GUI Server Property nameserver.userid nameserver.password Description Name Server login username. Maintained for backward compatibility only. Default is admin. Name Server login password. Maintained for backward compatibility only. Default is netcool.
49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 3. Connection properties between the Name Server and the GUI Server (continued) Property nameserver.count Description Number of Name Server instances in the cluster. If you are not running a Name Server cluster, the value of this property is 1. Host name of the Name Server instance, where # is an index value that identifies the Name Server instance. Port used, where # is an index value that identifies the Name Server instance. This is the HTTP port used by the embedded version of WebSphere Application Server, which is 9080 by default. URL location of the embedded version of WebSphere Application Server where Name Server is installed, where # is an index value that identifies the Name Server instance. Default is /nameserver/services. Specifies that the GUI Server connects to the Name Server using SSL. Value can be true or false. Default is false. For more information, see Setting up SSL communication in Tivoli Netcool/Impact on page 83. Number of seconds that the GUI Server waits on calls to the Name Server before timing out.
nameserver.#.host
nameserver.#.port
nameserver.#.location
nameserver.ssl_enabled
nameserver.netcall_timeout
Name Server configuration properties

Name Server configuration properties are stored in the $NCHOME/guiserver/ install/stage/nameserver/WEB_INF/web.xml file. The following table shows the basic configuration properties for the Name Server.
Table 4. Basic configuration properties for the Name Server Property SSL_ENABLED Description Specifies whether the Name Server uses the Secure Socket Layer protocol to communicate with Netcool applications. Value can be true or false. Default is false. For more information on configuring the Name Server to use SSL, see Setting up SSL communication in Tivoli Netcool/Impact on page 83. Number of commands stored in the Name Server command history. Default is 100. For more information, see Checking the cluster status in the Name Server on page 47. Number of seconds the application waits after making a call to the Name Server before timing out. Default is 10.
HISTORY_LOOPSIZE
NSSERVICES_NETCALL_TIMEOUT
50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 4. Basic configuration properties for the Name Server (continued) Property NSSERVICES_LOCK_TIMEOUT Description Number of seconds that the Name Server maintains the lock on registry data after a command to write data has been received from a Netcool application. If the Netcool application does not release the lock within the timeout period, the Name Server automatically releases it. Default is 60. Interval in seconds at which the Name Server checks registry data for expired locks. Default is 31. Specifies whether logging of Name Server status and event messages is enabled. Value can be true or false. Default is false. Specifies whether logging of non-ping requests received by the Name Server is enabled. Value can be true or false. Default is false. Specifies whether logging of ping requests received by the Name Server is enabled. Value can be true or false. Default is false.
NSSERVICES_CHECK_TIMEOUT ENABLE_GENERAL_LOGGING
ENABLE_REQUEST_LOGGING
ENABLE_PING_LOGGING
The following table shows properties of the Name Server in a cluster.

Table 5. Clustering properties of the Name Server Property REPLICANT.COUNT REPLICANT.#.HOST Description Number of Name Server in the cluster. Default is 1, for a single, non-clustered Name Server. Host name of the Name Server instance, where # is an index value that identifies the Name Server instance. You must assign index values to each cluster member in a sequence starting from zero. For example, for the first member in a cluster, this property must be named REPLICANT.0.HOST. For the second member, the property must be named REPLICANT.1.HOST. Note: It is recommended to not use the localhost, especially in a clustered architecture. Port used, where # is an index value that identifies the Name Server instance. This is the HTTP port used by the embedded version of WebSphere Application Server, which has 9080 as a default. URL location on servlet container where Name Server is installed, where # is an index value that identifies the Name Server instance. This is the directory you specified when you installed the Name Server. Default is /nameserver/services. Index value that identifies this Name Server cluster. You must specify index values as a series, starting with zero. Interval in milliseconds at which the Name Server contacts other cluster members to determine whether they are still running. Number of milliseconds after sending a query before the Name Server determines that another cluster member is no longer running.
REPLICANT.#.PORT
REPLICANT.#.LOCATION
SELFINDEX REPLICANT_PING_INTERVAL
REPLICANT_PING_TIMEOUT
51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 5. Clustering properties of the Name Server (continued) Property CHECKSUM_IDLE_THRESHOLD Description Minimum number of milliseconds that must pass since the last Name Server command was received (excluding ping commands and any read-only commands) before the Name Server can contact other cluster members to determine whether they are still running. Specifies whether the Name Server must cache its state information to disk at shutdown and read cached information at startup. Can be true or false. Typically, you set this property to true, which is the default. Specifies the directory where state information is cached. Default is $NCHOME/guiserver/webapps/nameserver.
PERSIST_ENABLED
PERSIST_PATH
Impact Server cluster configuration properties

Properties related to server clustering are located in the server properties file. This file is named servername_server.props, where servername is the name of the server instance. The server properties file is located in the $NCHOME/impact/etc directory. This table shows the server clustering properties.
Table 6. Cluster configuration properties Name impact.cluster.name impact.cluster.pinginterval Description Name of the server cluster. The default value is NCICLUSTER. Interval in milliseconds at which to ping other cluster members. The default value is 6000. Time in milliseconds to wait before retrying ping. The default value is 6000. Number of times to retry ping if the first fails. The default value is 3. Specifies whether the server synchronizes data with the primary at startup before becoming active. The default value is true. Specifies whether to synchronize the data item cache. The default value is true.
impact.cluster.pingtimeout
impact.cluster.repingcount
impact.cluster.resyncbeforestandby
impact.replication.receiveupdatesfor.orgnodes
impact.replication.receiveupdatesfor.hibernations Specifies whether to synchronize hibernations. The default value is true. impact.replication.receiveupdatesfor.servicestates Specifies whether to synchronize service states. The default value is true. impact.replication.receiveupdatesfor.types Specifies whether to synchronize data types. The default value is true.
52
| | | | | | | | |
Table 6. Cluster configuration properties (continued) Name impact.replication.receiveupdatesfor.policies impact.replication.statusinterval Description Specifies whether to synchronize policies. The default value is true. Interval at which servers synchronize data. The default value is 0.
53
54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 6. Version control

The version control manager uses Tivoli Netcool/Impact Subversion (SVN) as the default version control system to enable you to save policies, data sources, data types, and configuration properties as revisions in a source control archive.
Version control overview

Tivoli Netcool/Impact Subversion is a customized Subversion that has been prepared for use with Tivoli Netcool/Impact. It is installed automatically with the default settings. If you want to use another supported version control, you must install and configure it before installing Tivoli Netcool/Impact and specify your selection during the installation. Apart from the default version control, the following version control systems are supported: v External SVN v CVS v RCS v ClearCase Note: Version control is enabled by default and cannot be disabled.
Version control process

The version control process has the following phases: Element creation Element creation occurs when you create a new policy, data source or data type using the GUI or CLI. Check out Check out occurs when you open an existing policy, data source, data type, or properties file. At check out, the most recent revision is checked out and locked in the version control system. When an element is locked, the locked icon appears in the GUI. Only the user who has currently checked out the element can modify it. Check in Check in occurs when you save a policy. At check in, the corresponding file is checked in as a new revision and the lock is removed. Element deletion Element deletion occurs when you delete a policy, data source, or data type using the GUI or CLI. At element deletion, the entire element or archive is completely removed from the version control system. Element renaming Element renaming occurs when you rename a policy, data source, or data type using the GUI or CLI. When you rename an element, a new element is created using the new name in the version control system. The old element with the previous name is not deleted.
55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Configuring version control

You can change the version control configuration at any time after you have installed Netcool/Impact. Use the command line service on the secondary server to update the configuration in the version control properties file. This file is named server_versioncontrol.props, where server is the name of the instance of the Netcool/Impact server. This file is located in $NCHOME/impact/etc directory. The following table shows the version control configuration properties.
Table 7. Version Control Configuration Properties Property impact.versioncontrol.class impact.versioncontrol.debug impact.versioncontrol.path impact.versioncontrol.repository Description Class name for the version control system to use. Reserved for internal use. Path to the version control executable (CVS and RCS only) Location of the version control archive (CVS only)
Version control script

You use the provided version control script, nci_version_control, to perform housekeeping and maintenance tasks on data stored in the version control system that you cannot otherwise access using the GUI or the command-line interface. The script is located in the $NCHOME/impact/bin directory. The primary application of this script is storing in the version control the changes to the copy of the server properties file, the nameserver properties file, the JRExec server properties file, and other server-level configuration files. You can also use it to check in and check out copies of policies files, data source files, data type files, and service properties files. The best practice, however, is to avoid using the script directly for this level of management. For example, in a server cluster changes made on a per-server basis to these files are not propagated to other members of a server cluster. Changes are also not propagated to other parts of the system where meta information is stored. You should use the GUI or command line to manage policies, data sources, data types, and services. You use the version control script to: v Check out files. For more information about checking out files, see Checking out files on page 57. v Check in files. For more information about checking in files, see Checking in files on page 57. v Add files. For more information about adding files, see Adding files on page 57. v Uncheck out files.
56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
For more information about unchecking out files, see Unchecking out files on page 58. v Create a checkpoint. For more information about creating a checkpoint, see Creating a checkpoint on page 58. v Update the sandbox. For more information about updating a sandbox, see Updating the sandbox on page 58.
Checking out files

Use the following syntax to check out a file from the version control system:
$NCHOME/impact/bin/nci_version_control server co filename username
where server is the name of the Netcool/Impact server, filename is the name and relative path of the file and username is a valid Netcool username. The file path you specify is relative to the $NCHOME/impact directory. For example, if you want to check out the property file for the default event reader in a server named NCI, you specify etc/NCI_server.props as the file name and path. When you run the version control script, it checks out the file and copies it to the $NCHOME/impact/etc or $NCHOME/impact/policy directory. You must check the file back in order for any changes to the Netcool/Impact configuration to take effect.
Example
The following example shows how to check out a file:
$NCHOME/impact/bin/nci_version_control NCI co etc/NCI_server.props admin
Checking in files
Use the following syntax to check in a file to the version control system:
$NCHOME/impact/bin/nci_version_control server ci filename comment username
where server is the name of the Netcool/Impact server, filename is the name and relative path of the file, comment is a string that describes the check in and username is a valid Netcool Virtual Member Manager username. As with other version control commands, the file name and path that you specify must be relative to the $NCHOME/impact directory.
Example
The following example shows how to check in a file:
$NCHOME/impact/bin/nci_version_control NCI ci etc/NCI_server.props "Checking in new version" admin
Adding files
Use the following syntax to add a new file to the version control system:
$NCHOME/impact/bin/nci_version_control server add filename username
where server is the name of the Netcool/Impact server, filename is the name and relative path of the file, and username is a valid Netcool username.
57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
As with other version control commands, the file name and path that you specify must be relative to the $NCHOME/impact directory.
Example
The following example shows how to add a file:
$NCHOME/impact/bin/nci_version_control NCI add policy/MY_POLICY.ipl admin
Unchecking out files

Use the following syntax to remove the lock from a file that you have previously checked out without performing a new check in:
$NCHOME/impact/bin/nci_version_control server unco filename username
where server is the name of the Netcool/Impact server, filename is the name and relative path of the file, and username is a valid Netcool Virtual Member Manager username. As with other version control commands, the file name and path that you specify must be relative to the $NCHOME/impact directory.
Example
The following example shows how uncheck out a file:
$NCHOME/impact/bin/nci_version_control NCI unco etc/NCI_server admin
Creating a checkpoint
Use the following syntax to create a checkpoint:
$NCHOME/impact/bin/nci_version_control server checkpoint checkpoint_id
where server is the name of the Netcool/Impact server and checkpoint_id is a string that you want to use to identify the version control checkpoint.
Example
The following example shows how to create a checkpoint:
$NCHOME/impact/bin/nci_version_control NCI checkpoint config_build_01
Updating the sandbox

Use the following syntax to check out the tip revision of all files in the version control system:
$NCHOME/impact/bin/nci_version_control server update sandbox
where server is the name of the Netcool/Impact server and sandbox is a string that identifies which directory you want to update. Use etc for the $NCHOME/impact/etc directory, policy for the $NCHOME/impact/ policy directory or . (a period) for both directories.
Example
The following example shows how to check out the tip revision of all files in the version control system:
$NCHOME/impact/bin/nci_version_control NCI update .
58
| | | | | | | | | | | | | | | | |
Migrating to Subversion
You use the nci_cvs2svn script to create a new Subversion repository based upon the version information in the CVS repository. The script only works if you used the internal CVS. 1. Run the following command: v ./nci_cvs2svn (on UNIX platforms) v nci_cvs2svn.exe (on Windows platforms) 2. Restart the Impact Server.
Results
The script loops through all of the files in the /etc and /policy directories. It finds the version information for the files in the CVS repository and puts each version of the file in Subversion. After it is done, the Impact Server is updated to use the new SVN repository. The old CVS repository is kept for backup. Note: In a server cluster, it is recommended to run imports in a standalone server, then start up a secondary cluster member after the import completes.
59
60
Chapter 7. Netcool Database Server

The Netcool Database Server is a specially configured version of HSQL that has been prepared for use with Tivoli Netcool/Impact and other Netcool products.
Overview of the Netcool Database Server

The Netcool Database Server runs as a service in the Impact Server. You need to run the service only if you are using the GUI reporting tools or require a local SQL database data source for use with Tivoli Netcool/Impact, or if the Netcool Database Server is required for another Netcool product running on the same system. A database is used to store the underlying data used by the GUI reporting tools but you can also use it to store other kinds of information used by Tivoli Netcool/Impact. The Tivoli Netcool/Impact database is a HSQL database named impact that is managed by the Netcool Database Server. This database contains tables that store reporting information generated by the Impact Server. The database server is installed automatically with the Impact Server. The home directory for the database is $NCHOME/impact/db. You start and stop the database server using the Service Manager. For more information about starting and stopping the database server, see Running the Netcool Database Server. You perform administrative tasks with the database server using the database script. For more information about using the database script, see Managing the Netcool Database Server on page 62.
Setting the database port

By default, the Netcool Database Server uses port 5435. This port number is specified in the database properties file. The properties file is name <SERVERNAME>_impactdatabase.props and is located in the $NCHOME/impact/etc directory. 1. To change the database port, connect to the Tivoli Netcool/Impact client at http://<hostname>:<port>/nci and configure the ImpactDatabase service. 2. Stop and restart the service to have the change take effect.
Running the Netcool Database Server

To start and stop the Netcool database server, use the Tivoli Netcool/Impact client. The database server starts and stops automatically when you start and stop Tivoli Netcool/Impact.
61
Starting the database server

To start the Netcool Database Server, connect to the Tivoli Netcool/Impact client at http://<hostname>:<port>/nci and start the Service named ImpactDatabase. You do not need to start the server unless you plan to use the GUI reporting tools or use it as a local SQL database data source, or the database server is required by another Netcool application.
Stopping the database server

To stop the Netcool Database Server, connect to the Tivoli Netcool/Impact client at http://<hostname>:<port>/nci and stop the Service named Impact Database.
Managing the Netcool Database Server

You can perform database administration tasks using the database script. You use this script to connect to the database server using the HSQL command line client. The database script is named nci_db and is located in the $NCHOME/impact/bin directory. You use this script to connect to the database using a command line client.
Viewing the database status

To view the database status, connect to the Tivoli Netcool/Impact client at http://<hostname>:<port>/nci and check the status of the ImpactDatabase service.
Resetting the database

Resetting the database removes all of the historical data stored by the GUI reporting tools. To reset the database, complete the following steps: 1. Connect to the client at http://<hostname>:<port>/nci and stop the ImpactDatabase service. 2. Copy the files from $NCHOME/impact/install/dbcore to $NCHOME/impact/db directory and rename them based upon the server name. 3. Restart the ImpactDatabase service to re-initialize it to the base setup.
Connecting to the database with the command line client

The command line client is a SQL tool that is distributed with the HSQL database. To connect to the HSQL database with the client, enter the following command at a command prompt:
$NCHOME/impact/bin/nci_db connect <Impact_Server_Name> <Port>
You can use the client to run SQL statements against the database in real time.
Backing up the database

Use this procedure to back up the database. 1. Connect to the client at http://<hostname>:<port>/nci and stop the ImpactDatabase service. 2. Copy the files from the $NCHOME/impact/db directory.
62
Restoring the database

Use this procedure to restore the database from a backup file. 1. Connect to the client at http://<hostname>:<port>/nci and stop the ImpactDatabase service. 2. Copy the backup to the $NCHOME/impact/db directory.
Chapter 7. Netcool Database Server
63
64
Chapter 8. JRExec server

The JRExec server is a runnable server component that is used to execute external commands, scripts, and applications from within a policy.
Overview of the JRExec server

The JRExec server is automatically installed when you install Tivoli Netcool/Impact. On Windows platforms, you must also manually add the JRExec server as a Windows service. For more information about adding the JRExec server as a Windows service, see Installing the JRExec server (Windows platforms) on page 28. You run the JRExec server either using the JRExec server script or through the services administration tools, depending on the operating system. For more information about running the JRExec server, see Running the JRExec server on UNIX platforms, and Running the JRExec server on Windows platforms. You configure the JRExec server through a property file. For more information about configuring the JRExec server, see Configuring the JRExec server. You can use the JRExec server to run external commands, using the JRExecAction function. For more information about the JRExecAction function, see the Policy Reference Guide.
Running the JRExec server on UNIX platforms

The JRExec Server startup script, nci_jrexec, is located in the $NCHOME/impact/bin directory. v To start the JRExec Server run the following command at a command prompt:
$NCHOME/impact/bin/nci_jrexec
v To manually terminate the process, run the following command at a command prompt:
kill -9 pid
where pid is the process ID of the JRExec Server.
Running the JRExec server on Windows platforms

On Windows platforms you run the the JRExec server as a service, in the Control Panel Administrative Tools Services console. v To start the JRExec server right-click Netcool JRExec Server in the Services window that opens, and select Start. v To stop the JRExec server right-click Netcool JRExec Server in the Services window that opens, and select Stop.
Configuring the JRExec server

The JRExec server provides a properties file named jrexecserver.props. This file is located in the $NCHOME/impact/etc directory and contains the port number used by the JRExec server.
65
To change the port number used by the JRExec server, open the properties file in any text editor and change the value of the impact.jrexecserver.port property. If you change this property, you must also change the value of the impact.jrexec.port property in the server_server.props file, where server is the name of the Impact Server instance.
66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 9. Self-monitoring
Self-monitoring is used to monitor aspects of Tivoli Netcool/Impact runtime performance
Self-monitoring overview
Self-monitoring feature is used to monitor the following aspects of Tivoli Netcool/Impact performance: v Memory status usage v Event queue size v Data source status v Cluster status The performance information is then reported to the Netcool/OMNIbus ObjectServer as Netcool events. The events sent to the Object Server as part of self-monitoring are the same as any other Netcool/OMNIbus events. These events can be viewed by Netcool operators in an event list and managed according to the normal event handling procedures in your environment. You can also configure the event reader to launch custom policies that are designed to respond to these events. The self-monitoring feature is provided by the SelfMonitoring service. The service is created automatically when you install Tivoli Netcool/Impact. You cannot create new instances of this service. To set up the self-monitoring feature, you configure the SelfMonitoring service using the GUI or command line interface (CLI). For more information setting up and running self-monitoring, see Running self-monitoring using the command line interface on page 68 and Setting up self-monitoring using the GUI on page 68. If you are running Impact Servers in a cluster, self-monitoring operates on a per-server basis. For more information about self-monitoring in a server cluster, see Self-monitoring in server cluster.
Self-monitoring in server cluster

You configure self-monitoring on each server instance separately and each server runs the self-monitoring feature independent of other cluster members. Service configuration information is not propagated between members of the cluster which allows you to customize self-monitoring for each system where you are running the cluster. For single-server configurations of Tivoli Netcool/Impact, using the GUI to set up self-monitoring is recommended. For a clustered server configuration, set up self-monitoring for the secondary members using the $NCHOME/impact/etc/ <servername>_selfmonitoring.props properties file, or CLI since the GUI only configures the primary server. If you do not want to monitor each server in a cluster you can enable or disable the monitoring elements on a server in a cluster. For more information, see Cluster Status Monitoring on page 78
67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Setting up self-monitoring using the GUI

Use this procedure to set up self-monitoring using the GUI: 1. Open the GUI in a Web browser. 2. In the Service Status panel, select SelfMonitoring to open the Self-Monitoring Configuration window. 3. Select a data source from the ObjectServer Data Source list. This is the ObjectServer where any new events will be sent. 4. Select Memory Status to enable memory status monitoring. 5. Type an interval in seconds in the Interval field. This is the number of seconds at which you want memory status to be checked. 6. Enable or disable the Deduplication option. This options specifies whether memory status events sent to the Object Server are deduplicated. If you change the deduplication option while the service is running, you must stop and restart it before the change takes effect. 7. Select Queue Status to enable queue size monitoring. 8. Type an interval in seconds in the Interval field. This is the number of seconds at which you want the event queue size to be checked. 9. Enable or disable the Deduplication option. This options specifies whether event queue status events sent to the Object Server are deduplicated. If you change the deduplication option while the service is running, you must stop and restart it before the change takes effect. 10. Select Cluster Status to enable cluster status monitoring. 11. Select Data Source Status to enable data source status monitoring. 12. Enable or disable the Startup option. This option specifies whether this service starts automatically when you start the Tivoli Impact Server. 13. Enable or disable the Service Log option. This option specifies whether to print the service log to file. 14. Click OK.
Running self-monitoring using the GUI

Follow this procedure to run the self-monitoring service using the GUI.
Before you begin

If you are running the Impact Server in a clustered service configuration, you must use the command line interface to start and stop non-primary instances of the Impact Server in the cluster. For information on starting and stopping the service using the command line interface, see Running self-monitoring using the command line interface. 1. Open the GUI in a Web browser. 2. In the Service Status panel, click: a. The Start button next to the SelfMonitoring service to start the service. b. The Stop button next to the SelfMonitoring service to stop the service.
Running self-monitoring using the command line interface

v To start the self-monitoring service, enter the following command at the CLI prompt:
UPDATE Service SET Running = true WHERE Name = 'SelfMonitoring';
68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
v To stop the self-monitoring service, enter the following command at the CLI prompt:
UPDATE Service SET Running = false WHERE Name = 'SelfMonitoring';
Setting the Object Server Data Source for monitoring events

v To check the current Object Server DataSource where monitoring events are sent use this command:
Select DataSource from Service where Name = 'SelfMonitoring';
v To change the Object Server DataSource where monitoring events are sent use this command:
Update Service set DataSource='ObjDS' where Name='SelfMonitoring';
where ObjDS is the name of the Object Server Data Source.
Memory status monitoring

Memory status monitoring is the process by which the self-monitoring service checks the available Java and system memory and sends events to the Netcool/OMNIbus ObjectServer regarding the memory status at intervals. Tivoli Netcool/Impact monitors available memory in both the Java heap and in the system as a whole. The memory status is significant because Tivoli Netcool/Impact will fail and report an out-of-memory error if the maximum available memory is exceeded.
Java memory status

When you start an instance of the JVM, you can specify a minimum and maximum heap size using the -Xms and -Xmx flags. The -Xms flag specifies the minimum size of the memory heap and -Xmx specifies the maximum size.
About this task

For Tivoli Netcool/Impact, the default value of Xms is 50M and the default value of Xmx is 1000M. To set it to different value, you need to use the wsadmin.sh script located at $NCHOME/eWAS/profiles/ImpactProfile/bin directory. The following procedure shows how to set the maximum heap size. 1. If the Impact Server is not running, run the following command:
wsadmin.sh -conntype none -lang jython
2. Run the following command:

wsadmin.sh -conntype SOAP -lang jython -username wasadmin -password netcool
3. At a command prompt, type in:

wsadmin> jvm = AdminConfig.list("JavaVirtualMachine").split("\r\n") [0] wsadmin>AdminConfig.modify(jvm, '[[maximumHeapSize 2000]]') wsadmin>attr=[] wsadmin>attr.append([['name','Xmx'], ['value','2000']]) wsadmin>AdminConfig.modify(jvm, [['systemProperties',[]]]) wsadmin>AdminConfig.modify(jvm, [['systemProperties',attr]]) wsadmin> AdminConfig.save() wsadmin> exit
This will set the maximum heap size to 2000 MB. 4. Restart the server.
69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Results
When you enable the self-monitoring feature, Tivoli Netcool/Impact checks the current heap size at intervals and compares it to the maximum size specified by the XMX variable. The severity of the JVM memory status is then calculated using the rules in Memory status severity.
System memory status

In addition to Java heap memory, the memory monitoring feature also monitors available system memory as a whole. At maximum, Tivoli Netcool/Impact uses the amount of Java heap memory specified in the XMX variable as well as an additional 100 to 120 megabytes of system memory. In order to effectively report on the memory status for the system, the total amount of system memory available at a given time compared to the amount of memory currently in use by the application must also be taken into consideration . When you enable the self-monitoring feature, Tivoli Netcool/Impact checks the current available system memory at intervals and compares it to the maximum memory that it requires. The maximum memory is determined by adding 150 megabytes to the maximum amount allocated to the Java heap. For example, if the XMX variable is set to 1000M, the maximum allocated memory is determined to be 1150 megabytes. Then the severity of the system memory status is calculated using the rules in Memory status severity.
Combined memory status

After calculating the severity of the JVM and system memory status, the event is sent to the Object Server. This event contains the fields described in Memory event fields on page 71. The total severity of the event is the highest severity between the JVM and system memory status.
Memory status severity

The following criteria are used to determine the severity of the JVM memory status.
Table 8. Severity of the JVM memory status Severity 1 2 3 4 5 Criteria Maximum heap limit is greater than twice the current help size. Maximum heap limit is between 1.6 and 2 times the current heap size. Maximum heap limit is between 1.4 and 1.6 times the current heap size. Maximum heap limit is between 1.2 and 1.4 times the current heap size. Maximum heap limit is less than 1.2 times the current heap size.
The following criteria are used by Netcool/Impact to determine the severity of the system memory status.
Table 9. Severity of the system memory status Severity 1 Criteria Available system memory is greater than twice the maximum required memory.
70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 9. Severity of the system memory status (continued) Severity 2 3 4 5 Criteria Available system memory is between 2 and 1.8 times the maximum required memory. Available system memory is between 1.8 and 1.65 times the maximum required memory. Available system memory is between 1.65 and 1.5 times the maximum required memory. Available system memory is less than 1.5 the maximum required memory.
Note: The total severity of any memory event sent to the Object Server is the highest severity between the JVM and the system memory status.
Memory event fields

The following table shows the fields in memory events sent to the Object Server.
Table 10. Fields in memory events sent to the Object Server Field Identifier Node NodeAlias Severity Summary Class Type AlertGroup FirstOccurrence LastOccurrence Description Impact Memory Status for server, where server is the name of the Impact Server instance. Host name of the system where the Impact Server is running. IP address of the system where the Impact Server is running. Severity calculated according to the rules in Memory status severity on page 70. Detailed information about the memory status, including information about JVM heap usage and system memory usage. 10500 13 ImpactStatus Timestamp for the first occurrence of this event. Timestamp for the most recent occurrence of this event.
Checking if memory status monitoring is enabled

To check to see if memory status monitoring is enabled, enter the following command at the CLI prompt.
SELECT IsMemoryStatusEnabled FROM Service WHERE Name = 'SelfMonitoring';
The CLI returns a value of true if memory status monitoring is enabled. Otherwise, the CLI returns a value of false.
Enabling memory status monitoring

To enable memory status monitoring, enter the following command at the CLI prompt.
UPDATE Service SET EnableMemoryStatus = true where Name='SelfMonitoring';
71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Disabling memory status monitoring

To disable memory status monitoring, enter the following command at the CLI prompt.
UPDATE Service SET EnableMemoryStatus = false where Name='SelfMonitoring';
Viewing current memory status

SELECT MemoryStatus FROM Service WHERE Name='SelfMonitoring';
Viewing memory status history

SELECT MemoryStatusHistory FROM Service WHERE Name = 'SelfMonitoring';
Viewing the total JVM heap size

To view the total JVM heap size, enter the following command at the CLI prompt.
SELECT TotalVMHeapSize FROM Service WHERE Name = 'SelfMonitoring';
Viewing the maximum JVM heap size

To view the maximum JVM heap size, enter the following command at the CLI prompt.
SELECT MaxVMHeapSize FROM Service WHERE Name = 'SelfMonitoring';
Viewing the free system memory

To view the free system memory, enter the following command at the CLI prompt.
SELECT FreeSystemMemory FROM Service WHERE Name = 'SelfMonitoring';
Checking if memory status events are deduplicated

To check to see if memory status events are being deduplication, enter the following command at the CLI prompt.
SELECT MemoryDeduplication FROM Service WHERE Name = 'SelfMonitoring';
The CLI returns a value of true if memory status event deduplication is enabled. Otherwise, the CLI returns a value of false.
Disabling memory status event deduplication

To disable memory status event deduplication, enter the following command at the CLI prompt.
UPDATE Service SET MemoryDeduplication = false WHERE Name= 'SelfMonitoring';
72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Viewing memory status event intervals

To view the intervals at which the memory status is checked, enter the following command at the CLI prompt.
SELECT MemoryInterval FROM Service WHERE Name = 'SelfMonitoring';
Changing memory status event intervals

To change the interval at which the Impact Server checks the memory status, enter the following command at the CLI prompt:
UPDATE Service SET MemoryInterval = interval WHERE Name = 'SelfMonitoring';
where interval is the number of seconds at which the server checks the queue status,
Queue status monitoring

Queue size monitoring monitors the following services: v OMNIbusEventReader v v v v DatabaseEventReader OMNIbusEventListener DatabaseEventListener JMSMessageListener
Queue size monitoring is the process in which the self-monitoring service checks the size of event reader event queues at intervals and sends events to the Object Server regarding the event queue status. For each event, the self-monitoring service calculates the severity by determining the rate at which the queue size is increasing or decreasing since the last interval point. For more information on the rules used to determine the severity, see Queue status severity. For more information on the value of fields in the events sent to the Object Server see Queue status event fields on page 74.
Queue status severity

The following criteria are used to determine the severity of the event queue status.
Table 11. Severity of the event queue status Severity 1 2 3 4 5 Criteria Number of events in queue is less than or equal to 1.5 times the number of events at previous interval. Number of events in queue is between 1.5 and 2. times the number of events at previous interval. Number of events in queue is between 2 and 3 times the number of events at previous interval. Number of events in queue is between 3 and 5 times the number of events at previous interval. Number of events in queue is more than 5 times the number of events at previous interval.
73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Queue status event fields

The following table shows the fields in memory events sent to the Object Server.
Table 12. Fields in memory events sent to the Object Server Field Identifier Node NodeAlias Severity Summary Class Type AlertGroup FirstOccurrence LastOccurrence Description Impact Queue Status for server, where server is the name of the Impact Server instance. Host name of the system where the Impact Server is running. IP address of the system where the Impact Server is running. Severity calculated according to the rules in Queue status severity on page 73. Detailed information about the queue status, as described in the table below. 10500 13 ImpactStatus Timestamp for the first occurrence of this event. Timestamp for the most recent occurrence of this event.
This table shows the queue size information sent as the contents of the Summary field.
Table 13. Queue size information sent as the contents of the Summary field Value Service name QueueSize DeltaQueue Description Name of the service associated with the queue. Current number of events in queue. Change in queue size since the last interval. If this value is greater than zero, the queue size has increased. If the value is less than zero, the queue size has decreased. Rate at which the queue is increasing. This value is generated if DeltaQueue is greater than zero. Rate at which the queue is decreasing. This value is generated if DeltaQueue is less than zero. Time difference between the StateChange of the earliest event in queue and the current time.
QueueIncreaseRate QueueDecreaseRate Gap
Checking if queue status monitoring is enabled

To check to see if queue status monitoring is enabled, enter the following command at the CLI prompt:
SELECT IsQueueStatusEnabled FROM Service WHERE Name = 'SelfMonitoring';
The CLI returns a value of true if queue status monitoring is enabled. Otherwise, the CLI returns a value of false.
74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Enabling queue status monitoring

To enable queue status monitoring, enter the following command at the CLI prompt:
UPDATE Service SET EnableQueueStatus = true WHERE Name = 'SelfMonitoring';
Disabling queue status monitoring

To disable queue status monitoring, enter the following command at the CLI prompt:
UPDATE Service SET EnableQueueStatus = false WHERE Name = 'SelfMonitoring';
Viewing the current queue status

To view the current queue status, enter the following command at the CLI prompt:
SELECT QueueStatus FROM Service WHERE Name = 'SelfMonitoring';
Viewing the queue status history

To view the queue status history, enter the following command at the CLI prompt:
SELECT QueueStatusHistory FROM Service WHERE Name = 'SelfMonitoring';
Checking if queue status event deduplication is enabled

To check to see if queue status event deduplication is enabled, enter the following command at the CLI prompt:
SELECT QueueDeduplication FROM Service WHERE Name = 'SelfMonitoring';
The CLI returns a value of true if queue status event deduplication is enabled. Otherwise, the CLI returns a value of false.
Enabling queue status event deduplication

To enable queue status event deduplication, enter the following command at the CLI prompt:
UPDATE Service SET QueueDeduplication = true WHERE Name = 'SelfMonitoring';
Disabling queue status event deduplication

To disable, queue status event deduplication, enter the following command at the CLI prompt:
UPDATE Service SET QueueDeduplication = false WHERE Name = 'SelfMonitoring';
Viewing queue status event intervals

To view the interval at which the Impact Server checks the queue status, enter the following command at the CLI prompt:
SELECT QueueInterval FROM Service WHERE Name = 'Self-Monitoring';
75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Changing queue status event intervals

To change the interval at which the Impact Server server checks the queue status, enter the following command at the CLI prompt:
UPDATE Service SET QueueInterval = interval WHERE Name = 'SelfMonitoring';
where interval is the number of seconds at which the server checks the queue status,
Data source status monitoring

Data status monitoring is a process in which the self-monitoring service sends events to the Netcool/OMNIbus ObjectServer that report the status of Tivoli Netcool/Impact database connections. Data source monitoring for the following SQL database data sources is supported: v MySQL DSA v ObjectServer DSA v ODBC DSA v Oracle DSA v v v v PostgreSQL DSA SQL Server DSA Sybase DSA GenericSQL DSA
v DB2 v MS-SQL Server v HSQLDD v Informix
Data source status events

The self-monitoring service sends data source status events to the Object Server under the following conditions: Successful test connection to a data source You can use the GUI to test connections to the primary and backup database servers when you create or configure an SQL database data source. When you successfully test a connection to a database server, the self-monitoring service sends an event to the ObjectServer with a severity of 1. Failed test connection to a data source If a successful test connection to a database server cannot be made, the self-monitoring service sends an event to the Object Server with a severity of 4. Failed execution of an SQL query against a data source SQL queries are sent to data sources under a variety of conditions (for example, when it process a function like GetByFilter or AddDataItem in a policy or when you view the contents of a data type in the GUI). If an SQL query fails, another attempt is made to send the query to the database server. If the second attempt fails, the self-monitoring service sends an event to the Object Server with a severity of 4. Termination of existing connections to a data source When all existing connections to a database server are terminated, the
76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
self-monitoring service sends an event to the Object Server with a severity of 5. This happens, for example, when a primary database is no longer accessible and is switching to a backup database.
Data source status event fields

The following table shows the fields in data source status events sent to the Object Server.
Table 14. Fields in data source status events sent to the Object Server Field Identifier Node NodeAlias Severity Summary Class Type AlertGroup FirstOccurrence LastOccurrence Description Impact DataSource Status for server, where server is the name of the Impact Server instance. Host name of the system where the Impact Server is running. IP address of the system where the Impact Server is running. Severity as described in Queue status severity on page 73. Detailed information about the data source status, as described in Table 28. 10500 13 ImpactStatus Timestamp for the first occurrence of this event. Timestamp for the most recent occurrence of this event.
This table shows the data source status information sent as the contents of the Summary field.
Table 15. Data source status information sent as the contents of the Summary field Condition Successful test connection Summary Field If you are testing the connection while creating a new data source, the value of the Summary field is Connection established to the host hostname port port_number for the data source datasource_name, where hostname is the host name or IP address of the system where the database server is running, port is the connection port for the database server and datasource_name is the name of the data source. If you are testing the connection while editing an existing data source, the value of the summary field is Connection established to the primary | backup server for the data source datasource_name on host hostname port port_number. Failed test connection If you are testing the connection while creating a new data source, the value of the Summary field is Could not connect to the host hostname port port_number for the data source datasource_name, If you are testing the connection while editing an existing data source, the value of the summary field is Could not connect to the primary | backup server for the data source datasource_name on host hostname port port_number.
77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 15. Data source status information sent as the contents of the Summary field (continued) Condition Summary Field
Failed execution of an SQL Failed to execute query on the primary | backup server query for the data source datasource_name on host hostname port port_num. Invalidating all connections. Termination of existing connections Invalidating all connections to the primary | backup server for the data source datasource_name on host hostname port port_num.
Checking if data source status monitoring is enabled

To check to see if data source status monitoring is enabled, enter the following command at the CLI prompt:
SELECT IsDataSourceStatusEnabled FROM Service WHERE Name = 'SelfMonitoring';
The CLI returns a value of true if data source status monitoring is enabled. Otherwise, the CLI returns a value of false.
Enabling data source status monitoring

To enable data source status monitoring, enter the following command at the CLI prompt:
UPDATE Service SET EnableDataSourceStatus = true WHERE Name = 'SelfMonitoring';
Disabling data source status monitoring

To disable data source status monitoring, enter the following command at the CLI prompt:
UPDATE Service SET EnableDataSourceStatus = false WHERE Name = 'SelfMonitoring';
Viewing the current data source status

To view the current data source status, enter the following command at the CLI prompt:
SELECT DataSourceStaths FROM Service WHERE Name = 'Self-Monitoring';
Viewing the data source status history

To view the data source status history, enter the following command at the CLI prompt:
SELECT DataSourceStatusHistory FROM Service WHERE Name = 'Self-Monitoring';
Cluster Status Monitoring

Cluster status monitoring is a process in which the self-monitoring service sends events to the Netcool/OMNIbus ObjectServer that report the status of members in an Impact Server cluster.
78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Starting self-monitoring on a secondary cluster member

Before you begin
The self-monitoring service must be running on primary and secondary cluster members in order for this feature to report all possible status data to the Object Server. You can start the self-monitoring service on secondary cluster members using the CLI.
About this task

To start the self-monitoring service on a secondary cluster member: 1. Connect to the command line service running on the secondary server using a telnet application. For example, enter the following command at a command prompt:
telnet hostname 2000
where hostname is the name of the system where the secondary server is running. 2. Log in to the CLI using a valid Virtual Member Manager username and password. The default administration username is admin and the password is netcool. 3. Enter the following command at the command prompt to start the self-monitoring service:
UPDATE Service SET Running=true where Name='SelfMonitoring';
Cluster status events

The self-monitoring service sends cluster status events to the Object Server under the following conditions: A secondary cluster member becomes unavailable If the primary cluster member detects that a secondary server has become unavailable, the self-monitoring service running in the primary server sends an event to the Object Server with a severity of 3. A secondary cluster member assumes the primary role If a secondary cluster member assumes the primary role, its self-monitoring service sends an event to the Object Server with a severity of 1. A secondary cluster member detects that the primary has become unavailable If a secondary cluster member detects that the primary server has become unavailable, its self-monitoring service sends an event to the Object Server with a severity of 5. A secondary cluster member accepts a new primary server If a secondary cluster member accepts another member of the cluster as the new primary server, its self-monitoring service sends an event to the Object Server with a severity of 1.
Cluster status event fields

The following table shows the fields in data source status events sent to the Object Server.
79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Table 16. Fields in data source status events sent to the Object Server Field Identifier Node NodeAlias Severity Summary Class Type AlertGroup FirstOccurrence LastOccurrence Description Impact Cluster Status for server, where server is the name of the Impact Server instance. Host name of the system where the Impact Server is running. IP address of the system where the Impact Server is running. Severity as described in Cluster status events on page 79. Detailed information about the data source status, as described in Table 35. 10500 13 ImpactStatus Timestamp for the first occurrence of this event. Timestamp for the most recent occurrence of this event.
This table shows the data source status information sent as the contents of the Summary field.
Table 17. Data source status information sent as the contents of the Summary field Condition Secondary cluster member unavailable Secondary cluster member assumes the primary role Secondary cluster member detects that the primary has become unavailable Secondary cluster member accepts a new primary Summary Field Secondary Server server_name has gone down, where server_name is the name of the Impact Server instance. server_name is the new Primary Server, where server_name is the name of the server instance. Secondary Server secondary_name reporting that Primary Server primary_name has gone down, where secondary_name is the name of the secondary server instance and primary_name is the name of the primary server instance. Secondary Server secondary_name acknowledging primary_name as the new Primary Server, where secondary_name is the name of the secondary server instance and primary_name is the name of the primary server instance.
Checking if cluster status monitoring is enabled

To check to see if cluster status monitoring is enabled, enter the following command at the CLI prompt:
SELECT IsClusterStatusEnabled FROM Service WHERE Name = 'SelfMonitoring';
The CLI returns a value of true if cluster status monitoring is enabled. Otherwise, the CLI returns a value of false.
Enabling cluster status monitoring

To enable cluster status monitoring, enter the following command at the CLI prompt:
UPDATE Service SET EnableClusterStatus = true WHERE Name = 'SelfMonitoring';
80
| | | | | | | | | | |
Disabling cluster status monitoring

To disable cluster status monitoring, enter the following command at the CLI prompt:
UPDATE Service SET EnableClusterStatus = false WHERE Name = 'SelfMonitoring';
Viewing the current cluster status

To view the current cluster status, enter the following command at the CLI prompt:
SELECT ClusterStatus FROM Service WHERE Name = 'SelfMonitoring';
Viewing the cluster status history

To view the cluster status history, enter the following command at the CLI prompt:
SELECT ClusterStatusHistory FROM Service WHERE Name = 'SelfMonitoring';
81
82
Chapter 10. Secure communication in Tivoli Netcool/Impact

Tivoli Netcool/Impact supports secure modes of communication.
Setting up SSL communication in Tivoli Netcool/Impact

1. Generate the SSL keystore, server certificate, and truststore. For more information see, Generating the SSL keystore, server certificate and truststore. 2. Copy the SSL keystore, server certificate, and truststore to the Java application server installation directory. For more information see, Copying the SSL keystore, server certificate and truststore on page 84. 3. Configure the embedded version of WebSphere Application Server. For more information, see Configuring the embedded version of WebSphere Application Server for SSL certificate and key management on page 84. 4. Configure the Name Server. For a detailed procedure, see Configuring the Name Server for SSL on page 85. 5. Configure the Impact Server and GUI Server. For detailed procedures, see Configuring Impact Server for SSL on page 85 and Configuring the GUI Server for SSL on page 85 6. Redeploy the GUI Server EAR file. For instructions, refer to Redeploying the GUI Server on page 40.
Generating the SSL keystore, server certificate and truststore

About this task
The first step in setting up the nameserver to work with SSL is to generate the SSL keystore, server certificate, and truststore. You can use the Java keytool utility to perform these tasks. This utility is located in the $NCHOME/eWAS/java/jre/bin directory. To generate the keystore, enter the following command at a command line prompt:
keytool -genkey -alias ns_server -keyalg RSA -keypass password -storepass password -keystore keystore_server.jks
where password is the password that will be required in order to access the keystore. The keytool utility prompts you for information that identifies you, your organization and your location and then creates a file named keystore_server.jks in the current working directory. To export a server certificate, enter the following command at a command line prompt:
keytool -export -alias ns_server -file server.cer -storepass password -keystore keystore_server.jks
where password is the password that you specified when you created the keystore.
83
The keytool utility creates a server certificate file named server.cer in the current working directory. To create the truststore, enter the following command at a command line prompt:
keytool -import -alias ns_server -v -trustcacerts -file server.cer -keypass password -storepass password -keystore cacerts.jks
where password is the password that you specified when you created the keystore. They keytool utility prompts you to confirm that you trust the server.cer certificate file and then creates a file named cacerts.jks in the current working directory.
Copying the SSL keystore, server certificate and truststore

About this task
After you have created the keystore, server certificate and truststore, you must copy these files to a location in the Java application server installation directory. For the embedded version of WebSphere Application Server (which is the default application server for Tivoli Netcool/Impact components), the location is $NCHOME/eWAS/profiles/ImpactProfile/etc.
Configuring the embedded version of WebSphere Application Server for SSL certificate and key management
Follow this procedure to import the signed certificate from IBM Netcool/OMNIbus to enable SSL connections to the Object Server and to configure the embedded version of WebSphere Application Server for SSL certificate and key management. 1. Log on to the embedded version of WebSphere Application Server at http://host:port/ibm/console. 2. In the navigation pane, select Security SSL certificate and key management. The SSL certificate and key management page is displayed. 3. Under Related Items, click Key stores and certificates and then select NodeDefaultTrustStore. The General Properties page for NodeDefaultTrustStore is displayed. 4. Under Additional Properties, click Signer certificates. A table that includes a list of signer certificates is displayed. 5. In the table, click the Add button to copy the signed certificate (for example, cert.arm) file to the WAS_HOME/profiles/ImpactProfile/etc directory. 6. Provide the following information: a. In the Alias field, type trusted. b. In the File name field, type cert.arm. c. From the Data type list, select Base64encoded ASCII data. 7. To add the new certificate to the list, click OK. 8. Restart the embedded version of WebSphere Application Server.
Results
Your SSL connection should now work.
84
Configuring the Name Server for SSL

You must also configure the Name Server so that it recognizes that HTTPS connections are enabled. To configure the Name Server, you modify its deployment descriptor file. This file is named web.xml and is located in the $NCHOME/guiserver/install/stage/nameserver/WEB-INF directory. 1. Open the web.xml file in a text editor. 2. Locate the context-param element that contains the SSL_ENABLED property and set its value to true. The resulting element should look like this:
<context-param> <param-name>SSL_ENABLED</param-name> <param-value>true</param-value> </context-param>
3. Locate the context-param element that contains the REPLICANT.0.PORT property and update it with the SSL port number. The SSL port number should be the same port that you specified when you installed the GUI Server and when you configured the HTTPS connector. The default port is 8443. The resulting element should look like this:
<context-param> <param-name>REPLICANT.0.PORT</param-name> <param-value>8443</param-value> </context-param>
4. Save the web.xml file.
Configuring Impact Server for SSL

To configure the Impact Server to access the Name Server through SSL you modify the contents of the nameserver.props file in the $NCHOME/impact/etc directory. Set the following properties in the nameserver.props configuration file:
impact.nameserver.ssl_enabled=true impact.nameserver.0.port=port
where port is the SSL port number that you specified when you installed the GUI Server and when you configured the HTTPS connector. The default is 8443.
Configuring the GUI Server for SSL

To configure the GUI Server to access the Name Server through SSL you modify the contents of the nameserver.props file in the $NCHOME/guiserver/etc directory. Set the following properties in the nameserver.props configuration file:
nameserver.ssl_enabled=true nameserver.0.port=port
where port is the SSL port number that you specified when you installed the GUI Server and when you configured the HTTPS connector. The default is 8443.
Deploying Virtual Member Manager adapter

Tivoli Netcool/Impact supports connecting to the Object Server V7.x running in SSL mode.
85
To use the Object Server as an external authentication and authorization source for your deployment, you need to install a Virtual Member Manager (VMM) adapter that provided this functionality within the embedded version of WebSphere Application Server.
Installing Virtual Member Manager adapter on embedded version of WebSphere Application Server
To integrate Virtual Member Manager (VMM) with OMNIbus you must install Virtual Member Manager adapter on the application server. By default, the OMNIbus adapter is not installed on the embedded version of WebSphere Application Server. 1. Stop the embedded version of WebSphere Application Server as described in Stopping the embedded version of WebSphere Application Server on page 37. 2. Go to the $NCHOME//etc/tivoli-vmm4ncos/bin directory. 3. Run the install-vmm4ncos.[bat|sh] script to install the adapter on the application server. Note: v If you run the script without parameters, a help message is displayed. v For an authentication, provide OMNIbus user name, OMNIbus password, host name, and port number. Restart the application server as described in Starting the embedded version of WebSphere Application Server on page 38. Edit the $NCHOME/etc/tivoli-vmm4ncos/guiserver.settings file with the users to grant accesses and their associated roles. Run the update-roles.[bat|sh] script. Log on to the Impact GUI with an OMNIbus managed user.
4. 5. 6. 7.
Validating the installation script

Use this procedure to ensure that the installation script has successfully completed. 1. Make sure there are no errors while running the script. 2. Make sure there are new jar files created in the $NCHOME/eWAS/lib/ext directory: v commons-dbcp-1.2.2.jar v commons-pool-1.4.jar v jconn3.jar v tivoli-vmm4ncos-1.0.jar 3. And finally, make sure that the configuration information for the ObjectServerRepository has been successfully added in the $NCHOME/eWAS/profiles/ImpactProfile/config/cells/ImpactCell/wim/config/ wimconfig.xml file.
Mapping roles to users

To start using the Object Server for authentication, you need to configure the server so that it can map the roles that the application exposes to groups and users managed in OMNIbus. These roles must be granted to either users or groups managed within Virtual Member Manager. 1. Go to the tivoli-vmm4ncos directory. 2. Open the guiserver.setting file in a text editor. 3. Add roles to GUI Server:
86
a. Go to ROLE SETTINGS section. b. Specify the parameters: v IMPACT_USER v NETCOOL_ADMIN v OPVIEW_USER For example, set:
role.IMPACT_USER.user=admin role.NETCOOL_ADMIN.user=admin role.OPVIEW_USER.user=admin
4. Save the guiserver.setting file and close it. 5. Edit the installed GUI Server deployment and map the roles to the specified users. Note: Make sure that the application server is running while doing these steps. a. Go to the $NCHOME/etc/tivoli-vmm4ncos/bin directory. b. Run the ./update-impact-roles.[bat|sh] script. c. Check the SystemOut.log file to validate the steps.
Configuring LDAP or Active Directory

After the installation, you can configure an LDAP server through the administrative console.
Before you begin

If you want all LDAP communications to be encrypted, you can specify SSL communications. If so, be sure to import the LDAP signers certificate into the trust store of the embedded version of WebSphere Application Server before starting this task.
About this task

Follow these instructions to configure the embedded version of WebSphere Application Server to communicate over a secure (SSL) channel with an external repository such as Microsoft Active Directory. All application server instances must be configured for the LDAP server. 1. Log in to the administrative console.
http://host:adminport/ibm/console
where hostname is the name of the system where the application server is running and port is the admin port. The default port is 9060. The application server console prompts you for login information. The default administration username is wasadmin and the default password is netcool. 2. If you need to add a new LDAP repository, complete the following steps from the administrative console. a. In the navigation pane, select Security Secure administration, applications, and infrastructure. b. From the available realm definitions, select Federated repositories and then click Configure. c. Under Related Items click Manage repositories. To add a new LDAP Repository, click Add.
87
d. Enter the LDAP security setting information. The primary host name and the distinguished name must contain no spaces. e. If all LDAP communications should be encrypted, select Require SSL communications. If users authenticate to a Microsoft Active Directory Server, select this to enable password changes and creating users from the administrative console. f. Select Centrally managed. g. Click OK. 3. Return to Secure administration, applications, and infrastructure Federated repositories and add an entry to the base realm: a. Click Add Base entry to Realm. b. Enter the distinguished name (DN) of a base entry that uniquely identifies this set of entries in the realm. This base entry must uniquely identify the external repository in the realm. c. Click OK. If multiple repositories are included in the realm, use the DN field to define an additional distinguished name that uniquely identifies this set of entries within the realm. For example, repositories LDAP1 and LDAP2 might both use o=ibm,c=us as the base entry in the repository. So o=ibm,c=us is used for LDAP1 and o=ibm2,c=us for LDAP2. The specified DN in this field maps to the LDAP DN of the base entry within the repository (such as o=ibm,c=us b). The base entry indicates the starting point for searches in this LDAP directory server (such as o=ibm,c=us c). 4. Restart the server to enable the configuration. 5. To verify that the federated repository is properly configured, complete the following steps: a. In the navigation pane, click Users and Groups Manage Users. b. From the Search by list, select User ID. c. Click Search to search Users in federated repository. This list should display users from both LDAP and the local file registry. 6. If you want to create a user in LDAP, click Users and Groups Manage Users, and then click Create and continue as for the previous step: Enter user ID, first name, last name, email, and password. 7. For the changes to take effect, save, stop, and restart the embedded version of the WebSphere Application Server.
What to do next
To start using the LDAP server just configured for authentication and authorization, you need to configure the embedded version of the WebSphere Application Server so that it can map the roles that the application exposes to groups and/or users managed in LDAP according to the procedure in Mapping roles to groups and users managed in LDAP.
Mapping roles to groups and users managed in LDAP

To start using the LDAP server just configured for authentication and authorization, you need to configure the embedded version of WebSphere Application Server so that it can map the roles that the application exposes to groups and/or users managed in LDAP.
88
Before you begin

Before you begin, make sure that youve properly configured an LDAP repository and validated that you can search for users managed there.
About this task

Follow these instructions to configure the GUI Server application so that it recognizes entities stored in LDAP as valid users of the application. Make sure the application server is running while performing the following steps: 1. Go to the $NCHOME/etc/tivoli-vmm4ncos directory. 2. Open the guiserver.settings file in a text editor. 3. Complete the following steps to add roles to the GUI Server: a. Navigate to the ROLE SETTINGS section of the file. b. Add mapping(s) for some, or all, of the following roles: v IMPACT_USER v NETCOOL_ADMIN v OPVIEW_USER For example, set: v role.IMPACT_USER.user=<LDAP user> v role.NETCOOL_ADMIN.user=<LDAP user> v role.OPVIEW_USER.user=<LDAP user> 4. Save and close the guiserver.settings file. 5. Go to the $NCHOME/etc/tivoli-vmm4ncos/bin directory. 6. Run the ./update-impact-roles.[bat|sh] script. 7. Check the SystemOut.log file to validate the steps.
Results
After you complete these steps, you should be able to log in to the GUI Server with a user specified in the mapping steps above. | | | | | | | | | | | | | | | |
Setting up SSL communication with the Object Server

If the Object Server is already configured to run in SSL mode, you can use this procedure to set up the communication with the Object Server in SSL mode. 1. Log on to the following URL:
http://host:port/ibm/console
Use the port value as specified in the WC_adminhost attribute in the WAS_HOME/profiles/ImpactProfile/properties/portdef.props file. 2. Select the Security > SSL Certificate and key Management option. 3. Select Key stores and certificates and then click the NodeDefaultTrustStore option. 4. Click the Signer certificates link. 5. Copy the signed certificate file to the WAS_HOME/profiles/ImpactProfile/etc directory. 6. Click the Add button. 7. Click OK. You should see the certificate in the list.
89
| | | |
8. Make sure you saved all the changes and restart the embedded version of WebSphere Application Server.
Results
SSL connection with the Object Server should now work.
90
Chapter 11. Command-line tools

This chapter contains information about the Tivoli Netcool/Impact command-line tools.
nci_crypt
The nci_crypt tool encrypts a string using the Tivoli Netcool/Impact encryption algorithm. You can use this tool to encrypt passwords passed from the command line with nci_trigger. This tool is located in the $NCHOME/impact/bin directory. To run this tool, enter the following command at a command prompt:
$NCHOME/impact/bin/nci_crypt string
where string is the string you want to encrypt. Important: Enclose a string containing a space within double quotes (). Do not use single quotes () for they will be interpreted incorrectly by the nci_crypt tool.
nci_export
The nci_export tool exports data source, data type, service, policy, and project information from an instance of the Impact Server to a specified directory. This tool is located in the $NCHOME/impact/bin directory. Note: Make sure that the instance of the Impact Server that contains the data you are exporting is running before you use nci_export. Run the script using the following syntax:
$NCHOME/impact/bin/nci_export arguments options
Arguments
server name The name of the server instance whose data you want to export. directory The directory where you want to store the exported data. - - project This option is followed by the name of the project whose data you want to export. Use this option to export a single project.
Examples
Use this command to export all data from the NCI instance to the /tmp/NCI_export directory:
./nci_export NCI /tmp/NCI_export
Use this command to export the data from the F00 project only on the NCI instance to the /tmp/NCI_export directory:
./nci_export NCI --project F00 /tmp/NCI_export
91
nci_import
The nci_import tool imports data that was previously exported from an instance of the Impact Server. This data includes all data sources, data types, policies, and services currently defined in the server instance. This tool is located in the $NCHOME/impact/bin directory. Note: Make sure that the target instance of the Impact Server is running before you use nci_import. To run this tool, enter the following at a command prompt:
$NCHOME/impact/bin/nci_import server_name directory
where server_name is the name of the server instance where you want to import the data and directory is the location that contains data exported using nci_export. If Tivoli Netcool/Impact is running in a cluster setup, it is recommended to shutdown all secondary servers and have only primary server running before running nci_import. Once nci_import is completed successfully and there are no locks in the primary, the secondary servers can be started and they will replicate the configuration from the primary.
nci_trigger
The nci_trigger tool allows you to start a policy from the command line. This tool is located in the $NCHOME/impact/bin directory. To run this tool, enter the following at a command prompt:
$NCHOME/impact/bin/nci_trigger [-version] | server_name [ user_id | user_id/password | -e/user_id/encrypted_password | NULL ] policy_name field value field value ...
Note: If no password is defined for the user, you must specify the password as NULL when you execute the command. These are the command line arguments for nci_trigger: -version Causes nci_trigger to print the Tivoli Netcool/Impact version number, platform, and command syntax to standard output and then exit. server_name Instance of the Impact Server where you want the policy to run. user_id/password (UNIX platforms only) Username and password of a valid user who has access to Tivoli Netcool/Impact. user_id password (Windows platforms only) Username and password of a valid Netcool user who has access to Tivoli Netcool/Impact. -e/user_id/encrypted_password (UNIX platforms only) Username and encrypted password of a valid Netcool user who has access to Tivoli Netcool/Impact. You can encrypt passwords using the nci_crypt tool.
92
-e user_id encrypted_password (Windows platforms only) Username and encrypted password of a valid Netcool user who has access to Tivoli Netcool/Impact. You can encrypt passwords using the nci_crypt tool. policy_name Name of the policy to run. field value Name of a field in the event container passed to the policy. Optional. Value of a field in the event container passed to the policy. Optional.
Note: If you want to run a policy that contains a call to the ReturnEvent function, you must include Identifier and Serial fields in the event container passed to policy.
Runtime parameters
If you are using nci_trigger to pass runtime parameters to a policy, you must make sure that you specify the parameters as variables in the policy using the @ notation. The following example shows how to use this notation in a policy. In this example, the policy is named POLICY_01
Log(@Value1); Log(@Value2);
To run this policy using nci_trigger, you can enter the following at a command prompt:
nci_trigger admin/netcool POLICY_01 Value1 Testing1 Value2 Testing2
This prints the following to the policy log:

Testing1 Testing2
UNIX Examples
This example shows how to run a simple policy from the command line that does not process an incoming event. In this example, the policy is named POLICY_01, the user is admin, the password is netcool and the server instance is NCI.
nci_trigger NCI admin/netcool POLICY_01
This example shows how to run a policy using an encrypted password. In this example, the password was previously encrypted using the nci_crypt tool.
nci_trigger NCI_02 -e/admin/7E6C7364EFD7CD69 POLICY_02
This example shows how to run a policy and pass event field values to the policy as the contents of an incoming event container.
nci_trigger NCI admin/netcool POLICY_03 Node host_01 Summary Node_down AlertKey host_01Node_down
Windows Examples
This example shows how to run a simple policy from the command line that does not process an incoming event. In this example, the policy is named POLICY_01, the user is admin, the password is netcool and the server instance is NCI.
nci_trigger NCI admin netcool POLICY_01
93
This example shows how to run a policy using an encrypted password. In this example, the password was previously encrypted using the nci_crypt tool.
nci_trigger NCI_02 -e admin 7E6C7364EFD7CD69 POLICY_02
This example shows how to run a policy and pass event field values to the policy as the contents of an incoming event container.
nci_trigger NCI admin netcool POLICY_03 Node host_01 Summary Node_down AlertKey host_01Node_down
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
nci_policy
Purpose
You use the nci_policy script to do various command line tasks with your policies, for example to check the syntax of a policy that you created in an editor other than the integrated policy editor. Like other command line scripts it is located in the $NCHOME/bin directory.
Syntax
nci_policy [SERVER_NAME] [COMMAND] [ARGUMENTS]
Parameters
SERVER_NAME Name of the Impact Server instance. COMMAND Unless you use the --help or --h option, one of the following commands must be present: v syntax - This command is used to check the syntax of a policy. It requires arguments. v push - This command is used to upload or update a policy. It requires arguments. ARGUMENTS Arguments to use with the syntax or push command.
Example
Use this command to check the syntax of the policy.ipl policy on the NCI1 server instance:
nci_policy NCI1 syntax /path/to/policy.ipl
Use this command to upload the policy.ipl policy to project MyProject on the NCI1 server instance:
nci_policy NCI1 push user password /path/to/policy.ipl -project MyProject
Replace the user and password with the values that you use to log on to the server instance.
Using command line manager

The command line manager service tool allows you to access the Impact Server from the command line interface to start and stop services as well as configure their parameters.
94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
About this task

To configure the command line manager service, you specify the port to which you will be connecting to it. You can also specify whether you want the service to start automatically when the Impact Server starts. Follow this procedure to connect to the command line manager. 1. Start the command-line interface by opening the following address in any telnet application:
telnet <hostname> <commandlineport>
where hostname is the name of the system where the Impact Server is running and port is the command line port. The default port is 2000 (as specified during the installation). You can find the port number that is currently used by the Command Line Service by checking its configuration in the Command Line Manager service (it is stored in the configuration file $NCHOME/impact/etc/ <servername>_commandlinemanager.props). For more information on configuring the service, see Command Line Manager service in the User Interface Guide. 2. When prompted for the user name and password use the same user name and password as you would use to log on in the GUI. The default user name and password are admin and netcool.
Results
After you have logged into the command line service, you can work with services using specialized commands.
Example
You can use certain commands with all services. For example, to check if a service is running, you can use the following command:
Select Running from Service where Name = '<servicename>';
So for OMNIbusEventReader, it would be Select Running from Service where Name = 'OMNIbusEventReader';. Below are a few more examples of the commands that you can use with all services: v Select Standby from Service where Name = '<servicename>'; - use this command to check if the service is in standby mode (applicable to secondary members in a cluster). v Select Status from Service where Name = '<servicename>'; - this command returns the current status of the service. v Select Log from Service where Name = '<servicename>'; - use this command to display the log message for the service. You can start and stop a service from the command line. Note, that this is not applicable to all services since you cannot stop some services, like, for example, the Command Line Manager and Policy Logger service. Use the following command to stop a service:
Update Service set Running = FALSE where Name = '<servicename>';
To start a service use this command:

Update Service set Running= TRUE where Name = '<servicename>';
A service specific command, for example, would be:

95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Update Service set EnableMemoryStatus=true where Name='SelfMonitoring';
Issue this command to enable memory monitoring.
What to do next
If you change the port number in the primary server in a cluster, it does not affect the port where the secondary server is running. Change these settings on the secondary server using the GUI.
Event Processor commands

The event processor is the service responsible for managing events coming into Tivoli Netcool/Impact. You can use the following commands in the command line interface to work with the event processor service: Select NumEventsInQueue from Service where Name=EventProcessor; Gets the number of events in the queue. Select Events from Service where Name=EventProcessor; Gets the events waiting to be processed. Select ProcessingStatusHistory from Service where Name=EventProcessor; Gets the processing status history. Update Service set ClearQueue=true where Name=EventProcessor; Clears the event queue. Select NumThreads from Service where Name=EventProcessor; Gets the number of processing threads. Update Service set NumThreads=<numthreads> where Name=EventProcessor; Sets the number of processing threads. For example: Update Service set NumThreads=4 where Name='EventProcessor'; Select MinNumThreads from Service where Name=EventProcessor; Gets the minimum number of processing threads. This command is specific to release 5.1. Update Service set MinNumThreads = <minnumthreads> where Name=EventProcessor; Sets the minimum number of processing threads. For example: Update Service set MinNumThreads = 10 where Name = 'EventProcessor'; This command is specific to release 5.1. Update Service set MaxNumThreads =< maxnumthreads> where Name=EventProcessor; Sets the maximum number of processing threads. For example: Update Service set MaxNumThreads = 50 where Name = 'EventProcessor'; This command is specific to release 5.1. Update Service set MaximumThroughput = True where Name = EventProcessor; Sets up the service to achieve maximum throughput. This command is specific to release 5.1. Update Service set SaveTuningConfig = True where Name = EventProcessor; Saves the tuned configuration for the next restart. This command is specific to release 5.1.
96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Select NumEventsPerQuery from Service where Name=EventProcessor; Gets the block size of the events fetched. This command is specific to releases prior to 5.1. Update Service set NumEventsPerQuery=<num> where Name=EventProcessor; Sets the block size of the events fetched. For example: Update Service set NumEventsPerQuery=20 where Name='EventProcessor'; This command is specific to releases prior to 5.1. Select EventFetchRate from Service where Name=EventProcessor; Gets the interval at which the service asks for events. This command is specific to releases prior to 5.1. Update Service set EventFetchRate=<rate-in-milliseconds> where Name=EventProcessor; Sets the interval at which the service asks for events. For example: Update Service set EventFetchRate=5000 where Name='EventProcessor'; This command is specific to releases prior to 5.1. For more information on the Event Processor see Event processor service in the User Interface Guide. For more information on the command line interface, see Using command line manager on page 94.
Email Reader commands

The e-mail reader service polls a specified POP host for e-mail messages. It reads e-mail from a mailbox at intervals that you define when you create an e-mail reader service. This service is commonly used in escalation and notification policies to look for responses to e-mail notifications sent out by Tivoli Netcool/Impact. You can use the following commands in the command line interface to work with the e-mail reader service: Select POPHost from Service where Name=DefaultEmailReader; Gets the POP host. Update Service set POPHost=<pophost> where Name=DefaultEmailReader; Sets the POP host. Select UserName from Service where Name=DefaultEmailReader; Gets the user name. Update Service set UserName=<new_user_name> where Name=DefaultEmailReader; Sets the user name. Select PollInterval from Service where Name=DefaultEmailReader; Gets the poll interval. Update Service set PollInterval=<newpollinterval> where Name=DefaultEmailReader; Sets the poll interval. Select Policy from Service where Name=DefaultEmailReader; Gets the policy name. Update Service set Policy=<policyname> where Name=DefaultEmailReader; Sets the policy to which e-mails are to be sent. For the sake of examples, it is assumed that the name of the Email Reader instance is DefaultEmailReader. Change the syntax if the name of the instance is different.
97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Email Sender commands

The e-mail sender service lets you configure the local Tivoli Netcool/Impact e-mail address information so that you can send e-mail notification to users and to other installations of Tivoli Netcool/Impact. You can use the following commands in the command line interface to work with the e-mail sender service: Select SMTPHost from Service where Name=EmailSender; Get the SMTP host. Update Service set SMTPHost=<smtphost> where Name=EmailSender; Sets the SMTP host. Select SenderAddress from Service where Name=EmailSender; Gets the sender address. Update Service set SenderAddress=senderaddress where Name=EmailSender; Sets the sender address.
Policy Activator commands

The policy activator service activates policies at the intervals you specify for each policy selected. You can use the following commands in the command line interface to work with the policy activator service: Select Interval from Service where Name=DefaultPolicyActivtor; Gets the interval at which the policy is activated. Update Service set Interval=<interval> where Name=DefaultPolicyActivator; Sets the interval at which the policy is activated. Select Policy from Service where Name=DefaultPolicyActivator; Gets the policy which this service triggers. Update Service set Policy=policyname where Name=DefautPolicyActivator; Sets the policy that will be activated. For the sake of examples, it is assumed that the name of the service instance is DefaultPolicyActivator.
Hibernating Policy Activator commands

The hibernating policy activator is the service that is responsible for waking hibernating policies. You can use the following commands in the command line interface to work with the hibernating policy activator service: Select Interval from Service where Name=HibernatingPolicyActivtor; Gets the interval at which the policy is activated. Update Service set Interval=<interval> where Name=HibernatingPolicyActivator; Sets the interval at which the policy is activated. Select WakeProcessImmediately from Service where Name=HibernatingPolicyActivator; Gets the status of the WakeProcessImmediately flag. Update Service set WakeProcessImmediately=true where Name=HibernatingPolicyActivator Enables the WakeProcessImmediately flag.
98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Update Service set WakeProcessImmediately=false where Name=HibernatingPolicyActivator; Disables the WakeProcessImmediately flag. Update Service set ClearHibernations=true where Name=HibernatingPolicyActivator; Clears the hibernations.
Corba Name commands

The CORBA Name service is used by the CORBA Mediator DSAs to allow communication between Tivoli Netcool/Impact and the external application. You can use the following commands in the command line interface to work with the Corba name service: Select Port from Service where Name=CorbaNameService; Gets the port number. Update Service set Port=<new_port> where Name=CorbaNameService; Changes the port number.
Policy Logger commands

The policy logger service is responsible for managing the policy log. The log is a text stream used to record messages generated during the runtime of a policy. You can use the following commands in the command line interface to work with the policy logger service: Select ErrorHandlingPolicy from Service where Name=PolicyLogger; Gets the error handling policy. Update Service set ErrorHandlingPolicy=<policyname> where Name=PolicyLogger; Sets the error handling policy. Select LogLevel from Service where Name=PolicyLogger; Gets the LogLevel. Update Service set LogLevel=<loglevel> where Name=PolicyLogger; Sets the LogLevel. Select LogAllSQLStatements from Service where Name=PolicyLogger; Checks if the service logs all SQL statements. Update Service set LogAllSQLStatements=true where Name=PolicyLogger; Enables logging of all SQL statements. Update Service set LogAllSQLStatements=false where Name=PolicyLogger; Disables logging of all SQL statements. Select LogPreModuleParams from Service where Name=PolicyLogger; Checks if the service logs Pre-Execution Action Module parameters. Update Service set LogPreModuleParams=true where Name=PolicyLogger; Enables logging of Pre-Execution Action Module parameters. Update Service set LogPreModuleParams=false where Name=PolicyLogger; Disables logging of Pre-Execution Action Module parameters. Select LogPostModuleParams from Service where Name=PolicyLogger; Checks if the Service logs Post-Execution Action Module parameters.
99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Update Service set LogPostModuleParams=true where Name=PolicyLogger; Enables logging of Post-Execution Action Module parameters. Update Service set LogPostModuleParams=false where Name=PolicyLogger; Disables logging of Post-Execution Action Module parameters. Select LogAllModuleParams from Service where Name=PolicyLogger; Checks if the service logs all parameters. Update Service set LogAllModuleParams=true where Name=PolicyLogger; Enables logging of all parameters. Update Service set LogAllModuleParams=false where Name=PolicyLogger; Disables logging of all parameters. Select AppendThreadName from Service where Name=PolicyLogger; Checks if the service logs ThreadName to logs. Update Service set AppendThreadName=true where Name=PolicyLogger; Enables ThreadName logging. Update Service set AppendThreadName=false where Name=PolicyLogger; Disables ThreadName logging. Select AppendPolicyName from Service where Name=PolicyLogger; Checks if the service logs policy name to logs. Update Service set AppendPolicyName=true where Name=PolicyLogger; Enables policy name logging. Update Service set AppendPolicyName=false where Name=PolicyLogger; Disables policy name logging. Select CollectReports from Service where Name=PolicyLogger; Checks if the service reporting is enabled. Update Service set CollectReports=true where Name=PolicyLogger; Enables collecting of reports. Update Service set CollectReports=false where Name=PolicyLogger; Disables collecting of reports. Select PolicyProfiling from Service where Name=PolicyLogger; Checks if policy profiling is enabled. Update Service set PolicyProfiling=true where Name=PolicyLogger; Enables policy profiling. Update Service set PolicyProfiling=false where Name=PolicyLogger; Disables policy profiling.
OMNIbus Event Reader commands

The event reader service uses the host and port information of a specified Object Server data source so that it can connect to an Object Server to poll for new and updated events and store them in a queue. The event processor service requests events from the event reader. You can use the following commands in the command line interface to work with the OMNIbus event reader service: Update Service set ClearQueue=true where Name=OMNIbusEventReader; Clears the event reader queue. Select QueueSize from Service where Name=OMNIbusEventReader; Gets the queue size.
100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Update Service set ClearBuffer=true where Name=OMNIbusEventReader; Clears the event buffer. Select BufferSize from Service where Name=OMNIbusEventReader; Gets the buffer size. Update Service set ClearState=true where Name=OMNIbusEventReader; Clears the reader state. Select StatusEvents from Service where Name=OMNIbusEventReader; Checks if the service reads the status events inserted from the Self Monitoring Service. Update Service set StatusEvents=true where Name=OMNIbusEventReader; Enables reading of status events. Update Service set StatusEvents=false where Name=OMNIbusEventReader; Disables reading of status events. Select LockEvents from Service where Name=OMNIbusEventReader; Checks if event locking is enabled. Update Service set LockEvents=true where Name=OMNIbusEventReader; Enables event locking. Update Service set LockEvents=false where Name=OMNIbusEventReader; Disables event locking. Select LockingExpression from Service where Name=OMNIbusEventReader; Gets the event locking expression. Update Service set LockingExpression=<lockingexpression> where Name=OMNIbusEventReader; Sets the event locking expression. Select GetDeletes from Service where Name=OMNIbusEventReader; Checks if the service reads deleted events. Update Service set GetDeletes=true where Name=OMNIbusEventReader; Enables reading of deleted events. Update Service set GetDeletes=false where Name=OMNIbusEventReader; Disables reading of deleted events. Select PolicyForDeletes from Service where Name=OMNIbusEventReader; Gets the policy which gets triggered for deleted events. Update Service set PolicyForDeletes=<policyfordeletes> where Name=OMNIbusEventReader; Sets the policy where Deletes are sent. Select OrderByExpression from Service where Name=OMNIbusEventReader; Gets the OrderByExpression. Update Service set OrderByExpression=<orderbyexpression> where Name=OMNIbusEventReader; Sets the OrderByExpression. Select CollectReports from Service where Name=OMNIbusEventReader; Checks if collecting of reports is enabled. Select GetUpdates from Service where Name=OMNIbusEventReader; Checks if the Service is configured to get updates. Update Service set GetUpdates=true where Name=OMNIbusEventReader; Enables getting updates.
101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Update Service set GetUpdates=false where Name=OMNIbusEventReader; Disables getting updates. Select DataSource from Service where Name=OMNIbusEventReader; Gets the object server data source from which events are read. Update Service set DataSource=<datasourcename> where Name=OMNIbusEventReader; Sets the data source from which events are read. Select PollingInterval from Service where Name=OMNIbusEventReader; Gets the polling interval. Update Service set PollingInterval=<pollingintervalinmilliseconds> where Name=OMNIbusEventReader; Sets the polling interval. For example: Update Service set PollingInterval=4000 where Name='OMNIbusEventReader'; Select Fields from Service where Name=OMNIbusEventReader; Gets the fields used in select statements. Update Service set Fields=<fields> where Name=OMNIbusEventReader; Sets the fields used in select statements. Select ExecuteAllMatches from Service where Name=OMNIbusEventReader; Checks if the service sends the event to all the policies that pass the filter mapping evaluation. Update Service set ExecuteAllMatches=true where Name=OMNIbusEventReader; Sends the event to all the policies whose filter it matches. Update Service set ExecuteAllMatches=false where Name=OMNIbusEventReader; Sends the event to the first policy whose filter it matches. Select NumFilters from Service where Name=OMNIbusEventReader; Gets the number of filters. Update Service set NumFilters=<numfilters> where Name=OMNIbusEventReader; Sets the number of filters. Select FilterNum<num> from Service where Name=OMNIbusEventReader; Gets the information on a specific filter. For example, use the Select FilterNum1 from Service where Name='OMNIbusEventReader'; command to get the information for the first filter. The command will display the Policy, Restriction Filter and whether it is Active for that filter. Select PolicyNum<num> from Service where Name=OMNIbusEventReader; Gets the policy for a particular filter. Update Service set PolicyNum<num>=<policynum> where Name=OMNIbusEventReader; Sets the policy for a particular filter. Select ActiveNum<num> from Service where Name=OMNIbusEventReader; Checks if a particular filter is active. Update Service set ActiveNum<num>=true where Name=OMNIbusEventReader; Makes a particular filter active.
102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Update Service set ActiveNum<num>=false where Name=OMNIbusEventReader; Makes a particular filter inactive. Select RestrictionNum<num> from Service where Name=OMNIbusEventReader; Gets the restriction clause for a particular filter. Update Service set RestrictionNum<num>=<restriction> where Name=OMNIbusEventReader; Sets the restriction clause for a particular filter. For the sake of examples, it is assumed that the name of the Service is OMNIbusEventReader (this Service was called DefaultEventReader before Tivoli Netcool/Impact 5.1).
Database Event Reader commands

The database event reader was called the generic event reader in Tivoli Netcool/Impact versions 4.0.2 and earlier. This service polls an SQL data source at intervals and retrieves rows from a table. You can use the following commands in the command line interface to work with the database event reader service: Update Service set ClearQueue=true where Name=DatabaseEventReader; Clears the EventReader queue. Select QueueSize from Service where Name=DatabaseEventReader; Gets the queue size. Update Service set ClearBuffer=true where Name=DatabaseEventReader; Clears the event buffer. Select BufferSize from Service where Name=DatabaseEventReader; Gets the buffer size. Update Service set ClearState=true where Name=DatabaseEventReader; Clears the reader state. Select GetUpdates from Service where Name=DatabaseEventReader; Checks if a service is configured to get updates. Update Service set GetUpdates=true where Name=DatabaseEventReader; Enables getting updates. Update Service set GetUpdates=false where Name=DatabaseEventReader; Disables getting updates. Select DataSource from Service where Name=DatabaseEventReader; Gets the data source from which events are read. Update Service set DataSource=<datasourcename> where Name=DatabaseEventReader; Sets the data source from which events are read. Select PollingInterval from Service where Name=DatabaseEventReader; Gets the polling interval. Update Service set PollingInterval=<pollingintervalinmilliseconds> where Name=DatabaseEventReader; Sets the polling interval. For example: Update Service set PollingInterval=4000 where Name='DatabaseEventReader';
103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Select Fields from Service where Name=DatabaseEventReader; Gets the fields used in select statements. Update Service set Fields=<fields> where Name=DatabaseEventReader; Sets the fields used in select statements. Select ExecuteAllMatches from Service where Name=DatabaseEventReader; Checks if the service sends event to all the policies which pass the filter mapping evaluation. Update Service set ExecuteAllMatches=true where Name=DatabaseEventReader; Sends the event to all the policies whose filter it matches. Update Service set ExecuteAllMatches=false where Name=DatabaseEventReader; Sends the event to the first policy whose filter it matches. Select NumFilters from Service where Name=DatabaseEventReader; Gets the number of filters. Update Service set NumFilters=<numfilters> where Name=DatabaseEventReader; Sets the number of filters. Select FilterNum<num> from Service where Name=DatabaseEventReader; Gets information on a specific filter. For example, use the Select FilterNum1 from Service where Name='DatabaseEventReader'; command to see the information for the first filter. The command will output the Policy, Restriction Filter and whether it is Active for that filter. Select PolicyNum<num> from Service where Name=DatabaseEventReader; Gets the policy for a particular filter. Update Service set PolicyNum<num>=<policynum> where Name=DatabaseEventReader; Sets the policy for a particular filter. Select ActiveNum<num> from Service where Name=DatabaseEventReader; Checks if particular filter is active. Update Service set ActiveNum<num>=true where Name=DatabaseEventReader; Makes a particular filter active. Update Service set ActiveNum<num>=false where Name=DatabaseEventReader; Makes a particular filter inactive. Select RestrictionNum<num> from Service where Name=DatabaseEventReader; Gets the restriction clause for a particular filter. Update Service set RestrictionNum<num>=<restriction> where Name=DatabaseEventReader; Sets the restriction clause for a particular filter. Select DataType from Service where Name=DatabaseEventReader; Gets the data type from which events are read. Update Service set DataType=<datatypename> where Name=DatabaseEventReader; Sets the data type from which events are read.
104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Select KeyField from Service where Name=DatabaseEventReader; Gets the Key field used in this service. Update Service set KeyField=<ieldname> where Name=DatabaseEventReader; Sets the Key field. Select TimeStampField from Service where Name=DatabaseEventReader; Gets the TimeStamp field. Update Service set TimeStampField=<imestampfield> where Name=DatabaseEventReader; Sets the TimeStamp field. For the sake of examples, it is assumed that the name of the Service is DatabaseEventReader (this service was called GenericEventReader before Tivoli Netcool/Impact 5.1).
Database Event Listener commands

The database event listener service monitors an Oracle event source for new, updated, and deleted events. This service works only with Oracle databases. When the service receives the data, it evaluates the event against filters and policies specified for the service and sends the event to the matching policies. You can use the following commands in the command line interface to work with the database event listener service: Select QueueSize from Service where Name = DatabaseEventListener; Gets the current queue size. Update Service set ClearQueue=TRUE where Name = DatabaseEventListener; Clears the events in the queue.
JMS Message Listener commands

The JMS message listener service is a service that runs a policy in response to incoming messages sent by external JMS message providers. The message provider can be any other system or application that is capable of sending JMS messages. This section contains JMS message listener service commands that you can use in the command line interface to work with the JMS message listener service: For more information about the JMS Message Listener see JMS Message Listener service in the User Interface Guide. For more information about the command line interface, see Using command line manager on page 94. Note: The examples assume the name of the service to be JMSMessageListener.
Getting information about the service

Select Running from Service where Name=JMSMessageListener; Checks if the service is running. Select QueueSize from Service where Name=JMSMessageListener; Checks the queue size. Select Policy from Service where Name=JMSMessageListener; The policy triggered. Select DataSource from Service where Name = JMSMessageListener; Data source used.
105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Select JNDIFactory from Service where Name=JMSMessageListener Checks the JNDI Factory. Select ProviderURL from Service where Name=JMSMessageListener; Checks provider URL. Select URLPackage from Service where Name=JMSMessageListener; Checks URL package. Select ConnectionFactory from Service where Name=JMSMessageListener; Checks connection factory. Select Destination from Service where Name=JMSMessageListener; Checks the destination. Select MessageSelector from Service where Name=JMSMessageListener; Checks message selector. Select IsDurableSubscription from Service where Name=JMSMessageListener; Checks if durable subscription is used. Select ClientID from Service where Name=JMSMessageListener; Gets the client ID. Select SubscriptionName from Service where Name=JMSMessageListener; Checks subscription name. Select Username from Service where Name=JMSMessageListener; Checks user name.
Changing service configuration

Update Service set Running=true where Name=JMSMessageListener; Starts the listener service. Update Service set Running=false where Name=JMSMessageListener; Stops the listener service. Update Service set ClearQueue=true where Name=JMSMessageListener; Clears the message queue. Update Service set Policy=NewPolicy where Name=JMSMessageListener; Changes the policy triggered. Update Service set DataSource = NewDataSource where Name=JMSMessageListener; Changes the JMS data source used with service. Update Service set MessageSelector = NewMessageSelector where Name=JMSMessageListener; Changes the messages selector used by the listener. Update Service set DurableSubscription=true where Name=JMSMessageListener; Enables durable subscription. Update Service set DurableSubscription=false where Name=JMSMessageListener; Disables durable subscription. Update Service set ClientID = NewClientID where Name=JMSMessageListener; Sets the client ID.
106
| | | |
Update Service set SubscriptionName=NewName where Name=JMSMessageListener; Sets the subscription name.
107
108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Appendix A. Migrating from Security Manager to Virtual Member Manager

Use this procedure to migrate your role assignments from Security Manager 1.3/1.4 to Virtual Member Manager (VMM). 1. Unpack the migrationTool.zip file to a directory on the server where Security Manager was installed. 2. Set the NCHOME environment variable. Example: v UNIX platforms: export NCHOME=/opt/netcool v Windows platforms: set NCHOME=C:\netcool The security directory must be located in the NCHOME directory. 3. Run the export tool. v UNIX platforms: MigrationTool/bin/sm_migration_export.sh v Windows platforms: MigrationTool\bin\sm_migration_export.cmd If the operation is successful, there should be a data.zip file in the MigrationTool/output directory. 4. Unzip migrationTool.zip to a directory on the server where Tivoli Netcool/Impact was installed. 5. In the MigrationTool/etc/settings.properties file, update the impact.home property. The impact.home property must point to the Impact Server home directory. For example:
impact.home=/opt/IBM/netcool/impact51_1
6. Copy data.zip that was created in step 3 to the MigrationTool/output directory. 7. Set the TIPHOME environment variable. This will be your Impact Server home embedded version of WebSphere Application Server directory. v UNIX platforms: export TIPHOME=/opt/IBM/netcool/impact/eWAS v Windows platforms: set TIPHOME=C:\ibm\netcool\impact\eWAS 8. Run the import tool. Make sure that the Impact Server is up before running the import tool. v UNIX platforms: MigrationTool/bin/sm_migration_import.sh -migration v Windows platforms: MigrationTool\bin\sm_migration_import.cmd -migration The WSADMIN console will prompt you for the user name and password. Login as the user that has privileges to add users. 9. Run the following command to import roles: v UNIX platforms: IMPACT_HOME/etc/tivoli-vmm4ncos/bin/update-impactroles.sh v Windows platforms: IMPACT_HOME\etc\tivoli-vmm4ncos\bin\updateimpact-roles.bat
WARNING: Error occurred while adding user: admin. Possible reasons: the server is down or "admin" already exists. Please check wsadmin.traceout for errors.
109
| | | | | | | | | | | | | | | | | | | |
This message, if displayed when you run the import tool means that the admin account cannot be added because it already exists. The import continues despite this warning.
What to do next
The output from running WSADMIN by the import tool is written to the MigrationTool/log/add-users.log file. The wsadmin.traceout file is in the TIPHOME/profiles/<impactprofile>/logs directory. This is where the WSADMIN output is written to. You can roll back the changes, by running the following command: v UNIX platforms: MigrationTool/bin/sm_migration_import.sh -rollback v Windows platforms: MigrationTool\bin\sm_migration_import.cmd -rollback Note: Running this command only restores the guiserver.settings file but it does not delete the users that were added in the WSADMIN console. You can delete the users that were added by the import tool. Log on to the embedded version of WebSphere Application Server console, go to the Users and Groups Manage Users menu. Now you can remove the added users. If you already ran the update-impact-roles.sh script, the changes done by this script are not rolled back.
110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Appendix B. Migrating Tivoli Netcool/Impact from releases before 5.1 to 5.1.1

Before performing the upgrade or migration procedure make sure that the following preconditions are met: v Legacy Impact server is running. v New 5.1 Impact server is running and is not yet a member of an Impact cluster. We do not recommend or support importing configuration into an server that is a member of an Impact cluster. Importing into a single Impact instance is the only supported configuration at this time. After you have successfully completed the import into a single Impact 5.1 server, you can configure it to join an Impact cluster. The migration or upgrade process to an Impact 5.1 installation consists of mandatory and optional steps. The actual steps that you need to take will depend on the way you are currently using Impact. 1. Export existing Impact configuration and import into a new 5.1 installation. For more information, see Importing the existing configuration into 5.1 installation. 2. (Optional) Perform the security transition. For more information, see Performing the security transition on page 112. 3. (Optional) Migrate the reporting data. For more information, see Migrating the reporting data on page 112.
Importing the existing configuration into 5.1 installation

Because the Impact 5.1 installer does not provide a way to perform an upgrade from an existing Impact installation to 5.1 you have to perform a manual upgrade. The recommended workflow to accomplish this task is to first export the configuration from a legacy Impact install, and then perform an import into a 5.1 installation. 1. Navigate to the $IMPACT_HOME/bin directory of the legacy Impact installation. 2. Run the nci_export script. Make sure you provide the required options, for example:
./nci_export NCI /export_directory
3. Navigate to the $IMPACT_HOME/bin directory of the 5.1 Impact installation. 4. Run the nci_import script. Make sure you provide the required options, for example:
./nci_import NCI /export_directory
Note: The encryption algorithm in 5.1 has been changed from Blowfish to AES. Every effort was made to ensure that this transition was as seamless for the user as possible, which means that the export and import process just described, makes every possible accommodation for maintaining password accuracy. However, there is one service where the password is corrupted upon import into the 5.1 server, and that is the JabberService. After completing an import of the
111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
JabberService configuration from a legacy Impact server, you have to re-encrypt the passwords. The most straightforward way to accomplish this is to simply open the service within the Impact GUI, re-enter the password(s), and save the service.
Performing the security transition

If you use use the Netcool Security Manager with either the Netcool ObjectServer or an LDAP server, perform one of the steps of this procedure. 1. Security transition on the ObjectServer. If you use the Netcool Object Server as an external authentication and authorization source for the Netcool Security Manager, you have to take an additional step in order to get Impact 5.1 to properly recognize specific OMNIbus users as valid users of the Impact application. a. Install the VMM ObjectServer adapter (VMM4NCOS) as per the instructions in the Administration Guide. b. Use the Security Manager Migration tool to update application role assignments in Impact 5.1. Extract the MigrationTool.zip archive located under the /migration directory on the installation DVDs, and download images. Then follow the Readme file included with the tool. 2. Security transition on the LDAP server. If you use an external LDAP Server for an authentication and authorization source for the Netcool Security Manager, you have to take an additional step in order to get Impact 5.1 to properly recognize specific LDAP users as valid users of the Impact application. To do that configure the VMM LDAP integration as per the instructions found in the Administration Guide.
Migrating the reporting data

The Impact 5.1 installer does not provide a way to perform an upgrade from an existing Impact reporting database to 5.1. If you wish to migrate existing reporting information, adhere to the following workflow: 1. Set the PGUSER environment variable to postgres. You can issue the following command:
export PGUSER=postgres
2. Navigate to the $IMPACT_HOME/bin directory of the legacy Impact installation. 3. Run the nci_db backup script. This will create a backup sql in the $IMPACT_HOME/tmp directory. 4. Run the following command with the created impact backup sql:
cat $IMPACT_HOME/tmp/impact_db_backup_<timestamp>.sql | \ grep INSERT | \ grep -v "INSERT INTO process" | \ grep -v "INSERT INTO rep_severity_types" > <impact 5.1 dir>/tmp/impact_backup.sql
5. Open the impact_backup.sql file that you have just created in a text editor and add the COMMIT; text to the end of the file on its own line. 6. Import the information into the HSQL database in the Impact 5.1 installation by running the following command from the $IMPACT_HOME/bin directory:
nci_db connect <IMPACT SERVER NAME> <DATABASE PORT> \ -sqlfile $IMPACT_HOME/tmp/impact_backup.sql
Example of such a command:

nci_db connect NCI 5435 -sqlfile /opt/ibm/netcool/tmp/impact_backup.sql
112
Appendix C. Accessibility
Accessibility features help a user who has a physical disability, such as restricted mobility or limited vision, to use software products successfully. These are the major accessibility features you can use with Netcool/Impact when accessing it on the IBM Personal Communications terminal emulator: v You can operate all features using the keyboard instead of the mouse. v You can read text through interaction with assistive technology. v You can use system settings for font, size, and color for all user interface controls. v You can magnify what is displayed on your screen. For more information about viewing PDFs from Adobe, go to the following web site: http://www.adobe.com/enterprise/accessibility/main.html
113
114
Appendix D. Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 3-2-12, Roppongi, Minato-ku, Tokyo 106-8711 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
115
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBMs future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBMs suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to
116
IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBMs application programming interfaces. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml. Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both. Cell Broadband Engine and Cell/B.E. are trademarks of Sony Computer Entertainment, Inc., in the United States, other countries, or both and is used under license therefrom. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Appendix D. Notices
117
Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others.
118
Glossary of terms
Action function: An action function is a built-in IPL function that performs a high-level task such as retrieving data from a data source or sending e-mail. Action functions are pre-defined by the IPL and cannot be modified or extended when you write a policy. Assignment operator: The assignment operator is a built-in IPL function that assigns a value to a variable. The assignment operator is =. Boolean operator: A boolean operator is a built-in IPL function that specifies a logical operation of AND, OR or NOT when Netcool/Impact evaluates sets of operations. The boolean operators are &&, || and !. Command execution manager: The command execution manager is the Netcool/Impact service that manages remote command execution via the CommandResponse function in the IPL. Command line manager: The command line manager is the service that manages the Netcool/Impact command line interface. Comparison operator: A comparison operator is a built-in IPL function that Netcool/Impact uses to compare two values. The comparison operators are ==, !=, <, >, <= and >=. Control structure: A control structure is a statement block in the IPL that is executed when the terms of the control condition are satisfied. The IPL supports If ... Then ... Else and When control structures. CORBA name service: The CORBA name service is the Netcool/Impact service that provides CORBA naming functionality for mediator DSAs. Data item: A data item is an element of a Netcool/Impact data model that represents an actual unit of data stored in a data source (for example, a row in relational database table). Data model: A data model is an abstract representation of the business data and meta data used in a Netcool/Impact installation. A data model contains data sources, data types, links and event sources. Data source: A data source is an element of a Netcool/Impact data model that represents an external source of data (for example, a relational database). Data source adaptor: A data source adaptor (DSA) is a component of Netcool/Impact that allows the application to access data stored in an external source of data. Data type: A data type is an element of a Netcool/Impact data model that represents a set of data stored in a data source (for example, a table or view in a relational database).
119
Database event reader: A database event reader is an event reader that monitors an SQL database event source for new and/or modified events and triggers policies based on the event information. Database event listener: A database event listener is a Netcool/Impact service that listens for incoming messages from an Oracle Event Source and then triggers policies based on the incoming message data. DSA: See data source adaptor. Dynamic link: A dynamic link is an element of a Netcool/Impact data model that represents a dynamic relationship between data items in data types. E-mail reader: An e-mail reader is a Netcool/Impact service that polls a POP mail server at intervals for incoming e-mail and then triggers policies based on the incoming e-mail data. E-mail sender: An e-mail sender is a Netcool/Impact service that sends e-mail via an SMTP mail server. Event: An event is a set of data that represents a status condition or an activity that has occurred in your environment. Most commonly, events originate with Netcool probes and monitors and are stored in the Netcool/OMNIbus ObjectServer database. Event processor: The event processor is the service responsible for managing events coming into Netcool/Impact via event reader, event listener and JMS Message Listener. The event processor manages the incoming event queue and is responsible for sending queued events to the policy engine for processing. Event reader: An event reader is a Netcool/Impact service that monitors an event source for new, updated and/or deleted events and triggers policies based on the event data. See standard event reader and database event reader. Event source: An event source is a data source that stores and manages events. Most commonly, the event source used by Netcool/Impact is the ObjectServer database. embedded version of WebSphere Application Server, eWAS: the default Java application server used by Tivoli Netcool/Impact. For more information about eWAS, visit http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp. Exception: An exception an occurrence during runtime that changes the normal flow of policy execution. Field: A field is a single named unit of data in a Netcool/Impact event or data item. Filter: A filter is an expression that Netcool/Impact uses to select data (for example, data items in a data type) from a larger set of data. See SQL filter, LDAP filter and Mediator filter. Function: A function is a named set of instructions in the IPL that accepts certain pre-defined input parameters and optionally returns a value or set of values. See action function, parser function and user-defined function.
120
Generic event listener: A generic event listener is a Netcool/Impact service that listens to an external data source for incoming events and triggers policies based on the event data. GUI server: See Netcool/Impact GUI server. Hibernating policy activator: The hibernating policy activator is the Netcool/Impact service that is responsible for waking hibernating policies. IPL: See Netcool/Impact policy language. Jabber reader: A Jabber reader is a Netcool/Impact service that listens to external instant messaging servers for messages and triggers policies based on the incoming message data. Jabber service: The Jabber service is a Netcool/Impact service that sends instant messages to instant messaging clients like AOL Instant Messenger and Yahoo! Messenger via a Jabber server. JRExec server: See Netcool/Impact JRExec server. JMS DSA: The JMS DSA is a data source adaptor that allows Netcool/Impact to send and receive Java Message System (JMS) messages. Key field: A key field is a field that uniquely identifies a data item in a data type. Key expression: A key expression is an expression specify the value that one or more key fields in a data item must have in order to be retrieved by the GetByKey function in the IPL. LDAP DSA: The LDAP DSA is a data source adaptor that allows Netcool/Impact to read directory data managed by an LDAP server. LDAP filter: An LDAP filter is an expression that Netcool/Impact uses to select data elements located at a location in an LDAP directory tree. The syntax for LDAP filters is specified in Internet RFC 2254. Link: A link is an element of a Netcool/Impact data model that defines a relationship between data types and/or data items. See dynamic link and static link. Mathematic operator: A mathematic operator is a built-in IPL function that performs a mathematic operation on two values. The mathematic operators are +, -, *, / and %. Mediator DSAs: Mediator DSAs are a type of data source adaptor that allows Netcool/Impact to access data provided by third-party systems, devices and applications. NCHOME: NCHOME is an operating system environment variable that identifies the location of Netcool product installations on your file system. The default value for this variable is /opt/ibm/netcool. This variable is referenced as $NCHOME on UNIX platforms and %NCHOME% on Windows platforms.
Glossary of terms
121
Netcool database server: The Netcool database server is a specially configured version of HSQL that has been prepared for use with Netcool/Impact and other Netcool products. See Netcool/Impact database. Netcool/Impact database: The Netcool/Impact database is a HSQL database named Impact that is managed by the Netcool database server. This database stores reporting information used by the Netcool/Impact server. See Netcool database server. Netcool/Impact GUI server: The Netcool/Impact GUI server is the component of Netcool/Impact that serves the web-based graphical user interface to users web browsers via HTTP. Netcool/Impact JRExec server: The Netcool/Impact JRExec server is the component of Netcool/Impact that executes commands, scripts and applications triggered by the JRExecAction function in the IPL. Netcool/Impact server: The Netcool/Impact server is the primary component of Netcool/Impact. This component is responsible for maintaining the data model, managing services and running policies. Netcool/Impact policy language: The Netcool/Impact policy language (IPL) is the programming language that you use to write policies. Netcool/Impact ITNM DSA: (previously Netcool/Precision DSA) The Netcool/Impact ITNM DSA is a data source adaptor that is used for accessing data managed by the Netcool/Impact ITNM application. Operator: An operator is a built-in IPL function that assigns a value to a variable, performs an operation on a value or specifies how two values are to be compared in a policy. See assignment operator, mathematic operators, comparison operators, boolean operators and string operators. OMNIbus Event Reader: An OMNIbus Event Reader is a Netcool/Impact service that monitors a Netcool/OMNIbus ObjectServer database for new, updated and/or deleted events and triggers policies based on the event data. Parser function: A parser function is a built-in IPL function that performs a low-level task such as converting numeric and date formats or extracting a substring from a string. Parser functions are pre-defined by the IPL and cannot be modified or extended when you write a policy. Policy: A policy is a set of rules and actions that Netcool/Impact is required to perform when certain events or status conditions occur in your environment. Policies are implemented using the IPL. Policy activator: A policy activator is a Netcool/Impact service that runs a specified policy at intervals that you define. Policy logger: The policy logger is the Netcool/Impact service that writes messages to the policy log. ITNM DSA: See Netcool/Impact ITNM DSA.
122
Precision event listener: The Precision event listener is a Netcool/Impact service that listens to the Netcool/Precision application for incoming messages and triggers policies based on the message data. Self-monitoring service: The self-monitoring service is a Netcool/Impact service that monitors Netcool/Impact for memory and other status conditions and reports them to the Netcool/OMNIbus ObjectServer as events. Service: A service is a runnable sub-component of Netcool/Impact that you control from within the Netcool/Impact GUI. SNMP DSA: The SNMP DSA is a data source adaptor that allows Netcool/Impact to set and retrieve management information stored by SNMP agents. It also allows Netcool/Impact to send SNMP traps and notifications to SNMP managers. Socket DSA: The Socket DSA is a data source adaptor that allows Netcool/Impact to exchange information with external applications using a socket server as the brokering agent. SQL database DSAs: SQL database DSAs are data source adaptors that allow Netcool/Impact to retrieve information from relational databases and other data sources that provide a public interface via JDBC (Java Database Connectivity). SQL database DSAs also allow Netcool/Impact to add, modify and delete information stored in these data sources. SQL filter: An SQL filter is an expression that Netcool/Impact uses to select rows in a database table. The syntax for the filter is similar to the contents of an SQL WHERE clause. Static link: A static link is an element of a Netcool/Impact data model that defines a static relationship between data items in internal data types. String operator: A string operator is a built-in IPL function that performs an operation on two strings. Netcool/Impact supports one string operator that you can use for string concatenation. The string concatenation operator is +. User-defined function: A user-defined function is a custom function that you use to organize code in a Netcool/Impact policy. Variable: A variable is an IPL keyword that represents a value or a set of values. Web services DSA: The web services DSA is a data source adapter that allows Netcool/Impact to exchange information with external applications that provide a web services API. XML DSA: The XML DSA is a data source adapter that allows Netcool/Impact to read XML data from strings and files and to read XML data from web servers over HTTP.
Glossary of terms
123
124
Index A
accessibility viii, 113 data source (continued) status monitoring commands 78 database backing up 62 connecting with the command line client 62 port 61 resetting 62 restoring 63 database event listener commands 105 database event reader commands 103 deployment components 1 configuring components 3 distributed 2 installing components 3 monitoring 35 overview 1 running components 4, 29 setting up 3 single-system 2 types 2 directory names notation xiii disability 113
G
GenericSQL 28 GUI Server clustering 41 components 39 configuring 86 configuring for SSL 85 enabling HTTPS 40 GUI engine 39 Name Server properties 49 overview 2, 39 redeployment 40 running 40
B
books see publications vii, viii
C
certificate management 84 CLI See command line interface clustering checking cluster status 47 cluster components 41, 42 cluster configuration properties 52 cluster status events 79 cluster status monitoring commands 81 command replication 43 disabling status monitoring 81 enabling status monitoring 80 event monitoring 42 event processing 43 failover 43 failure and recovery 44 log analysis 47 monitoring cluster status 79, 80 overview 41 primary server 41 process 42 runtime 43 secondary server 41 self-monitoring 67 setting up cluster 44 shutdown 43, 44 starting and stopping cluster members 47 startup 42, 43 status monitoring 78 command line client connecting to the database 62 command line interface 95 command line manager See command line interface conventions typeface xiii Corba Name commands 99 customer support xi
H
hibernating policy activator commands 98 hot redeployment 40 HTTPS 40
I
IBM Redbooks ix IBM Support Assistant ix Impact Server administration scripts 34 clustering 41 clustering process 42, 43 clustering properties 52 configuring for SSL 85 creating new instances 33 deleting an instance 36 log file 35 monitoring 35 Name Server properties 49 overview 2, 33 read-only mode 37 running server instances 34 ImpactDatabase stopping service 62, 63 importing data 92 installation logs 28 response file 25 script 86 using console mode 17 using GUI mode 6 using silent mode 23
E
EAR creating 40 education See Tivoli technical training email reader commands 97 email sender commands 98 embedded version of WebSphere Application Server 2 starting 38 stopping 37 encrypting a string 91 environment variables notation xiii event processor commands 96 configuring 48 event queue monitoring 73 eWAS See embedded version of WebSphere Application Server exporting data 91
J
JDBC 28 JMS message listener commands 105 JRExec server configuring 66 installing Windows service overview 65
D
data source disabling status monitoring 78 enabling status monitoring 78 status events 76, 77 status monitoring 76, 77, 78 Copyright IBM Corp. 2006, 2009
F
fixes obtaining x
28
125
JRExec server (continued) starting 65 stopping 65
O
Object Server 86 security 85 setting up SSL communication OMNIbus adapter 86 OMNIbus event reader commands 100 online publications accessing viii ordering publications viii 89
K
key management 84
L
LDAP configuring 87, 89 log netcool.log 35 service log 36 Log4j 35
P
path names notation xiii policy checking syntax 94 starting from command line policy activator commands 98 policy logger commands 99 post installation utility 30 problem determination and resolution xii problem resolution ix publications vii accessing online viii ordering viii
M
manuals see publications vii, viii mapping roles 86, 89 memory status monitoring 69, 70 checking if enabled 71 combined memory 70 commands 72, 73 disabling 72 enabling 71 JVM memory status 70 memory event fields 71 monitoring system memory 70 setting JVM size 69 system memory status 70 monitoring server instances 35 services 36
92
Q
queue size monitoring 73 checking if enabled 74 commands 75, 76 disabling 75 enabling 75 queue status event fields 74 queue status severity 73
N
Name Server 2 checking cluster status 47 cluster components 42 cluster configuration properties 50 clustering process 43, 44 configuring for SSL 85 configuring SSL 83 functions 39 properties file 50 Netcool Database Server managing 62 overview 2, 61 resetting the database 62 running 61 setting the database port 61 starting 62 stopping 62 viewing the database status 62 notation environment variables xiii path names xiii typeface xiii
R
read-only mode 37 Redbooks ix response file 25 RMI ports configuring 35
Security Manager See Virtual Member Manager self-monitoring cluster 67 cluster status monitoring 78 data source status monitoring 76 memory status monitoring 69 overview 67 queue size monitoring 73 running using GUI 68 running using the command line interface 68 setting the Object Server Data Source 69 setting up in GUI 68 starting on a secondary cluster member 79 server certificates 83, 84 server truststores 83, 84 service command line interface 95 Corba Name 99 database event listener 105 database event reader 103 email reader 97 email sender 98 event processor 48, 96 hibernating policy activator 98 JMS message listener 105 log 36 OMNIbus event reader 100 policy activator 98 policy logger 99 Software Support contacting xi overview ix receiving weekly updates x SSL 83, 84, 85, 87, 89 SSL keystore 83, 84 support assistant ix SVN archives removing 36 system requirements 5
T
Tivoli Information Center viii Tivoli technical training viii training Tivoli technical viii troubleshooting ix typeface conventions xiii
S
scripts administration scripts 34 install-vmm4ncos 86 nci_crypt 91 nci_cvs2svn 59 nci_export 91 nci_import 92 nci_jrexec 65 nci_policy 94 nci_trigger 92 nci_version_control 56, 57, 58 remove server 36 remove SVN archives 36 uninstaller 29
U
uninstalling GUI Server 29, 30 Impact Server 29, 30 update-roles 86 upgrading from version 5.1 to 5.1.1 6, 17, 23 from versions before 5.1 to 5.1.1 111
126
V
validating installation script 86 variables notation for xiii verifying the installation 27 version control adding files 57 checking in 55, 57 checking out 55, 57 configuring 56 creating a checkpoint 58 creating element 55 deleting element 55 overview 55, 59 renaming 55 script 56, 57, 58 unchecking out 58 updating the sandbox 58 Virtual Member Manager 109 adapter 85, 86 migrating to 109 VMM See Virtual Member Manager
Index
127
128
Printed in USA
SC23-8829-02

Net Cool Administration Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Net Cool Administration Guide

Uploaded by

Copyright:

Available Formats

Tivoli Netcool/Impact Version 5.1.

Tivoli Netcool/Impact Version 5.1.1

Chapter 4. Managing the GUI Server . . 39

Chapter 5. Server clustering . . . . . 41

Chapter 6. Version control . . . . . . 55

Chapter 3. Managing the Impact Server 33

Chapter 7. Netcool Database Server . . 61

Chapter 8. JRExec server. . . . . . . 65

Chapter 10. Secure communication in Tivoli Netcool/Impact . . . . . . . . 83

Chapter 11. Command-line tools . . . . 91

Netcool/Impact: Administration Guide

. 103 . 105 . 105

Performing the security transition Migrating the reporting data . .

Appendix D. Notices . . . . . . . . 115

Glossary of terms . . . . . . . . . 119 Index . . . . . . . . . . . . . . . 125

Netcool/Impact: Administration Guide

About this publication

Tivoli Netcool/Impact library

Accessing terminology online

Accessing publications online

Tivoli technical training

Netcool/Impact: Administration Guide

Support for problem solving

Using IBM Support Assistant

Receiving weekly support updates

Netcool/Impact: Administration Guide

Contacting IBM Software Support

Determining the business impact

Describing problems and gathering information

Netcool/Impact: Administration Guide

Conventions used in this publication

Operating system-dependent variables and paths

Netcool/Impact: Administration Guide

Netcool Database Server

Netcool/Impact: Administration Guide

Netcool/Impact: Administration Guide

Chapter 2. Installing Tivoli Netcool/Impact

32 bit/64 bit 32 bit/64 bit 32 bit/64 bit 32 bit 64 bit

Solaris HP/UX Windows

Copyright IBM Corp. 2006, 2009

Running the installer in GUI mode

About this task

Netcool/Impact: Administration Guide

Chapter 2. Installing Tivoli Netcool/Impact

Click Next to continue. 5. Read and accept the license agreement.

Netcool/Impact: Administration Guide

7. Choose the installation directory.

Chapter 2. Installing Tivoli Netcool/Impact

Netcool/Impact: Administration Guide

Netcool/Impact: Administration Guide

Chapter 2. Installing Tivoli Netcool/Impact

Netcool/Impact: Administration Guide

Chapter 2. Installing Tivoli Netcool/Impact

Click Done to leave the installation.

Netcool/Impact: Administration Guide

Running the installer in console mode

About this task

Chapter 2. Installing Tivoli Netcool/Impact

(Windows platforms) Use the following syntax to start the installation:

3. Choose the installation language.

CHOOSE LOCALE BY NUMBER:

Press Enter to continue. 5. Read and accept the license agreement.

Netcool/Impact: Administration Guide