Unicenter Service Desk Implementation Guide

Unicenter Service Desk

Implementation Guide

r11.2

Second Edition

W:None;F:

This documentation and any related computer software help programs (hereinafter referred to as the

“Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and protected by the copyright laws of the United States and international treaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the Documentation for their own internal use, and may make one copy of the related software as reasonably required for back-up and disaster recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy.

Only authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the Product are permitted to have access to such copies.

The right to print copies of the Documentation and to make a copy of the related software is limited to the period during which the applicable license for the Product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the

Documentation have been returned to CA or destroyed.

EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY

APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING

WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE

OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY

LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT

LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY

ADVISED OF SUCH LOSS OR DAMAGE.

The use of any product referenced in the Documentation is governed by the end user’s applicable license agreement.

The manufacturer of this Documentation is CA.

Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-

7014(b)(3), as applicable, or their successors.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Copyright © 2007 CA. All rights reserved.

CA Product References

This document references the following CA brands and products:

Advantage™

Allfusion

®

**

BrightStor

®

CA SupportBridge

Clarity**

CleverPath™ Portal eTrust

®

Embedded Identity and Access Management (eTrust eIAM)

Unicenter AutoSys Job Management

Unicenter

®

Asset Management

Unicenter

®

Asset Portfolio Management (APM)

Unicenter

®

Management Portal

Unicenter

®

Network and Systems Management (NSM)

Unicenter

®

Remote Control

Unicenter

®

Service Desk

Unicenter

®

Knowledge Tools (KT)

Unicenter

®

Software Delivery

Unicenter

®

TNG for Windows

**Note: Refer to the CA Change Management Integration Guide for instructions on integrating Clarity and Allfusion Harvest with Unicenter Service

Desk.

Contact Technical Support

For online technical assistance and a complete list of locations, primary service hours, and telephone numbers, contact Technical Support at

http://support.ca.com

.

Contents

Chapter 1: Introduction 9

What You Need to Know

......................................................................

10

Before You Start

..............................................................................

10

Implementation Type Descriptions

.........................................................

11

Primary Server Components

...............................................................

12

Primary or Secondary Server Components

..................................................

14

Installation Walkthroughs

.....................................................................

16

Server and MDB on Same Machine

.........................................................

16

Server and MDB on Different Machines

.....................................................

16

Custom Installation using SQL Database

....................................................

17

Custom Installation using Oracle Database

.................................................

17

Custom Installation with Web Interface

.....................................................

18

Custom Installation with NSM Integration

..................................................

19

Chapter 2: Install and Configure Unicenter Service Desk 21

Review System Requirements

.................................................................

21

Installation Procedures

........................................................................

21

Server Installation

........................................................................

22

Install Remote Components

...............................................................

37

Configure the Server

......................................................................

38

Web Interface Installation

.................................................................

52

Client Installation

.........................................................................

57

Modify the Current Installation

................................................................

64

Install Log

...................................................................................

64

Chapter 3: Get Started Using Unicenter Service Desk 65

Define the Business Structure

.................................................................

65

Sites

.....................................................................................

66

Locations

.................................................................................

66

Organizations

.............................................................................

67

Define the Business Infrastructure

.............................................................

67

Asset Families and Classes

................................................................

68

Manufacturer and Models

..................................................................

68

Service Statuses

..........................................................................

69

Vendor Types and Vendors

................................................................

69

Assets

...................................................................................

70

Contents 5

Set Up Users

.................................................................................

70

Define Contacts

...........................................................................

71

Organize Users into Groups

................................................................

73

Establish Contact Types

...................................................................

74

Chapter 4: Integrate Unicenter Service Desk with Other Products 75

CA Workflow Integration

......................................................................

75

Workflow Components

....................................................................

75

CA Workflow Access

.......................................................................

78

Unicenter NSM Integration

....................................................................

80

Before You Integrate

......................................................................

80

Integrate Unicenter Service Desk and Unicenter NSM

.......................................

81

Post Integration Process

...................................................................

82

Unicenter Service Desk Event Converter

...................................................

114

Leverage NSM to Unicenter Service Desk Integration

.......................................

115

Change Impact Analyzer Implementation

.....................................................

126

Unicenter Service Desk Change Impact Analyzer

...........................................

126

How the Change Impact Analyzer Works

..................................................

127

Change Impact Analyzer and WorldView

...................................................

128

Configure the Daemon

...................................................................

129

Change Impact Analyzer Integration Considerations

........................................

131

Test the Change Impact Analyzer Integration

..............................................

132

Set up Change Impact Analyzer Integration

...............................................

132

Create Change Impact Analyzer Relationships

.............................................

139

Portal Integration

............................................................................

149

Verify Unicenter Service Desk Web Interface Accessibility

..................................

150

Install and Start the Portal

...............................................................

150

Configure Unicenter Service Desk to Use SSL with Portal

...................................

152

Mainframe Product Integration

...............................................................

156

Load Unicenter Service Desk Side Data

....................................................

156

CA Products Currently Using CAISDI

......................................................

156

CA Products Planning to Use CAISDI

......................................................

157

Chapter 5: Migrate Data from Previous Versions 159

Before You Migrate

..........................................................................

160

Install r11.2 on a 6.0 System

.............................................................

160

Install r11.2 on a System without 6.0

.....................................................

161

Clean Up the Database

...................................................................

161

Migrate from a Case-Sensitive Database

...................................................

163

Run the Migration

...........................................................................

164

Migration Interview

......................................................................

165

6 Implementation Guide

Migration Process

........................................................................

166

Knowledge Tools Migration

...................................................................

167

Migrate From a Remote Machine

..........................................................

168

Stand-Alone Knowledge Tools Migration

...................................................

172

Knowledge Tools Migration Tips

...........................................................

173

Change Impact Analyzer Migration

............................................................

174

Post Migration Steps

.........................................................................

174

Register Assets

..........................................................................

175

Reset Web Director

......................................................................

175

Update Shared File Repositories

..........................................................

175

Improve Knowledge Tools Performance

....................................................

176

Edit Access Types

........................................................................

177

Forms

...................................................................................

177

Activity Notification Message Templates

...................................................

177

SITEMODS.JS File

........................................................................

179

Version Control File

......................................................................

179

Remove Duplicate Key Values

............................................................

180

Adjust Access Type and Data Partition Settings

............................................

181

Migration Considerations

.....................................................................

183

Install/Remove Migration Views

..............................................................

184

Customized HTMPL Files in Unicenter Service Desk 6.0

.........................................

185

Update Unicenter Service Desk r11.2 HTMPL Code

.........................................

187

Incompatible htmpl Files

.................................................................

188

Migration Errors

.............................................................................

189

Errors in Data Reset Phase

...............................................................

189

Appendix A: Samples Directory 193

Contents of the Samples Directory

............................................................

193 asset

....................................................................................

193 call_mgt

................................................................................

193

data

....................................................................................

195

FAXserve (Windows only)

................................................................

195

i18n

....................................................................................

196

macro_lock

..............................................................................

197

ntf_meth

................................................................................

198

pdmconf

................................................................................

199 sdk

.....................................................................................

199 sql

......................................................................................

199

views

...................................................................................

200

Contents 7

Appendix B: Import Knowledge Tools Sample Data 201

Customize Field Data

........................................................................

202

About the Sample Data

......................................................................

203

Index 205


Chapter 1: Introduction

Welcome to Unicenter Service Desk, an advanced service support tool that helps organizations like yours address the challenges of managing today’s complex service and support requirements. It provides a comprehensive and scalable service management solution that can function as a stand-alone product for your small business or departmental service desk, or integrated into a much larger enterprise business solution. Its technology is designed to reap maximum benefits for your investment and ensure that your service and support solution can grow as your requirements do.

Unicenter Service Desk is designed to support both employees dependent on the IT infrastructure and customers seeking support regarding purchased products and/or services. It features numerous out-of-the-box integrations with other CA infrastructure management products and is easily configured to support the ITIL model, leverage CA's collection of years of service support

Best Practices, or implement your own processes.

This guide provides instructions for installing and configuring the base components of Unicenter Service Desk, which support the Unicenter Service

Desk application, as well as the Unicenter Service Desk Knowledge Tools addon. It contains detailed instructions for migrating your existing system and data. Additionally, it outlines necessary considerations and steps for integrating the Unicenter Service Desk system with companion CA products.

This section contains the following topics:


(see page 10)

Before You Start

(see page 10)


(see page 16)

Introduction 9


What You Need to Know

This guide is intended primarily for system implementers, integrators, and administrators. Some sections of this guide will be helpful to system users as well.

To use the information in this guide, you need a working knowledge of

Windows and/or UNIX operating systems, depending upon your current production environment. You should also be able to perform basic administrative tasks for your operating system.

Depending on your working environment, you may also need to be familiar with mainframe, mobile devices, and server and client application installations.

Note: Throughout this guide, you will see references to NX_ROOT. The references pertain to the environmental variable containing the installation path of Unicenter Service Desk. This NX_ROOT variable is set in the NX.env configuration file that is used to set environmental variables for Unicenter

Service Desk.

For example:

@NX_ROOT=C:\Program Files\CA\Unicenter Service Desk

Before You Start

Following are key points to keep in mind when installing and implementing

Unicenter Service Desk:

There are different types of Unicenter Service Desk implementations. You need to consider network availability, usable bandwidth, and responsiveness when deciding on the appropriate type of implementation for your organization.

Note: Refer to Unicenter Service Desk Implementation Types for a description of the different types of implementations.

Understand the purpose of the components that run on a primary server, as listed in

Primary Server Components

(see page 12). This is important

for implementation planning.

Understand the purpose of the components that run on either a primary or

secondary server, as listed in

Primary or Secondary Server Components

(see page 14). This is also important for implementation planning.

You may also want to review the Implementation Best Practices

(

http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm

) document for additional help in setting up your Unicenter Service Desk implementation.


Before You Start

Implementation Type Descriptions

Centralized

Installs and configures all components on one primary server. This is the default installation of CA Service Desk. You can implement multiple Object

Managers and web engines for client load balancing and failover, but your business may outgrow this implementation.

Distributed

Installs components on servers that are closer to the clients receiving the service. For example, a branch location of a business that has a number of subnets may have many analysts using the CA Service Desk Web Client.

Placing a secondary server at this branch location reduces the network traffic and response times. Network traffic between the branch location and the primary server location is also reduced because the secondary server performs caching. This type of implementation allows the implementation of multiple Object Managers and web engines for client load balancing and failover.

Global

Consists of two or more centralized or distributed implementations known as regions. The primary server of a region replicates minimal information to and from a master region. This allows a single region to be given all necessary information about all other regions. This enables an analyst to be aware of tickets from all regions, but only connect to a region when required.

This type of implementation is useful when network bandwidth is too limited for a distributed implementation. For example, you may have business locations in different countries with a slow link between them.

Introduction 11

Before You Start

Primary Server Components

The following Unicenter Service Desk components run on a primary server:

Daemon Manager (pdm_d_mgr)

Starts process sets as defined in the startup file, pdm_startup.tpl. By default, the daemon manager tries to start a failed component up to 10 times. To check the status of all Unicenter Service Desk components, use the pdm_status utility. The pdm_d_refresh utility instructs the daemon manager to start a new cycle of 10 attempts to start any process marked as previously failed.

Message Dispatcher (sslump_nxd)

Acts as a common bus or message passing system. Components that need to communicate with each other first register with the Message Dispatcher.

When a component sends a message, the Message Dispatcher delivers it to those components that have registered to receive that type of message.

If two components communicate so much that it would be inefficient to pass the messages through the Message Dispatcher, they create a fast channel between them. You can view a list of registered components using the slstat utility.

Database Agent (platform_agent)

Performs SQL queries on the database. Database Agents adhere to the logical schema of Unicenter Service Desk and translate the SQL at this level to the physical database platform SQL.

Agent Provider (platform_prov_nxd)

Starts or stops database agents. By default, a number of agents are running. If more are required to handle the number of database queries, the Agent Provider starts them. If the system no longer requires so many database agents, the Agent Provider terminates the unnecessary ones.

Virtual Database (bpvirtdb_srvr)

Enables the operation of multiple Object Managers. All Object Managers running on primary or secondary servers connect to the Virtual Database, which arbitrates their access to database agents. For example, when retrieving a new range of ticket reference numbers, the Virtual Database helps ensure that only one Object Manager at a time accesses the table containing the reference numbers. The Virtual Database also performs caching of database information for Object Managers.

Continuous Archive and Purge (arcpur_srvr)

Runs your archive and purge rules as configured by the Unicenter Service

Desk administrator.

Database Monitor (dbmonitor_nxd)

Monitors changes to common tables in the CA-MDB, for example

ca_contact.


Before You Start

KPI Daemon (kpi_daemon)

Manages the retrieval, organization, and storage of KPI metric data. It runs continuously. When the specified refresh time of a KPI query is reached, the KPI daemon interacts with other system components to collect data, and then stores the resulting metrics in the database.

License Manager (license_nxd)

Manages CA licensing for the product.

Mail Daemon (pdm_mail_nxd)

Sends outbound email notifications.

Mail Eater (pdm_maileater_nxd)

Accepts inbound email for ticket creation and updates.

Notification Manager (bpnotify_nxd)

Manages notifications in a Windows environment.

Spell Checker (lexagent_nxd)

Performs spell checking as requested by clients.

Text API Daemon (pdm_text_nxd)

Creates and updates tickets by external interfaces, such as command line and email.

Timed Event (animator_nxd)

Runs the delay times of events. In an implementation that has many service types or contracts, there may be many active events that the

Timed Event engine needs to track. In this situation, you should dedicate the primary server Object Manager entirely to the Timed Event engine.

You can configure other Object Managers on the primary or secondary servers for client access as appropriate.

Time-To-Violation (ttv_nxd)

Calculates projected violation times for service types.

Introduction 13

Before You Start

Primary or Secondary Server Components

The following Unicenter Service Desk components run on a primary or a secondary server:

Proctor Daemon (pdm_proctor_nxd)

Starts and restarts (USDK) components, as instructed by the Daemon

Manager, on primary and secondary servers.

When you install a secondary server, the pdm_proctor_nxd process is installed as the Unicenter Service Desk Remote Daemon Proctor service.

When the primary server starts, the Daemon Manager instructs the

Remote Daemon Proctor to connect to the Message Dispatcher. The

Daemon Manager then instructs the Remote Daemon Proctor to start components on the secondary server as defined by Process Sets in the startup file pdm_startup.tpl.

Object Manager (domsrvr)

Acts as the server process of Unicenter Service Desk. When you install a primary server, by default, two Object Managers are installed: one for client connections and one dedicated to Web Screen Painter. This allows you to test your modifications without affecting the production environment. When you install a secondary server, you can configure additional Object Managers.

There must always be a default Object Manager running on the primary server to which clients such as the Timed Event engine can connect.

The Object Manager also caches various records and tables for clients. If you use pdm_userload to manipulate these records, you can also use the

pdm_cache_refresh utility to make the Object Manager retrieve the new data.

Method Engine (spel_srvr)

Runs SPEL code, event, macros, etc. for an Object Manager. It is recommended that every Object Manager be run with its own method engine.

Login Server (boplogin)

Performs operating system user account validation and contact record lookups using the System Login field to match a user with an access type.

If your business provides Unicenter Service Desk to other client businesses, you can place the Login server on a secondary server in those client locations. External authentication can then be enabled in access types. This avoids creating user accounts for your clients on your business systems.

LDAP Virtual Database (ldap_virtdb)

Interfaces with an LDAP directory.


Before You Start

Knowledge Tools/Keyword Search Daemon (bpebr_nxd)

Performs knowledge base searches.

Knowledge Tools/Keyword Search Indexing Daemon (bdeid_nxd)

Re-indexes the knowledge base.

Knowledge Tools FAQ Ratings Daemon (bu_daemon)

Calculates FAQ ratings for Knowledge Tools.

Knowledge Report Card Daemon (krc_daemon)

Manages calculations for the Knowledge Tools Knowledge Report Card

(KRC) feature. This feature enables analysts to see how their knowledge documents have been rated by users.

Knowledge Tools Daemon (kt_daemon)

Manages knowledge base administration, the approval, process, and notifications.

Multii-Site Support (pdm_global_nxd)

Performs replication between a region and the master region.

Repository Daemon (rep_daemon)

Manages the attachment repositories for Unicenter Service Desk and the

Knowledge Tools/Keyword Search Daemon.

Version Control Daemon (pdm_ver_nxd)

Synchronizes the schema files between a primary and secondary server to ensure that they are using the same schema.

Apache Tomcat Web Server (javaw)

Enables certain features to be implemented, regardless of whether

Microsoft Internet Information Server (IIS) is used as the web server for client access to Unicenter Service Desk. These features include CA

Workflow, Graph Items, Attachments, and Web Services.

The Apache Tomcat web server can be administered with the apache

Tomcat controller (pdm_tomcat_nxd).

Web Engine (webengine)

Connects to web browsers through a pdmweb cgi running on a Microsoft

IIS or Apache Tomcat web server. There must be a web engine for WSP on the primary server so WSP Schema Designer can write schema files. Web engines are the true client of an Object Manager for user client web browsers.

Web engines cache .htmpl web forms for connected users. You can manipulate the cache using the pdm_webcache utility and see client connection statistics using the pdm_webstat utility.

Introduction 15


Installation Walkthroughs

Use the following walkthroughs to help plan new Unicenter Service Desk installations:

Server and MDB on Same Machine

(see page 16)

Server and MDB on Different Machines

(see page 16)

Custom Installation using SQL Database

(see page 17)

Custom Installation using Oracle Database

(see page 17)

Custom Installation with Web Interface

(see page 18)

Custom Installation with NSM Integration

(see page 19)

Note: There are many other possible installation scenarios. These are provided only as samples to guide you in your own installation process.

Server and MDB on Same Machine

Perform the following tasks for an installation with the MDB and primary server on the same machine:

Task Reference

1 Perform typical server or custom server installation

2 Perform server configuration

Typical Server Installation

22) or

Custom Server Installation

(see page 27)

(see page


(see page 38)

Server and MDB on Different Machines

Perform the following tasks for an installation with the MDB and primary server on different machines:

Task Reference

1 Perform a typical or custom server installation

Typical Server Installation

(see page

22) or


(see page 27)

2 Install the remote Unicenter

Service Desk components

3 Configure the server

Install Remote Components

37)


(see page

(see page 38)



Custom Installation using SQL Database

Perform the following steps for a custom server installation using a SQL database:

Task Reference


(see

page 27)

1 Perform a custom server installation, selecting the MS/SQL

Interface component.

2 Configure the server. You will need the following information for the database:


and

(see page 45)

(see page 38)

MS SQL Database Configuration

Name of the SQL instance

Unicenter Service Desk should use for configuration

Database size

Database User ID

Database password

SQL listening port

Custom Installation using Oracle Database

Perform the following steps for a custom server installation using an Oracle database:

Task Reference

1 Perform a custom server installation, selecting the Oracle


Custom Server Installation (see

page 27)

Introduction 17


Task Reference

2 Configure the server. You will need to know the following information for the database:

Configure the Server (see page 38)

and Oracle Database Configuration

(see page 46)

Whether the database is local or remote

Whether tablesspaces need to be created

Net service name

DBA User name

DBA password

Data tablespace name

Index tablespace name

Tablespace path

JDBC connectivity information

System identifier

Listener port

Custom Installation with Web Interface

Perform the following steps for a custom server installation, with the Web

Interface component selected:

Task Reference

1 Perform a custom server installation, selecting the Web


Custom Server Installation (see page

27) and Install the Web Interface (see

page 53)

2 Configure the server.

3 Enable the web engine

4 Configure the web interface

5 Start the Unicenter Service Desk services


and Web Interface Field Definitions

(see page 48)

Enable Web Engine on Secondary

Server (see page 54)

Configure the Web Interface (see page

55)

Start Services (see page 55)



Custom Installation with NSM Integration

Perform the following steps for a custom server installation, with the NSM

Integration option:

Task Reference

Custom Server Installation (see

page 27)

1 Perform a custom server installation, selecting the NSM

Integration component.

2 Configure the server

3 Make sure all integration prerequisites have been met

4 Perform the integration


Before You Integrate (see page 80)

5 Create Unicenter Service Deskowned assets

Integrate Unicenter Service Desk

and Unicenter NSM (see page 81)

Create Owned Assets (see page 83)

6 Define the necessary message records and actions to create requests automatically

7 Edit the topology.cfg file and define filter and writer rules

8 Troubleshoot, if necessary

Monitor Event Console Messages

(see page 85)

Filter Unwanted Events (see page

86)

Troubleshoot Integration (see page

107)

Introduction 19

Chapter 2: Install and Configure

Unicenter Service Desk

This section describes the procedure for installing and configuring Unicenter

Service Desk on Windows and Unix/Linux platforms.


Review System Requirements

(see page 21)


(see page 21)


(see page 64)

Install Log

(see page 64)

Review System Requirements

Before you begin the installation process, review the Readme included on your

Unicenter Service Desk installation media for Installation Considerations and to determine whether your environment meets the documented software and hardware requirements.

Review the certification matrix for a list of third party software applications certified to be used with Unicenter Service Desk. The certification matrix can be found at the following URL:

http://supportconnectw.ca.com/public/uniservplus/unicervplus-sd_supp.asp

.

Installation Procedures

Use the following procedures to help plan and perform installations of

Unicenter Service Desk:

Server Installation (see page 22)


Install Remote Components (see page 37)

Web Interface Installation (see page 52)

Client Installation (see page 57)

Note: You need to have full Administrative rights in order to install and configure Unicenter Service Desk.

Install and Configure Unicenter Service Desk 21


Server Installation

There are two options for installing Unicenter Service Desk: Typical and

Custom. Both options are described in the sections below.

Typical Server Installation

A Typical installation process installs the features needed to run Unicenter

Service Desk, such as the primary server, web client, Java client, Ingres, etc.

If you want to use other components, such as secondary servers, reports, or integrations with other CA products, you must perform a Custom Installation

(see Custom Server Installation (see page 27)).

To perform a typical Unicenter Service Desk install:

1. Insert the Unicenter Service Desk DVD and select Install Products.

The Install Products screen displays.


2. Select Install Unicenter SD r11.2.

The Welcome screen displays.



The Welcome screen for the installation process displays.



4. Click Next.

The License Agreement screen displays.

5. Scroll through the license agreement as you read it. When you reach the end, click I Agree.

The Destination Location screen displays.



6. Click Next to accept the default installation location, or click Browse to select a different installation location and click Next.

The Shared Component Destination Location screen displays.


The Setup Type screen displays.



8. Choose Typical to install the base components required to run Unicenter

Service Desk and click Next.

The Installation Data screen displays.

9. Enter the user name and password for the privileged user account and click Next.

The Installation Data for the restricted user screen displays.



10. Enter the user name and password for the restricted help desk user and click Next.

11. Review the settings you selected and click Next.

The installation process begins.

12. When the installation completes, the Configuration process begins. (Refer

to Configure the Server (see page 38) for more information.)

Custom Server Installation

A Custom installation process is required if you want to use other components, such as databases other than Ingres, secondary servers, reports, or integrations with other CA products, that are not installed during a Typical

installation (see Typical Server Installation (see page 22)).

To perform a custom Unicenter Service Desk install:

1. Insert the Unicenter Service Desk DVD and select Install Products.












4. Click Next.









The Shared Component Destination Location screen displays.




8. Choose Custom.

The Select Features screen displays.




9. Choose the components you want to install and click Next.

Note: Refer to Custom Installation Components (see page 36) for a

description of these components.

The Installation Data screen displays.



10. Enter the user name and password for the privileged user account and click Next.

The Installation Data for the restricted user screen displays.

11. Enter the user name and password for the restricted help desk user and click Next.




to Configure the Server (see page 38) for more information.)



Custom Installation Components

The following components can be selected for a custom installation:

Server

Installs all files needed to run a primary server.

Secondary Server

Installs all files needed to run a secondary server.

Client

Installs all files needed to run a client installation.

Ingres Interface

Installs all files needed to use an Ingres database with Unicenter Service

Desk.

MS/SQL Interface

Installs all files needed to use a Microsoft SQL database with Unicenter

Service Desk.

Oracle Interface

Installs all files needed to use an Oracle database with Unicenter Service

Desk.

Web Interface

Installs all files needed to use the web interface for Unicenter Service

Desk.

Unicenter NSM Integration

Installs all files needed to interface Unicenter NSM with Unicenter Service

Desk.

Screen Painter

Installs all files needed to edit Unicenter Service Desk form definitions.

Web Screen Painter

Installs all files needed to edit Unicenter Service Desk form definitions and modify the database schema.

Reporting

Installs all files needed to run reports in Unicenter Service Desk.

Access Reports

Installs all files needed to run Access database reports.

Crystal Reports

Installs all files needed to run Crystal Reports with Unicenter Service

Desk.



Access Database Runtime

Installs Access database runtime files.

Crystal Report Runtime

Installs Crystal Reports runtime files.

Install Remote Components

If the MDB you are using with Unicenter Service Desk resides on a different machine than where the Unicenter Service Desk installation resides, you must install the remote components on the remote database machine.

To install the remote components:

1. From the main installation menu, select Install Remote Components.

2. When the Welcome screen displays, click Next.

3. Fill in the fields on the Database Configuration screen as appropriate for your installation and click Next. Refer to either Ingres Database

Configuration (see page 43) or Oracle Database Configuration (see page

46) for more information.

Note:

If you select Ingres as the database type, the II_INSTALLATION identifier on the remote database server must match the

II_INSTALLATION identifier specified on the Ingres DB configuration page of the Unicenter Service Desk server configuration wizard. We recommend using the default identifier of EI.

4. Fill in the fields on the eIAM screen as appropriate for your installation and

click Next. Refer to eIAM Field Definitions (see page 49) for more

information.

Note:

If eIAM is already installed on the remote system, the password entered should match the previously defined password. The installation default password is eiamadmin1.

5. Fill in the Privileged User name and password as appropriate for your installation and click Next.

6. When the Summary page displays, verify all settings and click Finish.

The database is updated and the privileged user is created.

Note:

The installation log file can be found in C:\Documents and

Settings\xxxxx\Local Settings\Temp, where xxxxx is the userid of the person who performs the installation. The file name is ca_service_desk_remote_setup_xxxxx, where xxxxx is a 5 digit process

ID.



Configure the Server

Configuring the Unicenter Service Desk server requires the verification and completion of fields on the Configuration windows. These fields define necessary information for configuring the server.

When you select a Typical or Custom installation, you are prompted to specify whether to run configuration:

If you answer Yes to the configure prompt, the Configuration window appears automatically when installation finishes.

If you answer No to the configure prompt, you can run the configuration at a later time by choosing Start, Programs, CA, Unicenter Service Desk,

Configuration.

To configure the server, follow these steps:

1. Fill in the fields on the General Settings dialog as appropriate for your installation and click Next. Refer to General Settings Field Definitions (see

page 39) for more information.

2. Fill in the fields on the System Accounts dialog as appropriate for your installation and click Next. Refer to System Accounts Field Definitions (see


3. If you are using a Unix or Linux platform, fill in the fields on the Character

Encoding dialog as appropriate. Refer to Character Encoding (UNIX/Linux)

(see page 42) for more information.

4. Select the appropriate Database Type and click Next.

For example, if you are using the Open Source Ingres database on your server, select Ingres; if you are using an MS SQL database, select SQL.

The choices presented depend on what were selected for database interface packages during installation. The menu on the left will be automatically updated depending on the database type chosen on this page. For example, it will be updated with an item "MS SQL Database

Config", if you choose SQL for the Database Type.

5. Fill in the fields on the Database Type Configuration dialog as appropriate.

Refer to one of the following topics for more information:

Ingres Database Configuration (see page 43)

MS SQL Database Configuration (see page 45)

Oracle Database Configuration (see page 46)

6. Fill in the fields on the Web Interface dialog as appropriate for your installation and click Next. Refer to Web Interface Field Definitions (see


7. Fill in the fields on the eIAM dialog as appropriate for your installation and

click Next. Refer to eIAM Field Definitions (see page 49) for more

information.



8. Fill in the fields on the Config Options dialog as appropriate for your installation and click Next. Refer to Config Options Field Definitions (see


9. If you performed the configuration as part of the installation process, click

Finish to complete the installation process.

General Settings Field Definitions

Configuration Type

The possible options depend on the particular installation. Select one of the following from the drop-down list, depending on your requirements:

Primary Server

Used to configure a Primary Server installation. This configures a web installation as well, if you selected the Web Interface component during installation.

Secondary Server

Used to configure a second server. There may be zero or more

Secondary Servers in a Service Desk enterprise system. Secondary

Servers are often added to a system to provide increased volume and performance, for example, if you want to add more Object Managers and webengines to another server.

Client (Linux only)

Used to configure a stand-alone Java Client installation.

Primary Server Node

This field can be edited for Primary Servers, Secondary Servers and

Clients. The value is the DNS name of the Primary Server. The value is the same for the Primary Server, all Secondary Servers and Clients in the

Service Desk system. This field is case-sensitive.

Object Manager Display Name

Enter the name or alias of the server. This name is displayed on client windows when they connect to this server's (primary or secondary) object managers (domsrvr). All object managers that are started on this machine will use this name for display purposes only. This value can be overridden when the object manager is started.

Object Manager Name

Enter the names or aliases of the object managers with which you want to establish a connection. You can enter a single name or a list of names. The default is ANY, which will connect to any running object manager. The default is acceptable in most situations. Your system administrator may want you to specify the name of a defined object manager or group of object managers.



Local Host Name

This field is editable for Secondary Servers and UNIX Java Clients. This value is the name or IP of the Secondary Server or Client. On Primary

Servers this field is not editable. The value of this field on a Primary Server will be the value entered in the Primary Server field. This field is casesensitive.

Configure /etc/services (UNIX only)

Only valid if you are the root user. Checking this option allows you to add the new Socket ports to the /etc/services file.

Slump Socket Port

The name of the main communications socket port. This port is used by all of Service Desk, regardless of whether or not you are using a Primary or

Secondary Server or Client. The default value is 2100. The Primary Server will always open a listen port on the slump socket port. Every daemon

(service) that communicates across the slump port will connect to the

Primary Server using this port.

Proctor Socket Port

This only applies to systems that use Secondary Servers (proctors). Each

Secondary Server will listen on this port for messages from the Primary

Server. The default value is 2300. Secondary Servers will open this port only when they cannot connect to the slump port on the Primary Server, for example, when the Primary Server is not running.



System Accounts Field Definitions

Privileged User Name

Enter an OS user ID that can be used for administration. On Windows, if the name you specify here does not already exist, a local user is automatically created with user and domain rights to different places, depending on how your local machine is defined:

If the local machine is not defined as a primary or backup domain controller, the privileged user is added to the local machine as a local user.

If the local machine is defined as a primary domain controller, the privileged user is added as a domain user.

If the local machine is defined as a backup domain controller, the privileged user is added to the primary domain controller as a domain user.

Important! If you have customized the user and domain user rights, you may need the help of a system administrator to set up the privileged user.

Privileged User Password (Windows)

Enter a password that will be set if the privileged user account is created.

If the privileged user name already exists on the local machine, and the local machine is not defined as a primary or backup domain controller, the local user is checked. If the local machine is defined as a primary domain controller or a backup domain controller, the domain user is checked.

(Linux) - The password entered here will be used for integrations with AMS and Workflow if the Privileged User is accepted for these integrations.

Restricted User Name (Windows only)

Enter an OS user ID that is used on behalf of clients as they access functions. It is restricted because it is allocated with limited user rights.

The default is rhd. The rhd user is added in the same manner as the privileged user.

Restricted User Password (Windows only)

Enter a required password that is added when the restricted user name is added. It is also kept in the configuration.

Default User Name (UNIX)

This only appears on Client installations. This can be the Privileged user, but it is usually the user ID of a user that will be using this Client to connect to the system.



Character Encoding Field Definitions (UNIX/Linux)

This configuration page is only available on UNIX and Linux systems.

The ICU converter provides the character encoding mapping that Unicenter

Service Desk uses when transcoding character data between Unicode and the operating system character encoding.

Use detected converter

Auto-detection has determined the converter available for your UNIX/Linux system. Leave selected if you want to use this converter.

Specify a converter

The ICU converter name field provides feedback of the converter Unicenter

Service Desk has determined best matches the operating environment. It also provides a means of overriding the auto-detected converter by specifying a converter name in this edit box. Converter names are caseinsensitive.

You can find a list of ICU converter names and aliases grouped by industry standards using the ICU Converter Explorer tool at the following web site: http://ibm.com/software/globalization/icu/demo/converters

Two converter names should be given special attention, if these appear as auto-detected:

US-ASCII

This converter name will be displayed in two conditions:

The auto-detection could not determine a matching converter and defaulted to US-ASCII. In this case, the ICU Converter Explorer or an equivalent tool should be used to determine a converter best matching the character encoding of the operating system’s locale.

Its name should be entered into the ICU converter name field.

The character set of the operating system locale only supports a limited 7-bit character encoding such as “C”, “POSIX”, “US-ASCII”,

“ISO646-US”, and so on. In this case, it is highly recommended to select a different operating system locale which utilizes a character set encoding that supports a wider repertoire of characters. See your operating system documentation for details for changing the locale environment for the user or shell used to invoke the

Unicenter Service Desk configuration program. A matching locale environment should be used for all subsequent accounts used to launch and operate Unicenter Service Desk.

UTF-8

Unicode repertoire encoded as UTF-8.



Note: UTF-8 based operating system locales are not supported in this release. It is highly recommended that configuration is aborted at this point and the operating environment is configured to support a non-

Unicode locale environment. A matching locale environment should be used for all subsequent accounts used to launch and operate Unicenter

Service Desk.

Default HTTP character set

Specifies the character set used on web pages sent from Unicenter Service

Desk web servers. This value is specified in the web page's HTTP charset declaration as the charset parameter in the HTTP Content-Type header.

This is described in RFC 2616 Hypertext Transfer Protocol - HTTP/1.1.

Configuration will attempt to determine whether this value is an alias of the ICU Unicode converter specified in ICU Unicode converter name. If it is not, an over-ride may be entered.

Ingres Database Configuration

Load default data

Check this box to load the Service Desk default system data into the database. If you have modified any system default values, this option replaces these values.

Use ITIL methodology

The Unicenter Service Desk interface can be optionally configured with an

Information Technology Infrastructure Library (ITIL) interface. Checking this box during database initialization will produce an ITIL interface for your installation. The ITIL Service Desk interface supports additional data objects not used in the standard out-of-the-box product. For example, problems and incidents are supported in ITIL, and the term "Asset" is replaced with the term "Configuration Item" in ITIL. Clearing this check box will configure your database with the non-ITIL, standard interface.

Ingres Configuration Type

A drop down list allows you to specify the type of Ingres configuration, specifically:

Install/Upgrade Ingres Server

This will install the new Ingres server.

Install/Upgrade Ingres Client

This will install an Ingres client, as well as create a Vnode.

For secondary servers, if a reporting package is installed, you will be given a choice to install an Ingres client or to use the existing client.



Database Server Node

The name of the node for your Ingres database server. Use the following guidelines:

For Ingres, specify the Vnode name (or workstation name, if local) of your Ingres server.

If the Ingres database is on a different machine than the server, the

Database Server Node is the name of the virtual node for the installation containing the repository.

If the database is on the same physical machine as the server, the

Database Server Node is the name of the local machine.

Database Name

Read-only. The name of the current database to be created, set to MDB.

MDB Size

Select the database size from the drop down list. The default is Small

Database.

Ingres Vnode Userid

If Ingres Client is selected for the Ingres Configuration Type, this field is available for creating a virtual node. Enter the Ingres Configuration

Manager Local Vnode name.

Ingres Vnode Password

If Ingres Client is selected for the Ingres Configuration Type, this field is available for creating a virtual node password.

Note: The special character "@" cannot be used in database ID's or

Passwords.

Ingres Vnode Name

If the Install Ingres Client check box is checked, this field is available for creating a virtual node. Enter the Ingres Configuration Manager Local

Vnode name.

Remote Ingres Server Identifier

This identifier is used to create a Vnode. It refers to the identifier of the remote Ingres server to which the Vnode is pointing. For example, EI.

Ingres Installation Identifier

Instance Identifier refers to the local installation of the Ingres server or local Ingres virtual node. For example, EI. It is used to install either the

Ingres server or client.

Ingres Installation Location

The path to the Ingres program location.



MS SQL Database Configuration






Database Server Node

This is the name of the MS SQL instance which Unicenter Service Desk will use for configuration. It uses the format of hostname\instance_name, where hostname is the machine name and the instance_name is the name of the instance, if it is not the default. If the default instance is used, hostname only is sufficient.

Database Name

Read-only. The name of the current database to be created, set to MDB.

MDB Size

Select the database size from the drop down list. The default is Medium

Database.

Database UserID

The database userid is the id of a database user. It is used to access the database. This user is separate and distinct from the privileged user, even though both may have the same user id string. For SQL, this is a SQL

Server user as opposed to the privileged user, which is defined in the operating system. When you initially create the database, the userid and the password are added to it. If the database already exists, you must enter the existing database userid.

Database Password

This is the password associated with the Database Userid.


Passwords.

SQL Listening Port (Optional)

This is the listening port of the defined SQL server instance. If this field is not entered, the default SQL port will be used, which is typically 1433.



Oracle Database Configuration

About Oracle Server Names

Unicenter Service Desk requires a Net Service Name specifying the Oracle database where the MDB resides. Unicenter Service Desk also requires an SID

(System Identifier) for the database. These names may be different, although they specify the same MDB database. Two name values are required for

Unicenter Service Desk because it accesses the database with both Oracle client technology and JDBC technology. Refer to Oracle documentation for further information on Service Names and SIDs.

Unicenter Service Desk uses a local install of the Oracle client technology for database access, and therefore requires the Net Service Name as defined by the local Oracle client or server. Several Unicenter Service Desk components access the database server directly using JDBC technology, and these components require the SID for the MDB as defined on the Oracle server.

These values may or may not be the same, depending on your database configuration.






Remote Database

Indicates if the Oracle MDB is on a remote machine (checked) or the local machine. If the Oracle server is local, the MDB will be created if it is not already. If it is remote, the MDB must already be configured with the remote installer.

Create Table Spaces

This setting allows you to specify whether to create tablespaces for the

MDB database or use any tablespaces already created.

If the Create Table spaces check box is checked, the script will create tablespaces with the default names MDB_DATA and MDB_INDEX. It will require a tablespace path. The Data and Index tablespace name fields will be disabled.



If the Create Tablespaces check box is unchecked, the script will require

the names of existing tablespaces. It will disable the tablespace path field in the GUI and enable the Data and Index tablespace name fields.

Important! If you want to use existing tablespaces, you must create a

Data tablespace that is at least 500 MB, and an Index tablespace that is at least 150 MB prior to running this configuration.

Net Service Name

The Net Service Name of the Oracle database where the MDB resides. If the database is remote, this is the Net Service Name defined within the

Oracle client on the local machine. This is because Unicenter Service Desk accesses the database using a local install of the Oracle client, which may specify a Net Service Name that is different than the service name on the

Oracle server.

DBA User Name

The name of an Oracle user with DBA access. This may be the SYS user.

Used only if the Oracle server is on the local machine.

DBA Password

Password for the DBA user. Used only if the Oracle server is on the local machine.


Passwords.

Data Tablespace Name

The name for the MDB data tablespace. It will be created if it does not exist. Used only if the Oracle server is on the local machine.

Index Tablespace Name

The name for the MDB index tablespace - it will be created if it does not exist. Used only if the Oracle server is on the local machine.

Tablespace Path

Directory Path to physical tablespace location. It will be created if the tablespaces mentioned above do not exist. Used only if the Oracle server is on the local machine.

JDBC Connectivity

Several components of Unicenter Service Desk use JDBC technology to access the database and require specific information about the Oracle server.



SID

The SID (System Identifier) for the database as defined on the Oracle server machine. This must be the SID for the MDB on the Oracle server, as the JDBC components access the database directly and not through an

Oracle Client. This value may not necessarily be the same as the Net

Service Name specified in the previous section.

Listener Port

The listener port for the database.

Database Host Name

The name of the machine where the Oracle server is installed.

Web Interface Field Definitions

Web Host

This field is enabled only if you are on a Primary Server. It defaults to the

Primary Server name. You can change this value if your default web server is on another machine. For example, you can change this value to the name of your Secondary Server if you move your web server to a

Secondary Server. This value is used to build URLs for the system.

Config Type

This drop down list allows you to select the web server type. For Windows systems the choice is IIS or Tomcat. For UNIX systems the choice is

Tomcat or Apache. The "Manual" selection should be used when an alternate http or servlet server is employed.

Note: The Tomcat port is always used to access upload, the Asset

Maintenance System, and pdmgraph, regardless of the Config Type setting.

Web Site

NT only. From the drop-down list, select the web site to be used by the

Unicenter Service Desk Server. The names appearing identify the available web sites. The IIS port is used to specify the port associated with the site.

Note: You can install any mail system client on your server, but it must strictly comply with the Microsoft MAPI 1.0 standard.

Tomcat Port

This is the Tomcat port number. It defaults to 8080, but you can set this to any value. This value will be used in the URL that is constructed to access the web site, for example, http://bobcat:8080/CAisd/UploadServlet.

Tomcat Shutdown Port

This is the socket port at which Tomcat will listen for shutdown requests.



eIAM Field Definitions

Apache Config File (UNIX)

This is the complete path to the Apache configuration file. An include file is added to this configuration file when integrating with an existing Apache installation.

IIS/Apache Port

If you configure with IIS or Apache, and are not using port 80, enter an alternate port number here. If you are using port 80, this field can be left blank.

Deploy Web Services

This check box is only available if you are configuring a secondary server.

It allows you to specify if you would like the Web Services installed on the secondary server location. By default, Web Services are installed on the primary server.

The eTrust Embedded Identity and Access Management (eIAM) component is used by the embedded CA Workflow product, and is optionally used by

Unicenter Service Desk for authentication. This replaces the default validation performed by the host operating system. eIAM may be configured to use as its user base either an external LDAP directory (such as Active Directory or eTrust Directory) or its own internal database. Whichever source is used, make sure that the Privileged User is known to eIAM. If eIAM is configured to use its internal database for user records during Unicenter Service Desk configuration, the Privileged User is added automatically. If eIAM uses an LDAP server, you must make sure the

Privileged User exists before completing Unicenter Service Desk configuration.

During installation, the eIAM configuration fields default to the following values:

eIAM Admin Password: <blank, or the eIAM Administrator user password, if entered during a previous configuration>

eIAM Application Label: “ServiceDesk-<hostname>” where <hostname> is the name of the local machine eIAM Application Description: “Unicenter Service Desk”

Use eIAM for Authentication: Unchecked



Select an install location

If you select “Local”, eIAM will be installed on the local machine. Note that eIAM requires the Ingres database, which will be installed if not present. If eIAM already exists on the local machine, this instance will be used. You will need to provide the eIAM Administrator Password of the existing install. It is strongly recommended to use a single install of eIAM for your entire organization. If it is already installed somewhere, perhaps by another CA product, select “Remote” as the install location. If “Remote” is selected, enter the eIAM Server Name in the edit box provided. This is the machine that is hosting the eIAM server. Note that eIAM must be up and running on the remote machine. EIAM may be installed on a remote machine with the Remote Components Installer, or from the Unicenter

Service Desk installation DVD.

Default setting is Local.

eIAM Server Name

If you selected a “Remote” install of eIAM, enter the server name here.

This field is not accessible if you select "Local" as the install location. If the server is the local machine, Unicenter Service Desk will install eIAM, if it is not already installed.

Default setting is the local machine name.

eIAM Admin Password

If Unicenter Service Desk will be installing eIAM, enter the eIAM Password.

If eIAM is already installed either locally or remote, enter the existing eIAM Password. If eIAM already exists, configuration will not continue until it can successfully verify the Password, so make sure the existing eIAM is up and running.

Default setting is blank, or the eIAM Administrator user password, if entered during a previous configuration.

Note: eIAM always uses EiamAdmin as the eIAM Administrator User

Name.

eIAM Application Label

This is the name Unicenter Service Desk registers with eIAM. It creates an

“application instance” in eIAM. Unicenter Service Desk makes little use of the actual instance during normal operation. The string entered here should be a short label, as it appears on the eIAM login screen. Application instance labels must be unique. Separate installations of Unicenter Service

Desk should use different application label names. For example, you may have a test and production system both using a shared eIAM server - each should have their own eIAM Application Label. An example of the label could be, “ServiceDesk-<hostname>” or “ServiceDesk-test domain”.



Note: If the Application Label matches an application instance that already exists in eIAM, a warning box appears. If this is a reconfiguration, it is fine to continue with the same name. If this is a reconfiguration and a new label is specified, a new instance is created. The instance created in the previous configuration is left untouched.

eIAM Application Description

This is a non-unique string used to describe the application instance. This can be any value you choose.

Use eIAM for Authentication

Check this box if you want to turn on eIAM authentication. If unchecked, the host operating system validation is used. Checking this box will add the privileged user to eIAM, but only if eIAM is not using an LDAP server for its user base. If eIAM is configured to use an LDAP server, the privileged user must already exist in the LDAP directory.

Note: This option is not available on HP or Solaris platforms. See the latest Unicenter Service Desk Readme file for information on how to configure for eIAM authentication when the primary server is on one of these platforms.

When you click Next, the system validates your entries. If eIAM is already installed, either on the local or a remote machine, configuration will attempt to validate the input against the eIAM server. It will verify the eIAM server is running and validate the eIAM Administrator Name and Password. If an error is reported, you should verify that the server is operating and is reachable from the local machine. Also, verify that the eIAM Administrator Name and

Password being used are correct.

When the Use eIAM for Authentication feature is activated, login requests are checked with the eIAM server. A login request is granted only if all of the following conditions are true:

The userid specified matches a Contact record in Unicenter Service Desk

The userid matches a user profile in eIAM

The userid/password combination is successfully validated by eIAM



Config Options Field Definitions

For Windows:

Start service when completed

Select this check box if you want the server to start when configuration is complete.

Integrate with Change Impact Analyzer

Enabling this check box allows you to run integration with Change Impact

Analyzer during Unicenter Service Desk configuration. This check box will be available if you installed Unicenter NSM Integration during Unicenter

Service Desk installation. This check box is only available on Windows.

When available, the default setting is checked.

For UNIX:

Note: UNIX users should be at the root user level for these options to be enabled.

Put Unicenter Service Desk links in /usr/bin

This only works if you are at root. Checking this option will put important

Unicenter Service Desk links into /usr/bin.

Start Event Converter daemons

Checking this option enables the Event converter daemons. The event converter daemons give you a capability to create Unicenter Service Desk tickets from either NSM World View or NSM Event Monitor.

Web Interface Installation

You can use the web interface provided with Unicenter Service Desk to access the product from the Internet via a web browser. The web interface is also commonly referred to as the browser interface.






.



Install the Web Interface

When the web server and the Unicenter Service Desk primary server are on the same machine, no additional action is necessary.

However, if you are using a Windows web server and the Unicenter Service

Desk primary server is installed on a different machine, you will install and configure two Unicenter Service Desk servers, a primary server and a secondary server.

The secondary server is the Windows machine where your web server resides and where you will install and configure the Unicenter Service Desk web interface. This server should be installed after your primary server is installed.

During installation, select the Custom installation option and then select the following options on the Select Features window:

Secondary Server

Web Interface

For more information, refer to Custom Server Installation (see page 27).

Important! If you have performed a Typical installation Tomcat is the default

Unicenter Service Desk Web Server. If you want to use IIS as your Unicenter

Service Desk Web Server, run Configuration and select IIS as default Web

Server from the Web Interface Option. For more information, refer to

Configure the Server (see page 38).



Enable Web Engine on Secondary Server

Assuming that your Unicenter Service Desk primary server is already installed and configured, you must enable a web engine on your secondary server using the pdm_edit.pl utility as follows:

1. On the Unicenter Service Desk primary server installation, switch to the

$NX_ROOT/samples/pdmconf (UNIX) or

installation-directory\samples\pdmconf (Windows) directory.

2. Enter the following command to start the pdm_edit utility: pdm_perl pdm_edit.pl

3. Answer the prompts according to your requirements. When you get to the main menu, type W to select the Edit Web Engines option.

4. Type A to add, then enter the IP address or DNS name of the secondary server when prompted for a host name.

This value is case-sensitive, so be precise if you enter a DNS name. If you are unsure, check the NX_LOCAL_HOST entry in the NX.env file on the secondary server.

5. When prompted for an object manager and a configuration file, you can typically accept the default values. You can also change these values if necesary.

6. Press Enter to return to the main menu, then type X to save and exit.

This process creates a file named pdm_startup.rmt that stores your new configuration values.

7. Create a backup of the pdm_startup.tpl that resides in the

$NX_ROOT/pdmconf (UNIX) or installation-directory\pdmconf (Windows) directory of the Unicenter Service Desk primary server installation, then replace it with the newly created pdm_startup.rmt file.

8. Run the configuration utility on the Unicenter Service Desk primary server without making any changes. Configure the Unicenter Service Desk secondary server. For more information on the configuration utility, refer

to Configure the Server (see page 38).

Your new configuration settings are in effect the next time you start the

Unicenter Service Desk server.



Configure the Web Interface

The web.cfg allows you to configure the web interface. You should modify this file if the default configuration set up by running the configuration utility does not meet your requirements. This file is located in the installation-

directory\bopcfg\www, and can be edited with any text editor that does not add formatting or control character information, such as WordPad or Notepad.

Each entry in the file consists of a single line containing a property name, optionally followed by a value. Lines beginning with a pound sign (#) are treated as comments and are ignored.

For more information on the entries in the web.cfg file, refer to Configure the

Web Interface in the Unicenter Service Desk Administration Guide.

Start Services

Before users can access the web interface, you must ensure that the Unicenter

Service Desk Services (the Daemon Server service and the database server) are running on all machines configured as Unicenter Service Desk Servers.

This includes the primary server and the secondary servers.

To start services on a Windows server, follow these steps:

1. Choose Start, Settings, Control Panel, Administrative Tools, Services.

2. Right-click the Unicenter Service Desk Server (primary server) or

Unicenter Service Desk Remote Proctor Server (secondary server) and choose Start.

To start services on a Unix primary server, type the following command from a command prompt: pdm_init

To start services on a Unix secondary server, type the following command from a command prompt: pdm_proctor_init



Access the Web Interface

To start the Web Interface, choose Start, Programs, CA, Unicenter Service

Desk, Service Desk Web Client.

To start the Web Interface from a machine that is neither the Primary Server nor a Secondary Server, enter the following URL in a browser window: http://servername:8080/CAisd/pdmweb.exe where servername is the name of the machine that is hosting the Unicenter

Service Desk Web Server. If you are using IIS as your Web Server, type the following URL in a browser window: http://servername/CAisd/pdmweb.exe.

To access the Web Interface from an internal Web Site, add /pdmweb.exe to the URL for your web pages. Use the following sample HTML code where

server-name identifies your machine and port-no is the port on which your web server is listening:

A HREF=http://<server-name>:<port-no>/CAisd/pdmweb.exe

Note: If your Internet Explorer browser's security is set to HIGH, an Internet

Explorer Content Warning displays when you start the Web Interface. To avoid this warning message, add the Web site to your Trusted Sites, or lower your

Internet Explorer security settings.



Client Installation

There are several types of Unicenter Service Desk Web Client interfaces. The features that can be accessed and the tasks that can be performed by a user depend on the type of client interface they are assigned. The interface types are described below.

Guest Web Client

Create new tickets and search the knowledge base. This interface is accessed when a user clicks Guest Login Here on the login page.

Customer Web Client

Report issues, review resolutions, and search the knowledge base.

Employee Web Client

Report requests, review resolutions, and search the knowledge base.

Analyst Web Client

Full access to Unicenter Service Desk functionality, except Administration functions. A user with an Analyst Web Client access can request any of the other client accesses by preceding their user name on the login page with the appropriate code, as follows:

Customer -- cst:userid

Employee -- emp:userid

PDA -- pda:userid

System Administration

Full access to Unicenter Service Desk functionality, just like the Analyst

Web Client, with full administrative capabilities.

Personal Digital Assistant (PDA) Web Client

Selected automatically for Analysts on a device that does not support

JavaScript. This interface can be selected manually on the login page. It has a limited screen size.






.



Install the Client

Install on a Local Drive

You can install a Unicenter Service Desk client in one of the following ways:

Install on a Local Drive (see page 58)

Install from a Network Drive (see page 60)

Install Silently (see page 61)

There are two options for installing Unicenter Service Desk: Typical and

Custom. Both options are described in the sections below.

Typical Client Installation

A Typical installation process installs the features needed to run the Unicenter

Service Desk client If you want to use other components, such as reports or screen painters, you must perform a Custom Installation (see Custom Client

Installation (see page 59)).

To perform a typical Unicenter Service Desk install:

1. Insert the Unicenter Service Desk CD and select Install Products.






4. Click Next.






7. Choose Typical to install the base components required to run Unicenter

Service Desk and click Next.



When the installation completes, the Configuration process begins. (Refer to

Configure the Client (see page 62) for more information.)



Custom Client Installation

A Custom installation process is required if you want to use other components, such as reports or screen painters, that are not installed during a Typical

installation (see Typical Client Installation (see page 58)).

To perform a custom Unicenter Service Desk install:

1. Insert the Unicenter Service Desk CD and select Install Products.






4. Click Next.






7. Choose Custom.

The Select Features screen displays.

8. Choose the components you want to install and click Next.

Note: Refer to Custom Installation Components (see page 36) for a

description of these components.




to Configure the Client (see page 62) for more information.)



Install from a Network Drive

Installing the Unicenter Service Desk client from a network drive is a two-step process:

1. Load the Software Disk Images on a Network Drive (see page 60)

2. Install the Software from a Network Drive (see page 60)

Note: Before loading the software to the network drive, determine if you have sufficient disk space on the network drive after comparing the image on the installation media. You may want to use a comparison utility.

Load the Software Disk Images on a Network Drive

To load disk images for a network installation:

1. Create a directory named usdinst on a shared network drive as follows:

F:\SHARE>md usdinst

2. Copy the Unicenter Service Desk Windows client installation media to the network subdirectory as follows (where x is your CD/DVD-ROM drive):

F:\SHARE\usdinst>copy x:\*.*

The software is now available for users to install from the network.

Install the Software from a Network Drive

To install the Unicenter Service Desk client from network disk images, follow these steps:

1. Select Run from the Windows Start menu.

The Run dialog appears.

2. Enter the following in the Run dialog, and click OK:

F:\SHARE\usdinst\setup.exe

3. Refer to Install on a Local Drive (see page 58)for instructions on installing

the Unicenter Service Desk client.



Install Silently

You can install the Unicenter Service Desk client “silently” without requiring any user input. The silent install is useful for implementing software delivery or otherwise installing Unicenter Service Desk as part of a batch process.

To perform a silent install, you can use setup.exe with the –r option set to create a silent installation response file, as follows: setup_dir\winclnt.32\disk1\setup -r

Using the –r option creates a file named setup.iss in your WINNT directory and records in it all the choices you make during the installation process.

Note: A setup.iss file containing default settings resides at

setup_dir\winclnt.32\disk1\.

You can use the setup.iss file as input to install any client by issuing the following command: setup_dir\setup /s /f1"iss_file" /f2"log_file" where:

setup_dir

Specifies the directory where setup.exe resides. This may be a location on your CD/DVD-ROM drive or on a network drive, if you have copied the installation files to a shared drive on your network.

iss_file

Specifies the full path, including the name of the setup.iss file to use during installation.

log_file

Specifies the full path, including the name of a log file where the installation process can log information.

You can run this command from a batch file, by using the Run command on the Windows Start menu, or from the Command Prompt.

Important! After performing a silent install, you must configure Unicenter

Service Desk before you can use it. For more information, see Configure the

Client (see page 62).



Configure the Client

Configuring the Unicenter Service Desk client requires the verification and completion of fields on the Configuration window. These fields define necessary information for configuring the server.

When you select a Typical or Custom installation, you are prompted to specify whether to run configuration:

If you answer Yes to the configure prompt, the Configuration window appears automatically when installation finishes.

If you answer No to the configure prompt, you can run the configuration at a later time by choosing Start, Programs, CA, Unicenter Service Desk,

Configuration.

To configure the client, follow these steps:

1. Fill in the following fields on the Client Configuration dialog:

Primary Server Node

Enter the host name or IP address of the server. The value that you enter for this field must be the same name that was entered in the

Primary Server Node field on the Server Configuration window. Contact your system administrator if you do not know the name of the server node.

TCP Service Number

Enter the value for the TCP service number. You can contact your system administrator for this value or determine it yourself using the

instructions in Determine the TCP Service Number (see page 63).

Object Manager Aliases

Enter the names or aliases of the object managers with which you want to establish a connection. You can enter a single name or a list of names. The default is ANY, which will connect to any running object manager. The default is acceptable in most situations. Your system administrator may want you to specify the name of a defined object manager or group of object managers.

Default Login ID

Enter the login ID of the person that will be using this client. This login

ID must be valid on the server and must exist in the Contact table.

2. Click OK to process the client configuration parameters you have entered.

3. If you performed the configuration as part of the installation process, click

Finish to complete the installation process.



Determine the TCP Service Number

A default value that works for the TCP service number on most installations is shown the first time you run the configuration program. To determine the TCP service number at your installation, open a telnet session from your Windows workstation to the server:

If your network is using NIS, enter: ypcat services | grep slump.

The output includes a line similar to this: slump nnnn/tcp #This is required for slump to work!

If your network is not using NIS, enter: grep slump /etc/services.

The output includes a line similar to this:

#slump nnnn/tcp

Enter the number nnnn in the TCP Service Number field.

Start the Client Interface

Unicenter Service Desk has two client interfaces. Before you can use either interface, you must ensure that the Unicenter Service Desk Daemon Server services and the database server are started.

If you have configured a secondary server (for example, if you have the web interface installed on a web server that resides on a different machine than your primary Unicenter Service Desk server), the Unicenter Service Desk

Remote Daemon Proctor service must be running before you start the primary server service. To start the proctor on the secondary server, follow these steps:

1. Select Settings, Control Panel from the Windows Start menu.

The Control Panel window appears.

2. Double-click Administrative Tools.

The Administrative Tools window appears.

3. Double-click Services.

The Services window appears.

4. Right-click Unicenter Service Desk Remote Daemon Proctor and click Start from the shortcut menu.

The Unicenter Service Desk Remote Daemon Proctor service starts.

When all the necessary servers are started, select Web Client from the

Unicenter Service Desk menu (accessible from the Start, Programs menu).



Note: To start the Unicenter Service Desk interface for Unix installations, execute pdm_client from the command line.

Modify the Current Installation

If you run the Unicenter Service Desk setup program with a current version of the product installed on your machine, the installation process detects the existence of the current version and gives you the option of modifying or removing components as necessary.

Remove

Select this option to remove all Unicenter Service Desk components from your machine.

Modify

Select this option to install new features and selectively remove existing features. For example, you could use Modify to add Access Reports and remove Crystal Reports.

When you select Modify and click Next, the Select Features page of the installation wizard opens. Select the features that you want to add and clear components that you want to remove.

Important! During modification, all currently installed components are selected when the Select Features page first appears. If you clear the check box for a currently installed component, that component is removed during the installation modification. When the modification runs, only the components selected on this page are installed.

When the appropriate features are selected click Next and follow the instructions on the installation wizard pages to complete the installation process. Allow the wizard to run configuration after installation.

Install Log

The features that you selected to install are noted in the Unicenter Service

Desk installation log file. This file is located in the \log folder of the installation directory, and is called stdlog.x (where x is a number from 0 to 9). The first log file created is called stdlog.0. When this file becomes full (the default size of each log file is 3,000,000 bytes), the file stdlog.1 is created, and so on. You can change the size of the log files by using the pdm_logstat utility.

For more information on the Unicenter Service Desk utilities, refer to the

Unicenter Service Desk Administration Guide.


Chapter 3: Get Started Using Unicenter

Service Desk



(see page 65)


(see page 67)

Set Up Users

(see page 70)

Define the Business Structure

You define your business structure by setting up:

Sites

Locations

Organizations

These objects have a relationship to each other, as shown in the following diagram:

Get Started Using Unicenter Service Desk 65


Because an organization has (references) a location, which in turn has a site, you need to define sites first, followed by locations, and finally organizations.

This way, when defining each object, you can choose from existing objects at lower levels in the hierarchy.

The sections that follow give a general description of each of these objects and explain how they are used elsewhere in the system. For more information about how to define each of them, see the Online Help.

Sites

A site is a grouping of locations. Because locations reference sites, you should define sites before locations. This lets you use the new site in the location. An example of a site might be a city in which your enterprise has one or more physical locations, or a region in which you have a customer base that you support.

Locations

Locations precisely identify a specific physical place, such as the address of a particular company, or an office address. Because organizations reference locations, you should define locations before organizations. This lets you use the new location in the organization.

Locations are used to pinpoint where other system components reside, such as contacts and assets. A location can be any type of place, such as a city, a campus, a building, or even a floor of a building. Defining locations lets you keep track and administer the areas and locations where the items of concern to your enterprise reside. Locations are the only objects with which you can associate a physical address—all other objects, such as organizations, assets, and contacts, derive their addresses from their associated locations.

Locations are also used for the purpose of automatically assigning requests. To enable automatic assignment based on location, you assign locations to request areas and groups. The request area locations are used to match a request to a location based on the location of the request’s asset or affected end user. The group locations are then used to select a group that is eligible for automatic assignment of requests in that location.

See the chapter “Establishing the Support Structure" in this guide for more information about automatic assignment.



Organizations

Organizations describe internal departments and divisions or external companies that can be assigned to tickets, asset classes, and contacts (for example, they are used to identify the company with which a customer is associated).

You can assign a default service type to an organization that is automatically assigned to tickets when the organization is specified. This lets you associate a specific level of service to a ticket based on the assigned organization.

You can define assets for organizations. This lets you specify the hardware, software, and services that are used by the organization. Linking assets to an organization (shared assets) supplements the feature of linking assets directly to a contact (private assets). When you designate a contact as the affected end user of a request, you can then select an asset for the request from separate lists of shared and private assets.

Define the Business Infrastructure

An important aspect of implementing your service desk using Unicenter

Service Desk is to define your business infrastructure by setting up:

Asset families and classes

Manufacturers and models

Service statuses

Vendors and vendor types

Assets

These objects have a relationship to each other, as shown in the following diagram:



When defining these objects, you need to begin at the bottom levels of the hierarchy. This way, when defining each object, you will be able to choose from existing objects at lower levels in the hierarchy. For example, because an asset class has (references) a family, you need to define asset families first, followed by asset classes. Similarly, because assets themselves sit at the top of this hierarchy, you need to define them last, after defining all the supporting objects.

The sections that follow give a general description of each of these objects and explain how they are used elsewhere in the system. For specific information about how to define each of them, see the Online Help.

Asset Families and Classes

Asset families classify your system assets by type and assign meaningful attributes for each asset. Asset classes identify general categories of assets that your enterprise supports. Families are broad categories of assets, such as hardware, software, and services. Classes are more specific categories within the broader family category. For example, the asset family hardware might contain asset classes such as, modem, router, repeater, and bridge.

Organizing your assets into families and classes makes it easier to manage your assets. For example, you can generate a list of assets that belong to a particular family or class.

Because you define asset classes based on asset families, you need to define asset families before defining asset classes. Because you define assets and models based on asset classes, you need to define asset classes before defining models or assets.

Manufacturer and Models

Manufacturers identify the manufacturers of the various assets of concern to your enterprise. Models contain specific information about the products that a particular manufacturer provides to your enterprise. For example, you might define as a manufacturer a particular software company. Then, you would define as models each one of the applications that the company provides for your enterprise.

Defining manufacturers and models makes it easier to manage your assets.

For example, you can generate a list of models provided by a particular manufacturer and generate a list of assets of a particular model.

Because you define models based on manufacturers, you need to define manufacturers before defining models. Because you define assets based on models, you need to define models before defining assets.



Service Statuses

Service statuses identify the readiness condition of assets, such as in service, in repair, or discontinued. Defining service statuses let you track the availability and use of assets in your enterprise. For example, you can generate a list of assets that are currently in repair. Because you define assets based on service statuses, you need to define service statuses before defining assets.

Vendor Types and Vendors

Vendor types are classifications for vendors that identify the type of company providing assets. For example, you might classify vendors that you lease assets from as leasers, while classifying vendors that provide service to you as providers.

Vendors identify the companies that supply your enterprise, including the type of company and a primary contact. Besides being referenced by assets, you can also reference a vendor in a user’s contact record.

Defining vendor types and vendors gives you a convenient way to organize your assets. For example, you can generate a list of vendors that fall under a particular vendor type and generate a list of assets from a particular vendor.

Because you define vendors based on vendor types, you need to define vendor types before defining vendors. Because you define assets based on vendors, you need to define vendors before defining assets.


Set Up Users

Assets

Set Up Users

Assets are the devices, software, and services that make up your business infrastructure. The information associated with an asset uniquely identifies the asset and indicates its precise location. Assets are referenced in tickets and can be associated with contacts (private assets) and organizations (shared assets). Assets let you:

Identify assets by name, class, and family

Specify inventory information

Specify additional properties to define the asset

Log and view comments associated with the asset

Specify location information for the asset

Specify service information, such as a service type, for the asset

View and define contacts and organizations assigned to the asset

Identify hierarchical relationships between assets

View tickets associated with the asset

You are not required to define all this information for assets. However, if you define as much asset information as you can before a problem occurs, you create a thorough and effective collection of all the critical information your service desk needs to begin solving a problem the moment it is reported.

An important part of establishing a working service desk is defining the users who are going to access it. In Unicenter Service Desk, users are called contacts, and there are several tasks that the administrator can perform to set up and manage contacts:

Set up contacts manually.

Organize contacts into groups that define areas of responsibility.

Establish contact types to organize your Unicenter Service Desk contacts into logical groupings based on how they use the system.

Import LDAP (Lightweight Directory Access Protocol) Directory user information into a Unicenter Service Desk contact record.


Set Up Users

Define Contacts

Everyone who uses Unicenter Service Desk must be defined as a contact. A user’s contact record defines all the information the system needs to know about that user, which in turn, is used in many ways throughout the system.

The primary uses for contact data are as follows:

Basic Identification Information

Basic identification, such as the user’s name and contact type, is used. A contact’s name is used as the primary identifier when selecting a contact or filling in contact information in other contexts. For example, the assignee field on a ticket shows the name of the analyst contact assigned to that ticket. The contact type is used to define the context in which this person uses Unicenter Service Desk. For more information about contacts, see Establish Contact Types.

Login Information

Login information, such as the user’s system login ID and in some cases, a

PIN field to use as a password, is used to verify a user to the system at login time. All users use their system login ID as the user name when logging in to Unicenter Service Desk. The user name is then used as the basis for identifying the user in the contact table for authentication purposes and for determining the access types assigned to the user.

Depending on how the administrator has security set up, another field such as the contact ID, can be specified as the PIN field and the user can use that as the password for login.

Security Information

Security access, such as the access type for each user, is determined by the access type that is assigned in their contact record or by a default access type, depending on how you set up the security for your system. In addition, a user’s access type may be assigned based on their membership in an LDAP Directory group. For more information about assigning access types using LDAP groups, see Assign Access Types Using LDAP Groups.

A user’s access type determines all aspects of their security, including how they are authenticated to the system, which web interface they see, and what product functionality they can access.

Security management is a feature of the Web interface. For specific information about how to set security options and relate them to contacts, see the chapter "Policy Implementation."


Set Up Users

Service Type Information

Service type information is also used to determine the level of service a user receives. A contact’s service type defines the level of service a user should receive. Service Level Agreements (SLAs) are negotiated with

Unicenter Service Desk customers, and service types serve as the mechanism for Unicenter Service Desk to implement SLAs. By associating a service type with a user’s contact record, you can guarantee that when a ticket for which a user is identified as the affected end user is created, the service type for the ticket will be at least as good as the contact’s service type.

Setting up SLAs using service types is a feature that you, as the administrator, will perform using the Web interface. For more information about how to set up security types and associate them with various objects in your Unicenter Service Desk implementation, see the chapter

"Policy Implementation."

Automatic Assignment Information

Automatic assignment information, such as work shift and availability

(used for analyst contact types only) can be used. You can set up analyst contacts to determine if and when they are eligible for automatic assignment. Automatic assignment is valid only for requests, and is defined as part of the request area definition. It is further linked to the groups to which the analyst belongs. For more information about automatic assignment, see the chapter "Establish the Support Structure."

Information on How to Send Users Notification Messages

A contact’s notification information includes their various email addresses and phone numbers that might be used for notification purposes, as well as the method to use for notifications of different urgency levels and the work shifts during which they should receive notifications. For more information about implementing notification, see the chapter "Policy

Implementation."

Organizational information (such as location, organization, and department) lets you group together contacts based on the organization to which they belong. For example, associating a contact with a location links the contact to a physical address and also helps in determining automatic assignment. The organization can be assigned a service type, making it easier to manage SLAs by organization rather than by individual contacts.

For more information about working with organizational information, see the chapter "Business Structure."


Set Up Users

Information about the Assets Users Have in Their Environment

This information refers to computers or software. Linking assets to a contact is a way to let analysts know about the user’s environment when working on requests for that contact. Assets can also be linked indirectly to a contact through the organization. If assets are associated with the contact or the contact’s organization, then whenever a request is opened with them as the affected end user, the asset information will automatically be available whenever the analyst views the request in detail. The contact’s assets are shown as private assets, and the organization’s assets are shown as shared assets. For more information about managing assets, see the chapter "Define the Business

Infrastructure."

Groups to which a User Belongs

You can organize contacts into groups that represent specific areas of responsibility within your service desk. For more information about using groups to manage contacts, see Organize Users into Groups. You can set up and define contacts using the Web interface.

Organize Users into Groups

A group is a collection of contacts that share a common area of responsibility.

In Unicenter Service Desk, groups are implemented using the predefined group contact type, making a group just a special type of contact. A group has the same basic information as a contact, with the important additional feature that groups are one of the keys to automatically assigning requests. You can associate request areas, locations, and a work shift with a group. These attributes are used to determine if and when the contacts in the group can accept automatic assignment of a request.

You can set up groups using the Web interface. For more information about how to define groups, see the Unicenter Service Desk Online Help.


Set Up Users

Establish Contact Types

Contact types are used to categorize Unicenter Service Desk users into logical groupings based on how they use the system. For example, some of the many contact types that are predefined by the system are analyst, customer, and group. These predefined contact types will meet the needs of most Unicenter

Service Desk implementations; however, if your circumstances require it, you can create new contact types, as well as modify the predefined contact types.

When you create contact records for your users, you can associate a contact type with each one.

An administrator works with contact types using the Web interface. For more information about how to define contact types, see the Unicenter Service Desk

Online Help.


Chapter 4: Integrate Unicenter Service

Desk with Other Products

This section describes how to integrate Unicenter Service Desk with other CA products.



(see page 75)


(see page 80)


(see page 125)

Portal Integration

(see page 149)


(see page 156)

CA Workflow Integration

A workflow denotes the tasks, procedural steps, organizations or individuals involved, required input and output information, and the tools necessary for managing and maintaining each step in a business process. The workflow service provides a total solution to help you manage the business processes.

In general terms, workflow is best described as the automation of a business process, in whole or part, during which documents, information, or tasks are passed from one participant to another for action according to a set of procedural rules.

CA Workflow is a generic, high performance, and scalable workflow management system, that allows for the definition, management, and execution of workflows, and provides a generic workflow solution.

Workflow is integrated into Unicenter Service Desk via a Web service.

Workflow Components

CA Workflow uses the following components that are delivered with the

Workflow Embedding Kit:

Workflow Design Environment (see page 76)

Workflow Server (see page 77)

Worklist (see page 77)

Integrate Unicenter Service Desk with Other Products 75


Workflow Design Environment

You use the Workflow Design Environment to create and manage workflows.

The Workflow Design Environment is your primary tool for creating and managing process definitions and workflow instances, and for controlling workflow participant interaction.

A company creates a business process to identify the resources, manual and automated activities, and activity relationships to realize its business goals. A workflow partially or fully automates the business process by defining the business process activities in a process definition. These workflow activities commonly include passing forms, tasks, or information from one resource to another, where the resource may be human or software.

A process definition is a representation of your business process. A process definition is comprised of nodes, events, roles, actors, work, and the criteria for process start and process end.

While process definitions represent what you want to happen in your business process, process instances represent what is actually happening. By running a process definition, you create a process instance. You can create multiple process instances of the same process definition, also called a process definition instance.

To launch the Workflow Design Environment:

On Windows systems, do one of the following:

Choose Start, Programs, CA, Unicenter Service Desk, Workflow IDE

OR

Double-click the ide.exe or the ide.bat file, located in the

$NX_ROOT\site\Workflow\Client directory

Note: If the IDE classpath requires additions to accommodate application requirements, you must modify the APPCPATH parameter in the ide.bat and use the ide.bat to invoke the IDE.

On Linux systems:

Run the ide.sh file, located in the $NX_ROOT/site/Workflow/Client directory.

Note: The ide.sh file has an APPCPATH parameter which can be modified to add to the classpath to accommodate application requirements.

Refer to Workflow IDE Parameters (see page 77) for information on

streamlining access to the Workflow IDE.

Note: The Workflow IDE is not supported on Unix systems.



Workflow IDE Parameters

When you acess the Workflow Design Environment, a login screen displays.

This login screen is pre-populated with user name, password, and URL connection. For streamlined access to the IDE, you can completely bypass the login screen by using a combination of the following command line parameters:

-u <username>

-p <password>

-url <PM URL>

-t <eIAM Safe Session token>

You can invoke the IDE by providing either a user name and password (-u and

-p) or by providing a token (-t). The –t token refers to an exported

SafeSession (also referred to as an artifact) which is a String. This allows for parent products to re-use any existing SafeSessions they may have, rather than prompting for a user name and password again.

The –url is a required parameter that must be supplied regardless of whether you use the –u and –p userid/password method or the –t token method.

For example, [-u, -p, -url] or [-t, -url]

To use this facility to bypass the IDE logon screen, edit either the ide.bat file

(for Microsoft Windows) or ide.sh (for Linux) to add these parameters to the list of parameters passed to the java command.

Note: This facility cannot be used with the ide.exe.

Workflow Server

The Workflow server exposes runtime execution and management services for workflow processes. The Workflow server consists of these components:

Actor Adapters allow for expansion of workflow activity functionality

The Process Engine executes process definition instances

The Process Manager provides management for process definitions as well as process instances

All workflow clients, the Process Designer, the Worklist, and both the Java and

Web Services API use services provided by the Workflow server.

Worklist

The Worklist is launched via a web browser (for example, http://<hostname>:<port number>/wl) or via API calls from an embedding product.



CA Workflow Access

Unicenter Service Desk provides workflow management using a common

Workflow engine. The workflow system provides a graphical workflow definition environment, sophisticated branching mechanisms, and the ability to interact with individuals who do not have direct access to the Unicenter

Service Desk application for gaining approvals.

This section describes the CA workflow authentication and how to add users to the CA workflow groups.

eIAM and CA Workflow

All logins to CA Workflow are authenticated by eIAM. A user must have an eIAM user record in order to access the CA Workflow IDE or Worklist application. The CA Workflow administrator, specified during Unicenter Service

Desk configuration, has full access to CA Workflow. By default, this administrator is used by Unicenter Service Desk for the Workflow integration.

This user account is set by the cawf_username and cawf_password Options in

Options Manager. You must make sure the username and password set in these options are correct and the user has full access to CA Workflow resources within eIAM.

Resource Classes

CA Workflow also uses eIAM to restrict access to specific CA Workflow functions. The access is controlled by two Resource Classes:

IDE

The IDE resource has a single action named login for login access to the

IDE. A user must have permission for this action to login to the CA

Workflow IDE application.

Process

The Process resource has the single action named start for the ability to start a process instance. A user must have permission for this action to start processes from within the Worklist web application. All users have access to the CA Workflow Worklist application to view and perform workitem tasks. This permission is only for starting new instances from the

Worklist.

Note: These resource classes are defined with the Unicenter Service Desk application instance in eIAM. When logging into the eIAM Web user interface, you need to specify the Unicenter Service Desk application instance in order to see the resources, polices and groups discussed here.



Add Users to CA Workflow Groups

Users who need to either login to the IDE or start process instances need an authorization grant to the resources and the two actions. The Unicenter

Service Desk configuration adds two policies to eIAM that grant access to these resources. Two user groups are also added that are granted rights to the policies: Workflow Administrators and Workflow Process Initiators. Adding users to the Workflow Administrators group gives them access to the IDE.

Adding users to the Workflow Process Initiators group allows them to start processes from the Worklist application.

To add/remove users from the groups on the machine where eIAM is installed, follow these steps:

1. Choose Start, Programs, Computer Associates, eTrust, eTrust Embedded

IAM, Embedded IAM UI.

The login window displays.

2. Select the Unicenter Service Desk application and enter the eIAM administrator name and password.

The main eIAM window appears.

3. Select Manage Identities.

4. Select the Users Search, enter search criteria and click Search.

5. Select a user in the result list.

6. On the user details display, add/remove group membership in the

Application Group Membership section.

If this section is not displayed, Click Add Application User Details.

7. Click Save.

The users are added to the groups.



Unicenter NSM Integration

During Unicenter Service Desk installation, you have the option of integrating

Unicenter NSM. If you select this option, the installation will communicate certain information to Unicenter Service Desk automatically. For example, you can:

Create requests using the 2D/3D map, Unicenter Explorer and the

Unicenter NSM GUI

Monitor event console messages from Unicenter NSM to:

– Send generic event data to Unicenter Service Desk

– Automatically generate requests and incidents

– Automatically post announcements to the Unicenter Service Desk scoreboard

Add asset records to Unicenter Service Desk from Unicenter NSM

Note: If you do not already have Unicenter NSM installed, you must do so before you can integrate it with Unicenter Service Desk.

This chapter explains how you can control Unicenter NSM integration so that you get only the information you want.

Before You Integrate

Both Unicenter Service Desk and Unicenter NSM must be installed and all patches applied before you can begin integration.

Important! Changing default settings when you integrate Unicenter Service

Desk with Unicenter NSM can cause unexpected results. For example, to avoid instantaneous creation of thousands of Unicenter Service Desk Requests during integration, the following parameters in the NX.env file located in

$NX_ROOT (UNIX) or installation-directory (Windows) default to NO:

@NX_TNG_OBJECT_UPDATED_SUBSCRIBE=NO

@NX_TNG_OBJECT_ADDED_SUBSCRIBE=NO

@NX_TNG_OBJECT_DELETED_SUBSCRIBE=NO

@NX_TNG_OBJECT_STATUS_UPDATED_SUBSCRIBE=NO



Integrate Unicenter Service Desk and Unicenter NSM

When the Unicenter Service Desk server and Unicenter NSM are installed on the same machine, you must install the Unicenter NSM Integration option. You can install this option on either a UNIX or Windows server. You can select the

Unicenter NSM Integration option during the initial installation or later by modifying an existing installation.

Windows

When the Unicenter Service Desk server and Unicenter NSM are installed on different machines, you must install the Unicenter NSM Integration option on the Unicenter Service Desk primary server. You must also install and configure a Unicenter Service Desk client or secondary server on the

Unicenter NSM server or on a Unicenter NSM administrative client.

UNIX

When the Unicenter Service Desk server and Unicenter NSM are installed on different machines, you must install the Unicenter NSM Integration option on both the Unicenter Service Desk primary server and the

Unicenter NSM server. After installing the Unicenter NSM Integration option on the Unicenter NSM server, you must run pdm_configure to configure Unicenter Service Desk as a secondary server on that installation.

You must also configure the converter using the pdm_edit utility as follows:

1. On the Unicenter Service Desk primary server installation, switch to the

$NX_ROOT/samples/pdmconf directory.

2. Enter the following command to start the pdm_edit utility: pdm_perl pdm_edit.pl

3. Answer the prompts according to your requirements, and when you get to the main menu, type N to select the Edit UNI Converters (UNIX_ONLY) option.

4. Type A to add, then enter the name or IP address of the Unicenter NSM server machine (configured as the Unicenter Service Desk secondary server) when prompted for a host name.

5. The script prompts you for an IP address. Enter the IP address of the

Unicenter Service Desk primary server machine.

6. Press Enter to return to the main menu, and then type X to save and exit.

This process creates a file called pdm_startup.rmt that stores your new configuration values.

7. Create a backup of the pdm_startup.tpl that resides in the

$NX_ROOT/pdmconf directory of the Unicenter Service Desk primary server installation, then replace it with the newly created pdm_startup.rmt file.



8. Run pdm_configure on the Unicenter Service Desk primary server without making any changes. This puts your new configuration settings into effect the next time you start the Unicenter Service Desk server.

Important! Do not reinitialize your database when you reconfigure.

9. As the privileged user, run pdm_proctor_init on the Unicenter NSM server to start the Unicenter Service Desk proctor.

10. As the privileged user, restart the Unicenter Service Desk services to start the Unicenter Service Desk daemons. Run pdm_status to display the status of the daemons.

Note: Keep the following in mind as you make selections during the integration process:

Before the process of “receiving an NSM event and creating a Request in

Unicenter Service Desk” can work, you must install and configure all components, and ensure that they are active.

An event would only become lost if the event converter service has been stopped. The event converter service queues NSM events when the

Unicenter Service Desk system is down (meaning it has been paused instead of stopped from the Microsoft Windows Services Panel). When

Unicenter Service Desk is restarted, it processes the queued events.

The NSM event converter service queues events up to a maximum specified by the NX_TNGCNV_QUEUE_SIZE environment variable.

When the Unicenter NSM repository is rebuilt after integration with

Unicenter Service Desk, Unicenter Service Desk menu entries are lost. To restore them, you must re-run the integration on the Unicenter NSM

Windows machine. To do this, run integAHD.exe located in

installation-directory\bin.

If the NSM event converter starts during Unicenter NSM events generation, events that occur before the event converter is fully initialized are lost.

Post Integration Process

After integration, perform the following steps:

1. Create Assets that are owned by Unicenter Service Desk which represent

WorldView managed objects (see Create Owned Assets (see page 83)).

2. Monitor event console messages to define message records and message actions as needed to create requests automatically.

3. Make the necessary entries in the topology.cfg file, and define filter and writer rules to filter unwanted events.

4. Troubleshoot problems, if necessary.



Step 1: Create Owned Assets

Many Unicenter products create Assets in the MDB; however they are not automatically available to Unicenter Service Desk. Usually a Unicenter Service

Desk organization only wants to track Assets that are owned by the organization and were acquired through a formal process. Some devices that are detected on the network by other Unicenter products should most likely not automatically become available to Unicenter Service Desk. For example, the laptop computer of a visiting consultant probably is of no interest to the

Unicenter Service Desk organization.

To make a discovered Asset in the MDB available to Unicenter Service Desk, use the Discovered Asset selection dialog that is available from the Asset

Search or Create New Asset forms in the Analyst Web Interface.

Note: The Discovered Asset selection dialogue is available on the Web Client.

If the WorldView integration for Change Impact Analyzer is being used, discovered Assets can be made available to Unicenter Service Desk either from the Unicenter NSM 2D/3D Unicenter Explorer right-click menu (Read Impact

Analyzer) or the pdm_nsmimp command line utility.

2D/3D Map and Unicenter Explorer

The Unicenter NSM 2D/3D map and Unicenter Explorer lets you access and create requests by right-clicking a managed object to display two menu options: Create Request and Request List.

These menu options are added to Unicenter NSM when you integrate with

Unicenter Service Desk.



Import Discovered Assets

The pdm_discimp utility is used for batch registration of non-Unicenter Service

Desk Discovered Assets. This utility can be used to search the MDB for assets that were registered by other software products and register them as

Unicenter Service Desk assets, so they can be used in Unicenter Service Desk.

This is an interactive batch process.

The logic is similar to Discovered Assets dialog that can be launched from

Asset Search/List web form. This program will query the ca_logical_asset, ca_asset, and ca_logical_asset_property tables, using various parameters, and attempt to register new Unicenter Service Desk Assets from the discovered values.

Notes: If the processing results in a blank Asset Label, the value found for the

Host Name or DNS Name will be used as the Asset Label. Assets must have at least a Label and Asset Class to be registered for use in Unicenter Service

Desk.

Two queries are performed to select the appropriate records to process, because of the structure of the MDB and Unicenter Service Desk architecture.

This could affect performance. The first query retrieves the rows from a join between the ca_logical_asset and ca_asset tables that match label, serial number, tag and hostname. Then for each resulting row, a query is performed against ca_logical_asset_property to match dns_name and mac_address. The asset from the first query is chosen for registration if the second query results in rows being returned.



Step 2: Monitor Event Console Messages

The basic Unicenter Service Desk installation automatically monitors status changes of monitored objects and the addition of new managed objects. You can set up your environment to use AHD.DLL to monitor console messages on

Windows and send event messages to the Unicenter Service Desk server.

AHD.DLL is the recommended method for sending events to Unicenter Service

Desk. However, other methods are available when the event console is running on a UNIX system.

Event Management in Unicenter NSM lets you identify events to which you want to respond and specify one or more actions to initiate automatically.

After you define a message and an associated action, the action is performed automatically whenever the event is encountered.

After integration with Unicenter Service Desk, when the event message occurs, you can send generic event data to Unicenter Service Desk to:

Create new requests or update existing requests

Create and post announcements on the Unicenter Service Desk scoreboard

The following sections describe how to perform these tasks. However, you should begin by using AHD.DLL to create a Unicenter NSM msg_action record.

Then, use the cawto command to pass that message record to the event console.

Note: Use the default filter and writer rules provided with Unicenter Service

Desk until you are sure that your system is integrated. Do not modify or remove the default rules until you have witnessed Unicenter NSM events creating requests.

Send Generic Event Data (Unix Only)

You can use the uniconv daemon in a message action in Unicenter NSM Event

Management to send generic event data to filter daemons in Unicenter Service

Desk. Generic event data can then be used to generate requests automatically in the same manner as AHD.DLL is used on Windows. This is the preferred method on Unix.

Post Announcements Automatically

When you integrate Unicenter Service Desk with Unicenter NSM, you can create and post announcements on the Unicenter Service Desk scoreboard from Unicenter NSM.



Filter Unwanted Events

After you set up integration correctly and events are creating or updating requests as defined, you can modify your filter rules to filter out unwanted events.

The following list provides some tips for coding filter rules:

Anytime you change a filter rule, you must restart Unicenter Service Desk.

Use the default writer rules while testing your filter rules.

When coding the node_ID, user_ID, or event_ID parameters in the filter rule, you must match the case of the incoming event. To ensure that you have the case specified correctly, create an event in Unicenter NSM on the parameter you are testing. This creates a request with the information you need. Match the case on the request with the case in your filter rule. This includes the case of incoming console messages.

When you are coding a filter rule for a specific event, the incoming text on the event may have the following format: “Object_Status_Updated minor.”

Code your filter rule to look for the following text:

tng:::*:::*:::Object_Status_Updated.*minor.*:::(0,1)

Blanks in the event may actually be unprintable characters. You should code the filter to include one or more characters with a period and asterisk

(.*), instead of the blank space (‘ ’). You should also include .* at the end of the event for any unprintable characters that may be at the end of the event text.

To ensure the filter works when you are coding more than one parameter on it, such as combining the node_ID, user_ID, and event_ID, code only one initially and make sure it works. Then, add the next parameter, make sure it works in conjunction with the first parameter, and so on, until finished.

For ease in debugging, order your filter rules from the most specific at the beginning of the file, to the most general at the end of the file.

Event writer rules follow the same set of debugging practices as filter rules. If you are using the CR_CREATE action and you have included a template, make sure that the template exists.



Filter Events Automatically

You can configure Unicenter Service Desk to automatically create requests for error and event messages generated by network devices and other event sources. Defining how events are filtered lets you automatically detect when an event occurs and initiate the actions specified for handling that event. This can improve overall operating efficiency and reduce the potential for error. You can configure Unicenter Service Desk to:

Filter events based on host, content, type, and other information from

Unicenter NSM

Create requests automatically for error and event messages generated by network devices

Execute commands automatically in response to an event

To automatically filter events, you must:

Define filter rules that identify the events that require special handling

Define event writer rules that identify the actions to perform automatically when these events are encountered

Filter and event writer rules use a generic event data structure to receive and send data. They are defined using a text editor and stored and edited on the

Unicenter Service Desk server only.

Any event is eligible for processing by filter and event writer rules. Some examples of events you may want filter and event writer rules to process are:

Hardware failures

Failures of scheduled batch processes

Excessive CPU usage

High paging rates

Unusual file activity

Unusual security conditions

You can configure any number of filter daemons, event writer daemons, and event sources on different machines. The locations and relationships of these elements are stored in the topology file on the Unicenter Service Desk server.

Note: When integrated with Unicenter NSM, you can use the uniconv daemon to automatically generate requests (this is the preferred method for UNIX). uniconv is used in a message action in Unicenter NSM Event Management.



Generic Event Data

Information about events is communicated using a generic event data structure. The generic event data structure consists of the following data elements:

Source Type

Identifies the format for the rest of the event.

Node ID

Identifies the device name or ID.

User ID

Identifies the user name or ID (when applicable).

Major Source

Identifies the source application ID.

Minor Source

Identifies the agent of event or further delineation.

Date/Time

Identifies the event date and time.

Event ID

Identifies the source event string that triggered the event.

Event Data

Identifies the associated event data.

Severity

Identifies the measure of the event’s importance.

Handle

Identifies the daemon-supplied string resulting from rules.

Handle Source

Identifies the daemon identifier that assigned the handle.

Handle Status

Identifies the status as create, update, or terminate.

Status Count

Identifies the number of updates.



Set Up Filter Rules

Define Filter Rules

Filters receive information from event sources that can then be passed to event writers. Since network devices generate hundreds of event messages, you can use filter rules to isolate those that can be used to create requests.

Filter rules let you:

Determine which network events or traps to report and how.

Control what happens when each type of event or trap is reported. Valid actions include ignoring, reporting on, and marking.

When integrated with Unicenter NSM, filtering lets you manage events from all systems managed by Unicenter NSM, including SNA and TCP/IP networks.

By filtering events, you can retrieve specific information about a particular node, user, or workstation, and then pass that information to event writers.

You can define event filter rules to screen for your particular needs, helping you identify suspicious events and correct them before they cause problems.

Note: It is helpful to be familiar with UNIX regular expressions when writing filter rules. You can also use UNIX regular expressions on Windows.

Filter rules use UNIX regular expression matching to determine if an event has a matching filter rule and blocks events that do not filter. A special filter

(ID=5) passes the incoming generic event unchanged to the writer. The filter passes only filtered events and assigns a handle source of filter and handle status of create, update, or terminate.

Unicenter Service Desk uses the major source, event ID, node ID, and user ID fields from the generic event data structure to find a matching filter rule.

Important! Filter rules pass information from events to another daemon that uses event writer rules, which can automatically create requests.

The default filter rule file, tngfilter_rule.dat, is located in $NX_ROOT/site/eh/IP

(UNIX) or installation-directory\site\eh\IP (Windows) on the Unicenter Service

Desk server. $NX_ROOT or installation-directory is the directory where you installed Unicenter Service Desk and IP is the IP address of the machine on which the filter resides. Typically, this is the Unicenter Service Desk server.

This file also contains many comment lines that show you how to set up various filter rules. Comment lines begin with the pound sign (#).

Use a text editor to view, update, and save the filter rule file. However, do not use an editor that leaves extra formatting characters in the file. We recommend WordPad for Windows users and vi for UNIX users.



Syntax (Filter Rules)

The filter rule syntax is: source_type:::node_ID:::user_ID:::event_ID:::filter where:

Fields in the rule are separated by three colons (:::). You can use an asterisk

(*) as a wildcard character, which means the value of the parameter is ignored when determining whether an incoming event matches the filter rule pattern.

Note: The first four parameters in the filter rule describe a pattern to compare against incoming events. This pattern is used to determine if the filter specified in the last parameter of the rule should process an incoming event.

Parameters (Filter Rules)

source_type

Specifies the type of source directing events to the filter. The major source field of the incoming event is compared to the value in this parameter. The type of converter that is sending events to the filter generally determines the value of this parameter. Valid values are:

uni

Identifies the UNIX Unicenter NSM converter.

tng

Identifies the Windows Unicenter NSM converter.

If an incoming event matches several rules when source types and event IDs are compared, then node IDs are compared.

node_ID

Specifies the node ID where the event originated. This parameter must exactly match the node ID of the incoming event, or this filter rule is not used. An asterisk (*) indicates that the node ID is ignored when determining if an incoming event matches this filter rule pattern.

Rules that match the node ID of the incoming event take precedence over rules that have asterisk (*) specified for node ID.

If an incoming event matches several rules when source types, event IDs, and node IDs are compared, user IDs are compared.

user_ID

Identifies a user associated with the event. Use this parameter to execute a particular action for events from a specific user. Note that many events will not have specific users associated with them. This parameter cannot contain a UNIX regular expression. You must supply an exact user ID or an asterisk. An asterisk (*) is the default and indicates that the user is ignored in selecting the rule.



Rules that match the user ID associated with the event take precedence over rules that have asterisk (*) specified for user ID.

event_ID

Specifies the event identifier. You can use a UNIX regular expression. A period and an asterisk (.*) matches any event name. For example, you can specify [Aa].* to match any event that starts with uppercase or lowercase “a.”

If the event_ ID parameter is simple text (not a regular expression), it must exactly match the generic event’s event ID. Partial matching does not count. If the event_ID is a regular expression, the length of the regular expression match is used to determine how well the event filter rule’s event_ID matches the generic event’s event ID.

If an incoming event matches several rules when source types and event

IDs are compared, node IDs are compared.

filter

Specifies which filter to use to process the incoming event and the parameters that the filter uses. The format is:

(filter_id, filter_parameter1, filter_parameter2, …)

Valid values for filter_id are:

Value=0

Report all events

Value=2

Ignore events that occur infrequently

Value=3

Ignore outages shorter than the length specified in filter_parameter1

Value=4

Ignore bursts shorter than the length specified in filter_parameter1

Value=5

Pass all events to destination without modification

The number of filter parameters varies for each filter_id, as the following table shows:



filter_ID filter_parameter1 filter_parameter2 filter_parameter3

Indicates whether events should always be reported as separate problems.

Interval 0=no, 1=yes occurrences

Specifies the number of times an event must occur during an interval to be important.

Specifies the elapsed time, in seconds, during which an event must occur to be important.


None 3 Interval 0=no, 1=yes



None 4 Interval 0=no, 1=yes



5 None None None

Note: The first four parameters in the filter rule describe a pattern to compare against incoming events. This pattern is used to determine if the filter specified in the last parameter of the rule should process an incoming event.



Set Up Event Writers

Event writers specify what Unicenter Service Desk should do when it detects an important event from the network. The event writer uses converted events

(events using the generic event data structure) from an event source and events that have passed through a filter to create requests.

Using event writers, you can:

Identify the type of event received from an event source

Specify the action to perform when the event writer receives events of this type. Valid actions include:

– Creating new requests

– Updating existing requests

– Executing a command

Indicate whether logging occurs

Define Event Writer Rules

When Unicenter Service Desk is installed, a default configuration is supplied that runs on the Unicenter Service Desk server. This default configuration sets up a single event source, filter, and writer, and has a filter rule that passes all events to the writer. The default writer rule creates requests for all events that it receives.

The default writer rule file, tngwriter_rule.dat, is located in

$NX_ROOT/site/eh/IP (UNIX) or installation-directory\site\eh\IP (Windows) on the Unicenter Service Desk server. $NX_ROOT or installation-directory is the directory where you installed Unicenter Service Desk and IP is the IP address of the Unicenter Service Desk server.

You can view the contents of this file to see the default writer rule definitions and comments describing the format of the writer rules. The comments are at the beginning of the file, and the writer rules are at the end. Comment lines begin with the pound sign (#).

Use a text editor to view, update, and save the writer rule file. However, do not use an editor that leaves extra formatting characters in the file. We recommend WordPad for Windows users and vi for UNIX users.



Syntax (Event Writer Rules)

The event writer rule syntax is: event_ID:::device:::user_ID:::majorSrc:::minorSrc:::action:::template::: command:::logging:::event_token:::user_parms where:

Fields in the rule are separated by three colons (:::). You can use an asterisk

(*) as a wildcard character, which means the value of the parameter is ignored when determining matches for the event writer rule.

Parameters (Event Writer Rules)

event_ID

Specifies the event identifier to which the event writer rule applies. You can use a UNIX regular expression. A period and an asterisk (.*) matches any event name. For example, you can specify [Aa].* to match any event that starts with uppercase or lowercase “a.”

If the event_ ID parameter is simple text (not a regular expression), it must exactly match the generic event’s event ID. Partial matching does not count. If the event_ID is a regular expression, the length of the regular expression match is used to determine how well the event writer rule’s event_ID matches the generic event’s event ID.

device

Specifies the name of the object, which is typically a device or host associated with the event. A period and an asterisk (*) is the default and indicates that the source object is ignored in selecting the rule.

If an incoming event matches several rules when source types and event

IDs are evaluated, devices are compared. Rules that match the device of the incoming event take precedence over rules that have asterisk (*) specified for device.

If you have defined rules for assigning device names, this parameter can be useful. For example, if you name devices located in the United States

USxx, you can specify US.* in this parameter to execute a particular writer action for events from devices in the United States.

user_ID

Identifies a user associated with the event. Use this parameter to execute a particular action for events from a specific user. Note that many events do not have specific users associated with them. This parameter cannot contain a UNIX regular expression. You must supply an exact user ID or an asterisk. An asterisk (*) is the default and indicates that the user is ignored in selecting the rule.



If an incoming event matches several rules when source types, event IDs, and devices are evaluated, user IDs are compared. Those rules that match the user ID associated with the event take precedence over rules that have asterisk (*) specified for user_ID.

majorSrc

Automatically displays the major type of source directing events to the event writer. This parameter is required. Its value is determined by the event source. For events from Unicenter NSM on Windows, the value must be “tng.” For events from Unicenter NSM on UNIX, the value must be

“uni.”

minorSrc

Automatically displays the minor type of source directing events to the event writer. For events from Unicenter NSM, this parameter contains the event type. Use an asterisk (*) to accept all events.

action

Specifies the action that occurs when the event writer receives this type of event using one of the following values:

CR_CREATE

Write a new request for each event.

CR_UPDATE

Update an existing request or requests (if they exist), or create a new request if no requests are found. By default, records are located by matching on the log_agent and affected_resource attributes. The user can override the defaults by specifying a list of any request attributes.

CR_UPDATE_ONLY

Like CR_UPDATE, except a new request is never created when no matching requests are found.

COMMAND

Execute the command specified in the command parameter.

Note: If Unicenter Service Desk cannot access a request or change order, it attempts the update again after a fixed interval.

template

Specifies the name of a request template to use to create a request. This parameter is not required and is ignored if the action is not CR_CREATE.

Note: The request template must be created before the rule is defined.



command

Specifies the command to execute if the action parameter value is

COMMAND. Substitution arguments, as the following table shows, can be incorporated into the command. The arguments are replaced by their realtime values when the command is executed:

&node

The device name or node identifier

&user

The user name or ID

&date

The event date

&time

The event time

&event-id

The source event string that triggered the event

&data

The associated event data

&sev

A measure of importance for the event

&major-src

The source application ID

&minor-src

The agent name or further delineation of the event

&handle

The daemon-supplied string resulting from rules

&src-handle

The daemon identifier that assigned the handle

&status-handle

The status of the handle (valid values are create, update, or terminate)

logging

Specifies whether logging occurs, using one of the following values:



NONE

No logging, other than normal error logging, occurs. NONE is the default value.

PDM

Logging occurs in the Unicenter Service Desk log (stdlog.0) in its internal generic event format. For more information, see Unicenter

Service Desk Log (stdlog.0) Syntax in this chapter.

SYS

Logging occurs in the UNIX syslog, which can be forwarded to the

Unicenter Console. The event is assigned a message ID (CAPD ....13) to allow event processing from the Unicenter Console.

BOTH

Logging occurs in the Unicenter Service Desk log (stdlog.0) and the

UNIX syslog.

event_token

A 30-character user-defined tag that identifies a specific request associated with an event_id (tng event message) or all messages like an

event_id (for example, a wildcarded event_id). event_token is a request attribute and is stored in every request generated by the Unicenter NSM interface. If no event_token is specified in the writer rule, the string

“tng_generated” is used. This lets the user update all requests that match the event_token attribute. For example, two different messages for the same asset can update unique requests.

Each CR_UPDATE writer rule specifies the unique message parts and a unique event_token. The event_token is used to find and update the matching request. By default, an activity log containing the message is added to the matching request. In another example, the user can update the status attribute (for example, set status=CL (closed)) in an existing request by specifying the same event_token in the CR_UPDATE writer rule that was used when the request was created using a CR_CREATE writer rule.

For example, the first writer rule below causes the writer process

(tngwriter) to create a call request with an event_token equal to

‘SystemCritical whenever it receives a NSM event identified by the string

‘Event1’. The second writer rule causes the writer process to update the status value to ‘CL’ for all call requests with an event_token equal to

‘SystemCritical’ whenever it receives a NSM event identified by the string

‘Event2’.

Event1:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE:::SystemCritical:::

Event2:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE:::SystemCritical:::%SEARCH=EVENT_TOKEN;%STATU

S=CL



user_parms

Contains the following types of information:

Request attribute values

Request attribute values are specified using the following syntax:

%ATTRIBUTE=value, where ATTRIBUTE is an attribute name identified in text_api.cfg that maps to a Unicenter Service Desk Majic call request attribute. This file is located in NX_ROOT/site (UNIX) or

installation-directory\site (Windows). For more information about text_api.cfg and how Unicenter Service Desk uses the Text API to create requests from Unicenter NSM, See the chapter “Creating

Objects using Text API” in the Administrator Guide.

Note: If you use multiple keyword/value pairs, separate each one with a semicolon (“;”).

For example, the writer rule below causes the writer process

(tngwriter) to create a call request with assignee equal to ‘mccda04’ and customer equal to ‘nsm’ whenever it receives a NSM event identified by the string ‘Event4’.

Event4:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE::::::%ASSIGNEE=mccda04;CUSTOMER=nsm

A list of request attributes to match when updating existing request records

The syntax for the list of attributes to match is specified as follows:

%SEARCH=attribute1[, attribute2…], where SEARCH is a fixed keyword and attribute1, attribute2, and so on are ATTRIBUTE names specified in the text_api.cfg. See the chapter “Creating Objects using

Text API” in the Administrator Guide for more information about text_api.cfg and how Unicenter Service Desk uses the Text API to create requests from Unicenter NSM.

The default search list of attributes is "asset_name" (DEVICE or UUID) and LOG_AGENT. The SEARCH keyword adds attributes (to match on) to the default search list. The SEARCH_EXPLICIT keyword completely overrides the default search list. Only the list of attributes following the SEARCH_EXPLICIT keyword are used to search for a call request.

For example, the writer rule below causes the writer process

(tngwriter) to update the status value to ‘CL’ for all call requests with assignee equal to ‘mccda04’ whenever it receives a NSM event identified by the string ‘Event2’.

Event2:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE:::SystemCritical:::%SEARCH=ASSIGNEE;%STATUS=CL;

%ASSIGNEE=mccda04



Note: An attribute in the list of attribute values is used to search on if the attribute is in the SEARCH or SEARCH_EXPLICIT list. If it is not in the search list it is used to set or update the attribute's value in the call request. It cannot be used for both in the same writer rule.

Special parameter names that are replaced with their corresponding value from the Unicenter NSM event structure

You can use the following special parameter names anywhere in the

user_parms string:

&message

Message text associated with this Unicenter NSM message.

&parm

AHD.DLL Parm field on Unicenter NSM Message Action Screen.

&uuid

Unicenter NSM universally unique identifier.

&device

Device (for example, host name) that generated the Unicenter NSM message.

&majorsrc

The major type of source directing events to the event writer. For events from Unicenter NSM on Windows, the value is “tng.” For events from Unicenter NSM on UNIX, the value is “uni.”

&minorsrc

The minor type of source directing events to the event writer.

&node

Device (for example, host name) that generated the Unicenter NSM message.

&addr

The IP address of the host that generated the Unicenter NSM message.

&username

The user name on the host that generated the Unicenter NSM message.

&date

An integer representing how long since 1970 the Unicenter NSM message was generated.

&time

The Date and Time of the Unicenter NSM message (for example, Tue

Jul 4 10:23:37 2000).



&severity

The severity of the Unicenter NSM message.

&tag

Tag data associated with the Unicenter NSM message.

For example, the writer rule below causes the writer process (tngwriter) to create a call request with customer equal to the username value

(&username) of the event message whenever the writer receives a NSM event identified by the string ‘Event2’.

Event2:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE::::::%CUSTOMER=&username

Using event_token and user_parms, you can set initial values or update values of all attributes of the request and specify which fields to match when locating records to update. The only restriction is that the description attribute is never updated in an existing call request record. If a record update and the description field are specified, an activity log containing the text of the description is added to the existing record.

NSM Message Action Record: ahd.dll AHD_Call <parms...>

You can also specifiy data (<parms...>) to the AHD_Call on the NSM message action record that can be used to replace the &Parm parameter specified in your user_parms parameter in your writer rule.

In order for the data specified on the AHD_Call to be processed in this way the data (<parms...>) must be preceeded with a '%' character and the &Parm 'special parameter' must be included somewhere in the user_parms field of the writer rule.

The following is an NSM message action and a writer rule that work together to cause the writer process to create requests with assignee set to ‘mccda04’ whenever it receives a NSM event identified by the string ‘Event3’.

Ahd.dll AHD_Call %ASSIGNEE=mccda04

Event3:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE::::::&Parm

Unicenter Service Desk customers migrating from AHD4.5 and earlier may already be using the <parms...> field. For example, you may be using this data to match on Writer rules. You can continue this practice without change. If you want to use both 'old' and 'new' parameters then you must concatenate a '%' character to your 'old'

<parms..> data and then follow with 'new' data. For example: ahd.dll AHD_Call old data ahd.dll AHD_Call %new user_parms ahd.dll AHD_Call old data%new user_parms



Data before the first '%' charactier is concatenated to the TNG event message which is placed into the Call Request description field. This is how Unicenter Service Desk has worked in the past. Data after the first '%' character is used to replace the &Parm parameter wherever it is specified in your user_parms parameter in your writer rule.

Unicenter Service Desk Log (stdlog.0) Syntax

The syntax for entries in the stdlog.0 file is: genDate genTime genNode genProc PID level codefile linenum msgID

:::msgDomain\msgNode::: ::: :::msgGenDomain\msgGenUser:::domainID

:::msgDate msgTime:::eventID arg tag::: :::IPaddr:filter:filterNum

:::majorSrc::: :::msgSrc:::msgType:::msgSrcNum::: :::platform where:

Fields in the rule are separated by three colons (:::).

genDate

Specifies the month and day (from the system clock) on which the log incident was generated.

genTime

Specifies the time (from the system clock) at which the log incident was generated.

genNode

Specifies the node name that generated the log incident. The value is typically the first eight characters of the generating node’s DNS name.

This value is always the same, because stdlog.0 only contains entries from processes running on the same node.

genProc

Specifies the name of the process (for example, ehwriter) that generated the log incident. The process name is operating environment-dependent, but should correspond to the name that appears in the Task Manager processes list (Windows) or in output from a ps command (UNIX).

PID

Specifies the numeric process identifier from the Task Manager processes list (Windows) or in output from a ps command (UNIX). The PID is critical when multiple processes are running with the same process name. For example, multiple database agents typically run concurrently with the same process name.



level

Specifies the programmer’s estimation of the significance of the message.

Possible values include FATAL, EXIT, RESTART, SIGNIFICANT, SEVERE,

ERROR, MINIMUM, WARNING, INFORMATION, MILESTONE, TRACE, and

VERBOSE.

codefile

Specifies the name of the code source file from which the message was generated.

lineum

Specifies the number of the line in the code source file at which the message was generated.

msgID

Specifies the ID assigned to a TNG event.

msgDomain

Specifies the name of the domain from which the message originated.

msgNode

Specifies the name of the node from which the message originated.

msgGenDomain

Specifies the domain from which the user identified by the msgGenUser value generated the TNG message.

msgGenUser

Specifies the user ID of the user that generated the TNG message.

domainID

Specifies the ID of the domain from which the TNG message was generated.

msgDate

Specifies the month and day (from the system clock) on which the TNG message was generated.

msgTime

Specifies the time (from the system clock) at which the TNG message was generated.

eventID

Specifies the source event string or sed-style regular expression that triggered the event.



Load Event Writer Rules

arg

Specifies a variable entered in the text string of a message action. For example, if the text field on a message action is entered as “ahd.dll

AHD_Call help me,” the argument in stdlog.0 appears as “args=help me.”

tag

Specifies tag data associated with the TNG message.

IPaddr

Specifies the IP address of the host that generated the TNG message.

filter

Specifies the process name for the filter rule file.

filterNum

Specifies the number of the filter rule file.

majorSrc

Specifies the major source (or converter type). This is a string that identifies the source application ID. That is, whether events come from

Unicenter TNG for Windows (in which case the value is tng), from

Unicenter for UNIX (in which case the vale is uni), or from an internal daemon (in which case the value is -).

msgScr

Specifies the message source. Possible values are CNV (converter), FLT

(filter), NOS (no source), and WRT (writer).

msgType

Specifies the message type. Possible values are CRT (create), DSC

(discovery), TRM (terminate), and UPD (update).

msgSrcNum

Specifies the message source number.

platform

Specifies the operating environment from which the message originated.

Possible values are AIX, AS400, DECOSF1, DGUX, DYNIX, HPUX, IRIX,

MISERVER, MPRAS, MVS, NETWARE, SINIX, SOLARIS, SVR4MP, TANDEM,

UNIXWARE, WNT (Windows), or any value defined by the UNIX agents.

When you modify or define writer rules, you can load these new rules without restarting the Unicenter Service Desk server or any of the support processes, such as the Unicenter NSM converter or the filter and writer daemons. To do this, use the wrtrule utility. You can also use this utility to write existing writer rules to a file.



Syntax (Loading Event Writer Rules)

The syntax for loading event writer rules is: wrtrule [-v] -c addr [-r rule_file] [-d dump_file]

Parameters (Loading Event Writer Rules)

-v

Specifies verbose mode, so feedback displays as the utility executes.

-c addr

The name of the event writer as shown by slstat.

-r rule_file

The name of the text file containing the events to load.

-d dump_file

The name of the file where you want the current event writer rules written.

The following types of information are written to the file:

Pending event messages

Network resource information in the process of being retrieved

Event writer rules

Note: Although both -r rule_file and -d dump_file are optional, you must specify one or the other. You can specify both, in which case new rules load first.

Note: If the event writer is handling one or more Unicenter NSM event messages when it receives a request to load new writer rules, the load is delayed until the writer completes the current messages. For example, the writer may be processing an event because it is waiting for network resource

(asset) information. In this case, the load message is delayed until this information has been retrieved and the request for a Unicenter Service Desk call request has been generated.

A request to write the current event rules to a file, however, is performed with no delay.



Maintain Filtered Events

The relationships between filter and event writer daemons and event sources on different machines are maintained in the topology file, topology.cfg, in the

$NX_ROOT/site/eh directory (UNIX) or installation-directory\site\eh directory

(Windows) on the Unicenter Service Desk server. The topology file lets you determine and maintain the entire event handling system from one location.

Instead of going to multiple clients, you can edit files in a single location and determine the topology of the entire event handling system.

Note: The $NX_ROOT/site/eh directory (UNIX) or installation-directory\site\eh directory (Windows) on the Unicenter Service Desk server also includes filter and event writer rules.

Use a text editor to view, update, and save the topology.cfg file. We recommend WordPad for Windows users and vi for UNIX users. Do not use a text editor that leaves formatting characters in a file.

The format of the topology file is: name cmd [dest-name] [converter-type] where:

name

Specifies the host and the unique name of the event-handling daemon in the format hostname:daemon-name (for example, ws2:uconv). The

daemon-name appears in slstat.

cmd

Specifies the name of the executable in the $NX_ROOT/bin directory

(UNIX) or installation-directory\bin (Windows), such as tngcnv, uniconvert, filter_nxd, or ehwriter.

dest-name

Specifies the daemon that receives the generic events from this daemon

(for example, ws2:filter1 and ws3:wrtr). Event writer daemons do not have destination daemons. All daemons should also have a record in the topology file.

converter-type

Specifies whether events come from Unicenter NSM for Windows (tng),

Unicenter NSM for UNIX (uni), or from an internal daemon (-).

A sample topology file is as follows:

# maple:uniconv uniconvert maple:tngfilter uni maple:tngcnv tngcnv maple:tngfilter tng maple:tngfilter filter_nxd maple:tngwriter - maple:tngwriter ehwriter - -



Example

Following is an example of how one organization implemented filtered events in an integrated installation of Unicenter Service Desk and Unicenter NSM.

To automatically create requests when a critical status appears on the

Unicenter NSM WorldView map, the Unicenter Service Desk administrator

(Ken) must create an event filter rule to identify the events to which he wants to respond. He must also create an event writer rule to specify the action to perform when events of this type are received.

Ken decides that he will use one simple filter rule at first. Then, as he becomes more familiar with the system, he will use a more complex set of rules. He decides to capture each critical event from U.S. servers. His system uses the convention that names all servers located in the contiguous United States as usaxxx, so this is very simple.

Ken first edits the tngfilter_rule.dat filter rule file in the $NX_ROOT/site/eh/IP directory on the Unicenter Service Desk server, where IP is the IP address of the Unicenter Service Desk server. He uses the UNIX vi editor, although he could use any text editor that does not add extraneous control characters (we recommend that Windows users use WordPad to edit files).

In the tngfilter_rule.dat file, the pound sign (#) is the comment character. Any characters after the pound sign are ignored when the rules are read. Most of the lines in Ken's tngfilter_rule.dat file are commented out, but he notices the following lines:

# Report All Events (separately) uni:::*:::*:::.*:::(0,1) tng:::*:::*:::.*:::(0,1)

These lines constitute an open filter; that is, a filter that will pass all events to the event writer.

Ken changes these lines to:

# Report All Events (separately)

# uni:::*:::*:::.*:::(0,1) tng:::*:::*:::Object_Status_Updated.*Critical.*:::(0,1)

Ken comments out the uni line because he is currently interested only in

Windows Unicenter NSM events. He enters Object_Status_Updated.*Critical.* in the event_ID field in the tng line because he wants the filter to pass only

Object_Status_Updated.*Critical.* events. Unicenter NSM generates

Object_Status_Updated.*Critical.* events when the state of an object becomes critical.

After saving the filter rule file, Ken edits the tngwriter_rule.dat writer rule file found in $NX_ROOT/site/eh/IP on the Unicenter Service Desk server, where IP is the IP address of the Unicenter Service Desk server.



As with the filter rules, most of the lines in the file are comments. The last two lines in the file show the default writer rule definitions. Ken wants to pay attention to events from Windows Unicenter NSM only, so he comments out the first of these two lines.

Ken formats the second line following these steps:

1. He has already set his filter to pass only critical events, so he leaves the event ID open with .*.

2. He wants to accept events from U.S. servers only, so he enters usa.* in the device field.

3. He wants to accept events from any user, so the user field remains asterisk (*).

4. He wants to write a new request for each critical event, so he leaves

CR_CREATE in the action field.

5. He has already entered a suitable request template in the system, so he enters its name, CriticalTemplate, in the template field.

6. He does not want any other logging done, so the logging field remains

NONE.

Here are the results of Ken's edit:

# .*:::.*:::*:::uni:::*:::CR_CREATE:::::::::NONE

.*:::usa.*:::*:::tng:::*:::CR_CREATE:::CriticalTemplate::::::NONE

Ken saves the writer rule file, and then recycles the Unicenter Service Desk server. He is ready to receive events and write requests automatically.

Troubleshoot Integration

Errors may occur when integrating, configuring, and using Unicenter NSM with

Unicenter Service Desk. This section contains information you can use to troubleshoot these errors. The following topics are discussed:

2D/3D Map Error Messages (Windows Only) (see page 107)

Review Server Configuration (see page 110)

Filter Error Messages (see page 111)

Check the Slump Connection (see page 112)

Turn On Logging (see page 113)

2D/3D Map Error Messages (Windows Only)

The integration portion of the 2D/3D map and Unicenter Explorer can produce

Unicenter NSM errors.



TNGWV object create failure= x

Reason:

This error typically occurs when the integration script is executed multiple times without first running deintegration (x represents a number).

Action:

To deintegrate, then integrate, Unicenter Service Desk with the Unicenter

NSM 2D/3D map and Unicenter Explorer, follow these steps:

1. At the command line, enter: installation-directory\bin\deintahd.exe

2. Open the Unicenter NSM Object Browser. Locate and click Method to display a list of methods.

3. If any AHD Methods are listed in the name column, select Delete from the Object menu to remove them.

4. Click Popup_Menu to display a list of menus.

5. If any AHDManagedObject exists under the name column, select

Delete from the Object menu to remove it.

6. With Popup_Menu still open, scroll down until ManagedObjects displays under the name column.

7. Search for any ManagedObject that has a method name containing

AHD. If any exist, select Delete from the Object menu to remove them.

8. Click Jasmine_Menu_Action to display a list of Unicenter Explorer methods. If any USPSD menu actions are listed in the name column, select Delete from the Object menu to remove them.

9. Click Jasmine_Menu_Object to display a list of Unicenter Explorer menus. If any USPSD menu objects are listed in the name column, select Delete from the Object menu to remove them.

10. Exit Object Browser.

11. At the command line, enter: installation-directory\bin\integAHD.exe

Your integration into the 2D/3D maps and Unicenter Explorer should now be successful. Right-click a managed object from the 2D/3D map or Unicenter

Explorer, and verify that all of the Unicenter Service Desk menu options are displayed.



Couldn't connect to the server - Please check the network and that server daemons are running.

(Socket error 10061)

Reason:

This is a general connectivity error and occurs if you try to get into

Unicenter Service Desk from the Java Client.

Action:

1. Ensure that the Unicenter Service Desk daemons or services are running.

2. If so, check the client configuration for correct settings.

CAE0232E-Repository error code 22

Reason:

This message indicates that the path to the executable in the method is incorrect.

Action:

Add installation-directory\bin to your path or modify the exe_name field in the Method list to include the full path to the executable.



Review Server Configuration

When the Unicenter Service Desk server is on a UNIX or Windows machine and

Unicenter NSM is on a different Windows machine, the Unicenter Service Desk server must be up and running. Start the NSM Event Converter service on the

Unicenter NSM machine. To ensure the converter is up and running, check the processes using Task Manager. If tngcnv does not appear as a running process after the event converter service was started, check the most recent tngcnv.n or stdlog.n files (located in installation-directory\log). These files provide you with information about why the event converter is not running.

When the Unicenter Service Desk server and Unicenter NSM server are on the same Windows machine, the Unicenter Service Desk Service must be up and running. Start the Unicenter NSM Event Converter Service on the machine. To ensure the converter is up and running, check the processes using Task

Manager. If tngcnv does not appear as a running process after the Unicenter

Service Desk service was started, check the following:

1. Using WordPad, edit the pdm_startup file located in

installation-directory\pdmconf. In this file, you will see text similar to the following:

[ procset MAIN_PROCSET] pdm_info sw_ver_ctl bpnotify_nxd

PDMBASE

PDMBOP

FILTERING

If a semicolon (;) is used to comment out FILTERING, remove the semicolon.

2. Moving backwards toward the top of the file, you should see the following text:

[ procset FILTERING ] tngfilter tngwriter ehc

; UNICNV_REPLACE

; tngcnv:NT_ONLY

If a semicolon (;) is used to comment out any of the above options, remove the semicolon.

3. If you made any changes to this file, save them, then recycle Unicenter

Service Desk server.

If the event converter still does not show up as a running process, check the most recent tngcnv.n file (located in installation-directory\log). This file provides you with information about why the event converter is not running.



Filter Error Messages

If your event converter (tngcnv) does not start or your converter is running but no requests are being created, your log files may contain an error indicating why it could not start or report events. You may see one or more of the following error messages:

Can’t resolve host name to an IP address

Reason:

This message indicates that you are missing host entries on your Unicenter

Service Desk machine, your Unicenter NSM machine, or both.

This error might also indicate that DNS is not working or is not returning the correct IP address.

Action:

Check the %SystemRoot%/system32/drivers/etc/hosts file. Your host file must contain an entry for the Unicenter Service Desk machine and the

Unicenter NSM machine. After adding the host name, restart the converter

(or the Unicenter Service Desk service). An example entry resembles the following:

127.0.0.1 localhost # Local host loop back

141.202.211.11 usbegp11 # This is the NSM client box

141.202.211.12 usbegp12 ahdhost # This is the Service Desk host

# (showing multiple entries)

Cannot find repository file

Reason:

This message indicates that the @NX_REPOSITORY parameter is not set in

NX.env (located in installation-directory) on the client.

Action:

Edit NX.env, add your repository name, making sure that you match the name exactly, save the file, and then restart the event converter.

The dependency doesn’t exist or has been marked for deletion

Reason:

This message occurs when there is a dependency (probably MSSQL) on the converter that should be removed.

Action:

Execute regedt32 and open the HKEY_LOCAL_MACHINE -> System

-> Current Control Set -> Services -> AHD_Event_Converter tree.

Remove the MSSQL dependency (or other as applicable) and restart your

Windows server.



Destination unknown, Queuing events or No topology.cfg file entry for node; queuing event

Reason:

This message indicates that the topology.cfg file on the Unicenter Service

Desk server must be corrected.

Action:

Correct the topology.cfg file as necessary, then recycle Unicenter Service

Desk and the Unicenter NSM converter. An example topology.cfg file for

Unicenter Service Desk on a Windows machine named AHD1 and a

Unicenter NSM machine named TNG1 follows:

TNG1:tngcnv tngcnv AHD1:tngfilter tng

AHD1:tngfilter filter_nxd AHD1:tngwriter -

AHD1:tngwriter ehwriter - -

Check the Slump Connection

If the Unicenter NSM converter is running and you still do not see any events being created, you should verify the slump connection to Unicenter Service

Desk. To do this, enter the slstat command from the command line on the

Unicenter Service Desk machine.

Look for a slump connection to tngcnv. If you do not find one, the converter is not communicating with Unicenter Service Desk. Recycle the Unicenter NSM converter, and then verify the connection again. If the connection still cannot be found, check the tngcnv.n files (located in installation-directory\log) for errors regarding tngcnv and slump logon.



Turn On Logging

If the slump logon was successful and you still do not see new events, turn on logging and check the files for an indication that an event has come through

Unicenter NSM. You can create an event simply by changing the status on a managed object on the 2D/3D map.

To turn on logging, modify the file NX.env file located in $NX_ROOT (UNIX) or

installation-directory (Windows) to include the following line:

@NX_LOG_LEVEL_BSTRAP=VERBOSE

You can then monitor the tngcnv.n files (located in installation-directory\log) to determine if events are being passed to Unicenter Service Desk. You should see something similar to the following:

09/17 16:35:58:01 tngcnv 477 MILESTONE convrtr.c 399

Sending 1:::dogwood:::9994011e-2f7e-11d1-a435-00c04fd478c9:::09/17/1997

:::16:35:41:::Object_Status_Updated minor:::BV:141.202.211.0:Segment.1

IP:141.202.211.14 MAC: CNT: LOC: DSC::::3:::tngcnv:1:::tng:::WindowsNT:

::CNV:::CRT:::1:::

In this example, the message indicates that the status on a managed object has been updated to Minor.

If you find that events are being passed to Unicenter Service Desk and they appear in the log, double check to make sure that you are using the default filter and writer rules. If not, restore the original default filter and writer files, recycle the server, and create a new event.

If you find that events are not being passed to Unicenter Service Desk, make sure that two Unicenter NSM processes responsible for passing event information (canotify.exe and caoprdmn.exe) are executing. If they are not running, start them as described in the Unicenter NSM documentation. If they are running, contact Unicenter NSM Support.



Unicenter Service Desk Event Converter

This section applies to NSM Integration on a Windows platform only.

The Unicenter Service Desk Event Converter is installed in two different ways when Unicenter Service Desk configuration is run on a Windows server:

As a Windows Service

As a part of Unicenter Service Desk Daemon Server from where you can start and stop the converter

The Event Converter can be run on a Primary, Secondary or Client-only machine. While you may use either method to start the Converter on the

Primary and Secondary servers, it can only be started as a Windows Service on a Client.

Note: If Unicenter Service Desk is shutdown for any reason, you may want to leave the Event Converter running so it can continue to receive messages from

NSM. Any messages received from NSM while Unicenter Service Desk is down will be queued and processed once Unicenter Service Desk is restarted.

Remove Event Converter from the Daemon Manager

The Daemon Manager not only starts and stops the Converter but also restarts the Converter if it stops inadvertently. You can use pdm_status to see whether the Converter is running or not and to determine if it is running on the local or on a remote (Secondary) server.

If you wish to use the Windows Service Manager to start and stop the Event

Converter, remove the Event Converter from the Daemon Manager’s startup configuration.

To change the startup configuration on a Primary server, change the following line in the pdm_startup file. tngcnv so that it reads:

; tngcnv

However, this change would revert when you re-run Unicenter Service Desk

Configuration. If you want the change to persist make the same change in pdm_startup.tpl file.

To change the startup configuration on a remote (Secondary) server use the pdm_edit facility. For more information on running pdm_edit, see the chapter

"Configuring the Web Interface" in the Administrator Guide.



Remove Event Converter from Windows Service

If you want to use the Daemon Manager to start and stop the Event Converter, use the following command to remove the Event Converter from the Windows

Service: tngcnv –u

To re-install the Event Converter as a Windows Service use the following command: tngcnv -i

Leverage NSM to Unicenter Service Desk Integration

The section provides an example of how to leverage the integration between

Unicenter NSM and Unicenter Service Desk. The example offers a sample approach for configuring this out-of-box functionality and is not intended to suggest that it is the only way to accomplish this task.

Sample Message Records/Actions with Limited Content

Two Message Records, CFNEW and CFUPDATE, written with a single message action each, are the cornerstone in this example for integrating NSM to

Unicenter Service Desk (sample files are also included). For a clean, compact, robust and easy-to-maintain integration, you can leverage the strength of the following:

tngwriter_rule.dat

CR_UPDATE and CR_UPDATE_ONLY functions text_api keyword list

Note: The example shows how to create Message Records and Message

Actions with very little content. The content has been moved into the cawto commands that are illustrated in the examples that follow. You could alternately place the desired parameters and content directly into the “text” field of the message action, or even use a combination of the two approaches.



Sample Event Management Message Record

The following dialog shows a sample Event Management Message Record that will react to an event containing “CFNEW” at the start of the event alert:



Sample Message Action List

This sample shows the Message Action list that is associated with the

“CFNEW*” Message Record. By double-clicking on this item, you can see the detailed information stored as part of the Message Action.



Note: The next example shows the detailed view where you can see the

“action” field set to “EXTERNAL” and the “text” field with the standard integration text value of “AHD.dll AHD_Call”.



Sample Message Record (configured to scan for events beginning with

CFUPDATE)

This sample reflects part of the detail that results from a second Message

Record, configured to scan for events that began with “CFUPDATE”. This

Message Record also has an identical Message Action created for it (as illustrated by the previous “CFNEW*” Message Record):



Sample cawto Commands that Generate/Update Requests

To use the Message Records previously created, send a message through

Unicenter NSM Event Management by using the “cawto” utility/command provided with Unicenter NSM. The “cawto” utility/command allows you to create or update a Request using the command formats shown in the two examples that follow.

Note: By using this approach, you can capture and reformat (for translation into an expected format for inclusion into Unicenter Service Desk) any alerts of interest coming into the Event Management console.

Issue the “opreload” command on the NSM Event management Console to refresh the NSM Event Message Records and Actions that are stored in memory after creating the previous NSM Message and Action rules.

Sample 1: “cawto” formats for Generating and Updating a New

Request

Use the following cawto format for generating a New Request:

CAWTO -n <NSM-server-name>

CFNEW;%STRING1=KEYWORD1;%CUSTOMER=ServiceDesk;%SUMMARY=Photos required;%CATEGORY=Applications;%DESCRIPTION=Description: Photos required Justification: required by regulations for entry

Use the following cawto format for updating a Request:

CAWTO -n <NSM-server-name>

CFUPDATE;%STRING1=KEYWORD1;%STATUS=Closed;%SUMMARY=Cancelled by ServiceDesk

Sample 2: Alternative “Cawto” formats for Generating and Updating a

New Request

Use the following alternative cawto format for generating a New Request:

CAWTO -n <NSM-server-name> CFNEW2;%EVENT_TOKEN=KEYWORD2;%SUMMARY=Server

Installation Approved;%STATUS=Work in Progress;%CATEGORY=Hardware;%DESCRIPTION=Install new server and level V drops to existing server location within the data center. Also, install wiring on patch panel in router cabinet

Use the following alternative cawto format for updating a Request:

CAWTO –n <NSM-server-name>

CFUPDATE2;%EVENT_TOKEN=KEYWORD2;%STATUS=Closed;%SUMMARY=Closed by Server

Team

Sample Files to Use with the Integration

This section describes the sample files available for your use when integrating

NSM to Unicenter Service Desk.



topology.cfg tngfilter_rule.dat

# <remote_node>:uniconv uniconvert <IP_ADDR_tngfilter>:tngfilter uni

<IP_ADDR_tngcnv>:tngcnv tngcnv <IP_ADDR_tngfilter>:tngfilter tng

<IP_ADDR_tngfilter>:tngfilter filter_nxd <IP_ADDR_tngwriter>:tngwriter -

<IP_ADDR_tngwriter>:tngwriter ehwriter - - where:

<IP_ADDR_tngcnv>

The IP Address of the server that is running the Unicenter NSM Event

Converter process.

<IP_ADDR_tngfilter>

The IP Address of the server that is running Unicenter Service Desk.

<IP_ADDR_tngwriter>

The IP Address of the server that is running Unicenter Service Desk.

Use the default version of this file, with no changes.



tngwriter_rule.dat

The tngwriter_rule.dat displays as follows:

# evt id:::dev:::user:::majorSrc:::minorSrc:::action:::template:::cmd:::log:::event_token:::user_parms where:

# event id

The string or sed-style regular expression.

device

The string, sed-style regular expression, or '*' or empty.

user

The string, '*', or empty.

majorSrc

The string "uni" from uniconverter, or "tng" from tng converter.

minorSrc

The string or '*'.

action

The action options. The following options are available:

CR_CREATE

Write a new request for each event

CR_UPDATE

Updates an existing request or requests (if any exists) or creates a new request if no requests are found. By default, requests are located by matching on the log_agent and affected_resource (asset) fields.

The user can override the defaults by specifying a list of any call request attributes.

CR_UPDATE_ONLY

This is like CR_UPDATE except that a new request is never created when no matching requests are found.

COMMAND

Executes <cmd>, identified in the cmd description in this table.

template

Specifies the name of a request template to use to create a request. This parameter is not required and is ignored if the action is not CR_CREATE.

Note: The request template must be created before the rule is defined.



cmd

The command passed to the shell—ignored on all but COMMAND action.

logging

The logging options, as shown by the following:

NONE

No logging (other than error logging).

SYS

Log incidents to the Unix syslog (Unicenter message console).

PDM

Log incidents to application log ($NX_ROOT/log).

BOTH

Log incidents to application log and syslog.

event_token

(Optional). This is a 30-character user defined tag that is used to identify a specific request associated with an event_id (tng event message) or all messages like an event_id (for example, a wildcarded event_id). event_token is a request attribute that is stored in every request generated by the TNG interface. If no event_token is specified in the writer rule, the string "tng_generated" is used. This allows the user to update all requests that match the event_token attribute. For example, two different messages for the same asset can now update unique requests. Each

CR_UPDATE writer rule specifies the unique message parts and a unique event_token. The event_token is used to find and update the matching request. By default, an activity log containing the message is added to the matching request.

In another example, the user can update the status attribute (such as, set status=CL (closed)) in an existing request by specifying the same event_token in the CR_UPDATE writer rule that was used when the request was created using a CR_CREATE writer rule.

user_parms

(Optional) This contains the following three types of information:

Request attribute values

List of request attributes to match on when updating existing request records

Special parameter names that are replaced with their corresponding value from the TNG event structure



The request values and the list of attributes are specified using a

%<KEYWORD>=<value> syntax. If you use multiple keywords/value pairs, you must separate each by a semicolon (";").

Request attribute values are specified using the syntax

%<ATTRIBUTE>=<value>, where ATTRIBUTE is an attribute name identified in the text_api.cfg (located in NX_ROOT/site directory), which maps to an AHD majic request attribute.

The syntax for the list of attributes to match is specified as

%SEARCH=<attribute1>[,<attribute2>.], where SEARCH is a fixed keyword and attribute1 (and so on), are ATTRIBUTE names specified in the text_api.cfg.

The following special parameter names can be used anywhere in the user_parms string:

&Message

The message text associated with this Unicenter NSM message.

&Parm

The AHD.DLL Parm field on the Unicenter NSM Message Action dialog.

&Uuid

The TNG universally unique identifier.

&Device

The device (for example, hostname) that generated the Unicenter NSM message.

&Majorsrc

The major type of source directing events to the event writer. For events from Unicenter NSM on Windows, the value is “tng”. For events from Unicenter NSM on UNIX, the vaule is “uni”.

&Minorsrc

The minor type of source directing events to the event writer.

&Node

The device (for example, hostname) that generated the Unicenter NSM message.

&Addr

The IP address of the host that generated the Unicenter NSM message.

&Username

The user name on the host where the Unicenter NSM message was generated.



&Date

The integer number representing the time since 1970 when the

Unicenter NSM message was generated.

&Time

The date and time of the Unicenter NSM message. For example, Tue

Jul 4 10:23:37 2000.

&Severity

The severity of the Unicenter NSM message.

&Tag

The tag data associated with the Unicenter NSM message.

Note: The Defining Event Writer Rules topic describes how to use the event_token and user_parms.

As an example, using the examples outlined in Sample 2: Alternative “Cawto” formats for Generating and Updating a New Request the default Event Writer

Rules file should be changed from:

*:::.*:::*:::uni:::*:::CR_CREATE:::::::::NONE

To the following:

CFNEW.*:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE::::::&Parm;%SEARCH_EXPLICIT=STRING1

CFNEW2.*:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE::::::&Parm;%SEARCH=Event_Token

CFUPDATE.*:::.*:::*:::tng:::*:::CR_UPDATE_ONLY:::::::::NONE::::::&Parm;%SEARCH_EXPLICIT=STRING1

CFUPDATE2.*:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE::::::&Parm;%SEARCH=EVENT_TOKEN;%STATUS=C

L

Note: The %SEARCH_EXPLICIT parameter is used to ensure that when an update is performed, the search looks for a matching Request by comparing the contents of the STRING1 field before proceeding with the update.

For more information about text_api.cfg and how Unicenter Service Desk uses the Text API to create requests from Unicenter NSM, see the chapter “Creating

Objects Using Text API” in the Administrator Guide.



Change Impact Analyzer Implementation

This section explains how to integrate, implement, and maintain the Change

Impact Analyzer.

Unicenter Service Desk Change Impact Analyzer

Your business is comprised of many interrelated elements—people, roles, processes, and the resources that support the successful operation of these elements—which together deliver products and services to your consumers.

Often the knowledge of how these elements interrelate and affect your business exists only in the heads of a few key members of your organization.

A method is needed to effectively display the relationships between these elements based on current data. By monitoring the status of elements such as configuration changes and faults, the health of your business can be ascertained. Often failure of a component in one part of a business exhibits itself in an unpredictable manner in another part of the business. Having the relationships of the elements that comprise your business mapped in an intuitive graphical form lets you easily determine the root cause of failures.

Using the map, what-if scenarios can be analyzed to see what impact an anticipated change will have on your business, or more importantly, what may happen if the change is unsuccessful.

Using the Change Impact Analyzer feature, you can do the following:

Define the elements of your business

Map the relationships between these elements

Track the status of each element

View and manage relationship information in a hierarchical graphical map



How the Change Impact Analyzer Works

Change Impact Analyzer works as an integrated feature of Unicenter Service

Desk to manage your assets, which are the key elements of your business.

Change Impact Analyzer uses Unicenter Service Desk asset information in conjunction with the Unicenter NSM WorldView product, which provides the visual tool to view and manage these business elements and their relationships in a graphical environment. Communication between the

Unicenter Service Desk daemon server and WorldView is accomplished utilizing a Windows service routine. This communication allows the transfer and synchronization of asset data between Unicenter Service Desk and WorldView, which is critical to keeping WorldView refreshed with the most up-to-date asset information from the Unicenter Service Desk database. Asset information includes asset status and relationship data. It is this data, when viewed graphically in WorldView, which lets you see the real-time statuses and relationships of assets and identify problems to formulate solutions. You can also introduce changes to the current WorldView map in order to see the impact that changes will have on your organization.

Through menu items in the interface, Unicenter Service Desk provides the facilities to export asset information to WorldView, synchronize status information between the two systems, and view and maintain relationship information. In addition, Change Impact Analyzer provides command line utilities that can be run on-demand. Most of these utilities are run automatically during initial setup or can be run directly from the Unicenter

Service Desk interface. They are provided as stand-alone components for flexibility in managing the Change Impact Analyzer integration.



Change Impact Analyzer and WorldView

The Change Impact Analyzer feature is integrated into Unicenter Service Desk.

There are no separate installation steps that need to be performed to use the functionality.

The Impact Analysis feature, available from a Change Order, can be used with or without integration with Unicenter NSM WorldView. Unicenter Service Desk

Change Impact Analyzer integration with WorldView provides these additional benefits:

Facilitates building relationships among assets using the graphical tools of

Unicenter NSM WorldView.

Provides a graphical view of real-time asset status information using

WorldView.

Facilitates root-cause analysis using the graphical WorldView map.

The Change Impact Analyzer and the Unicenter NSM WorldView integration point is currently supported only on the Windows platform. However, it is not necessary for Unicenter Service Desk to reside on the Windows platform.

If your Unicenter Service Desk resides on a platform other than Windows or a

Windows system that does not host WorldView, you should complete the following steps before proceeding.

Set up a Windows system to host the integration.

Install, configure, and test a WorldView Administrative client on this new system. For information on completing this process, see Unicenter NSM documentation.

Install, configure, and test a Unicenter Service Desk Secondary Server with the NSM Integration option on the new Windows Server.

As always, you should test this reconfiguration in an environment that is isolated from your production environment.

Important! Both Unicenter NSM WorldView and Unicenter Service Desk must be configured and operational before integrating Unicenter Service Desk

Change Impact Analyzer and WorldView.



Configure the Daemon

The Unicenter Service Desk Change Impact Analyzer daemon communicates real-time status information to managed objects in the WorldView repository.

To configure the daemon, follow these steps:

1. Use the Unicenter Service Desk pdm_edit utility to configure the Change

Impact Analyzer Daemon, pdm_uspnsm_nxd, to run on the new Windows

Server.

Note: Win client is not a supported configuration. pdm_uspnsm_nxd daemon will require primary or secondary windows server. For further information on how to run the pdm_edit utility, see the appendix

"Reference Commands" in the Administrator Guide. Please follow all instructions, including re-running the USD Configuration utility after successfully executing the pdm_edit utility. During the execution of the pdm_edit utility choose the following option: “9. Edit ( C )hange Impact

Analyzer”. Also, make sure to take the default of “primary” when specifying the “Change Impact Analyzer Host”.

2. Restart the Unicenter Service Desk server.

3. Use the pdm_status command to verify that the daemon is running



The Change Impact Analyzer uses several new Managed Object Classes and associated icons. To verify that these new classes exist, use the Unicenter

Class Browser as follows:

1. Choose Start, Programs, CA, Unicenter, NSM, WorldView, Class Browser.

2. Expand the TNGROOT folder, the ManagedObject folder, and the UBM folder. You should see the following:

If you do not see the UBM folder or any of the classes underneath it, you must use the WorldView Import/Export utility (trix.exe) to load

$NX_ROOT\data\svc_ana\ubm0.tng into each WorldView repository that is participating in the configuration. Be sure to recycle the WorldView Manager services, as well as the Unicenter Service Desk pdm_uspnsm_nxd daemon, after making changes to the WorldView Managed Object Class.



Change Impact Analyzer Integration Considerations

When configuring your system environment to support Change Impact

Analyzer, keep the following in mind:

The utilities of Change Impact Analyzer that interface with WorldView use the Worldview API. Currently, the Worldview API is limited to the Windows platform. Since some Change Impact Analyzer utilities require the

Worldview API, they too are limited to the Windows platform. The following Change Impact Analyzer utilities use the Worldview API or are only supplied as Windows utility executables:

– pdm_nsmbmcls.exe

– pdm_nsmclass.exe

– pdm_nsmimp.exe

– pdm_nsmsync.exe

– pdm_uspnsm_nxd.exe

Change Impact Analyzer works with NSM 3.x WorldView and NSM r11.1

WorldView. Change Impact Analyzer provides for integration with more than one WorldView repository. If you try to integrate with different versions of WorldView, the results may be inconsistent, due to the differences in the class names among the various versions of NSM

WorldView. Change Impact Analyzer relies on both managed object name and managed object class to uniquely identify WorldView objects.

WorldView is case-sensitive. Verify the case for the following:

– Arguments used in running the Change Impact Analyzer integration utilities

– Hostnames in WorldView

– Change Impact Analyzer Repository records

If you use NSM 3.x WorldView Administrative clients connecting to the

WorldView Repository integrated with Change Impact Analyzer, the icons for the seven new Managed Object classes must be manually copied. Copy these icons from $NX_ROOT\data\svc_ana\icons and

$NX_ROOT\data\svc_ana\images and paste them to the appropriate

WorldView directories on the WorldView administrative client machines.

Normally, these icons are installed during CIA Integration and will be installed on the machine on which the integration is run.

Note: Make sure you restart the WorldView services after performing

Change Impact Analyzer integration.



Test the Change Impact Analyzer Integration

To test the Change Impact Analyzer Integration, follow these steps:

1. From the Unicenter Service Desk Web Interface, choose Administration

Tab, Change Impact Analyzer.

Note: There should be multiple nodes listed under Change Impact

Analyzer. If “Maintain Relationships” is the only available option, continue with the rest of this procedure. If there are multiple nodes listed, the integration is successful.

2. Install NSM r11.1 WorldView on a separate machine.

Note: If you install NSM r11.1 Worldview on the same machine as

Unicenter Service Desk, you may encounter problems with the database.

You will need Windows 2003 for NSM r11.1 Worldview.

3. Leave the primary server running.

4. Perform a custom installation of a Unicenter Service Desk Secondary

Server on the machine on which NSM is installed.

Choose Unicenter NSM Integration option on the Select Features window.

5. During Secondary Server Configuration, do the following: a. Configure to use the primary server. b. Select Integrate with Change Impact Analyzer.

Note: The domsrvr should be running on primary.

6. Run pdm_edit.pl in the PRIMARY server, adding the Change Impact

Analyzer. Use the SECONDARY server’s hostname when asked.

7. Copy the generated pdm_startup.rmt file to $NX_ROOT/pdmconf, rename it to pdm_startup.tpl, and re-run Configuration on the Primary Server.

To verify the presence of the nodes, login to the Web Interface and select

Change Impact Analyzer from the Administration Tab, Service Desk,

Application Data, Assets. There should be more than one node listed.

Set up Change Impact Analyzer Integration

After you have completed the required installations and configurations, the next step in implementing Change Impact Analyzer is to populate the reference tables with the data needed for integration.



Change Impact Analyzer Classes

The first table populated by the installation of the Change Impact Analyzer is the Change Impact Analyzer Class table. This table is used to map Unicenter

Service Desk Asset Classes to Unicenter NSM Managed Object Classes.

To verify the presence of these classes, login to the Unicenter Service Desk

Web Interface and select the Administration Tab, Classes, Service Desk,

Application Data, Assets, Change Impact Analyzer. If you see classes in the

Change Impact Analyzer Classes List proceed with Map Change Impact

Analyzer Classes to Asset Classes (see page 137).

If you see nothing in the Change Impact Analyzer Class List, run the pdm_nsmbmcls utility from the DOS command prompt. It will read all the

Managed Object Classes from the WorldView repository and populate the

Business_Management_Class table in Unicenter Service Desk.



If multiple WorldView repositories are being used, and you have created custom Unicenter NSM Managed Object Classes, the pdm_nsmbmcls utility should be run for each of the repositories that you plan on using.

Run pdm_nsmbmcls –h to display information on the available command line options.

After the Change Impact Analyzer Classes are populated, several additional options will be available in the Unicenter Service Desk Web Client

Administration tab for maintaining the Change Impact Analyzer integration.



Define WorldView Repositories

Change Impact Analyzer integration requires that at least one Unicenter NSM

WorldView repository be defined. This record defines the WorldView Repository by hostname and the credentials that the Change Impact Analyzer daemon will use to sign on the repository.

To maintain the repository definitions, follow these steps:

1. Select Administration, Service Desk, Application Data, Assets, Change

Impact Analyzer, Repository Configuration.

The Change Impact Analyzer Repository List appears.

If no repository is defined, click Create New to create a new repository.

Note: When defining the new repository, you must first save the definition by clicking on the Save button before providing login information on the

NSM Credentials tab.

2. Click the repository link under the Symbol column.

The Update Change Impact Analyzer Repository window appears.

3. Edit the repository record by filling in the Symbol and Repository fields.

4. Click NSM Credentials

The NSM Credentials window appears at the bottom of the screen.



5. Click Save.

The NSM WorldView Repository definition is saved.

6. Click Change Repository Login to save the User ID and Password for the

Repository.

7. Click Test Repository Login to ensure that the credentials are correct.

The Change Impact Analyzer daemon, pdm_uspnsm_nxd, attempts to connect to the Repository. A successful test updates the daemon’s in-memory cache of repositories and will begin using the new credentials when it needs to communicate with the repository. If you skip this step, the repository is not available until Unicenter Service Desk server is recycled.

Note: The User ID provided must have “dbowner” rights to the WorldView database for Change Impact Analyzer functionality to work properly. Often

WorldView requires that the hostname be uppercase.



Map Change Impact Analyzer Classes to Asset Classes

The Change Impact Analyzer Classes are mapped to Asset Classes manually using the Change Impact Analyzer Class field or automatically by running the pdm_nsmclass utility.

Map Manually

To manually map each Asset Class to a Change Impact Analyzer Class, follow these steps:

1. Choose Administration, Service Desk, Application Data, Assets, Asset

Classes.

The Class List window appears.

2. Click the available Class.

The Asset Class Detail window appears. Click Edit to display the

Update Class window.

3. Click the Change Impact Analyzer Class to map the asset.



Run pdm_nsmclass to Map Automatically

The pdm_nsmclass utility, run from command prompt, uses a file to map each Asset Class to a Change Impact Analyzer Class. Before running pdm_nsmclass review the sample $NX_ROOT\site\nsmclsmap.dat file.

Keep the following in mind:

Each line in the sample file maps an Asset Class to a Change Impact

Analyzer Class.

If pdm_nsmclass finds an Asset Class that has no corresponding entry in the nsmclsmap.dat file, it will map the Asset Class to the

“Component” Change Impact Analyzer Class by default. If required, the default Change Impact Analyzer Class can be changed with a command line option. pdm_nsmclass will only update Asset Classes that have no Change

Impact Analyzer Class selected. A command line option lets you reset the Change Impact Analyzer Class of all Asset Classes.

Run pdm_nsmclass –h to display information on the available command line options.

If you are running Unicenter Service Desk with a case-sensitive DBMS, such as Oracle, pay extra attention to the case of your entries in nsmclsmap.dat file. The mapping is case-sensitive.



Create Change Impact Analyzer Relationships

Successful implementation of Change Impact Analyzer requires careful planning. This section uses an example scenario to walk you through the basic steps involved in the planning and analysis of a business process, and adding that process into Change Impact Analyzer.

Do not try to map your whole organization at once. Organize your business into manageable sections. Your business is more than IT hardware. The following new Unicenter NSM Managed Object Classes are available to help you represent non-IT related elements:

Document

Practice

Process

Service

Component

Role

Person

In this sample scenario, you are the Unicenter Service Desk administrator at

Myco Industries, Inc., which recently implemented Change Impact Analyzer.

You are going to add the password reset process to Change Impact Analyzer.

The following steps are required:

Install the Sample Data (see page 140)

Analyze the Process (see page 140)

Import Change Impact Analyzer Relationships (see page 141)

Create Assets (see page 143)

Export Assets to WorldView (see page 144)

Organize Relationships (see page 147)

Examine Change Impact Analyzer Relationship in Unicenter Service Desk

(see page 148)



Install the Sample Data

Use the sample WorldView data to help you with the Change Impact Analyzer integration. This sample data is located in the $NX_ROOT\samples\assets subdirectory on the Unicenter Service Desk server, and is loaded using the

WorldView Import/Export utility (trix.exe).

Analyze the Process

To install the sample WorldView data, follow these steps:

1. Copy myco_demo.caz to a temporary directory on your NSM WorldView server.

2. Change to the temporary directory in a DOS prompt window.

3. Extract the sample data file using the command:

Cazipxp –u myco_demo.caz

This uncompresses the file myco_demo.tng.

Note: The cazipxp utility is available from CA's SupportConnect website.

(http://supportconnect.ca.com

http://www.supportconnect.ca.com

).

4. Load the myco_demo.tng file using the Unicenter NSM WorldView

Import/Export Repository utility (trix.exe).

For more information on the WorldView Import/Export utility, see

WorldView documentation.

Analyze the process to determine its dependant elements. This helps you determine the assets that need to be created to represent these elements.

Your analysis of the password reset process determined that it has two dependant elements: the Password Reset Procedure Document and the

Password Reset Administrator Role. The Password Reset Process itself is dependant upon the Help Desk Practice, because this is the department that handles the password reset procedures.

Help Desk Practice

– Password Reset Process

Password Reset Procedure Document

Password Reset Administrator Role



Import Change Impact Analyzer Relationships

Import the logical relationships between assets in WorldView into Unicenter

Service Desk as Change Impact Analyzer Relationships.

To import the relationships, follow these steps:

1. Right-click on the top-level object of a Relationship in WorldView that you want to import to Unicenter Service Desk.



2. Select Read Impact Analyzer.

The pdm_nsmimp utility is launched to import the Change Impact Analyzer

Relationships to Unicenter Service Desk.

Note: The name of the WorldView Managed Object chosen for import will be used as the name of the Change Impact Analyzer Relationship in




Create Assets

In Unicenter Service Desk, create the appropriate assets to represent the elements of the business. Refer to the Unicenter Service Desk Web Interface online help system for specific instructions.



Export Assets to WorldView

To export Assets to WorldView, follow these steps:

1. From the Unicenter Service Desk Web Interface, choose Administration,

Service Desk, Application Data, Assets, Change Impact Analyzer, Export

Assets to NSM.

The Export Assets window appears.

2. Click Add Assets.

The Assets to Export Search window appears.



Refine the search criteria to find each of the four assets that were just created. Multiple searches are required to find all four assets.

3. Select the Assets from the Available Assets list and add them to the Assets to Export list and click OK.

The Export Configuration Items to NSM window appears.

4. Select the Target Repository. This is the repository to which the assets will be exported.

5. Select the Target Object folder. This controls the WorldView container in which the assets will be placed. If not specified, the objects will be created in the ManagedObjectRoot folder.

Important! Normally any child assets, of the assets that were selected for export, that are found will be exported. The hierarchical relationships are recreated in WorldView. The Exclude Child Assets options exports only the selected assets and excludes any child assets.

6. Click the Export Assets button to start the export process.

When the export completes, you are notified.

Once exported, the assets are placed in the ManagedObjectRoot folder in

WorldView.



When assets are exported to Unicenter NSM WorldView, the repository is automatically assigned.

Note: Certain WorldView Managed Object classes require additional, nonstandard Instance Level Properties that can't be anticipated. When the Change

Impact Analyzer daemon tries to create Managed Objects using these classes, the creation will fail. The Change Impact Analyzer Daemon attempts to set these Instance Level Properties from corresponding information contained in the Unicenter Service Desk Asset: Name, Label, IP Address, MAC Address,

Description, Contact and Location. Try to avoid using Managed Object Classes such as: IP_Interface, IP_Network, IP_Subnet, LANBus, and Segment which require additional Instance Level Properties.



Organize Relationships

Now that the assets are in WorldView, you can use the 2D map in Design Mode to define the relationships between your business elements.

Move the folders and documents as follows:

1. Move the Help Desk Practice folder into the Myco Industries Inc folder.

2. Move the Password Reset Procedure Document, Password Reset Process, and Password Rest Administrator folders into the Help Desk Practice folder.

Import the new logical relationship into Unicenter Service Desk by performing the following steps:

1. Right click the Help Desk Practice folder.

2. Select Read Change Impact Analyzer.

The pdm_nsmimp utility is launched to import the Change Impact Analyzer

Relationships to Unicenter Service Desk.



Examine Change Impact Analyzer Relationship in Unicenter Service Desk

To examine the results of the import in Unicenter Service Desk, follow these steps:

1. Choose Administration Tab, Service Desk, Application Data, Assets,

Change Impact Analyzer, Maintain Relationships

The Change Impact Analyzer Relationship List appears.


Portal Integration

2. Check whether the Source Repository is set to the Repository from which it was imported when the Assets are imported from WorldView.

Note: The status in WorldView is considered unreliable. The Change

Impact Analyzer data is owned by Unicenter Service Desk. WorldView is used only to display Unicenter Service Desk information.

Portal Integration

This section discusses accessing Unicenter Service Desk components through

Unicenter Management Portal and CleverPath Portal.

Note: Unicenter Management Portal and CleverPath Portal are not shipped with Unicenter Service Desk, and must be purchased and licensed separately.

This section contains only the most basic information for accessing Unicenter

Service Desk through Portal Administration. For detailed information, see the

CleverPath and Unicenter Management Portal Server Administration Online

Help.


Portal Integration

Verify Unicenter Service Desk Web Interface Accessibility

After Unicenter Service Desk is installed on a system, make sure that you can access the web interface through the tomcat server. For Portal Integration to work, the Unicenter Service Desk Web Interface must be accessible through tomcat.

Note: For Unicenter Service Desk LINUX server installation, the

LD_LIBRARY_PATH must be set to $NX_ROOT/sdk/lib.

Install and Start the Portal

For detailed information on installing, starting, and stopping Portal, see the

Unicenter Management Portal Getting Started Guide or the CleverPath Portal

Getting Started Guide, whichever applies to your installation.

Note: You can install Portal on the system where Unicenter Service Desk is installed, or on a separate system.

Include Portlets

To include Unicenter Service Desk portlets in the portal:

1. Log onto the Unicenter Service Desk and click Search from the Options

Manager on the Administration tab.

The Options List window appears.

2. Click on Portal_Safe_List.

The Portal_Safe_list Detail window appears.

3. Enter the machinename:portnumber where the portal was installed in the Options Value Field. For more information on what this option does, see the online help.

4. Click Install.

5. Restart Unicenter Service Desk daemon.

6. Login to the portal as an administrator.

7. Create a user which is valid Unicenter Service Desk User. For more information on how to create a user, see the portal documentation.


Portal Integration

Note: The password used while creating this user in the portal could be different from the password used by this same user to log into Unicenter

Service Desk as Unicenter Service Desk authenticates the users for this integration using a combination of the following, username, a valid portal session and the portal install value if it exits in the PORTAL_SAFE_LIST option.

8. Select Knowledge from the main Portal menu bar.

The Knowledge page appears.

9. Select Library from the left pane Knowledge bar.

The Library tree appears in the left pane.

10. Select (or create then select, if necessary) a folder in the Library tree, then choose Publish File from the right pane Knowledge bar.

The Publish File form opens.

11. Type the following Unicenter Service Desk portlet URL in the Content text box on the General Information tab: http://hostname:portnumber/CAisd/PortalServlet?USERNAME=$USER.username$&PORTALSESSION=$

SESSION$&PORTALINSTALL=portalhostname:portalportnumber

Note: Substitute hostname:portnumber in the URL with the name and port of the web server on which Unicenter Service Desk resides.

Substitute portalhostname:portalportnumber in the URL with the name and port of the web server on which Portal resides.

12. Type Unicenter Service Desk in the Title text box.

13. Click Advanced.

The Advanced properties page of the Publish File form displays.

14. Type portal/variable-url in the Content (mime) Type field and click

Publish.

The published contents appear in the selected Library folder.

15. Configure the Workplace to show this portlet.

16. Log out and login as the newly created user. You should be automatically logged onto Unicenter Service Desk in the portlet you just created without logging on again.

Note: While running Unicenter Service Desk in the portlet, the preference,

Avoid Popups, is not available in the Preference page and a popup window is always used regardless of the setting of the preference.


Portal Integration

Connect to the Portal Server

To connect to the portal server, open a web browser, and enter the following

URL in the location or address field: http://<servername>:<port#>/servlet/portal where:

<servername>

Specifies the server name (or IP address) of the portal server.

<port#>

Specifies the port number that the portal server monitors. You specified the port number during portal server installation. The default port is 8080.

Configure Unicenter Service Desk to Use SSL with Portal

Note: For production purposes, it is always recommended that you obtain a certificate from a trusted certificate authority.

Before configuring Unicenter Service Desk to use SSL, check to see if the

Portal and Unicenter Service Desk integration works without SSL. If the integration works without SSL, follow the steps in Include Portlets (see page

150).


Portal Integration

Setup SSL Using a Self-Signed Certificate

To set up the Unicenter Service Desk Portal Integration using a self-signed certificate, follow these steps:

1. At the command line, enter:

%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

Answer the prompts appropriately and enter "changeit" as the password for both password prompts.

This sets up the certificate.

2. Edit the server.xml file located in:

$NX_ROOT/bopcfg/www/CATALINA_BASE/conf

3. Uncomment the following section and save:



4. Add keystoreFile attribute to server.xml. (When you run the command in step 1, a .keystore file is created in the user's home directory. Add the reference to the keystoreFile attribute and Save the file. Your server.xml should appear as follows.

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="100" debug="0" scheme="https" secure="true" useURIValidationHack="false" disableUploadTimeout="true">

<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" clientAuth="false" protocol="TLS" keystoreFile="location/.keystore" />

</Connector>

5. Restart Unicenter Service Desk.

6. To check the SSL functionality, point your browser to https://machinename:8443. This should display a Security Alert dialogue. Click Yes.

Note: SSL uses port 8443

7. Replace the Unicenter Service Desk portlet to use HTTPS and port 8443. https://hostname:8443/CAisd/PortalServlet?

USERNAME=$USER.username$&PORTALSESSION=$SESSION$&PORTALINSTALL=portalhostname: portalportnumber


Portal Integration

Connect to Unicenter Service Desk when Portal Uses SSL

To import the Portal Server Certificate so that a trusted connection can be made between Unicenter Service Desk and Portal when it is configured to use

SSL, follow these steps:

1. Verify that Portal is configured and works with SSL.

Note: Refer to the Portal documentation for the verification process.

2. Export the certificate from the box on which Portal is installed by following these steps: a. Locate the server.xml file at the following location:

PORTAL_Install_Dir\jakarta-tomcat-4.1.29\conf. b. Note the keystore location and password (pwd), as illustrated in the following lines in server.xml. The default password is

changeit

(all lower case). If you used a custom password while creating the certificate during the portal setup (for more information, see "Create a

Security Certificate" in the

Portal’s Getting Started Guide

), you will have to use the custom password. In the steps and examples that follow,

changeit

is the default password used:



<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"

port="8443" minProcessors="5" maxProcessors="150"

enableLookups="true"

acceptCount="100" debug="0" scheme="https" secure="true"

useURIValidationHack="false" disableUploadTimeout="true">

<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"

keystoreFile="c:\Program Files\CA\SharedComponents\Unicenter Management

Portal\UMPkeystore"

keystorePass="changeit"

clientAuth="false" protocol="TLS" />

</Connector> c. Navigate to the JRE bin directory (PORTAL_Install_Dir\ jre\bin) on the portal server box to access the keytool utility that you will use for exporting the PORTAL Server certificate to a file. d. Access the keytool utility, using the following command: keytool -export -alias tomcat -file umpserver.cer -keystore "c:\Program

Files\CA\SharedComponents\Unicenter Management Portal\UMPkeystore"

Enter keystore password: changeit

Certificate stored in file <umpserver.cer>

Note: When prompted for the password, be sure to use the password obtained from step 2b. In the previous example,

changeit

is the password noted in step 2b. The keystore location is also obtained from step 2b.

3. Import the certificate obtained from the server to the box containing the

Unicenter Service Desk installation by using the keytool utility, as follows:


Portal Integration

a. On the Unicenter Service Desk box, navigate to the JRE\bin directory directory, typically at the following location:

C:\Program Files\CA\SharedComponents\JRE\bin. b. The certificate should be imported into the Certification authority used by the Unicenter Service Desk Java Virtual Machine.

The following is an example of an import. In this example, the location of the Certificate authority is:

C:\Program Files\CA\SharedComponents\JRE\1.4.2_06\lib\security\cacerts

When prompted for a

pwd

, enter “changeit”. When prompted for

Trust this certificate

, enter Yes.

Keytool.exe -import -alias tomcat -trustcacerts -file umpserver.cer -keystore "C:\Program

Files\CA\SharedComponents\JRE\1.4.2_06\lib\security\cacerts"

Enter keystore password: changeit

Owner: CN=ump001.ca.com, OU=unicenter, O=ca, L=islandia, ST=ny, C=us

Issuer: CN=ump001.ca.com, OU=unicenter, O=ca, L=islandia, ST=ny, C=us

Serial number: 43ecb469

Valid from: Fri Feb 10 10:42:33 EST 2006 until: Thu May 11 11:42:33 EDT 2006

Certificate fingerprints:

MD5: A1:AF:AE:92:39:2E:53:D5:1C:6D:FE:44:68:61:DD:5C

SHA1: 66:3A:BC:77:32:81:60:89:70:B9:EF:FB:74:3D:93:74:CD:8E:E2:D2

Trust this certificate? [no]: yes

Certificate was added to keystore

Note: When prompted for the password, use the password obtained from step 2b. In the previous example,

changeit

is the password noted in step 2b.

4. Edit the file portal-xml-api.xml under

$NX_ROOT\bopcfg\www\CATALINA_BASE\webapps\CAisd\WEB-

INF\xml\portal-xml-api.xml by doing the following: a. Replace http in the line:

<!DOCTYPE PORTAL SYSTEM "http://127.0.0.1:8080/servlet/media/xml/api/request.dtd">

With https:

<!DOCTYPE PORTAL SYSTEM "https://127.0.0.1:8080/servlet/media/xml/api/request.dtd"> b. Save the file. c. If Portal_Safe_List has been installed, make sure you change the portnumber to 8443 and the machine name to include the domain name (for example, machinename.ca.com:8443).

Note: It is important to include the domain name in the machinename as the portal certificate contains the domain name. For more information, see "Create a Security Certificate" in the Portal's Getting

Started Guide. If Portal_Option_List is not installed, see Include

Portlets in this guide, and follow steps 1 through 4.

5. Recycle the Unicenter Service Desk server.



6. From Portal, connect to the Unicenter Service Desk Portlet using the the following url: http://hostname:portnumber/CAisd/PortalServlet?USERNAME=$USER.username$&PORTALSESSION=$

SESSION$&PORTALINSTALL=machinename:8443

Note: Substitute machinename in the url with the name of the web server on which Portal resides. The machine name in this url should include the domain name, for example, machinename.ca.com:8443. Substitute the hostname:portnumber in the url with the name and port of the web server on which Unicenter Service Desk resides.

Mainframe Product Integration

This section describes the Unicenter Service Desk side data (.dat file) associated with mainframe product integrations.

Load Unicenter Service Desk Side Data

The Unicenter Service Desk side data (.dat file) associated with mainframe product integrations is in a list which associates a .dat to mainframe product name.

Note: If the Unicenter Service Desk server is configured to use ITIL methodology, ITIL updates need to be applied to the integration data. Use pdm_userload -a itil_integXXX.dat to apply the updates only after loading the respective integXXX.dat.

Use pdm_userload -f integXXX.dat to load Unicenter Service Desk side data to enable a particular integration. The files are delivered to

$NX_ROOT\data\integrations\.

For further instructions on enabling the calling side (mainframe product side) of the integration, see "CA Common Services for z/OS - Unicenter Service

Desk Integration Guide r11.1", which is included with each mainframe product.

CA Products Currently Using CAISDI

The following table lists the products currently using CAISDI and the associated .dat files:

CA Product Currently Using CAISDI DAT file

Advantage EDBC

BrightStor CA-1 integEDBC.dat integCA1.dat



CA Product Currently Using CAISDI

BrightStor CA-Allocate

BrightStor CA-Disk

BrightStor CA-Dynam/TLMS

BrightStor CA-Vantage

BrightStor CA-Vtape

Unicenter CA-7

DAT file

integAllocate.dat integDisk.dat integTLMS.dat integVantage.dat integVtape.dat integCA7.dat

Unicenter CA-JARS

Unicenter CA-MIM

Unicenter CA-OPS/MVS integJARS.dat integJARSMVS.dat integMIM.dat integOPMVS.dat

Unicenter CA-SYSVIEW integSysview.dat

Unicenter NetMaster Network Management for TCP/IP integNetMaster.dat

Unicenter NetMaster Network Management for SNA integNetMaster.dat

Unicenter NetMaster Network Automation integNetMaster.dat

Unicenter NetMaster Network Performance integNetMaster.dat

Unicenter NetMaster Network Operations for TCP/IP integNetMaster.dat

Unicenter NetMaster File Transfer Management integNetMaster.dat

Unicenter NeuMICS integNeuMICS.dat

CA Products Planning to Use CAISDI

The following table lists the CA products that would use CAISDI and the associated .dat files:

CA Product Planning to Use CAISDI DAT file

Allfusion CA-2e integ2e.dat

Unicenter AutoSys Job Management

Unicenter CA-Bundl

Unicenter CA-11 Restart and Tracking

Unicenter CA-Connect

CA-DASDCheck (?) integAutoSys.dat integBundl.dat integCA11.dat integConnect.dat integDASD.dat



CA Product Planning to Use CAISDI

Allfusion CA-Datamacs

Allfusion Date Simulator

Unicenter CA-Deliver Output Management

Unicenter CA-Dispatch Output Management

BrightStor CA-FAVER VSAM Data Protection

Allfusion CA-FileAge

DAT file

integDatamacs.dat integDate.dat integDeliver.dat integDispatch.dat integFaver.dat integFileAge.dat

Allfusion CA-FileMaster Plus integFileMaster.dat

CA-Filesave/RCS integFileSave.dat

Allfusion Gen (?)

Unicenter GSS (Common component) integGen.dat integGSS.dat

Allfusion CA-InterTest

Unicenter CA-JCLCheck Utility

Unicenter CA-Jobtrac Job Management

Allfusion Joe integInterTest.dat integJCLCheck.dat integJobtrac.dat integJoe.dat

Unicenter CA-LPD Report Convergence

Allfusion CA-Optimizer

Allfusion CA-Optimizer/II

Allfusion Plex

Unicenter CA-Scheduler Job Management

Unicenter CA-Spool Print Management

Allfusion CA-SymDump

Allfusion CA-Verify

Unicenter CA-View Output Archival and Viewing integLPD.dat integOptimizer.dat integOptimizerII.dat integPlex.dat integScheduler.dat integSpool.dat integSymDump.dat integVerify.dat integView.dat


Chapter 5: Migrate Data from Previous

Versions

This chapter contains the information you need to migrate data from an earlier version of Unicenter Service Desk.

Note: The procedures in this section are applicable only if migrating from r6.0 to r11.2.


Before You Migrate

(see page 160)

Run the Migration

(see page 164)


(see page 167)


(see page 174)


(see page 174)


(see page 183)


(see page 184)


(see page 185)

Migration Errors

(see page 189)

Migrate Data from Previous Versions 159

Before You Migrate

Before You Migrate

This section discusses things you should consider before migrating data. The following topics are discussed:

Install r11.2 on a 6.0 System (see page 160)

Install r11.2 on a System without 6.0 (see page 161)

Clean Up the Database (see page 161)

Migrate from a Case-Sensitive Database (see page 163)

You can only migrate to this version (r11.2) of Unicenter Service Desk from the r6.0 version of Unicenter Service Desk. If you need to upgrade from a version earlier than 6.0, you first need to migrate to 6.0, and then migrate to version r11.2.

If you need to upgrade from an earlier version of Service Desk to Service Desk

6.0, and plan to migrate to the r11.2 version of Service Desk on a Windows

2000 Server, the WSCRIPT.EXE needs to be upgraded to the latest version before running migration. This upgrade is necessary for creating the migration.log. To upgrade the WSCRIPT.EXE, download scripten.exe (the script installer) from the Microsoft website (http://www.microsoft.com/downloads/).

Note: Migration to the r11.2 version of Unicenter Service Desk is currently supported for MS SQL Server, Oracle, and Ingres databases. Review Migration

Considerations (see page 183) before running migration.

Install r11.2 on a 6.0 System

This is a simple migration process. Version r11.2 of the Unicenter Service Desk installation will detect the 6.0 version, and will launch an upgrade installation wizard.

Note: When migrating from the 6.0 version to the r11.2 version with a remote

SQL database, you must first run the Service Desk Remote Components

Installer on the SQL database server to configure the database. Make note of the Database User Name and Password. When you run the Migration Wizard on the Service Desk server, enter the same Database User Name and

Password as entered in the Remote Components Installer for the Target

Database User and Password.


Before You Migrate

Install r11.2 on a System without 6.0

If the system on which you want to install version r11.2 of Unicenter Service

Desk is different from the system where version 6.0 is installed, perform the following steps:

1. Install the 6.0 version of Unicenter Service Desk on the new system.

2. Make sure that you implement all 6.0 NX_ROOT/site/mod data to the new

6.0 version of Unicenter Service Desk.

3. Run configuration and point to either the production Unicenter Service

Desk 6.0 database, or a copy of one located elsewhere.

4. Install Service Desk by following the procedures in this chapter.

Clean Up the Database

The migration process takes data from your current database and inserts it into the new MDB database. This process runs faster when there is less data to be moved. Take the time now to do a few simple tasks to remove old, obsolete data from your database. Consider decreasing the amount of data in the following tables which tend to get larger over time.

Note: Before performing any table maintenance, always backup the data before you start. Use the utilities provided with your DBMS or use the pdm_extract or pdm_backup commands. The samples shown here are purely examples. You need to determine if they are appropriate for your environment.

Requests, Change Orders and Issues

The pdm_crarcpurge utility identifies inactive ticket data older than a certain age and archives and purges the data from the Unicenter Service

Desk database. For more information, see the online help.

Notification Log History

The pdm_purge utility completely removes records older than the specified time from the notification log file. These log file records are not archived and cannot be recovered. For more information, see the online help.

Audit Log

If you have enabled any of the audit logging options in Options Manager, consider removing old entries. First use the pdm_extract utility to select the records that you want to remove and save them in a file. For example, to select all Audit_Log records that are older than August 1, 2005 use the following commands: pdm_extract –f “select * from Audit_Log where change_date < DATE ‘2005-08-01’ ” > audlog_old.dat

Then use the pdm_load utility with the –r option to remove them: pdm_load –r –f audlog_old.dat


Before You Migrate

Service Type Events

If you are using the Save History feature of your Service Type Events, completed event records are left in the database. Consider deleting them.

Completed events will have status_flag=1. Canceled events will have status_flag=0. For example, to remove all events that are in complete status use the following commands: pdm_extract -f "select * from Attached_Events where status_flag=1" > atev_old.dat

Then use the pdm_load utility with the –r option to remove them: pdm_load –r –f atev_old.dat

Knowledge

You need not remove old Document FAQ Rating/Voting data or Audit data.

Parameters in the Knowledge Tools Migration dialog allow you to specify the number of days' worth of data that should be retained.

Surveys

Survey response data is stored in the following tables:

– Survey

– Survey_Question

– Survey_Answer

You can use the pdm_extract / pdm_load command combination, as shown in the Audit_Log example above, to extract and remove records from these tables. There is a small chance that some orphan records could be left in the database if the processing of the received survey spanned midnight. This should have no impact.

For example, to remove all the Survey records that are older than

September 2, 2005, use the following commands in this order: pdm_extract -f "select * from Survey where last_mod_dt < DATE '2005-09-02' " > survey_old.dat pdm_load -r -f survey_old.dat pdm_extract -f "select * from Survey_Question where last_mod_dt < DATE '2005-09-02' " > survey_question_old.dat pdm_load -r -f survey_question_old.dat pdm_extract -f "select * from Survey_Answer where last_mod_dt < DATE '2005-09-02' " > survey_answer_old.dat pdm_load -r -f survey_answer_old.dat


Before You Migrate

Migrate from a Case-Sensitive Database

If you are migrating from a case sensitive database, query your database prior to the r11.2 migration to determine if you have duplicate values in any of the unique index key columns due to the case differences.Although the r11.2 database schema differs from the 6.0 database schema, you should be able to locate potential duplicates by identifying the indexes in the 6.0 database which contain unique key columns, and then running queries against those which you suspect may contain duplicate key values. The duplicates should be removed prior to migration to avoid indexing errors.

Note: If duplicates are found before migration, you should modify the previous version's database in Unicenter Service Desk to remove these duplicates. If duplicates are found during migration, you should modify the r11.2 database to remove the duplicates. Then create the index that failed using the syntax provided in the migration error message.

View Index List in 6.0

Depending on the type of database, use one of the following syntaxes to view a list of Unicenter Service Desk 6.0 indexes which contain unique key columns:

For Ingres Server:

SELECT t.table_name, i.index_name, c.column_name, c.key_sequence from iiindexes i, iiindex_columns c, iitables t

WHERE i.index_name = c.index_name and i.index_name = t.table_name

AND i.unique_rule = 'U' and i.system_use = 'U' order by t.table_name, i.index_name, c.key_sequence

For Sql Server:

SELECT o.name AS TableName, i.name AS IndexName, c.name AS ColumnName, k.keyno AS 'Position'

FROM sysindexkeys k LEFT OUTER JOIN sysobjects o ON k.id = o.id LEFT OUTER JOIN sysindexes i ON k.id = i.id AND k.indid = i.indid LEFT OUTER JOIN syscolumns c ON k.id = c.id AND k.colid = c.colid LEFT OUTER JOIN sysfilegroups fg ON i.groupid = fg.groupid

WHERE (i.indid > 0) AND (o.type = 'U') AND (i.indid <> 0) AND (i.indid <> 255) AND (o.name NOT

IN ('dtproperties')) AND (i.status & 2048 = 0) AND (i.status & 2 <> 0)

ORDER BY o.name, i.indid, i.name, [Position]

For Oracle:

Select i.Table_Name, i.Index_Name, c.Column_Name, c.Column_Position from user_indexes i, user_ind_columns c where i.Index_Name = c.Index_Name and i.Uniqueness = 'UNIQUE' AND c.Column_Name <> 'ID' order by i.Table_Name, i.Index_Name, c.Column_Position


Run the Migration

Once you have identified indexes which have duplicates, use the syntax described in the following example to list any duplicates found for a specified index and column name(s).

Example for the code column in the chgcat table:

SELECT *

FROM chgcat

WHERE (UPPER(code) IN

(SELECT upper(code)

FROM chgcat

GROUP BY upper(code)

HAVING (COUNT(UPPER(code)) > 1)))

Run the Migration

This section describes the migration process for MS SQL Server or Ingres database from Unicenter Service Desk version 6.0 to r11.2. Unless stated otherwise, you must run all procedures on the primary server and on any secondary servers.

Follow the Unicenter Service Desk installation procedure for your operating environment as explained in this guide. The process detects that this is an upgrade installation, backs up all files to the $NX_ROOT/migrate/tor11/prer11 directory, and installs new files.

When the installation finishes, the migration wizard is launched automatically.You can also start the migration wizard by running the following command:

Windows

NX_ROOT\bin\migrate_to_r11.vbs

Linux

NX_ROOT\bin\migrate_to_r11.sh


Run the Migration

Migration Interview

Before migration, a number of queries are performed to determine the database connectivity information for both the source and target databases.

The Ingres connectivity is accessed through created Ingres vnodes based on the information supplied during the interviewing.

To complete the migration interview, follow these steps:

1. Click Next on the Unicenter Service Desk Migration Wizard Welcome window.

The Source Connectivity window appears.

2. Enter the source database details and click Next.

The Target Connectivity window appears.

Note: Use the OS logged in user name and password as the Target

Database (Ingres) user name and password.

3. Enter the target database details and click Next.

The Tomcat Port window appears.

4. Enter the port number and click Next.

Note: Tomcat Port is used for attachment document repository servlet port information. Specify the same Tomcat Port number when asked during the configuration that you specified during the migration process. If they are different, then edit the port number for the Document Repository after configuration in order for it to be accessible for use.

The Check Prerequisites window appears, which validates Database

Connectivity and API registration based on the information provided in the previous steps.

At this stage, a check is also done on the diskspace and the memory. The wizard prompts a Recommended Disk Space Window.

5. Click Browse to select a new location or click OK.

The Knowledge Tool Migration inquiry is launched.

Note: The Knowledge Tools migration is launched automatically if it is on the r11.2 system. Otherwise, the files output from the Knowledge Tools

Migration should be moved to the r11.2 system.

6. Click Finish.

This completes the final configuration for the r11.2 settings and the actual migration process begins.


Run the Migration

Migration Process

Initially, the migration wizard runs a validation to check the data sources to determine its progression. Once the validation is completed, the migration is done in four phases and the status window is updated as the migration progresses. A migration.log file is created in $NX_ROOT/logs directory.

Note: During migration you may see errors in the stdlog regarding recurring animator missed firings. These errors are due to the fact that the system is down during migration and are normal errors.

The user interface allows you to start, stop, and restart the migration by recording each successful step and phase within the migration.properties file.

However, when you stop the migration, there are some places when the process does not stop immediately, and runs until after a set of steps are completed.

Once the migration is done, the wizard launches the Unicenter Service Desk

Configuration window. For more information about server configuration, see

Configure the Server (see page 38).

If you need to re-run the Unicenter Service Desk migration, you will not be interviewed unless you rename the following files before running the migration wizard:

$NX_ROOT\site\migration.properties

$NX_ROOT\Mig60ToR11\migration_phase1.properties

$NX_ROOT\Mig60ToR11\migration_phase3.properties

Note: If you need to re-run migration, you will need a clean installation of the database.

Extract Data

In this phase, the migration tool performs the following actions:

1. Extracts all the rows from Source database into xml files. The extraction includes all the modifications: the additional columns in existing tables and the new tables that have been created and defined to Unicenter Service

Desk.

2. Validates a new schema and makes modifications to the r11.2 MDB.

3. Adds new columns and tables, if necessary.



Convert Data

In this phase, the migration tool performs the following actions:

Reads and re-arranges information from the XML files, generated in

Phase1, based on R11.2 database structures.

Resets all necessary foreign keys as primary keys that have changed in the r11.2 MDB.

Replaces ID's used in the previous version's database, when necessary, with UUID's used in the R11.2 database.

Once these changes are made the tool generates the XML data files.

Insert Data

In this phase, the XML data file generated in Phase 2 is parsed, and all the data is loaded into the r11.2 MDB.

Load Scripts

In this phase, the required scripts are loaded and updated to the r11.2 system.

Knowledge Tools Migration

Knowledge Tools migration components are designed to be deployed to and run remotely from the Unicenter Service Desk migration, or run locally from the Unicenter Service Desk migration. Knowledge Tools migration information is also gathered during the interview stage (see Migration Interview). If the

Knowledge Tools migration is local, it displays automatically by the migration wizard.



Migrate From a Remote Machine

Important: If you are using an Ingres database for Knowledge Tools, follow

the instructions in Using an Ingres Database (see page 172) prior to running

the migration.

To migrate Knowledge Tools from a remote machine, follow these steps:

1. Run the migration wizard on the Unicenter Service Desk r11.2 server.

2. Complete the Knowledge Tools dialog to migrate Knowledge Tools data on a remote machine. A message box displays informing you where to move the Knowledge Tools migration files.

Note: Before clicking OK on this message box, follow the remaining steps in this procedure to complete the migration process on the r11.2 server.

3. Copy the KTMig60ToR11 directory from the Unicenter Service Desk r11.2 installation media to the Knowledge Tools server.

4. Register the CRMR11ENU.dll located in KTMig60ToR11 directory using the regsvr32 command. For example, assuming the KTMig60ToR11 directory is located on the c:\ drive, type the following command: regsvr32 C:\KTMig60ToR11\CRMR11.dll

5. Run the R11Migration.exe located in the KTMig60ToR11 directory.

6. For Ingres or SQL Server, enter information on the following dialog as appropriate:





For Oracle, enter information on the following dialog as appropriate:



7. Enter the following details, as appropriate:

"Migrate document FAQ rating/voting data for the last xxxxx days" refers to the bu_trans table.

"Migrate audit data for the last xxxxx days" refers to the ci_asked_ques, ci_audit_trails and ci_audit_trail_data tables.

8. Select the following, as appropriate:

Remove the KT 6.0 shortcuts

If selected, the KT 6.0 shortcuts will be deleted from Start, Programs,

CA.

Redirect the KT 6.0 URLs to the new installation at <xxxxxx> where <xxxxxx> is the URL of the new Unicenter Service Desk installation.

If selected, the KT 6.0 URLs will be redirected to the new r11.2 URL after migration.

Migrate the user's passwords to the default PIN field for users with . . .

Select these options as appropriate to migrate KT 6.0 user passwords to r11.2.

Note: This option is available only for KT stand alone migration.

9. Click Start.

The migration process begins.

10. Upon completion, copy the KTMigrationFiles folder to the destination indicated on the Knowledge Tools dialog.

11. Complete the Unicenter Service Desk/Knowledge Tools r11.2 migration.

Once the Knowledge Tools and the Unicenter Service Desk migrations are complete, run the following Knowledge Tools command to reindex the

Knowledge Documents:

NX_ROOT/bin/pdm_k_reindex.exe



Using an Ingres Database

If the Knowledge Tools database is Ingres, perform the following steps before starting the Knowledge Tools migration utility:

1. Create the following directory structure:

=> %NX_ROOT%\migrate\tor11\prer11

2. Create a text file named "NX.env".

3. Edit the NX.env text file and add the following line:

=> "@II_SYSTEM='Your base ingres 2.6 location goes here'

(example: "@II_SYSTEM=C:/IngresII")

Run the migration.

Stand-Alone Knowledge Tools Migration

For migration of stand-alone Knowledge Tools to the r11.2 version of Unicenter

Service Desk, follow these steps:

1. Install and configure version r11.2 of Unicenter Service Desk on the system and restart the machine (see Install and Configure Unicenter

Service Desk (see page 21)).

2. Confirm that Unicenter Service Desk Server services are stopped, and

Windows Services manager is not running (required for Windows 2000).

3. Manually invoke the migration utility from:

$NX_ROOT\bin\migrate_to_r11.vbs.

4. Follow the instructions in the Migration Wizard to complete the Knowledge

Tools migration process.

Note: In some situations, the migration process may fail with a "Schema

Validation" error.

If the migration process fails, follow these steps:

1. From the command line, run the following command: pdm_configure -m

2. Wait three minutes for it to complete (there will be no indication of completion).

3. Manually invoke the migration utility from:

$NX_ROOT\bin\migrate_to_r11.vbs.

4. Follow the instructions in the Migration Wizard to restart the migration process where it left off.



Knowledge Tools Migration Tips

This section lists tips and considerations to keep in mind when performing a migration:

1. The errors that may occur during the extraction of Knowledge Tools data into XML files are logged in MigrationKT.log. The log file is located in the

$NX_ROOT\Mig60ToR11\phase2_kt directory when Knowledge Tools is on the same system as Unicenter Service Desk. The log file is located in the

Mig60ToR11\KTMigrationFiles directory, if Knowledge Tools (or the

Keyword Search) data is on a different system.

2. If you cancel migration extraction while it is running, the process will run to a checkpoint, record the activity in the log file, and then halt. This will allow for rollback if the process is terminated.

3. The Knowledge Tools “CRM_CONTACTS" table is migrated in a Knowledge

Tools stand-alone migration, when Knowledge Tools is not integrated with


4. After the Knowledge Tools migration is done, to enable the embedded images inside documents, copy the Knowledge Tools 6.0 images library directory (usually the UploadedImages directory), to

$NX_ROOT/bopcfg/www/wwwroot.

5. The Knowledge Tools administrator settings for Allow Users to Submit

Knowledge will not migrate to R11.2. Instead, the administrator can allow

Document Creation for each access type in the access type form. The default value will be "Yes" for all access types.

6. The Knowledge Tools 6.0 custom field names are not migrated to r11.2.

7. The following two new tags have been added to the document template:

Related Tickets

Properties

If the default order of the tags was not changed using the HTML editor in the previous version, the migration will place the new tags between the

Related Categories and Comments tags. If the order of the tags was changed in the previous version, the new tags will be added at the end of the template after migration.



Change Impact Analyzer Migration

The following are the Change Impact Analyzer post-migration tasks:

1. Configuration changes made to the Change Impact Analyzer daemon using the pdm_edit utility are not migrated. Run pdm_edit to redo the configuration changes.

2. If you have upgraded to NSM WorldView r11.1:

Review the defined Logical Repositories. You may define a new

WorldView Logical Repository for the Change Impact Analyzer integration to use. The Repository field and the NSM Credentials of the

Change Impact Analyzer Repository records must match the

WorldView Logical Repository definitions. These values are casesensitive.

Click Change Repository Login and reset the User ID and Password.

Click Test Repository Login to verify the credentials and update the real-time daemon cache.

3. If you are using NSM 3.x:

Review the Repository fields of the Change Impact Analyzer Repository records and verify that they match the hostname of the server hosting

NSM 3.x. These values are case-sensitive.

Click Change Repository Login and reset the User ID and Password.

Click Test Repository Login to verify the credentials and update the real-time daemon cache.

4. Review the Asset Class – Change Impact Analyzer Class mappings. This is especially important if you have upgraded NSM because class definitions may have changed. Each Asset Class contains a field that allows you to select a corresponding Change Impact Analyzer Class. You can set these manually or use the pdm_nsmbmcls and pdm_nsmclass utilities. If you use these utilities, review the nsmclsmap.dat file first.

Post Migration Steps

Once the migration is completed, you may need to perform some or all of the tasks described in the following sections.

Note: The Unicenter Service Desk Services should be running when you perform these tasks.



Register Assets

Register the assets that were migrated from the previous version as follows:

1. Run pdm_configure.

2. Run pdm_reg_assets -fv

This registration can be run while users are accessing the system. Depending upon the number of assets migrated, the registration process may take considerable amount of time. You can cancel the process at any point and start it again; it will restart registration from where it last left off. If records are skipped during the first run because the asset was being edited by another user, you can re-run the registration process.

Reset Web Director

If you used Web Director in Unicenter Service Desk 6.0, run pdm_edit to reset your Web Director parameters after running migration. This needs to be done in order for registration to pick up the skipped assets.

Update Shared File Repositories

If Shared File repositories existed on the database (for attachments), you need to update them based on the following guidelines prior to accessing them for upload or download:

If the share resides on a server that runs the r11.2 version of Unicenter

Service Desk, specify the local path to the physical directory in the Upload

Path.

If the share resides on a server that does not run the r11.2 version of

Unicenter Service Desk, it needs a dedicated drive mapping on a server that runs on r11.2 of Unicenter Service Desk. This permanent mapped path should be specified as the Upload Path on the repository record. The user will no longer need to map to the shared drive, only the server will require access.

Note: Mapped drive repositories are not supported on WIN2003.

The r11.2 version of Unicenter Service Desk does not support UNC file names. You must manually update the repository record after the migration.

Note: Repositories defined on servers other than the Primary must be validated after migration is completed. These servers should have a secondary server set up on them. Repositories defined on the Primary server will be set correctly.



Improve Knowledge Tools Performance

The following steps may improve the performance of Knowledge Tools after migration:

1. To improve Ingres Database Performance for Knowledge Tools, run the following command bop_cmd -f reorg.frg "reorg()"

This reorganizes the tables and recreates all indexes. This process takes some time. Once the execution is complete, issue the following command: ktoptdb

This optimizes the database on Knowledge Tool tables.

You should optimize the database after migration and also after importing a large number of documents, especially on following tables:

optimizedb -zk -umdbadmin mdb -rskeletons optimizedb -zk -umdbadmin mdb -rindex_doc_links optimizedb -zk -umdbadmin mdb -rebr_fulltext optimizedb -zk -umdbadmin mdb -rebr_fulltext_adm

2. If you are migrating from a release earlier than 6.0 of Unicenter Service

Desk, note that the format of the val_fieldupdate_site() trigger has changed. Review the examples in

$NX_ROOT\samples\call_mgt\chg_site.mod, cr_site.mod and iss_site.mod. This trigger can be used to automatically log changes to user-defined fields in the ticket's Activity Log. If you have an adaptation that uses this trigger, review your coding and adjust as necessary to ensure proper operation and prevent error messages in the logs.

3. Run the following Knowledge Tools reindexing command:

NX_ROOT/bin/pdm_k_reindex.exe



Edit Access Types

You may need to perform the following edits to access types after migration:

1. Login as a contact that is using the out-of-box Administrator access type.

Manually edit all Access type records that were created in Unicenter

Service Desk 6.0. The Unicenter Service Desk Analyst, Unicenter Service

Desk Administrator, Knowledge Manager, and Knowledge System

Administrator entries on the Web Interface tab need to be set as appropriate for using the Access type records.

2. After migration, you will be not be able to access the Web Interface as any user associated with an Access Type not delivered in version 6.0. To enable web access for these Access Types, log into the Web Interface as a user with Administrator access, select the Administration tab, and enable the appropriate check boxes on the Web Interface and Knowledge Tools tabs.

Forms

Forms in the previous version that include "where" clauses may not work properly after migration. When using a "where" clause in the HTMPL file, you need to have the character “U” in front of the UUID type ID. For example:

<PDM_LIST PREFIX=list

WHERE="ANALYST_ID=U'$cst.id'"

FACTORY="USP_PREFERENCES">

This modified PDM_LIST statement shows a list of the user preference records owned by the login user.

Activity Notification Message Templates

The HTML-formatted Activity Notification Message Templates that can be used with email notifications are new in the r11.2 version of Unicenter Service Desk.

These HTML Message Templates are installed during the r11.2 installation, but are not installed during migration from 6.0. If the recipient's email reader supports HTML, it will show the HTML message rather than the plain text message. If you have customized your Message Templates, your customizations will not be included in the new HTML templates.

These HTML Message Templates are supplied in files, and can be loaded if you would like to use them. The files are located in the $NX_ROOT\samples\data directory:



html_ntf_chg.dat Sample HTML Message Templates for Change Orders html_ntf_cr.dat Sample HTML Message Templates for Request html_ntf_iss.dat Sample HTML Message Templates for Issues html_ntf_itil.dat Sample HTML Message Templates for Requests,

Problems and Incidents for ITIL installations

Before loading these templates, backup the following tables containing your existing Message Templates:

pdm_extract Act_Type > aty_backup.dat pdm_extract Spell_Macro > macro_backup.dat

The new files can then be loaded as follows: pdm_load –f html_ntf_chg.dat.

To display an e-mail notification containing multi-byte characters correctly on your e-mail client, make the following changes to the NX.env file and re-cycle the services:

By default on localized OS (for example, Win2K3-Japanese) with English

Unicenter Service Desk installed, the NX.env file contains the following entries:

NX_CHARSET = <charset supported by the localized OS >

(for Windows-Japanese, it is "shift_jis")

NX_MAIL_SMTP_HEADER_CHARSET = windows-1252 and NX_MAIL_SMTP_BODY_CHARSET =iso-8859-1



Change the code to the following:

NX_MAIL_SMTP_HEADER_CHARSET = <charset supported by the localized OS> and NX_MAIL_SMTP_BODY_CHARSET = <charset supported by the localized OS>

(for Windows-Japanese, it is "shift_jis")

On Linux, NX.env by default contains the following entries:

NX_CHARSET = <corresponding character set of the localized Language entered on “Character Encoding” screen during configuration of Service Desk>

For example: euc-jp for Japanese Linux, gb2312 for Simplified Chinese, and so on.

NX_MAIL_SMTP_HEADER_CHARSET = iso-8859-1 (regardless of the language)

NX_MAIL_SMTP_BODY_CHARSET=iso-8859-1 (regardless of the language)

Modify NX.env as follows:

NX_CHARSET = <corresponding character set of the localized Language entered on the “Character

Encoding” dialog during configuration of Service Desk>

NX_MAIL_SMTP_HEADER_CHARSET = <same value as for NX_CHARSET>

NX_MAIL_SMTP_BODY_CHARSET= <same value as for NX_CHARSET>

Restart the services for the changes to take effect.

SITEMODS.JS File

Lines of code added to the sitemods.js file of the previous version, called from an HTMPL page, must be merged into the r11.2 sitemods.js file before the code will work.

Version Control File

If you created a custom.ver version control file in the previous version of

Unicenter Service Desk, you must remove the file and create a new custom.ver file for r11.2 of Unicenter Service Desk.



Remove Duplicate Key Values

If you have already run the migration and received errors indicating that an index could not be created due to duplicate key values, use the syntax as described in the following example to locate duplicate keys in your r11.2 database for Unicenter Service Desk.

Important: After you remove duplicates, you must manually create the index which failed, using the index syntax provided within the migration error message.

The following example syntax for the code column in the chgcat table will provide a count for each duplicate code value, regardless of case:

Ingres:

select upper(char(code)),count(*) from chgcat group by upper(char(code)) having count(*) > 1

Sql Server and Oracle:

select upper(code),count(*) from chgcat group by upper(code) having count(*) > 1

If you prefer to view the full contents of the duplicate rows, the following alternative syntax can be used:

Ingres:

select * from chgcat where upper(char(code)) in

(select upper(char(code))

FROM chgcat

GROUP BY upper(char(code))

HAVING (COUNT(UPPER(char(code))) > 1))

Sql Server and Oracle:

select * from chgcat where upper(code) in

(select upper(code)

FROM chgcat

GROUP BY upper(code)

HAVING (COUNT(UPPER(code)) > 1))



Adjust Access Type and Data Partition Settings

If you used customized access types and data partitions in the previous release of Unicenter Service Desk, there can be a problem with the Knowledge

Tools data partitions settings after migration. This can cause a problem with the permission groups settings on categories and documents. For example, a user may see restricted information.

Note: Even if you once deleted a data partition or an access type, and then re-created it, you must verify your access type and data partition settings after migration. Follow these steps after migration:

From the Administration tab click on the Access Types book under Security.

Then, for each access type do the following:

1. Right-click on the Access Type name and select Edit.

2. Look at the 'Data Partition Name' field. If this field is empty, there is no data partition associated with the selected Access Type. This means the user will have no restrictions and can access any document or category in the application, even if permission groups are set up. This is may be appropriate for administrators, but not for all access types. So, if there is no data partition associated with the Access Type, you will have to create a new one or select an existing one.

Next, you will need to verify the Majic code Constraint settings for both the

SKELETONS table (used for Knowledge Documents) and the O_INDEXES table

(used for Knowledge Categories).

1. In the left tree, click the Data Partition Constraints book under Security>

Data Partitions.

2. Click on the Show Filter button and enter the Data Partitions used in previous steps. You can use the Table Name field in the Search area to limit your list. For example, enter SKELETONS or O_INDEXES in the Table

Name field and click the Search button.

The typical out-of-the-box settings for Constraints are listed as follows:

Constraint Settings for Customer (like) and Employee (like) Data Partitions should be:

SKELETONS table:

View constraint as:

'SKELETONS READ_PGROUP in @root.pgroups and ACTIVE_STATE = 0'

Pre-update and Delete constraint:

'id = 0' (Note that id=0 means no access)

O_INDEXES table:

View constraint as:



READ_PGROUP in @root.pgroups

Pre-update and delete constraint:

WRITE_PGROUP in @root.pgroups

Constraint Settings for Unicenter Service Desk Analyst (like), Knowledge

Managers (like) and Knowledge Engineers (like) should be:

SKELETONS table:

View constraint as:

(ACTIVE_STATE >=0 )and (READ_PGROUP in @root.pgroups OR

(ACTIVE_STATE > 0 AND ASSIGNEE_ID = @root.id) OR

(ACTIVE_STATE = 0 AND OWNER_ID = @root.id)) Active


(ACTIVE_STATE >= 0) AND (WRITE_PGROUP in @root.pgroups OR

(ACTIVE_STATE > 0 AND ASSIGNEE_ID = @root.id) OR

(ACTIVE_STATE = 0 AND OWNER_ID= @root.id)) Active

O_INDEXES table:

View constraint as:

READ_PGROUP in @root.pgroups


WRITE_PGROUP in @root.pgroups



Migration Considerations

This section lists things you should keep in mind during migration:

1. Foreign Keys (SRELs) that reference tables, whose primary key is now a

UUID, are changed from integer type to UUID type (or BYTE 16).

2. The MDB provides a consistent database schema for a wide variety of IT management data. During the development of the MDB, data elements from the previous version of Unicenter Service Desk and Knowledge Tools were incorporated into this schema. The size of the data elements may increase and, consequently, increase the overall database size. However, if you have increased the size of the standard data elements beyond the column width defined for the MDB, there may be some data truncation in these elements during the migration process. Messages will alert you to any truncation that occurs during migration.

3. Referential integrity issues detected by the migration program when attempting to reset foreign keys will result in errors in the migration.log file. The associated foreign key will be set to a pre-defined valid reference.

4. The r11.2 version of Unicenter Service Desk includes a redesigned File

Attachment component. After a migration, any previously existing repositories and file attachments are still accessible, with one exception.

Shared file repositories will only be accessible if the repository daemon is running on a machine that can access the shared file. This means that the server name on the repository record (detail form) must be a Windows machine that has access to the share. A Unicenter Service Desk repository daemon must also be running on the machine.

Note: After a migration, the process of downloading attachments differs depending upon when they were attached. Existing attachments (uploaded prior to a migration) will be downloaded and must be unzipped before you can view them. Any attachments uploaded by means of the r11.2 client interface of Unicenter Service Desk will be unzipped before being downloaded and are viewable immediately.

5. If you have written custom reports that access database tables from previous versions that have been moved to newly named tables, and the column names that have been changed in the r11.2 version of Unicenter

Service Desk, refer to the appendix, "Changes to Database Schema" in the

Release Impact Guide

.

6. Migration to the r11.2 version of Unicenter Service Desk will retain the customizations on the forms from the previous version. However, you will not see the new r11.2 functionality on the migrated customized forms.

If you need the r11.2 functionality and would like to preserve your customizations, you will need to redo the customizations on a base r11.2 form, which has the new functions.

7. Hyphens contained in Knowledge Documents may not migrate properly.



Install/Remove Migration Views

To help you continue working with customized reports that use ODBC, and prevent you from having to modify them, you have the option of installing a set of views that mimic the tables that were replaced by ca_xxx (or common tables) in the MDB. These views are not required for reports delivered with


There is a corresponding script to remove the views once the customized reports have been converted to access the new CA-MDB tables.

Note: The following commands must be run on a system local to the DBMS.

For Ingres, the scripts are stored in NX_ROOT/samples/views/ingres.

To install the views, issue the following command: sql -umdbadmin mdb < IngresCreateMigViews.sql

To remove the views, issue the following command: sql -umdbadmin mdb < IngresDropMigViews.sql

For SQL Server, the scripts are stored in NX_ROOT/samples/views/SQLServer.

To install the views, issue the following command: osql -E -n < SQLCreateMigViews.sql

To remove the views, issue the following command: osql -E -n < SQLDropMigViews.sql

For Oracle, the scripts are stored in NX_ROOT/samples/views/Oracle.

To install the views, issue the following command: sqlplus mdbadmin/<password> < OracleCreateMigViews.sql

To remove the views, issue the following command: sqlplus mdbadmin/<password> < OracleDropMigViews.sql



Customized HTMPL Files in Unicenter Service Desk 6.0

Some of the files in the 6.0 version of Unicenter Service Desk are no longer used in the r11.2 version. However, they are required for displaying htmpl files customized in the 6.0 version of Unicenter Service Desk. After migration, you must run the following command to copy the files to specific r11.2 directories so they can be loaded and used by the web interface: pdm_perl $NX_ROOT/bin/migrate_to_r11_web_check.pl

The following lists the source/target directories and the files that will be copied:

1. From the 6.0 version of Unicenter Service Desk’s

NX_ROOT/migrate/tor11/prer11/bopcfg/www/htmpl/web/analyst to the r11.2 version of Unicenter Service Desk’s

NX_ROOT/bopcfg/www/htmpl/web/analyst/legacy:

ci_search.htmpl detail_cr_prp_edit.htmpl detail_crkn.htmpl detail_iss_prp_edit.htmpl

detail_mfr_ro.htmpl detail_vp.htmpl do_svy.htmpl list_mfr.htmpl list_vp.htmpl nr_prop_tab.htmpl svy_thanks.htmpl tour_content.htmpl

tour_frames.htmpl view_svy.htmpl

xx_alg_tab.htmpl xx_resln_tab.htmpl


NX_ROOT/migrate/tor11/prer11/bopcfg/www/htmpl/default to the r11.2 version of Unicenter Service Desk’s

NX_ROOT/bopcfg/www/htmpl/default/legacy:

help_frameset.htmpl cst_ci_search.htmpl loginerr.htmpl




NX_ROOT/migrate/tor11/prer11/bopcfg/www/macro to the r11.2 version of Unicenter Service Desk’s NX_ROOT/site/mods/www/macro:

kt_search_str.mac


NX_ROOT/migrate/tor11/prer11/bopcfg/www/wwwroot/html to the r11.2 version of Unicenter Service Desk’s

NX_ROOT/site/mods/www/wwwroot/html:

cst_menubar.html

Note: The customization in the html file needs to be merged to R11.1.

Keep the customized html file under html directory can cause problem.


NX_ROOT/migrate/tor11/prer11/bopcfg/www/wwwroot/css to the r11.2 version of Unicenter Service Desk’s

NX_ROOT/site/mods/www/wwwroot/css:

tour.css


NX_ROOT/migrate/tor11/prer11/bopcfg/www/wwwroot/img to the r11.2 version of Unicenter Service Desk’s

NX_ROOT/site/mods/www/wwwroot/img:

bg_lines_dark.gif bg_lines_medium.gif

bg_lines_light.gif ca_sheet.gif button_middle.gif button_middle_down.gif button_middle_active.gif button_left_down.gif button_left.gif button_right.gif

button_right_active.gif button_right_down.gif button_left_active.gif pb_blank.gif pb_vert.gif corner.gif button_middle_ns.gif



pb_folder.gif books04.gif ca_logo_black.gif nsm_banner.gif sdo_banner.gif about_top.jpg amo_banner.gif kt_banner.gif tour_lines.gif tour_feature.gif tour_page.gif tour_bottombanner.jpg tour_topbanner.jpg

Update Unicenter Service Desk r11.2 HTMPL Code

The 6.0 attachment code for Unicenter Service Desk does not work in the r11.2 version of Unicenter Service Desk installation since code for the attachment feature in r11.2 changed. In order to make the new attachment work in the 6.0 customized htmpl files, for example, detail_cr.htmpl, detail_chg.htmpl, and detail_iss.htmp, the following htmpl code needs to be replaced with the new r11.2 htmpl code.

6.0 code in Unicenter Service Desk:

<PDM_TAB FILE="xx_attmnt_tab.htmpl" NAME="Attachments" NEW_ROW=Yes> r11.2 code in Unicenter Service Desk:

<INPUT TYPE=hidden NAME="NEW_ATTMNTS" ID="NEW_ATTMNTS">

<PDM_TAB ID=attmnt

SRC="OP=SHOW_DETAIL+HTMPL=xx_attmnt_tab.htmpl+FACTORY=cr+PERSID=$args.persistent_id"

NAME="Attachments" height=300></pdm_tab>



Incompatible htmpl Files

Some of the htmpl files in the 6.0 version of Unicenter Service Desk are not compatible with the htmpl files in the r11.2 version of Unicenter Service Desk.

These files need to be removed from the following 6.0 customization directories of Unicenter Service Desk:

NX_ROOT/site/mods/www/htmpl/default

NX_ROOT/site/mods/www/htmpl/web/analyst

NX_ROOT/site/mods/www/htmpl/web/employee

NX_ROOT/site/mods/www/htmpl/web/customer

The following is the list of incompatible files, which need to be removed:

ahdtop.htmpl

std_head.htmpl std_body.htmpl

std_footer.htmpl login.htmpl menu_frames.htmpl top_splash.htmpl

reports.htmpl styles.htmpl xx_attmnt_tab.htmpl upload_file.htmpl detail_attmnt_edit.htmpl upload_success.htmpl load_properties.htmpl imgbtndata.htmpl load_wait.htmpl scoreboard.htmpl detail_nr.htmpl list_nr.htmpl

Note: These files may or may not appear in the directories mentioned above.


Migration Errors

Migration Errors

This section lists error messages you may see during a migration process, and what, if any, action should be taken.

Errors in Data Extraction Phase

Phase1 ### XML write error while extracting from table table_name

This occurs during the data extraction phase of the migration. Additional debugging messages should follow this error message. Provide this information to technical support.

Errors in Data Reset Phase

04/08 06:28:54.875 ERROR ctct 128 Cannot locate USA in ca_country table

This error occurs during the data reset phase of the migration, when migrating a contact record. The record in the previous version had a value of "USA" in the country column, which the migration attempted to match with what is defined in the ca_country table, and failed.

Errors in Data Loading

The following errors occur during the data loading phase of the migration:

DropIndex ### ca.gcf.util.SqlEx: ALTER TABLE DROP CONSTRAINT: constraint 'constraint_name' does not exist

This error occurs when migration attempts to drop an index which does not exist. The execution of the migration failed to add the index. Ignore this error.


Migration Errors

LoadTable ### org.xml.sax.SAXParseException: Content is not allowed in trailing section

This error indicates that an xml file created by migration is invalid, and it stops the further processing for the table. The SAXParseException details "Content is not allowed in trailing section" may vary from this example. This is a serious error. Contact technical support.

LoadTable 404 ca.gcf.util.SqlEx: Duplicate key on INSERT detected

This error occurs when there is a unique Primary key which is being violated by attempting to insert a row with a duplicate key. The preceding messages will identify the row that migration was attempting to insert.

LoadTable ### ca.gcf.util.SqlEx: Cannot INSERT into table

'"table_name1"' because the values do not match those in table

'"table_name2"' (violation of REFERENTIAL constraint

'"constraint_name"')

This error indicates that the step which drops the indexes was unsuccessful.

The r11.2 version of Unicenter Service Desk contains referential constraints which were not imposed in the previous version of Unicenter Service Desk.

This means that in order to insert a row in the database, rows must already exist in the referenced table. This error should not occur because migration drops all referential indexes prior to loading the data. Review the migration log for additional error messages and contact technical support.

LoadTable ### ca.gcf.util.SqlEx: line 1, You cannot assign a value of type 'long nvarchar' to a column of type 'nvarchar'. Explicitly convert the value to the required type

This error indicates that a migration step was skipped. Contact technical support.

LoadTable ### java.io.UTFDataFormatException: Invalid byte 1 of 1byte UTF-8 sequence

This error indicates that your data contains characters which are not supported by XML. Migration currently supports invalid XML/UTF-8 characters within the range X'0000' thru X'001F', as well X'007F, which may be contained within your data as ASCII control characters. Contact technical support if you receive this message.

LoadTable ### ca.gcf.util.SqlEx: Table 'table_name' does not exist or is not owned by you

LoadTable ### Can not find column column_name in table table_name

LoadTable ### Processing has stopped for this table because the target database does not contain the column noted in the above message


Migration Errors

These errors may occur if migration has difficulty processing user-defined tables or columns. Please contact technical support if you encounter these error messages.

LoadTable ### ca.gcf.util.SqlEx: No value specified for mandatory column 'column_name'

This error occurs when migration attempts to insert a row which does not have a value for a column that is mandatory in the r11.2 version of Unicenter

Service Desk. Data in the previous informational message will assist in locating the row which is causing this error.

AddIndex ### ca.gcf.util.SqlEx: INDEX: table could not be indexed because rows contain duplicate keys

This error occurs when the rows loaded by migration contain duplicate values for the key, while a secondary index has a unique key constraint. There are two reasons for this error.

If the previous version of the database already contained duplicate keys

If the previous version of the database contained references to invalid keys which no longer exist. These invalid references are identified and logged in Phase 2.

Phase 2 creates a “Migration Generated Entry” in the referenced table so that the reference is no longer invalid. To avoid excessive generation of these

“migration” rows, in many cases, but not all, only one such row is created for a particular table, even though more than one value may have been invalid. This situation can lead to the duplicate key error message. For example, you may receive this error for the hier_x0 index if there were multiple invalid parent or child references pointing to a single “Migration Generated Entry” row. Refer to the informational message directly above this error for details about the index and its keys. Use this information and the Invalid SREL (foreign key) messages from Phase 2 to query the r11.2 database in Unicenter Service Desk to identify duplicate key values. It is important to correct these duplicates so that the index can be added. For Beta2, use sql to add the index, using the syntax provided in the log message, after the error is corrected.

AddIndex ### ca.gcf.util.SqlEx: Could not add a REFERENTIAL

CONSTRAINT. Some rows in table 'table_name1' do not have matching keys in table 'table_name2'.


Migration Errors

This error occurs when tables fail to load completely when migration attempts to add the referential constraints. The r11.2 version of Unicenter Service Desk includes referential constraints which did not exist in the previous version. In addition, there are some columns in the r11.2 version database whose values will default to "0" if no value is supplied. An example is the resource_class column in the ca_owned_resource table. If one or more of the previous version's Network_Resource rows did not include a value for resource_class, and you do not have a General_Resource_Class row for id = 0, you will receive this error. Use the information provided in the preceding message to identify the index column(s) in error. It is necessary to correct these references so that the index can be added. For Beta2, use sql to add the index, using the syntax provided in the log message, after the error is corrected.

AddIndex ### java.sql.SQLException: [Microsoft][SQLServer 2000

Driver for JDBC][SQLServer]There is already an index on table

'table_name' named 'index_name'

This error, as identified in the log messages which precedes this message, indicates that migration is attempting to recover from a prior execution of migration, which failed in the middle of the step while adding the indexes. You may receive this duplicate error because some of the indexes had already been added. Ignore this error.


Appendix A: Samples Directory

This appendix contains information on several files in the $NX_ROOT/samples directory that can be modified for use with various external interfaces. These are grouped into various sub-directories. None of the files in the samples directory are executable as originally shipped.

Note: Windows C++ complier, such as Microsoft Visual C++ (which is a part of Microsoft Visual Studio .NET 2003) is a pre-requisite to use

$NX_ROOT/samples/i18n/makei18ndll.bat, which allows a Unicenter Service

Desk administrator to customize the message catalog (pdm.dll) on Windows.

Contents of the Samples Directory

The sample directory contains the following subdirectories and files:

asset

myco_demo.caz

This file contains a sample Business Process View that can be used to test

Change Impact Analyzer.

call_mgt

Contains samples for customization in request management.

gencr.frg

This file can be used in conjunction with bop_cmd to create requests from a command line. All notifications and activity log entries will occur, however no Request Form will display on the server when created. Be sure to read the gencr_readme.txt file to learn the syntax, and how to modify it if necessary. The file should be placed in $NX_ROOT/site/mods/interp, if the directory does not exist, you should create it.

Samples Directory 193


iss_site.mod

This file can be used to enable activity logging of site-adapted fields in issues. This file should be placed in $NX_ROOT/site/mods/majic after it has been changed for the site-adapted fields.

cr_site.mod

This file can be used to enable activity logging of site-adapted fields in requests. This file should be placed in $NX_ROOT/site/mods/majic after it has been changed for the site-adapted fields.

chg_site.mod

This file can be used to enable activity logging of site-adapted fields in change orders. This file should be placed in $NX_ROOT/site/mods/majic after it has been changed for the site-adapted fields.

gencr_readme.txt

This file contains instructions on how to use the gencr.frg file.

chg_site.spl

This file may be modified to change the mapping of attributes when creating a change order from a request. This file should be placed in

$NX_ROOT/site/mods/majic after the appropriate changes have been made.

audlog_site.mod

This file can be used to enable audit logging of site-adapted fields. This file should be placed in $NX_ROOT/site/mods/majic after it has been changed for the site-adapted fields.

Notify_add.spl (UNIX only)

This file can be used to add the request’s log agent, assignee and group to the request notification list. This file should be placed in

$NX_ROOT/site/mods/majic.

Notify_replace.spl (UNIX only)

This file can be used to add the request’s log agent, assignee and group to the request notification list when they are changed. This file should be placed in $NX_ROOT/site/mods/majic.



data

Sample data for loading into the database. As noted, modifications may have to be made before using with your system.

html_ntf_chg.dat

This file contains sample html notifications for change orders. A pdm_userload can be run using this file to load the sample notifications.

This is only necessary on a system that has been migrated from a previous version.

html_ntf_cr.dat

This file contains sample html notifications for requests. A pdm_userload can be run using this file to load the sample notifications. This is only necessary on a system that has been migrated from a previous version.

html_ntf_iss.dat

This file contains sample html notifications for issues. A pdm_userload can be run using this file to load the sample notifications. This is only necessary on a system that has been migrated from a previous version.

html_ntf_itil.dat

This file contains sample html notifications for systems configured for using the ITIL methodology. A pdm_userload can be run using this file to load the sample notifications. This is only necessary on a system that has been migrated from a previous version.

FAXserve (Windows only)

fs-template2.rtf

This file contains a sample template for use with FAXserve.

fs-template.rtf

This file contains a sample template for use with FAXserve.



i18n

Contains resources and scripts necessary to build the product’s global resource and message catalogs.

Note: Other Java components utilize Java resource bundles for their UI strings and messages. Reports, forms, and base-data also contain elements appearing on the user-interfaces and are defined in formats. For more information on this, see the Modification Guide.

This catalog is a repository for user interface (UI) strings and messages utilized by most compiled components and the UI elements of the Unicenter

Service Desk interface (excluding form definitions). The i18n directory further contains a backup copy of the initial out-of-box catalog: pdm.dll (Windows) and pdm.cat (Linux/UNIX). The runtime copy used by the system can be found in %NX_ROOT%\bin\pdm.dll (Windows) and $NX_ROOT/fig/cfg/pdm.cat

(Linux/UNIX).

pdm.mc (Windows only)

This file is an executable that is used to create a pdm.dll file.

pdm.dll (Windows only)

This file contains messages used by Unicenter Service Desk and Unicenter

Knowledge Tools.

pdm.def (Windows only)

This file is used in creating the pdm.dll file.

makei18ndll.bat (Windows only)

This batch file is run to create the pdm.dll file.

makei18ncat (UNIX only)

This script file is run to create the pdm.cat file.

pdm.cat (UNIX only)

This file contains messages used by Unicenter Service Desk and Unicenter

Knowledge Tools.

pdm.txt (UNIX only)

This file contains messages in text format used by Unicenter Service Desk and Unicenter Knowledge Tools.



Message catalog on Windows

To modify, build and deliver the message catalog on Windows, you need a tool for generating Windows resource-only DLLs, such as Microsoft Visual

Studio.NET 2003.

To make the modification, follow these steps:

1. Backup the %NX_ROOT%\samples\i18n directory.

2. Edit the pdm.mc file with an editor capable of saving in Unicode format, such as Notepad.

3. From a command prompt, cd to the %NX_ROOT%\samples\i18n directory.

4. If using MS-Visual Studio, confirm that the proper Microsoft Visual Studio

C++ command line variables have been configured (for example, for

Microsoft Visual Studio .NET 2003, run

<VSINSTALLDIR>\Common7\Tools\vsvars32.bat).

5. Run makei18ndll.bat to generate pdm.dll.

6. Stop the product’s services, copy the generated pdm.dll to the

%NX_ROOT%\bin, and restart services.

Message catalog on Linux/Unix

To modify, build and deliver the message catalog on Linux/UNIX, you need a

Linux/UNIX environment matching the production environment with the gencat utility installed.

To make the modification, follow these steps:

1. Backup the $NX_ROOT/samples/i18n directory.

2. Edit the pdm.txt file with an editor.

3. From a command shell, navigate to the $NX_ROOT/samples/i18n directory.

4. Invoke the script makei18ncat.

5. Stop the product’s services, copy the generated pdm.cat to the

%NX_ROOT/bin, and restart services.

macro_lock

This file contains a spel fragment that can be run using a bop_cmd to turn off locks that are being held by macros.



ntf_meth

These are sample notification methods. As noted, modifications may have to be made before using them with your system. These scripts are all written to run with a Bourne shell interpreter.

Note: Under UNIX, these scripts will run as written. However, on Windows NT, either a third party Bourne shell interpreter must be installed on the server or the scripts need to be rewritten as complied c files, or .bat files. Another possibility is to install a Perl interpreter and translate the scripts to Perl.

hp.pdm_pager0 (UNIX Only) hp.pdm_pager1(UNIX Only) hp.sendpage0(UNIX Only) hp.sendpage1(UNIX Only) pager.p(UNIX Only) sun.pdm_pagera(UNIX Only) sun.pdm_pagerb(UNIX Only) sun.sendpagea(UNIX Only) sun.sendpageb(UNIX Only)

These files contain sample notification methods for pagers. These are only examples and will not necessarily work with different pagers.

pager_notify.pl

This file contains a sample perl script that could be modified and used as a notification method for pagers. Note that it is only a sample and may not necessarily work with different pagers.


sdk sql pdmconf


web.xml.tpl pdm_startup.tpl pdm_edit_usage_notes.htm alias_install.bat web.cfg.tpl pdm_startup.i.tpl pdm_edit.pl

README_files

All of these files are used by pdm_edit.pl to create startup files for a primary server and secondary servers that are configured to run a variety of daemons.

This directory contains a sample file for making Unicenter Service Desk web service calls.

ingres_lockdown_sd_only.sql

This file contains a set of REVOKE statements which will remove the

SELECT privilege on Unicenter Service Desk tables from PUBLIC access.

You may want to run this script in order to manage who has access to these tables.

ingres_lockdown_common.sql

This file contains a set of REVOKE statements which will remove the

SELECT privilege on CA Common tables from PUBLIC access. You may want to run this script in order to manage who has access to these tables.



views

ingres

IngresCreateMigViews

This file contains views for an Ingres database that could be used to allow most reports written for earlier releases to continue to work until the reports can be rewritten to support the current table structures.

Loading these views should only be required to support customized reports written for a previous release.

IngresDropMigViews

This file contains commands to drop the migration views from an

Ingres database.


Appendix B: Import Knowledge Tools

Sample Data

Sample Knowledge data from Knowledge Broker, PCHowTo and Right Answers is provided for your use. If you decide you want to use the sample Knowledge data you must import the data into the Knowledge Tools database. Follow the instructions outlined below to do so.

For a Windows installation:

1. Go to $NX_ROOT\samples\data and unzip SampleData.zip into the same directory.

If you want to customize field data, refer to Customize Field Data (see

page 202) before moving on to the next step.

2. There are four batch files located at $NX_ROOT/bin. These can be run by double-clicking on the batch file, or from a command window. a. ImportSampleData.bat – loads all the sample data files

(ImportKnowledgeBroker.bat, ImportPCHowTo.bat,

ImportRightAnswers.bat) b. ImportKnowledgeBroker.bat – sample data provided by Knowledge

Broker c. ImportPCHowTo.bat – sample data provided by PCHowTo d. ImportRightAnswers.bat – sample data provided by Right Answers

For a UNIX installation:

1. Run the command tar -xvf SampleData.tar from $NX_ROOT/samples/data.

If you want to customize field data, refer to Customize Field Data (see

page 202) before moving on to the next step.

2. There are four shell files located at $NX_ROOT/bin, which can be run from a command window. These files include the following: a. ImportSampleData.sh - loads all the sample data files

(ImportKnowledgeBroker.sh, ImportPCHowTo.sh,

ImportRightAnswers.sh) b. ImportKnowledgeBroker.sh – sample data provided by Knowledge

Broker c. ImportPCHowTo.sh – sample data provided by PCHowTo d. ImportRightAnswers.sh – sample data provided by Right Answers

Import Knowledge Tools Sample Data 201

Customize Field Data

Changing the Imported Document Status:

By default, the status of an imported document is Published. If you need to change the status to Draft, perform the following procedure for every imported document you want changed to the Draft status:

1. Open Headings.txt located in $NX_ROOT/site/cfg.

A template appears containing the property of Status, with the default value of Published.

2. Change Published to Draft.

3. Open ImportKnowledgeBroker.bat and ImportSampleData.bat for Windows or ImportKnowledgeBroker.sh and ImportSampleData.sh for Unix.

4. Replace all words "Published" with "Draft".

Note: These changes should be completed before running any .bat (Windows) or .sh (Unix) file.

Customize Field Data

To customize Field Data on both Windows and UNIX installations, follow these steps:

1. Open the headings.txt file, located at $NX_ROOT\site\cfg, with WordPad.

The file contains 3 paragraphs that appear as follows:

NAME=SampleTemplate_1

DELIMITER={Tab}

FIELDS=CREATION_DATE, TITLE, SUMMARY, PROBLEM, RESOLUTION,

PATH

DEFAULTS=STATUS:Draft, AUTHOR:ServiceDesk, OWNER:ServiceDesk,

INITIATOR:[email protected]

PATH_DELIMETER=~

NEW_LINE_IN_REC=\n

2. On the first line, the Name= refers to these samples:

SampleTemplate_1 – default settings

SampleTemplate_2 – settings for PCHowTo sample

SampleTemplate_3 – data settings for RightAnswers sample data

Note: The sample data from Knowledge Broker is in kbi format and cannot be customized in this manner.


About the Sample Data

3. On the line beginning with DEFAULTS, default values for status, author, owner, and initiator may be set. Note that the value entered here applies to all the sample data, it cannot be set on a document by document basis.

Additional fields may be added to the DEFAULTS line in the same format, if desired.

About the Sample Data

CA is not responsible for the accuracy of the data provided by the various vendors. It is provided “as is” for your use.

KnowledgeBroker

This free KnowledgeBase from KnowledgeBroker contains more than 400 sample solutions to common problems with Microsoft Outlook 2003 and

Outlook XP. Used by Help Desk Analysts and End Users, KBI

KnowledgeBases save time and cut costs by streamlining the support process. Each Outlook solution is short, concise and easy to follow.

Needed graphics are built-in. No clicks on links or outside URLs. Enter a question or key word in your CA Search, select an answer and follow the step-by-step solution. It's that simple.

PCHowTo

To illustrate the power and utility of a multimedia knowledge base,

PCHowTo has assembled a small content library of knowledge items for

Internet Explorer. Integrated into the CA Unicenter Service Desk product in a very simple, straight-forward manner, detailed descriptions on how to set the browser toolbars, manage favorite links, and other useful functions fully enable the user to obtain maximum performance from the product.

These knowledge items are task specific, designed to provide the user with precise information at the time of need. The text is presented with a

“Show Me” link that will display the multimedia feature, allowing users to read or experience the knowledge items.

RightAnswers

This sample title includes a variety of “How To” solutions &" Error

Message” solutions from Microsoft Excel 2003, all designed to fuel selfservice for end-users and improve 1st call resolution rates for support analysts. In addition, you’ll find a sample of our multimedia solutions

(search for “Show-IT”) that show you what to do with sound and video and our automated tasks (search for “Automate-IT”) that actually implement the solution for you!

Import Knowledge Tools Sample Data 203

Index

2

2D/3D Map Error Messages (Windows Only) •

114

A

About the Sample Data • 214

Access the Web Interface • 59

Activity Notification Message Templates • 186

Add Users to CA Workflow Groups • 85

Adjust Access Type and Data Partition Settings

• 191

Analyze the Process • 146, 147 asset • 203

Asset Families and Classes • 74

Assets • 75

B

Before You Integrate • 19, 86

Before You Migrate • 168

Before You Start • 10

C

CA Product References • iii

CA Products Currently Using CAISDI • 163

CA Products Planning to Use CAISDI • 164

CA Workflow Access • 84

CA Workflow Integration • 81

CAE0232E-Repository error code 22 • 116 call_mgt • 204

Can’t resolve host name to an IP address • 118

Cannot find repository file • 118

Change Impact Analyzer and WorldView • 135

Change Impact Analyzer Classes • 140

Change Impact Analyzer Implementation • 132

Change Impact Analyzer Integration

Considerations • 138

Change Impact Analyzer Migration • 183

Character Encoding Field Definitions

(UNIX/Linux) • 38, 43

Check the Slump Connection • 114, 119

Clean Up the Database • 168, 170

Client Installation • 21, 60

Config Options Field Definitions • 39, 55

Configure the Client • 61, 62, 64, 65

Configure the Daemon • 136

Configure the Server • 16, 17, 18, 19, 21, 27,

35, 38, 56, 57, 175

Configure the Web Interface • 18, 58

Configure Unicenter Service Desk to Use SSL with Portal • 159

Connect to the Portal Server • 159

Connect to Unicenter Service Desk when Portal

Uses SSL • 161

Contact Technical Support • iii

Contents of the Samples Directory • 203

Convert Data • 176

Couldn't connect to the server - Please check the network and that server daemons are running. (Socket error 10061) • 116

Create Assets • 146, 150

Create Change Impact Analyzer Relationships •

146

Custom Client Installation • 61, 62

Custom Installation Components • 34, 36, 62

Custom Installation using Oracle Database •

16, 17

Custom Installation using SQL Database • 16,

17

Custom Installation with NSM Integration • 16,

19

Custom Installation with Web Interface • 16,

18

Custom Server Installation • 16, 17, 18, 19,

22, 27, 56

Customize Field Data • 212, 213

Customized HTMPL Files in Unicenter Service

Desk 6.0 • 195

D

data • 205

Define Contacts • 77

Define Event Writer Rules • 100

Define Filter Rules • 95

Define the Business Infrastructure • 73

Define the Business Structure • 70

Define WorldView Repositories • 142

Determine the TCP Service Number • 65, 66

Index 205

E

Edit Access Types • 186 eIAM and CA Workflow • 84 eIAM Field Definitions • 37, 38, 53

Enable Web Engine on Secondary Server • 18,

57

Errors in Data Extraction Phase • 199

Errors in Data Loading • 200

Errors in Data Reset Phase • 199

Establish Contact Types • 79

Examine Change Impact Analyzer Relationship in Unicenter Service Desk • 146, 155

Example • 113

Export Assets to WorldView • 146, 151

Extract Data • 175

F

FAXserve (Windows only) • 205

Filter Error Messages • 114, 118

Filter Events Automatically • 93

Filter Unwanted Events • 19, 92

Forms • 186

G

General Settings Field Definitions • 38, 40

Generic Event Data • 94

Get Started Using Unicenter Service Desk • 69

H

How the Change Impact Analyzer Works • 134

I

i18n • 206

Implementation Type Descriptions • 11

Import Change Impact Analyzer Relationships

• 146, 148

Import Discovered Assets • 90

Import Knowledge Tools Sample Data • 211

Improve Knowledge Tools Performance • 185

Include Portlets • 158, 159

Incompatible htmpl Files • 198

Ingres Database Configuration • 37, 38, 45

Insert Data • 176

Install and Configure Unicenter Service Desk •

21, 181

Install and Start the Portal • 157

Install from a Network Drive • 61, 63

Install Log • 68


Install on a Local Drive • 61, 63

Install r11.2 on a 6.0 System • 168

Install r11.2 on a System without 6.0 • 168,

169

Install Remote Components • 16, 21, 37

Install Silently • 61, 64

Install the Client • 61

Install the Sample Data • 146, 147

Install the Software from a Network Drive • 63

Install the Web Interface • 18, 56

Install/Remove Migration Views • 194

Installation Procedures • 21

Installation Walkthroughs • 16

Integrate Unicenter Service Desk and

Unicenter NSM • 19, 87

Integrate Unicenter Service Desk with Other

Products • 81

Introduction • 9

K

Knowledge Tools Migration • 176

Knowledge Tools Migration Tips • 182

L

Leverage NSM to Unicenter Service Desk

Integration • 122

Load Event Writer Rules • 110

Load Scripts • 176

Load the Software Disk Images on a Network

Drive • 63

Load Unicenter Service Desk Side Data • 163

Locations • 71

M

macro_lock • 207

Mainframe Product Integration • 163

Maintain Filtered Events • 112

Manufacturer and Models • 74

Map Change Impact Analyzer Classes to Asset

Classes • 140, 144

Message catalog on Linux/Unix • 207

Message catalog on Windows • 207

Migrate Data from Previous Versions • 167

Migrate from a Case-Sensitive Database • 168,

171

Migrate From a Remote Machine • 177

Migration Considerations • 168, 193

Migration Errors • 199

Migration Interview • 174

Migration Process • 175

Modify the Current Installation • 68

MS SQL Database Configuration • 17, 38, 47

N

ntf_meth • 208

O

Oracle Database Configuration • 18, 37, 38, 48

Organizations • 72

Organize Relationships • 146, 154

Organize Users into Groups • 79

P

Parameters (Event Writer Rules) • 101

Parameters (Filter Rules) • 97

Parameters (Loading Event Writer Rules) • 111 pdmconf • 209

Portal Integration • 156

Post Announcements Automatically • 91

Post Integration Process • 88

Post Migration Steps • 183

Primary or Secondary Server Components •

10, 14

Primary Server Components • 10, 12

Q

Destination unknown, Queuing events or No topology.cfg file entry for node • 119

R

Register Assets • 184

Remove Duplicate Key Values • 190

Remove Event Converter from the Daemon

Manager • 121

Remove Event Converter from Windows

Service • 122

Reset Web Director • 184

Resource Classes • 84

Review Server Configuration • 114, 117

Review System Requirements • 21, 56, 60

Run the Migration • 173

S

Sample cawto Commands that

Generate/Update Requests • 127

Sample Files to Use with the Integration • 127

Sample Message Records/Actions with Limited

Content • 123

Samples Directory • 203 sdk • 209

Send Generic Event Data (Unix Only) • 91

Server and MDB on Different Machines • 16

Server and MDB on Same Machine • 16

Server Installation • 21, 22

Service Statuses • 74

Set up Change Impact Analyzer Integration •

139

Set Up Event Writers • 99

Set Up Filter Rules • 95

Set Up Users • 76

Setup SSL Using a Self-Signed Certificate •

160

SITEMODS.JS File • 189

Sites • 71 sql • 209

Stand-Alone Knowledge Tools Migration • 181

Start Services • 18, 58

Start the Client Interface • 67

Step 1

Create Owned Assets • 19, 88, 89

Step 2

Monitor Event Console Messages • 19, 91

Syntax (Event Writer Rules) • 100

Syntax (Filter Rules) • 96

Syntax (Loading Event Writer Rules) • 110

System Accounts Field Definitions • 38, 42

T

Test the Change Impact Analyzer Integration •

139

The dependency doesn’t exist or has been marked for deletion • 118 tngfilter_rule.dat • 128 tngwriter_rule.dat • 129

TNGWV object create failure= x • 115 topology.cfg • 128

Troubleshoot Integration • 19, 114

Turn On Logging • 114, 120

Typical Client Installation • 61, 62

Typical Server Installation • 16, 22, 27

U

Unicenter NSM Integration • 86

Unicenter Service Desk Change Impact

Analyzer • 133

Index 207

Unicenter Service Desk Event Converter • 121

Unicenter Service Desk Log (stdlog.0) Syntax •

108

Update Shared File Repositories • 184

Update Unicenter Service Desk r11.2 HTMPL

Code • 197

Using an Ingres Database • 177, 181

V

Vendor Types and Vendors • 75

Verify Unicenter Service Desk Web Interface

Accessibility • 157

Version Control File • 189

View Index List in 6.0 • 172 views • 210

W

Web Interface Field Definitions • 18, 38, 51

Web Interface Installation • 21, 56

What You Need to Know • 10

Workflow Components • 81

Workflow Design Environment • 81, 82

Workflow IDE Parameters • 82, 83

Workflow Server • 81, 83

Worklist • 81, 83

Unicenter Service Desk Implementation Guide

Unicenter Service Desk

Implementation Guide

CA Product References

Contact Technical Support

http://support.ca.com

Contents

Contents 5

6 Implementation Guide

Contents 7

8 Implementation Guide

Chapter 1: Introduction

Introduction 9

What You Need to Know

What You Need to Know

Before You Start

http://supportconnectw.ca.com/public/impcd/r11/StartHere.htm

10 Implementation Guide

Before You Start

Implementation Type Descriptions

Introduction 11

Before You Start

Primary Server Components

12 Implementation Guide

Before You Start

Introduction 13

Before You Start

Primary or Secondary Server Components

14 Implementation Guide

Before You Start

Introduction 15

Installation Walkthroughs

Installation Walkthroughs

Server and MDB on Same Machine

Server and MDB on Different Machines

16 Implementation Guide

Installation Walkthroughs

Custom Installation using SQL Database

Custom Installation using Oracle Database

Introduction 17

Installation Walkthroughs

Custom Installation with Web Interface

18 Implementation Guide

Installation Walkthroughs

Custom Installation with NSM Integration

Introduction 19

Chapter 2: Install and Configure

Unicenter Service Desk

Review System Requirements

http://supportconnectw.ca.com/public/uniservplus/unicervplus-sd_supp.asp

Installation Procedures

Install and Configure Unicenter Service Desk 21

Installation Procedures

Server Installation

Typical Server Installation

22 Implementation Guide

Installation Procedures

Install and Configure Unicenter Service Desk 23

Installation Procedures

24 Implementation Guide

Installation Procedures

Install and Configure Unicenter Service Desk 25

Installation Procedures

26 Implementation Guide

Installation Procedures

Custom Server Installation

Install and Configure Unicenter Service Desk 27

Installation Procedures

28 Implementation Guide

Installation Procedures

Install and Configure Unicenter Service Desk 29

Installation Procedures

30 Implementation Guide

Installation Procedures

Install and Configure Unicenter Service Desk 31

Installation Procedures

32 Implementation Guide

Installation Procedures

Install and Configure Unicenter Service Desk 33

Installation Procedures