null  null
Unicenter Network and Systems
Management
®
Implementation Guide
r11.2
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.2277014(b)(3), as applicable, or their successors.
All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Copyright © 2008 CA. All rights reserved.
CA Product References
This document references the following CA components and products:
■
BrightStor® Backup for Unicenter
■
BrightStor® SAN Manager
■
Business Process View™ Management
■
CA Cohesion® Server
■
CA SPECTRUM® Network Fault Manager
■
CA SPECTRUM® OneClick
■
Distributed Intelligence Architecture (DIA)
■
Distributed State Machine Wizard (Unicenter DSM Wizard)
■
eHealth® Suite
■
eTrust® Access Control (eTrust AC)
■
eTrust® Security Command Center (eTrust SCC)
■
Job Management Option
■
Smart Business Process View (SmartBPV)
■
Unicenter® Adaptive Dashboard Services™ (ADS)
■
Unicenter® Advanced Systems Management (Unicenter ASM)
■
Unicenter® CA-7® Job Management (Unicenter CA-7)
■
Unicenter® CA-Jobtrac® Job Management (Unicenter CA-Jobtrac)
■
Unicenter® CA-Scheduler® Job Management (Unicenter CA-Scheduler)
■
Unicenter® Cisco Integration
■
Unicenter® Management Command Center (Unicenter MCC)
■
Unicenter® Management Portal (Unicenter MP)
■
Unicenter® Network and Systems Management (Unicenter NSM)
■
Unicenter Remote Control
■
Unicenter Remote Monitoring
■
Unicenter® Service Desk
■
Unicenter® Systems Command Center (Unicenter SCC)
■
Unicenter® Service Desk Knowledge Tools (Unicenter SDKT)
■
Unicenter Software Delivery
■
Unicenter® Trap Manager
■
Unicenter® Web Reporting Server™ (WRS)
■
WorldView
Contact CA
Contact Technical Support
For online technical assistance and a complete list of locations, primary service
hours, and telephone numbers, contact Technical Support at
http://ca.com/support.
Provide Feedback
If you have comments or questions about CA product documentation, you can
send a message to [email protected]
If you would like to provide feedback about CA product documentation, please
complete our short customer survey, which is also available on the CA Support
website.
Contents
Chapter 1: Overview
15
Introduction .................................................................................. 15
Unicenter NSM ............................................................................... 15
Product Components .......................................................................... 17
Management Command Center Overview ................................................... 17
Agent Technology ......................................................................... 17
Event Management ....................................................................... 18
Unicenter Systems Performance ........................................................... 18
Active Directory Monitoring (Windows) ..................................................... 18
Discovery ................................................................................ 18
Notification Services ...................................................................... 19
Alert Management System................................................................. 19
Advanced Event Correlation ............................................................... 20
Adaptive Configuration .................................................................... 20
TrapManager ............................................................................. 20
Unicenter Browser Interface ............................................................... 21
Unicenter Configuration Manager .......................................................... 21
Unicenter Management Portal .............................................................. 21
Unicenter Software Development Kit (SDK) ................................................. 21
Web Reports and Dashboards .............................................................. 21
Online Books ............................................................................. 22
Management Database .................................................................... 22
Unicenter for Pocket PC ................................................................... 22
Unicenter Management for Microsoft Operations Manager.................................... 23
Integration with System Center Operations Manager ........................................ 23
Unicenter Cisco Integration ................................................................ 24
Unicenter Remote Monitoring .............................................................. 24
Business Process View Management (Windows) ............................................. 25
Data Scoping ............................................................................. 26
Unicenter Windows Management Instrumentation Agent ..................................... 26
Documentation ............................................................................... 26
Unicenter NSM Databases ................................................................. 27
Readme Files ............................................................................. 27
Release Notes ............................................................................ 27
Related Publications ....................................................................... 28
Contents 5
Chapter 2: System Requirements
33
Hardware Requirements ...................................................................... 33
Enterprise Manager Configuration .......................................................... 34
Infrastructure Server Configuration (Windows only) ......................................... 34
Management Command Center Configuration ............................................... 34
Managed Node Configuration .............................................................. 35
GUI Configurations ........................................................................ 35
Database Requirements ....................................................................... 36
Windows ................................................................................. 36
Web Environment Support .................................................................... 37
Supported Web Browsers .................................................................. 37
Supported Web Servers and Servlet Environments .......................................... 37
Java Browser Support ......................................................................... 37
Adobe Acrobat Reader Support ................................................................ 38
Unicenter NSM Agent Requirements ........................................................... 38
Unicenter Remote Monitoring Requirements .................................................... 38
Unicenter Management for Microsoft Operations Manager Requirements .......................... 39
CA System Center Operations Manager Integration ............................................. 39
CA High Availability Service (HAS) Requirements ............................................... 40
Windows: ................................................................................ 40
UNIX ..................................................................................... 40
Unicenter Cisco Integration Requirements ...................................................... 40
Unicenter for Pocket PC Requirements ......................................................... 41
Systems Performance Requirements ........................................................... 41
Chapter 3: Product Architecture
43
Implementation Layers ....................................................................... 43
Visualization .............................................................................. 43
MDB ..................................................................................... 44
Managers ................................................................................ 45
Monitoring Technology .................................................................... 51
Unicenter Systems Performance ............................................................... 59
Distributed Intelligence Architecture ........................................................... 60
Classic Versus Continuous Discovery ........................................................... 60
Deployment of Discovery Managers ........................................................ 61
Deployment of Discovery Agents ........................................................... 61
Chapter 4: Architecture Considerations
63
Introduction .................................................................................. 63
Current Environment ......................................................................... 63
6 Implementation Guide
Hardware and Software ................................................................... 63
Network Considerations ................................................................... 64
Operational Standards and Restrictions ..................................................... 65
Evolution of the Environment .................................................................. 66
Business Needs ............................................................................... 67
Unicenter NSM Requirements .................................................................. 68
Chapter 5: Installation Preparation
69
Installation Methods .......................................................................... 69
Unicenter NSM Product Explorer - Windows ................................................. 69
setupNSM - Linux/UNIX ................................................................... 70
Unattended Installation ................................................................... 70
Unicenter Software Delivery ............................................................... 71
Start Menu and Installations ............................................................... 71
Common Unicenter NSM Server Categories ..................................................... 72
Managed Server .......................................................................... 72
Unicenter NSM Monitoring Manager ........................................................ 73
Unicenter NSM Reporting and Configuration Manager........................................ 76
MDB Server .............................................................................. 76
Visualization Server ....................................................................... 77
Pre-Installation Tasks ......................................................................... 78
Windows ................................................................................. 78
Linux and UNIX ........................................................................... 79
DIA Configuration ......................................................................... 79
Distributed State Machine (DSM) .......................................................... 80
Monitoring for z/OS ....................................................................... 82
Unicenter Systems Performance ........................................................... 87
Unicenter for Pocket PC ................................................................... 87
Unicenter Management for MOM ........................................................... 88
CA System Center Operations Manager Integration ......................................... 90
Unicenter Remote Monitoring .............................................................. 92
Highly Available Installations .............................................................. 93
Other Software Considerations ............................................................. 93
Chapter 6: Installation
95
Installation Overview ......................................................................... 95
Operating System Dependencies ........................................................... 96
Maximum Operating System PATH Lengths ................................................. 96
Special Character Support ................................................................. 97
Other Installed Software .................................................................. 98
Microsoft SQL Server Considerations ....................................................... 99
Contents 7
Microsoft SQL Server Browser Service ..................................................... 101
IPv6 Support Over MDAC ................................................................. 102
Reserved Database User Names .......................................................... 102
Database Configuration Considerations .................................................... 103
Security Considerations .................................................................. 105
Warning Messages During Installation ..................................................... 106
System Restarts During Installation (Windows Only) ....................................... 106
Installation Using Unicenter Remote Control ............................................... 107
Migration of Component Data From a Prior Release ........................................ 107
Network Port Conflicts.................................................................... 108
Windows Terminal Services Support ....................................................... 108
High Availability Considerations ........................................................... 110
Response File Must Not Be Read-Only ..................................................... 110
Install Unicenter NSM on Windows ............................................................ 111
Install Unicenter NSM on Linux or UNIX ....................................................... 119
Install CA Common Discovery ................................................................ 133
Platform Support ........................................................................ 134
Tomcat Authentication ................................................................... 134
Install CA Common Discovery............................................................. 135
NSM--Configure CA Common Discovery (CACD) With SSL .................................. 136
Register Unicenter NSM with Unicenter Software Delivery ...................................... 141
Prepare for Registration .................................................................. 142
Run Registration ......................................................................... 144
Deploy Unicenter NSM to Hosts ........................................................... 145
Install Unicenter Systems Performance........................................................ 145
Install Unicenter NSM Systems Performance on Windows ....................................... 146
Install Active Directory Management .......................................................... 147
Platform Support ........................................................................ 147
Software Requirements .................................................................. 147
Install Active Directory Management ...................................................... 149
Active Directory Agent Installation ........................................................ 151
Install Monitoring for z/OS Interface .......................................................... 156
FTP and Load JCL to the Mainframe ....................................................... 156
Install on the Mainframe ................................................................. 157
Download the Installation Library ......................................................... 159
SETVARS Member Modification............................................................ 159
Run the Installation Job .................................................................. 160
Copy the MIB to Agent Technology ........................................................ 160
Load the MIB into the Object Store........................................................ 160
Update the awservices Configuration ...................................................... 161
Update Agent PROCs and Add to System Procedure Library ................................. 161
Agent Load Library APF-Authorization ..................................................... 161
8 Implementation Guide
Give the ZOSAGTS and CICAGTS PROCs the Proper Security ................................ 162
Migration of Previous z/OS Agent Installations ............................................. 162
Install Unicenter Management Portal .......................................................... 163
Install Unicenter for Pocket PC................................................................ 164
Installation of Unicenter Management for MOM ................................................ 165
Prerequisites for MOM Management Installation ............................................ 165
Install Unicenter Management for MOM .................................................... 166
Installation of the CA System Center Operations Manager Integration ........................... 167
Prerequisites for the SCOM Integration Installation ......................................... 167
Install the SCOM Integration.............................................................. 168
Install Unicenter Cisco Integration ............................................................ 169
Install TrapManager ......................................................................... 170
Install Unicenter Remote Monitoring .......................................................... 172
Install the Remote Monitoring Agent ...................................................... 172
Install the Administrative Interface Only ................................................... 173
Install the SPECTRUM Integration Kit ......................................................... 174
Discovery of SPECTRUM Server ........................................................... 175
How to Use the Event Agent to Forward SPECTRUM Alarms ................................. 175
Install the SPECTRUM Integration Kit ...................................................... 177
Uninstall Individual Components .............................................................. 187
Uninstall Unicenter NSM .................................................................. 187
Uninstall CA Common Discovery .......................................................... 189
Uninstall Unicenter for Pocket PC ......................................................... 189
Uninstall Unicenter Management for MOM ................................................. 189
Uninstall the Integration with System Center Operations Manager ........................... 190
Uninstall Unicenter Cisco Integration ...................................................... 190
Chapter 7: Post-Installation and Configuration
191
Reghost, Reinstall, Unplug Unicenter NSM Components ........................................ 191
Configure Active Directory Enterprise Manager ................................................ 191
Configure Data Scoping ...................................................................... 192
Configure Data Scoping for Linux and UNIX ................................................ 193
Configure Data Scoping for Windows ...................................................... 194
Create Data Scoping Rules Using the MCC ................................................. 194
Configure and Maintain CAICCI ............................................................... 195
CAICCI Overview ........................................................................ 195
Configure CAICCI on Windows ............................................................ 200
Configure CAICCI on Linux or UNIX ....................................................... 202
Configure CAICCI on HP NonStop ......................................................... 204
Configure CAICCI on OpenVMS ........................................................... 206
Configure CAICCI on OS/400 ............................................................. 210
Configure CAICCI on the Mainframe ....................................................... 214
Contents 9
Troubleshooting CAICCI .................................................................. 217
CCIRMTD Behavior at Startup ............................................................ 218
Configure Remote Monitoring ................................................................. 219
Configure Unicenter Management Portal ....................................................... 220
Configure Unicenter for Pocket PC ............................................................ 220
Configure the Unicenter WMI Agent ........................................................... 221
Configure Monitoring for z/OS Interface ....................................................... 221
Unicenter CA-SYSVIEW Server ............................................................ 222
Start and Stop the Agents ................................................................ 222
Run Unicenter Management for MOM Discovery ................................................ 223
Run CA System Center Operations Manager Discovery ......................................... 224
Access Unicenter NSM Web Applications ....................................................... 225
Access AEC Web UI ...................................................................... 227
Unicenter Configuration Manager Setup ................................................... 227
Access the Knowledge Base .............................................................. 228
Configure Unicenter NSM Web Reporting Server ........................................... 228
CA Web Server Configuration with SSL .................................................... 229
CA Web Server Security .................................................................. 240
Enable Unicenter NSM Integration with eHealth Reports ........................................ 242
Enable the DSM Policy for eHealth ........................................................ 243
Enable Alert Management Policy .......................................................... 244
Enable eHealth Links in the Unicenter MCC ................................................ 244
Configure eHealth Links in the Classical Interfaces ......................................... 245
Discover eHealth Objects in Unicenter NSM Using the Discovery Gateway Command-Line Utility245
Chapter 8: Creating the Reduced-Size Installation Image
249
Remote Agent Installation Using RSII ......................................................... 249
Prerequisites ................................................................................ 250
Best Practices ............................................................................... 250
How RSII Works ............................................................................. 250
Create an Installation Image for Windows ..................................................... 251
Create Custom Response Files ................................................................ 252
Plan Your Response Files ................................................................. 252
Create Custom Response Files for Windows ................................................ 252
Create Custom Response Files for Systems Performance Agents on Windows ................ 253
About Response Files ........................................................................ 254
Deploy the Agent-Only Installation Image ..................................................... 254
Interactive Installation ................................................................... 254
Registration with Unicenter Software Delivery ............................................. 254
Unattended (Silent) Installation on a Delivery Application................................... 255
Deploy the Image to Unicenter Software Delivery .......................................... 256
Troubleshooting ......................................................................... 257
10 Implementation Guide
Chapter 9: Getting Started
261
Discover Your Network Infrastructure ......................................................... 261
Network Visualization ........................................................................ 262
Unicenter MCC ........................................................................... 262
2D Map ................................................................................. 264
Managed Object Status................................................................... 266
Value of Objects in Your Network ......................................................... 266
Network Views ........................................................................... 267
Association Browser ...................................................................... 268
Object Statistics ......................................................................... 268
Historical Information About Your Network ................................................ 268
Chapter 10: Implementation Scenarios
271
Introduction ................................................................................. 271
Scenario 1: Agentless Monitoring and Portal-Based Visualization ................................ 271
Installation .............................................................................. 272
Configuration ............................................................................ 273
Scenario 2: Focused Visualization Using Weighted Severity ..................................... 279
Assign Severity Weights .................................................................. 280
Scenario 3: Automated Business Views Using Dynamic BPV .................................... 281
Define Business Process Views to Show Location ........................................... 281
Scenario 4: Event Management and Advanced Event Correlation ................................ 283
Configure AEC to Receive Events at the Console ........................................... 284
Appendix A: DIA Reference
291
DIA Introduction............................................................................. 291
DIA Architecture ............................................................................. 292
Unicenter Knowledge Base ............................................................... 293
Dynamic Node Administrator ............................................................. 294
Gene .................................................................................... 295
Cells .................................................................................... 296
DIA Grid ................................................................................ 297
Consumer Applications ....................................................................... 297
Adaptive Dashboards Server .............................................................. 298
Management Command Center ........................................................... 298
Unicenter Management Portal & Web Reporting Services ................................... 299
Unicenter Remote Monitoring ............................................................. 299
WVObject Cell ........................................................................... 300
How DIA Works ............................................................................. 301
Utilities.................................................................................. 302
Contents 11
DIA Diagnostic Tool ...................................................................... 302
Advantages and Primary Functions............................................................ 304
Centralized Component Management ...................................................... 304
Data Collection and Abstraction ........................................................... 306
Transparent and Secure Communications.................................................. 306
Availability .............................................................................. 309
Zoning .................................................................................. 310
DIA Configuration ........................................................................... 312
DIA Deployment Recommendations ....................................................... 313
Configure Unicenter Domain Name Services ............................................... 314
Configure the MasterKB Without an SRV Record or Domain ................................. 316
Commands to Start and Stop DIA Daemons on Linux or UNIX............................... 317
Cell Configuration ........................................................................ 318
DIA Rules File ........................................................................... 318
Configure Communications for Encryption ................................................. 319
DIA Configuration in Special Environments ................................................ 321
Troubleshooting and Diagnostics .............................................................. 327
Backup for Master Knowledge Base ....................................................... 327
C-Gene Utilities Fail on HP-UX ............................................................ 328
Configure Memory Usage for a Cell ........................................................ 328
DIA Communications ..................................................................... 328
DIA Configuration in a Firewall or NAT Environment ........................................ 329
DIA Logs ................................................................................ 329
DIA Maintenance Tasks .................................................................. 333
Dynamic Node Administrator and UKB Installation Process Stops Responding ................ 340
Dynamic Node Administrator Floated to a Different Knowledge Base......................... 340
Dynamic Node Administrator Unable to Communicate with Unicenter Knowledge Base ........ 341
Float Dynamic Node Administrator to Another UKB Temporarily ............................. 342
Impact of Master Knowledge Base Crash on DIA ........................................... 342
Install DIA Without DNS Available......................................................... 343
Install DIA Without an SRV Record Set .................................................... 344
Multiple Entries in a Unicenter Knowledge Base in Grid ..................................... 345
Number of Cells Supported by Dynamic Node Administrator or Knowledge Base .............. 345
Potential Problems with DIA Consumer Applications ........................................ 346
Primary Master Knowledge Base is Down .................................................. 349
Primary and Secondary Master Knowledge Base Communication ............................ 350
Reconfigure Unicenter Knowledge Base Into Master Knowledge Base ........................ 350
Remove Server from the Network and the Grid in DIA ...................................... 350
Security Concerns with DIA ............................................................... 351
Specific OS Configuration Requirements for DIA Installation ................................ 351
Troubleshooting DIA Components ......................................................... 351
Two Zones in DIA ........................................................................ 355
12 Implementation Guide
Unable to Autoactivate the Dynamic Node Administrator.................................... 356
Unable to Deploy Packages Using Package Deployment Infrastructure (PDI) ................. 356
Unable to Do an SRV Record Lookup ...................................................... 357
Unable to Open DIA Tool ................................................................. 358
Unicenter Knowledge Base Failure in Firewall Scenario ..................................... 358
Utilities to Assist Troubleshooting DIA ..................................................... 359
Appendix B: Making Components Cluster Aware and Highly Available
369
Cluster Aware and High Availability Introduction ............................................... 369
CA High Availability Service .................................................................. 369
Failover and Failback ........................................................................ 370
Resource Groups ............................................................................ 371
Resource Groups on Linux Platforms ...................................................... 371
Cluster Configuration..................................................................... 371
Shared Disk Support ..................................................................... 372
HAS Architecture ........................................................................ 373
Unicenter NSM Highly Available Components .................................................. 374
How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) ...................... 375
How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases) ......... 377
How You Install, Reinstall, or Uninstall Unicenter NSM Components ............................. 379
How WorldView Becomes Cluster Aware ....................................................... 380
WorldView Resource Group ............................................................... 380
How Event Management Becomes Cluster Aware .............................................. 380
Event Management Resource Groups ...................................................... 381
How Event Daemon Resumes Processing from Point of Failure .............................. 381
Environment Variables Event Management Uses When Highly Available ...................... 382
How You Configure Event Management in a Cluster Environment ............................ 382
How You Test Event Management in a Cluster Environment ................................. 383
How AEC Becomes Cluster Aware ............................................................. 383
AEC Resource Groups .................................................................... 384
How Alert Management Becomes Cluster Aware ............................................... 384
Alert Management Resource Group........................................................ 385
How You Test Alert Management in a Cluster Environment .................................. 385
Cluster-Aware Agent Technology ............................................................. 386
How Agent Technology Becomes Cluster Aware ............................................ 387
Windows System Agent Highly Available Resource Groups .................................. 388
UNIX/Linux System Agent Highly Available Resource Groups................................ 390
UNIX/Linux and Windows Log Agent Highly Available Resource Groups ...................... 390
Microsoft SQL Server Agent Highly Available Resource Groups .............................. 393
Contents 13
Appendix C: CCS Linux/UNIX Reference
395
CCS Linux/UNIX Reference Introduction ....................................................... 395
PIF Response Files ........................................................................... 395
Parameter Usage in PIF ...................................................................... 396
PIF Response Files and Parameters ........................................................... 396
PIF Response Files Creation .................................................................. 396
Response File Considerations ................................................................. 397
Appendix D: Database Maintenance Quick Reference
399
Database Maintenance Quick Reference Introduction ........................................... 399
Database Backup ............................................................................ 400
Query Optimization (Ingres Only) ............................................................. 401
System Catalog Optimization (Ingres Only).................................................... 401
User-Defined Tables Optimization (Ingres Only) ............................................... 402
Database Recovery .......................................................................... 402
Index
14 Implementation Guide
405
Chapter 1: Overview
This section contains the following topics:
Introduction (see page 15)
Unicenter NSM (see page 15)
Product Components (see page 17)
Documentation (see page 26)
Introduction
This chapter contains an overview of Unicenter Network and Systems
Management (Unicenter NSM), a brief introduction of the available
components, system requirements, and resources you can use for additional
information.
Note: In Unicenter NSM r11, the database used for the MDB is Ingres for both
Windows and UNIX/Linux. In Unicenter NSM r11.1 and r11.2, however, the
database used for the MDB is Microsoft SQL Server. Additionally, the Unicenter
NSM r11.2 Enterprise Manager also runs on UNIX/Linux systems. It has its
own local PostgreSQL database to store relevant event management data. This
PostgreSQL database is installed with the product. Therefore, the
documentation for Unicenter NSM r11.2 has to provide various database
information, so be aware that some information may not apply, depending on
the Unicenter NSM version you are running.
Unicenter NSM
Unicenter NSM is a comprehensive management solution that lets you
discover, monitor, and analyze infrastructure elements, gather reports on
system and network status to help avoid potential bottlenecks, and set up
automated actions to improve performance. Unicenter NSM lets you analyze
the health, status, and performance of your infrastructure elements, improving
management and facilitating optimization.
Unicenter NSM displays and reports system status, problems, and history in a
number of secure and personalized facilities including the Management
Command Center (Unicenter MCC), Unicenter Management Portal (Unicenter
MP), Event Console, and visual maps (such as Association browser and 2D
Map). Unicenter NSM displays overview and detailed views of infrastructure
elements with a single GUI, the Unicenter MCC. These visualizations let you
identify and understand information relevant to particular operational roles.
Chapter 1: Overview 15
Unicenter NSM
Enterprise management requires tracking many elements to provide a valid
view of infrastructure health. Unicenter NSM includes agents that provide
monitoring and visualization of resources across many different platforms in
the enterprise, that network together to perform a business service, and that
complete a unified view of the enterprise. Efficient information sharing is
accomplished through a centralized database known as the MDB. This
comprehensive knowledge base of CA-gathered intelligence is shared among
CA products such as Unicenter NSM and Unicenter MP to provide more
accurate and significant information about infrastructure problems and
resolutions. This technology allows multiple CA solutions to work together to
perform a business service.
In addition, Unicenter NSM can provide information from system platforms
such as Windows, Linux, UNIX, AS400, z/OS, and HP NonStop, and network
platforms such as Cisco and 3Com switches and routers to a single
management station. For the most up-to-date listing of supported platforms,
see the Release Notes.
Unicenter NSM provides a unified approach encompassing all disciplines and
elements needed to proactively manage business initiatives. Unicenter NSM
offers specialized support to manage key technologies, like high availability
clustering, available on many operating systems.
Because Unicenter is a family of integrated business infrastructure
management solutions, each member of the product family can use common
facilities, making the whole solution more powerful. Unicenter uses advanced
intelligence and visualization technology to simplify business administration.
Through innovative use of intelligence, visualization, and personalization,
Unicenter improves problem resolution time—reducing downtime and slow
performance while improving overall service delivery.
Unicenter products offer the following:
■
Sophisticated monitoring capabilities that gather information for display,
managing, and reporting.
■
Advanced root-cause analysis and event management to identify the
source of problems.
■
Industry-leading visualization and reporting that simplifies the complexity
of the IT infrastructure, including Java-based graphical user interfaces
(GUIs), 2D Maps, portal views, and association browsers.
■
Personalized views of information specific to the role and interests of the
end user through the use of portal technology.
16 Implementation Guide
Product Components
The following product add-ons are available for Unicenter NSM:
■
Unicenter Advanced Systems Management
This product leverages the intelligence in Unicenter NSM and Agent
Technology to create a centralized, uniform infrastructure that lets you
discover and manage clusters, dynamically reconfigure resources, and
discover and manage virtual machines.
■
Unicenter Job Management Option
This product enhances the efficiency of the enterprise by coordinating the
execution of application processes. Business process dependencies are
enforced to maximize utilization of resources and minimize manual
interaction.
Product Components
Unicenter NSM offers out-of-the-box integration with other CA management
products and consists of the components described in the following topics.
Management Command Center Overview
The Management Command Center (Unicenter MCC) provides a graphical tree
structure, both familiar and intuitive, for productive navigation of role-based
administrative tasks. The Unicenter MCC is the center for visualization,
configuration, and monitoring in Unicenter NSM. You use it to navigate the
WorldView 2D Map and topology tree view, monitor Event messages, look into
details of Agent Technology, start network and system discovery, create
reports, and much more. Integration with WorldView (through icons and
Business Process Views) is also crucial for interaction between Unicenter NSM
and other applications.
Agent Technology
Agent Technology monitors and manages your enterprise. Agent Technology
can extend and manage customer and third-party programs and applications.
Individual agents can collect information on a wide range of data across
numerous operating systems and applications. Unicenter NSM Agent
Technology also includes an integrated Distributed State Machine (DSM). This
vital component provides the intelligent correlation of received events and
translation of data into meaningful information for visualization and
monitoring.
Chapter 1: Overview 17
Product Components
Event Management
Event Management provides a rich collection of facilities to meet your
information technology needs with flexible correlation, intelligence and
automation capabilities at all levels of the management infrastructure. The
Event Manager, Event agents, and the Event Console comprise Event
Management.
Unicenter Systems Performance
Unicenter Systems Performance monitors the performance of the server
platforms in your enterprise, letting you apply consistent management policies
to disparate operating systems. Systems Performance provides historic and
real-time information to assist with problem analysis and capacity planning.
Also, simplified reports provide immediate value upon installation.
Active Directory Monitoring (Windows)
Active Directory Monitoring on Windows platforms monitors the health of
critical aspects of the Windows Active Directory environment. Unicenter NSM
provides comprehensive monitoring of the Active Directory Service (ADS), the
File Replication Service (FRS), and the Domain Name Service (DNS).
Discovery
Discovery discovers and classifies devices on IP and IPX networks. It provides
both an ad hoc (on demand) and continuous (real-time) mode. It provides
discovery services to other CA Common Services components and updates the
MDB with newly discovered and classified network objects.
When you install your product, you can use any of the following types of
Discovery:
Classic Discovery
Provides on demand discovery that lets you decide which subnets you
want to discover and when. You can also configure Classic Discovery to
run at regular intervals, which can be used as an alternative to Continuous
Discovery and ensures that your discovered environment in the MDB is
always current. You can start a Classic Discovery from the Discovery
Classic GUI, the Management Command Center, the Unicenter Browser
Interface, or the command line.
18 Implementation Guide
Product Components
Continuous Discovery
Provides event-driven and ongoing discovery. Continuous Discovery
employs a manager and agents that continuously scan your network in
real-time mode for new devices or changes in IP addressing of existing IP
devices. You can configure Continuous Discovery for optimal load
balancing between the Discovery Agents and the Discovery Manager. If
you choose this method of discovery, you must install the Discovery
Agents and the Discovery Manager.
Common Discovery
Discovers IPv6 networks. The Common Discovery Import utility discovers
IPv6 networks using Common Discovery technology and imports IPv6
addresses into WorldView, where they are integrated with existing
networks.
Notification Services
Notification Services provide the messaging infrastructure for Unicenter NSM
and leverage your existing investments in application, network, and
telecommunications infrastructures to deliver business information to remote
personnel in a timely manner through wireless and advanced protocols such as
WCTP, SMTP, POP3, and so forth. Notification Services consist of two parts:
Notification Services Client
Provides the necessary libraries and utilities to connect to the Notification
Services Server in order to send notifications and retrieve responses. You
must select this component in addition to the Enterprise Management
Administrative Client to manage remote installations through that GUI.
Notification Services Server
A Windows Service that provides the necessary facilities to process client
notification requests, resolve recipient information, and send requests to
recipients using various protocols and providers. If requested, the Server
can retrieve responses and send them back to the requesters.
Alert Management System
The Alert Management System (AMS) organizes and tracks the most important
events in an enterprise or a logical segment of an enterprise so that you can
focus on and manage the highest severity IT events. AMS provides tools for
defining alert policies and multiple panes in the Unicenter MCC for viewing
alerts. AMS lets you link to Unicenter Service Desk, the customer support
application that manages calls and IT assets, resolves problems, and shares
corporate knowledge. You can also view the Alert Management console
through Unicenter MP.
Chapter 1: Overview 19
Product Components
Advanced Event Correlation
Advanced Event Correlation (AEC) integrates seamlessly with Event
Management to provide a powerful event correlation, root cause, and impact
analysis capability. When used with existing Unicenter NSM features, AEC can
increase the quality and reduce the quantity of the information reported on the
Event Console, which is used to automate certain operational tasks. Event
correlation is a way to group associated events together for further processing.
Grouping events lets you do simple but powerful forms of processing, such as
event suppression, reformatting, aggregation or consolidation.
Adaptive Configuration
The Adaptive Configuration service supports the challenging agent areas of
initial configuration, the ongoing configuration adjustment, and the tuning with
the following functions:
■
Detection of resources that should be monitored
■
Providing suitable thresholds for these resources
■
Automatic configuration of the agent with an optimum monitoring policy
After startup, the Adaptive Configuration service provides a predefined
configuration. If the predefined configuration does not match your specific
applications, you can customize the service to meet your needs. As an
example, you can influence the Adaptive Configuration service by specifying
threshold policies or including and excluding specific resources.
TrapManager
TrapManager is a component of Unicenter NSM that lets you perform
sophisticated trap database and trap filter file management. You can use
TrapManager to manage trap information and translation messages stored in
the Trap Database and trap filters stored in the trap filter file.
SNMP traps contain critical information about the latest status of your network
environment, including the network itself and devices on that network. Since
this information is received in the form of Management Information Base
(MIB) variables and their numeric values, it is difficult to understand offhand.
The Trap Daemon reads the Trap Database, which contains all trap information
and translation messages, and translates SNMP traps into meaningful, easy to
understand messages. These translated traps appear on the Unicenter NSM
Event Console.
20 Implementation Guide
Product Components
For every incoming trap, the Trap Daemon also searches the trap filters file for
any filters that apply. If the specified filter criteria are satisfied, the trap is
dropped from further processing and does not appear on the Event Console.
This can be helpful if you are only interested in certain traps.
Unicenter Browser Interface
The Unicenter Browser Interface provides a lightweight web-based Java user
interface through which you can administer Unicenter NSM.
Unicenter Configuration Manager
The Unicenter Configuration Manager allows for web-based configuration and
remote distribution of agent profiles. It is able to deliver configuration data at
scheduled times and to audit existing configurations for Unicenter NSM
components such as agents, Advanced Event Correlation, and opr (operator)
settings in Event Management. Unicenter Configuration Manager also delivers
file packages to remote machines, which is useful when you have callbacks
defined on agent configurations. Audit, delivery forecast, and delivery status
reports are also available.
Unicenter Management Portal
Unicenter Management Portal provides a role-based, dynamic, personalized,
and consolidated view of the enterprise management information provided by
Unicenter products using the web portal.
Unicenter Software Development Kit (SDK)
The Unicenter Software Development Kit (SDK) provides the means to
programmatically interface with the major components of Unicenter NSM. It
lets you extend and tailor the WorldView, Event, and Agent Technology
functionality to your specific needs by letting you create personalized
visualizations and policies, and integrating with your site-specific data,
applications, and configurations.
Web Reports and Dashboards
Web reports let you create inventory, status, and performance reports for
your managed resources. Dashboards present the detailed state of your
managed resources in a graphic and intuitive manner. Web reports and
Dashboards are accessible through the Unicenter MCC, Unicenter MP, and the
CA web server.
Chapter 1: Overview 21
Product Components
Online Books
Selecting Online Books from the installation Product Explorer installs Unicenter
NSM documentation.
Selecting Unicenter Online Books from the setupNSM menu on Linux or UNIX
installations installs the Java-based book reader (cabook) on the system.
Running cabook directly from the Linux/UNIX DVD lets you view the books
without installing them.
Management Database
Unicenter NSM components are integrated using a management database (the
CA MDB). The MDB provides a single integrated database schema (tables,
columns, views) for the management data stored by all CA products. The
schema includes the database objects used by Unicenter NSM, its components,
and options. Use of the MDB in Unicenter NSM enables integration of Unicenter
NSM and other CA products for managing your IT infrastructure.
Unicenter NSM r11.2 supports MDBs running on Microsoft SQL Server. The
Unicenter NSM r11.2 Enterprise Manager also runs on UNIX/Linux systems. It
installs its own local PostgreSQL database to store relevant event management
data.
Unicenter for Pocket PC
Unicenter for Pocket PC works with Unicenter NSM to provide access to Event
Management functionality from your Personal Digital Assistant. With Unicenter
for Pocket PC, you can do the following:
■
Send events and commands to specific servers to request administrator
response, trigger automated Event Management policy, or execute
commands.
■
View console logs and update them in real time using convenient
predefined or custom filters.
■
Subscribe to critical events delivered directly to the Pocket PC as Unicenter
NSM notifications.
22 Implementation Guide
Product Components
Unicenter Management for Microsoft Operations Manager
Unicenter Management for MOM integrates Unicenter NSM and the Microsoft
Operations Manager (MOM).
The integration between MOM and Unicenter NSM provides a central location
for performing management functions. You can see the status of MOM servers
and managed PCs using WorldView, and you can change the status from there.
You can also view open MOM alerts and Unicenter NSM events in one
convenient location on the Event Console.
Alerts generated by Microsoft-managed nodes are forwarded to the Event
Console, where the updates are processed. After an event is generated, it can
be filtered for action, such as saving it into the MOM database or correlating it
with similar events. Other automated responses, such as sending email
messages, or issuing SNMP traps or pages are also possible. You can execute
low-level functions such as command lines or scripts.
Note: If you are upgrading Unicenter NSM from an earlier version and were
using Unicenter Management for MOM, you must also upgrade Unicenter
Management for MOM to its current version. Earlier versions of the component
are not compatible with this release of Unicenter NSM.
Integration with System Center Operations Manager
Unicenter NSM integrates with Microsoft's System Center Operations Manager
2007 (SCOM).
The integration between SCOM and Unicenter NSM provides a central location
for performing management functions. You can see the status of SCOM servers
and managed PCs using WorldView, and you can change the status from there.
You can also view open SCOM alerts and Unicenter NSM events in one
convenient location on the Event Console.
Alerts generated by Microsoft-managed nodes are forwarded to the Event
Console, where the updates are processed. After an event is generated, it can
be filtered for action, such as saving it into the SCOM database or correlating it
with similar events. Other automated responses, such as sending email
messages, or issuing SNMP traps or pages are also possible. You can execute
low-level functions such as command lines or scripts.
Chapter 1: Overview 23
Product Components
Unicenter Cisco Integration
Unicenter NSM integration for Cisco provides enhancements to the generic
Cisco class that is supplied with Unicenter NSM. It updates the Cisco classes
for both Cisco routers and switches.
This integration provides the object identifiers for each Cisco device, which
automatically lets Unicenter NSM discover Cisco devices and classify them into
a specific Cisco model. After Discovery, Unicenter NSM can display and
monitor these Cisco devices. In addition, you can add support for new Cisco
devices from the Cisco Integration Control by just providing the device type
(router or switch) and Sys ObjID.
Integration with the Unicenter Systems Performance tools Performance
Configuration and Trend Analysis provides a set of predefined configuration
files for all supported Cisco routers. The Performance Manager gathers
information for these Cisco routers and lets you graphically visualize the
historical performance of all these devices.
Using the Cisco integration, you can perform many tasks such as the
following:
■
See the Cisco devices from the Unicenter MCC
■
Launch Cisco Works from the Unicenter MCC Topology Map to view and
manage any Cisco device in greater detail
■
Launch Cisco Works from WorldView 2D Map
■
Monitor device interfaces from Node View
■
Launch DSM View of your devices from Node View
■
Review the performance of your devices through Unicenter Performance
Trend
Unicenter Remote Monitoring
Unicenter Remote Monitoring remotely monitors your Windows servers,
Windows workstations, UNIX, Linux, and Mac OS X resources, and IP
resources without installing any software on the monitored resources. From a
single instance of the Unicenter Remote Monitoring agent, you can remotely
monitor your distributed servers and workstations. If scalability or load
balancing is a concern, simply add another instance of the agent.
24 Implementation Guide
Product Components
Unicenter Remote Monitoring uses protocols native to each operating system
to gather its data. For IP resources, it uses the network protocol, ICMP. For
Windows resources, it uses the native RPC commands to pass into a remote
Windows resource and gather data. It accomplishes its monitoring using a
domain administrative account that you can validate against the remote
Windows resource. For UNIX, Linux, and Mac OS X resources, monitoring is
accomplished using remote shell (rsh) or secure shell (ssh).
Using Unicenter Remote Monitoring, you can deploy a management server
with a Unicenter Remote Monitoring agent to monitor the resources at the
remote location and perform its responsibilities without having to load
dedicated agents on each resource. A Unicenter NSM Manager upstream
knows about the Unicenter Remote Monitoring manager and processes all
alerts and exceptions with less traffic through the wide area network (WAN)
infrastructure. The deployment produces less traffic through the WAN and a
simpler, faster product deployment.
Unicenter Remote Monitoring provides you with a deployment solution that lets
you monitor the computers in your environment. It is adaptive, quick to
install, and easy to configure. It manages your resources by exception
notification, is scalable, and provides reporting functionality.
Business Process View Management (Windows)
Business Process View Management (BPVM) for Windows adds intelligence to
the Business Process Views you use to monitor and control your network. A
Unicenter Business Process View is a logical group of managed objects you
create based on any criteria you determine, such as geographic location,
business process, security, and so on. The Business Process View acts as a
filter that displays only objects relevant to the management of resources for a
specific business requirement.
Using Business Process Views, you can apply new rules to your system to
determine how the state condition is propagated from existing WorldView
objects using methods ranging from simple counters to complex correlation
rules. BPVM lets you implement policies to make automated high-level
decisions about key resources and set warning and critical events when
problems are detected.
Chapter 1: Overview 25
Documentation
Data Scoping
Data Scoping is one of the security mechanisms available for securing
Unicenter NSM. Data Scoping works in addition to eTrust Access Control or
Security Management if you do not use eTrust Access Control. Data Scoping
protects the WorldView components from unauthorized access and is
automatically installed with WorldView
WorldView Data Scoping lets you protect the MDB object data from
unauthorized access. Data Scoping rules let the MDB administrators control a
specific user ID’s access to a particular data object or group of data objects.
Data Scoping is intended to provide protection against both malicious and nonmalicious access.
Data Scoping also lets you filter large amounts of information contained in the
MDB into smaller, more pertinent subsets of data. It lets you view the same
data differently depending on the current task.
For information about configuring Data Scoping, see the “Post-Installation and
Configuration” chapter. For additional information about Data Scoping, see the
Administrator Guide.
Unicenter Windows Management Instrumentation Agent
The Unicenter Windows Management Instrumentation agent exposes the
monitored resources of Windows Management Instrumentation (WMI) to
Unicenter NSM management services so that you can monitor the content of
your system. The agent sets thresholds for these monitored resources to alert
the manager of critical events. The Unicenter WMI agent enables the efficient
monitoring and proactive management of Windows systems and applications.
Documentation
This guide is intended for users who are implementing Unicenter NSM on a
new system; it documents architecture considerations, pre-installation tasks,
installation instructions, and configuration information and implementation
scenarios. Upgrade and migration instructions are presented in the Migration
Guide.
The Unicenter NSM documentation set consists of Portable Document Format
(PDF) files, JavaHelp files (.JAR), and Windows Help files (.HLP). The Unicenter
NSM Installation DVD contains the guides in PDF format. See the
Documentation Roadmap topic in the Unicenter NSM Release Notes for a listing
of the documentation provided with the product.
26 Implementation Guide
Documentation
Note: The PDF files are independent of platform and operating system, and
are viewable in the Adobe Acrobat Reader in Windows, Linux, and UNIX
environments. To download the appropriate version of the Adobe Acrobat
Reader, go to http://www.adobe.com.
Unicenter NSM Databases
In Unicenter NSM r11, the database used for the MDB is Ingres for both
Windows and UNIX/Linux. In Unicenter NSM r11.1 and r11.2, however, the
database used for the MDB is Microsoft SQL Server. Additionally, the Unicenter
NSM r11.2 Enterprise Manager also runs on UNIX/Linux systems. It has its
own local PostgreSQL database to store relevant event management data. This
PostgreSQL database is installed with the product. Therefore, the
documentation for Unicenter NSM r11.2 has to provide various database
information, so be aware that some information may not apply, depending on
the Unicenter NSM version you are running.
Readme Files
The Unicenter NSM readme file contains important information not included in
the product documentation (such as installation requirements and
dependencies). Review the file before working with the product. You can
access the readme file from the product explorer.
Microsoft SQL Server Databases
For information about installing Microsoft SQL Server, see the product
readme and online books.
Ingres Databases
For information about restrictions of computer name, user name, and
directory path when you are installing Ingres or components that require
Ingres, see the Ingres readme file.
Release Notes
For a description of Unicenter NSM features and enhancements specific to this
release, operating system support, system requirements, installation
requirements, published fixes, as well as a documentation roadmap, see the
Release Notes.
Chapter 1: Overview 27
Documentation
Related Publications
The following guides provide information that you will find useful. Most are
available on the Unicenter NSM installation media.
Administration Guide
Is intended for use by system administrators and contains general
information and procedures about how to secure, customize, configure,
and maintain Unicenter NSM after installation and implementation.
Individual chapters describe the components that are included with or that
can be integrated with your Unicenter NSM installation.
Agent Technology Support for SNMPv3
Provides information about how Agent Technology can take advantage of
the SNMPv3 protocol. Documents how the security information is handled
on the manager and agent side as well as how it is applied to the managed
systems. SNMPv3 configuration and usage details are provided in this
guide.
CA Procedures
Contains procedures and processes for all components of Unicenter NSM,
including WorldView, Agent Technology, Enterprise Management, Event
Management, CAICCI, Data Scoping, Discovery, Notification Services,
Wireless Messaging, Security Management, and Unicenter NSM Job
Management Option.
CA Reference
Contains commands, parameters, and environment variables for all
components of Unicenter NSM, including Advanced Event Correlation,
Agent Technology, Enterprise Management, Event Management, CAICCI,
Data Scoping, Discovery, Notification Services, Wireless Messaging,
Security Management, Unicenter NSM Job Management Option, and
WorldView.
Implementation Guide
Documents architecture considerations, pre-installation tasks, installation
instructions, post-installation configuration information, and
implementation scenarios. Appendixes include in-depth information about
Distributed Intelligence Architecture (DIA), the MDB, and the CA High
Availability Service (HAS) for cluster aware environments. This guide is
intended for users who are implementing Unicenter NSM on a new system.
Inside Active Directory Management
Provides general information, installation scenarios, and configuration
procedures for Active Directory Management.
28 Implementation Guide
Documentation
Inside Event Management and Alert Management
Provides detailed information about Event Management (message records
and actions), Advanced Event Correlation, and Alert Management.
Inside the Performance Agent
Contains detailed information about the configuration and use of the
Performance Agent.
Inside Systems Management
Documents systems management from the Unicenter NSM architecture
perspective. The guide describes the different layers (WorldView,
Management Layer, Monitoring Layer) and associated components, for
example: Distributed State Machine (DSM), Unicenter Configuration
Manager, Dashboards and so on.
Inside Systems Monitoring
Explores how to use and configure the system agents of Unicenter NSM to
monitor the system resources in your environment. The chapters guide
you through the process of configuring and optimizing the agent for your
special requirements.
Inside Systems Performance
Contains detailed information about the three architectural layers of
Systems Performance, and provides guidance in the deployment,
configuration, use, and best practice of the Systems Performance
components.
MDB Overview
Provides a generic overview of the Management Database (MDB), a
common enterprise data repository that integrates CA product suites. The
MDB provides a unified database schema for the management data stored
by all CA products (mainframe and distributed). The MDB integrates
management data from all IT disciplines and CA products. The guide
includes implementation considerations for the database systems that
support the MDB and information specific to Unicenter NSM's
implementation of the MDB.
MIB Reference Guide
Provides detailed information about each MIB attribute of the Unicenter
NSM system agents.
Migration Guide
Provides detailed upgrade and migration instructions. This guide is
available on http://SupportConnect.ca.com only.
Chapter 1: Overview 29
Documentation
Programming Guide
Provides details for constructing applications by CA development teams
and by third parties and their clients. The guide is intended for developers
who use one or more of the application programming interfaces (APIs) in
the SDK to develop applications for use with Unicenter NSM. Key among
these APIs are the WorldView API, the Agent Technology API, and the
Enterprise Management API.
Readme Files
Provides information about known issues and information discovered after
Unicenter NSM publication. The following readme files are available:
■
The Unicenter NSM r11.2 for UNIX and Linux readme
■
The Unicenter NSM r11.2 Windows readme
■
The Unicenter Management Portal readme
Release Notes
Provides information about operating system support, system
requirements, new and changed features, published fixes, international
support, and the documentation roadmap. The following release notes are
available:
■
The Unicenter NSM r11.2 for UNIX and Linux release notes
■
The Unicenter NSM r11.2 release notes.
■
The Unicenter Management Portal release notes
Unicenter Management Portal Implementation Guide
Provides installation, deployment, and basic administrative instructions for
Unicenter Management Portal.
CA Green Book, Systems Management
Identifies CA's solution for managing challenges involved in maintaining
the performance and availability of complex server infrastructures. The CA
solution provides proactive management of servers as part of an overall
effort to improve service levels, and minimize the costs of managing the
computing infrastructure through increased automation. It provides a view
of the requirements for systems management and best practices for
deployment. This guide is available online at:
http://supportconnectw.ca.com/public/ca_common_docs/greenbooks/gree
nbooks-index.asp.
30 Implementation Guide
Documentation
CA Green Book, Service Availability Management
Describes how to deliver integrated end-to-end performance and event
management that is centered on services. The CA Service Availability
Management solution leverages the Manager of Managers integration
capabilities of Unicenter NSM and eHealth and explains how to take
advantage of those capabilities. It includes details on how to install and
configure a variety of management solutions to provide simpler and more
comprehensive management and monitoring of IT services. This guide is
available online at:
http://supportconnectw.ca.com/public/ca_common_docs/greenbooks/gree
nbooks-index.asp.
Chapter 1: Overview 31
Chapter 2: System Requirements
This chapter describes system requirements that your systems must meet
before installing Unicenter NSM. This ensures that someone has prepared your
systems with the proper database, adequate memory, CPU, and disk space.
When necessary, certain information is flagged if it is specific only to the
Windows platform or only the UNIX platforms.
This section contains the following topics:
Hardware Requirements (see page 33)
Database Requirements (see page 36)
Web Environment Support (see page 37)
Java Browser Support (see page 37)
Adobe Acrobat Reader Support (see page 38)
Unicenter NSM Agent Requirements (see page 38)
Unicenter Remote Monitoring Requirements (see page 38)
Unicenter Management for Microsoft Operations Manager Requirements (see
page 39)
CA System Center Operations Manager Integration (see page 39)
CA High Availability Service (HAS) Requirements (see page 40)
Unicenter Cisco Integration Requirements (see page 40)
Unicenter for Pocket PC Requirements (see page 41)
Systems Performance Requirements (see page 41)
Hardware Requirements
If the computer does not have the minimum resources necessary to support
the installed components, you will see messages stating that one or more CA
services have failed to start. In some cases, even computers that meet or
exceed the necessary hardware requirements may experience this behavior if
the combination of software products installed cause a temporary shortage of
resources during startup. The services may in fact be operational shortly after
the errors appear.
If this occurs, it is necessary to delay the startup of CA services to allow other
critical services time to completely initialize. In cases where there are simply
insufficient resources available, CA services and other services may fail
causing other cascading failures. The overall stability of your system is
affected if you install this product on systems with insufficient resources.
Chapter 2: System Requirements 33
Hardware Requirements
We recommend letting the Windows operating system manage virtual
memory, instead of specifying an absolute value. If you decide to specify an
absolute value, we recommend that value is at least 1.5 times the physical
amount of real memory (RAM) on the computer. (Windows only)
A pointing device, (for example, a mouse) is required to install and use this
product.
Enterprise Manager Configuration
An Enterprise Manager Configuration consists of all management components
including a local MDB.
Hardware
Minimum
Recommended
CPU
Intel Pentium 4 - 2 GHz,
or AMD Athlon XP 2000+
Latest model available
RAM
2 GB
4 GB or more
Hard drive
6 GB
20 GB
Infrastructure Server Configuration (Windows only)
An Infrastructure Server consists of all management components with a
remote MDB.
Hardware
Minimum
Recommended
CPU
Intel Pentium 4 - 2 GHz,
or AMD Athlon XP 2000+
Latest model available
RAM
1 GB
2 GB or more
Hard drive
4 GB
8 GB
Management Command Center Configuration
A Management Command Center consists of the main GUI client interface to
an Infrastructure Server or an Enterprise Server.
Hardware
Minimum
Recommended
CPU
Intel Pentium 4 - 2 GHz,
or AMD Athlon XP 2000+
Latest model available
34 Implementation Guide
Hardware Requirements
Hardware
Minimum
Recommended
RAM
512 MB
1 GB or more
Hard drive
1 GB
2 GB
Managed Node Configuration
A Managed Node consists of the System, Performance and Event Agents.
Hardware
Minimum
Recommended
CPU
Intel Pentium III - 550
MHz, or AMD Athlon 600
Latest model available
RAM
512 MB
1 GB or more
Hard drive
500 MB
1 GB
GUI Configurations
Local GUI configurations require the following hardware:
Hardware
Minimum
Recommended
Video
32 MB DirectX-True Color
64 MB DirectX-True Color
Monitor
17" @ 1024 x 768
21" @ 1600 x 1200
Chapter 2: System Requirements 35
Database Requirements
Database Requirements
Windows
Unicenter NSM for Windows supports the following databases:
■
Microsoft SQL Server 2005 (64-bit)
■
Microsoft SQL Server 2005 (32-bit) with (optionally) SP1 or any later
maintenance
■
Microsoft SQL Server 2000 (32-bit) with a minimum of SP4 or any later
maintenance
Note: MDB creation uses Windows Authentication and must be run by an
operating system user that is a member of the System Administrators server
role.
This release of Unicenter NSM has the following other database requirements:
■
Mixed-mode authentication is required.
■
A dictionary sort order of case-sensitive or case-insensitive is required.
■
You can use the English version of Microsoft SQL Server with a code
page/character set of 1252 on any of the Windows language versions that
CA has certified for use with Unicenter NSM.
■
You can use localized versions of Microsoft SQL Server other than English
on any of their respective and matching Windows language versions that
CA has certified for use with Unicenter NSM, with the default code
page/character set, or with a code page/character set of 1252 if you are
not using specific localized character data for that region, even though you
are installing on a localized system of that region. You must use the
default code page/character set if you plan to use specific localized
characters.
■
You cannot use a Microsoft SQL Server alias that matches the local
computer name, but which really points to a remote Microsoft SQL Server
(whether in another resource group on the same physical node of a cluster
or actually on a different computer).
Note: In Unicenter NSM r11, the database tool used for the MDB is Ingres for
Windows, UNIX, and Linux. In Unicenter NSM r11.1 and r11.2, however, the
database tool used for the MDB is Microsoft SQL Server. The documentation
for Unicenter NSM r11.2 contains information for both Ingres databases and
Microsoft SQL Server databases, so be aware that some of it may not apply to
your installation, depending on the Unicenter NSM version you are running.
36 Implementation Guide
Web Environment Support
Web Environment Support
This release supports specific web browsers, web servers, and servlet
environments.
Supported Web Browsers
The release of Unicenter NSM supports the following web browsers:
■
Microsoft Internet Explorer, Version 6 SP1 and later
■
Mozilla Version 1.6, Firefox and later
Supported Web Servers and Servlet Environments
Unicenter NSM web applications run as Java Servlets and conform to the Java
Servlet 2.3 and JSP 1.2 specifications. Unicenter NSM is shipped with Apache
Tomcat, so a web server is not required to install or run Unicenter NSM web
applications. JavaScript must be enabled on all supported web browsers for
Unicenter NSM applications to function correctly.
The Management Command Center Java Browser interface supports the
following web servers:
■
Apache Server Version 2.0 and later
■
Microsoft Internet Information Services (IIS), version installed with the
operating system
Java Browser Support
The Unicenter Browser Interface, Web Reporting Server (WRS), Unicenter NSM
dashboards, and Systems Performance reports use Java applications in their
web pages and require the following browser support for Java:
■
Unicenter NSM dashboards work with built-in Java support in a web
browser, if present. If the built-in support for Java is not present, the
dashboards require that you install the Java Runtime Environment (JRE)
from Sun Microsystems.
■
WRS and Systems Performance reports require that you install the Java
Runtime Environment (JRE) from Sun Microsystems for the web browser.
Chapter 2: System Requirements 37
Adobe Acrobat Reader Support
If JRE is not detected on the system when you try to use WRS, Unicenter NSM
dashboards, or Systems Performance reports, a link appears so you can
download JRE from the Sun Microsystems website. When you install JRE for
Windows, make sure that you select the "Offline Installation" option instead of
the "Install from the Web" option. Unicenter NSM web applications support JRE
1.5.10 or later.
The graphical displays on dashboards and reports do not appear unless built-in
support or the JRE is present.
Adobe Acrobat Reader Support
WRS and Systems Performance reports let you export reports in PDF format.
To view reports in PDF format, the computer running the web browser or the
Management Command Center must have Adobe Reader version 7.0 or later
(for Windows) or Adobe Reader version 5.0.9 or later (for Linux) installed.
To download the appropriate version of Adobe Acrobat Reader, go to
http://www.adobe.com. A copy of the Adobe Acrobat Reader installation image
is also available on the Unicenter NSM installation media.
Note: To help ensure that you can correctly open reports using Acrobat
Reader, open Acrobat Reader and clear the Internet category option "Display
PDF in browser" under Edit, Preferences.
Unicenter NSM Agent Requirements
For information about systems requirements for Unicenter NSM agents, see
Inside Systems Monitoring. Unicenter NSM agents are supported on the same
operating systems as those supported by Unicenter NSM.
Unicenter Remote Monitoring Requirements
Unicenter Remote Monitoring requires .NET Framework 1.1 SP1 on all
supported Windows platforms. Install the .NET Framework service pack before
you install Unicenter Remote Monitoring.
38 Implementation Guide
Unicenter Management for Microsoft Operations Manager Requirements
Unicenter Management for Microsoft Operations Manager
Requirements
Unicenter Management for Microsoft Operations Manager has the following
requirements:
■
Microsoft Operations Manager 2000 SP1 or later
■
WorldView repository
■
Installation on a Unicenter NSM Event Manager
■
The same hardware requirements as Unicenter NSM r11.2 Manager
■
Unicenter NSM Manager running on Windows 2003
CA System Center Operations Manager Integration
Before installing the Unicenter NSM SCOM Integration, your system must meet
minimum software requirements.
Computer where the Integration Is Installed
The computer where the SCOM Integration is installed must have, at
minimum, the following software:
■
The Microsoft System Center Operations Manager Console Client, which
provides the files necessary to integrate with SCOM
■
A Unicenter NSM Event Agent
■
A Unicenter NSM WorldView Client
Elsewhere in the Domain
The domain where the SCOM Integration is installed must meet the following
minimum requirements:
■
An instance of System Center Operations Manager must be installed and
running.
■
A Unicenter NSM Event Manager must be present because the SCOM
Integration creates Unicenter NSM events from SCOM alerts. The Event
Manager may be on the same computer as the SCOM Integration.
Chapter 2: System Requirements 39
CA High Availability Service (HAS) Requirements
■
A Unicenter NSM WorldView Manager must be present because the SCOM
Integration creates objects in the WorldView Repository. The Integration
reflects the status of those objects, and SCOM alerts are created based on
that status. The WorldView Manager may be on the same computer as the
SCOM Integration.
■
An instance of the Management Command Center must be present
because it is the user interface that shows SCOM objects in the WorldView
Topology, and alerts in the SCOM Alert Viewer. The Unicenter MCC may be
on the same computer as the SCOM Integration.
CA High Availability Service (HAS) Requirements
CA High Availability Service (HAS) has the following requirements:
Windows:
■
The same hardware requirements as Unicenter NSM r11.2 Manager
■
The Unicenter NSM Manager must be running a version of Windows
suitable for HAS.
■
On computers running Microsoft Clustering Services (MSCS), HAS must
run under a cluster domain account to operate across the cluster nodes.
■
The Unicenter NSM r11.2 Supplement includes High Availability services.
These services enable HA-ready components in clustered configurations.
HA-ready components provided by this deliverable are consistent with
those enabled in the CCS / NSM r11.2 parent project. Any components or
configurations that have not been certified as HA-ready in Unicenter NSM
r11.2 will not be considered HA-ready in the Unicenter NSM r11.2
Supplement.
■
HA readiness will be limited to Linux platforms only. Additionally, Unicenter
NSM r11 Event and calendar on Linux were not certified on a cluster and
are not planned to be HA-ready in Unicenter NSM 11.2 UNIX or Linux.
UNIX
Unicenter Cisco Integration Requirements
To use Unicenter Cisco Integration, you must have access to the Cisco nmidb
file that contains device model information. The file is accessible through your
cisco.com login privileges, or from your CiscoWorks product media. You can
obtain a valid Cisco user account and password from your channel partner or
you can log a request at http://cisco.com. (Windows only)
40 Implementation Guide
Unicenter for Pocket PC Requirements
Unicenter for Pocket PC Requirements
Unicenter for Pocket PC has the following requirements (Windows only):
■
Any certified Pocket PC 2002 device with a minimum of 32 MB RAM and a
wireless LAN card
■
Microsoft ActiveSync 3.5 or later (for installation only)
■
Windows server running the Unicenter NSM Enterprise Manager
Systems Performance Requirements
The Performance Trend and Chargeback components of Systems Performance
require the existence of Excel from Microsoft Office 2000, Office 2003 or Office
2007. (Windows only)
Chapter 2: System Requirements 41
Chapter 3: Product Architecture
This section contains the following topics:
Implementation Layers (see page 43)
Unicenter Systems Performance (see page 59)
Distributed Intelligence Architecture (see page 60)
Classic Versus Continuous Discovery (see page 60)
Implementation Layers
For implementation purposes, Unicenter NSM is implemented in a distributed
manner and is arranged into four layers:
■
Visualization
■
MDB/Enterprise - Database Level
■
Managers
■
Monitoring Technology
Visualization
The visualization layer represents user access to the various GUIs and
management points. This includes:
■
Management Command Center
■
WorldView (Maps, Class and Object Browsers, Viewers, Wizards)
■
Unicenter Browser Interface (Remote and Web-based Viewer)
■
Unicenter Management Portal
■
Unicenter Remote Monitoring (Administrative Interface)
■
Web Reports and Dashboards
■
Unicenter Configuration Manager
■
Classic Enterprise Management
For the architecture of the GUI layer, ensure that adequate response and
access is provided among the WorldView clients and both the MDB enterprise
level and the associated management points. If there is a heavy concentration
of GUI users in one location, place the related repository computers in close
proximity.
Chapter 3: Product Architecture 43
Implementation Layers
Which GUIs you decide to employ and at what level is determined by the role
and responsibility of the targeted viewer. For example:
■
Administration and Operations staff may use the Management Command
Center, Unicenter Browser Interface, WorldView, or Configuration
Manager.
■
Management may use the Management Command Center or Unicenter MP.
■
End users or clients may use Unicenter MP or Web Reports and
Dashboards.
These GUIs will vary depending on your organization’s requirements, the roles
each individual needs to support, and the platform and supporting features of
each of the individual interfaces.
MDB
The MDB is a single database containing common tables and multiple productspecific tables that were previously contained in separate product databases
(for example, the Unicenter NSM WorldView Common Object Repository).
Based on a central management database, the MDB serves as the enterprise
database integrating all CA products. As the primary reference point, the MDB
lets you collect asset resource information from a centralized entity, or
database, eliminating costly access on the network.
From a Unicenter NSM perspective, all WorldView data is now stored in the
MDB (formerly known as the Common Object Repository) and is referenced as
the MDB. Typically, there is one MDB, but there may be times when for
physical reasons (many managed objects), organizational reasons
(departmental segregation), or network considerations (international office
locations) you may need multiple MDBs. If this is the case, use the Repository
Bridge to synchronize WorldView data between the MDBs.
The Repository Bridge lets you roll up the higher level monitored objects to an
enterprise MDB, or you can use the Repository Bridge to segregate a single
MDB into multiple MDBs, thereby separating departmental reference points
from the enterprise-wide view.
You can also install a distributed MDB where the component databases are on
different computers. In this way, you can have a remote MDB (part of a
distributed MDB) for TrapManager and a separate one for DSM, WorldView,
Alert Management System, Continuous Discovery, and so forth.
Although the number of MDBs deployed in an environment may differ, you
should always have one enterprise MDB serving as the central database. The
enterprise MDB provides a complete view of the environment status that other
product installations can use.
44 Implementation Guide
Implementation Layers
Use the following guidelines for MDB planning:
■
Any files that are accessed by the DBMS Server must be configured on the
Linux file system EXT3 (Third Extended File system), or another nonjournal file system.
Note: CA does not recommend use of the Reiser file system for the MDB.
This file system is not suitable for use by a large database.
■
When a central MDB is not feasible, create an enterprise MDB to
consolidate the data from the multiple MDBs in the environment.
■
Increase the computer requirements as necessary for the enterprise MDB,
when the MDB is integrating information for multiple CA products.
Consider the information provided in the readme for each product and plan
accordingly.
■
Treat the enterprise MDB as a business critical service, which may benefit
from installation on a highly available server system (a cluster, for
example). The cluster system may then be monitored using the CA High
Availability Service (HAS). See the appendix Making Unicenter NSM
Components Cluster Aware and Highly Available for additional information.
■
Locate a server with an installed MDB close to the majority of users who
will require access.
■
Use the Repository Bridge for MDB large-scale roll-ups for WorldView
objects.
■
Use the Repository Bridge when you require departmental MDBs for
WorldView objects.
For additional details about working with the MDB, see the Management
Database Overview.
Managers
The manager layer requires planning. It is possible to have multiple layers of
managers to scale to your network and requirements. The most common
managers in Unicenter NSM follow:
■
WorldView
■
DSM
■
Continuous Discovery
■
Event
■
Alert
■
Job Status
Chapter 3: Product Architecture 45
Implementation Layers
WorldView Manager
WorldView Manager monitors the MDB for changes to WorldView objects,
propagates severity, and populates Dynamic BPVs. The WorldView Manager
also exposes WorldView data to the Unicenter MCC and provides data to
reports, dashboards, and Unicenter MP. As a best practice, the WorldView
Manager must reside on the MDB server. This component contains the
Severity Propagation engine and the Dynamic BPV engine.
Note: The WorldView Manager component cannot be installed on a Windows
Domain Controller.
DSM Manager
The Distributed State Machine (DSM) is the manager of agents and provides
the first level of fault correlation in Unicenter NSM. An agent traps, or the
manager polls, to ascertain whether there is a fault (or the possibility of one).
Typically, you will want to use more than one DSM, not because of enterprise
size, but because the DSM functionality is able to failover. The DSM is mission
critical; treat the loss of enterprise monitoring the same as a critical server
failure. Use a second DSM to handle the failover, when necessary, or a remote
DSM that is responsible for dedicated locations (reporting to a central MDB).
Continuous Discovery Manager
The Continuous Discovery Manager consolidates discovery information
gathered by its data collectors, the Continuous Discovery agents, with the
MDB. When a new device is discovered on the network by an agent, it updates
the MDB with this information. The manager monitors when it has last seen
traffic for a device through various mechanisms that include DHCP and
network traffic monitoring, scanning the ARP caches of routers, and scanning
monitored subnets through various protocols such as ICMP (ping), SNMP,
HTTP, and so forth.
Discovery information is submitted to the MDB to be shared among
Unicenter NSM components as well as other CA products. When new devices
are discovered, these products can use the MDB Distributed Intelligent
Architecture (DIA) cell to receive event notification to define business policy.
46 Implementation Guide
Implementation Layers
Event Manager
The Event Management System is the focal point for managing enterprise
events from a variety of sources throughout your network. Through the
console log, you can monitor event activity and immediately respond to events
as they occur. By filtering messages that appear on each console, you can
retrieve specific information about a particular node, user, or workstation.
Event Management processes messages and their related actions through the
following components:
■
Console log views let you restrict message access to authorized users and
user groups.
■
Calendars let you establish date and time controls for automated event
processing.
■
Message record and action profiles let you identify events that are
important to your operation and define the special processing that
Unicenter NSM performs when encountering these events.
■
Advanced Event Correlation (AEC) enhances your message record and
action policy by identifying a set of events that you want to monitor and
correlate and what actions should be performed if correlation exists or
does not exist.
The following schema is typical for Event Managementt implementation:
■
Collect and centralize
■
Notify and escalate
■
Automate and report
In a distributed environment, you can link many levels of Event Management
to process cooperatively. A small implementation may have just one Event
Manager; large implementations may have more Event Managers in a layered
approach.
Use the following guidelines for Event Manager planning:
■
Use escalation hierarchies if possible (filter and forward).
■
Ensure you have enough resources on the machine for the volume.
■
Be as generic as possible with your messages and actions.
■
Take advantage of console color-coding.
■
Remember the 80/20 rule; some are vital and many are trivial.
■
Use Text matching rather than Scan wherever possible in message record
definitions.
■
Consider deploying non-root event agents on Linux or UNIX wherever
possible for increased security.
Chapter 3: Product Architecture 47
Implementation Layers
In general, as with DSMs, it is best to place Event Managers as close as
possible to the objects with which they communicate. Avoid having lower level
Event Managers simply forward all of their messages to higher level ones.
Think of Event layers as escalation points. Each Event manager handles what
it can, and escalates what it cannot to the next higher level (as configured on
each Event Manager using message records to identify events that require
special handling and message actions to specify what Event Management
should do when it detects a match between an input event message and a
message record). This keeps traffic levels to a minimum, and does not flood
higher level Event Managers with trivial messages. Placing Event agents on the
same level as DSMs is a good approach. In situations where a message gets to
the highest level Event Manager and still requires escalation, you can create a
message record and action that creates a trouble ticket.
Note: Event agents do not require the message and action database to reside
locally; only the committed Decision Support Binary (DSB) is required.
In a situation where the Event Manager computer fails, locally generated
messages would not be created; in an escalation-based setup, however,
several critical messages would arrive from lower level Event Managers. A
good approach is to have a DSM control the activation of failover policy and to
plan multiple escalation points in case of failure.
Event Managers are scalable and can handle large volumes of messages
without problems. Place Event Managers where localized action processing is
most effective (usually leading to a hierarchical placement at various levels in
the environment). Depending on your requirements, it is sometimes
reasonable to have multiple Event Manager hierarchies based on computer
type, not only locale.
Alert Manager
The Alert Management System (AMS) is a tool for organizing and tracking the
most important events in an enterprise or a logical segment of an enterprise.
It lets you focus on and manage the highest severity IT events.
With AMS you can do the following:
■
Specify the situations that create alerts, and define alert policies.
■
View and manage alerts in multiple panes of the MCC.
■
Link to Unicenter Service Desk, which is a customer support application
that manages calls and IT assets, tracks problem resolution, and shares
corporate knowledge.
48 Implementation Guide
Implementation Layers
Alerts are important (or critical) events generated by one or more source
events in the Event Management System (EMS). You can organize, view, and
manipulate alerts in complex ways with the Unicenter MCC.
Alert Management maintains specialized events processed through message
records and actions or AEC policies. An approach based on class makes
extending and tailoring policies to any environment easy.
We recommend that an Alert Manager be as close as possible to its
corresponding Event Managers. You can install multiple Alert Managers on a
functional or geographic basis for large enterprises. When determining your
management requirements, consider how you want your Event and Alert
configuration divided or consolidated, and where you would like the important
and critical events processed to create alerts. Unlike Event Managers, you
cannot configure Alert Managers to be organized in a hierarchy or to forward
alerts. You can accomplish forwarding and reduction with Event Managers
(where an Alert Manager is at the highest level of the hierarchy). At the
appropriate level, you should implement message record and action event
policy (forwarding any alert created to the Alert Manager).
Note: Alerts should be a small subset of the events that occur. They should
represent only events that require human intervention or provide information
critical to continued normal operations. There are two reasons for this. First, if
few alerts are generated, the operations staff can focus more easily on what is
important. Second, AMS is a complex system and each alert consumes more
computing resources than other events. By carefully designing your AMS
configuration and policy, you can help ensure that you get the most benefit
from AMS.
Job Manager
Another commonly implemented enterprise management function is Unicenter
Job Management. Job managers control job scheduling. Job agents process
commands at the direction of job managers. Installing a job agent enables the
computer to be part of job process execution. Configure one or more job
managers to direct job scheduling; configure one or more job agents across
different machines and platforms to execute jobs.
Job management can span multiple platforms; job managers are supported on
the following platforms:
■
MVS
■
UNIX/Linux
■
Windows
Chapter 3: Product Architecture 49
Implementation Layers
Job agent support is provided through the Unicenter Universal Job
Management Agent. It supports the following platforms:
■
OpenVMS
■
OS/400
■
UNIX/Linux
■
Windows
The job agent’s function is to execute and track the status of jobs on the local
system; the job manager’s function is to instruct and manage the job agent.
Use the ability to schedule and track jobs across multiple platforms to allow
flexibility in the architecture. For example, a UNIX job MANAGER can control
not only UNIX job agents but also Windows job agents.
Remote CAICCI, the CA Common Communication Interface, is required if you
are going to use cross-platform scheduling and must be installed and
configured to connect to any computer that is part of cross-platform
scheduling.
Multiple job managers can schedule to each job agent. In a centralized job
management environment, a single server schedules and monitors all job
related activity (for all agents on all systems). In a decentralized environment,
multiple job managers coordinate the jobs on multiple systems and may even
perform tasks for other job managers.
Place job managers on any host that runs scheduled production work. You can
distribute job managers throughout the environment and coordinate them
from a central location. This usually fits in well with the Event Manager and
DSM Manager locations. Setting up a single locale and then replicating it to
other locales is an efficient way to proceed with your implementation. Also,
mission-critical processing on a single host is a good reason for placing an
additional job manager on that host. The CA mainframe solutions such as
Unicenter CA-7 Job Management (Unicenter CA-7) function as both job
manager and job agent in the distributed architecture.
Use the following guidelines for job manager planning:
■
Install job managers on mission-critical computers; install job agents on
other computers.
■
Designate an enterprise job manager for top-level processing.
■
Do not forget the mainframe.
50 Implementation Guide
Implementation Layers
Monitoring Technology
CA provides two methods for monitoring your network resources: Agent
Technology and remote monitoring (RM). The topics that follow describe and
compare the two methods.
Agent Technology
Unicenter NSM employs many types of agents, including System, Event, and
Job.
For Agent Technology to perform its function, all of the following components
must work together:
Agents
Monitors the resources (operating system, log files, MS-Exchange Server,
and so on) and, based on policy, forwards trap information to the DSM.
DSM
Converts the trap information to object state information and forwards it
to the MDB.
MDB
Records the object information for use and displays it in the various
Unicenter NSM interfaces.
Interface
Displays the object state information.
Although you can install all of these components on the same computer, you
will most likely install two or more on different computers. A simple
configuration includes the three Agent Technology layers--a number of Agents
communicating with a single DSM that in turn communicates with a single
WorldView.
This configuration is simplified, but it introduces basic pieces of each Agent
Technology layer before you evaluate more complex implementation
strategies.
Determine exactly what computers need a performance agent. Implementing
performance agents on a standalone server or a workstation may not be
necessary. Only implement those components that serve a stated business
requirement. Remember, you want to start with the business requirement, not
the technology.
Chapter 3: Product Architecture 51
Implementation Layers
You can configure agents to monitor specific resources or metrics they should
examine, and what level should be considered a problem for that metric
(commonly known as a threshold). When a threshold is met, the agent sends a
trap to its managers.
Note: Agents can have multiple trap destinations, which is useful for failover
situations.
Ideally, traps are used when an agent detects an exception. When a manager
polls an agent, it creates more traffic than a trap. A good practice is to set the
poll level according to the type of network connection and the importance of
the machine you are managing. Traps may not occur frequently because
agents respond to polls from a manager. This is normal behavior. Use polls to
ensure that the managed device is still responding to requests. A good practice
is to have a larger poll interval (greater than 10 minutes) in a reliable network
environment.
Unicenter NSM supports agents on a wide range of platforms; however, there
are platforms where agents cannot be installed. These platforms may be
critical to your environment, in which case you can monitor them using
proxies. Proxies bring the information from the unsupported platform into the
Unicenter NSM domain. For example, you can view console logs from an HP
3000 machine piped to a managed Solaris (or serial) port fed into a Windows
machine.
You can also use Remote Monitoring to support platforms where agents cannot
be installed. See the topic, Unicenter Remote Monitoring Architecture and also
the scenario, Agentless Monitoring and Portal-Based Visualization in the
chapter “Implementation Scenarios” for information about this method of
monitoring your environment.
Agents are instrumental in the environment, reporting conditions and status to
their manager (a DSM), while providing the capability to drive the
environment. Like any other software, agents have resource requirements.
Agents are scalable and monitoring by an agent is designed to warn of
impending problems. If the computer hard drive on which you intend to install
the agent is full, consider a system upgrade before implementing the agent. In
general, agents should reside near the managed resource.
52 Implementation Guide
Implementation Layers
Use the following guidelines for agent planning:
■
Determine which computers require monitoring.
■
Consider scheduling only a ping to a computer; it may be all you need.
■
Ensure that you have enough resources to run the agent.
■
Consider dual trap destinations (to more than one DSM) for failover
purposes.
■
Use system agents for basic application monitoring (processes, services,
files, and so on).
■
Ensure that you manage configurations centrally and automatically
through Unicenter Configuration Manager.
■
Consider using Unicenter Remote Monitoring (agentless monitoring) if you
cannot install an agent (because of dedicated systems or for liability
reasons).
Unicenter Remote Monitoring Architecture
The Unicenter Remote Monitoring architecture consists of three tiers. The first
tier contains a Unicenter NSM Windows manager with the Administrative
Interface (AI) installed. The AI lets you configure the attributes of monitored
resources, view the current state of monitored resources, and through
WorldView, the AI presents a centralized view of your enterprise.
The second tier contains the Unicenter Remote Monitoring agents, which are
deployed throughout your enterprise running as a Windows service, usually on
dedicated monitoring computers.
Although Unicenter Remote Monitoring can remotely monitor UNIX, Linux, and
Mac OS X servers, the Unicenter Remote Monitoring agent is currently
supported only on Windows platforms.
The third tier contains the resources being monitored by each Unicenter
Remote Monitoring agent, which are the workstations and servers running in
your corporate environment.
Unicenter Remote Monitoring itself has three major components:
■
The Administrative Interface (AI) lets you discover resources, configure
selected resources, and receive updates on the status of monitored
resources.
■
The agent is the main processing module, which polls each monitored
resource continuously and determines whether an error has occurred.
■
The local XML data store records the configuration data for each Unicenter
Remote Monitoring agent.
Chapter 3: Product Architecture 53
Implementation Layers
Comparison of System Monitoring Products
Determining which method you want to deploy for a system in your enterprise
depends on several factors, including the information you must monitor to
ensure the health and availability of your network resources.
Consider using Unicenter Remote Monitoring (agentless monitoring) when you
cannot install a remote agent for dedicated systems, or for liability reasons.
Scalability compared to ease of deployment is also a consideration. The size
and growth potential of your IT environment is an important factor. Agent
Technology monitoring uses an approach that requires you to deploy agents
and then scales in larger environments because the monitoring load is
decentralized and network bandwidth is not consumed to do monitoring.
The following table compares the general attributes of each monitoring
method.
Feature
Unicenter NSM Agent
Technology
Unicenter Remote
Monitoring
Managing
Component
Distributed State Machine
(DSM)
Agent
Managing
Platforms
Windows, UNIX, Linux
Windows only
Management
method
Monitoring sensor, or agent,
installed on each remote host
Agent queries each
monitored host for its
current status
Communication
protocol
Host sends SNMP traps to
DSM only if status changes,
and DSM polls host to detect
health
Native operating system
queries from agent to
remote hosts
Overall
Footprint
DSM manager piece and
browsers installed on
dedicated servers, and
appropriate sensors installed
on each host
Agent and GUI interface
manager piece installed on
dedicated servers. Nothing
installed on hosts
Configuration
Method
Configset models applied as
profiles centrally by Unicenter
Configuration Manager
Centrally configured
through Administrative
Interface
54 Implementation Guide
Implementation Layers
Feature
Unicenter NSM Agent
Technology
Unicenter Remote
Monitoring
Benefits
Manager runs on multiple
platforms; in-depth
monitoring of diverse data;
manager can monitor itself;
manager retains history of
events, limited network traffic
Lightweight, speedy
implementation and
discovery, easy
configuration, user can
choose exception only
reporting, reduced support
and management costs
Integration
With Event Management,
WorldView, and Management
Command Center
With Event Management,
WorldView, Management
Command Center
Security
Support of SNMPv3, and
community strings
Agent utility defines
privileged users.
Monitored Information
The following tables compare the type of data you can monitor using each of
the two monitoring methods.
General Agent Information
AT
RM
Remote monitoring configuration (resources on remote
machine)
*
Y
Discovery **
Y
Y
Scalable in larger environments
Y
N
Easy deployment
N
Y
IP devices (any machines on the network), ICMP (ping) only
N
Y
Novell Netware
Y
N
Windows NT / 2000 / XP / 2003
Y
Y
Tier 1 UNIX (AIX, HP-UX, Linux, Solaris). For RM, Tru64
Y
Y
Programmable Watchers--monitor result of any user defined
metric combination
Y
N
Hardware monitoring (for example, CPU temperature, fan
speed, UPS State and so on)
Y
Y
* Only certain resources such as files, directories, and printers can be
monitored remotely.
** Automatic discovery of objects can be monitored by using Adaptive
Configuration or “AutoWatchers.”
Chapter 3: Product Architecture 55
Implementation Layers
Windows System Monitoring Features
AT
RM
Processors--load or loss
Y
Y
Memory--physical, virtual, paging file
Y
Y
Logical volumes--throughput, fragmentation, free space, used Y
space
Y
Mounts--change, loss
Y
N
Distributed files systems (Win 2000)--loss, available replicas
Y
N
Quotas--space per user
Y
N
Directories--number, size, timestamp
Y
N
Files--number, size, delta, timestamp
Y
N
Processes--number, threads, children, memory, CPU usage
Y
Y
Services--activity, existence, optional restart
Y
Y
Jobs--existence, number of processes, CPU usage
Y
Y
Sessions--number, memory, CPU usage, activity
Y
Y
Printers--events, queue length, loss
Y
Y
Network interfaces--send/receive packets+bytes, error rates,
total values
Y
Y
Registry entries--existence, value, change in subtree
Y
Y
ASCII file content monitoring--user-defined, created files
Y
N
Event log content monitoring--native system logs
Y
Y
Linux and UNIX Monitoring Features AT
RM:
AIX/HP/Linux/Sun/T64
System--release, version, details, node
name, system name, boot time
Y
N/N/N/N/N
CPU--total, user, system, wait, idle CPU
usage, context switches (for AT,
includes overall and per CPU; for RM,
includes overall only)
Y
Y/Y/Y/Y/Y
Load--average load over 1, 5, 15
minutes
Y
Y/Y/Y/Y/Y
Real memory--used, total
Y
N/N/N/N/N
56 Implementation Guide
Implementation Layers
Linux and UNIX Monitoring Features AT
RM:
AIX/HP/Linux/Sun/T64
Physical memory:
Y
Y
- Scan Rate
Y
N/N/N/N/N
- Free memory (KB)
Y
Y/Y/Y/Y/Y
- Pages paged in/out
N
Y / Y / N/ N / N
- Total amount changed
Y
N/N/N/N/N
- Size free list
N
Y/Y/N/N/N
- Active free pages
N
Y/Y/N/N/N
Swap space--used, total, per swap file
used, per swap total
Y
N/N/Y/Y/Y
File systems--KBytes used, total, free
(no inodes for RM)
Y
Y/Y/Y/Y/Y
Mounts--loss, total, free, KBytes
Y
N / N / N / N/ N
Physical disk throughput--blocks in/out
Y
Y/Y/N/Y/Y
Files--existence, file size (KB), file size
delta, modified date
Y
N/N/N/N/N
Processes--number of instances,
children, CPU, size
Y
Y/Y/Y/Y/Y
Printer queues--number of jobs, status
of queue
Y
N/N/N/N/N
Network--in packets, out packets,
collisions, interface name
Y
Y/Y/Y/Y/Y
IPC--total resources, message queues,
shared memory, semaphores
Y
N/N/N/N/N
IP Monitoring Features
AT
RM
IP response times/availability
N
Y
Port availability (IP services)
Y
Y
Agent Monitoring Features
AT
RM
Multiple poll methods--disable, poll only, poll and query,
query only
Y
Y*
Configurable thresholds for severity level
Y
Y
Chapter 3: Product Architecture 57
Implementation Layers
Agent Monitoring Features
AT
RM
Delta warning and critical statuses for monitoring changes in
analog values
Y
Y
Overloaded thresholds
Y
N
Call backs to rectify problems automatically on the monitored Y
machine
N
Detailed event information sent to Unicenter Event
Management Console
Y
Y
Ability to monitor the removal of a resource (Loss
Monitoring)
Y
Y
Ability to avoid state change in data that spikes by using
lags/breaches
Y
Y
Available resource lists to aid with configuration of the agent
Y
Y
Monitoring of cluster resources **
Y
N
Automatic Adaptation of Monitoring Thresholds ***
Y
N
Policy based creation of Monitoring Objects ****
Y
Y
* Disable and poll are valid for Remote Monitoring
** Allows you to discern between a failover and a loss of shared resource
*** By means of Adaptive Configuration
**** By means of Auto Watchers or Adaptive Configuration
Collection of Historic Data
AT
RM
Data collected by agent stored into Performance Cubes for
historical analysis
Y
N
Data collected by agent passed to Performance Scope for
real-time analysis
Y
N
Event history (history of state changes) stored in agent
Y
Y
Event Message Handling
AT
RM
Status events sent to Unicenter Event Management Console
Y
Y
Integration with Unicenter Service Desk
Y
Y
Place agent into maintenance mode to stop event
propagation
Y
Y*
Provisioning of NSM Event Definitions
Y
Y
58 Implementation Guide
Unicenter Systems Performance
* Even if the monitoring of a single resource is stopped, agent continues to
monitor all other resources.
Visualization
AT
RM
Visualized in 2D Map
Y
Y
Visualized in MCC
Y
Y
Visualized in Unicenter Management Portal
Y
Y
Unicenter Systems Performance
The computing facilities in many companies typically comprise a large and
diverse collection of machines spread over a wide geographic area. The
Systems Performance architecture supports such a distributed environment by
providing high levels of scalability and enabling easy configuration across
many thousands of machines. Furthermore, because it is often desirable to
define logical groupings within the enterprise and manage each of these
groups independently, the architecture implements the concept of multiple
configuration domains.
Applications like Performance Scope and Performance Reporting retrieve
performance data from the Performance Data Grid (PDG). This grid has
multiple levels: the Enterprise Server Node, the Distribution Server Nodes, and
the Managed Nodes.
In essence, the grid creates a single image of the performance data for the
entire enterprise and grants you seamless access to this data. The grid
contains performance data for the following machines, resources, and times:
■
All the machines in your enterprise that have ever been monitored
■
All the resources capable of being monitored
■
All times from when you first collected performance data through to the
present time
Performance Agents (running on the managed nodes) report to the
Performance Distribution Servers, which in turn report to a Performance
Domain Server. Both the Domain and Distribution Servers run as persistent
services or daemons, so they can react immediately to registration requests
from agents and service instructions from the Performance Configuration
application.
For a complete discussion of Unicenter Systems Performance, see the Inside
Systems Performance guide.
Chapter 3: Product Architecture 59
Distributed Intelligence Architecture
Distributed Intelligence Architecture
Distributed Intelligence Architecture (DIA) allows a central location to manage
all components and aspects of a network. DIA makes data requests and
retrievals standard across different Unicenter components by providing a
generic mechanism that permits the dynamic deployment of necessary files to
facilitate the correct monitoring of any given system. Deployment is generic
and open to growth. DIA allows for high speed, secure communications to
transport data while providing remote node management and inherent failover
capabilities.
For a detailed discussion of DIA, see the appendix "DIA Reference."
Classic Versus Continuous Discovery
Discovery is the process by which network devices are found and classified and
then placed in the MDB as managed objects. The Agent Technology WorldView
Gateway service locates agents running on the network objects. A common set
of classification rules lets you tailor your discovery to your environment.
Note: An MDB must exist before you can run Discovery to discover your
network devices and populate the MDB.
Once objects are defined to the database, you can view, monitor, and manage
these objects and their Management Information Base (MIB) through the 2D
Map, ObjectView, and the Topology Browser. You can manage the entities they
represent using Event Management, Manager/Agent Technology, and thirdparty manager applications.
When you install your product, decide which type of discovery you want to
use:
Classic Discovery
An on-demand process that lets you decide which subnets you want to
discover and when. You can also configure Classic Discovery to run in
regular intervals, which can be used as an alternative to Continuous
Discovery and ensures that your discovered environment in the MDB is
always current. You can start a Classic Discovery from the Discovery GUI,
the Unicenter MCC, the Unicenter Browser Interface, or the command line.
60 Implementation Guide
Classic Versus Continuous Discovery
Continuous Discovery
An event-driven and ongoing process. It employs a manager and agents
that continuously scan your network in real-time mode for new devices or
changes in IP addressing of existing IP devices. You can configure
Continuous Discovery for optimal load balancing between the Discovery
agents and the Discovery Manager. If you choose this method of
discovery, you must install the Discovery Agents and the Discovery
Manager.
Note: We recommend that you do not use both discovery methods. After a
device is under Continuous Discovery control, it should not be discovered with
Classic Discovery.
Deployment of Discovery Managers
Due to its distributed nature, the deployment of managers and agents is very
important. Manager granularity primarily depends on the hosting server's
capability, which includes memory and processing bandwidths. Since a
manager aggregates the agents' subnets, the bandwidth required is directly
proportional to the number of subnets and their constituent devices. Discovery
Manager granularity may also depend on other factors, such as administrative
issues. For example, an enterprise's network may be geographically dispersed
and internal domains may exist, such as NA, EMEA, AP, and so forth. It may
be appropriate for your enterprise to deploy managers and agents based on
these geographical regions.
Deployment of Discovery Agents
Agent granularity also depends on the agent's hosting server capability.
However, additional considerations apply. Discovery employs various nonintrusive methods, such as sniffing and DHCP listening, which enable real-time
discovery. These methods require proximity to the events generated; that is,
they require close proximity to the hosts making DHCP and ARP requests. To
capture these events, an agent must be deployed in that subnet. Therefore,
the finest agent deployment granularity that you can achieve is to deploy one
agent per subnet. In practice, you may need to compromise to get sufficient
coverage.
Due to the plausible constraint of deploying an agent in each subnet, you
could enable DHCP-based discovery on the Discovery Manager to get wider
coverage. In this case, the Discovery Manager must be deployed on the same
subnet as the DHCP server. Since a corporate network may have multiple
DHCP servers, a plausible scenario may be deployment on the backup DHCP
server subnet. However this type of deployment requires changing router
configuration regarding helper addresses.
Chapter 3: Product Architecture 61
Chapter 4: Architecture Considerations
This section contains the following topics:
Introduction (see page 63)
Current Environment (see page 63)
Evolution of the Environment (see page 66)
Business Needs (see page 67)
Unicenter NSM Requirements (see page 68)
Introduction
This chapter contains architecture information that you should consider before
beginning your Unicenter NSM implementation. Review this chapter carefully
to ensure optimal results for your particular environment.
A well thought-out architecture is important to a successful production rollout
of Unicenter NSM.
Current Environment
Before designing your Unicenter NSM architecture, you must understand your
current technology environment. Start your Unicenter NSM implementation
planning by identifying the following aspects of the existing architecture:
■
Hardware and software
■
Network considerations
■
Operating standards and restrictions (security, firewalls, and naming
conventions)
Hardware and Software
To understand the physical architecture of your deployment environment,
identify the following information for your current hardware and software:
■
Number, type, and location of computers that will be impacted by this
implementation (as user interface clients, managers, managed devices, or
installed with the enterprise MDB)
■
The operating system of those computers (including release and
maintenance level)
Chapter 4: Architecture Considerations 63
Current Environment
■
Major software applications installed on those computers and their
corresponding roles (for example, mail server)
■
Available disk space and processor load on those computers
■
Open issues regarding functionality of computers or software
You need to understand how the Unicenter NSM deployment will impact the
current software applications and how those applications could impact
Unicenter NSM. Start by identifying mission-critical applications and computers
(the computers, applications, or functions that must be minimally impacted).
Your size requirements and various hardware platform capabilities will help
determine the placement of the required Unicenter NSM management points.
Depending on the components or options you deploy, you can have fewer
more powerful computers (database servers) or more less powerful computers
(software delivery). Unicenter NSM has the flexibility to allow the housing of
multiple components on a single powerful machine or distribution across
multiple servers and platforms.
In planning your implementation, we highly recommend that you test your
proposed configuration in a lab environment before deploying it in your
production environment. The lab equipment should mirror, as much as
possible, the hardware and software specifications of your production
environment. This will help you identify potential problems while the impact is
minimal.
Know the number of computers, their location, and the bandwidth available
between the central and remote locations (especially where other software will
use the enterprise MDB)--this is crucial in determining scalability. Keep in
mind that low-level functions can run on existing hardware, but it is better to
have dedicated hardware for enterprise-level functions. Typically, users
connect through administrative GUIs to the higher-level management points;
this facilitates better response times (where fewer independent functions are
executing concurrently).
Network Considerations
Your Unicenter NSM implementation will rely on the underlying network
infrastructure to function. Ensure that your implementation makes the most
efficient and effective use of network resources by understanding the
following:
Physical and logical layout
Learning the physical layout of the network lets you realistically and
correctly place Unicenter NSM management functionality. You should also
learn the logical aspects (such as LAN segments) and what devices
(servers, printers, workstations, and so on) reside on the network so you
can plan what you want to manage with Unicenter NSM.
64 Implementation Guide
Current Environment
Line speed
Know the line speed and the backbone (in place and planned) of the
network. It may be better to purchase another management server than
to upgrade the network, or to overload a WAN connection.
Load information
Measure the average and peak loads for the network to ensure that the
network can support your planned implementation. You must know the
underlying technology to determine whether a connection is busy;
Ethernet and ATM have widely different capabilities for throughput in a
stressed setting. If a connection is stressed, investigate any plans to
upgrade or add connections and consider waiting to implement that
segment.
The distributed nature of Unicenter NSM lets you customize the architecture to
provide the right solution. However, you need all the available information to
plan the architecture correctly.
Operational Standards and Restrictions
Understanding the current environment requires knowing the following
operating standards:
Scheduled downtimes
Knowing when a system will be down helps you minimize or eliminate the
false alarms that generate when Unicenter NSM cannot detect that system
(and the objects it is monitoring on that system).
Existing firewalls and which ports are available to open
Unicenter NSM and its many options provide tools to both monitor and
manage enterprise resources that sometimes span very complex and
extensive networks. To perform these tasks, Unicenter can communicate
using multiple protocols (TCP/IP, SNMP, and UDP) and multiple
communication ports. In cases where agents or other components will be
installed outside of a firewall, additional configuration steps are required to
minimize the number of ports that must be opened through the firewall.
Security restrictions
Obtain the necessary passwords and the appropriate authorizations.
Failover requirements
Determine whether failover or fallback is the operational standard. Failover
(the switch from a primary system to a backup system) is configured to
perform automatically, while fallback is designated as a manual task.
Chapter 4: Architecture Considerations 65
Evolution of the Environment
Naming conventions
Know the naming conventions for users, computers, directories, jobs, and
so on. If no naming conventions are in place, now is a good time to
establish them.
Evolution of the Environment
Besides examining the existing environment, you should also research the
evolution of your environment. The addition of new computers, a change in
network structure, operating system changes, and the implementation of other
software solutions (especially where remote access to the enterprise MDB is
required) should all influence your architecture design. For example, if you
plan to add many new workstations, plan for an additional management point
(provided those workstations require monitoring). If a server you are targeting
for MDB installation will also be the target of several processor-intensive
software installations, consider selecting a different server. When considering
the possibilities, remember to take growth into account.
Be aware that your environment is not static and, in most cases, will evolve
and grow. An enterprise-scale Unicenter NSM implementation can take over a
year to roll out, so you should understand what environmental changes could
take place during that time. By using a tiered architecture, you can easily
handle change and growth because the environment is split into smaller
groups. For example, think of the architecture as having the following levels of
responsibility:
■
Enterprise
■
Regional
■
Office
If you add a new office, you can replicate (sized appropriately) the office level
architecture to the new office. The same is true for the regional offices.
Unicenter NSM allows for as many tiers, or levels, as you require, allowing
greater flexibility in the implemented solution.
66 Implementation Guide
Business Needs
Business Needs
Determine the business needs you expect to address using Unicenter NSM. For
example, you can install Unicenter Software Delivery to manage software
installations across multiple computers and multiple sites in a standardized
manner. Understanding the need that is driving the Unicenter NSM
implementation will help you decide which components to implement and
which customizations to make. Once you have implemented Unicenter NSM,
this information will provide insight into how to customize the components to
optimally monitor and manage your infrastructure. Identify the following:
■
What devices will you monitor or manage?
■
What type of reporting will you require? (Who will need those reports,
when will they be needed, and through what medium?)
■
What type of response do you require if a monitored object is unreachable
or if you receive specific error messages?
■
What are your security requirements?
■
What are your job processing requirements?
■
Where will administration occur? (If multiple locations are involved, will
each location be administered locally or remotely from a central site?)
■
Who will need administrative capabilities?
■
How much of the infrastructure will each administrator handle? Although
Unicenter NSM can handle the entire environment, can one administrator
handle all alerts, messages, events, and so forth?
■
Who will need informational-only capabilities?
■
How will you provide those capabilities (GUI access)? If you plan to use
Unicenter MP technology to give executives high-level access to the
environment’s state, what type of activity should they be able to monitor?
■
Who needs automatic notification of the status and state of specific
objects?
■
How will notifications occur (email, pager)?
■
Who will be responsible for administering the databases?
Note: Unicenter NSM spans multiple disciplines and you may find that there
are some subtle, yet critical differences in how different departments approach
IT requirements.
Chapter 4: Architecture Considerations 67
Unicenter NSM Requirements
Deliverables should always be business-related. Create a measurement
mechanism for each deliverable, so you can measure the effectiveness of the
solution. For example, in a Unicenter Remote Control implementation, the
business requirement may be to decrease by 40 percent the time it takes to
ascertain why a user cannot print. The business requirement is not to put a
Unicenter Remote Control agent on every desktop. That may be the solution,
but it is not the business requirement. Without a metric to use as a measure,
it will be difficult to pinpoint exactly how the new implementation has
improved operations and what areas need improvement.
Before deployment begins, verify the project timeline and ascertain if it is
realistic without compromising the implementation. Reach an agreement for
the implementation plan with all involved parties. We recommend a phased
implementation (preceded by technical engineering and policy development in
a lab environment) if time allows.
Unicenter NSM Requirements
The Unicenter NSM readme includes the latest Unicenter NSM requirements.
Ensure that you meet these hardware and software requirements before
beginning your implementation.
68 Implementation Guide
Chapter 5: Installation Preparation
This section contains the following topics:
Installation Methods (see page 69)
Common Unicenter NSM Server Categories (see page 72)
Pre-Installation Tasks (see page 78)
Installation Methods
You can install Unicenter NSM using any of the following methods:
■
Unicenter Product Explorer--Windows
■
setupNSM--Linux/UNIX only
■
Unattended Installation
■
Unicenter Software Delivery
■
Upgrade and Migration
Unicenter NSM Product Explorer - Windows
The Unicenter NSM Product Explorer starts automatically when you use the
Unicenter Network and Systems Management Installation DVD. Using the
Unicenter Product Explorer provides the following benefits:
■
The automated process determines your Windows platform and displays
the appropriate options.
■
The search feature (or F3) lets you find specific components for installation
by title or keyword.
■
The Product Information button lets you reference this guide and the
readme during installation.
■
The System Requirements button for each component displays the
hardware and software requirements specific to that component.
Chapter 5: Installation Preparation 69
Installation Methods
setupNSM - Linux/UNIX
Unicenter NSM for Linux and UNIX uses the installer setupNSM, which
leverages available technology from within the Unicenter brand of products.
This installer provides the following capabilities:
■
A Java-based graphical user interface for easy point-and-click selection of
Unicenter NSM components
■
Tighter integration with Unicenter Software Delivery for remote
deployment of Unicenter NSM components
■
Unattended installation of Unicenter NSM components
Unattended Installation
Unattended installation is available for Windows, Linux, and UNIX platforms,
and lets you use a response file to answer installation questions. You can
create the response file by selecting the “Build Unicenter NSM response file for
unattended install” option in the Windows setup or by running the Linux or
UNIX setupNSM installer with the -a option.
Working from the initial Product Explorer dialog (Windows) or the initial
setupNSM dialog (Linux/UNIX), you can choose to register response files to
define custom installation procedures for Unicenter NSM deployment. To
register custom installation procedures of Unicenter NSM, the setup walks you
through creating a response file that lets you request the installation of one or
more individually selected components, common agent configurations, or all
Unicenter NSM components.
The response file is a text file that you can edit or customize; it configures all
of the options during your installation. This file is ideal for use with Unicenter
Software Delivery because no prompts appear during the installation; the
answers reside in the response file.
See the topic Register Unicenter NSM with Unicenter Software Delivery in the
“Installation” chapter and the appendix “CCS UNIX/Linux Reference” for
detailed information about response files.
70 Implementation Guide
Installation Methods
Unicenter Software Delivery
Unicenter NSM lets you register Unicenter Software Delivery packages, so that
you can automate the delivery, installation, and configuration of Unicenter
NSM components across your network.
Working from the initial Product Explorer dialog (Windows) or the initial
setupNSM dialog (Linux/UNIX), you can choose to register response files to
define custom installation procedures for Unicenter NSM deployment. To
register custom installation procedures of Unicenter NSM, the setup walks you
through creating a response file that lets you request the installation of one,
any, or all Unicenter NSM components.
Once you create the response file, the complete Unicenter NSM installation
image and response file is registered to Unicenter Software Delivery as a
single package. You can create multiple response files for embedding in
Unicenter Software Delivery to support different types of installations using the
same Unicenter Software Delivery package.
Unicenter Software Delivery supports a multi-tiered architecture that lets you
stage product installation images across the enterprise and invoke the
installation from a local software store.
Note: You must install Unicenter Software Delivery Enterprise, Local, or
Workgroup Server, or an Admin Console to use this installation method.
See Register Unicenter NSM with Unicenter Software Delivery in the
“Installation” chapter for detailed instructions about this installation method.
Start Menu and Installations
When upgrading or reinstalling, log on as the same operating system user that
performed the first installation. Some aspects of the product, such as the Start
Menu folder, are intentionally tailored just to the user that installed the
product. In some cases, users may have created the Start Menu items for
more users using utilities such as CAUTCFG.EXE. Thus, if you install a prior
release as User A and upgrade to a newer release as User B, only the Start
Menu icons that User B originally had (if any) will be upgraded for the new
product. This is especially important when performing installations through
Unicenter Software Delivery, which can run either as SYSTEM or as a particular
user. Upgrading a product that was installed under User A through Unicenter
Software Delivery that is running under User B (which may be SYSTEM) will
cause this condition.
Chapter 5: Installation Preparation 71
Common Unicenter NSM Server Categories
For information about upgrading and migrating an existing version of this
product, see the Migration Guide. For the latest version of the guide, visit
http://ca.com/support. After you have logged in, in the left panel under the
Downloads topic, select "Documentation." You are directed to an area where
you can search for the guide.
Common Unicenter NSM Server Categories
The categories presented here provide recommended component selection for
servers that are typically found in a Unicenter NSM environment. These server
descriptions are not intended to be comprehensive or restrictive and some
level of adjustment will often be needed to make them specific to your
Unicenter NSM infrastructure.
Managed Server
A Unicenter NSM Managed Server represents a server that is to be monitored
by a corresponding Unicenter Monitoring Manager. A server can be monitored
either through the deployment of Unicenter Agent Technologies or through
Unicenter Remote Monitoring technology. Unicenter Remote Monitoring can
perform basic monitoring without requiring any software deployment to the
managed server. Unicenter NSM Managed Servers are enabled for monitoring
from Unicenter NSM Visualization Servers.
Unicenter NSM Agents
Unicenter NSM Components
Comments
Agent Common Services
Includes Adaptive Configuration
System Agent
Log Agent
Performance Agents
For Windows platforms, these agents
are installed through the separate
Unicenter Systems Performance
installation.
Active Directory Agent
Windows only
WMI Agent
Windows only
Event Agent
Universal Job Management Agent
72 Implementation Guide
Install only if you are using the Job
Management Option
Common Unicenter NSM Server Categories
Unicenter NSM Monitoring Manager
Unicenter NSM Monitoring Managers represent the core pieces of Unicenter
NSM technology. Through interaction with Unicenter NSM Managed Servers,
you can manage the entire enterprise with technology such as Advanced Event
Correlation, Alert Management, WorldView, Systems Performance, and Remote
Monitoring, all tied together by the MDB. You can then monitor the entire
enterprise from a central point of control using the Unicenter MCC and
Unicenter Reporting technology.
Event and Alert Manager
Unicenter NSM Components
Comments
MDB Client/Server
The CA Management Database can be
local or remote.
Unicenter knowledge base
Required with the MDB Server
Event Manager
Alert Management
Advanced Event Correlation (AEC)
Web Policy Editor
Event Management Wireless
Messaging
Notification Services Server
Enterprise Management Provider
Job Management Server
Unicenter NSM Components
Comments
MDB Client/Server
The CA Management Database can be
local or remote, but a local MDB is
strongly recommended for the Job
Management Server.
Unicenter knowledge base
Required with the MDB Server
Event Manager
Event Management Wireless
Messaging
Job Management Option
Enterprise Management Provider
Chapter 5: Installation Preparation 73
Common Unicenter NSM Server Categories
WorldView Manager
Unicenter NSM Components
Comments
MDB Server
The CA Management Database must
be local.
Unicenter knowledge base
Required with the MDB Server.
WorldView Manager
Must be installed on the MDB Server
before any remote WorldView clients
can connect to it.
WorldView Provider
Bridge Repository Service
If desired.
Continuous Discovery Manager
If desired.
Notes: Migration of WorldView data from a Unicenter NSM 3.x MSSQL
repository during an installation can only be performed when you are installing
the WorldView Manager on the MDB Server. A WorldView Admin Client
upgrade installation does not allow for migration of WorldView data. See the
Migration Guide for more information.
Distributed State Machine (DSM)
Unicenter NSM Components
Comments
MDB Client/Server
The CA Management Database can be
local or remote.
The DSM and WorldView on the same
machine must share an MDB.
This is enforced at install time.
Distributed State Machine
Unicenter knowledge base
Agent Views
OS Agent Gateway
Agent Technologies DSM Provider
74 Implementation Guide
Required with the MDB Server or DSM
Common Unicenter NSM Server Categories
Unicenter Systems Performance Domain Server
For Windows platforms, the Unicenter Systems Performance components are
installed through the separate Unicenter Systems Performance installation.
For Linux and UNIX platforms, the Unicenter Systems Performance installation
is integrated with the Unicenter NSM installer and is a component selection in
the Installation Wizard.
Unicenter NSM Components
Comments
Performance Domain Server
Typically, there is only one Domain
Server machine for an enterprise.
Performance Distribution Server
Performance Scope
Win32s
Performance Trend
Win 32s
Performance Reporting
Browser
Performance Configuration
Win32s
Chargeback
If desired, Win 32s
Performance Tools and Utilities
Unicenter Systems Performance Distribution Server
For Windows platforms, the Unicenter Systems Performance components are
installed through the separate Unicenter Systems Performance installation.
For Linux and UNIX platforms, the Unicenter Systems Performance installation
is integrated with the Unicenter NSM installer and is a component selection in
the Installation Wizard.
Unicenter NSM Components
Comments
Performance Distribution Server
Install multiple Distribution Server
machines to load-share.
Performance Tools and Utilities
Chapter 5: Installation Preparation 75
Common Unicenter NSM Server Categories
Unicenter Remote Monitoring Manager
Unicenter Remote Monitoring provides remote monitoring of Windows, Linux,
and UNIX servers without the need for agents.
Unicenter NSM Components
Comments
Unicenter Remote Monitoring
The manager must be a Windows
server.
Unicenter NSM Reporting and Configuration Manager
A Unicenter NSM Reporting and Configuration Manager enables reporting on
the state of the entire enterprise through Unicenter MP and Dashboard
technology. The Unicenter Configuration Manager allows for configuration of
Unicenter NSM Managed Servers from a central location and maintains a
comprehensive Unicenter knowledge base for configuration data.
Reporting/Configuration Manager
Unicenter NSM Components
Comments
Configuration Manager
Unicenter knowledge base
Required with Configuration Manager
System Performance Reporting
Web Reports and Dashboards
Unicenter Management Portal
MDB Server
The MDB provides a single, integrated database schema (tables, columns,
views, and so forth) for the management data stored by all CA products. The
MDB schema ties together data from all IT management disciplines and
enables integration between CA products.
Management Database Server
Unicenter NSM Components
Comments
MDB Server
Local Management Database
Unicenter knowledge base
Required with MDB Server
76 Implementation Guide
Common Unicenter NSM Server Categories
Unicenter NSM Components
Comments
WorldView Manager
Required with MDB Server.
Must be installed on the MDB Server
before any remote WorldView clients
can connect to it.
Visualization Server
The Unicenter NSM Visualization Server represents Unicenter NSM interface
technology. The MCC provides a single point of control for visualization and
monitoring of events and network topology throughout the entire enterprise.
Other less powerful interfaces are also available, as in previous releases of
Unicenter NSM, to specifically target WorldView and Agent Technology
visualization and monitoring. You can also deploy Unicenter MP and Systems
Performance technology for comprehensive reporting.
Management Command Center
Unicenter NSM Components
Comments
WorldView Administrative Client
Win32s
Agent Views
Enterprise Management
Administrative Client
Win32s
Notifications Services Client
Install if Enterprise Management
Administrative Client is to manage
remote Unicenter Notification
Services installations
Advanced Event Correlation Policy
Editor
Install if Enterprise Management
Administrative Client is to manage
remote AEC installations
Unicenter Browser Interface
Browser; install as desired
Management Command Center
Java; install as desired
Unicenter Management Portal
Chapter 5: Installation Preparation 77
Pre-Installation Tasks
Systems Performance Desktop Applications
For Windows platforms, the Unicenter Systems Performance components are
installed through the separate Unicenter Systems Performance installation.
For Linux and UNIX platforms, the Unicenter Systems Performance installation
is integrated with the Unicenter NSM installer and is a component selection in
the Installation Wizard.
Unicenter NSM Components
Comments
Performance Scope
Win32s
Performance Trend
Win32s
Performance Reporting
Browser
Performance Configuration
Win32s
Chargeback
If desired; Win32s
Pre-Installation Tasks
This section includes any pre-installation tasks specific to supported platforms
and components. You must perform the pre-installation tasks to ensure a
successful implementation. The following supported platforms and components
require pre-installation tasks.
Windows
eTrust Access Control, or any other software that performs similar protections,
must be shut down prior to a clean installation or an upgrade of Unicenter
NSM. eTrust Access Control protects against unauthorized adds, deletes, or
updates to users and usergroups. Unicenter NSM creates users during the
installation, such as the nsmadmin and cautil users. Any of these operations
can either fail or result in a disabled user. When the installation or upgrade is
complete, restart the security software.
See the eTrust Access Control documentation for the commands and
instructions to stop and start the software.
The user or system TEMP environment variable must exist and point to a valid
directory with a path name that contains 125 or fewer characters. The TEMP
path must be writable and have at least 500 MB of free space.
78 Implementation Guide
Pre-Installation Tasks
Linux and UNIX
You must update certain parameters in the kernel configuration for Unicenter
NSM to acquire the required IPC (Inter-process Communication) resources on
Linux and UNIX platforms. These values, if not already at required levels, are
automatically updated and built into the kernel during installation.
Parameter Name
Minimum Setting
maxfile
8192
msgmax
32768
msgmnb
65535
msgmni
128
semmni
256
semmns
512
semmsl
100
shmmax
536870912
shmmni
512
threads-max
65262
Hostname Limitations
If you intend to install CCS or CCS consumers on HP-UX, the hostname should
not consist of more than 8 characters. This is a prerequisite for this
installation, because HP-UX is unable to recognize hostnames with more than
8 characters.
The name of the host on which the Event Agent is running should not consist
of more than 15 characters including its domain name, for example,
mynsm.mydom.com. Otherwise the CA-opr service does not start.
DIA Configuration
Before installing Unicenter NSM r11.2, there are several tasks you need to
perform to ensure that the Distributed Intelligence Architecture (DIA) is
configured to monitor your infrastructure. You must complete these
configuration tasks before you begin the installation.
For a detailed description of the tasks required to configure DIA, see the
section DIA Configuration in the appendix "DIA Reference."
Chapter 5: Installation Preparation 79
Pre-Installation Tasks
Distributed State Machine (DSM)
We recommend that you plan to install each DSM physically close to the
resources it will manage. DSMs have a capacity based on polling cycles; if the
DSM has to poll across multiple routers, the round-trip time to complete each
poll increases. If the round-trip time is excessive, consider decreasing the DSM
capacity. The number of objects that a DSM can monitor varies with your
hardware specifications.
The primary rule used in sizing a DSM for a Windows-based server is based on
an Intel architecture using Pentium III (700 MHz) with 512 MB of RAM and 4
GB or more of disk space. We suggest an upper limit of 20,000 managed
objects for each Windows-based DSM. Linux or UNIX DSMs may scale to a
smaller number of objects.
Further tuning, by adjusting polling intervals at the object and class levels, can
allow DSMs to run up to 50,000 objects for polling over a local area. DSMs
handling this many objects should have more than 1GHz CPU with 1GB RAM or
more. If you are polling objects at remote locations over slow connections, we
suggest a maximum of 10,000 managed objects; the effective maximum may
be less. If you are monitoring more than 100,000 objects with a single DSM,
that DSM should be installed on a dedicated server.
Note: The number of objects a DSM can monitor depends on the poll interval,
the amount of memory on the machine, the number of processes running, the
hard drive speed, the connection speeds, the efficiency of the pollsets, and the
type of policy running (ATP or DAT/CNF).
Use the following guidelines for DSM planning:
■
Always monitor the DSM as a critical device (use dsmMonitor to monitor
remote DSMs from a central DSM).
■
Provide sufficient resources for DSMs (50 MB main memory minimum plus
more for additional objects).
■
Consider multiple DSMs when monitoring more than 200 hosts.
■
Ensure that polling frequency is reasonable.
■
Ensure that all DSMs report to a specific MDB.
■
Locate DSMs as close as possible to their monitored devices to avoid
unnecessary network load.
80 Implementation Guide
Pre-Installation Tasks
Installation Considerations
Consider the following items when you are preparing to install your DSM:
ID and Password
During the installation procedure, you may be required to provide a user
ID and password for the agent. For example, if the agent requires a
database administrator ID, use that administrator ID and password. This
practice prevents other users from disabling the agent or changing the ID
and password. The ID remains available for use by the related agent so
that the information can be accessed from the database server. The
information you provide is stored in a secure manner specific to the
subject agent.
DSM Installation Consideration
The file Install_Path/SC/CCS/AT/services/bin/awservices is a script that
starts and stops Agent Technology services. In that script, the Agent
Technology SNMP Gateway is started using the following command:
aws_snmp -t <port_number>
If you encounter a port conflict (where the SNMP Gateway and some other
code both require access to the default port of 162), start aws_snmp on
another port using the -t operand as previously shown.
Verify Trap Socket Number Definitions
Traps may be sent to as many machines (ports) as appropriate for your
installation. When agents send traps intended to be received by the SNMP
Gateway, the target port number designated should be the same number
to which the aws_snmp daemon has been instructed to bind.
Previous Method: Editing the following configuration file configures the
destination of traps:
Install_Path/SC/CCS/AT/services/config/aws_sadmin/aws_sadmin.cfg
New Method: If there are any DSM entries in the file aws_sadmin.cfg,
those entries are used to configure traps to be sent to those DSMs.
Otherwise, an entry in the atmanager.ini file (AutoConfig Trap
Destination=yes) automatically configures a DSM to notify the system
administrator of each host machine that it is listening to. This setting
resides on the DSM side, so nothing on a monitored host would need to be
modified.
Chapter 5: Installation Preparation 81
Pre-Installation Tasks
Monitoring for z/OS
Use the sections that follow to help you perform all necessary pre-installation
tasks for the Monitoring for z/OS feature of Unicenter NSM.
CAIRIM for License Authorization
Each z/OS agent uses CAIRIM, the Resource Initialization Manager, for product
license authorization. Many CA z/OS products share CAIRIM features and
functions, which prepares your z/OS operating system environment for your
CA products and components and executes them.
CAIRIM routines are grouped under CA MVS Dynamic Service Code S910.
Review the CA Common Services for z/OS and OS/390 Administrator Guide for
more information about the features and associated utilities of CAIRIM.
The CA License Management Program
To initialize correctly, the agents require the CA License Management Program
(LMP). CA LMP also provides a standardized and automated approach to the
tracking of licensed software.
CA LMP is provided as an integral part of CAIRIM. Once CAIRIM has been
installed, assistance is available to you for all CA LMP-supported products.
To authorize the agents through the LMP facility, you must install CAIRIM,
activate LMP, and then code LMP statements.
For details, see the CA Common Services for z/OS and OS/390 Administrator
Guide.
LMP Key Certificate Information
Examine the CA LMP Key Certificates you received with the installation and
maintenance tape for the Monitoring for z/OS feature.
Your certificate contains the following information:
Product Name
Specifies the trademarked or registered name of the product as licensed
for the designated site and CPUs.
Product Code
Specifies a two-character code that corresponds to the agent.
82 Implementation Guide
Pre-Installation Tasks
Supplement
Specifies the reference number of your license for the product in the
format nnnnnn - nnn.
This format differs slightly inside and outside North America, and in some
cases may not be provided.
CPU ID
Specifies the code that identifies the specific CPU for which installation of
the product is valid.
Execution Key
Specifies an encrypted code required by CA LMP for the installation of the
product.
During installation, it is referred to as the LMP Code.
Expiration Date
Specifies the date your license for the product expires. It is in the format
ddmmmyy, as in 15JAN04.
Technical Contact
Specifies the name of the designated technical contact at your site
responsible for installation and maintenance of the product.
This is the person to whom CA addresses all CA LMP correspondence.
MIS Director
Specifies the name of the Director of MIS or the person who performs such
a function at your site.
If the title but not the individual’s name is indicated on the certificate, you
should supply the actual name when correcting and verifying the
certificate.
CPU Location
Specifies the address of the building where the CPU is installed.
Chapter 5: Installation Preparation 83
Pre-Installation Tasks
LMP Code Specification
You must add the CA LMP Execution Key provided on the Key Certificate to the
CAIRIM parameters to ensure proper initialization of the agents. To define a
CA LMP Execution Key to the CAIRIM parameters, modify the KEYS member in
CAI.PPOPTION.
The parameter structure for the KEYS member is as follows:
PROD(pp) DATE(ddmmmyy) CPU(tttt-mmmm/ssssss) LMPCODE(kkkkkkkkkkkkkkkk)
pp
(Required) Specifies the two-character product code.
This code agrees with the product code already in use by the CAIRIM
initialization parameters for any earlier versions of the product (if
applicable). Values for pp are as follows:
IU
Represents the z/OS System agent.
IY
Represents the CICS agent.
ddmmmyy
Specifies the CA LMP licensing agreement Expiration Date.
tttt-mmmm
(Required) Specifies the CPU type and model on which CA LMP is to run
(for example, 3090-600).
If the CPU type and or model require less than four characters, blank
spaces are inserted for the unused characters.
ssssss
(Required) Specifies the serial number of the CPU on which CA LMP is to
run.
kkkkkkkkkkkkkkkk
Specifies the execution key needed to run CA LMP.
This CA LMP execution key is provided on the key certificate shipped with
each CA LMP software solution.
For a full description of the procedure for defining the CA LMP Execution Key to
the CAIRIM parameters, see the CA Common Services for z/OS and OS/390
Administrator Guide.
84 Implementation Guide
Pre-Installation Tasks
Unicenter CA-SYSVIEW Server Installation
If you are installing the Monitoring for z/OS feature for the first time, install
the Unicenter CA-SYSVIEW Server before installing Unicenter NSM. See the
Unicenter CA-SYSVIEW Realtime Performance Management Server Getting
Started guide for instructions on installing the Unicenter CA-SYSVIEW Server.
If you are installing the Monitoring for z/OS feature in an environment that
contains an existing Unicenter CA-SYSVIEW installation (operating at a
minimum release level of 7.7 SP1), or you are installing on top of an existing
copy of the System, CICS, or MQ Series agents (operating at a minimum
release level of 3.3), you do not need to install the Unicenter CA-SYSVIEW
Server.
Use the procedures that follow to prepare an existing Unicenter CA-SYSVIEW
or z/OS agent installation for proper operation.
Note: If you are running a version of Unicenter CA-SYSVIEW older than 7.7
SP1, you must upgrade before installing the Monitoring for z/OS feature.
Reassemble and Link the Unicenter CA-SYSVIEW GEN Module
For the Monitoring for z/OS agents to operate with an existing Unicenter CASYSVIEW or z/OS agent installation, you must reassemble and relink the
Unicenter CA-SYSVIEW GEN module.
To reassemble and link the Unicenter CA-SYSVIEW GEN module
1.
Update the INST0005 member, which is in the sysview.INSTLIB data, so
that the GEN parameter FEATURE= includes the SERVER option. If you use
the Unicenter CA-SYSVIEW installation with the Monitoring for z/OS
feature across multiple systems, you must update the GEN module for
each system.
2.
Submit the INST0005 job.
3.
Ensure that all job steps complete with a condition code of 0.
Chapter 5: Installation Preparation 85
Pre-Installation Tasks
Disable the Previous Release
The following applies only if you are currently running a previous release of the
z/OS system or CICS agents.
To disable the previous release
1.
Set the UNICENTER-CICS-AGENT parameter of the sysview.PARMLIB
(CICSOPTS) member to NONE to disable the previous release of the CICS
agent.
2.
Set the UNICENTER-MVS-AGENT parameter of the
sysview.PARMLIB(MVSAGENT) member to NONE to disable the previous
release of the z/OS System agent.
Important! The changes do not take effect until the Unicenter CA-SYSVIEW
CICS XPFS transaction and the MVSDATA tasks have been recycled.
Enable the MVSDATA Task
For the Monitoring for z/OS feature to collect data from Unicenter CA-SYSVIEW
or CA-SYSVIEW Server, the MVSDATA task must be enabled and running. If
you have a previous release of the z/OS and CICS agents, this task will
already be enabled.
■
For CA-SYSVIEW, add the following line to the sysview.PARMLIB
(SYSVIEW) member to enable the MVSDATA task:
START MVSDATA
■
For CA-SYSVIEW Server, add the following line to the sysvserv.PARMLIB
(SYSVSERV) member to enable the MVSDATA task:
START MVSDATA
Enable the CICS Logger Task
To collect data from Unicenter CA-SYSVIEW or CA-SYSVIEW Server using the
Monitoring for z/OS CICS agent, the CICSLOGR task must be enabled and
running. If you have a previous release of the CICS agent or the Unicenter CASYSVIEW CICS option is turned on, this task will already be enabled.
■
For CA-SYSVIEW, add the following line to the sysview.PARMLIB
(SYSVIEW) member to enable the CICSLOGR task:
START CICSLOGR.CICSLOGR
■
For CA-SYSVIEW Server, add the following line to the sysvserv.PARMLIB
(SYSVSERV) member to enable the CICSLOGR task:
START CICSLOGR.CICSLOGR
86 Implementation Guide
Pre-Installation Tasks
Unicenter Systems Performance
Both of the following components run on Windows, Linux, and UNIX:
Performance Domain Server
Defines and manages a Systems Performance Domain. This service
provides Systems Performance applications with accessibility to the
performance data gathered by the Performance Agents registered in the
domain and also manages all of the configuration information pertinent to
the operation of those Performance Agents. Each Systems Performance
Domain contains only one Systems Performance Domain Server.
Performance Distribution Server
Allows the Systems Performance Domain Server to scale effectively.
Multiple instances of this service can be installed across the servers in your
network (one instance per server) to provide rapid access to performance
data and high levels of scalability for Performance Agent configuration
operations. Each one of these services forms a node in the Performance
Data Grid. These nodes communicate with each other to share the
performance data stored in their local Performance Cube Store and
collaborate to fulfill requests for performance data made by Systems
Performance applications.
Before installing Unicenter Systems Performance, you must check the
following:
■
■
For connections to a Performance Domain Server, ensure that:
–
The Performance Domain Server is running.
–
The computer running the Performance Domain Server is in the
repository.
The remote admin client must be at or above the level of the server to
which it attaches.
Unicenter for Pocket PC
Before installing Pocket PC, complete the following pre-installation tasks:
■
Ensure that the Pocket PC device is configured to communicate over the
wireless LAN. The most widely used connectivity option is a wireless LAN
card using 802.11b. See your Pocket PC vendor for compatible wireless
solutions.
■
Identify an existing Unicenter NSM Windows server that hosts Unicenter
NSM Enterprise Management. Any Windows server running any
combination of Unicenter NSM Enterprise Management can manage
Pocket PC devices.
Chapter 5: Installation Preparation 87
Pre-Installation Tasks
■
Name your device. Each Pocket PC managed by Unicenter NSM must have
a unique device ID.
To name your device, follow these steps:
1.
Select the System menu.
2.
Select Settings, System, About.
3.
Select the Device ID tab.
Unicenter Management for MOM
Unicenter Management for MOM (MOM Management) requires the following
pre-installation tasks:
■
Install a patch that enables MOM Management to recognize MOM agent
computers.
■
Set up an account for installation and discovery.
■
Set up the Unicenter Management for MOM runtime account.
Note: Both the WorldView and Event Managers must be installed before
installing Unicenter Management for MOM.
Install Patch for Recognizing MOM Agent Computers
If you are running Microsoft Management for MOM 2005, you need to install a
patch that enables MOM Management to recognize MOM agent computers. The
patch updates the MSFT_Computer class of Microsoft SQL Server.
For step-by-step instructions, see the Knowledge Base article 888197 on
support.microsoft.com.
Set Up an Account for Installation and Discovery
The user account for installing Unicenter Management for MOM and for running
Unicenter Management for MOM Discovery must have the following privileges:
■
Membership in the Administrators group on the Unicenter Manager node
■
User right to “Act as part of the operating system”
Note: The domain administrator or domain user account for collecting MOM
information, installing Unicenter Management for MOM, and discovery must be
same account used for installing Unicenter NSM.
88 Implementation Guide
Pre-Installation Tasks
To apply the privilege “Act as part of the operating system"
1.
On the Unicenter NSM Manager node, choose Start, Settings, Control
Panel, Administrative Tools, Local Security Policy.
The Local Security Settings window opens.
Note: You can also give domain administrators this privilege on the
primary domain controller. Choose Start, Settings, Control Panel,
Administrative Tools, Domain Security Policy.
2.
Expand Local Policies, and click User Rights Assignment.
The user rights appear in the right pane.
3.
Double-click Act as part of the operating system. Add the user name to the
list, and click OK.
The user account now has the “Act as part of the operating system”
privilege.
Set Up the MOM Management Runtime Account
Unicenter Management for MOM requires a user account for collecting MOM
information. Use a domain administrator or domain user account that can
access MOM information throughout the domain. The installation prompts you
for this user name and password. The account needs the privilege “Log on as a
service” on the Unicenter Manager. If you use a domain user account, it also
needs to be a member of the Administrators group on the MOM server.
Note: The account for collecting MOM information can be the same account
used for installing MOM Management and running MOM Discovery.
To apply the privilege “Log on as a service” to a domain administrator
or domain user account
1.
On the Unicenter NSM Manager node, choose Start, Settings, Control
Panel, Administrative Tools, Local Security Policy.
The Local Security Settings window opens.
Note: You can also give domain administrators and users this privilege on
the primary domain controller. Choose Start, Settings, Control Panel,
Administrative Tools, Domain Security Policy.
2.
Expand Local Policies, and click User Rights Assignment.
The user rights appear in the right pane.
3.
Double-click Log on as a service. Add the user name to the list, and click
OK.
The account now has the “Log on as a service” privilege.
Chapter 5: Installation Preparation 89
Pre-Installation Tasks
To apply administrative privilege to a domain user account
1.
On the MOM server, open Control Panel, Administrative Tools, Computer
Management.
The Computer Management window opens.
2.
Expand Local Users and Groups, and click Groups.
The groups appear in the right pane.
3.
Double-click Administrators, add the domain user name to the list, and
click OK.
The domain user account becomes an administrator.
CA System Center Operations Manager Integration
CA System Center Operations Manager Integration (SCOM Integration)
requires the following pre-installation tasks:
■
Set up an account for installation and discovery.
■
Set up the SCOM Integration runtime account.
■
Install the Microsoft System Center Operations Manager Console Client
Note: Both the WorldView and Event Managers must be installed before
installing SCOM Integration.
Set Up an Account for SCOM Installation and Discovery
The user account for installing the SCOM Integration and for running SCOM
Discovery must have the following privileges:
■
Membership in the Administrators group on the Unicenter NSM Manager
node
■
Permission to "Act as part of the operating system"
Note: The domain administrator or domain user account for collecting SCOM
information, installing SCOM Integration, and discovery must be same account
used for installing Unicenter NSM.
To apply the privilege "Act as part of the operating system"
1.
Choose Start, Settings, Control Panel, Administrative Tools, Local Security
Policy on the Manager node.
The Local Security Settings window opens.
Note: You can also give domain administrators this privilege on the
primary domain controller. Choose Start, Settings, Control Panel,
Administrative Tools, Domain Security Policy.
90 Implementation Guide
Pre-Installation Tasks
2.
Expand Local Policies, and click User Rights Assignment.
The user rights appear in the right pane.
3.
Double-click Act as part of the operating system. Add the user name to the
list, and click OK.
The user account now has the "Act as part of the operating system"
privilege.
Set Up the SCOM Integration Runtime Account
SCOM Integration requires a user account for collecting SCOM information.
Use a domain administrator or domain user account that can access SCOM
information throughout the domain. The installation prompts you for this user
name and password. The account needs the privilege "Log on as a service" on
the Unicenter Manager. If you use a domain user account, it also needs to be a
member of the Administrators group on the SCOM server.
Note: The account for collecting SCOM information can be the same account
used for installing SCOM Integration and running SCOM Discovery.
To apply the privilege "Log on as a service" to a domain administrator
or domain user account
1.
On the Unicenter NSM Manager node, choose Start, Settings, Control
Panel, Administrative Tools, Local Security Policy.
The Local Security Settings window opens.
Note: You can also give domain administrators and users this privilege on
the primary domain controller. Choose Start, Settings, Control Panel,
Administrative Tools, Domain Security Policy.
2.
Expand Local Policies, and click User Rights Assignment.
The user rights appear in the right pane.
3.
Double-click Log on as a service. Add the user name to the list, and click
OK.
The account now has the "Log on as a service" privilege.
Chapter 5: Installation Preparation 91
Pre-Installation Tasks
To apply administrative privilege to a domain user account
1.
On the SCOM server, open Control Panel, Administrative Tools, Computer
Management.
The Computer Management window opens.
2.
Expand Local Users and Groups, and click Groups.
The groups appear in the right pane.
3.
Double-click Administrators, add the domain user name to the list, and
click OK.
The domain user account becomes an administrator.
Unicenter Remote Monitoring
The processor on the Unicenter Remote Monitoring agent computer needs to
be powerful because it analyzes the data for each monitored resource to
determine whether an error has occurred. The advantage to this method is
minimal CPU and memory impact on your production environment.
Before installing the component, review the following tasks to ensure that your
system is ready.
In the Agent checklist, verify the following:
■
The WorldView Manager or Client is installed. If Client, the WorldView
Manager must be installed on another machine in the environment.
■
The Remote Administrative Client is installed.
In the Administrative Interface checklist verify that a DIA client (DNA) is
present.
Security Considerations
You must install the Unicenter Remote Monitoring agent using an administrator
account and password. When configuring a Windows resource for monitoring,
you can use the service administrator account or you can provide the agent
with specific credentials to use instead.
Linux, UNIX, and Mac OS X resources are monitored using remote shell (rsh)
or secure shell (ssh). The Unicenter Remote Monitoring agent includes a
secure shell client for accessing your remote Linux, UNIX, and Mac OS X
computers, but you must provide the secure shell daemon on each of the
target computers. The Unicenter Remote Monitoring agent connects to remote
Linux, UNIX, and Mac OS X systems using a non-privileged user account that
must have write access to its home directory.
92 Implementation Guide
Pre-Installation Tasks
Highly Available Installations
Pay particular attention when configuring Microsoft SQL Server and this
product in a cluster environment. The installation of Microsoft SQL Server
creates a network name inside the resource group that you selected for
installation. If there is already a network name in that resource group, the
result is two or more network names.
Resource groups with more than one network name or more than one IP
address are not supported by this product. Ensure that the target resource
group has only one network name and one IP address.
Other Software Considerations
We strongly recommend that you update all other installed software products
to their latest maintenance levels. It is particularly important to update all
virus scanning products so they can properly detect the newest viruses and
prevent known false alarms. Furthermore, be aware that some virus scanners
may cause problems during product installation, runtime operation, and/or
uninstallation. For example, an installation wizard, when finished installing,
may be unable to clean up its files in the %TEMP% directory tree if a virus
scanner has one or more of those files locked. Other more severe problems
may occur if this happens during product installation or operation.
Chapter 5: Installation Preparation 93
Chapter 6: Installation
Note: If you have not reviewed the information in the previous chapters, do
so before proceeding.
This section contains the following topics:
Installation Overview (see page 95)
Install Unicenter NSM on Windows (see page 111)
Install Unicenter NSM on Linux or UNIX (see page 119)
Install CA Common Discovery (see page 133)
Register Unicenter NSM with Unicenter Software Delivery (see page 141)
Install Unicenter Systems Performance (see page 145)
Install Unicenter NSM Systems Performance on Windows (see page 146)
Install Active Directory Management (see page 147)
Install Monitoring for z/OS Interface (see page 156)
Install Unicenter Management Portal (see page 163)
Install Unicenter for Pocket PC (see page 164)
Installation of Unicenter Management for MOM (see page 165)
Installation of the CA System Center Operations Manager Integration (see
page 167)
Install Unicenter Cisco Integration (see page 169)
Install TrapManager (see page 170)
Install Unicenter Remote Monitoring (see page 172)
Install the SPECTRUM Integration Kit (see page 174)
Uninstall Individual Components (see page 187)
Installation Overview
Before starting a Unicenter NSM installation, we strongly recommend that you
shut down all application software, most specifically other CA software, to
prevent files from being in use, thus requiring the new software installation to
schedule a restart of the system to replace those files that are in use. It is
critically important that you use all proper mechanisms provided by other
software or the operating system to shut down these applications and
services. Killing processes and applications in Task Manager may cause
breakage to those other applications and possibly leave them in an unstable
state. Additionally, some applications may detect that services they use are
unexpectedly gone and try to restart them again, perhaps causing still further
problems.
When you install a Unicenter NSM component on a computer, the Welcome
and End User License Agreement (EULA) screens appear. You must respond to
the EULA before continuing with an installation. Use the Unicenter component
selection menus to select one or more components for installation.
Chapter 6: Installation 95
Installation Overview
Installing Unicenter NSM on any individual machine is normally done either
from CA-supplied media, such as a DVD, or from a Unicenter Software
Delivery process. You can also copy the CA-supplied media to your hard drive
and install from there, whether locally or from a remote network share. In this
case, be careful that you do not alter the image in any way. Changes such as
resetting or altering file attributes such as the read only, hidden, or other
attributes using attrib, attrib /S, or Windows Explorer and changing the case of
file names and directories are all unsupported actions and can cause
installation or runtime failures in the product.
You must also carefully control write access to any hard drive copy of the
installation files to avoid inadvertent changes by individuals and to protect the
files from viruses or other malware infections that could then further
propagate during future installations from the affected image. Placing the
image on a read only share is supported so long as the attributes of the files
and directories remain as originally copied from the CA-supplied media.
Operating System Dependencies
This product cannot be installed properly if either of the following conditions
are true:
■
Windows Installer is not correctly installed or not fully operational, or the
service is disabled.
■
The Windows Service Control Manager database is locked.
Maximum Operating System PATH Lengths
The different versions of Microsoft Windows Operating Systems have different
maximum system PATH lengths.
■
■
96 Implementation Guide
The following Windows versions support a maximum of only 1024
characters:
■
Windows 2000 unless hotfix Q180410 is applied
■
Windows XP unless Service Pack 2 or higher is applied
■
Windows 2003 unless Service Pack 1 or higher is applied
Newer versions and service packs of Windows provide support for a
maximum of 2048 characters
Installation Overview
This product uses a portion of the available system PATH space depending on
which components and how many components you select to install. If the
components and destination install paths that you select exceed the available
system PATH space, the installation warns you of this and will not proceed. In
this case, you must do one of the following:
■
Upgrade the operating system to achieve 2048 character support
■
Select shorter destination install paths
■
Select fewer components for installation
Special Character Support
Note: In this section, "ASCII alphanumeric" refers to the following characters:
A-Z, a-z, and 0-9.
Unicenter NSM does not support localized characters in the computer name,
Microsoft SQL Server instance name, installation source media/response file or
destination paths, user names, or password fields. It does support the
following set of characters with any frequency, pattern, or ordering of those
characters for those fields as specified here:
■
Computer name: ASCII alphanumeric and hyphen (-).
Underscores and other special characters are commonly used by Microsoft
Windows operating environments but are not allowed in RFC-952 even
with the looser restrictions of RFC-1123. Their use can cause problems in
systems that communicate over the network, or even locally when an
application uses network related functions. This is true even if your
network is using the Microsoft DNS Server or no DNS server at all.
Some versions of Microsoft Windows block the use of non-standard
characters into the computer name in their administrative GUIs, or they
present warnings about the ramifications of their use. Still, the Win32
SetComputerName API lets you get around some of those blocks.
Although adding IP address/computer name aliases into the \etc\hosts file
of each computer may correct some problems you may encounter while
using non-standard characters or names not allowed by the DNS standard,
the deployment of Unicenter NSM in such an environment is not
supported.
For more information, review Microsoft Article 909264 and the
documentation for the SetComputerName Win32 API.
■
Microsoft SQL Server Instance Name: ASCII alphanumeric
■
Installation source media/response file path: ASCII alphanumeric, hyphen
(-), underscore (_), period (.), open bracket ([), close bracket (]), space (
), and dollar sign ($).
Chapter 6: Installation 97
Installation Overview
■
Installation destination path: ASCII alphanumeric, hyphen (-), underscore
(_), period (.), tilde (~), and space ( ).
■
System %TMP% and %TEMP% path: ASCII alphanumeric, hyphen (-),
underscore (_), period (.), open bracket ([), close bracket (]), tilde (~),
space ( ), and dollar sign ($). Unsupported characters can exist in these
variables if your logged on user name contains such characters or because
you have otherwise manually defined them this way. In this case, change
these system environment variables to contain characters meeting these
restrictions.
Note: The installation source media/response file path, installation
destination path, and system %TMP% and %TEMP% paths cannot start
with a space ( ), end with a space, or contain the string "$$". The colon (:)
character is supported only when it immediately follows the name of an
existing disk drive as part of a path specification such as "C:\". The
backslash (\) character is supported only as a path separator of directory
levels.
In addition, the installation source media path cannot have a directory that
ends with a space or contain any of the following characters:
/*?<>|"%,=&@^!~()#;>
■
User name: ASCII alphanumeric, hyphen (-), underscore (_), pound or
hash sign (#), and dollar sign ($).
■
Passwords: No character restrictions except that passwords cannot contain
localized characters.
Note: Also review the section called Using Semicolons in Microsoft SQL Server
Login Passwords under Known Issues in the Readme file.
Other Installed Software
We strongly recommend that all other installed software products be updated
to their latest maintenance levels. Some Microsoft and other third-party issues
are documented in the Known Issues section of the Readme file.
■
It is of particular importance to update all virus scanning products so that
they can properly detect the newest viruses and prevent known false
alarms.
■
For optimal integration with CA eTrust Antivirus, use the version shipped
with this media to upgrade any existing installation if you select Event
Management or the Event Agent for installation. If this upgrade is not
performed, when Event Management launches the default Midnight
message record action for virus scanning, thousands of "File filename has
been skipped from Antivirus scanning" messages may appear in your
console log, which is different behavior than previous releases of this
product.
98 Implementation Guide
Installation Overview
■
For correct integration with Unicenter Service Desk 6.0, the following
Service Desk patches must be applied: QO43395 and QO57381.
■
If you want to install Unicenter NSM r3 or r3.1 for NetWare from a system
with this product's r11 or r11.1 versions installed, you must preapply
QO79868 or a similarly appropriate fix to your Unicenter for NetWare
product install media.
■
This release contains DIA performance enhancements and better
integration with Agent Technology. In a mixed environment where r11 and
r11.1 installations both exist, the r11 systems must be patched with the
corresponding performance enhancements. Not patching those systems
could cause performance degradation on the r11.1 systems. As of the
publishing of this document, the patches are QO81842 and QO81837
(Windows), QO81843 and QO81838 (Linux), QO81844 and QO81840
(Solaris), QO81846 and QO81841 (HP-UX), and lastly QO81845 and
QO81839 (AIX). For the latest versions, go to SupportConnect at
http://supportconnect.ca.com.
Microsoft SQL Server Considerations
Unicenter NSM requires that Microsoft SQL Server installations have the
TCP/IP network protocol enabled and operational. See the Microsoft SQL
Server documentation for information on how to choose and configure network
protocols.
When establishing connections between a local Microsoft SQL Server (DBMS or
Client) and a remote Microsoft SQL Server DBMS, the default network library
settings of the local and remote installations must be compatible. For example,
you can use "TCP/IP" on both sides. If the Microsoft SQL Client configurations
are not compatible, you may receive connection errors during the installation
process.
There are many reasons why you may not be able to connect to a remote
Microsoft SQL Server. One solution you can try using to establish connections
to remote named instances follows. When connectivity problems exist,
command line Microsoft SQL Server tools may also fail to connect and perhaps
generate the following error message:
SQL Server does not exist or access denied.
ConnectionOpen (Connect ()).
Chapter 6: Installation 99
Installation Overview
One solution you can try using to establish connections to remote named
instances when receiving this error message is as follows.
To connect to a remote Microsoft SQL Server
1.
On the Start menu, select Programs, Microsoft SQL Server, then click
Client Network Utility.
The Client Network Utility dialog appears.
2.
If TCP/IP is not already present under Enabled protocols, follow Steps 3,
4, and 5. If TCP/IP is present, go to the Alias tab, Step 6.
3.
Configure a client to use TCP/IP.
4.
Click the General tab, then click Add.
The Add Network Library Configuration dialog box appears.
5.
Click TCP/IP.
6.
Click the Alias tab, then click Add.
The Add Network Library Configuration dialog box appears.
7.
Under Network libraries, select TCP/IP network library.
8.
In the Server alias box, enter the alias of the instance of Microsoft SQL
Server listening on the Windows Sockets Net-Library to which you want to
connect.
9.
Specify exactly the full instance name of the Microsoft SQL Server to which
you want to connect (for example, Servername\Instancename) and which
listens for TCP/IP Sockets clients.
With TCP/IP, you also can specify the server with its IP address instead of
its name.
10. Clear the Dynamically determine port check box to set the port manually.
11. Type the port number of the Microsoft SQL Server instance from the
remote machine in the Port number box.
To get the port number from the remote server
1.
On the Start menu, select Programs, Microsoft SQL Server, then click
Server Network Utility.
The Server Network Utility dialog appears.
2.
Under Enabled protocols, select TCP/IP, then click Properties.
3.
Note the value of the default port. Use this number to configure the clients
also.
100 Implementation Guide
Installation Overview
In general, if you experience difficulty with Unicenter NSM connecting to a
Microsoft SQL Server instance, always try the native Microsoft SQL Server
tools themselves to ensure that they can connect. If the Microsoft SQL Server
client software is unable to connect to the remote instance, it is very likely
that CA software will not be able to connect either. See Microsoft article
328306 and other articles for some of the common causes of connectivity
problems.
When receiving this error message from the Microsoft SQL Server command
line tools, the Unicenter NSM Installation Wizard may also report "connect
failed" on the Database Selection dialog, though it may report this for other
failures also.
CA MDB and Raw Partitions
You cannot install the MDB into a Mircosoft SQL Server instance where the
default data files are created on a raw partition.
Microsoft SQL Server Browser Service
When using the Installation Wizard, you may not be able to select
configuration of an MDB that already exists in a Microsoft SQL Server installed
image on your system. The following message indicates the reason:
"There is no MDB that is both installed and active that can be configured"
If you receive this message, confirm that the Microsoft SQL Server Browser
Service is running on that system. The service enables this product to find the
existing MDB.
In addition, various interfaces of this product may offer a Browse button so
that all existing Microsoft SQL Server installed images are found and listed.
The accuracy and completeness of the data in resulting dialogs may be
affected by a number of conditions, including at least the following:
■
The Master Browser is updated only periodically, and may not know about
all of the active Microsoft SQL Servers at the time the browse request is
issued.
■
This product may indicate that a given Microsoft SQL Server exists, but
when you try to list available instances for it, a message may appear
indicating no instances exist. If this occurs, confirm that the Microsoft SQL
Server Browser Service is running on that server.
Chapter 6: Installation 101
Installation Overview
IPv6 Support Over MDAC
Communication between the Systems Performance and WorldView database
layers and the MDB occurs through SQLOLEDB, which uses the Microsoft Data
Access Components (MDAC) for the underlying communication with Microsoft
SQL Server. As MDAC does not support IPv6 on Windows Server 2003 or
Windows XP, the database application layer cannot support IPv6 addresses to
connect to the database. We recommend that you use the host name or an
IPv4 address to connect to the database on these platforms. This applies to
the MDB hostname field in the Systems Performance installer.
Reserved Database User Names
When defining database user names for the MDB, there are a number of
reserved names that cannot be used for the nsmadmin ID. This is because
either the database you install, Microsoft SQL Server or Ingres, or the CA MDB
has reserved them. The list of reserved names is as follows:
MDB Users, Roles, or Groups
aiadmin
emadmin
uapmadmin_group
aionadmin_group
emuser
uapmbatch_group
aipublic
harvest_group
uapmreporting_group
amsgroup
harvest_rep
ucmadmin
apmadmin
icanbill_group
ucmuser
apmuser
icancommon_group
udmadmin_group
apnm_admin
infopump_admin
ujoadmin
apnm_user
infopump_user
umpadmin
apwmv_admin
jmoadmin
umpuser
apwmv_user
jmouser
uniadmin
asmoadmin
pdadmin
uniuser
asmouser
pduser
upmadmin_group
backup_admin_group
portaldba_group
upmuser_group
ca_itrm_group
regadmin
usmgroup
cmew_admin
sccadmingroup
workflow_admin_group
cmew_rdr
sccusergroup
workflow_ro_group
dms_backup_group
service_desk_admin_group
wsm_admin_group
102 Implementation Guide
Installation Overview
dsaadmin
service_desk_d_painter_
group
wsm_ro_group
dscadmin
service_ro_group
wvadmin
dscuser
siadmins
wvuser
MS SQL System Users
dbo
guest
MS SQL Server (Reserved System) Roles
bulkadmin
processadmin
setupadmin
dbcreator
securityadmin
sysadmin
diskadmin
serveradmin
MS SQL Database (Reserved) Users or Roles
db_accessadmin
db_ddladmin
db_securityadmin
db_backupoperator
db_denydatareader
public
db_datareader
db_denydatawriter
db_datawriter
db_owner
MS SQL 2000 MSDB-Specific Roles
RepositoryUser
TargetServerRole
PostgreSQL Users
postgres
nsmadmin
mdbadmin
Database Configuration Considerations
If you choose to install one or more components (such as Event Management
and WorldView) that require a database management system (DBMS) and an
MDB, the Installation Wizard interview asks you to specify on the Database
Selection and Configuration dialog which database the components should use.
You can choose to have the components use the same DBMS instance or you
can specify that they use different instances.
If you have installed other CA products on your system, you may already have
an MDB. Although it may be installed, the MDB does not appear in bold in the
Component Selection dialog of the Unicenter NSM Installation Wizard. The
MDB component appears bold in the dialog only if you installed it by using
Unicenter NSM or if you configured an existing instance that was installed by
some other product for use by Unicenter NSM.
Chapter 6: Installation 103
Installation Overview
The reasons to configure an existing instance prior to Unicenter NSM physically
using it are as follows:
■
Unicenter NSM must ensure that settings for memory, connection limits,
and other parameters necessary to support it are large enough.
■
Unicenter NSM installation must create a nsmadmin ID in the database
that has the proper access permissions to the MDB table space that the
product requires.
■
The supporting infrastructure that Unicenter NSM requires must be
installed on the MDB server.
In situations where an existing MDB is present, you can choose to configure
that MDB for use by Unicenter NSM or you can install a new one. We
recommend that you configure the existing MDB to preserve system resources
and enable better integration of data across products.
Once you have configured an instance of the MDB for use by Unicenter NSM,
or installed a new one, you do not need to configure any others on this
system. Therefore, the configuration option is disabled for future installations.
MDB installations are one-time selections. This means that once an instance is
either configured or newly installed for use with Unicenter NSM, this product's
installation is tied to that instance and can be changed only by uninstalling the
product. You can, however, adjust runtime settings on particular components,
such as Event Management and WorldView, to point them to different
instances on remote machines that Unicenter NSM has similarly configured.
If you have an existing instance of the MDB that is of a newer version than
what is shipped on the Unicenter NSM media, you are only able to configure
the MDB instance for use by Unicenter NSM. Never install the MDB from the
Unicenter NSM media on top of the existing newer version. If you require a reinstall or repair operation of the newer version, use the media that shipped it.
Of course, you could simply install a new instance of the version shipped with
Unicenter NSM rather than configure the newer, pre-existing instance.
The configuration option has the following restrictions:
■
The option does not install an MDB into an existing database instance. It
solely configures a locally existing MDB for the needs of this particular
product.
■
The option applies only to local installations. It cannot configure an
existing remote database with an existing MDB.
104 Implementation Guide
Installation Overview
To use an existing MDB of the same database type that this product supports,
whether local or remote, you must use the configure operation provided in the
Installation Wizard to configure that MDB for use by this product. As stated in
this topic, and shown in the Installation Wizard's Component Selection dialog,
the configure operation can be performed only on a local MDB. Therefore, if
you want to use an existing remote MDB, you must first run this product
physically on that remote machine to configure it. Once this is done, you can
have any number of other machines point to that existing remote MDB.
Security Considerations
Unicenter NSM security provides approximately 100 rules, nine roles or user
groups, and about 100 asset types out-of-the-box. Unicenter NSM provides
embedded security, which is a DENY mode security engine that, by default, is
turned on. The following components use Unicenter NSM embedded security, if
it is enabled:
■
Calendar Management
■
Embedded Security (can protect itself)
■
Job Management Option
■
Alert Management
■
Notification Services
■
Agent dashboards
■
Web Reporting Service
■
Unicenter Configuration Manager
■
Management interfaces, which include Management Command Center,
Event Management, Unicenter Management Portal, Unicenter Browser
Interface, and Unicenter for Pocket PC (logon only)
While selecting components in the Installation Wizard for Unicenter NSM,
consider clearing the Express check box if you want to customize the
installation for tighter security. By clearing this installation option, you are able
to explicitly specify more user names and passwords than if you choose this
option, where the installation chooses default values for you.
For Windows installations only, you can enable security for these components
by selecting the check box "Install security for components that support it"
during the installation. This check box appears only when you are installing in
non-Express mode.
Chapter 6: Installation 105
Installation Overview
CA Web Server
The CA Web Server is configured, by default, to use standard MemoryRealm,
but Unicenter NSM secures the directory containing the tomcat-users.xml file
by restricting it to Administrators only. You may want to upgrade this product
to a version of Unicenter NSM with Security Management so that you can use
the NSM Security Realm, or you may want to use digested passwords as
mentioned previously.
Note: For more information about the NSM Security Realm, see the topic CA
Web Server Security in the "Post-Installation and Configuration" chapter.
Warning Messages During Installation
During the installation of Unicenter NSM, the following warning message may
appear one or more times:
Process "<some process and parameters>" is taking longer than expected to
complete.
Do you want to wait longer? <YES|NO>
This message generally occurs because the components you selected for
installation on the system are consuming more resources than the computer
may have in total, or may have available at a given moment in time. You
should choose Yes to wait longer unless directed otherwise by Customer
Support, or unless a process seems to take an unreasonable amount of time,
which might indicate the computer is hung or looping. Although you may be
using a computer that meets the minimum requirements, your particular
deployment or network topology may increase the resources required by this
product.
If you receive this message, consider using a machine with greater processing
power for the components you have selected, or a machine with fewer other
processes and applications that are competing for available resources. If you
are installing management components on a computer with insufficient
resources, some processes may take five to ten or even more minutes to
complete because of operating system swapping and processor thrashing.
System Restarts During Installation (Windows Only)
There are a number of circumstances under which installing Unicenter NSM
can require a system restart.
One reason depends on the components you select to install. For example, if
you install Unicenter NSM on a computer that does not have an existing
installation and you choose to install the Unicenter Browser Interface
component and have it use an Apache Web Server, a restart will be required.
106 Implementation Guide
Installation Overview
Installations, reinstallations, and upgrades can require a restart for other
reasons. These usually include being unable to delete, rename, or alter files
that are in use by other processes, or being unable to update or alter
Unicenter NSM Windows services that do not stop within a reasonable time
when asked to do so. It is not possible to predict whether a specific
installation, reinstallation, or upgrade is going to require a restart because of
these conditions; it depends on the state of the computer at the time.
Processes outside of the Unicenter NSM installation (whether local or remote)
such as virus scanners and other applications not under Unicenter NSM control
can lock a file to which the installation needs control.
To minimize the possibility of being required to restart for an upgrade or
reinstallation, we recommend that you stop all processes relating to Unicenter
NSM, that use Unicenter NSM, or that share components in common with
Unicenter NSM. For example, numerous CA products use the CA Messaging
(CAM) component. If one of those products is actively using CAM during a
Unicenter NSM installation and Unicenter NSM needs to upgrade it, a restart
will be required.
Installation Using Unicenter Remote Control
You cannot install Unicenter NSM from a Unicenter Remote Control session if
the host on which you are installing is a Unicenter Remote Control "managed
host." This is because Unicenter Remote Controll managed hosts use the CA
Message Queuing Service (CAM), which is a component of the Unicenter NSM
installation, and CAM cannot be used and upgraded at the same time.
Migration of Component Data From a Prior Release
During the upgrade of a prior release of Unicenter NSM, the Installation Wizard
lets you migrate component data (such as message records and actions from
Event Management) from the original database server the component uses
now to a new database server of your choice, which the upgraded installation
will then use. For upgrades from Unicenter NSM 3.x to Unicenter NSM r11.2
for example, you can move data from an SQL Server database (CAIOPRDB) on
node A to a new database (MDB) on node B. In some cases, A and B might be
the same node. You cannot migrate data from the Ingres-based Unicenter
NSM r11 to the Microsoft SQL Server-based Unicenter NSM r11.2 during the
r11.2 installation.
Chapter 6: Installation 107
Installation Overview
If you do not choose to migrate your existing records for a component, the
new database is loaded with fresh default data, or it is left alone if records
already exist. If you choose to migrate existing data, any and all data
belonging to that specific component that already exists in the new database
will be deleted and replaced with the migrated data. Data belonging to other
components will be left alone. It is not possible to automatically merge
component data on an upgrade or migration. If you want to merge message
records and actions, or other component-specific data, you must do so
manually after the upgrade.
If you choose to build a response file, or run an interactive installation, and
you ask for data migration, the Installation Wizard prompts you with a warning
about this condition. You must either choose Yes to proceed or go back and
elect no data migration.
Network Port Conflicts
Unicenter NSM requires numerous network ports during installation and later
during normal runtime operation. Examine your system for any potential
conflicts between the port requirements of this software and any existing
software on your system, or of future software that you may install.
For example, Unicenter NSM may install Apache Tomcat under certain
circumstances, with default port selections of 9090 for primary functionality
and 9005 for shutdown functionality. While the Installation Wizard prompts
you to specify different ports if it finds these are in use during the installation
interview, the wizard cannot know if you have another instance of Apache
Tomcat, or any other application, that might not be running at installation
time. In such cases, runtime operation of the other product, or of Unicenter
NSM, may fail, depending on which product started later and was unable to
establish ownership of the port.
For more information about the ports that Unicenter NSM uses, see the
appendix "Utilizing and Configuring Ports" in the Administrator Guide.
Windows Terminal Services Support
Windows Terminal Services (WTS) is a server-based component that supports
the Terminal Services Client. Unicenter NSM support of WTS allows at least
one instance of any given application, excluding daemons or services, to run
under each unique WTS session.
108 Implementation Guide
Installation Overview
For example, you can run a Remote Administrative client application at least
once in each unique WTS session without regard to whether the effective user
ID is the same or different in the various WTS sessions. Therefore, each of five
WTS sessions, three using the same user ID and two using different user IDs,
may all run the same application at the same time.
Installing, uninstalling, and configuring Unicenter NSM do not support multiple
instances of WTS. The processes prevent concurrent instances across other
sessions by failing and providing an informative message that only one
instance of the installation can run across the entire system at any one time.
However, the processes do support being executed in a WTS session.
Unlike Unicenter NSM r11.1 GA, this release supports installations through
Windows Terminal Services even when configured in Application Server Mode.
However, the following settings are required:
■
CONSOLE mode must be used when performing installation from remote
access.
Example:
mstsc /v:HostName /console
■
Terminal server USER settings should be changed to INSTALL prior to the
installation.
Example:
change user /install
To verify the user settings, execute the following command:
change user /query
For more information about the Windows Terminal Server CHANGE USER
utility, see http://support.microsoft.com/kb/186504.
For additional information about the WTS/Citrix support Statement for
Unicenter NSM, see Technical document TEC411264 on SupportConnect.
Chapter 6: Installation 109
Installation Overview
High Availability Considerations
You must change all Unicenter resources to be offline on the current node
before installing, reinstalling, or upgrading Unicenter NSM or any CCS
consumer product on that same node.
If you perform a highly available installation and select any components that
use a Microsoft SQL Server database, be sure to choose the same cluster
resource group for this product installation as the Microsoft SQL Server
instance. For example, the WorldView Manager requires a local MDB. If you
select a different resource group at the beginning of our install than the one
that Microsoft SQL Server is actually using, Microsoft SQL Server will appear to
be remote, and the WorldView Manager cannot be installed on that server.
Similarly, this product supports installing an MDB to an existing local Microsoft
SQL Server. If you select a different resource group at the beginning of your
installation than the one your target Microsoft SQL Server is actually using, the
Microsoft SQL Server will appear to be remote, and the MDB itself cannot be
installed on that server.
Response File Must Not Be Read-Only
You cannot use a response file for an unattended installation when the
response file is located on a read-only file system or if the response file has
the read-only attribute set. The file must be writable because certain values
may be altered during installation based on the configuration of the target
system. For example, if the CA_APPSW directory already exists on the target
system, that current location is used instead of what is specified in the
response file.
110 Implementation Guide
Install Unicenter NSM on Windows
Install Unicenter NSM on Windows
Use the following procedure to ensure a successful installation of Unicenter
NSM on a Windows platform.
Note: You must be logged in as a member of the Administrators group of the
local system to initiate the Unicenter NSM installation.
To install Unicenter NSM on Windows platforms
1.
Verify that Microsoft SQL Server for the desired instance is running.
2.
Insert the Installation DVD into the DVD drive.
The Unicenter Product Explorer window appears. The option for Installation
Wizard for Unicenter NSM is preselected.
Note: When you click a selection, prerequisite information appears at the
bottom of the window. The Prerequisites section lists the following
information:
None
No prerequisites are required.
Satisfied
Additional prerequisites beyond the standard are required, but you
have met those requirements.
Should already be installed
Additional prerequisites are required and they have not been installed.
You must meet these additional requirements before you can install
the component.
3.
Click Install.
The Unicenter NSM Installation Wizard window appears with the following
setup options:
Install any or all Unicenter NSM components
When you choose to install any or all Unicenter NSM components, the
installation wizard prompts you for the components you want to install,
where the components should be installed, relevant user IDs and
passwords, and other information important for installing the product
in your enterprise.
Chapter 6: Installation 111
Install Unicenter NSM on Windows
Build Unicenter NSM response file for unattended install
When you choose to build a Unicenter NSM response file for
unattended installations, the installation wizard prompts you for the
same information as in the interactive installation as well as the name
and location for the response file. Saving setup information in a
response file is an effective way to perform identical installations on a
number of different physical computers. As the installation wizard
records your answers, no attempt is made to validate the data
because the machine and environment you are using to create the
response file may be different than the target machine where the
installation eventually occurs.
Note: You cannot reuse a response file created for an earlier version
of the product. Use the installation wizard to build a new response file,
and then manually merge in any changes that you want to retain from
the earlier version.
Enter the following command at a command prompt to run the
Unicenter NSM installer and pass the name of the response file to it as
follows:
SETUP.EXE -NT="full path to response file" -CDPATH="full path of
directory containing this setup.exe on the product media"
For example:
SETUP.EXE -NT="C:\MY.RSP" -CDPATH="C:\Images\NSMr11\DVD\Windows"
For additional information about deploying installations using the
response files you create, see the topic Register Unicenter NSM with
Unicenter Software Delivery in this chapter.
Create Reduced-Size Install Image (RSII)
When you choose to create a Reduced Size Install Image (RSII), see
the chapter "Install the Reduced-Size Installation Image" and the topic
Create an Installation Image for Windows for information about this
feature.
4.
Select “Install any or all Unicenter NSM components” and click Next.
The License Agreement Window appears.
5.
Read the license agreement carefully.
When you have scrolled to the end of the agreement, the “I accept the
terms in the license agreement” button becomes enabled.
6.
Click “I accept the terms in the license agreement” and then click Next.
The Company Information window appears.
112 Implementation Guide
Install Unicenter NSM on Windows
7.
Enter the information requested and click Next.
The Component Selection window appears.
Notes: Under Configuration choices, the default setting is Management
Station. If you select anything outside one of the standard installations, by
adding or deselecting components, the Configuration choices setting
changes to Custom.
A red X next to a component selection signifies that the component cannot
be installed on the system. For example, the system does not meet the
requirements for the component. You can select an item with a red X and
read the description text under the tree to see the reason why the item
cannot be installed.
Management Station
Installs the most frequently used Unicenter managers on a large
server for centralized administration of the enterprise.
Managed Node
Installs the most frequently used Unicenter agents on a workstation
that will be administered by the Management Station.
Administrative Client
Installs the graphical user interfaces, utilities, and supporting
infrastructure required to manage remote installations.
Custom
Installs only the components that you select for installation.
Note: Selecting the Express Install option limits the number of installation
questions by supplying default responses. One response sets up an
operating system user account with the name caunint and automatically
supplies a long, random password. If you ever want to use this account or
need to change the password, either uncheck the Express Install option so
that you can supply a password of your choice, or use some other
Administrator account after installation is complete to reset the password.
Chapter 6: Installation 113
Install Unicenter NSM on Windows
8.
Select components by clicking empty check boxes to add components and
clicking check boxes until the box clears to deselect components not
desired.
Components that do not have checkmarks beside them are not part of the
default installation. You must select those components you want for your
installation scenario. See the topic Common Unicenter NSM Server
Categories in the “Installation Preparation” chapter for examples of
recommended component selections for servers typically found in a
Unicenter NSM environment.
Note: Click Help for an explanation of the color-coded checkmarks.
114 Implementation Guide
Install Unicenter NSM on Windows
9.
Click Next.
If DNS is not available, the installation wizard asks you for the Master
Knowledge Base node name.
Chapter 6: Installation 115
Install Unicenter NSM on Windows
10. Click Next.
The Management Database (MDB) Setup dialog appears.
11. Use the MDB Setup dialog to define the database administrative user you
want to create and use.
Note: Unicenter NSM can only configure or install an MDB to a local
database instance, so the Database Server Name field is dimmed.
To use an MDB, WorldView requires that the server name of the Microsoft
SQL Server system housing the MDB and the Microsoft SQL Server's
instance name together do not exceed 29 bytes total. You can use a
combination of single- and double-byte characters. Whichever combination
you use, it cannot exceed 29 bytes.
Note: See the Installation Overview topic Special Character Support for
additional information about supported and restricted characters.
You can enter the following information:
Database Instance Name
Specifies in a drop-down list all the database server instance names
the system detects. Select an instance from the list. Use the Refresh
button to update the list. If you leave the field blank, the default
(unnamed) instance is used.
Administrator Name
Specifies the user name this product should use to access the MDB.
The default user name is nsmadmin, but you can change it to a name
of your choice.
If you specify a user name that already exists in the database, the
password you supply must be the actual password for that user and
that user name must already have all appropriate permissions, roles,
groups, and so forth that the product requires. A prompt appears if the
name does not have these permissions. For Microsoft SQL Server, an
existing user must be an authorized user of the master and MDB
databases, and must be assigned the roles of db_owner, uniadmin,
and regadmin.
Note: The MDB creation uses Windows Authentication and must be
run by an operating system user that is a member of the System
Administrators server role.
If you specify a user name that does not already exist, the name is
created with the password you supply.
A number of names are reserved by the database or the MDB and will
be rejected. Review the list of reserved database user names in the
earlier topic Reserved Database User Names before selecting a name.
116 Implementation Guide
Install Unicenter NSM on Windows
Administrator Password
Specifies the password to use with the administrator name. The
password must be at least six characters in length.
Note: Remember the user name and password you specify. During
installation, you must specify the user name and password. You will
also use the name and password to connect to this MDB from this local
or any remote machine in the future.
Confirm Password
Confirms the password you entered previously.
12. Click Next.
The Database Selection and Configuration window appears.
Note: This window does not appear during an Express Install unless the
default values assumed by the installation wizard are invalid on the current
system.
Use this window to specify the database server type, location, and
authorization credentials for the Unicenter management components that
store data in a Database Management System (DBMS). You can use the
same DBMS on the same machine for all components, or designate
different DBMSs on different machines.
The list box identifies components that require a DBMS to store data for
the components you have selected.
Note: If you are creating a response file for unattended installations, the
Database Selection and Configuration dialog does not attempt to
determine the location of an MDB. Therefore, you must specifically
designate the Database Server and Instance Name that you want to use.
When you later install the product using the response file, there is no
attempt to search for an MDB other than on the server and instance name
you have specified.
13. Select a component such as WorldView Repository, enter the requested
information in the Logon Information and other tabs, and click Next.
The Apache Tomcat Configuration Information window appears.
Chapter 6: Installation 117
Install Unicenter NSM on Windows
14. Enter the following information:
User Name
Specifies the user name required for authentication to Apache Tomcat.
The name is admin and cannot be changed.
Password
Specifies the password for the Tomcat administrative user. The
password cannot be blank and must contain at least six characters.
Port
Specifies the port the Tomcat service must use. The default port is
9090.
If the default port is not available at the time the dialog appears, the
system tries to locate an available port by incrementing the number to
up to 9095. If none of these ports are available, the port number is set
back to 9090. You cannot proceed with the installation without
entering a valid (that is, available) port number.
15. Click Next.
The Install Directories window appears.
Use this window to verify the directories where Unicenter NSM components
are to be installed.
To install a component in a different directory, click the directory name
and press F2 to change the directory. If you select a different directory for
installation, Unicenter NSM may require directory name changes for other
components as well, based on product prerequisites.
Note: If you install Unicenter NSM r11.2 on a 64-bit Windows Server, a
message appears and informs you that all NSM 11.2 applications will be
installed in "%ProgramFiles(x86)%", if "%ProgramFiles%" is specified as
the input directory.
16. Click Next.
The Selection Summary window appears showing the components you are
installing and their install locations.
If you want to change any of the values in the summary, click Back to
return to the appropriate window and make your changes.
17. When the values are correct, click Next.
The Interview Complete window appears.
18. Click Install to begin the installation process.
The Installation Progress window appears.
19. When the Installation Progress bar shows 100% Complete, click Close.
Note: Remember to restart your security software. See Pre-Installation
Tasks in the “Installation Preparation” chapter.
118 Implementation Guide
Install Unicenter NSM on Linux or UNIX
Install Unicenter NSM on Linux or UNIX
Use the following procedure to install Unicenter NSM for Linux or UNIX on a
system that has a local DVD drive and supports a Java GUI installation. The
DVD drive can be network mounted.
Note: During the installation of Unicenter NSM, some kernel parameters are
verified and updated to meet Interprocess Communications (IPC)
requirements. See the chapter “Installation Preparation” for more information.
You will be notified if updates are required.
To install Unicenter NSM on a Linux or UNIX system
1.
If you want to perform an unattended installation, set the SHLIB_PATH
variable to the path where the GTK libraries are located.
This is a prerequisite for creating a response file.
2.
The DVD provides directories for each supported platform (AIX, HP-UX,
Linux, Solaris-Intel, Solaris-Sparc). Change to the appropriate directory on
the DVD (for example: Linux) and run the setupNSM installation program.
Use one of the following commands:
./setupNSM
Installs the Unicenter NSM components interactively. This launches the
interface by default when running in a graphically enabled Linux or
UNIX environment (for example, KDE). Otherwise, VT100 mode will be
used.
./setupNSM [-V|-vt100]
Installs the Unicenter NSM components interactively using VT100 style
GUIs. Use this to bypass GUI mode if desired.
./setupNSM -a /directory/responsefile
Generates a response file for future use with unattended installation of
the requested component.
./setupNSM -r /directory/responsefile
Installs the component using a previously generated response file.
./setupNSM -s
Reinstalls or upgrades existing Unicenter NSM components silently.
To complete a silent mode install for a machine that does not have
Unicenter NSM installed, you must use the -r option to initiate a
response file install.
Chapter 6: Installation 119
Install Unicenter NSM on Linux or UNIX
Note: You must be logged in as userid root to initiate the Unicenter NSM
installation.
The Installation window appears.
The installer supports interactive installation of one or more Unicenter NSM
components and uninstallation of Unicenter NSM components. The initial
startup includes valid options based on the state of your computer. The
Product Information button provides a brief description of available
choices.
When you install Unicenter NSM on a Linux or UNIX computer where a
remote MDB is used, proper network and port authority is required. If the
machine is not in a network state, or the ports are secured, the installation
will not succeed.
The installation wizard prompts you for the components you want to
install, where the components should be installed, relevant user ids and
passwords, validates system requirements, and other information
important for installing the product in your enterprise.
120 Implementation Guide
Install Unicenter NSM on Linux or UNIX
For additional information about system requirements, such as kernel
parameters, see the "Installation Preparation" chapter, the Release Notes
and the Readme.
3.
Click Install.
The License Agreement window appears (initial installation only).
4.
Read the license agreement carefully.
When you have scrolled to the end of the agreement, the "I agree" button
becomes enabled.
Chapter 6: Installation 121
Install Unicenter NSM on Linux or UNIX
5.
Click "I agree".
The Unicenter NSM Configuration window appears (new installation only).
6.
Select your configuration type and click Next.
The Component Selection window appears.
Note: Choosing the Express Install option limits the number of installation
questions by supplying default responses.
122 Implementation Guide
Install Unicenter NSM on Linux or UNIX
7.
Select those components you want for your installation scenario. See the
topic Common Unicenter NSM Server Categories in the “Installation
Preparation” chapter for examples of recommended component selections.
Notes:
■
You can only select components that are supported on your UNIX or
Linux system.
■
Depending on your component selection, the following windows in this
procedure may or may not appear. The following steps in this
procedure describe typical installations.
Chapter 6: Installation 123
Install Unicenter NSM on Linux or UNIX
8.
Click Next.
Depending on your system configuration and on the selected components
to be installed, it can be necessary that kernel parameters need to be
modified. In this case the following window appears:
124 Implementation Guide
Install Unicenter NSM on Linux or UNIX
9.
Select Yes if you want to continue the installation and then click Next.
The Select Installation Locations window appears.
Accept the default directories or change the installation locations if
necessary. Unicenter NSM cannot be installed into directories with names
containing white spaces or special characters such as (, ), *, [, ], :, $, or
#.
Chapter 6: Installation 125
Install Unicenter NSM on Linux or UNIX
10. Click Next.
If you are installing the Event Agent for a Managed Node configuration, the
Select Event Agent Policy window appears.
Enter the required name and click Next.
126 Implementation Guide
Install Unicenter NSM on Linux or UNIX
If you are installing components that require DIA, the Distributed
Intelligence Architecture window appears.
Chapter 6: Installation 127
Install Unicenter NSM on Linux or UNIX
11. Enter the name of the Master Knowledge Base Node or leave this field
blank. Click Next.
The Enable Security window appears.
128 Implementation Guide
Install Unicenter NSM on Linux or UNIX
12. Select Yes or No and click Next.
The Management Database Configuration window appears since you install
Enterprise Management. It uses a local PostgreSQL database for its data.
Chapter 6: Installation 129
Install Unicenter NSM on Linux or UNIX
13. Enter the required passwords and click Next.
The Remote DSM Configuration window appears if you have selected the
DSM component to be installed.
130 Implementation Guide
Install Unicenter NSM on Linux or UNIX
14. Enter the credentials for the remote MDB and click Next.
The Selection Summary window appears.
Chapter 6: Installation 131
Install Unicenter NSM on Linux or UNIX
15. Check your component selection and click Next if it is complete.
The Installation Wizard is now ready to install Unicenter NSM.
16. Click Install to start the installation process.
The Installation Progress window appears.
When the installation completes, the Installation Complete window
appears.
17. Click View Readme to review the latest product updates.
The readme appears.
18. Click Details to review the installation log.
You can review the log at a later time using an editor of your choice. The
log is maintained on your computer as /opt/CA/installer/log/Unicenter
NSM.install_type.log, where install_type is install, reinstall, upgrade, or
deinstall. If the install fails for any reason, the log will be located at
/tmp/CAInstaller.Unicenter NSM.install_type.log.
19. Click OK to close the installation dialog.
132 Implementation Guide
Install CA Common Discovery
Install CA Common Discovery
CA Common Discovery is a subsystem that provides the discovery and
classification of all entities in your Internet Protocol version 4 (IPv4) or
Internet Protocol version 6 (IPv6) network. It discovers the relationships
between these entities and effectively records the network's topology.
CA Common Discovery includes the following components:
Discovery User Interface
Provides the services to support an administration user interface thin
client. The Apache Tomcat web service must be previously installed on the
computer. The installation prompts for the Tomcat installation path,
discovery server name, and port number.
You can install multiple Discovery UI components that point to a single
Common Discovery server component.
Discovery Server
Provides a central point for storing and querying Discovery data, options,
policies, and log data. The server includes a single instance of the
discovery agent. You must install at least one discovery server in a CA
Common Discovery installation. Large environments can install multiple
discovery servers as they are needed, but it is not necessary to have
multiple discovery servers. Several CA products can share the same
discovery server. The installation prompts for the discovery server port
number.
Installation includes the following discovery server subcomponents:
■
Request Manager
■
Database (DB) Manager
■
Log Manager
■
Enterprise Common Services Installation
Note: It is not necessary to have multiple Discovery Servers. You can
share a single Discovery Server across multiple CA products.
Chapter 6: Installation 133
Install CA Common Discovery
Discovery Agent
Provides discovery data gathering. CA Common Discovery installs at least
one discovery agent with a discovery server in a CA Common Discovery
installation. Multiple agents can be installed at strategic locations on the
network to gather data and communicate it back to the discovery server.
After installation, the agent service starts automatically. It also registers
itself with the discovery server. The agent registration process adds the
agent to the discovery server's agent list. The server returns a set of
default agent options. The installation prompts you for the discovery
server name.
Installation includes the following discovery agent subcomponents:
■
Request Agent
■
Discovery Engines
■
Enterprise Common Services Installation
Platform Support
The following platforms support installation of CA Common Discovery:
■
Windows 2003
■
Windows XP
■
Windows Vista
■
Longhorn
Tomcat Authentication
You can select Tomcat authentication by choosing the custom CA Common
Discovery installation.
The installation defines an admin role for a Tomcat user with a user name of
admin. If the admin user is already present, the installation aligns it to the
admin role created, but if not present, the installation creates a user by that
name with a password of tomcat. The admin user is given access to CA
Common Discovery on successful authentication.
134 Implementation Guide
Install CA Common Discovery
Install CA Common Discovery
You must install Tomcat 5.5 or greater as a prerequisite to performing the CA
Common Discovery UI installation.
To install CA Common Discovery on Windows
1.
Insert the installation media into the drive.
The installation program starts automatically. The Unicenter Product
Explorer appears.
2.
Select Installation Wizard for CA Common Discovery, and click Install.
A welcome screen appears.
3.
Click Next.
The Setup Type page appears.
4.
Select one of the following:
Complete
Installs all the Common Discovery components.
Custom
Lets you select the Common Discovery components you want to
install.
The Custom Setup page appears when you select the Custom option. The
Destination Folder page appears when you select the Complete option.
5.
Select the program features you want to install in the Custom Setup page.
The Destination Folder page appears.
6.
Click Change.
The Change Current Destination Folder page appears.
7.
Select the Apache Tomcat folder, and click Install.
Note: You must manually locate the Apache Tomcat folder or else an error
message appears.
The installation starts.
8.
Click Finish.
CA Common Discovery is installed.
Chapter 6: Installation 135
Install CA Common Discovery
NSM--Configure CA Common Discovery (CACD) With SSL
When installing and configuring SSL-enabled CACD or CA Web Server, keytool
commands and installation or configuration dialogs prompt you for the
hostname of the system. Provide that hostname consistently using either Fully
Qualified Domain Name or the short hostname.
There is potential for two SSL mechanisms to be in place:
■
The Common Discovery UI is accessible by the Tomcat SSL port. Complete
the procedure below to configure this mechanism.
■
Clients of CACD (for example, classic discovery using dscvrbe) connect to
an SSL enabled CACD server using the Common Discovery Server Port
specified during CACD installation. For more information about configuring
this mechanism, see Configure Your Client Applications to Communicate
With an SSL-enabled CACD Server.
To configure CA Common Discovery (CACD) with SSL
1.
Choose a custom CACD installation to support SSL encryption and
authentication.
2.
When performing the installation, select the "Use SSL/TLS encryption and
authentication" check box, which is not selected by default. See the
Common Discovery Server Configuration window of the CACD Installation
Wizard.
136 Implementation Guide
Install CA Common Discovery
3.
Continue the installation and follow the instructions on the screen.
4.
On the Certificate Password dialog, when prompted for the CACD
Certificate password, it must also match that of the CA Web Server's
.keystore file.
Chapter 6: Installation 137
Install CA Common Discovery
5.
138 Implementation Guide
During the CACD installation, the Java Keystore dialog prompts you for the
Java Keystore filename. If the Tomcat service was installed with SSL
enablement, you must enter the full path of the same .keystore file that
was installed with CA WebServer. The Keystore Password must also match
the password of the CA Web Server's .keystore file.
Install CA Common Discovery
6.
If the same certificate was already imported into Java Trust Store as
described in step 3 in the "Configure Tomcat with SSL" section in this
guide, enter the full path and credentials of the same Java Trust Store that
was already installed.
7.
When the CACD Installation completes successfully, it writes the
setjavaopts.bat file into the root directory of the CA-Web Server. This file
contains two entries similar to the following:
VM_OPTION = -Djavax.net.ssl.keyStore=C:\keystore
VM_OPTION = -Djavax.net.ssl.keyStorePassword=changeit
8.
Copy these entries manually into the ws.cfg file that is located in the conf
folder of the CA Web Server installation directory.
9.
Restart the CA Web Server service.
Note: The Server.xml file inside the Tomcat must be changed manually to
enable the SSL for Tomcat as explained in steps 5 and 6 in the "Configure
Tomcat with SSL" section in this guide.
Chapter 6: Installation 139
Install CA Common Discovery
Configure Your Client Applications to Communicate With an SSL-enabled CACD Server
The following steps detail how to create an SSL client key to enable client
applications to communicate with an SSL-enabled CACD server.
To create an SSL client key
1.
From the command prompt change to the folder
CA_APPSW\WVCmnDscv_SSL
2.
Copy the cacert.pem file from the discovery server located under the
Common Discovery Installation Folder\SSL to the
CA_APPSW\WVCmnDscv_SSL folder.
3.
Run the following command:
newclientcert.cmd client
4.
When prompted, enter your details like country name and so on or you
can just press the enter key to use the default values.
Note: When prompted for Common Name, enter the client system's name.
Remember to consistently use either the FQDN or hostname as
appropriate.
5.
Verify that you have a certs folder under SSL folder. In the SSL folder the
files client.pem and clientkey.pem should exist.
Reinstall CACD in an SSL Enabled Environment
If presented with a "Certificate already exists." error while attempting to
reinstall an SSL enabled CACD on a system, you need to confirm that the
certificate with alias "cacd" is not being used by any other applications. Once
confirmed, you may use the following commands to list and delete the
certificate from the Java Trust Store.
To list and delete a certificate from the Java Trust Store
1.
From the command prompt, enter the following command:
cd JRE_HOME\lib\security
JRE_HOME is the install path of the corresponding JRE. Make sure that the
JRE_HOME\bin is in the path.
2.
List all of the certificates that are stored in the trust store file by entering
the following command:
keytool -list -keystore cacerts
140 Implementation Guide
Register Unicenter NSM with Unicenter Software Delivery
3.
Delete a certificate with the "cacd" alias using the following command:
keytool -delete -alias cacdSYSTEMNAMEca -keystore cacerts
SYSTEMNAME is the name of the corresponding host machine. The
cacdSYSTEMNAMEca must match the cacd prefixed entry as output of the
keytool -list command.
4.
Once the certificate has been deleted, a restart of all the applications using
JRE and tomcat authentication is recommended.
You should now be able to reinstall CACD successfully again using SSL.
Register Unicenter NSM with Unicenter Software Delivery
Registering Unicenter NSM with Unicenter Software Delivery lets you register
once and deploy many times. When you register Unicenter NSM, the entire
contents of the Unicenter NSM product media are copied to the Unicenter
Software Delivery database. Because of the large amount of data, you do not
want to register Unicenter NSM multiple times, and it is not necessary.
The many computers to which you want to deploy Unicenter NSM may have
different uses for or requirements of Unicenter NSM. You may want to install
different agents and management components on different computers.
Further, you may want to specify different installation or configuration
parameters.
The solution is to register Unicenter NSM as one Unicenter Software Delivery
package with many procedures, where each procedure installs a different
selection of components and specifies a different set of installation or
configuration values.
Chapter 6: Installation 141
Register Unicenter NSM with Unicenter Software Delivery
Prepare for Registration
The first thing you must do is plan. Make a list of all the varieties of
installations you want to support. Each item on the list will specify a selection
of components to install, as well as installation parameters such as installation
drive and path, database server name, and so on.
You can create response files for Windows, Linux, and UNIX installations. You
can also create response files for Systems Performance on these platforms.
Note: When registering packages to Unicenter Software Delivery, you must
define 32-bit response files to be deployed to 32-bit operating systems and
64-bit response files to be deployed to 64-bit operating systems. The job
output will contain an error message indicating that you deployed the response
file to the wrong operating system. If you are running DSM 11.x, this
restriction is enforced by DSM and the deployment will not take place.
Host names and other machine-specific information needs to be edited in the
response file. For information about response files in PIF and enabling dynamic
settings that are evaluated on the target system, see the “CCS UNIX/Linux
Reference” appendix.
After making your plan, create a separate response file to correspond to each
item on your list. A response file is a text file that the Unicenter NSM
Installation Wizard creates for you. When you run the wizard, select the option
to “Build Unicenter NSM response file for unattended install.” The response file
records all of your choices and specifications.
You can tell the wizard what name to give the response file and where to store
it. Later, when you perform Unicenter Software Delivery registration, the name
of the response file becomes the name of the Unicenter Software Delivery
procedure that installs Unicenter NSM with that response file. If you are
making more than one response file, make each name descriptive of the kind
of installation it will perform.
142 Implementation Guide
Register Unicenter NSM with Unicenter Software Delivery
Note: You must run the registration tool using the steps provided here. You
cannot run the executable SDRegister.exe directly from the product media.
To prepare for registering a Unicenter NSM install package with
Unicenter Software Delivery for Linux or UNIX
1.
Create a directory to contain your custom response files.
This directory may be given any name; for example, ResponseFiles.
2.
Run setupNSM with the -a parameter to create custom response files.
3.
Select Installation Wizard for Unicenter NSM.
Note: Give the response file a meaningful name, as this name will become
the name of the Unicenter Software Delivery procedure that runs the
unattended install. The name appears in the Unicenter Software Delivery
catalog and you will want to be able to recognize it.
4.
Click Next and select the components you want to install, answering the
install questions with appropriate values.
For Linux and UNIX registrations, you have the option of registering
Unicenter NSM agents only. Registering Unicenter NSM agents reduces
only network load while deploying agents to a large number of machines.
You will be prompted for any required information.
You can create as many custom response files as you want with this
procedure.
To prepare for registering a Unicenter NSM install package with
Unicenter Software Delivery for Windows
1.
Create a directory to contain your custom response files.
This directory may be given any name, for example, ResponseFiles.
2.
Run the install wizard for the appropriate Windows, Linux or UNIX platform
to create custom response files.
The first page of the install wizard appears.
3.
Select “Build a Windows response file for unattended install” and enter the
full path name for the response file, specifying the directory you created in
Step 1.
Note: Give the response file a meaningful name, as this name will become
the name of the Unicenter Software Delivery procedure that runs the
unattended install. The name appears in the Unicenter Software Delivery
catalog and you will want to be able to recognize it.
4.
Click Next and select the components you want to install, answering the
install questions with appropriate values.
You can create as many custom response files as you want with this
procedure.
Chapter 6: Installation 143
Register Unicenter NSM with Unicenter Software Delivery
To prepare for registering a Unicenter NSM Systems Performance
install package with Unicenter Software Delivery (Windows only)
1.
Create a directory to contain your custom response files.
This directory may be given any name, for example, ResponseFiles.
2.
Run the install wizard for Unicenter NSM Systems Performance to create
custom response files.
The first page of the install wizard appears.
3.
Select “Generate a response file for unattended (and remote) installations”
and enter the full path name for the response file, specifying the directory
you created in Step 1.
Note: Give the response file a meaningful name, as this name will become
the name of the Unicenter Software Delivery procedure that runs the
unattended install. The name appears in the Unicenter Software Delivery
catalog and you will want to be able to recognize it.
4.
Click Next and select the components you want to install, answering the
install questions with appropriate values.
You can create as many custom Systems Performance response files as
you want with this procedure.
Note: You can copy and rename response files if necessary, as long as the end
result is the same. The files should have meaningful names and be placed in
the directory you created in Step 1.
Run Registration
After you have created all required response files and placed them in a single
directory, run the Unicenter Software Delivery registration tool.
On Windows platforms, to run the Unicenter Software Delivery
registration tool
1.
From the Unicenter NSM Product Explorer, locate “Unicenter
Products/Unicenter for Windows,” select “Register packages to Unicenter
SD for Windows,” and click Install.
The registration tool dialog appears.
Specify the directory that contains your response files and the location of
Unicenter NSM product media.
Note: You may not specify UNC drives for either the Root directory or the
Response Files fields. If these files are located on remote servers, map
them to a local drive and use that drive letter.
2.
Click Register.
The task is complete.
144 Implementation Guide
Install Unicenter Systems Performance
On Linux or UNIX platforms, to run the Unicenter Software Delivery
registration tool
1.
Run setupNSM, select “Register Unicenter NSM r11.2 Linux/UNIX packages
to Unicenter SD,” and click Install.
The registration tool dialog appears.
2.
Specify the directory that contains your response files and the location of
Unicenter NSM product media.
3.
Click Register.
The task is complete.
Deploy Unicenter NSM to Hosts
To deploy Unicenter NSM to a host on your network, specify to Unicenter
Software Delivery both the host and the procedure. Unicenter NSM installation
runs in unattended mode on the designated host. The installation is configured
by the response file you associated with the procedure.
Note: On Linux or UNIX systems proper locale settings are required before
Unicenter Software Delivery deployment (for example: en_US).
Install Unicenter Systems Performance
You must use the Systems Performance Component Selection screen to install
the Unicenter Systems Performance feature. In addition, you can use
Unicenter Software Delivery to install and configure Systems Performance
agents across the enterprise.
Note: Systems Performance creates default settings in the All Users area of
Documents and Settings.
The package for the Unicenter NSM agents provides procedures for installing
the following agents:
■
System (OS and log) agents
■
Performance agents
Chapter 6: Installation 145
Install Unicenter NSM Systems Performance on Windows
Install Unicenter NSM Systems Performance on Windows
Use the following procedure to ensure a successful installation of Unicenter
NSM Systems Performance on Windows platforms.
To install Unicenter NSM Systems Performance on Windows platforms
1.
Insert the installation DVD into the drive. The installation program starts
automatically.
The Unicenter Product Explorer appears.
2.
Expand the Unicenter for Windows view.
3.
Click Installation Wizard for Unicenter NSM Systems Performance, and
then click Install.
The Unicenter NSM Systems Performance Setup wizard appears.
4.
Click Next.
The license agreement appears.
5.
Accept the license agreement, and click Next.
The Customer Information page appears.
6.
Enter your user name and organization, select Install on this machine, and
click Next.
The Setup Type page appears.
7.
Select the required setup type, and follow the on-screen instructions to
complete the installation.
Note: If you select a folder under %ProgramFiles% on a 64-bit version of
Windows, the installer automatically corrects the folder to be under
%ProgramFiles(x86)% because it is installing 32-bit applications.
Note: If you choose the option Generate a Response File in the Customer
Information page of the wizard, you can make a file containing setup and
configuration information for future use with unattended installations of
Systems Performance.
Enter the following command at a command prompt to run the Systems
Performance installer and pass the name of the response file to it (the
argument is case-sensitive):
setup.exe USE_THIS_RESPONSE_FILE="full path to response file"
The setup.exe file for this command is located on your installation media at
x:\Windows\NT\SystemsPerformance\setup.exe.
146 Implementation Guide
Install Active Directory Management
Install Active Directory Management
Active Directory Management (ADM) for Unicenter NSM is integrated into the
Unicenter NSM r11.2 installation and consists of the following components:
■
Active Directory Enterprise Manager
■
Active Directory Explorer
■
Active Directory Reporting
■
Active Directory Knowledge Base Content
■
Active Directory Agent (caiAdsA3)
You can select Active Directory Management and the Active Directory Agent to
install from the Unicenter NSM Installation Wizard. Each entry contains subnodes that define what ADM components are installed and how the Active
Directory Agent interacts with Active Directory Management. This section
contains ADM platform support, software requirements, installation procedures
for ADM and the Active Directory Agent, and both agent installation scenarios:
integrated with ADM or standalone.
Platform Support
ADM fully supports the following platform:
■
Windows Server 2003
The caiAdsA3 agent also supports Windows Server 2008, but not on an Active
Directory functional level. Read-only DCs are also not supported on this
platform.
Software Requirements
Ensure that the following software requirements are met for ADM and the
Active Directory Agent:
■
Active Directory Management requires the Performance Distribution Server
component to be present on the same server to import created
performance cubes from the Active Directory EM Service on the manager
server into the Performance Data Grid. On startup, ADM checks for the
availability of Systems Performance libraries and whether a Distribution
Server is installed. If either of the checks fails, the service terminates and
writes a message to the Windows Event Log.
Chapter 6: Installation 147
Install Active Directory Management
■
Active Directory Reporting requires the Performance Reporting component
to be present on the same server. Active Directory Reporting tightly
integrates with Performance Management to provide performance statistics
related to Active Directory domains. When running reports, the Active
Directory data displays within Performance Reporting using customized
reports and a customized report tree. If Performance Reporting is not
installed, Active Directory Reporting cannot register itself with Web
Reporting Server.
■
When integrated with Active Directory Management, the Active Directory
Agent requires the Historical Performance Agent to be present on every
monitored node to poll the Active Directory Agent for performance data
and transfer it to an associated performance cube. You should install both
agents on at least every domain controller to ensure that all relevant
performance data is captured.
None of these operations are performed by default when you install the Active
Directory components. You must ensure that these components are on the
appropriate servers and install them manually if they are not. You can perform
the required installations in any order (either before or after the Active
Directory installations), although it is recommended to install the Active
Directory Agent before the Performance Agent.
148 Implementation Guide
Install Active Directory Management
Install Active Directory Management
Starting with Unicenter NSM r11.2, Active Directory Management appears as a
new component in the Unicenter NSM Installation Wizard. Active Directory
Management appears as several manager components that you must install to
take full advantage of its Active Directory monitoring capabilities. Installation
of the Active Directory manager components is managed as part of the new
Active Directory Management (ADM) setup plug-in, which is loaded by the
Unicenter NSM installer and interfaces with the installation framework to drive
the correct setup of the components.
Important! Keep in mind that you must have the Performance Distribution
Server and Systems Performance Reporting components installed on the same
server for ADM to work correctly. You can install these components before or
after the ADM installation. For more information, see Software Requirements.
For the integration with the Active Directory Agent to work correctly, all Active
Directory Agents must be at the caiAdsA3 level (either r11.1 or r11.2).
Install Active Directory Management on a Unicenter NSM manager server
somewhere in the Active Directory; installation on a domain controller is not
recommended.
ADM installs to the following location:
Install_Path\SC\CCS\ADEM
Note: The following procedure reflects an ADM-only installation. If you select
additional Unicenter NSM components to install at the same time, other
screens and options may appear during the installation.
To install Active Directory Management
1.
Open the Unicenter Product Explorer, select Installation Wizard for
Unicenter NSM, and click Install.
The installation wizard initializes, and the Setup Options screen appears.
2.
Select Install any or all Unicenter NSM components and click Next.
The License Agreement screen appears.
3.
Scroll to the bottom of the agreement, select I agree, and click Next.
The Company Information screen appears.
4.
Enter your information in the Details pane and click Next.
The Component Selection screen appears.
5.
Select the Active Directory Management check box to install the main ADM
manager component, which provides a hierarchy view of the Active
Directory infrastructure and stores a Business Process View representation
of Active Directory components and services in the MDB.
Chapter 6: Installation 149
Install Active Directory Management
The following sub-nodes are automatically selected and are necessary to
implement the complete functionality of ADM:
Active Directory Enterprise Manager
Provides an enterprise-wide view of your Active Directory resources.
Active Directory Enterprise Manager analyzes all enterprise Active
Directory resources and displays the information it gathers in the
Active Directory Explorer.
Selecting this check box automatically installs the following two
components:
■
Active Directory EM Service
Queries the Active Directory for information about Active Directory
resources and polls the Active Directory Agents on all monitored
domain controllers in all forests for domain controller specific
metrics and states.
■
Active Directory Explorer
Displays Active Directory data in a web-based application. The
Active Directory Explorer gets its data from the Active Directory
EM Service. It lets you manage your Active Directory on an
enterprise level based on forests, sites, and domains from domainoriented or site-oriented perspectives.
Active Directory Reporting
Transfers important Active Directory metric and event information to
Unicenter NSM performance cubes. Active Directory Reporting lets you
run various out-of-the box reports from the Active Directory Explorer
that are generated from this performance cube data. These reports are
processed by Web Reporting Server (WRS), which provides the ability
to select from preconfigured reports, configure your own custom
reports, and schedule reports to run at set times.
Note: Active Directory Reporting requires the Systems Performance
Reporting component to be installed on the same server to enable the
reporting functionality. For more information, see Software
Requirements.
6.
(Optional) Expand CA Knowledge Base and select ADM Knowledge Base
Content if you want to install the Knowledge Base content for Active
Directory Management. This component causes traps from the Active
Directory Agent and messages from the Active Directory Enterprise
Manager that appear as event messages in the Unicenter NSM Event
Console to contain a specific hyperlink in their message text. Clicking that
link redirects you to associated articles in the Knowledge Base that you
can use to troubleshoot the cause of the event and possible solutions.
This option is not selected by default when you select Active Directory
Management.
150 Implementation Guide
Install Active Directory Management
7.
Click Next when finished selecting components to install.
The Distributed Intelligence Architecture screen appears.
8.
Enter the Master KB Node in the provided field and click Next.
The Database Selection and Configuration screen appears.
9.
Confirm the logon information for the MDB containing WorldView
information and click Next.
The Apache Tomcat Configuration screen appears.
10. Enter the Tomcat configuration credentials in the provided fields and click
Next.
The Install Directories screen appears.
11. Specify the installation directory or accept the default, and click Next.
The Installation Summary screen appears.
12. Click Next.
Active Directory Management installs.
Active Directory Agent Installation
You install the new Active Directory Agent used with ADM (caiAdsA3) into the
same place you installed the old agent (caiAdsA2). Installation of the caiAdsA3
agent is managed as part of the existing Agent Technology Agents (ATA) setup
plug-in that is loaded by the Unicenter NSM installer and interfaces with the
installation framework to drive the correct setup of all agents shipped with
Unicenter NSM.
Note: The Unicenter NSM r11.1 ADM patch suite also included several PTFs
related to the Active Directory Agent policy files, such as DSM, abrowser, and
dashboards. These files are now included with Unicenter NSM and
automatically installed as part of the Common Resource Packages and Agent
Technologies components.
The Active Directory Agent is an entry in the Unicenter NSM Installation
Wizard located under Agent Technologies, Agent Technology Agents.
The agent installs to the following location:
Install_Path\SC\CCS\AT\AGENTS
During an initial installation the agent is selected by default on domain
controllers, and it is not selected by default for non-domain controllers. If you
are reinstalling or upgrading, your previous settings are preserved.
Chapter 6: Installation 151
Install Active Directory Management
The selections you make for the Active Directory Agent and the agent's
implementation requirements depend on how you want to use the agent. The
following are the two most common implementation scenarios:
■
Full integration with Active Directory Management
■
Standalone operation (similar to caiAdsA2 agent implementation, without
ADM integration)
Important! You must select one or the other implementation option. You can
either have an environment with standalone caiAdsA3 agents without ADM
installed, or you can implement a fully-functional ADM environment, including
caiAdsA3 agents installed on all domain controllers.
152 Implementation Guide
Install Active Directory Management
Install the Active Directory Agent for Full Integration with Active Directory Management
The most common and recommended implementation scenario for the Active
Directory Agent on domain controllers is to enable full integration with Active
Directory Management. In this scenario, Active Directory Management relies
on the agent's enhanced and sophisticated monitoring capabilities to be able to
fully provide the enterprise-wide monitoring functionality.
Important! Keep in mind that you must have the Performance Agent installed
on every monitored node to collect the performance data of the Active
Directory Agent. We recommend installing the Active Directory Agent first. For
more information, see Software Requirements.
In this scenario, you must install the Active Directory Agent on all domain
controllers (DCs) in the forests you want to monitor and select Full Integration
on these DCs. If during a roll-out phase the Active Directory Agent is not
installed on all DCs, the agent and Active Directory Management still function;
however, for a full picture of proper Active Directory operation, such as proper
replication to all DCs, the agent must be installed on all DCs.
Note: The following procedure reflects an agent-only installation. If you select
additional Unicenter NSM components to install at the same time, other
screens and options may appear during the installation.
To install the Active Directory Agent fully integrated with Active
Directory Management
1.
Open the Unicenter Product Explorer, select Installation Wizard for
Unicenter NSM, and click Install.
The installation wizard initializes, and the Setup Options screen appears.
2.
Select Install any or all Unicenter NSM components and click Next.
The License Agreement screen appears.
3.
Scroll to the bottom of the agreement, select I agree, and click Next.
The Company Information screen appears.
4.
Enter your information in the Details pane and click Next.
The Component Selection screen appears.
Chapter 6: Installation 153
Install Active Directory Management
5.
Select Active Directory Agent under Agent Technologies, Agent Technology
Agents, and clear the Express Install check box.
Note: You must clear the Express Install check box, or you cannot specify
the implementation of the agent that you want to use.
Click Next.
The Component Functionality screen appears.
6.
Select the Full Integration of Active Directory Agent with Active Directory
Management check box.
Also, you should select the Adaptive Configuration Support for Active
Directory Agent check box if you want Adaptive Configuration to
automatically configure the agent.
Click Next.
The Distributed Intelligence Architecture screen appears.
7.
Enter the Master KB Node in the provided field and click Next.
The Install Directories screen appears.
8.
Specify the installation directory or accept the default, and click Next.
The Installation Summary screen appears.
9.
Click Next.
The Active Directory Agent installs.
Install the Active Directory Agent as a Standalone Agent
If you do not make use of Active Directory Management, or if you want to
monitor critical member servers, such as Microsoft Exchange, you should
install the agent as standalone without Active Directory Management
integration.
The caiAdsA2 agent is not supported in Unicenter NSM r11.2, but you can
operate the standalone Active Directory Agent in the same manner you did the
caiAdsA2 agent. However, the agent will only support a subset of its
monitoring capabilities in this configuration. You may even want to preserve
the configuration of the old caiAdsA2 agent. For more information, see the
Inside Active Directory Management guide.
When the Active Directory Agent is not integrated with Active Directory
Management, the Historical Performance Agent is no longer a required
component.
Note: The following procedure reflects an agent-only installation. If you select
additional Unicenter NSM components to install at the same time, other
screens and options may appear during the installation.
154 Implementation Guide
Install Active Directory Management
To install the Active Directory Agent to operate in a standalone
manner
1.
Open the Unicenter Product Explorer, select Installation Wizard for
Unicenter NSM, and click Install.
The installation wizard initializes, and the Setup Options screen appears.
2.
Select Install any or all Unicenter NSM components and click Next.
The License Agreement screen appears.
3.
Scroll to the bottom of the agreement, select I agree, and click Next.
The Company Information screen appears.
4.
Enter your information in the Details pane and click Next.
The Component Selection screen appears.
5.
Select Active Directory Agent under Agent Technologies, Agent Technology
Agents, and clear the Express Install check box.
Note: You must clear the Express Install check box, or you cannot
Also, you should select the Adaptive Configuration Support for Active
Directory Agent check box if you want Adaptive Configuration to
automatically configure the agent.
Note: You must clear the Express Install check box, or you cannot specify
the implementation of the agent that you want to use.
Click Next.
The Component Functionality screen appears.
6.
Clear the Full Integration of Active Directory Agent with Active Directory
Management check box.
Also, you should select the Adaptive Configuration Support for Active
Directory Agent check box if you want Adaptive Configuration to
automatically configure the agent.
Click Next.
The Distributed Intelligence Architecture screen appears.
7.
Enter the Master KB Node in the provided field and click Next.
The Install Directories screen appears.
8.
Specify the installation directory or accept the default, and click Next.
The Installation Summary screen appears.
9.
Click Next.
The Active Directory Agent installs.
Chapter 6: Installation 155
Install Monitoring for z/OS Interface
Install Monitoring for z/OS Interface
The Monitoring for z/OS interface is installed automatically as part of Unicenter
NSM (with no component selection screen). The following instructions provide
the information you need to install the interface on the mainframe. You have
the choice of using the files provided on the Unicenter NSM Installation DVD or
installing using the mainframe tape provided.
FTP and Load JCL to the Mainframe
This topic provides instructions for you to FTP the necessary files from the
Unicenter NSM Installation DVD to the mainframe and load the necessary JCL
for the installation.
FTP the Sequential Files to the Mainframe
To upload the sequential files to the mainframe
1.
From a command prompt, change to the SMO file directory on the DVD.
For example:
cd dvd_drive:\zOS
2.
Connect to the mainframe using the ftp client:
ftp mf_hostname
3.
Sign on to the FTP server.
4.
At the FTP prompt, enter the following:
ftp> bin
ftp> quote site recfm=fb
ftp> quote site lrecl=80
ftp> put smo110.seq.instlib 'hlq.SMO110.SEQ.INSTLIB'
ftp> put smo110.seq.loadlib 'hlq.SMO110.SEQ.LOADLIB'
ftp> put smo110.seq.miblib 'hlq.SMO110.SEQ.MIBLIB'
5.
To transfer the conversion JCL to the mainframe, enter the following:
ftp> cd 'hlq.site.JCL'
ftp> ascii
ftp> put smo110_receive.jcl RECSMO1
156 Implementation Guide
Install Monitoring for z/OS Interface
Convert the Sequential Files Back to PDS Format
To convert the sequential files back to PDS format
1.
Edit the RECSMO1 file and follow the instructions listed at the top of the
file.
2.
Submit the RECSMO1 job.
The job should complete with a return code of zero for all steps.
Complete the Installation
To complete the installation, see the topic Install on the Mainframe and follow
these steps:
For a non-SMP/E installation:
1.
Skip Steps 1 and 3 in the Procedure checklist.
Detailed instructions for each step follow the checklist.
2.
Complete Step 2 and Steps 4 through 10 as listed.
For an SMP/E installation:
1.
Skip Step 1.
2.
Complete Step 2 by filling in the required values.
3.
For Step 3, use the JCL INSTDVD1 instead of the INSTSMP1.
This completes the SMP/E installation while bypassing the tape copy steps.
4.
Complete Steps 4 through 10 as listed.
Install on the Mainframe
Use the following procedure if you want to install the Monitoring for z/OS
feature using the mainframe tape (included with the Unicenter NSM package)
instead of the files on the Installation DVD.
The installation tape, which is a standard label tape, contains these data sets
and formats:
File
Data Set Name
Data Set Contains
Format
1
SMO.INSTLIB.TAPE
The installation JCL
IEBCOPY
2
SMO.MIBLIB.TAPE
MIB library
IEBCOPY
3
SMO.LOADLIB.TAPE
Agent load library
IEBCOPY
Chapter 6: Installation 157
Install Monitoring for z/OS Interface
The Monitoring for z/OS installation requires several procedures; use the
following checklist as you install the agent.
√
Procedure
1. Download the installation library.
2. Modify member SETVARS.
3. Run the installation job.
4. Copy the MIB to Agent Technology.
5. Load the MIB into the object store.
6. Update the awservices configuration.
7. Update the agent PROCs and add them to a system procedure
library.
8. Give APF authorization to the agent load library.
9. Give the ZOSAGTS and CICSAGTS PROCs the proper security.
10. Migrate previous z/OS installations (if applicable).
158 Implementation Guide
Install Monitoring for z/OS Interface
Download the Installation Library
To download the installation library
1.
Run the following job stream to download the installation library from the
installation tape.
//COPYINST JOB (0000)
//COPY
EXEC PGM=IEBCOPY
//SYSUT3
DD
UNIT=SYSDA,SPACE=(CYL,(5,1))
//SYSUT4
DD
UNIT=SYSDA,SPACE=(CYL,(5,1))
//SYSPRINT DD
SYSOUT=*
//TAPEIN
DSN=SMO.INSTLIB.TAPE,DISP=OLD,
DD
//
UNIT=TAPE,VOL=SER=SMO110,
//
LABEL=(1,SL)
//INSTLIB
DD
DSN=smo.INSTLIB,DISP=(NEW,CATLG,DELETE),
//
UNIT=SYSDA,VOL=SER=volume,
//
DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160),
//
SPACE=(CYL,(1,1,5))
//SYSIN
DD
*
COPY INDD=((TAPEIN,R)),OUTDD=INSTLIB
/*
//
2.
Modify the job stream to fit your site’s specifications by replacing the
italicized items in the sample JCL with the following information:
smo
Specifies the high-level index qualifier for the installation library. You
can change this index to meet your site’s needs or naming
conventions. The default index qualifier for all the libraries is smo.
volume
Specifies the volume serial number where the installation library is to
reside.
SETVARS Member Modification
The SETVARS member contains JCL SET statements used to assign symbolic
parameters used in the remainder of the installation. Review and modify these
statements as needed. The meaning of each symbolic parameter is explained
in the member.
Note: The install supports both SMP/E and non-SMP/E; the SETVARS member
contains settings for both installation types.
Chapter 6: Installation 159
Install Monitoring for z/OS Interface
Run the Installation Job
Run the installation job to create the agent libraries. The SMP/E installation
and non-SMP/E installation have separate jobs. INSTSMP1 is for the SMP/E
installation and INSTSTD1 is for the non-SMP/E installation. Instructions for
the installation are included in the members.
To run the installation job for an SMP/E installation
1.
Review the INSTSMP1 member in the smo.INSTLIB data set.
2.
Submit the INSTSMP1 member.
3.
Ensure the INSTSMP1 job ends with a condition code of 4 or less.
To run the installation job for a non-SMP/E installation
1.
Review the INSTSTD1 member in the smo.INSTLIB data set.
2.
Submit the INSTSTD1 member.
3.
Ensure the INSTSTD1 job ends with a condition code of 0.
Copy the MIB to Agent Technology
To copy the agent MIB to the Agent Technology MIB directory
1.
Review the INSTMIB2 member in the smo.INSTLIB data set.
2.
Submit the member INSTMIB2.
3.
Ensure the job INSTMIB2 ends with a condition code of 0.
Note: To load the monitoring for z/OS MIBs automatically whenever the
clean_sadmin script runs, update the install_mibs script. Add the following
lines to the $AGENTWORKS/services/tools/install_mibs file:
ldmib -n caiSysAgtzOS -m “//’$AWORKS_MVS_PREFIX.MIBLIB(ZOSAGENT)’”
ldmib -n caiSysAgtCics2 -m “//’$AWORKS_MVS_PREFIX.MIBLIB(CICSAGT2)’”
Load the MIB into the Object Store
To load the agent MIB into the Agent Technology Object Store
Note: Agent Technology must be active to run this job.
1.
Review the INSTLDM3 member in the smo.INSTLIB data set.
2.
Submit the member INSTLDM3.
3.
Ensure the job INSTLDM3 ends with a condition code of 0.
160 Implementation Guide
Install Monitoring for z/OS Interface
Update the awservices Configuration
The Monitoring for z/OS feature must be defined so it can register itself with
Agent Technology.
To define the z/OS and CICS agents
Note: Agent Technology must be active for this job to run.
1.
Review the INSTAWS4 member in the smo.INSTLIB data set.
2.
Submit the member INSTAWS4.
3.
Ensure the job INSTAWS4 ends with a condition code of 0.
Update Agent PROCs and Add to System Procedure Library
The CICSAGTS, CICSAGTE, ZOSAGTS, and ZOSAGTE members contain the JCL
procedures needed to start and stop the CICS and System agent address
spaces.
To update the agent PROCs
1.
Copy the agent PROCs into one of your system procedure libraries.
2.
Modify the SET statements at the beginning of each PROC.
3.
Remove the following load libraries from the STEPLIB if they are in the
system LINKLIST:
■
Agent Technology
■
IBM LE
■
Unicenter CA-SYSVIEW Server
Agent Load Library APF-Authorization
The smo.LOADLIB data set must be APF-authorized for the agents to operate.
Chapter 6: Installation 161
Install Monitoring for z/OS Interface
Give the ZOSAGTS and CICAGTS PROCs the Proper Security
To give the ZOSAGTS and CICSAGTS PROCs the necessary security
1.
Ensure an OMVS segment is defined to the user ID assigned to the
ZOSAGTS and CICSAGTS started tasks. The segment allows the agents to
access USS.
2.
Assign a user identifier (UID) to the user ID assigned to the started task
ZOSAGTS. This allows the agent to collect complete information on USS
processes and IPC resources.
Note: A UID of 0 (super-user authority) allows the agent to collect all USS
process and IPC resource information. A UID of any other value allows the
agent to collect information only on USS processes and IPC resources owned
by the specified UID.
Migration of Previous z/OS Agent Installations
You use the CFGCONV utility to migrate an existing agent configuration from
the previous release of CICS, OS/390, and USS agents into this release of
Unicenter NSM. Configuration sets for the system and CICS agents from
previous releases are not compatible with this release. In addition, the
functionality of the USS agent has been integrated into the z/OS system
agent. Use the CFGCONV utility to migrate existing threshold and watcher
settings from an existing agent installation. The JCL for using the CFGCONV
utility is located in smo.INSTLIB(CFGCONV).
CFGCONV generates the configuration set in a format that Unicenter NSM can
use. By default, the newly generated configuration set is CfgZOSAGENT for the
system agent and CfgCICSAGENT for the CICS agent, where ZOSAGENT and
CICSAGENT represent the default agent instance names.
Note: You must run CFGCONV once for each agent instance you are
migrating. Run the utility additional times to append USS agent settings to the
z/OS system agent or to append multiple CICS regions to a CICS configuration
set.
How You Can Use the CFGCONV Utility
Perform the following steps before using CFGCONV:
1.
Start Agent Technology.
2.
Stop the agent instance.
If you are migrating data from the OS/390 and USS agents, shut down
both agents while running CFGCONV.
3.
162 Implementation Guide
Update the PARM field in the CFGCONV job to specify the migration
options. Sample PARMS are provided in the job.
Install Unicenter Management Portal
The following flags control CFGCONV:
-i
Identifies the instance name of the previous agent.
The default instance name for the OS/390 agent is Mvs.CAIAGENT or
Mvs.SYSVIEW, depending on your installation. The default instance name
for the CICS agent is Cics.RegionName.
Note: This flag is required for the CICS and OS/390 agent migration.
-c
Specifies the file name for the newly generated configuration set.
By default, the configuration set file is stored in the Agent Technology HFS
file system. The full path is
$AGENTWORKS_DIR/agents/config/CfgZOSAGENT.cfg for the z/OS system
agent and $AGENTWORKS_DIR/agents/config/CfgCICSAGENT.cfg for the
CICS agent.
-f
Specifies the full path name for the log file.
By default, the log file is stored in the Agent Technology HFS file system,
with the file name of
$AGENTWORKS_DIR/agents/log/CfgConver_instance.log.
-a
Appends configuration data to an existing configuration set.
Note: This flag is required if you are generating a configuration set for
multiple CICS regions or converting a USS agent configuration to the z/OS
system agent.
-u
Converts the USS agent configuration to a z/OS system agent
configuration set.
Install Unicenter Management Portal
On Windows platforms, you can install Unicenter MP using the Product Explorer
of the Unicenter NSM Installation DVD. On Linux and UNIX platforms, you can
install Unicenter MP using the Unicenter NSM Installation Wizard.
See the Unicenter Management Portal Implementation Guide for complete
installation information.
Chapter 6: Installation 163
Install Unicenter for Pocket PC
Install Unicenter for Pocket PC
Perform the Unicenter for Pocket PC installation from a host PC using the
Microsoft ActiveSync Add/Remove Programs utility. You must establish a
working partnership between the Pocket PC and a Windows workstation before
installing Pocket PC.
To install Pocket PC
1.
Ensure that Microsoft ActiveSync is installed on the local Windows
workstation and that a partnership is established with the Pocket PC device
where you want to install Unicenter NSM. Ensure that the device is
connected to ActiveSync before proceeding.
2.
Launch the Unicenter Product Explorer, select the Unicenter for Pocket PC
option, and click Install.
The Unicenter Product Explorer appears.
If Microsoft ActiveSync is installed and a device is connected, the following
dialog may appear.
Note: If a device is not currently connected, Unicenter for Pocket PC
automatically installs the next time a device connects to ActiveSync.
3.
Click Yes and follow the prompts on both the Windows workstation and the
target Pocket PC device.
4.
Set the Timeout value in seconds. The default is 60.
5.
Click OK in the upper-right corner to save these settings.
164 Implementation Guide
Installation of Unicenter Management for MOM
Installation of Unicenter Management for MOM
The installation of Unicenter Management for MOM (MOM Management)
involves the following sequence of tasks:
1.
Make sure your network conforms to prerequisites.
2.
Set up user accounts for installation, MOM Discovery, and collecting
information from MOM.
3.
Install MOM Management.
4.
(Optional) Run MOM Discovery.
Note: Unicenter NSM provides integration kits to both of Microsoft's
management applications, Microsoft Operations Manager (MOM) and System
Center Operations Manager 2007 (SCOM). Although the integrations to MOM
and SCOM can coexist on the same management server, each one integrates
only with its Microsoft counterpart.
Prerequisites for MOM Management Installation
The Unicenter NSM Manager where you install MOM Management must meet
the following requirements:
■
The operating system must be Windows 2003 Server.
■
WorldView, Event Management, and Unicenter MCC must be installed.
■
Microsoft Operations Manager (MOM) and the servers it monitors must be
in the same Windows domain.
■
The MOM database must be on a different server because of SQL
configuration differences.
■
The node running the Unicenter NSM integration with MOM must be in the
local Administrators group on the node where MOM is running.
Note: See the Unicenter Management for MOM readme on the installation DVD
for any other system requirements.
Chapter 6: Installation 165
Installation of Unicenter Management for MOM
Install Unicenter Management for MOM
Unicenter Management for MOM (MOM Management) lets you manage
Microsoft Operations Manager (MOM) alerts from Unicenter NSM. Install MOM
Management after you install Unicenter NSM.
Note: After the installation, you are prompted to perform MOM Discovery. Do
this only if you have recently run Discovery on the MOM network. Otherwise,
the discovery will not find any MOM servers or managed PCs. You can always
run MOM Discovery later.
To install MOM Management
1.
Log on to the Unicenter Manager, and insert the Unicenter NSM installation
DVD.
The Unicenter Product Explorer appears.
Note: The user must be an administrator with the privilege “Act as part of
the operating system.” See Set Up an Account for Installation and
Discovery in the chapter “Pre-Installation Tasks.”
2.
Expand Unicenter for Windows, Post Installation Utilities.
A list of utilities appears.
3.
Double-click Management for Microsoft Operations Manager and answer
the prompts.
A window asks for the account that will collect information from MOM.
4.
Enter a domain, user name, and password, and click Next.
Note: The user must be an administrator with the privilege “Log on as a
service.” See Set Up the MOM Management Runtime Account in the
chapter “Pre-Installation Tasks.”
Unicenter Management for MOM is installed.
5.
(Optional) Run MOM Discovery by verifying the domain, user name, and
password, and clicking Next. See Run MOM Discovery in the chapter “PostInstallation and Configuration.”
MOM entities are classified as MOM servers or MOM managed PCs in the
MDB.
166 Implementation Guide
Installation of the CA System Center Operations Manager Integration
Installation of the CA System Center Operations Manager
Integration
The installation of the CA System Center Operations Manager Integration
(SCOM Integration) involves the following sequence of tasks:
1.
Make sure your network conforms to prerequisites.
2.
Set up user accounts for installation, SCOM Discovery, and collecting
information from SCOM.
3.
Install Microsoft System Center Operations Manager Console Client from
the SCOM media.
4.
Install the SCOM Integration.
5.
(Optional) Run SCOM Discovery.
Note: Unicenter NSM provides integration kits to both of Microsoft's
management applications, Microsoft Operations Manager (MOM) and System
Center Operations Manager 2007 (SCOM). Although the integrations to MOM
and SCOM can coexist on the same management server, each one integrates
only with its Microsoft counterpart.
Prerequisites for the SCOM Integration Installation
The Unicenter NSM Manager where you install the SCOM Integration must
meet the following requirements:
■
The operating system must be Windows 2003 Server.
■
WorldView, Event Management, and Unicenter MCC must be installed,
either on the same server or in the same Windows domain.
■
The Microsoft System Center Operations Manager Console Client must be
installed where you install SCOM Integration.
■
If SCOM Integration is not on the same server as the Unicenter NSM
Manager, a Worldview Client and Event Agent must be installed where you
install SCOM Integration.
■
Microsoft System Center Operations Manager (SCOM) and the servers it
monitors must be in the same Windows domain.
■
The SCOM database must be on a different server because of SQL
configuration differences.
Note: See the SCOM Integration readme on the installation DVD for any other
system requirements.
Chapter 6: Installation 167
Installation of the CA System Center Operations Manager Integration
Install the SCOM Integration
The CA System Center Operations Manager Integration (SCOM Integration)
lets you manage Microsoft System Center Operations Manager (SCOM) alerts
from Unicenter NSM. Install the SCOM Integration after you install Unicenter
NSM.
Note: After the installation, you are prompted to perform SCOM Discovery.
You may do so at that time or run SCOM Discovery later. It is not required to
first run Discovery on the SCOM network.
To install SCOM Integration
1.
Log on to the Unicenter Manager, and insert the Unicenter NSM installation
DVD.
The Unicenter Product Explorer appears.
Note: The user must be an administrator with the privilege "Act as part of
the operating system." See Set Up an Account for SCOM Installation and
Discovery in the chapter "Pre-Installation Tasks."
2.
Expand Unicenter for Windows, Post Installation Utilities.
A list of utilities appears.
3.
Double-click CA System Center Operations Manager Integration and
answer the prompts.
A window asks for the account that will collect information from SCOM.
4.
Enter a domain, user name, and password, and click Next.
Note: The user must be an administrator with the privilege "Log on as a
service." See Set Up the SCOM Integration Runtime Account in the chapter
"Pre-Installation Tasks."
5.
(Optional) Run SCOM Discovery by verifying the domain, user name, and
password, and clicking Next. See Run CA System Center Operations
Manager Discovery in the chapter "Post-Installation and Configuration."
SCOM entities are classified as SCOM servers or SCOM managed PCs in the
MDB.
168 Implementation Guide
Install Unicenter Cisco Integration
Install Unicenter Cisco Integration
Unicenter NSM integration for Cisco provides enhancements to the generic
Cisco class that is supplied with Unicenter NSM. It updates the Cisco classes
for both Cisco routers and switches.
This integration provides the object identifiers for each Cisco device, which
automatically lets Unicenter NSM discover Cisco devices and classify them into
a specific Cisco model. After Discovery, Unicenter NSM can display and
monitor these Cisco devices. In addition, you can create policy for each Cisco
device to customize how Unicenter NSM manages the device in WorldView.
To use Unicenter Cisco Integration, you must have access to Cisco's nmidb file
that contains device model information. The file is accessible through your
cisco.com login privileges, or from your CiscoWorks product CD. You can
obtain a valid Cisco user account and password from your channel partner or
you can log a request on cisco.com.
Note: On Linux and UNIX platforms, Cisco Integration installation is part of
the installation interview and is located on the Post Installation Utilities
Component Selection window.
To install the Unicenter Cisco Device Integration on Windows
1.
Insert the installation DVD into the drive. The installation program starts
automatically.
The Unicenter Product Explorer appears.
2.
Expand the Post Installation Utilities folder.
3.
Click Cisco Integration, and then click Install.
A welcome screen appears.
4.
Click Next.
The installation wizard starts.
5.
Follow the installation wizard prompts, and click Finish to complete your
installation.
Chapter 6: Installation 169
Install TrapManager
To run a silent installation of the Unicenter Cisco Device Integration on
Windows, enter the following command:
msiexec.exe /qn /i “CA Unicenter NSM Cisco Integration.msi” [/lv* <log file>]
[PROPERTY=VALUE …]
For example:
msiexec.exe /qn /i “CA Unicenter NSM Cisco Integration.msi” /lv* “C:\ci.log”
INSTALLDIR=”C:\Program Files\CA\Unicenter NSM Cisco Integration”
where INSTALLDIR is the installation location for Cisco Integration.
To run a silent uninstall of the Unicenter Cisco Device Integration on Windows,
enter the following command:
msiexec.exe /qn /x “CA Unicenter NSM Cisco Integration.msi” [/lv* <log file>]
For example:
msiexec.exe /qn /x “CA Unicenter NSM Cisco Integration.msi” /lv* “C:\ci.log”
Install TrapManager
The TrapManager is a component of Unicenter NSM that lets you perform
sophisticated trap database and trap filter file management. You can use the
TrapManager to manage trap information and translation messages stored in
the Trap Database and trap filters stored in the trap filter file.
Note: On UNIX and Linux platforms, TrapManager installation is part of the
installation interview and is located on the Post Installation Utilities Component
Selection window.
To install the Unicenter NSM TrapManager on Windows
1.
Insert the installation DVD into the drive. The installation program starts
automatically.
The Unicenter Product Explorer appears.
2.
Expand the Post-Installation Utilities folder. Click TrapManager and then
click Install.
A welcome screen appears.
3.
Click Next.
The license agreement appears.
170 Implementation Guide
Install TrapManager
4.
Scroll to the end of the license agreement, accept the license agreement,
and click Next.
5.
Follow the installation wizard prompts.
6.
Click Finish to complete your installation.
To run a silent installation of the Unicenter NSM TrapManager on Windows,
enter the following command:
msiexec.exe /qn /i “CA Unicenter NSM TrapManager.msi” [/lv* <log file>]
[PROPERTY=VALUE …]
For example:
msiexec.exe /qn /i “CA Unicenter NSM TrapManager.msi” /lv* “C:\tm.log”
INSTALLDIR=”C:\Program Files\CA\Unicenter NSM TrapManager” XLATE=1 LOADDB=1
INSTALLDIR
Specifies the installation for TrapManager.
REMOTE
Specifies 0 for a local database or 1 for a remote database. The default is
0.
REPSERVERID
Specifies the server name for the remote database when REMOTE is set to
1.
REPSERVERID
Specifies the user name for the remote database when REMOTE is set to 1.
XLATE
When REMOTE is set to 0, specifies 0 to disable message translation for
traps and 1 to enable message translation for traps. The default is 1.
LOADDB
When REMOTE is set to 0, specifies 0 not to lead the default trap database
and 1 to load the default trap database. The default is 1.
To run a silent uninstall of the Unicenter NSM TrapManager on Windows, enter
the following command:
msiexec.exe /qn /x “CA Unicenter NSM TrapManager.msi” [/lv* <log file>]
For example:
msiexec.exe /qn /x “CA Unicenter NSM TrapManager.msi” /lv* “C:\tm.log”
Chapter 6: Installation 171
Install Unicenter Remote Monitoring
Install Unicenter Remote Monitoring
The installation for Unicenter Remote Monitoring lets you select which
components of Unicenter Remote Monitoring you want to install on a single
computer. We recommend installing the Administrative Interface (AI) on the
Unicenter Remote Monitoring agent computer. Additional Administrative
Interface-only installs can be performed on as many non-agent computers as
necessary. The AI can connect to any Unicenter Remote Monitoring agent in
your environment.
Important! We recommend that you install the Unicenter Remote Monitoring
agent on a dedicated computer for optimum performance. In addition, you
may be required to restart your computer during the installation procedure.
Therefore, you should exit all programs before beginning the Unicenter
Remote Monitoring installation procedure.
Install the Remote Monitoring Agent
Install Unicenter Remote Monitoring from the Unicenter Product Explorer on
your installation DVD.
To install the Remote Monitoring agent
1.
Expand the folder Unicenter for Windows.
The list of subheadings appears.
2.
Expand the entry for Post Installation Utilities.
A list of utilities appears.
3.
Select Remote Monitoring and click Install.
The Install Welcome dialog appears.
4.
Click Next.
The Install Type dialog appears.
5.
Select the Complete option to install the agent, the AI, tools, and icons.
6.
Click Next and follow the wizard prompts until finished.
7.
On the Congratulations dialog, select the “Yes, I want to launch the URM
Agent now” check box to immediately start the agent, and then click
Finish.
The agent starts as soon as the installation completes.
172 Implementation Guide
Install Unicenter Remote Monitoring
Install the Administrative Interface Only
You can install the AI alone on any Unicenter NSM computer. The steps to
install only the AI differ from the install of the agent. Begin from the Unicenter
Product Explorer on your installation DVD and complete the following
procedure.
To install the AI only
1.
Expand the folder Unicenter for Windows.
The list of subheadings appears.
2.
Expand the entry for Post Installation Utilities.
A list of utilities appears.
3.
Select Remote Monitoring and click Install.
The Install Welcome dialog appears.
4.
Click Next.
The Install Type dialog appears.
5.
Select the Custom option and click Next.
The “Choose the features Setup will install” dialog appears.
6.
Select the Administrative Interface and Icons check boxes.
The icons install to the same location as the Unicenter MCC icons, allowing
the Unicenter Remote Monitoring icons to display correctly with these
Unicenter NSM tools.
7.
Click Next and follow the wizard prompts until finished.
The first time you launch the newly installed AI, it will prompt you for the
name of the Unicenter Remote Monitoring agent to which you want to connect.
Successive launches automatically connect to the last viewed agent.
You can customize the command line of the AI to include the name of the
Unicenter Remote Monitoring agent to which you want to connect. If you have
installed multiple agents, this will let you launch the AI specifically for the
targeted agent. Use the following command:
install drive:\installdir\sagui.exe /A agentname
Note: If the AI and the Unicenter Remote Monitoring agent are installed on
the Unicenter NSM server, skip the following information regarding remote
installations.
Chapter 6: Installation 173
Install the SPECTRUM Integration Kit
After you have installed the AI, you can start discovering resources.
Note: For information about discovering your resources through Unicenter
Remote Monitoring, see the Unicenter Remote Monitoring online help or the
chapter "Monitoring Your Enterprise" in the Administration Guide.
Install the SPECTRUM Integration Kit
Unicenter NSM integration with SPECTRUM is achieved using the SPECTRUM
Integration Kit. After installing the SPECTRUM Integration Kit, you can do the
following from Unicenter NSM administrative interfaces:
■
Monitor states of SPECTRUM objects
■
View and manage SPECTRUM device model alarms
■
View SPECTRUM device model alarms as events in the Event Console
■
Access the SPECTRUM OneClick Console from the MCC or 2D Map
The SPECTRUM Integration Kit version 3.5 is included with Unicenter NSM
r11.2, and you can install it using the Unicenter Product Explorer. Use version
3.5 if you want to integrate Unicenter NSM r11.2 with versions 7.1 or 8.x of
SPECTRUM. To integrate with SPECTRUM 9.0, you must use the SPECTRUMNSM Integration Kit version 4.0, which is located on the SPECTRUM 9.0
installation DVD. For more information about using version 4.0 of the kit, see
the CA Unicenter NSM SPECTRUM Integration Guide shipped with SPECTRUM.
The SPECTRUM Integration Kit uses existing Unicenter NSM and SPECTRUM
architectures to establish a communication channel between the two products.
After installation, SPECTRUM forwards alarms to Unicenter NSM using the
SPECTRUM UnicenterNotifier. The SPECTRUM UnicenterNotifier forwards the
alarms to Unicenter NSM using either SNMP traps or the Event Agent.
Before you install the SPECTRUM Integration Kit, you must discover the
SPECTRUM server that you want to integrate with and decide what method
you want to use to forward SPECTRUM alarms to Unicenter NSM. The topics
that follow provide information about these pre-installation tasks and the
installation procedure.
Note: For detailed information about how the SPECTRUM integration works,
the complete installation and deployment process, and post-installation
configuration, see the Administration Guide.
174 Implementation Guide
Install the SPECTRUM Integration Kit
Discovery of SPECTRUM Server
Before you install the SPECTRUM Integration Kit, you must ensure that the
SpectroSERVER has been discovered by Unicenter NSM. This server must have
a representative object in WorldView for the integration to work.
For the integration to function correctly, the SpectroSERVER server object
must be classified as one of the following classes after Unicenter NSM
discovers it:
■
Windows2000_Server
■
Windows_NetServer
■
WindowsXP
■
Windows2000
How to Use the Event Agent to Forward SPECTRUM Alarms
By default, the SPECTRUM UnicenterNotifier uses SNMP traps to forward alerts
to Unicenter NSM. However, you can use the Event Agent to forward alerts to
Unicenter NSM as events using message policy if you want a more reliable
method of delivery. The coldstart.bat, SetScript, and ClearScript files make
use of the cawto command to send the alarms. When the Event Manager
receives the alarms from UnicenterNotifier, it forwards them to the DSM,
where they are classified and available to view using Unicenter NSM interfaces.
To use the Event Agent to forward alerts to Unicenter NSM, complete the
following process before installing the SPECTRUM Integration Kit:
1.
Install the Event Agent on the SPECTRUM host server.
2.
Configure the NSM Event Manager to allow command execution by the
Administrator user from the SPECTRUM server. (see page 176)
This gives the process running UnicenterNotifier on the SPECTRUM server
permission to run commands using Event Management.
3.
Recycle opr.
4.
Ensure that the Unicenter NSM Event Manager server has the Agent
Technology common service installed and is configured to enable Event
Management to forward alarm messages to the local DSM.
Note: For more details about the Event Agent method of communication,
including the format of event messages and examples of different types of
event messages, see the Administration Guide.
Chapter 6: Installation 175
Install the SPECTRUM Integration Kit
Configure the Unicenter NSM Event Manager to Receive Event Agent Alarms
If you want to use the Event Agent to forward alarms from the SPECTRUM
server to Unicenter NSM, you must configure the Event Manager to allow
command execution initiated by the user on the SPECTRUM server running the
UnicenterNotifier process.
To configure the Event Manager to receive Event Agent alarms from
the SPECTRUM server
1.
Enter the following command from a command prompt:
caugui settings
The EM Settings dialog appears.
2.
Click the Event Management tab, scroll down to the 'Users authorized to
issue commands' entry, double-click the Setting field for this entry, and
append the field with the following:
, <SpectrumServerName>\Administrator
This gives the SPECTRUM Administrator user on the SPECTRUM server
running the UnicenterNotifier authorization to issue the Event Management
commands necessary to forward SPECTRUM alarms.
3.
Close the EM Settings dialog, and run the following commands from a
command prompt:
unicntrl stop opr
unicntrl start opr
The Event Management process is reloaded, and the authorization change
takes effect.
176 Implementation Guide
Install the SPECTRUM Integration Kit
Install the SPECTRUM Integration Kit
Install the SPECTRUM Integration Kit from the Unicenter Product Explorer on
the Unicenter Manager that you want to integrate with SPECTRUM. Complete
installation of the kit requires a DSM, WorldView Manager, and Event Manager
to be present on the Unicenter NSM server. If one of these components is not
present, you can complete a distributed installation by also installing the kit on
the server that contains the component that is missing from the original
server.
Note: The following procedure describes how to install the Unicenter NSM
portion of the SPECTRUM Integration Kit. You also must install the "SPECTRUM
UnicenterNotifier Installation" piece of the kit on the primary SPECTRUM server
to complete the integration. For more information about the complete
installation process, configuring the SPECTRUM integration, and different
deployment options, see the Administration Guide.
To install the SPECTRUM Integration Kit on a Unicenter NSM server
1.
Insert the installation DVD into the drive. The installation program starts
automatically.
The Unicenter Product Explorer appears.
2.
Expand the Post-Installation Utilities folder. Click Spectrum Integration Kit
and then click Install.
A welcome screen appears.
Chapter 6: Installation 177
Install the SPECTRUM Integration Kit
3.
Click Next.
The Setup Type screen appears.
178 Implementation Guide
Install the SPECTRUM Integration Kit
4.
Select Unicenter NSM Integration with Spectrum and click Next.
The integration begins to install. A dialog appears asking whether you
want to enable the ability to clear SPECTRUM alarms in Unicenter NSM.
Chapter 6: Installation 179
Install the SPECTRUM Integration Kit
5.
Click Yes or No, depending on if you want to be able to clear SPECTRUM
alarms in Unicenter NSM.
The SPECTRUM Main Location Server screen appears.
180 Implementation Guide
Install the SPECTRUM Integration Kit
6.
Enter the name of the SPECTRUM Main Location server in the Server field,
and click Next.
The Event Trap Daemon Setup screen appears.
Chapter 6: Installation 181
Install the SPECTRUM Integration Kit
7.
Enter the name of the SpectroSERVER you want to use for the SPECTRUM
integration in the Server field, and click Next.
The OneClick Launch Setup screen appears.
8.
Enter the name of the OneClick webserver you want to use when
launching SPECTRUM OneClick. Also, enter the port number (separated
from the server name by a colon) if the port you are using for OneClick is
different than 80 (For example: OneClickServer:port). Click Next.
A dialog appears asking if it is safe to reset the DSM to enable the DSM
policy installed by the SPECTRUM Integration Kit.
9.
Click Yes.
The DSM resets, and a dialog appears asking for permission to issue the
awservices start command to restart the DSM.
182 Implementation Guide
Install the SPECTRUM Integration Kit
10. Click Yes.
The DSM restarts, and a dialog appears stating one of the following:
■
If all required components are present on the Unicenter NSM server,
the message informs you that all necessary files for the Unicenter NSM
side of the integration have been installed.
■
If all required components are not present on the Unicenter NSM
server, the message informs you of the component that did not install.
You must install the SPECTRUM Integration Kit again on a server that
contains the missing component to complete a distributed installation.
Click OK.
The Installation Complete screen appears.
11. Click Finish.
The installation is complete. The SPECTRUM integration kit files are
installed in the following location on the Unicenter NSM server:
C:\Program Files\CA\SPECTRUM Integration v3.5 with Unicenter NSM
To complete the SPECTRUM integration, you must also install the SPECTRUM
UnicenterNotifier Installation component on the appropriate SPECTRUM server.
Chapter 6: Installation 183
Install the SPECTRUM Integration Kit
To install the SPECTRUM Integration Kit on a SPECTRUM server
1.
Insert the installation DVD into the drive. The installation program starts
automatically.
The Unicenter Product Explorer appears.
2.
Expand the Post-Installation Utilities folder. Click Spectrum Integration Kit
and then click Install.
A welcome screen appears.
184 Implementation Guide
Install the SPECTRUM Integration Kit
3.
Click Next.
The Setup Type screen appears.
4.
Select SPECTRUM UnicenterNotifier Installation and click Next.
The integration begins to install. If CA Event Management Agent is
installed on this system, a dialog appears asking whether you like to
forward SPECTRUM events through the Event Agent.
Chapter 6: Installation 185
Install the SPECTRUM Integration Kit
If Yes, the installation is complete. If No, the DSM Server Setup dialog
appears.
5.
Enter the Server Name and click Next.
The Installation Complete screen appears.
186 Implementation Guide
Uninstall Individual Components
6.
Click Finish.
The installation is complete. The SPECTRUM Integration Kit is installed on
the SPECTRUM server.
For more information about configuring and deploying the SPECTRUM
integration, see the Administration Guide.
Uninstall Individual Components
The following topics provide instructions for uninstalling individual components
from your system.
Uninstall Unicenter NSM
You can uninstall Unicenter NSM from Windows, Linux, or UNIX platforms
using the following procedures.
Take great care in deciding whether to uninstall the MDB, as it may be shared
by other local products and by other applications across the network that
might not be active at any particular moment. You should uninstall the MDB
only after making sure you have no other products installed that are
dependent on this MDB on this particular server. If you decide to uninstall
Unicenter NSM on a Linux or UNIX platform, you may uninstall Ingres along
with other selected components.
To uninstall Unicenter NSM on a Windows platform
1.
Select Start, Settings, Control Panel, Add or Remove Programs.
The Add or Remove Programs window opens.
2.
Select Unicenter NSM and click Remove.
Unicenter NSM is removed from the server.
3.
Restart the computer.
The uninstallation completes.
Notes: The caunint ID is removed during an uninstall only if the ID was
created during the installation of Unicenter NSM. The caunint ID is the
administrator level ID under which Unicenter Enterprise Management services
run. If the installation of Unicenter NSM you are removing was an upgrade to a
previous release, the caunint ID is not removed.
Chapter 6: Installation 187
Uninstall Individual Components
If you decide to uninstall Unicenter NSM, you will need to uninstall the MDB,
the MDB users such as the nsmadmin ID, and the entire DBMS manually
afterwards. Although these may listed as components for uninstall by the
product, selecting them for uninstall only results in their deregistration from
the product. The physical items will remain on the machine for use by any
other products, whether local or remote. The DBMS itself can be removed by
going to the Windows Add or Remove Control Panel applet or by any other
mechanism supported by the underlying DBMS.
For additional information about removing Microsoft SQL Server on Windows
platforms, see the Microsoft SQL Server online books.
For additional information about removing Ingres on Windows platforms, see
the Ingres for Windows Getting Started.
To uninstall Unicenter NSM on a Linux or UNIX platform
1.
Run setupNSM from the Unicenter NSM Installation DVD.
The Installer window appears.
2.
Choose Uninstall Unicenter NSM and click Update.
An Update Options screen appears.
3.
Select Remove All to uninstall all of Unicenter NSM or Remove
Components to uninstall individual components.
Notes: The uninstall process creates a log to record the progress of the
uninstall. One of two logs is created depending whether you choose Remove
All or Remove Components. The log created when removing all of Unicenter
NSM is /tmp/CAInstaller.UnicenterNSM.deinstall.log. The log created when
removing individual components is
/opt/CA/installer/log/UnicenterNSM.update.log.
For additional information about removing Ingres on Linux or UNIX platforms,
see the Ingres for Linux Getting Started.
Microsoft SQL Server is not supported on Linux or UNIX platforms.
188 Implementation Guide
Uninstall Individual Components
Uninstall CA Common Discovery
If you do not want to use the CA Common Discovery program, you can
uninstall it.
To uninstall CA Common Discovery
1.
Select Start, Settings, Control Panel, Add or Remove Programs.
The Add or Remove Programs window opens.
2.
Select CA Common Discovery, and click Remove.
CA Common Discovery is uninstalled.
Uninstall Unicenter for Pocket PC
If you no longer need to manage your Pocket PC from Unicenter NSM, you can
uninstall Unicenter for Pocket PC.
To remove Unicenter for Pocket PC from your Pocket PC
1.
From the Pocket PC Start menu, select Settings.
The Settings dialog appears.
2.
Select the System tab, and launch Remove Programs.
The Remove Programs dialog appears.
3.
Select Computer Associates Unicenter NSM, and click Remove.
Unicenter NSM is removed from the Pocket PC.
Uninstall Unicenter Management for MOM
If you no longer need to manage Microsoft Operations Manager (MOM) alerts
from Unicenter NSM, you can uninstall MOM Management.
To uninstall Unicenter Management for MOM using the Control Panel
1.
Log on to the Unicenter Manager, and choose Start, Settings, Control
Panel, Add or Remove Programs.
The Add or Remove Programs window opens.
2.
Select Unicenter Management for MOM, and click the Remove button.
MOM Management is deleted from the server.
3.
Restart the computer.
Chapter 6: Installation 189
Uninstall Individual Components
Uninstall the Integration with System Center Operations Manager
If you no longer need to manage Microsoft System Center Operations Manager
(SCOM) alerts from Unicenter NSM, you can uninstall the SCOM Integration.
To uninstall SCOM Integration using the Control Panel
1.
Log on to the Unicenter Manager, and choose Start, Settings, Control
Panel, Add or Remove Programs.
The Add or Remove Programs window opens.
2.
Select CA Unicenter NSM Integration for System Center Operations
Manager, and click the Remove button.
The SCOM Integration is deleted from the server.
3.
Restart the computer.
Uninstall Unicenter Cisco Integration
When you uninstall Cisco Integration, Cisco device information is not removed.
You must manually remove any devices you no longer want to support before
you uninstall. See the Cisco Integration online help for more information.
To uninstall Cisco Integration
1.
Log on to the Unicenter Manager, and select Start, Settings, Control Panel,
Add or Remove Programs.
The Add or Remove Programs window opens.
2.
Select Unicenter Cisco Integration, and click the Remove button.
Unicenter Cisco Integration is deleted from the server.
190 Implementation Guide
Chapter 7: Post-Installation and
Configuration
This section contains the following topics:
Reghost, Reinstall, Unplug Unicenter NSM Components (see page 191)
Configure Active Directory Enterprise Manager (see page 191)
Configure Data Scoping (see page 192)
Configure and Maintain CAICCI (see page 195)
Configure Remote Monitoring (see page 219)
Configure Unicenter Management Portal (see page 220)
Configure Unicenter for Pocket PC (see page 220)
Configure the Unicenter WMI Agent (see page 221)
Configure Monitoring for z/OS Interface (see page 221)
Run Unicenter Management for MOM Discovery (see page 223)
Run CA System Center Operations Manager Discovery (see page 224)
Access Unicenter NSM Web Applications (see page 225)
Enable Unicenter NSM Integration with eHealth Reports (see page 242)
Reghost, Reinstall, Unplug Unicenter NSM Components
If you need to reghost, reinstall, unplug, or in any way shut down or make
inaccessible a particular computer in your deployment, make certain to
implement appropriate precautions for any other computers that depend on
the computer. One such precaution can be to temporarily pause their services.
For example, if you need to make the MDB or other management components
inaccessible, remote computers may fail when they try to perform their
function of connecting to the MDB or component.
Product reinstallations and upgrades are particularly vulnerable. If remote
applications attempt to connect to any one or more components on the node
you are reinstalling, both the remote application as well as the local
installation can fail.
Configure Active Directory Enterprise Manager
The Active Directory Enterprise Manager (ADEM) only automatically finds the
forest of which the ADEM server is a member. If you have more than one
forest you must use the Active Directory Enterprise Manager Connection
Settings Utility utility in order for the ADEM to monitor it. See the Inside Active
Directory Management guide and the utility help for further information.
Chapter 7: Post-Installation and Configuration 191
Configure Data Scoping
Configure Data Scoping
Data Scoping is a security mechanism that Unicenter NSM uses to protect the
WorldView components from unauthorized access. Data Scoping is
automatically installed with WorldView
To configure or implement Data Scoping involves writing Data Scoping rules
that filter or protect the data.
To implement Data Scoping, you must define a set of Data Scoping rules. Each
set of Data Scoping rules governs data access only for the MDB for which they
are defined. If more than one MDB exists on a computer, each MDB has its
own set of autonomous rules. Further, if a user of a single computer connects
to more than one MDB, each MDB has its own independent set of Data Scoping
rules for that user.
Data Scoping rules can control the type of access that is used. You can govern
all access to a particular data type, or you can give a specific user ID read
access without giving that same user update, create, or delete capabilities.
You can activate and deactivate Data Scoping rules according to the current
date at the time of access by defining a Data Scoping rule with an effective
date or an expiration date. If Enterprise Management is installed, you can also
activate and deactivate a Data Scoping rule by specifying that it use a
particular calendar.
By default, users connected to the MDB have full access to objects until Data
Scoping rules are generated to deny particular types of access. You can define
class-level rules or object-level rules. Class-level rules scope data objects
using their data classification. Object-level rules let you explicitly filter data
objects on an object-by object basis using the object's instance-level
properties.
192 Implementation Guide
Configure Data Scoping
Configure Data Scoping for Linux and UNIX
Configure data scoping for Linux and UNIX to define users and give or remove
their access to the MDB.
To configure Data Scoping for Linux and UNIX
1.
To initialize Data Scoping, run:
$CAIGLBL0000/wv/bin/wvscpini.exe -r database
where database is the name of the MDB on which you want to activate
Data Scoping.
Remote MDBs are not supported; therefore, the database name should be
that of the local MDB.
Note: Only root can execute this command and the commands that follow.
When you execute this command after connecting to the repository,
applications already connected do not have Data Scoping rules enforced
until you restart the applications.
2.
Recycle WorldView.
3.
To define users, run the following command:
$CAIGLBL0000/bin/cautil
Note: To use the cautil utility to define users, Security Management must
be installed.
See the CA Reference for more information about the cautil utility.
4.
To give users access to the MDB, run the following command:
$CAIGLBL0000/wv/scripts/add_ingres_user
5.
To remove a user's access to the Ingres database, run the following
command:
$CAIGLBL0000/wv/scripts/delete_user_ingres
6.
To define Data Scoping rules and associate rules with users, run the
following command:
$CAIGLBL0000/wv/bin/scputil.exe
See the Data Scoping topics in the MCC help for additional information. See
the CA Reference for more information about the scputil executable.
If, after activating and using Data Scoping, you want to deactivate it, run the
following command:
$CAIGLBL0000/wv/bin/wvscpdel.exe
Chapter 7: Post-Installation and Configuration 193
Configure Data Scoping
Configure Data Scoping for Windows
Before you can begin to use the Data Scoping Rule Generator in Windows, you
must complete the following configuration procedure.
To configure Data Scoping for Windows
1.
Activate the Data Scoping utility and create the Data Scoping classes by
executing the following command:
wvscpini.exe
Note: Only administrators can execute this command and the commands
that follow on Data Scoping functions. When you execute this command
after connecting to the MDB, applications already connected do not have
Data Scoping rules enforced until you restart the applications.
2.
Execute the following command to start the Data Scoping Rule Generator
GUI and create new rules or update existing rules:
datargen.exe
3.
If, after activating and using Data Scoping, you want to deactivate it,
execute the following command:
wvscpdel.exe
For additional information, see the Data Scoping topics in the MCC help and in
the Administrator Guide.
Create Data Scoping Rules Using the MCC
You use the Data Scope Rule Editor to create Data Scoping rules to protect the
MDB object data from unauthorized access, or to filter large amounts of data
into smaller subsets of data for a group or user.
Note: The administrator must be authorized to create or update rules for the
specific class.
To create Data Scoping rules
1.
Open the Management Command Center, click the left pane menu and
select Class Specification.
The Class Specification view appears.
2.
Select the ManagedObject class or Association class for which you want to
create a rule. You can create Data Scoping rules only for these two classes
and subclasses of these classes.
The class is highlighted.
194 Implementation Guide
Configure and Maintain CAICCI
3.
Right-click New, Rule from the context menu.
The Data Scope Rule Editor appears. A default Data Scoping rule for the
class is created that allows full access to class objects for all users. You
can modify the rule and make it more specific. For more information, see
the MCC help.
Configure and Maintain CAICCI
The acronym CAICCI stands for CA Common Communications Interface. This
topic explains briefly how to configure, manage, and test an important
communication component that runs on Unicenter NSM and Unicenter Job
Management. The topic describes how to test CAICCI communication between
Windows, UNIX/Linux, HP NonStop, OpenVMS, and a job management
manager.
CAICCI Overview
CAICCI is the Common Communications Interface for Unicenter NSM and
Unicenter Job Management, and is essentially the glue among the various
Enterprise Management components across a heterogeneous environment.
CAICCI uses and runs on top of TCP/IP.
CAICCI is implemented as three processes or daemons:
■
CAICCID is referred to as the main CAICCI daemon because it starts first
and builds the necessary CAICCI resources. It is responsible for starting
and stopping the other two processes.
■
CCICLND is referred to as the clean daemon because its responsibility
includes the maintenance of the CAICCI IPC resources.
■
CCIRMTD is the remote daemon process that is responsible for
transmission of data across the network.
For a Unicenter job manager to communicate with the Unicenter Universal Job
Management Agent on a target machine, you need to configure CAICCI on
each platform. This topic provides step-by-step instructions for configuring
CAICCI on the following platforms:
■
Windows
■
UNIX
■
HP NonStop
■
OpenVMS
■
OS/400
■
the mainframe
Chapter 7: Post-Installation and Configuration 195
Configure and Maintain CAICCI
LOCAL and REMOTE Statements
The format is the same for the LOCAL and REMOTE statements. The brackets
are applied in the syntax example to separate the parameter names.
Otherwise, the parameters are delimited by a space.
LOCAL and REMOTE statements have the following format:
LOCAL = <TCP/IP name><CCI name><buffersize><startup options><alias options><port
options><retry interval>
REMOTE = <TCP/IP name><CCI name><buffersize><startup options><alias options><port
options><heartbeat options><retry interval>
TCP/IP name
Specifies either an IP address or a name that is used as input to a name
service to retrieve an IP address. You may use the TCP/IP name with the
PING command to determine whether a remote connection is live. The
default is the TCP/IP host name. It does not require a logical connection to
the CCI name.
CCI name
Specifies the logical name CAICCI uses to identify this host. This is the
system name, which may or may not be the same as the IP hostname.
This name may be as long as 64 characters, but an alias must be used for
names greater than eight characters.
For the REMOTE statement that defines the mainframe, the CAICCI name
is the value specified by SYSID (xxxx) in the //ENFPARMS DD statement.
This value is also on the PROTOCOL statement in //ENFPARMS.
buffersize
Specifies the maximum buffer CAICCI will receive or send over the socket,
a value used for segmenting the data transfer. Each side of the connection
may have this set to a different value, between 1024 and 32768. The
lesser of the two values will be used. It is generally not necessary to alter
this field.
Important! Contact CA Customer Support before changing the buffer
size.
startup options
Tells ccirmtd (the CAICCI remote daemon) whether to initiate a
connection-sometimes you may want only one side to initiate the
connection. Not having the server start connections eliminates a
succession of messages when CAICCI is recycled. STARTUP tells CAICCI to
attempt a remote connection when activated, whereas NOSTART implies
that the remote system will be initiating the connection to the node.
196 Implementation Guide
Configure and Maintain CAICCI
alias options
Specifies an optional alias name used to differentiate multiple remote
computers having exactly the same first eight characters (when their host
names exceed eight characters).It specifies that, for hosts with a
hostname greater than eight characters, this name is used for internal
CAICCI structures. This alias need not appear in DNS or IP host file. It
must be unique and consistent across nodes.
When an alias is used on the LOCAL line for a host with a name greater
than eight characters, all hosts to which it will be connected must have a
REMOTE line for this host with this same alias defined. The format is
<ALIAS=aliasname>.
port options
Allows you to specify an alternate port for this specific connection only.
Sometimes you may have two groups of hosts. One may still use the old
7000 port and the new ones may use the new 1721 port. Any host from
the first group wishing to communicate with the second group must be
made aware that the connection should be made to a different port. The
format is PORT=1721. Do not change this value.
heartbeat options
Specifies whether the CAICCI remote heartbeat feature is enabled. The
heartbeat feature detects connection loss with the remote node if the
remote node terminates the connection without notification. The format to
enable the heartbeat feature is HEARTBEAT=YES. The format to disable
the heartbeat feature is HEARTBEAT=NO.
You can also define the heartbeat functionality by using environment
variables as follows.
On Linux or UNIX:
CAI_CCI_RMTHEARTBEAT
When this variable is set to 1, the heartbeat option is enabled to all
the nodes listed in the ccirmtd.prf file. However, explicitly setting the
option in the ccirmtd.prf file takes precedence over the global flag. The
variable needs to be unset to turn it off after being set.
CAI_CCI_HBTIMEOUT
By default, the wait time for an acknowledgement to ping from the
remote node is 30 seconds. You can alter this value by setting the
variable to a desired number of seconds. The minimum and maximum
values allowed are 15 and 45 seconds. The value defaults to 30
seconds if any other value is set.
Chapter 7: Post-Installation and Configuration 197
Configure and Maintain CAICCI
On Windows:
CAI_CCIRMT_HEARTBEAT
When this variable is set to YES, the heartbeat option is enabled to all
the nodes listed in the ccirmtd.rc file. However, explicitly setting the
option in the ccirmtd.rc files takes precedence over the global flag.
CCIRMTPINGTIMEOUT
By default, the wait time for an acknowledgement to the ping from the
remote node is 30 seconds. You can alter this value by setting the
variable to a desired number of seconds. The minimum and maximum
values allowed are 15 and 45 seconds. The value defaults to 30
seconds if any other value is set.
You can set the variables using the Configuration Settings GUI (Options,
CCI Options tab) or from the command prompt by running the following
commands:
cautenv setopt CAI_CCIRMT_HEARTBEAT value
cautenv setopt CCIRMTPINGTIMEOUT value
retry interval
Determines how ccirmtd behaves if the connection is dropped and specifies
the number of seconds between retry connect attempts. The format is as
follows:
–
If x=0, ccirmtd will not retry the connection.
–
If x=-1, ccirmtd will start with a two second retry interval and double
after each unsuccessful retry attempt.
–
If x > 0, ccirmtd will wait n seconds between retry attempts.
Note: Retry interval is mainly used in conjunction with the nostart option
to allow the server to sit passively and wait for incoming connection
requests. If a client host goes down, the server will not attempt to
reconnect.
198 Implementation Guide
Configure and Maintain CAICCI
Basic Sample Configuration
Assume you have four systems, all with node names of eight characters or
less: NTSYS1, VMSSYS2, UNXSYS3, and HPNSTP4. The configuration file for
each system follows:
UNIX: CCIRMTD.PRF
LOCAL = UNXSYS3 UNXSYS3 32768 startup
REMOTE = NTSYS1 NTSYS1 32768 startup
REMOTE = VMSSYS2 VMSSYS2 32768 startup
REMOTE = HPNSTP4 HPNSTP4 32768 startup
Windows Manager: CCIRMTD.RC
LOCAL = NTSYS1 NTSYS1 32768 startup
REMOTE = UNXSYS3 UNXSYS3 32768 startup
REMOTE = VMSSYS2 VMSSYS2 32768 startup
REMOTE = HPNSTP4 HPNSTP4 32768 startup
OpenVMS: CCIRMTD.PRF
LOCAL = VMSSYS2 VMSSYS2 32768 startup
REMOTE = UNXSYS3 UNXSYS3 32768 startup
REMOTE = NTSYS1 NTSYS1 32768 startup
REMOTE = HPNSTP4 HPNSTP4 32768 startup
HP NonStop: CACCICFG.RMTPRF
LOCAL = HPNSTP4 HPNSTP4 32768 startup
REMOTE = UNXSYS3 UNXSYS3 32768 startup
REMOTE = NTSYS1 NTSYS1 32768 startup
REMOTE = VMSSYS2 VMSSYS2 32768 startup
Advanced Sample Configuration
In this configuration, assume that all of the host or system names are longer
than eight characters (OPENVMSSYS1, for example). The configuration files
would be as follows:
UNIX: CCIRMTD.PRF
LOCAL = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3
REMOTE = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1
REMOTE = VMSSYS2 OPENVMSSYS2 32768 startup ALIAS=VMSNOD2
REMOTE = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4
Windows Manager: CCIRMTD.RC
LOCAL = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1
REMOTE = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3
REMOTE = VMSSYS2 32768 OPENVMSSYS2 startup ALIAS=VMSNOD2
REMOTE = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4
Chapter 7: Post-Installation and Configuration 199
Configure and Maintain CAICCI
OpenVMS: CCIRMTD.PRF
LOCAL = VMSSYS2 OPENVMSSYS2 32768 startup ALIAS=VMSNOD2
REMOTE = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3
REMOTE = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1
REMOTE = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4
HP NonStop: CACCICFG.RMTPRF
LOCAL = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4
REMOTE = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3
REMOTE = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1
REMOTE = VMSSYS2 OPENVMSSYS2 32768 startup ALIAS=VMSNOD2
Configure CAICCI on Windows
During post-installation, you must configure CAICCI on every Windows
machine on which you have installed the Unicenter Universal Job Management
Agent (UJMA).
To configure CAICCI on Windows
1.
Attempt to ping the job manager node. If you cannot, modify the TCP/IP
setup on the Windows machine as well as on the job manager machine.
This may require a DNS entry or an entry in the Windows machine's
%SystemRoot%\system32\drivers\etc\hosts file for the job manager or
mainframe ENF node name.
2.
Issue the following command to verify that the Remote Server is installed:
ccicntrl
A series of messages appears indicating status. If the Remote Server is
installed and running, the following message appears:
Service "CA-Unicenter (Remote)", STATUS is "Running"
3.
Define a connection between job manager nodes and the UJMA machine.
To define it on the UJMA machine, use LOCAL and REMOTE statements in
the CAICCI configuration file, located at InstallPath\CAIUSER\ccirmtd.rc.
The LOCAL statement applies to the local computer, while any REMOTE
statements apply to the remote nodes that exchange information through
CAICCI. For an explanation of the syntax and parameters in the LOCAL
and REMOTE statements, see the section LOCAL and REMOTE Statements.
The definitions apply to both LOCAL and REMOTE statements.
200 Implementation Guide
Configure and Maintain CAICCI
LOCAL Statement Example
The following LOCAL statement example tells CAICCI that the TCP/IP
name of the local machine is NTSYS1 and that any remote system
wishing to communicate with this system can do so by referencing
NTSYS1 as the name. Any UJMA within the network can send and
receive messages to this system independent of hardware or
protocols, if it uses the name NTSYS1.
LOCAL = NTSYS1 NTSYS1 32768 STARTUP
REMOTE Statement Examples
The following REMOTE statement example tells CAICCI to attempt a
connection to 172.22.111.121 and to internally register MF01 as the
CCI name. Any Job Management Agent within the network can send
and receive messages to this system independent of hardware or
protocols, if it uses the name MF01.
REMOTE = 172.22.111.121 MF01 32768 STARTUP PORT=1721
The following REMOTE statement example tells CAICCI to attempt a
connection to the computer whose TCP/IP name is UNXSYS3 and
whose CCI name (machine name) is UNIXSERVER3, but also to allow
UJMA to send and receive messages using the alias UNX3.
REMOTE = UNXSYS3 UNIXSERVER3 32768 STARTUP ALIAS=UNX3
4.
If the Remote Server is not installed, issue the following command:
ccicntrl install rmt <path>
where path represents the location of the drive:\NSM\bin (installation
path\bin).
5.
Start the Remote Server if necessary. The Remote Server must be
running. To determine whether it is running, issue the following command:
ccicntrl
A series of messages appears indicating the status. If the Remote Server
is running, the following message is included:
Service "CA-Unicenter (Remote)", STATUS is "Running".
If the Remote Server is not running, issue the following command to start
it:
ccicntrl start rmt
If you modified the ccirmtd.rc file as described in Step 3, and the Remote
Server is still active, recycle the Remote Server by issuing the following
commands:
ccicntrl stop rmt
ccicntrl start rmt
Chapter 7: Post-Installation and Configuration 201
Configure and Maintain CAICCI
If the Unicenter service (or any other service that depends on CAICCI) is
running, stop it manually prior to stopping CAICCI with this command. If
you use the Windows Services Control Panel applet to stop the Remote
Server instead of using the ccicntrl stop command, you will see the list of
any dependent services.
6.
Issue the following command to verify that CAICCI has established
communications:
ccii
The following is an example of the output of this command:
Oid(SCHLAP2,CAI_OPR_SAFD
) Did( , ) type(L)
Oid(SCHLAP2,CAU9SET SetUp Mgr
Oid(SCHLAP2,SUBMITC Server
Oid(A44SENF,W410_SPAWN_SERVER
Oid(A44SENF,MVS_START_SERVER
Oid(A44SENF,CA7XE44 Server
) Did( , ) type(L)
) Did( , ) type(L)
) Did( , ) type(R)
) Did( , ) type(R)
) Did( , ) type(R)
Oid(A44SENF,BARRYNT2.A44SENFUL2 ) Did( , ) type(R)
Oid(A44SENF,CA7XE44 Job track ) Did( , ) type(R)
In this example, the lines with the A44SENF entries indicate that the
CAICCI connection has been made to a mainframe. SCHLAP2 is the
Windows machine where UJMA is installed.
The ccii command displays the CAICCI applications that are available. If
UJMA has not been started, no entries are displayed for the local machine.
Configure CAICCI on Linux or UNIX
During post-installation, you must configure CAICCI on every UNIX or Linux
machine where the Unicenter Universal Job Management Agent (UJMA) is
installed.
To configure CAICCI on Linux or UNIX
1.
Attempt to ping the job manager node. If you cannot, modify the TCP/IP
setup on the Linux or UNIX machine as well as on the job manager node.
This may require a DNS entry or an entry in the /etc/hosts file of the Linux
or UNIX machine for the job manager or mainframe ENF node name. (Note
the MVS host name.)
2.
Define a connection between job manager nodes and the UJMA machine.
To define it on the UJMA machine, use LOCAL and REMOTE statements in
the CAICCI configuration file, located at
$CAIGLBL0000/cci/config/local host/ccirmtd.prf.
202 Implementation Guide
Configure and Maintain CAICCI
LOCAL and REMOTE Statement Format
The LOCAL statement applies to the local Linux or UNIX computer,
while REMOTE statements apply to the remote nodes that exchange
information with CAICCI.
For an explanation of the syntax and parameters in the local and
remote statements, see the section LOCAL and REMOTE Statements.
The definitions apply to both LOCAL and REMOTE statements.
LOCAL Statement Example
The following example tells CAICCI that the TCP/IP name of the local
machine is UNXSYS3 and that any remote system that wants to
communicate with this system should reference UNXSYS3 as the
name. Any Job Management Agent within the network can send and
receive messages to this system independent of hardware or protocols
if it uses the name UNXSYS3.
LOCAL=UNXSYS3 UNXSYS3 32768 STARTUP
REMOTE Statement Examples
The following REMOTE statement example tells CAICCI to attempt a
connection to 172.22.111.123 and to internally register MF01 as the
CCI name. Any Job Management Agent within the network can send
and receive messages to this system, independent of hardware or
protocols, if it uses the name MF01.
REMOTE=172.22.111.123 MF01 32768 STARTUP PORT=1721
The following REMOTE statement example tells CAICCI to attempt a
connection to the computer whose TCP/IP name is NTSYS1 and whose
CCI name is WINNTSYS1, but also to allow any Job Management Agent
to send and receive messages using the alias NT1.
REMOTE=NTSYS1 WINNTSYS1 32768 STARTUP ALIAS=NT1
3.
Issue the following command to determine the status of the Remote
Server:
unifstat
A series of messages appears indicating the status of servers. If the
Remote Server is running, the following message is included:
CA-CCI Remote Server nnn
running
where nnn is the process ID of the Remote Server process.
4.
Start the Remote Server if necessary. If the Remote Server is not running,
issue the following command to start all processes including CAICCI:
unistart all
Chapter 7: Post-Installation and Configuration 203
Configure and Maintain CAICCI
If you modified the ccirmtd.prf file (Step 2), and the Remote Server is
active, issue the following command:
unicycle all
This command stops and starts all Unicenter processes.
5.
Issue the following command to verify that CAICCI has established
communications:
$CAIGLBL0000/cci/bin/ccii
The ccii command displays the CAICCI applications that are available. If
Unicenter services have not been started, no entries are displayed for the
local machine.
Following is an example of the output of this command:
Oid(SCHLAP2,CAI_OPR_SAFD
) Did( , ) type(L)Oid(SCHLAP2,CAU9SET SetUp Mgr
) Did( , ) type(L)
Oid(SCHLAP2,SUBMITC Server
) Did( , ) type(L)
Oid(A44SENF,W410_SPAWN_SERVER
Oid(A44SENF,MVS_START_SERVER
Oid(A44SENF,CA7XE44 Server
) Did( , ) type(R)
) Did( , ) type(R)
) Did( , ) type(R)
Oid(A44SENF,BARRYNT2.A44SENFUL2 ) Did( , ) type(R)
Oid(A44SENF,CA7XE44 Job track ) Did( , ) type(R)
In this example, the lines with the A44SENF entries indicate that the
CAICCI connection has been made to a mainframe. SCHLAP2 is the UNIX
machine where UJMA is installed.
Configure CAICCI on HP NonStop
During post-installation, you must configure CAICCI on every HP NonStop
machine on which you have installed Unicenter Universal Job Management
Agent (UJMA).
To configure CAICCI on HP NonStop
1.
Attempt to ping the job manager node. If you cannot, modify the TCP/IP
setup on the HP NonStop machine and on the job manager machine. This
may require a DNS entry or an entry in the HP NonStop machine's
$SYSTEM.ZTCPIP.HOSTS file for the job manager or mainframe ENF node
name. (Note the MVS host name.)
2.
Define a connection between job manager nodes and the UJMA machine.
To define it on the UJMA machine, use LOCAL and REMOTE statements in
CACCICFG.RMTPRF, the CAICCI configuration file.
204 Implementation Guide
Configure and Maintain CAICCI
LOCAL and REMOTE Statement Format
The LOCAL statement applies to the local computer. REMOTE
statements apply to the remote nodes that exchange information with
CAICCI. The LOCAL statement is automatically configured in the NSK
installation. The REMOTE event node can be optionally configured in
the NSK installation.
For an explanation of the syntax and each parameter in the LOCAL and
REMOTE statements, see the section LOCAL and REMOTE Statements.
The definitions apply to both LOCAL and REMOTE statement formats.
LOCAL Statement Example
The following LOCAL statement example tells CAICCI that the TCP/IP
name of the local machine is HPNSTP4 and that any remote system
that wants to communicate with this system can do so by referencing
HPNSTP4 as the name. Any Job Management Agent within the network
can send and receive messages to this system, independent of
hardware or protocols if it uses the name HPNSTP4.
LOCAL=NSK01 NSK01 31998 STARTUP
REMOTE Statement Examples
The following REMOTE statement example tells CAICCI to attempt a
connection to 172.22.111.125 and to internally register MF01 as the
CCI name. Any UJMA within the network can send and receive
messages to this system, independent of hardware or protocols if it
uses the name MF01.
REMOTE=172.22.111.125 MF01 31998 STARTUP PORT=1721
The following example tells CAICCI to attempt a connection to the
computer whose TCP/IP name is UNXSYS3 and whose CCI name is
UNIXSERVER3, but also to allow UJMA to send and receive messages
using the alias UNX3.
REMOTE=UNXSYS3 UNIXSERVER3 31998 STARTUP ALIAS=UNX3
3.
Determine the status of the Remote Server. The Remote Server must be
running. To determine whether it is running, issue the following command:
unifstat
A series of messages appears indicating the status of servers. If the
Remote Server is running, the following message is included:
CCI Remote Server nnn
running
where nnn is the process ID of the Remote Server process.
4.
Start the Remote Server if necessary. If the Remote Server is not running,
issue the following command to start all processes including CAICCI:
unistart all
Chapter 7: Post-Installation and Configuration 205
Configure and Maintain CAICCI
If you modified the ccirmtd.prf file (Step 2), and the Remote Server is
active, issue the following commands:
unishutdown all
unistart all
These commands stop and start all processes.
Configure CAICCI on OpenVMS
During post-installation, you must configure CAICCI on every OpenVMS
machine on which you have installed the Unicenter Universal Job Management
Agent (UJMA).
To configure CAICCI on OpenVMS
1.
Attempt to ping the job manager node. If you cannot, modify the TCP/IP
setup for the particular TCP/IP stack on the OpenVMS machine as well as
the job manager node. This may require a DNS entry or configuration of
the TCP/IP stack. Refer to the documentation for your particular TCP/IP
stack.
2.
Define a connection between job manager nodes and the UJMA machine.
To define it on the UJMA machine, use LOCAL and REMOTE statements in
the CAICCI configuration file, located at CAI_CCI_nodename:ccirmtd.prf.
LOCAL and REMOTE Statement Format
The LOCAL statement applies to the local computer, where the
REMOTE statements apply to the remote nodes that exchange
information with CAICCI.
The syntax is the same for the LOCAL and REMOTE statements:
LOCAL = <TCP/IP name><CCI name><buffersize><startup options><alias
options><port options><retry interval>
REMOTE = <TCP/IP name><CCI name><buffersize><startup options><alias
options><port options><retry interval>
For an explanation of the syntax and each parameter in the local and
remote statements, see the section LOCAL and REMOTE Statements.
The definitions apply to both LOCAL and REMOTE statement formats.
206 Implementation Guide
Configure and Maintain CAICCI
3.
Determine the status of the Remote Server. The general-purpose utility
RMTCNTRL is available to help manage the remote daemon. The following
syntax is supported:
rmtcntrl show
Outputs data concerning the hosts to which the remote daemon is or
should be connected. It will also output information about the
receivers available on those remote platforms similar to the RVT
(Receiver Vector Table) information displayed by cci show. The
information will be provided in sys$manager:syslog.log.
rmtcntrl debugon/rmtcntrl debugof
Enables or disables remote traces without recycling the remote
daemon. Trace data is written to the log directory defined by the
logical CAI_CCI_LOG.
rmtcntrl status
Displays information concerning the remote hosts to which the remote
daemon is connected or to which it should be connected. This data
appears in tabular form on stdout. If you receive a “no receiver online”
error, check this output; it may show that you are not connected to
the host in question.
rmtcntrl release
Displays the release of the ccirmtd to stdout. The command gives the
release as follows:
xxxyyzzzz
xxx
Specifies the source code version (for example, 1.137)
yy
Specifies the genlevel of Unicenter NSM (for example, 31 for
NSM 3.1)
zzzz
Specifies the release of Unicenter NSM (for example, 9708)
rmtcntrl disconnect <sysid>
Causes the local remote to issue a disconnect command to the sysid
specified and then close down the connection. This has the effect of
severing the connection between these hosts. Neither side attempts to
reestablish the connection.
rmtcntrl reconnect <sysid>
Disconnects hosts that are connected and then reconnects them. If
hosts are not connected, the local remote daemon attempts to connect
to the remote host.
Chapter 7: Post-Installation and Configuration 207
Configure and Maintain CAICCI
rmtcntrl ping <sysid>
Requests the local remote daemon to send a special CAICCI packet to
a remote daemon. This command lets you determine if the CAICCI
connection is useful at the most basic level. Upon successful
completion, the roundtrip time is displayed.
rmtcntrl echo <sysid><message>
Displays message on the target systems console if successful. Another
useful tool for determining how well the CAICCI connection between
two hosts is functioning.
rmtcntrl retry <sysid>N
Affects the retry time interval as follows:
If N >0
Set the retry time interval to N
If N = -1
Set the retry time interval to 2, then double on each
successive failure
If N = 0
Prevents the local host from attempting to reconnect
4.
Issue the following command to verify that CAICCI has established
communications.
ccii
The ccii command displays the CAICCI applications that are available.
If Unicenter services have not been started, no entries are displayed
for the local machine.
Following is an example of the output of this command:
Oid(vmsys1,Cci.Remote.SERVER ) Did( , ) type(L)Oid(vmsys1,CAU9SET SetUp Mgr )
Did( , ) type(L)
Oid(vmsys1, SUBMITC Server ) Did( , ) type(L)
Oid(A44SENF,W410_SPAWN_SERVER ) Did( , ) type(R)
Oid(A44SENF,MVS_START_SERVER ) Did( , ) type(R)
Oid(A44SENF,CA7XE44 Server ) Did( , ) type(R)
Oid(A44SENF,BARRYNT2.A44SENFUL2 ) Did( , ) type(R)
Oid(A44SENF,CA7XE44 Job track ) Did( , ) type(R)
208 Implementation Guide
Configure and Maintain CAICCI
In this example, the lines with the A44SENF entries indicate that the
CAICCI connection has been made to a mainframe: vmsys1 is the
OpenVMS machine where UJMA is installed.
5.
Monitor CAICCI. Certain syntax is supported to help you understand
CAICCI activities.
cci show
Lets you view the shared memory segment in which CAICCI stores the
RVT list.
This command is useful to determine general CAICCI information such as
the number of free and active RVTs, the key used to create the CAICCI
resources, the identifiers for the CAICCI resources, the process IDs of the
CAICCI daemons, and the time the shared memory was created.
You can also use this command to display the following information about
a specific receiver:
6.
■
The existence of a specific receiver
■
The number of pending messages for a specific receiver
■
The PID of the process that created the receiver
■
The PID of the process that holds the semaphore for this receiver
■
The last send and receive time
■
The number of sends and receives
Manage CAICCI. Certain syntax is supported to help you manage CAICCI:
cci shutdown
Tells the main daemon to shut down. The use of this command is not
advised if Unicenter NSM is still running.
cci debugon/cci debugoff
Turns main daemon tracing on and off.
7.
Check CAICCI logicals. The following table describes the logicals that are
available on the OpenVMS platform. The logicals are defined in the file
sys$startup:cci$environment.com. Do not modify this file unless directed
to do so by CA Customer Support. If any of the values in this file are
modified, CAICCI and any dependent applications will need to be
restarted.
Variable
Definition and Use
Components
Affected
CAI_CCI _DEBUG
All CAICCI processes
Use for tracing purposes. Use
and applications
set to enable CAICCI traces,
unset to disable CAICCI traces. using CAICCI
Chapter 7: Post-Installation and Configuration 209
Configure and Maintain CAICCI
Variable
Definition and Use
Components
Affected
CAI_CCI_LOG
The directory to which CAICCI
trace file will be written. Use if
a larger volume is required for
trace output. Example:
CAI_CCI_LOG=path, where
path is a directory.
All CAICCI processes
and applications
using CAICCI
CAI_CCI _CONFIG
Sets the path to the CAICCI
configuration directory.
Example:
CAI_CCI_CONFIG=path
All CAICCI processes
CAI_CCI _PORT1
Use for firewalls or certain
Remote daemon
multi NIC situations: ccirmtd
process
will bind to specified port prior
to connect calls. Example:
CAI_CCI_PORT1=n, where 250
< n < 65k
CCI_SELECT _TIME
Sometimes network conditions
will cause the TCP/IP
handshake to take a long time
to complete. Determines the
timeout for select after
connect. Example:
CCI_SELECT_TIME=n, where
n > 1.
Remote daemon
process
Configure CAICCI on OS/400
During post-installation, you must configure CAICCI on every OS/400 machine
on which you have installed the Unicenter Universal Job Management Agent
(UJMA).
To configure CAICCI on OS/400
1.
Define CAICCI server node. You must select a Windows system in your
network to function as the CAICCI Server Node for your OS/400 systems.
This Windows system should run CAICCI services, either as part of
Unicenter NSM or as part of Unicenter Universal Job Management.
Configuration on the OS/400 system involves running the CAICCI
configuration command, CACFGCCI, on the OS/400 system and specifying
the name of the Windows node that will function as the CAICCI Server
Node. (For more information about CACFGCCI see the Unicenter Universal
Job Management Agent User Guide chapter “Job Management Agent
Commands.”)
210 Implementation Guide
Configure and Maintain CAICCI
The CAICCI Server Node provides directory services to the Event
Management component of UJMA on OS/400. The CAICCI Server Node can
be the same machine as the Event Database Server Node, although it is
not necessary that these nodes be the same.
Note: The Event Database Server Node is configured with command
CACFGEVT.
2.
Configure remote bridge node. If UJMA on OS/400 will receive job
submission requests from non-Windows platforms such as UNIX and
OS/390, CAICCI, or the Remote Bridge Node, must be configured on
OS/400.
There are two parts to this configuration. These steps should be completed
prior to starting UJMA on OS/400.
If you change the configuration while UJMA is running on OS/400, you
must stop and restart the CAICCI Remote services on your OS/400
system. From a command prompt on the OS/400 system, enter the
following commands in order:
cajmastop *cci *rmtd
cajmastart *cci *rmtd
The messages returned should indicate that CAICCI was stopped and restarted.
Part 1-Specify OS/400 Node Name
From a command prompt on the OS/400 system, enter the command
CACFGCCI, and specify the name of the OS/400 node as the value of
the option Remote Bridge Node Name. An example follows:
CACFGCCI OS/400_nodename
Part 2-Define a Remote Connection
You must define a remote connection between the OS/400 system and
each remote UNIX or mainframe system that will be submitting jobs to
your OS/400 system. These connections may be defined on the
remote hosts or on the local OS/400 system. If they are defined on the
remote hosts, it is not necessary to define them on the OS/400
system. Similarly, if you define them on the OS/400 system, it is not
necessary to define them on the remote hosts.
To define connections on remote hosts, see the documentation for
those remote platforms.
To define connections on the OS/400 system, add REMOTE entries to
the CAICCI configuration file, as shown:
/UJMA/cci/ccirmtd.rc
Chapter 7: Post-Installation and Configuration 211
Configure and Maintain CAICCI
The syntax and interpretation of the REMOTE entries in this file is
identical to that described previously for the Windows, UNIX, or Linux
platforms. The following illustration is an example of the ccirmtd.rc
file:
You can edit this file by entering the following OS/400 command at the
command prompt:
WRKLNK '/UJMA/cci/ccirmtd.rc'
Select option 2 to invoke the OS/400 editor.
3.
Establish CAICCI connections. For a CAICCI connection to be established,
the following conditions must be met:
■
You must be able to PING the remote TCP/IP name from the OS/400
system.
■
You must be able to PING the OS/400 system name from the remote
host.
■
CAICCI must be started on the remote host.
■
CAICCI must be started on the OS/400 system.
To start CAICCI on the OS/400 system, first configure CAICCI (as
described previously), specifying the OS/400 system name as the value for
the Remote Bridge Node Name option in CACFGCCI. For example:
CACFGCCI BRGNODNAME(local-os400-system)
Then any of the following commands would cause the remote bridge node
(CAICCI) to start on OS/400:
cajmastart *all
cajmastart *cci
cajmastart *cci *rmtd
4.
Enter the following command at the command prompt to check the status
of CAICCI connections with remote systems (whether configured locally or
remotely):
caccirmt status
This displays the status of all connections on the terminal.
212 Implementation Guide
Configure and Maintain CAICCI
5.
Verify remote job servers. To verify that remote job servers can be
reached by CAICCI, you can run the CAUNICTRL command, which displays
the same information that is available from CCII on Windows and UNIX
platforms.
At an OS/400 command line, run command caunictrl:
Caunictrl
At the prompt, type the subcommand 'i', which stands for 'inquiry':
===> i
A list of all known remote server applications appears, as shown in the
following sample:
You should find entries for the job management products in the list.
To quit the CAUNICTRL utility, type the subcommand 'qq':
===> qq
6.
Verify CAICCI communications. On OS/400, the commands CACCIR and
CACCIS are the counterparts of the commands “ccir” and “ccis” that are
available on Windows and UNIX or Linux.
To test a CAICCI receiver on OS/400, run the command:
caccir
To test a CAICCI sender on OS/400, run the command:
caccis node('remote-host-name') count(nnn)
Chapter 7: Post-Installation and Configuration 213
Configure and Maintain CAICCI
To stop the CAICCI receiver test on OS/400, run the command:
casetevt 'test.cci.receiver'
Read the output messages that are sent to the terminal by the caccir and
caccis commands which indicate either a successful or failed attempt to
communicate.
Configure CAICCI on the Mainframe
You can configure CAICCI on the mainframe before or after installing the
Unicenter Universal Job Management Agent (UJMA).
To configure CAICCI on the mainframe
1.
Ensure required FMIDs are installed for TCP/IP support. The following CA
Common Services for z/OS and OS/390 FMIDs (functional sysmods) are
required for TCP/IP support:
FMID
Service
CS91000
CAIRIM - CA Resource Initialization Manager
CW11000
CW21000
CAIENF - CA Event Notification Facility
CW41100
CAICCI - CA Common Communications Interface
CF33100
CA-C Runtime 3.1 - CA C Language Runtime Facility,
Version 3.1
Ensure that all of these FMIDs are installed. If any are missing, install
them before continuing. See the CA Common Services for z/OS and
OS/390 Getting Started for instructions.
If the CAS9DCM3 database is not installed, perform task 11d in the CA
Common Services for z/OS and OS/390 Getting Started.
2.
214 Implementation Guide
Link edit CAICCI with TCP/IP. Requirements for link editing CAICCI with
TCP/IP differ based on the combination of TCP/IP and runtime libraries you
are using. See either of the following for a description of the link-edit
process:
■
CA Common Services for z/OS and OS/390 Getting Started
■
CA Common Services for z/OS and OS/390 Administrator Guide
Configure and Maintain CAICCI
3.
Configure TCP/IP Gateway server started task. The started task procedure
name differs based on the combination of TCP/IP and runtime libraries you
are using.
■
CAI.CAIPROC member CCITCPGW contains the JCL needed to run the
CAICCI TCP/IP Gateway server using IBM TCP/IP with LE/370.
■
CAI.CAIPROC member CCIGWS contains the JCL needed to run the
CAICCI TCP/IP Gateway server using IBM TCP/IP with SAS C Runtime
(instead of LE/370).
■
CAI.CAIPROC member CCIGWI3 contains the JCL needed to run the
CAICCI TCP/IP Gateway server using Interlink TCP/IP 3.1 and 4.1.
IBM TCP/IP users—If you do not have the IBM LE/370 or SAS C Runtime
modules in a LNKLST data set, concatenate your runtime library to the
appropriate CAICCI TCP/IP load library.
Interlink TCP/IP users--If you do not have the SAS C Runtime modules in
a LNKLST data set, concatenate your runtime library to the appropriate
CAICCI TCP/IP load library. (Interlink provides the SAS C Runtime library.)
The Interlink TCP/IP load library should be ahead of the SAS C library in
the CCIGWI3 STEPLIB concatenation.
4.
Define parameters for TCP/IP Gateway Server Started Task. Define the
following PROTOCOL statement and port number parameters for the
TCP/IP Gateway Server Started Task. An example follows the parameter
descriptions.
PROTOCOL Statement
To start the desired TCP address space for host-to-host connectivity,
you must include the appropriate PROTOCOL statement in the data set
pointed to by the //ENFPARMS DD statement with your ENF started
task JCL:
■
PROTOCOL(TCPIPGW,...) starts procedure CCITCPGW to use IBM
TCP/IP (with the IBM C Runtime) for host-to-host connectivity.
■
PROTOCOL(TCPIPSGW,...) starts procedure CCIGWS to use IBM
TCP/IP with the SAS C Runtime (instead of IBM C Runtime) for
host-to-host connectivity.
■
PROTOCOL(TCPIP3GW,...) starts procedure CCIGWI3 to use
Interlink TCP/IP Version 3.1 or 4.1 for host-to-host connectivity.
TCP/IP can be started before or after any of the CAICCI address
spaces. If TCP/IP services are not available, the gateway server
started task periodically retries the connection until TCP/IP starts. If
TCP/IP is shut down for any reason, the gateway server started task
terminates. If originally brought up by CAICCI, the gateway server
started task is automatically restarted and again repolls for TCP/IP
restart. Otherwise, you must restart the address space manually.
Chapter 7: Post-Installation and Configuration 215
Configure and Maintain CAICCI
To manually restart the CAICCI Gateway server, issue the console
command:
ENF,PROTOCOL(TCPIPGW,...)
Port Number
TCP/IP connections are based on network addresses plus a port
number. The combination of address and port uniquely identifies each
application on the network. CAICCI, like all other TCP/IP applications,
requires that you specify a port number for its use. This port number
must be available to both the mainframe CAICCI software and PC
client systems.
By default, CAICCI uses port number 7000 for host-to-host
connectivity. Change this value to 1721.
Examples
IBM TCP/IP users-If CAICCI is starting the TCP address space, override
the port number using the associated PROTOCOL statement within the
//ENFPARMS DD statement of the ENF started task JCL. For example:
SYSID(SYSA)
PROTOCOL(TCPIPGW,1721,,SYSA)
Interlink TCP/IP users-If CAICCI is starting the TCP address space,
override the port number using the associated PROTOCOL statement
within the //ENFPARMS DD statement of the ENF started task JCL:
SYSID(SYSA)
PROTOCOL(TCPIP3GW,SSID=ACSS:1721,,SYSA)
Note: ACSS is the default name for the Interlink TCP/IP subsystem.
5.
Define a connection between the mainframe and the UJMA machine. We
recommend that you define the connection from the agent machine
instead of OS/390. Instructions for this syntax are included in the section
Configure CAICCI on Windows in the step to define a connection between
nodes.
If you do wish to define the connection on the OS/390 mainframe, use
NODE and CONNECT statements in ENFPARMS.
NODE Statement
The NODE statement identifies the machine to which you are defining
a connection. For example:
NODE(TCPIPGW,172.16.197.114:1721,1,TRITON)
TCPIPGW is the protocol, 172.16.197.114 is the IP address, 1721 is
the port number, 1 is the repoll time in minutes, and TRITON is the
sysid (CAICCI machine name).
216 Implementation Guide
Configure and Maintain CAICCI
Note: You may use a node name instead of an IP address if the CA
Common Services for z/OS and OS/390 genlevel is 9807 or higher
(formerly known as TNG Framework for OS/390). If the node name is
greater than eight characters, use the alias name specified in the
LOCAL statement in the CAICCI configuration file (ccirmtd.rc in
Windows, ccirmtd.prf in UNIX, or CACCICFG.RMTPRF in HP NonStop).
CONNECT Statement
The CONNECT statement initiates the connection. For example, the
following statement initiates the connection to the machine identified
in the previous NODE statement example:
CONNECT(TRITON)
For more information about the NODE and CONNECT statements, see
the CA Common Services for z/OS and OS/390 Administrator Guide.
6.
Restart CAIENF for these changes to take effect.
Note: To dynamically define a connection between nodes, you may use
console commands instead of NODE and CONNECT statements. However,
if you do this, the changes are in effect for this session of CAIENF only. For
the changes to be in effect permanently, you need to define NODE and
CONNECT statements and restart CAIENF. The following example shows
how to use commands to define a connection between nodes:
ENF NODE(TCPIPGW,172.16.197.114:1721,1,TRITON)
ENF CONNECT(TRITON)
Troubleshooting CAICCI
When communication between two remote systems does not take place, it is
often because the queues are not available.
CCII Utility
The simplest method to determine whether the queues are registered on a
remote system is by running CCII on both the local and remote machine. The
output of CCII is the list of registered local and remote message queues.
CCIS/CCIR Utilities
CCIS and CCIR are provided on OpenVMS, UNIX, and Windows Manager.
These test programs can be used to test communication between two remote
daemons.
CCIR-Connects to CCIRMTD and creates a message queue. It will listen on the
queue for messages sent from another system that supports CCIS.
Chapter 7: Post-Installation and Configuration 217
Configure and Maintain CAICCI
Note: Before running CCIS, make sure that the test queue is registered on the
remote system (system where CCIS will run), by executing CCII on the remote
machine.
CCIS-Sends a test message to the designated host. The format of the CCIS
command is:
CCIS SYSID COUNT
count
Specifies the number of times the message should be sent
A summary of the location of the CAICCI configuration file follows:
Operating
System
File Location + File Name
Windows
unicenter installdir \caiuser\ccirmtd.rc
UNIX
$CAIGLBL0000/cci/config/hostname/ccirmtd.prf
OpenVMS
CAI_CCI_nodename:ccirmtd.prf
CCIRMTD Behavior at Startup
At startup, the remote daemon must be able to resolve both the CAICCI
service as well as the node name specified in the LOCAL line of the
configuration file. If the remote daemon fails to start, check that these names
can be resolved by whatever means are used to resolve names in the client's
environment. This information is then used to passively open a socket.
The remote daemon operates in a peer-to-peer manner, that is, all remote
daemons listen for connection requests from all other remote daemons.
Next, the remote daemon runs down the list of hosts to connect to, as
specified in the configuration file. For each host you must be able to resolve
the node name to the correct IP address.
The remote daemon issues a connect request. If the target host is listening,
the connection established at this point is at the TCP/IP level. Should a
connection between two hosts drop, by default both hosts attempt to
reestablish the connection.
218 Implementation Guide
Configure Remote Monitoring
Configure Remote Monitoring
The best configuration for your Remote Monitoring deployment is determined
by many factors, including network traffic, machine speed, and other
variables. After you install and configure, you can monitor various reports and
metrics to assess the performance of your deployment.
After reviewing reports you may find that altering your configuration will
produce better performance results. You can make the following changes to
your Remote Monitoring deployment:
■
Change which Agent opens in the Administrative Interface
Each Remote Monitoring Agent is configured to monitor a select set of
resources. The resources you can view and configure in the Administrative
Interface is determined by which Remote Monitoring Agent you connect to.
By changing the Remote Monitoring Agent connection, you can view and
configure a different set of resources.
Note: If your organization is using the Remote Monitoring security, you
must log in with the administrator access defined by Remote Monitoring to
configure the agent (this is different from a Windows administrative user
account).
■
Send status data to a different MDB
Remote Monitoring sends resource data to an MDB. Both the Unicenter
WorldView and Event Management Console are connected to this MDB and
they are responsible for displaying the resource status and the event
message information gathered by Remote Monitoring. In an environment
where there is more than one MDB deployed, you may decide that an
agent should instead start sending its information to one of the other
MDBs.
■
Run multiple instances of the Administrative Interface
Although you can change which Remote Monitoring Agent you connect to
with the Administrative Interface, you may choose instead to create
several shortcuts to the interface and configure each shortcut to connect
to a different agent. By connecting each shortcut to a unique agent, you
can run several instances of the Administrative Interface at the same time,
monitoring several agents at once without having to manually switch from
agent to agent within one interface.
■
Alter the list of resources monitored by a single Agent
The amount of network traffic generated by monitoring a single resource is
unpredictable. After you set up a list of resources to monitor with a single
agent, you may need to revise that list; you can either add resources or
remove resources from monitoring. If you remove resources from one
agent, you can rediscover and add them to the list of another agent.
Chapter 7: Post-Installation and Configuration 219
Configure Unicenter Management Portal
Configure Unicenter Management Portal
Unicenter MP leverages Unicenter DIA to get managed data from Unicenter
NSM managers. The Unicenter NSM knowledge base in the designated zone
must be set as the first step for Unicenter MP configuration. Furthermore, to
get data from Unicenter NSM managers, the managers must be registered
with Unicenter MP. Set the Unicenter knowledge base and register managers
using the tool provided in the Unicenter MP Administration wizard under Task
1: Manage component. The Administration wizard is available when you log in
to the portal using administrator credentials.
For configuration information, see the chapter "Unicenter MP Administration"
in the Administrator Help in the portal knowledge library under the Enterprise
Management\Documentation folder.
Configure Unicenter for Pocket PC
Once you have installed Unicenter for Pocket PC, you are ready to configure
the device.
To configure Unicenter for Pocket PC
1.
Start Unicenter NSM on the device by selecting Unicenter NSM from the
Start menu.
When you start Unicenter NSM for the first time on a device, a
Configuration dialog appears.
2.
Enter the name of the Windows server that acts as the device manager for
this device. This can be the name or IP address of any Windows server
running Unicenter NSM Enterprise Management.
You can change this information later by selecting Options from the
Unicenter Tools menu.
3.
Select the TCP/IP Port number used for communications.
The default is 8888.
4.
220 Implementation Guide
Click OK.
Configure the Unicenter WMI Agent
Configure the Unicenter WMI Agent
To configure the Unicenter WMI agent
1.
Use the cawmicnf.exe utility to provide authentication for additional
namespaces. It prompts for a namespace and associated credentials. Only
authenticated namespaces can be monitored.
2.
Configure thresholds and poll times through the Agent View user interface.
You can launch this interface by right-clicking one of the following areas:
■
The context menu from WorldView
■
Directly on the command line by entering the following command:
abrowser -c browser.caWmiAgent
Configure Monitoring for z/OS Interface
Use the information in this section to configure and control the Monitoring for
z/OS feature (z/OS and CICS agents).
To configure the Monitoring for z/OS Interface, edit the configuration sets to
provide settings specific to your installation.
A sample configuration set for each agent is located in the smo.INSTLIB data
set in the following members:
■
CFGSETOS (z/OS system agent)
■
CFGSETCI (CICS agent)
Note: You must reload the configuration set after running the clean_sadmin
command.
Chapter 7: Post-Installation and Configuration 221
Configure Monitoring for z/OS Interface
Unicenter CA-SYSVIEW Server
The Unicenter CA-SYSVIEW Server address space must be active before the
agent can collect data. For instructions on starting and stopping the Unicenter
CA-SYSVIEW Server address space, see the Unicenter CA-SYSVIEW Realtime
Performance Management Server Getting Started. If you are an existing
Unicenter CA-SYSVIEW or agent's user, start your SYSVIEW or CAIAGENT
address space using the START command.
If the MVSDATA collector has not been started in your SYSVIEW address
space, issue the following command from the system console to start the
MVSDATA collector dynamically:
MODIFY SYSVIEW,START MVSDATA
If the CICSLOGR task has not been started in your SYSVIEW address space,
issue the following command to start the CICS logger dynamically:
MODIFY SYSVIEW,START CICSLOGR
The Unicenter CA-SYSVIEW CICS XPFI transaction must also be active in each
CICS region that is to be monitored by the CICS agent.
Start and Stop the Agents
To start the agents
1.
Ensure that Agent Technology is running before starting the agent address
spaces.
2.
Initiate the PROC that starts the agent address spaces by issuing the z/OS
START command from a system console:
START ZOSAGTS
START CICSAGTS
To initiate the PROC that stops the agent address spaces, issue the z/OS
START command from a system console:
START ZOSAGTE
START CICSAGTE
Do not use the CANCEL or FORCE commands to terminate the agent address
spaces unless the agents refuse to terminate using the procedures provided.
Doing so may prevent the agents from restarting properly until you recycle
Agent Technology.
For more information on controlling the z/OS and CICS agents, see the Inside
Systems Monitoring Guide.
222 Implementation Guide
Run Unicenter Management for MOM Discovery
Run Unicenter Management for MOM Discovery
Unicenter NSM MOM Discovery communicates with Micosoft Operations
Manager to classify WEBM computers in your network as MOM servers or
managed PCs. After discovery, you can view and update the status of these
devices in WorldView and view MOM alerts on the Event Console.
Note: The first MOM discovery can be done during the installation of Unicenter
Management for MOM. To keep MOM information current, perform MOM
Discovery at regular intervals.
To run MOM Discovery
1.
Run WorldView Auto Discovery on your MOM network.
The MDB is populated with WBEM machines.
2.
Choose Start, Programs, CA, Unicenter, Management for MOM, MOM
Discovery.
The MOM Discovery Wizard opens.
3.
Click Next, and enter or verify the domain, user ID, and password for the
account that accesses and updates MOM information. You defined this user
when you installed Unicenter Management for MOM.
The account that handles MOM is identified.
4.
Click Next, and follow the prompts.
MOM Discovery classifies WBEM devices as MOM servers or managed PCs.
5.
Restart the RMI server (rmi_server).
The icons are displayed correctly in WorldView.
Chapter 7: Post-Installation and Configuration 223
Run CA System Center Operations Manager Discovery
Run CA System Center Operations Manager Discovery
Unicenter NSM SCOM Discovery communicates with Micosoft System Center
Operations Manager to classify computers in your network as SCOM servers or
managed PCs. After discovery, you can view and update the status of these
devices in WorldView and view SCOM alerts on the Event Console.
Note: The first discovery can be done during installation of the Integration
with Operations Manager. To keep the information current, perform SCOM
Discovery at regular intervals.
To run SCOM Discovery
1.
Run WorldView Auto Discovery on your SCOM network.
The MDB is populated with servers and managed PCs.
2.
Choose Start, Programs, CA, Unicenter, SCOM Integration, SCOM
Discovery.
The SCOM Discovery Wizard opens.
3.
Click Next, and enter or verify the domain, user ID, and password for the
account that accesses and updates SCOM information. You defined this
user when you installed the Unicenter NSM Integration for System Center
Operations Manager.
The account that handles SCOM is identified.
4.
Click Next, and follow the prompts.
SCOM Discovery classifies the devices as SCOM servers or managed PCs.
5.
Restart the RMI server (rmi_server).
The icons are displayed correctly in WorldView.
224 Implementation Guide
Access Unicenter NSM Web Applications
Access Unicenter NSM Web Applications
Unicenter NSM web applications such as the Active Directory Explorer,
Adaptive Dashboard Services, Advanced Event Correlation Web User Interface,
Knowledge Base, Unicenter Configuration Manager and Web Reporting Server
run on the CA Web Server using Tomcat technology. You access the web
applications through the welcome page that is available as part of the CA Web
Server or directly by specifying the complete URL to the application.
On Windows or Linux platforms, you launch the welcome page by opening your
web browser and entering the following URL:
http://host_name:port_number
host_name
Specifies the name of the server where the CA Web Server is running.
port_number
Specifies the port number where the CA Web Server is running. The
default if 9090 unless it was changed during installation.
On a Windows server that has CA Web Server installed, you can launch the
welcome page by selecting Start, Programs, CA, Unicenter, NSM, CA Web
Server.
Chapter 7: Post-Installation and Configuration 225
Access Unicenter NSM Web Applications
The welcome page lists the names of the applications installed by CA. You can
access the application by clicking the application name.
The welcome page also provides links to the standard Tomcat applications
Tomcat Administration and Tomcat Manager. Tomcat Manager provides the
capability to manage your web applications without having to shut down and
restart Tomcat. Tomcat Administration lets you manage users, groups, and
roles and perform advanced administration tasks. For more information about
Tomcat applications, see http://jakarta.apache.org/tomcat/index.
As an alternative to the welcome page, you can access the Unicenter NSM web
applications directly by specifying the complete URL to the application as
follows:
Application
URL
Active Directory Explorer
http://host:port/ade
Adaptive Dashboard Services
http://host:port/ads
Advanced Event Correlation Web User http://host:port/aecwebUI
Interface
Knowledge Base
http://host:port/KnowledgeBaseUI
Unicenter Configuration Manager
http://host:port/wiser
Web Reporting Server
http://host:port/wrs
host
Specifies the name of the server that is running the application.
port
Specifies the port that was specified for Apache Tomcat during the
installation of Unicenter NSM. The default port is 9090.
When you access a Unicenter NSM web application, you are prompted for a
user ID and password. The default user ID for the Tomcat user defined by
Unicenter NSM is admin. The password for the admin user is specified during
the Unicenter NSM installation as the password for the Apache Tomcat
administrator.
226 Implementation Guide
Access Unicenter NSM Web Applications
Access AEC Web UI
You can launch the AEC Web Policy Editor a few different ways:
■
Launch through the CA Web Server menu, which displays a list of all CA
web applications, including the AEC web policy editor.
■
Locate the AEC Policies tree item in the Management Command Center.
The Web Policy Editor opens in the right pane of the Management
Command Center.
■
Open the Web Policy Editor from Alert Management using the Alert Class Detail window, AEC tab in the Unicenter MCC.
Launching the Web Policy Editor independently, outside of Management
Command Center, requires some basic configuration. The Web Editor
automatically displays a Configuration tab that prompts for the name of the
Distributed Intelligence Architecture (DIA) Knowledge Base and the Event
Manager host.
Note: Launching from within Management Command Center does not require
this configuration because Management Command Center already understands
these values and passes them automatically to the web policy editor within the
right pane of Management Command Center.
Unicenter Configuration Manager Setup
Post-installation steps for Unicenter Configuration Manager involve updating a
configuration file in a cluster environment and entering information to access
the MDB.
■
Cluster environment—If UCM is installed in a cluster environment, you
need to update three properties in the configuration file ucm.properties.
Add the Universal Naming Convention (UNC) address of the shared storage
area that all UCM servers in the cluster use for retrieval and storage of all
UCM profiles and file packages. An example is
\\ServerName\SharedDirectoryName. The properties are:
–
ui.profile.defaultDirectory
–
ui.filepkg.defaultDirectory
–
ui.adaptive.defaultDirectory
Chapter 7: Post-Installation and Configuration 227
Access Unicenter NSM Web Applications
■
Access to MDB—The first time you start Unicenter Configuration
Manager, you must enter the following information to access the MDB:
–
The hostname where the MDB resides
–
A valid local user ID and password that has the appropriate MDB
access levels in Microsoft SQL Server or Ingres
–
JDBC Port (The default value is provided when you select the DBMS
Type.)
Note: See the Unicenter Configuration Manager help for more information.
Access the Knowledge Base
You can access Knowledge Base articles in different ways:
■
Open the Knowledge Base User Interface and use the table of contents or
perform a search from the Knowledge Base User Interface.
■
Specify a direct URL that performs a search in the Knowledge Base and
that displays the search results. See the Knowledge Base help system for
details.
■
Use the Knowledge Base links in the Active Directory Explorer and in the
Active Directory Agent Dashboards. These links redirect you automatically
to the associated articles.
■
Use the Knowledge Base links in Active Directory messages that appear in
the Event Console. These links redirect you automatically to the associated
articles.
See the Inside Active Directory Management guide for further details.
Configure Unicenter NSM Web Reporting Server
The first time you start Unicenter NSM Web Reporting Server, you need to
establish connections to the Unicenter NSM managers using the Manage
Components page.
To access the Manage Components page
1.
Expand the Administration tree node in the left pane to view the Manage
Components tree node.
2.
Select Manage Components.
3.
Click Discover to discover the Unicenter NSM managers available in your
environment.
4.
Select the components that you want to be accessible for reporting,
choose the default connection for each component type, provide user ID
and passwords as required, and save the connections.
228 Implementation Guide
Access Unicenter NSM Web Applications
CA Web Server Configuration with SSL
SSL, or Secure Socket Layer, is a technology that lets web browsers and web
servers communicate over a secured connection. This means that the data
being sent is encrypted by the sending side, transmitted, and then decrypted
by the receiving side before processing. This is a two-way process, both the
server and the browser encrypt all traffic before sending out data.
Another important aspect of the SSL protocol is authentication. During your
initial attempt to communicate with a web server over a secure connection,
the server will present your web browser with a set of credentials in the form
of a certificate as proof the site is who and what it claims to be.
To implement SSL, a web server must have an associated certificate for each
external interface (IP address) that accepts secure connections. The theory
behind this design is that a server should provide reasonable assurance that
its owner is who you think it is, particularly before receiving any sensitive
information.
This certificate is cryptologically signed by its owner and is extremely difficult
for anyone else to forge. For sites involved in e-commerce, or any other
business transaction in which authentication of identity is important, a
certificate is typically purchased from a well-known Certificate Authority such
as VeriSign or Thawte. Such certificates can be electronically verified. In
effect, the Certificate Authority vouches for the authenticity of the certificates
that it grants, so you can believe that the certificate is valid if you trust the
Certificate Authority that granted it.
In many cases, authentication is not a concern. An administrator may simply
want to ensure that the data being transmitted and received by the server is
private and cannot be snooped by anyone who may be eavesdropping on the
connection. Java provides a relatively simple command-line tool, called
keytool, which can create a self-signed certificate.
CA Web Server which is based on Tomcat 5.5 technology hosts several
Unicenter NSM web applications including Active Directory Explorer,
Knowledge Base, Unicenter NSM Web Reports and Dashboards, Unicenter
Configuration Manager, and the AEC Web Interface.
Chapter 7: Post-Installation and Configuration 229
Access Unicenter NSM Web Applications
Therefore, the SSL configuration of the CA Web Server can be divided into two
parts:
Part 1 describes how to configure Tomcat that is distributed as part of CA Web
Server to work with SSL. This topic provides step-by-step instructions on
configuring CA Web Server and shared Tomcat. The procedures provided are
specific to the Tomcat installed as part of Unicenter NSM r11.2.
Part 2 describes additional configuration steps that are specific to web
applications (Web Reporting Server) which are running under the CA Web
Server.
For additional information regarding Tomcat or SSL for Tomcat, visit the
following websites:
http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
http://tomcat.apache.org/index.html
230 Implementation Guide
Access Unicenter NSM Web Applications
Part 1: Configure Tomcat with SSL
To configure Tomcat with SSL, you need to know the install locations of the
Tomcat and Java Runtime Environment (JRE) that is installed by Unicenter
NSM.
Linux default locations:
Tomcat
/opt/CA/SC/tomcat/5.5.23
JRE
/opt/CA/SC/JRE/1.5.0_11
Windows default locations:
Tomcat
InstallPath\CA\SC\TomCat.ccs\5.5.23
JRE
InstallPath\CA\SC\JRE.ccs\1.5.0_11
In the steps that follow, the install locations are referred to as jre_install_path
or tomcat_install_path.
To configure Tomcat with SSL
1.
Change to the WRS directory InstallPath\SC\CCS\WRS.
2.
To generate a self-signed certificate, run the keytool utility as follows:
jre_install_path\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore
\tomcat_keystore_path\tomcat_keystore_name
tomcat_keystore_path
Defines the path to the location of the keystore file you are creating. If
you do not explicitly specify the path, the keystore file is created in
your HOME directory. If you use a directory that has spaces in the
path, you must enclose the value of the keystore parameter in double
quotes; for example, "\my path\tomcat_keystore_name".
tomcat_keystore_name
Defines the name you assign for this specific certificate.
The keytool utility prompts you for the following parameters:
Keystore password
Provide a password. The default password used by Tomcat is changeit
(case-sensitive), although you can specify a custom password.
Remember the password you use. You will provide the password in
steps 3 and 4.
Chapter 7: Post-Installation and Configuration 231
Access Unicenter NSM Web Applications
First and last name
Specify your host name. You must use the fully qualified host name
when responding to this prompt; for example, myhost.mydomain.com.
Information parameters
Respond to several information parameters as they apply to your
organization: the name of your organizational unit, the name of your
organization, your city or locality, your state or province, and your
two-letter country code.
Key password for tomcat
Specify the key password in the server.xml configuration file using
"keystorePass" (see step 4). You must use the same password here as
you use for the keystore password itself. The keytool prompt tells you
that pressing the Enter key does this for you automatically.
The following screen illustrates the output from the keytool command:
232 Implementation Guide
Access Unicenter NSM Web Applications
3.
To export the generated certificate into JRE's cacerts, run the following
two commands:
jre_install_path\bin\keytool -keystore
\tomcat_keystore_path\tomcat_keystore_name -export -alias tomcat -file
temp.cer
tomcat_keystore_path
Specifies the path to the keystore file you set in step 2.
tomcat_keystore_name
Specifies the name you assigned for this specific certificate in step 2.
When prompted, provide the password you used to create the keystore in
step 2.
and
jre_install_path\bin\keytool -keystore jre_install_path\lib\security\cacerts
-import -alias tomcat -file temp.cer
By default, the password for jre_install_path\lib\security\cacerts is
changeit. Use this password even if you used a different password in step
2 while creating your own keystore file for Tomcat.
If the jre_install_path has spaces in it, enclose the
jre_install_path\lib\security\cacerts entry in double quotes. For example:
"C:\Program Files\CA\SC\JRE\1.5.0_11\lib\security\cacerts"
4.
Take a backup of the server.xml file that is located in
tomcat_install_path\conf and modify the server.xml file with a text editor
according to the following steps.
5.
Open the server.xml file, remove the comment delimiters (<!-- and -->)
before and after the SSL connector statement and add the keystoreFile
and keystorePass attributes. The statement then appears similar to the
following:
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150"
minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="\tomcat_keystore_path\tomcat_keystore_name"
keystorePass="your_custom_password" />
\tomcat_keystore_path\tomcat_keystore_name
Points to the keystore file you created in step 2.
your_custom_password
Specifies the password you defined for the keystore in step 2. The
default password is changeit.
Chapter 7: Post-Installation and Configuration 233
Access Unicenter NSM Web Applications
Note: If you change the default SSL port to something other than 8443,
you must change the redirect ports for other connectors to that new SSL
port number.
6.
The WRS server uses the HTTP port (Non-SSL) for local connections. To
stop listening for remote requests, add the address attribute to the 9090
Connector statement. The statement then appears similar to the following:
<Connector port="9090" maxHttpHeaderSize="8192" maxThreads="50"
minSpareThreads="2" maxSpareThreads="10" enableLookups="false"
redirectPort="8443" acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true" address='localhost' />
7.
Save server.xml.
8.
Restart CA Web Server service.
9.
Change the URL of the start menu entry:
Select "Start->Programs->CA->Unicenter->NSM->CA Web Server", right
click Properties, and change the URL to https://hostname:8443/index.jsp.
Part 2: Application-Specific Instructions
Once you configure the CA Web Server to run with SSL, the web applications
running under it may require additional configuration steps. This topic
describes the steps that are specific to the Web Reporting (WRS) and Adaptive
Dashboard Services (ADS).
Note: Unicenter Configuration Manager reports are published in WRS. To load
them properly from Unicenter Configuration Manager and WRS, use the WRSspecific instructions that follow to get all the reports republished for use with
the SSL port.
The following procedure describes how to enable SSL for ADS and WRS:
To enable SSL for ADS and WRS
1.
Change to the ADS directory InstallPath\SC\CCS\ADS and run the wrscfg
utility in that directory to republish the links:
wrscfg republish from=http://hostname:9090/ads to=https://hostname:8443/ads
save=true
hostname
Use the fully qualified host name that you have specified for your selfsigned certificate in part 1, step 2.
from
Specifies the non-SSL port and protocol (for example,
http://myhost.mydomain.com:9090/ads)
234 Implementation Guide
Access Unicenter NSM Web Applications
to
Specifies the SSL port and protocol (for example,
https://myhost.mydomain.com:8443/ads)
save
true (default) saves the new port and protocol in local properties.
For example:
wrscfg republish from=http://myhost.mydomain.com:9090/ads
to=https://myhost.mydomain.com:8443/ads save=true
Note: The configuration capability (add, edit, delete watchers) is only
available to users belonging to the administrator role.
2.
Change to the WRS directory InstallPath\SC\CCS\WRS and run the wrscfg
utility in that directory to republish the links:
wrscfg republish from=http://hostname:9090/wrs to=https://hostname:8443/wrs
save=true
hostname
Use the fully qualified host name that you have specified for your selfsigned certificate in part1, step 2.
from
Specifies the non-SSL port and protocol (for example,
http://myhost.mydomain.com:9090/wrs)
to
Specifies the SSL port and protocol (for example,
https://myhost.mydomain.com:8443/wrs)
save
true (default) saves the new port and protocol in local properties.
For example:
wrscfg republish from=http://myhost.mydomain.com:9090/wrs
to=https://myhost.mydomain.com:8443/wrs save=true
Note: The host name remains the same during republishing.
3.
Restart CA Web Server service.
Chapter 7: Post-Installation and Configuration 235
Access Unicenter NSM Web Applications
4.
Stop RMI_SERVER process using the following command:
RMI_MONITOR -k
5.
Run the wrs_modcat command:
wrs_modcat -s ServerName -p PortNumber -l ListenPort -c Protocol
ServerName
Specifies the server name on which WRS is running. Specify localhost.
PortNumber (optional)
Specifies the port number on which WRS operates. Specify the http
port (for example, 9090).
ListenPort (optional)
Specifies the port number on which the wrapper listens for
notifications. You can specify any available port (for example, 5182).
Protocol (optional)
Specifies the protocol to use. Specify http.
In this case the following command is sufficient:
wrs_modcat -s localhost
6.
Make sure that Java and JavaScript is enabled for the Internet Explorer
and that the host name used in step 1 and 2 does not block web sites.
Otherwise, the reports cannot be displayed properly in MCC. To avoid
blocking, you can, for example, modify the Security Zones of the Internet
Explorer settings accordingly if necessary.
Revert to a Non-SSL Configuration
If you want to return to a non-SSL configuration, you need, in principle, only
reverse some of the previously made configuration steps.
To revert to a non-SSL configuration
1.
Change to the WRS directory InstallPath\SC\CCS\WRS and run the wrscfg
utility to republish the links:
wrscfg republish from=https://hostname:8443/wrs
to=http://hostname:9090/wrs
save=true
2.
Change to the ADS directory InstallPath\SC\CCS\ADS and run the wrscfg
utility to republish the links:
wrscfg republish from=https://hostname:8443/ads to=http://hostname:9090/ads
save=true
236 Implementation Guide
Access Unicenter NSM Web Applications
3.
Change to the tomcat_install_path\conf directory and rename the backup
file of server.xml to server.xml. The backup file was taken in step 4 of the
Part 1 procedure.
4.
Restart the CA Web Server service.
5.
Change the URL of the start menu entry:
Select "Start->Programs->CA->Unicenter->NSM->CA Web Server", right
click Properties, and change the URL to http://hostname:9090/index.jsp.
Example Procedure
The following sequence of commands is an example for configuring the CA
Web Server in SSL-mode. The commands may slightly differ depending on the
respective installation.
Part 1: Configure Tomcat with SSL
1.
Change to the WRS directory C:\Program Files\CA\SC\CCS\WRS.
2.
Generate a self-signed certificate.
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\JRE.ccs\1.5.0_11\bin\keytool" -genkey -alias tomcat -keyalg RSA keystore "C:\Program Files\CA\SC\CCS\WRS\WRSkeystore"
Enter keystore password:
changeit
What is your first and last name?
[Unknown]:
myhost.mydomain.com
What is the name of your organizational unit?
[Unknown]:
R&D
What is the name of your organization?
[Unknown]:
myorg
What is the name of your City or Locality?
[Unknown]:
mycity
What is the name of your State or Province?
[Unknown]:
mystate
What is the two-letter country code for this unit?
[Unknown]:
DE
Is CN=myhost.mydomain.com, OU=R&D, O=myorg, L=mycity, ST=mystate, C=US
correct?
[no]:
yes
Enter key password for <tomcat>
(RETURN if same as keystore password):
3.
Export the certificate to a temporary file.
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\JRE.ccs\1.5.0_11\bin\keytool" -keystore "C:\Program
Files\CA\SC\CCS\WRS\WRSkeystore" -export -alias tomcat -file temp.cer
Enter keystore password:
changeit
Certificate stored in file <temp.cer>
Chapter 7: Post-Installation and Configuration 237
Access Unicenter NSM Web Applications
4.
Import the certificate into cacerts.
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\JRE.ccs\1.5.0_11\bin\keytool" -keystore "C:\Program
Files\CA\SC\JRE.ccs\1.5.0_11\lib\security\cacerts" -import -alias tomcat file temp.cer
Enter keystore password:
changeit
Owner: CN=myhost.mydomain.com, OU=R&D, O=myorg, L=mycity, ST=mystate, C=DE
Issuer: CN=myhost.mydomain.com, OU=R&D, O=myorg, L=mycity, ST=mystate, C=DE
Serial number: 48594891
Valid from: Wed Jun 18 19:40:33 CEST 2008 until: Tue Sep 16 19:40:33 CEST
2008
Certificate fingerprints:
MD5:
2F:AA:84:D7:8C:67:72:21:9B:A6:0D:A3:0D:20:37:C2
SHA1: FE:EE:09:EC:95:47:79:F5:54:75:05:C5:77:91:20:A9:C3:45:F4:69
Trust this certificate? [no]:
yes
Certificate was added to keystore
5.
Change to C:\Program Files\CA\SC\Tomcat.ccs\5.5.23\conf, open
server.xml, add the parts formatted in bold characters to the server.xml
file, and remove the comment delimiters (<!-- and -->) from the SSL
connector statement (port 8443).
...
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector port="9090" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
address='localhost'
/>
...
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="C:\Program Files\CA\SC\CCS\WRS\WRSkeystore"
keystorePass="changeit"
/>
...
6.
Save server.xml.
7.
Restart CA Web Server service.
8.
Change the URL of the start menu entry:
Select "Start->Programs->CA->Unicenter->NSM->CA Web Server", right
click Properties, and change the URL to https://hostname:8443/index.jsp.
238 Implementation Guide
Access Unicenter NSM Web Applications
Part 2: Application-Specific Instructions
1.
Change to the ADS directory C:\Program Files\CA\SC\CCS\ADS.
2.
Run the wrscfg utility to republish the ADS links.
C:\Program Files\CA\SC\CCS\ADS>wrscfg republish
from=http://myhost.mydomain.com:9090/ads
to=https://myhost.mydomain.com:8443/ads save=true
3.
Change to the WRS directory C:\Program Files\CA\SC\CCS\WRS.
4.
Run the wrscfg utility to republish the WRS links.
C:\Program Files\CA\SC\CCS\WRS>wrscfg republish
from=http://myhost.mydomain.com:9090/wrs
to=https://myhost.mydomain.com:8443/wrs save=true
5.
Stop RMI_SERVER.
C:\Program Files\CA\SC\CCS\WRS>RMI_MONITOR -k
RMI_MONITOR
RMI_Server is not running
6.
Run the wrs_modcat command.
C:\Program Files\CA\SC\CCS\WRS>WRS_MODCAT -s localhost
Using Default Values for WRS Port Number and Listen Port Number
......Adding Local NameSpace: WRS on computer
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\CCS\AIS\framework\bin\addprov.exe" WRS WRSWrp key=WRSPrv
WebServer="localhost" Webport="9090" ListenerPort="5182" Protocol="http"
Modified provider - name: WRS
wrapper: WRSWrp
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\CCS\AIS\framework\bin\addnsp.exe" WRS Root WRSPrvkey=WRSNsp
description="NLS_WEBREPORTS" label="myhost" icon="reports_icon"
Modified namespace - name: WRS
owner: Root
Delete existing WRS(WRS Namespace on Global Machine ......
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\CCS\AIS\framework\bin\DelNspByName.exe" Root/WRS(myhost)
Root/MasterCat
Namespace deleted
UnPublish Namespace : WRS on Global Machine ......
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\CCS\AIS\framework\bin\UnPublishCat.exe" Root/WRS Root/MasterCat
Namespace unpublished
Publish Namespace : WRS(WRS Namespace on Global Machine ......
Chapter 7: Post-Installation and Configuration 239
Access Unicenter NSM Web Applications
C:\Program Files\CA\SC\CCS\WRS>"C:\Program
Files\CA\SC\CCS\AIS\framework\bin\publishcat.exe" Root/WRS Root WRS(myhost)
Root/MasterCat description="NLS_WEBREPORTS" label="myhost"
icon="reports_icon"
Namespace published
The new provider and namespace was successfully added. The relevant batch
files have been modified.
C:\Program Files\CA\SC\CCS\WRS>
CA Web Server Security
CA Web Server security is based on the Tomcat 5.5 security mechanism and is
primarily concerned with authentication and access control. Tomcat security
uses role-based authorization to manage access control. With this model,
access permissions are granted to a security role and access is allowed only to
the users or groups of users who are assigned this role.
You can think of roles as similar to groups in Unix-like operating systems
because access to specific web application resources is granted to all users
possessing a particular role (rather than enumerating the list of associated
user names). An individual user can have any number of roles associated with
their user name.
When a user accesses Unicenter NSM Web Applications, Tomcat security
enforces user authentication. The user ID and password the user provides is
sent to the Tomcat server for authentication.
Important! When using HTTP to communicate with Tomcat, the user ID and
password are not encrypted when they are sent from the web browser to the
Tomcat server. In a production environment, we strongly recommend that you
configure CA Web Server with SSL and use HTTPS as a secure transport
mechanism to ensure encryption of the user ID and password.
If authentication succeeds, Tomcat checks whether the user is assigned to a
role authorized to access the application. For example, Tomcat Administration
and Tomcat Manager applications only grant access to the users with the
manager role. The following table provides a list of roles authorized by
different web applications.
Application
Authorized Roles
Unicenter Configuration Manager
tomcat, admin, user
Web Reporting Server
tomcat, admin, user
240 Implementation Guide
Access Unicenter NSM Web Applications
Application
Authorized Roles
Adaptive Dashboard Services
tomcat, admin, user
Advanced Event Correlation Web User Interface
tomcat, admin, user
Tomcat Administration
manager
Tomcat Manager
manager
Tomcat security needs access to a database of user names and passwords that
identify valid users of a web application (or set of web applications), plus an
enumeration of the list of roles associated with each valid user. In Tomcat
security implementation, this database is called a Realm. Unicenter NSM Web
Applications support two implementations of Tomcat Realm, enabling
connections to two different sources of authentication information as follows:
MemoryRealm
Accesses authentication information stored in an in-memory object
collection, which is initialized from an XML document (conf/tomcatusers.xml). MemoryRealm is part of standard Tomcat functionality. For
more information on MemoryRealm implementation, see the Apache
website:
http://tomcat.apache.org/tomcat-5.5-doc/index.html
At startup time, MemoryRealm loads information about all users and their
corresponding roles from an XML document loaded from
CA_SHARED_COMPONENT_DIR/tomcat/5.5.23/conf/tomcat-users.xml.
Changes to the data in this file are not recognized until Tomcat is
restarted.
You can use the Tomcat Administration application to manage users,
groups, and roles used by the standard MemoryRealm implementation. If
for security reasons you want to limit access to the Tomcat Administration
application, it is possible to limit access to the web users on the local host
only, or a list of specified hosts. See the Apache website for detailed
instructions.
Important! For the standard MemoryRealm implementation, the user's
password is stored in tomcat-users.xml in clear text. In many
environments, this is undesirable because of security concerns. To avoid
the problem, the standard MemoryRealm implementations support the
concept of digesting user passwords. This allows the stored version of the
passwords to be encoded in a form that is not easily reversible. For more
information on digesting user passwords and MemoryRealm
implementation, see the Apache website.
Out-of-the-box, the CA Web Server is configured to use MemoryRealm.
MemoryRealm is not designed for production use. In the production
environment, we recommend running NSM Web Applications with the NSM
Security Realm.
Chapter 7: Post-Installation and Configuration 241
Enable Unicenter NSM Integration with eHealth Reports
NSM Security Realm
Accesses authentication information provided by Unicenter NSM security.
Unicenter NSM security authenticates the user using OS native
authentication. Access control is implemented based on Unicenter NSM
assets.
You can configure the choice of Realm used by Unicenter NSM Web
Applications using a web interface specific to the application. For more
information, see the online help for the particular application.
Access to Unicenter NSM Web Applications
Granting access to Unicenter NSM web applications when Unicenter NSM
security is enabled has the following requirements:
■
To access the Unicenter NSM web applications WRS, ADS, and UCM, the
user ID must be assigned to one of the default groups in the Unicenter
NSM security database. All security groups except PUBLIC have user
access by default.
■
To access Unicenter NSM applications as an admin user with administrator
authority, the user ID must belong to the SYSADMIN group
Enable Unicenter NSM Integration with eHealth Reports
eHealth and LiveHealth servers are configured to monitor the performance of
various nodes on a network. Similarly, Unicenter NSM is deployed and
configured to monitor various network devices and systems. Unicenter NSM
and eHealth integration is an Agent Technology (DSM) policy-based integration
that receives and processes the SNMP traps from your eHealth and LiveHealth
servers.
Real-Time Integration
The LiveHealth server is specifically for real-time network performance
monitoring and you can configure this server to send SNMP traps to the
DSM server. Once configured, the LiveHealth server sends nhLiveAlarm
SNMP traps to the DSM server when a performance threshold is violated.
When an alarm expires (that is, when performance returns to acceptable
levels), the LiveHealth server sends an nhClearLiveAlarm SNMP trap.
As the nhLiveAlarm/nhClearLiveAlarm traps are received by the DSM
server, the logic in the DSM policy processes these traps and updates or
creates managed objects with the appropriate status in the DSM and
appropriate corresponding managed objects in the WorldView database
tables of the MDB.
242 Implementation Guide
Enable Unicenter NSM Integration with eHealth Reports
Performance Trend Integration
You can also schedule Health reports from the eHealth server. If you
configure the eHealth server to forward SNMP traps to the DSM server
when a scheduled Health report runs, netHealthException SNMP traps are
generated and sent to the DSM server.
The DSM policy processes these netHealthException traps in a manner
parallel to the nhLiveAlarm and nhClearLiveAlarm traps with one major
difference: netHealthException traps are only generated when a scheduled
Health Report is run. These traps are indicating negative network
performance trends over time that may be currently affecting the
performance of some element that is being managed.
The nature of these traps and the fact that there is no corresponding
“clear” trap, causes the DSM policy to create netHealthException managed
objects in Agent Technology and WorldView with a status automatically set
at a low-level WARNING. Once these particular netHealthException objects
are created, the DSM policy does nothing more with them and you must
acknowledge and remove them when appropriate.
Your Unicenter NSM installation includes all of the integration policies
necessary for integration with eHealth reports. To enable these policies,
complete the procedures that follow.
See the Unicenter MCC online help for additional information about Unicenter
NSM integration with eHealth reports.
Enable the DSM Policy for eHealth
The DSM policy for eHealth lets Unicenter NSM create eHealth managed
objects, process eHealth alarms, and maintain the status of eHealth managed
objects. To enable the DSM policy for eHealth, start the DSM Wizard and mark
the eHealthSpace class as enabled.
To enable the DSM policy for eHealth
1.
Click Start, Programs, CA, Unicenter, NSM, Agent Technology, DSM
Wizard.
The DSM Wizard appears.
2.
Navigate to the Agent Selection page of the DSM Wizard and click the
check box next to the eHealthSpace agent name.
3.
Click Save.
The change is committed.
4.
Click Next until the Congratulations window appears.
Chapter 7: Post-Installation and Configuration 243
Enable Unicenter NSM Integration with eHealth Reports
5.
Click the Enable New Configuration check box.
6.
Click Finish.
Enable Alert Management Policy
Alert Management policy translates eHealth alarms into Unicenter alerts. The
following steps enable AMS policy.
To enable Alert Management policy
1.
Open a Command Prompt window on your AMS server.
2.
Enter the following command:
enableehealthAMS
The output from the command script appears as follows:
Install eHealth/AMS policy
adding event policy...
activating event policy...
adding alert policy...
The alert policy will not be activated until
the CA-Unicenter Alert Management service is
restarted.
eHealth/AMS policy has been installed.
3.
Go to the Services dialog of the Microsoft Management Console and restart
the CA-Unicenter Alert Management Service.
Enable eHealth Links in the Unicenter MCC
After enabling the eHealth DSM and ASM policies, the Unicenter MCC
automatically displays eHealth managed objects and any corresponding alerts.
You can also enable the display of the Links menu in the main Unicenter MCC
menu that contains actions to start the Business Service Console and the
eHealth Report Server.
To enable eHealth links in the Unicenter MCC
1.
On the MCC client machine, set your working directory to the
SC\CCS\WVEM\bin directory.
2.
Issue the following command:
cazipxp -u mcc_ehealth.caz
The Links menu is available the next time you start the Unicenter MCC.
244 Implementation Guide
Enable Unicenter NSM Integration with eHealth Reports
Configure eHealth Links in the Classical Interfaces
To launch eHealth reports from the Unicenter NSM classical interfaces such as
the 2D Map and NodeView, configure Unicenter NSM to specify the location of
the eHealth Web Server.
On your Unicenter NSM client machine, run the SeteHealthServer.exe
command.
The syntax for the command is as follows:
SeteHealthServer -h eHealthServerName -p ehServerPort -c ehServerProtocol
The eHealth server name is the only required parameter. The defaults for the
port and protocol are used if you omit them.
Example:
SeteHealthServer -h ehealthweb.company001.com -p 80 -c http
Discover eHealth Objects in Unicenter NSM Using the Discovery Gateway
Command-Line Utility
Before Unicenter NSM can start monitoring eHealth objects, the eHealth
objects must first be discovered and added to the WorldView repository. The
eHealth Discovery Gateway is a command-line utility that synchronizes the
objects discovered in eHealth with the objects that have been discovered by
Unicenter NSM.
The command has the following format:
dscvrehealth -h eHealthServerHostname -s ehealthServerPort -l -u ehealthUserId -p
ehealthPassword -wr WorldviewRepository -wu WorldviewUserid -wp WorldviewPassword
-t ElementType -a ElementAddress -f LogFileName
-d -?
-h eHealthServerHostname
Specifies the eHealth web server hostname or address. This parameter is
required.
-s ehealthServerPort
Specifies the eHealth web server port. The default value is 80 if you use
HTTP for the protocol. The default value is 443 if you specify the SSL
option.
-l
Enables SSL support.
Chapter 7: Post-Installation and Configuration 245
Enable Unicenter NSM Integration with eHealth Reports
-u ehealthUserId
Specifies the eHealth web server userid. The default value is admin.
-p ehealthPassword
Specifies the eHealth web server password. The default value is ehealth.
-wr WorldviewRepository
Specifies the name of the WorldView repository. This parameter is
required.
-wu WorldviewUserid
Specifies the WorldView repository userid. This parameter is required.
-wp WorldviewPassword
Specifies the WorldView repository password. This parameter is required.
-t ElementType
Specifies the element base type to discover. Valid values are
ROUTER,SYSTEM, or INTERFACE. The default is to discover all types.
Note: When using the -t flag, you must discover routers and switches
using the ROUTER option before using the INTERFACE option; otherwise,
any discovered child interface objects are discarded if the parent device is
not yet discovered.
-a ElementAddress
Specifies the IP subnet or address to discover. The default is to discover all
objects of the specified type. Use '*' as a wildcard to discover all devices in
a subnet range. For example, 192.168.* discovers all devices in the
192.168 subnet.
-f LogFileName
Directs output to a log file.
-d
Enables debugging information.
-?
Display command usage information.
Whenever new objects are added to eHealth, you must rerun the dscvrehealth
utility to resynchronize the two databases. Any objects that already exist in
both databases are skipped. Any objects that are defined in the eHealth
database but not in the WorldView repository are ignored.
246 Implementation Guide
Enable Unicenter NSM Integration with eHealth Reports
Note: Using an IP address correlates objects in the eHealth and Unicenter
NSM databases; therefore, the IP address assigned to a device in eHealth and
Unicenter NSM must match. If a device has multiple IP addresses assigned to
it, eHealth and Unicenter NSM must have discovered the device using the
same primary address; otherwise, the eHealth object is not added to the
WorldView repository. Also, since the correlation relies on static address for
devices, DHCP addresses are not supported.
Chapter 7: Post-Installation and Configuration 247
Chapter 8: Creating the Reduced-Size
Installation Image
This section contains the following topics:
Remote Agent Installation Using RSII (see page 249)
Prerequisites (see page 250)
Best Practices (see page 250)
How RSII Works (see page 250)
Create an Installation Image for Windows (see page 251)
Create Custom Response Files (see page 252)
About Response Files (see page 254)
Deploy the Agent-Only Installation Image (see page 254)
Remote Agent Installation Using RSII
The Reduced-Size Install Image (RSII) produces an agent-only subset of the
Unicenter NSM installation image. The agent-only image is considerably
smaller than the full Unicenter NSM image. The RSII image makes it easier for
you to send specific agents to remote computers using Unicenter Software
Delivery or another distribution application. The Adaptive Configuration service
is supported where applicable.
The agent-only installation image supports remote deployment using either
the Response file created with the RSII Image or one that you customize for it.
You can install or upgrade agents for the following Unicenter NSM versions
with RSII:
■
r11.2 Windows
■
r11.1 Windows
■
r3.1 Windows
Chapter 8: Creating the Reduced-Size Installation Image 249
Prerequisites
Prerequisites
Make sure that your system is ready to run the RSII:
■
Verify that you have at least 200 MB of free space per operating
environment.
■
RSII can upgrade Unicenter NSM r3.1 agents and r11.1 agents to
Unicenter NSM r11.2. Note the following, however:
–
If you already upgraded computers using the full Unicenter NSM r11 or
r11.1 DVD, you must continue to use the full DVD for later agent
installations and reinstallations.
–
If you are running only the Unicenter NSM r3.1 Systems Performance
agent on a Unicenter NSM r3.1 computer, upgrade the common agent
services by deploying the Log or System agent package before the
Systems Performance agent package.
Best Practices
To ensure that you create the agent-only installation image as efficiently and
accurately as possible, consider the following best practices.
■
Check CA Support for any updates to Unicenter NSM r11.2. Apply the fixes
before you create the installation image.
■
Use Windows as the operating system on your Unicenter Software Delivery
server.
How RSII Works
RSII makes it easier for you to send agents to client computers in your
enterprise. A few steps let you create the image and send the agents:
■
Create the installation image.
■
Create response files if you want to do a custom installation (see
page 254). Response files make unattended installations possible because
they contain answers to installation questions.
■
Register with Unicenter Software Delivery. This product supports a
multitiered architecture that lets you stage product installation images
across the enterprise and invoke the installation from a local software
store.
■
Deploy the installation image (see page 256). This indicates the systems
where you want to install the agents.
250 Implementation Guide
Create an Installation Image for Windows
Create an Installation Image for Windows
This procedure shows how to create an image that will install agents on
remote Windows servers.
Note: Use a Windows computer when you create an installation image for
Windows.
To create an installation image for Windows
1.
Make sure that you have the Unicenter NSM r11.2 GA DVD.
2.
Start the Unicenter NSM Product Explorer by double-clicking on
SETUP.EXE.
The Unicenter NSM Product Explorer appears.
3.
Select the item Installation Wizard for Unicenter NSM.
After a few moments the first page of the wizard appears.
4.
Select the option Create Reduced Size Install Image (RSII).
The edit control labeled "Enter full path and name of the response file" and
the Browse button are enabled.
5.
Enter the location and a response file name to use to create the RSII
image.
Use the Browse button to find a location to place the response file.
6.
Click Next and continue through the wizard changing options as needed.
You are not given the option of selecting any components during this
process. The components are preselected for you. They consist of the
following agents:
7.
■
System Agent
■
ADS Agent
■
Log Agent
■
WMI Agent
■
Script Agent
■
Event Agent
■
Performance Agent
Click Create on the Summary dialog to create the RSII image.
The response file you specified on the first wizard dialog is loaded with
your choices. The wizard creates the new image.
Chapter 8: Creating the Reduced-Size Installation Image 251
Create Custom Response Files
A status window appears indicating the progress of the image creation.
Completing the image takes approximately five minutes. Upon completion,
a message box displays the location of the new image. This location is
usually at %TEMP%\NSMRSII.
You can use the new image in exactly the same way as you use the GA
Unicenter NSM DVD. You can start the Product Explorer from this image
and then launch the Unicenter NSM wizard. The only thing you cannot do
is create an RSII image from an RSII image.
Create Custom Response Files
Plan Your Response Files
Make a list of all the types of agent installations you want to perform. For
example, some remote clients may require only system agents, others may
need only log agents, and so on. Create a separate response file for each item
on your list.
Note: You can use a combination of default response files and custom
response files.
Use a meaningful, descriptive file name for your response file because it
becomes the name of the Unicenter Software Delivery procedure that installs
the agents.
Note: Besides using the installation wizards to create response files, you can
also copy and rename response files.
Create Custom Response Files for Windows
You can create a response file that Unicenter Software Delivery can use to
install Agent Technology and Event agents on remote Windows servers.
Response files make unattended installations possible because the files contain
answers to installation prompts.
To create custom response files for Windows
1.
Create a directory to contain your custom response files using the
Command Prompt.
2.
Switch to the directory that contains the agent-only image.
3.
Enter the following command:
setup
The Unicenter Product Explorer opens.
252 Implementation Guide
Create Custom Response Files
4.
Expand Unicenter Agents for Windows.
Selections for available agents to install appear.
5.
For Agent Technology agents, select Installation Wizard for Unicenter NSM
Agents, and click Install.
The Welcome to the Unicenter NSM Install page of the Installation Wizard
opens.
6.
Alternatively, for the Event Agent, select Installation Wizard for Unicenter
NSM Event Agent, and click Install.
The Welcome to the Unicenter NSM Install page of the Installation Wizard
opens.
7.
Select Build Unicenter NSM response file for unattended install, and enter
or browse for the name of the directory you created in Step 1, then click
Next.
Note: Use a meaningful, descriptive file name for your response file,
because it becomes the name of the Unicenter Software Delivery
procedure that runs the unattended installation. The name appears in the
Unicenter Software Delivery catalog and you must be able to recognize it.
8.
Select the agents to install.
The wizard creates the response file.
Note: Repeat this step for every response file you need to create.
Create Custom Response Files for Systems Performance Agents on Windows
This procedure shows how to create a response file that Unicenter Software
Delivery can use to install Systems Performance agents on remote Windows
servers. Response files make unattended installations possible because the
files contain answers to installation prompts.
To create a custom response file for Systems Performance agents
1.
Create a directory to contain your custom response files using the
Command Prompt. Use the same directory where any other Windows
response files are located.
2.
Switch to the directory that contains the agent-only image.
3.
Enter the following command:
setup
The Unicenter Product Explorer opens.
4.
Expand Unicenter Agents for Windows, select Installation Wizard for
Unicenter NSM Systems Performance Agents, and click Install.
The CA Unicenter NSM Systems Performance wizard opens.
Chapter 8: Creating the Reduced-Size Installation Image 253
About Response Files
5.
Click Next. Enter a user name and company, select Generate a response
file, and click Next.
The Setup Type page appears.
6.
Follow the on-screen instructions.
Note: Use a meaningful, descriptive file name for your response file,
because it becomes the name of the Unicenter Software Delivery
procedure that runs the unattended installation. The name appears in the
Unicenter Software Delivery catalog and you must be able to recognize it.
The wizard creates the response file.
Note: Repeat this step for every response file you need to create.
About Response Files
Response files are text files that contain configuration information for an
installation. They are useful for unattended installations because no prompts
appear; all answers are in the response files. These files also provide an
effective way to perform multiple identical installations.
Note: Do not use response files created from a full-size Unicenter NSM r11,
r11.1, or r11.2 image. They may produce unexpected and incorrect results
and their use is not supported.
Note: You do not need to create response files if you will use only the default
response file created with the Image or will install the agents interactively. You
can skip this section.
Deploy the Agent-Only Installation Image
Interactive Installation
If you plan to install the agents interactively, you need not perform the actions
described in this chapter. Instead, run setup.exe and follow the on-screen
prompts.
Registration with Unicenter Software Delivery
Registration is the process of copying the agent-only image to the Unicenter
Software Delivery database.
254 Implementation Guide
Deploy the Agent-Only Installation Image
Register the Windows Image
This procedure shows how to register the agent-only image so that Unicenter
Software Delivery can install Windows, Systems Performance, and Event
agents on remote Windows servers.
To register the image for Windows
1.
Verify that all response files you are going to use are in the same
directory.
2.
Access the directory that contains the agent-only image.
3.
Enter the following command:
setup
The Unicenter Product Explorer opens.
4.
Expand Unicenter Products and Unicenter Agents for Windows.
Selections for available agents to install appear.
5.
Select Register Packages to Unicenter Software Delivery for Windows
Agents, and click Install.
The USD Registration dialog opens.
6.
Enter or browse to the directories that contain the agent-only image (Root
directory) and the response files, and click Register.
Note: We recommend that you use the Browse buttons to select the
directories.
The Choose Products to Register dialog opens.
7.
Select both packages, click Next, and follow the on-screen prompts.
The wizard registers the agent-only image.
Unattended (Silent) Installation on a Delivery Application
If you are using a software delivery application other than Unicenter Software
Delivery, check its exit code and use that application to transfer the agent
image and response files to the remote computer.
Use the following commands for the unattended installation in the different
operating environments. The commands install the agents using a previously
generated response file.
Windows
Installs all agents on Windows except the Systems Performance agent.
setup.exe -nt="full path and response file name" -cdpath="full path to this
setup.exe"
Chapter 8: Creating the Reduced-Size Installation Image 255
Deploy the Agent-Only Installation Image
Systems Performance on Windows
Installs Systems Performance agents on Windows. This command must be
in the directory \Windows\NT\SystemsPerformance.
setup.exe USE_THIS_RESPONSE_FILE="full path and response file name"
Deploy the Image to Unicenter Software Delivery
Deployment is the process of indicating to Unicenter Software Delivery where
you want to install the agents. The response file names become the names of
the Unicenter Software Delivery procedures that run the unattended
installations. These names appear in the Software Delivery catalog.
To deploy the agent-only install image, open Unicenter Software Delivery, and
drag and drop the agent package onto the systems or group of systems where
you want to deploy the image.
256 Implementation Guide
Deploy the Agent-Only Installation Image
The response file names appear when you open the procedures of the
registered agent package:
Note: For more information about Unicenter Software Delivery, see the
Unicenter Software Delivery Administrator Guide. You can view and download
this guide from CA Support Online.
Troubleshooting
This section contains information that may help you if you have any questions
or problems when creating or deploying the agent-only installation image.
More information:
Cannot Install the Agents (see page 258)
Start Menu Has an Empty Folder (see page 259)
Chapter 8: Creating the Reduced-Size Installation Image 257
Deploy the Agent-Only Installation Image
Cannot Install the Agents
Symptom:
When I try to install RSII agents over older agents, I get an error message
and the installation terminates.
Solution:
Try the following solutions:
■
Check the computer for a manager, and verify which agents are installed.
RSII upgrades agents only if the target computer has the following
configuration:
–
No manager component
–
The same agents or a subset of the agents in the RSII image
If the target computer has a manager or different agents, you must use
the full installation image copied from the DVD to install the agents.
■
■
258 Implementation Guide
If you are using RSII to upgrade Systems Performance r3.1 agents to
r11.2, you need to upgrade base Unicenter NSM first in one of the
following ways:
–
Run the r11.2 installation interactively on the remote computer. Select
nothing in the wizard and click Next repeatedly until you get to the end
of the installation.
–
Install another agent first, like the system agent, and then install the
Systems Performance agents.
Recreate the agent-only installation image if you applied a CA Support
patch to Unicenter NSM. If you applied any patches to the master image,
verify that the RSII image was recreated from the updated master image.
Deploy the Agent-Only Installation Image
Start Menu Has an Empty Folder
Symptom:
After I install RSII agents on a Windows computer, the Start menu has a
Books Online folder that is empty.
Solution:
You used a response file from Unicenter NSM r11.2 instead of RSII. Do not use
response files created from a full-size Unicenter NSM image even though they
may work in some cases. They may cause inconsistent results such as empty
folders on the Windows Start menu.
If a blank Books Online folder bothers you, you can remove it from the Start
menu. For more information, see the Unicenter NSM online help for Windows.
If you are going to use this agent-only installation image to install more
agents, you may want to recreate a response file using RSII, reregister with
Unicenter Software Delivery, and redeploy the image.
Chapter 8: Creating the Reduced-Size Installation Image 259
Chapter 9: Getting Started
This section contains the following topics:
Discover Your Network Infrastructure (see page 261)
Network Visualization (see page 262)
Discover Your Network Infrastructure
After you install Unicenter NSM, you need to discover the devices and objects
in your enterprise and begin to monitor them.
To discover the resources on your local machine
1.
Open the Unicenter MCC.
2.
Select Tools from the left pane drop-down menu.
3.
From the tools tree view, select Discovery Wizard.
The Discovery Wizard appears in the right pane.
4.
Click Next and proceed through the Wizard windows, indicating what is
appropriate for your environment.
If you choose to discover a subnet of your network, you have to supply
your subnet address, gateway and subnet mask in a subsequent dialog.
On the Discovery Mode window, select Faster Discovery.
Chapter 9: Getting Started 261
Network Visualization
5.
When you click Discover on the final Wizard window, Discovery runs.
Ultimately, the results window appears:
Network Visualization
Unicenter NSM WorldView offers a highly visual and naturally intuitive
approach to enterprise management with the 2D Map and WorldView GUIs.
The 2D Map works as an infrastructure navigator, letting you view any part of
your enterprise with the click of a button. For example, you can view all assets
in your network--from the global network to the local subnets, hubs, bridges
links, the servers and workstations connected to them, their processors and
drives, right down to the databases, and applications.
Unicenter MCC
The Unicenter Management Command Center is the primary interface for
managing your entire enterprise. The Unicenter MCC integrates all Unicenter
enterprise and network monitoring functionality into a single console. The
Unicenter MCC provides dynamic multi-viewer content relevant to any asset in
the MDB.
262 Implementation Guide
Network Visualization
The Unicenter MCC window has a left pane and a right pane. The views shown
in those panes structure data into usable, meaningful relationships. Views not
only show relationships within data and metadata, but also let you locate a
specific entity in the MDB. These different left pane and right pane
combinations let you completely customize the way you work in Unicenter
NSM.
You select a view from the drop-down list in the left pane, which displays
information in a tree format. After you select a subject in the left pane,
multiple standard viewers for that subject display content in the right pane.
You can also select from the right pane drop-down list to display details about
or modify the subject selected in the tree.
The left pane Topology view displays a hierarchical tree of all the entities
appearing in the Managed Objects folder in the 2D Map.
Web Reports
Unicenter NSM Web Reports are accessible from the Reports navigation tree in
the Unicenter MCC. These reports are obtained from the Web Reports server.
A valid user ID and password for the Tomcat server on which the Web Reports
option is installed must be sent to the server before accessing reports. When
requesting the first report each session, you are prompted to enter the user ID
and password.
Instead of being prompted once each session, you can check "Remember
these settings" when entering the user ID and password on the Connection
Settings dialog.
Chapter 9: Getting Started 263
Network Visualization
2D Map
The 2D Map is a two-dimensional, geographical representation of the logical
structure of your enterprise. It simplifies managing your eBusiness resources
by providing tools to customize visual representations of your business
enterprise. To access the 2D Map, select the Topology view from the left pane
drop-down list box of the Unicenter MCC, then select 2D Map from the right
pane’s drop-down list box. As the 2D Map starts, icons depicting these objects
appear arranged according to your network topology. Use the Topology view
simultaneously with the 2D Map to view the dependencies between managed
objects, their hierarchical relationships and links (parent-child) between them.
The 2D Map gives you direct access to the managed objects maintained in the
MDB. You can list objects, delete them, change the values of their properties,
enhance their definitions with comments and user-defined fields, add objects
to the MDB, and search and query object information in the MDB.
264 Implementation Guide
Network Visualization
Business Process Views
The 2D Map also addresses additional management needs by letting you
create customized Business Process Views. A Business Process View is a logical
group of managed objects you create, based on any criteria you determine,
such as geographic location, business process, security, and so on. A Business
Process View acts as a filter that displays only objects relevant to the
management of resources for a specific business requirement. For example,
you can create a Business Process View that displays only objects related to
your company’s accounting processing, another for payroll, and so forth.
Adaptive Dashboards
Unicenter NSM Adaptive Dashboards are accessible as right-pane data viewers
in the Unicenter MCC if you install the Web Reports and Dashboards option.
When requesting the first dashboard each session, you must enter the user ID
and password for the Tomcat server on which the Web Reports and
Dashboards option is installed.
Instead of being prompted once each session, you can check "Remember
these settings" when entering the user ID and password on the Connection
Settings dialog.
Chapter 9: Getting Started 265
Network Visualization
Managed Object Status
Another important feature of Unicenter NSM is the ability to display the
current, real-time status of any managed object. If a managed object
experiences a problem, its visual appearance in Unicenter NSM changes.
Using the Class Editor, you can assign the icon used to represent a class of
objects. The icon’s shape always remains the same, but the color changes
based on severity.
Several Unicenter NSM facilities control how the status of managed objects
appears on the 2D Map. First, up to ten severity levels can be set for every
class of managed object. To customize WorldView for your own environment,
you can set the color scheme for the icons that appear for each severity level.
Value of Objects in Your Network
You can define the value of an object in your network infrastructure by
assigning a numeric value from 1-100 that defines the degree of value of an
object in your network. The higher the weight, the more value an object has in
your network. Each class of ManagedObject has a default weight assigned to
it, and when your network is discovered, each object that is derived from that
class inherits the default weight for each class. For example, the default
weight of a router is higher than the default weight of a workstation because,
typically, a router has more significance in a network than an individual
workstation.
266 Implementation Guide
Network Visualization
You can change this weight value for each object to reflect the value of the
object in your network using the Status page of the Property Notebook. You
may want to assign a higher weight to a particular router because the router
affects more critical processes. For example, you may want to increase the
weight of the router that is connected to the computers that process your
company's payroll. Assigning a weight to an object helps give you a better
indicator of the overall health of your network infrastructure.
Object Importance
Using a sophisticated algorithm, WorldView determines the importance of each
managed object in your network. Letting you view the importance of each
managed object in your network helps you better analyze your network by
giving you a much better view of the health of your IT infrastructure. For
example, importance lets you quickly and easily distinguish between a printer
that has a critical severity because it is out of toner and a critical payroll
server that processes your payroll.
Importance is calculated using the weight and severity levels of child and
parent objects in your network. The importance of an object increases when
the propagated weighted severity of one of its child objects increases. You can
set the weight of each object in your network, or you can use the default
weight that is preset for each ManagedObject class.
Network Views
You can select the criteria (or property) you want to use to determine the
status of objects to view in the Unicenter MCC. The view of your network may
be entirely different depending upon the criteria you choose. Only the icon
colors associated with the object's severity change. You have the following
three property choices:
Maximum Severity
Specifies that you want to view the status of your network by the highest
severity of objects. The icon colors change to reflect the greater of the
true severity and the propagated severity of each object.
Maximum Weighted Severity
Specifies that you want to view the status of your network by the highest
weighted severity of objects. The icon colors change to reflect the greater
of the true weighted severity and propagated weighted severity of each
object.
Maximum Importance
Specifies that you want to view the status of your network by the highest
importance of objects. The icon colors change to reflect the greater of the
true calculated importance and propagated importance of each object.
Chapter 9: Getting Started 267
Network Visualization
Association Browser
The Association Browser lets you navigate different types of relationships
among objects. The hyperbolic tree helps you see what is happening in your
enterprise as you traverse nodes through associations.
To view the Association Browser, select Topology from the drop-down list box
of the left pane, and then select Association Browser from the drop-down list
box in the right pane. When the Association Browser appears, it shows the
selected object and all the objects with which it is directly associated.
Object Statistics
You can view statistics data, such as variance, number of children, and
average weighted severity (variance, mean, and nodal sum), for most
WorldView objects in the Topology or Business Process Views view in the left
pane.
Historical Information About Your Network
You can travel back in time to view historical information about your network
using the Unicenter Controller and Unicenter MCC Historian view. The
Unicenter Controller lets you set the clock to a time in the past, and the
Historian displays information for the specified point in time on timelines. The
Unicenter Controller opens automatically when you choose Historian view from
the right pane of the Unicenter MCC when historical information is available for
an object.
268 Implementation Guide
Network Visualization
The Unicenter Controller provides controls similar to those found on a VCR.
There are buttons for forward play and reverse play, and others for quickly
moving to key points in time. A dial lets you manually turn the clock back to a
desired time in the past.
For example, if you need to know what the state of a Printer 6B was during the
weekend, display the Historian for Printer 6B. The Unicenter Controller
automatically opens. From the Unicenter Controller, rotate the dial counter
clockwise to reach that date and time. When you release the mouse button,
the historical data for the printer is updated in the Historian view for Printer
6B.
The Unicenter Controller also allows you to display a list of objects that are
identified as being in a “critical” state. You select these objects from the
Unicenter MCC to be updated to present information. You can display specific
Business Process Views that you define.
Chapter 9: Getting Started 269
Chapter 10: Implementation Scenarios
This section contains the following topics:
Introduction (see page 271)
Scenario 1: Agentless Monitoring and Portal-Based Visualization (see page
271)
Scenario 2: Focused Visualization Using Weighted Severity (see page 279)
Scenario 3: Automated Business Views Using Dynamic BPV (see page 281)
Scenario 4: Event Management and Advanced Event Correlation (see page
283)
Introduction
This chapter describes ways you can implement Unicenter NSM to solve typical
requirements in today’s businesses. Illustrative scenarios explain the situation,
the Unicenter components you can use, and how to configure the components
to meet the business need.
Scenario 1: Agentless Monitoring and Portal-Based
Visualization
In this scenario, a system administrator needs to provide an internal service to
a department that includes monitoring IT devices and providing a dedicated
portal view on critical issues. Unfortunately, because of corporate policies
several machines cannot have any monitoring software installed on them.
The system administrator decides to use the Unicenter Remote Monitoring
feature to collect availability and performance information from the servers.
Whenever threshold values are breached, event messages are generated and
sent to Unicenter Management Portal for display in user-specific views.
The benefits provided by this solution follow:
■
Minimal effort to collect the data is required.
■
Collected data is turned into information for target groups:
■
–
For an administrator, the data is presented through the Unicenter
Remote Monitoring Administrative Interface.
–
For the system administrator, the data is presented through the
Unicenter MP user workplace.
The implementation is easy to maintain and extend.
Chapter 10: Implementation Scenarios 271
Scenario 1: Agentless Monitoring and Portal-Based Visualization
The products and components Unicenter NSM provides that the system
administrator uses to implement the solution are as follows:
■
Unicenter NSM--provides the basic management infrastructure, including
the MDB
■
Unicenter Remote Monitoring--provides its agentless monitoring
feature, including an engine and an administrative interface
■
Unicenter MP--provides a portal server that exposes Unicenter and other
content to users through a web browser
Installation
The implementation of the scenario for agentless monitoring and portal-based
visualization is a two-part process requiring installation of the components
followed by configuration of the components to present the visualization
solution. This section covers the installation part of that process.
Installation of the Management Machine on a Windows Server
The Unicenter NSM setup starts the Product Explorer with an installation
menu. Select the following options from the menu:
■
Unicenter NSM Installation Wizard--leads you through the main
installation process. You need to make at least the following selections:
–
MDB
–
WorldView Manager and Client
–
Event Manager
If you already have a Unicenter Manager with the MDB in your
environment, you can select the Administrative Client installation option.
■
Post-Installation Utilities
–
Unicenter Remote Monitoring
For additional information about the installations, see the Installation chapter
in this guide.
Installation of the Portal Server on a Windows or Linux/UNIX Server
We recommend that you use a dedicated computer for the portal server.
Unicenter MP installs separately from the base Unicenter NSM installation.
Select Unicenter Management Portal from the Product Explorer of the
Unicenter NSM Installation DVD. No specific selections are required. For
detailed information about the installation, see the Unicenter Management
Portal Installation Guide.
272 Implementation Guide
Scenario 1: Agentless Monitoring and Portal-Based Visualization
Configuration
The implementation of the scenario for agentless monitoring and portal-based
visualization is a two-part process requiring installation of the components
followed by configuration of the components to present the visualization
solution. This section covers the configuration part of that process.
Configure Unicenter Remote Monitoring
The configuration monitors a set of services and a few system parameters for
all Windows servers.
To set up monitoring using the Unicenter Remote Monitoring AI
1.
Connect to a Unicenter Remote Monitoring agent.
2.
Select Windows, Template to define a Windows template.
The Windows Template dialog appears.
3.
Enter the server name in the Node field to base the template on one of the
servers, and then click Discover.
Some system metrics such as Available Memory and Processor Load are
already enabled by default.
4.
In the Services tab, select the Windows services you want to monitor and
the expected state.
5.
Click OK.
Chapter 10: Implementation Scenarios 273
Scenario 1: Agentless Monitoring and Portal-Based Visualization
6.
Select Windows, New to define servers based on this template.
The New Windows resource dialog appears.
This is a web server, so the Expected State for the WWW service should be
changed to running.
7.
Click OK.
The server is discovered and its settings are saved. Repeat this step for all
servers you need to monitor.
For detailed information about Unicenter Remote Monitoring, see the
Administration Guide and the online Unicenter Remote Monitoring help.
274 Implementation Guide
Scenario 1: Agentless Monitoring and Portal-Based Visualization
Configure a Unicenter MP Workplace
After you configure and publish an event view portlet to Unicenter MP, a portal
user who belongs to the Windows Systems Administrator group can select the
published Unicenter Remote Monitoring portlet for the workplace definition.
To add a portlet to the workplace
1.
Select or create a Workplace and click Add Content.
The Add Content to Workplace screen appears.
2.
Select the portlet you want to display and click Add To Column.
The selected portlet appears in the column on the right pane of the screen.
3.
Click OK.
The portlet is added to the workplace.
The Workplace appears with data.
Chapter 10: Implementation Scenarios 275
Scenario 1: Agentless Monitoring and Portal-Based Visualization
Configure and Publish a Unicenter MP Event View Portlet
The configuration task for Unicenter MP is to define an event view portlet that
the Windows system administrator can use in a portal workspace. This
configuration requires Unicenter MP administrative privileges.
To define an event view portlet
1.
Start Unicenter MP and navigate to Knowledge, Library, Enterprise
Management, and expand Unicenter Event Management.
2.
Select Configure Event Filters to define an event filter.
3.
Create a new filter group, name it URM, and save this setting.
4.
Add a new filter and name it URM All to reflect all event messages related
to Unicenter Remote Monitoring. Assign permissions for the workgroup
Windows System Administrator and save the settings.
Then add the filter criteria as follows:
■
Property:
Message
■
Condition:
startsWith
■
Value:
URM
Click Back to view the filter definition.
You can define additional filters for specific Unicenter Remote Monitoring
metrics in the same way.
5.
Select Event Console from Knowledge, Library, Enterprise Management,
Unicenter Event Management to define an event portlet named URM All.
6.
In the content view, select the Configuration tab.
276 Implementation Guide
Scenario 1: Agentless Monitoring and Portal-Based Visualization
7.
Select the newly-created URM All filter in the Available column and click
the forward arrow to move the filter to the Selected column.
Chapter 10: Implementation Scenarios 277
Scenario 1: Agentless Monitoring and Portal-Based Visualization
8.
9.
Publish the portlet by specifying the following parameters:
■
View Name:
URM All events
■
Permission:
View: Workgroup / Windows System Administrator
■
Channel:
MyViews
Publish Business Process Views by selecting Knowledge, Library, Enterprise
Management, Business Processes, and then select _Configure BPV
Summary View.
10. Select New for the WV-Business Process Views scoreboard and then select
the Remote Monitoring Business View.
278 Implementation Guide
Scenario 2: Focused Visualization Using Weighted Severity
11. Check the option boxes Include Summary and Portal Explorer and publish
the new view as URM Objects view.
Scenario 2: Focused Visualization Using Weighted Severity
In this scenario, an operator is confronted with dozens of critical objects that
need intervention. The administrator’s concern is to attend to the most critical
problems first.
The administrator decides that the Unicenter Management Command Center
can provide the solution. The administrator can take the following steps:
■
Assign higher severity weights to objects of specific interest.
■
Specify sort and display rules based on importance.
The benefits provided by this solution follow:
■
Abnormalities on important systems are addressed first.
■
Visualization of the critical objects is easy to understand because the
display is laid out clearly.
■
Problems are solved faster.
The products and components provided by Unicenter NSM that the system
administrator uses to implement the solution is as follows:
■
Unicenter NSM--to provide the Unicenter MCC component.
Chapter 10: Implementation Scenarios 279
Scenario 2: Focused Visualization Using Weighted Severity
Assign Severity Weights
The implementation of the scenario requires the system administrator to
assign severity weights to server objects and set sort and display rules for the
critical objects in the Unicenter MCC.
To assign new severity weights to server objects
1.
Select a server object from the Unicenter MCC Topology View or Business
Process View, right-click and select Add Viewer, Properties from the
context menu.
The Property Notebook for the server object appears.
2.
Modify the weighted severity for all servers that require extra attention.
You can use the importance in Unicenter MCC as sort and object color
criteria.
By default, the object color is determined by the propagated severity and
the sort order is by object name ascending.
3.
Right-click in the viewer’s white space to open the Sort context menu and
change the sort criteria to Importance / Descending.
4.
Select View, Status Display Rule in the Unicenter MCC menu bar to change
the object color criteria to Maximum Importance.
The most important server appears in the upper left followed by your other
servers in descending order of importance.
280 Implementation Guide
Scenario 3: Automated Business Views Using Dynamic BPV
Scenario 3: Automated Business Views Using Dynamic BPV
In this scenario, a company rule requires the presence of location information
in the system SNMP MIB. The server objects in the topology map need to be
displayed in folders that represent this information.
The system administrator decides that Business Views and Dynamic BPV are
tools that provide a solution. Rules allow for dynamic objects.
The benefits provided by this solution follow:
■
Automatic assignment of objects to business-centric views
■
Resource-specific status aggregation and display
■
Improved operator focus on abnormal situations
The products and components provided by Unicenter NSM that the system
administrator uses to implement the solution follow:
■
Unicenter NSM--to provide the WorldView component Dynamic BPV.
Configuration and visualization employ the Unicenter MCC component.
Define Business Process Views to Show Location
The implementation of the scenario to provide automated business views
requires defining Business Process Views in the Unicenter MCC that show
location information. This information is part of the server object properties
that are collected during the IT discovery.
Chapter 10: Implementation Scenarios 281
Scenario 3: Automated Business Views Using Dynamic BPV
To define Business Process Views to show location
1.
In the Unicenter MCC Business Process Views navigation pane, right-click
the BPV parent object and select New, Business Process View to create a
new BPV. In the Properties view for this new BPV, specify FirstFloor as the
name and the label.
2.
Reclassify the FirstFloor object to the DynamicBPV class by right-clicking
on the object to open the context menu and selecting Reclassify, Business
View, DynamicBPV.
3.
Right-click the FirstFloor object to open the context menu again and select
Viewers, Dynamic BPV Editor.
4.
Define the rules that define membership to the FirstFloor folder.
This rule selects Windows 2003 servers and workstations that have “L1” as
part of their location string.
5.
282 Implementation Guide
Click Save to save the view and populate the folder.
Scenario 4: Event Management and Advanced Event Correlation
You can repeat these steps for additional views like GroundFloor,
SecondFloor, and so forth. Then, you can arrange all these business views
in a hierarchy reflecting your real-world environment.
Scenario 4: Event Management and Advanced Event
Correlation
In this scenario, a system administrator wants to receive events for Windows
servers at the console whenever there are both physical and virtual memory
shortages.
The system administrator determines that the Advanced Event Correlation
(AEC) component will provide the solution. AEC provides not only root cause
analysis but also Boolean logic on events. AEC generates aggregated events
that can be forwarded to the Alert Management System (AMS).
Chapter 10: Implementation Scenarios 283
Scenario 4: Event Management and Advanced Event Correlation
The benefits provided by this solution follow:
■
Consolidated event messages
■
Improved operator focus on abnormal situations
The products and components provided by Unicenter NSM that the system
administrator uses to implement the solution follow:
■
Unicenter NSM--AEC is part of Event Management
Configure AEC to Receive Events at the Console
To implement the solution of configuring AEC to receive events at the console
when there are physical and virtual memory shortages, the system
administrator begins by creating a rule using the AEC Interactive Development
Environment (IDE).
To create a rule using IDE
1.
Open the Windows EM Classic GUI, Event, and AEC Policies.
The AEC Policies Summary dialog appears.
284 Implementation Guide
Scenario 4: Event Management and Advanced Event Correlation
2.
Select AEC Policies New.
The Select Rule Type dialog appears.
3.
Select General Boolean and click OK.
The Advanced Event Correlation IDE window appears.
The left pane provides basic instructions for policy authoring. Review the
instructions for additional background information.
Chapter 10: Implementation Scenarios 285
Scenario 4: Event Management and Advanced Event Correlation
4.
In the tree view, select the rule node [BOOL, TEMPLATE] and enter the
following values in the right pane:
■
Name
WindowsMemEx
■
Override Maturity
TRUE
■
Maturity Seconds
3600
■
Reset Seconds
0
The maturity is the lifetime of the rule instance that starts as soon as the
first event matches. The rule instance expires when the second event
arrives by not later than after 3600 seconds.
5.
Expand the rule note [BOOL, TEMPLATE] and then expand the AND
operator node.
The AND operator node shows two children, Event A and Event B.
6.
Right-click on Event A and select the wizard to define the first event.
The Logical Operator Configuration Wizard dialog appears.
7.
286 Implementation Guide
Enter the following settings:
■
Item Name
WindowsPhysMem
■
Enable local reset
request event
checked
Scenario 4: Event Management and Advanced Event Correlation
8.
Click Next.
The Event Configuration Wizard Match Event dialog appears.
9.
Specify event attributes that match any event console message that
reports the status change to Warning or Critical for the physical memory
metric on any host machine:
■
Message template
Host:.*caiWinA3 Trap WinA3_MemPhys .*
(Warning | Critical) Physical
■
Node
&(NODE)
10. Click Next twice.
You do not need to make any entries in the dialog you skip.
Chapter 10: Implementation Scenarios 287
Scenario 4: Event Management and Advanced Event Correlation
The Event Configuration Wizard Reset Request Event dialog appears.
11. Specify the event attributes to request that if the status changes back to
Normal during the lifetime of the rule, the AND condition does not apply
and the rule should be reset.
■
Message template
Host:.* caiWinA3 Trap WinA3_MemPhys
(Warning | Critical) Repaired Physical
■
Node
&(NODE)
12. Click OK to finish the definition and terminate the wizard.
The configuration in the second item (Event B) is similar.
1.
Right-click on Event B in the Logical Operator Configuration Wizard dialog
and select the wizard to define the second event.
Use the following settings:
2.
288 Implementation Guide
■
Item name
WindowsVirtMem
■
Enable local reset
request event
checked
In the Match Event dialog, use the following settings:
■
Message template
Host:.* caiWinA3 Trap WinA3_MemVirt .*
(Warning | Critical) Repaired Virtual
■
Node
&(NODE)
Scenario 4: Event Management and Advanced Event Correlation
3.
In the Reset Request Event dialog, use the following settings:
■
Message template
Host:.* caiWinA3 Trap WinA3_MemVirt
(Warning | Critical) Repaired Virtual
■
Node
&(NODE)
Finally, define the message that is generated when both events arrive and the
AND rule evaluates to true.
1.
Start the wizard from the [BOOL, TEMPLATE] rule node and move forward
to the root correlation event definition screen to modify the default
message template with the following:
■
RCA: &(NODE) high memory utilization (virtual and physical)
2.
Save the new AEC policy by choosing File, Save As) and give the new
policy a name (for example, WindowsMemEx).
3.
For test purposes, you can perform rule processing inside the IDE by
choosing Options, Start Test Engine.
4.
Otherwise, deploy the rule to any Event Management node by choosing
File, Deploy policy.
In any case, when the related events arrive the console messages appear
similar to the following:
Chapter 10: Implementation Scenarios 289
Appendix A: DIA Reference
This section contains the following topics:
DIA Introduction (see page 291)
DIA Architecture (see page 292)
Consumer Applications (see page 297)
How DIA Works (see page 301)
Advantages and Primary Functions (see page 304)
DIA Configuration (see page 312)
Troubleshooting and Diagnostics (see page 327)
DIA Introduction
Distributed Intelligence Architecture (DIA) allows a central location to manage
all components and aspects of a network. DIA makes data requests and
retrievals standard across different Unicenter NSM components by providing a
generic mechanism that permits the dynamic deployment of necessary files to
facilitate the correct monitoring of any given system. Deployment is generic
and open to growth. DIA allows for high-speed, secure communications to
transport data while providing remote node management and inherent failover
capabilities.
DIA is the underlying architecture upon which to build your system. It serves
as the common communication and data collection interface that monitors
your entire system.
DIA is IPv6 compliant. You can deploy DIA on pure IPv6 systems and across
IPv4 and IPv6 systems.
DIA supports all the clustering services and platforms which are supported by
HAS.
Note: For more detailed information on the major functions of DIA, see the
Advantages and Primary Functions section. For configuration information, see
the DIA Configuration section.
Appendix A: DIA Reference 291
DIA Architecture
DIA Architecture
DIA is composed of the following components that execute its functions:
■
Knowledge Base
■
Dynamic Node Administrator
■
Genes
■
Cells
■
Grid
292 Implementation Guide
DIA Architecture
Unicenter Knowledge Base
The Unicenter Knowledge Base is the central communication and management
point for DIA, serving as the interface for the outside world in the DIA system.
A Knowledge Base consists of a core, a Dynamic Node Administrator interface,
a consumer interface, and a plug-in interface. It is a logical grouping of
Dynamic Node Administrator hosts that collects data from several sources and
abstracts the original location of the information. The Knowledge Base
performs all of the following functions:
■
Detects and locates the Dynamic Node Administrator
■
Seeds the Dynamic Node Administrator
■
Manages and deploys DNS nodes based on configuration parameters to
make them management enabled
■
Collects and manipulates data from various data sources and shares them
across DIA components
■
Routes consumer requests to the correct locations
■
Performs proxy and port brokering for nodes located behind firewalls
■
Distributes work to the Dynamic Node Administrator
■
Creates an abstracted view of data
Note: The Knowledge Base uses Java Remote Method Invocation (RMI) as the
communication mechanism to the consumers.
All the Unicenter Knowledge Bases in the DIA environment communicate with
each other and synchronize their information through the MasterKB. Through
this environment, a Knowledge Base can get information about any host
without knowing its location or other details. To request host information,
query the nearest Knowledge Base and submit the request. The Knowledge
Base routes the request to the appropriate location, abstracts the information,
and returns the result of the request in a generic format.
The MasterKB in a Unicenter NSM installation is indicated by the presence of
an SRV entry in DNS. This entry points all of DIA to one or more Knowledge
Bases and allows for automatic configuration of the grid and managed hosts
based on policy. The primary Master Knowledge Base is assigned by virtue of
having the lowest priority number in the SRV record listing. The other higher
priority number is considered secondary Knowledge Base. For example, the
primary has a priority of 1 and the secondary Knowledge Bases have priorities
of 2.
Once any Knowledge Base starts, it looks for the presence of the SRV record
and then contacts that Knowledge Base to perform several tasks. First, it is
processed in policy to determine zone information; next, it is synchronized in
the grid; and finally, it sends to the grid any information about itself to update
the grid for its managed objects.
Appendix A: DIA Reference 293
DIA Architecture
On startup of any DIA object, Knowledge Base or Dynamic Node
Administrator, the SRV record is queried and the information is used to
connect to the Master Knowledge Base to have the host processed in the policy
engine. This determines which zone to use for each of the Knowledge Bases
and which Knowledge Base will manage which Dynamic Node Administrator;
that is, where each Dynamic Node Administrator should activate. The existing
zone policy file performs two functions: to determine and control the zone
information and to determine and control the activation information.
The only interaction with DNS from a DIA perspective is to query the DNS
information to determine where the network service for DIA is running (occurs
only once during startup). The DNS information indicates where the primary
and secondary Knowledge Bases are running. Normal host resolution is also
performed as new targets come online or as IP addresses change. There is
very little impact to DNS with this technology.
Note: Because all Knowledge Bases are in full communication with each other,
you only need to connect to one Knowledge Base at a time to access all
systems. Upon connecting, you can dynamically switch to another Knowledge
Base at any time.
Consumer Interface
The consumer interface is a collection of methods used to submit requests to
the Knowledge Base. The consumer interface is the entry point for applications
external to DIA to submit requests for data, enable cells, and enable a host on
the network. Examples of applications through which you can interface include
Unicenter Management Portal and Unicenter Web Services.
The SDK provides clean, easy to use APIs that allow secure connections to the
Knowledge Base. Requests are sent in to the consumer interface and
responses are sent back out. The response is then passed into the DIA
decoder to supply the data in the format requested.
Dynamic Node Administrator
The Dynamic Node Administrator, the smallest subcomponent needed to hook
into the DIA system, cultures the growth of knowledge for Unicenter
components by seeding the system. It gives the host system all the necessary
components for users to make intelligent system management decisions based
on the available information.
The two main tasks of a Dynamic Node Administrator are:
■
Recognition
■
Gene Management
294 Implementation Guide
DIA Architecture
A Dynamic Node Administrator is also responsible for the following:
■
Making the system Management Aware
■
Monitoring the system
■
Providing a central location to acquire information from the system
Each Dynamic Node Administrator reports to a single Unicenter Knowledge
Base (usually the nearest one, but configurable based on policy). A Knowledge
Base in turn has many Dynamic Node Administrators reporting to it. The
Knowledge Base distributes incoming work requests to the Dynamic Node
Administrator. The Dynamic Node Administrator uses a domain lookup to
determine the location of the Knowledge Base and which systems it can
activate to. This process allows DIA to automatically locate Knowledge Bases
and get Dynamic Node Administrator systems inserted into the Dynamic Node
Administrator grid.
You can configure the Dynamic Node Administrator to have a specific
Knowledge Base as the owner using the autoactivatedna.bat or
autoactivatedna.sh file. Simply provide the name of the Knowledge Base to
which you want to assign the Dynamic Node Administrator as a parameter in
the file. If you do not specify this information, the product performs an SRV
lookup to determine the best Knowledge Base to use based on network and
domain information.
Notes:
■
Once a Dynamic Node Administrator is autoactivated to a Knowledge Base,
it cannot be reactivated by rerunning autoactivatedna.bat or
autoactivatedna.sh. You must use the DIA Diagnostic Tool.
For more information on the autoactivatedna.bat file, see the
Troubleshooting and Diagnostics section in this appendix.
■
When you install the Dynamic Node Administrator with the DIA Diagnostic
Tool on a remote system, run autoactivatedna.bat manually on this remote
system after the installation is completed successfully.
Gene
The gene is an interface between the cells and the Dynamic Node
Administrator. The gene is responsible for the following:
■
Cell inventory
■
Encryption and decryption
■
Work order acceptance
Appendix A: DIA Reference 295
DIA Architecture
Cells
Cells are the primary mechanisms for acting on existing data. They are dataor command-specific modules that collect any type of information from any
given type of data source and therefore are responsible for the knowledge of
the abstracted entities on which they are instructed to operate. Cells plug
directly into the gene interface to collect data and are responsible for any type
of communication needed for the data manipulation they support.
Each cell isolates itself from all other entities and starts in its own
environment, independent of the Dynamic Node Administrator and other cells,
so that it remains abstracted from the Dynamic Node Administrator
environment. This results in enhanced security and stability. All consumers can
request data from any given cell by using a specific framework.
Cells are either in Java or C/C++ format (which uses a Java/JNI interface).
Every cell is lightweight with a Java component; however, when a cell needs
native C/C++ code to make calls to the legacy code, it has a C/C++
component as well.
In general, you manually enable cells only when they are required. This
conserves the resources they consume. The cells installed with Unicenter NSM
are an exception. Unicenter NSM installs, registers, enables, and starts the
following cells by default as part of the Unicenter NSM installation process
because they are required for Unicenter NSM to function:
■
Agent Control cell
■
DSM Control cell
■
WVObject cell
■
MDB cell
■
CAEM cell
■
CAAMS cell
Note: These cells can be registered even if the Dynamic Node Administrator is
not yet activated to a Knowledge Base, but starts running only after the
Dynamic Node Administrator is activated.
The PDI (Package Deployment Infrastructure) cell is also installed with
Unicenter NSM. The PDI cell is a DIA internal cell, but to conserve resources it
is not enabled by default. Enable the PDI cell when you want to use DIA's
package deployment feature. You can deploy and start a DIA internal cell
using the DIA Diagnostic Tool. However, support is not available for the PDI
cell, even though it is shipped with Unicenter NSM.
296 Implementation Guide
Consumer Applications
DIA Grid
The DIA grid determines the network location of particular DIA system
elements. The grid allows users to route requests to any machines in the
current DIA architecture. In other words, all DIA aware components can talk to
any other DIA aware components without knowing specifics about each other.
Users can make requests to any Unicenter Knowledge Base in the system and
the grid will route it correctly for data retrieval.
Once you submit a request to the system, DIA formats the request, moves and
issues it, and finally returns it to the requester, all based on information
contained in the grid.
The grid seeks out the following information between all Knowledge Bases:
■
What is available
■
Version information
■
How each message should be passed around the DIA system
Consumer Applications
Consumer applications interact with DIA through the consumer interface to
submit requests, enable cells, and enable hosts. Each application interfaces
with DIA for a specific purpose, and each application has potential problems
that may occur between DIA and the component. The main DIA consumer
applications are as follows:
■
Adaptive Dashboards Server (ADS)
■
Management Command Center (MCC)
■
Unicenter Management Portal (UMP) and Web Reporting Services (WRS)
■
Unicenter Remote Monitoring (URM)
■
WVObject Cell
See the topics that follow for an explanation of what each of these main
consumers uses DIA for and ways to solve problems that may occur when
interfacing.
Appendix A: DIA Reference 297
Consumer Applications
Adaptive Dashboards Server
Adaptive Dashboards Server (ADS) uses DIA for registration and updates. It
uses the Unicenter Knowledge Base as the interface to get information from
the cells regarding the different enterprise resources that need to be displayed
in the dashboards.
Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and
running locally or on a remote system that can be queried for information. In
addition to that, the dsmcell and the agctrlcell must be registered and active
to collect the information.
Potential Problems: Being a web-based application using Tomcat, the
dashboards may not be visible. The first thing to check is whether the Tomcat
server is up and running.
From the DIA perspective, if the dashboards application is not able to connect
to the Knowledge Base, it will not be able to show the latest information. In
this case, check the ukb0.log file to determine the exact reason.
If Tomcat and the Knowledge Base are both working properly, open the diatool
to verify that both the dsmcell and agctrlcell are working properly. If there is a
problem you can de-register and then reregister them. The cell-specific logs
can also provide a precise cause of the failure.
Management Command Center
The Unicenter Management Command Center (Unicenter MCC) uses DIA for
the correct and timely updates of status and other information that needs to
be used and displayed.
Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and
running locally or on a remote system that can be queried for information. In
addition, the amscell, mdbcell and the event cell must be registered and active
to collect the information from and send it to the Unicenter MCC.
Potential Problems: The Unicenter MCC has various views. The views that
are dependent on DIA could have trouble displaying the correct information
when the Dynamic Node Administrator or the Knowledge Base services are not
running properly.You must ensure that all the required cells are functioning
properly.
298 Implementation Guide
Consumer Applications
Unicenter Management Portal & Web Reporting Services
Unicenter MP and Web Reporting Services (WRS) are DIA clients and use it for
registration and updates. They use the Unicenter Knowledge Base (local or
remote) as the interface to get information from the cells (local or remote)
regarding the different enterprise resources that need to be displayed in the
dashboards.
Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and
running locally or on a remote system that can be queried for information. In
addition, the following cells are required for gathering the information:
■
wvobjectcell
■
caamscell
■
dsmcell
■
evtcell
Potential Problems: Most functionality is unavailable when DIA or the cells
are down. No reporting data is displayed. You will see the "unable to retrieve
data" messages and other messages that only a System Administrator will be
able to understand.
Restarting the Unicenter Knowledge Base is probably not possible since it is
unlikely the Knowledge Base is local to the Tomcat server. See the ukb0.log
file for more details
If Tomcat and the Unicenter Knowledge Base are both working properly, open
the DIA Diagnostic Tool to verify that both the dsmcell and agctrlcell are
working properly. If there is a problem, try deregistering and then
reregistering them. The cell-specific logs could also provide precise cause of
the failure.
Unicenter Remote Monitoring
Unicenter Remote Monitoring uses the DIA C-Gene – the communication
component of DIA – to communicate between the Administrative Interface and
Unicenter Remote Monitoring Agents.
Pre-requisites: DIA Dynamic Node Administrator must be installed and
running on both the Unicenter Remote Monitoring Agents and the
Administrative Interface nodes.
Potential Problems: Unicenter Remote Monitoring uses DIA for its
communications. If the Dynamic Node Administrator service fails or is stopped
on either the agent or the admin node, then this communication fails and you
get an error message “Communication with the agent failed”
Appendix A: DIA Reference 299
Consumer Applications
You can also get this error message if the Dynamic Node Administrator is
running, but it is not activated properly to the Unicenter Knowledge Base. That
is, the libraries required for communication have not been pushed to the
Dynamic Node Administrator by the owner Knowledge Base. To confirm this,
check for the cgeneclient.dll library in the dna/lib directory. If this file is not
present, it means that the Dynamic Node Administrator was not activated
properly.
WVObject Cell
The WVObject cell depends on the Dynamic Node Administrator and the
Unicenter Knowledge Base. It uses both the native and non-native API. The
location of the registration and deregistration batch files are:
InstallPath\CA\SC\CCS\WVEM\Bin
The registration batch file is regwvcell.bat
The deregistration batch file is unregwvcell.bat
Potential Problems: Following are problems that a user might face with
regards to the WVObject cell:
■
Cannot connect to cell
■
No data from cell
To debug the problems related to the WVObject cell, do the following:
■
Check whether the WVObjectcell.exe, Dynamic Node Administrator and
Unicenter Knowledge Base are running. Start them if they are not running.
■
Check whether the Severity Propagation Service and the database are
running. Start them if they are not running.
300 Implementation Guide
How DIA Works
How DIA Works
An understanding of how the DIA process works is necessary to know how
your network is managed by one central location. The DIA process entails the
initial configuration and subsequent processing of information across the IT
infrastructure as follows:
Configuration
■
The Knowledge Base detects a Dynamic Node Administrator and creates
the required genes to support the current local installation; Dynamic Node
Administrator recognition is automatic and configurable.
■
The Dynamic Node Administrator recognizes software components and
operating system attributes that Unicenter may be interested in
monitoring.
The following inventories are created:
■
Knowledge interfaces in a Knowledge Base
■
Software and services in each Dynamic Node Administrator
environment
Information Processing
■
As requests come into the Unicenter Knowledge Base from consumers,
they are sent to the appropriate nodes for data collection. The Unicenter
Knowledge Base collects information from multiple sources like Event
Management, WorldView, Agent Management, and Unicenter NSM agents.
■
The Unicenter Knowledge Base takes all information obtained during
detection and deployment and populates the grid. If a Knowledge Base
goes down, all managed nodes are adopted by another Knowledge Base.
Information is instantly replicated across all Knowledge Bases.
■
Consumers like Unicenter MP or Web Services issue requests to the
Unicenter Knowledge Base and the Knowledge Base submits those
requests to the systems that it knows about based on information
gathered when the system was enabled.
Appendix A: DIA Reference 301
How DIA Works
Utilities
The following utilities, used to configure and test the product during the
development phase, evolve frequently and have a limited availability:
Detection and Deployment
The detection and deployment utility locates all of the Dynamic Node
Administrator in a given IP address range and, if a Dynamic Node
Administrator is present, describes its state. This utility also deploys cells
to all systems with a Dynamic Node Administrator.
Console
The console utility gets console data, displays attributes of console
records, and filters console messages. This utility is currently in the form
of the console log GUI (a way to test the console log knowledge module).
It lets you collect the contents of the log file to any system running the
utility without having to map a network drive or install other components.
WorldView Registration Service
The WorldView Registration Service is a DIA service that lets one machine
in the DIA grid act as a server for registering and processing status
changes of Unicenter components. There is one WV Registration Server for
each DIA zone. The switchwvregsrvr command line utility lets you switch
the WV Registration Server that is registered with DIA. The utility usage is
described in the online CA Reference under WorldView Executables.
DIA Diagnostic Tool
The DIA Diagnostic Tool is a component of Unicenter NSM that lets you
troubleshoot and manage all aspects of your DIA infrastructure from any
Knowledge Base. The DIA Diagnostic Tool is designed for administrative and
support personnel rather than end users.
The DIA Diagnostic Tool is installed as part of the Knowledge Base installation
and is located in the InstallPath\DIA\dia\ukb\bin directory. You can run the
tool from this directory.
Note: To run the DIA Diagnostic Tool to a non-english Knowledge Base,
modify the diatool.bat file by adding the following case-sensitive option:
-DAuth="false"
The option must follow the line:
-DCA_DIA_HOME="%CA_DIA_HOME%"
302 Implementation Guide
How DIA Works
Run the DIA Diagnostic Tool
Run the DIA Diagnostic tool to monitor all aspects of your DIA infrastructure.
To run the DIA Diagnostic Tool
1.
Do one of the following:
■
On Windows, run the following command in the
InstallPath\DIA\dia\ukb\bin directory:
diatool.bat kb host
■
On Linux or UNIX, run the following command in the
$CA_DIA_HOME/dia/ukb/bin directory:
./diatool.sh kb host
kb host
Specifies the name or IP address of the knowledge base to which you
want to connect.
The Knowledge Base Login screen appears.
2.
Enter a valid Administrator or root user name and password that has
access to the knowledge base you specified and click Connect.
An admin group or root equivalent is also acceptable.
The following message appears when the login is successful:
Disclaimer: Caution!!!
Improper usage of this tool might cause irreversible damage on your Knowledge
Base grid, especially making a change like moving (floating) a DNA node to a
different Knowledge Base node. Note that a corrupted grid will get propagated
to all the known Knowledge Bases, so make sure you know exactly what you are
doing before making changes to the grid. Click "Yes" to proceed or "No" to
exit the tool.
3.
Click Yes on the disclaimer to proceed with the tool.
The DIA Diagnostic Tool main window appears.
Note: See the DIA Diagnostic Tool help for more information.
Appendix A: DIA Reference 303
Advantages and Primary Functions
Advantages and Primary Functions
DIA provides a central location that abstracts the data coming from any data
source so that the front-end display does not need to know how to format it.
These and other primary functions give you the many advantages of
centralized system management.
DIA comes with the following functions and abilities:
■
Centralized component management
■
Abstract data collection
■
Transparent and secure communications
■
Constant availability
■
Zoning
See the topics that follow for more detailed descriptions of each primary
function.
Centralized Component Management
DIA provides one central location to manage the Unicenter infrastructure that
is installed. This allows for a much more robust environment that is selfmaintaining and easy to manage.
The Dynamic Node Administrator lets you manage the system and perform
tasks such as data collections and communications. The Knowledge Base is the
entry point for collecting information from the Dynamic Node Administrator
hosts.
304 Implementation Guide
Advantages and Primary Functions
Detection and Deployment
DIA can locate itself on the network, in the form of a Knowledge Base or
Dynamic Node Administrator host, and configure automatically and
dynamically.
Knowledge Bases locate all Dynamic Node Administrators and other Knowledge
Bases on the network. They create a grid of machine information that allows
you to determine where requests should be moved to and how to access all of
the systems on the network. The grid is essentially a map of the entire
management environment, allowing for communication to any of the systems.
After a Knowledge Base locates a Dynamic Node Administrator, it can perform
tasks such as the following:
Software Recognition
The process of locating installed software on the target system to allow for
management of that software (such as SQL, Oracle, Unicenter Event
Management, etc.).
Management Aware/Enabled
Activates components for cultivating knowledge from the target system for
display in a GUI.
Note: See the topic L Gene Technology for more information.
Communications Enablement
Provides secure and encrypted transmissions without changes to existing
interfaces if so desired.
Note: See the topic Transparent and Secure Communications for more
information.
Remote Node Management
When a system becomes Management Aware, a Dynamic Node Administrator
is placed on the system and the recognition process starts. The Dynamic Node
Administrator detects operating system information, software and hardware
information, and network information pertaining to the given target host. This
information is then transmitted back to the Knowledge Base to determine the
best way to manage the system and what components the system needs.
Using Dynamic Node Administrator, you can dynamically and automatically
adjust settings such as IP address changes, network firewall locations, future
software installations, and others.
Appendix A: DIA Reference 305
Advantages and Primary Functions
Data Collection and Abstraction
DIA creates a common interface to all available Unicenter components.
Because each component uses different technology to recognize and use backend data, DIA abstracts the data format from the display and moves all backend components into one centralized common look. This method of data
collection separates the data from the source from which it came, allowing
multiple users to handle the data in their own ways, all without having specific
knowledge of the source.
L Gene Technology
DIA uses L Gene technology to convert back-end data into an abstract format
that can be distributed across the system for the purpose of displaying and/or
correlating the data.
L Genes provide a clean and easy to use interface for data suppliers to connect
to DIA and feed knowledge into the system. DIA uses the L Gene to start up
and configure a collection of cells that are used to cultivate or obtain
knowledge from any given system.
L Cells serve as the hook into DIA, and L Genes determine if a given L Cell
should be created on a system based on information found on the given
system.
Transparent and Secure Communications
DIA facilitates transparent and secure communications across different
communications packages. Using the communications gene (or C Gene), DIA
provides a layer to each communications mechanism on a network to allow
their existing interfaces to remain the same while at the same time giving
them the use of firewall detection, port consolidation and secure/encrypted
transmissions with little or no modification to existing code.
306 Implementation Guide
Advantages and Primary Functions
C Gene Technology
C Gene technology is responsible for moving data between hosts. It can
perform tasks such as changing network IP addresses, detecting firewalls, and
issuing proxy requests to the Knowledge Base for systems that are
unreachable through normal communications. As with all DIA technology, C
Gene technology performs independent of user interaction, on demand, and
dynamically enough to be self-maintaining.
The C Gene is a simple mechanism that moves data from point to point. C
Cells support data such as publish/subscribe operations and message-based
communications. To enhance the guaranteed delivery of messages, all
communications can be confirmed with the receiving applications.
Dynamic Network Detection
The C Gene can detect the presence of a firewall and multi-tiered
"Demilitarized Zones" (DMZ), allowing DIA to establish connections without
making changes to the firewall. In addition, firewall detection allows for wellknown ports to access information located outside of the firewall. A DMZ is a
firewall configuration for securing local area networks (LANs).
DIA uses the same port for all communications so that there is no need to
configure ports other than the ports required for DIA (a maximum of three).
DIA can automatically proxy connections for target Dynamic Node
Administrator hosts that are located behind the firewall without any interaction
or configuration changes by the systems administrators.
Since information can change on the network and more often on machines
outside the firewall, DIA provides the ability to relearn the network topology
with regards to the firewalls and network connections not only on the private
network but in the DMZs as well.
Appendix A: DIA Reference 307
Advantages and Primary Functions
Security
For security purposes, the Knowledge Base includes a proxy which detects
firewalls and dynamically connects to machines that need monitoring in this
environment.
Note: DIA does not currently support Unicenter Knowledge Bases located
outside a firewall unless in-bound ports are open for connects. However, the
Dynamic Node Administrators can be outside of a firewall as long as they are
communicating to a Unicenter Knowledge Base inside of the firewall.
To further heighten security, all information in the DIA subsystem is encrypted
and secure. It can only be removed within the DIA subsystem, which removes
the ability to "spoof" requests and responses.
All out-bound data communications from all DIA components (from the
Knowledge Base to the Dynamic Node Administrator host) use secure sockets
with public/private key encryption up to 128 bit for all transmissions to provide
the highest possible level of security.
Security Scenarios
For a network with one DMZ or multiple DMZs that allow the private network
full access on the way out, a single Knowledge Base is set up to proxy for all
nodes in the DMZs outside the private network. The Knowledge Base learns
about the nodes as they start up, and this information determines where the
system needs help communicating to private network nodes.
For a network with multi-tiered DMZs representing different levels of security
before reaching the internet, multiple proxies are used to establish a wellknown path out of the private network. Each proxy manages the DMZ it is
located in and passes information out by the established path.
308 Implementation Guide
Advantages and Primary Functions
Availability
DIA is available at all times; there cannot be a single point of failure in the
system. Knowledge transfers and communications are guaranteed, and in the
event of a problem with a system area, they will reroute dynamically to ensure
guaranteed delivery.
Failover of Knowledge Bases ensures DIA's constant availability. DIA is selfreplicating, fully distributed, and backed up to a physical disk. Therefore, if a
problem arises with one Knowledge Base, all other Knowledge Bases adopt the
workload from the failed system. All users are then updated and rerouted
accordingly.
Appendix A: DIA Reference 309
Advantages and Primary Functions
Grid Technology
The Knowledge Base takes all of the information that was obtained during
detection and deployment and populates the grid. The grid tracks the status
and location of any system in the DIA management system. In the grid, all
DIA aware components can interact without knowing specifics about each
other.
The grid replicates information from the master connection (the Knowledge
Base on the MDB system). Knowledge Bases then retrieve this information
from the grid and use it to interact with all other Knowledge Bases (such as
notifying other bases of changes and requesting information). This replication
allows for one common grid for all nodes in a given domain.
After the grid is populated, the information is passed on to all other Knowledge
Bases and replicates across these Knowledge Bases. As a result of this
replication, if a Knowledge Base goes down, all of the managed nodes from
that Knowledge Base are adopted by another Knowledge Base. The grid
updates to reflect this change, and communications are re-established. All
users connected to the failed Knowledge Base are then updated and rerouted
accordingly.
Once a Knowledge Base is part of the grid, its system will connect to the grid
automatically without having to supply a host name for a Knowledge Base. DIA
can then determine all potential connections to the grid without requiring
information from the end user.
Zoning
Zones are logical entities or groupings of managed hosts on the network. Zone
information is based on policy on the Master Knowledge Bases and is used to
segregate groupings of machines so that there is no communication between
logical groupings. For example, a typical use of zones is to break up
production and test environments. The advantage is that a machine can be
moved from test into production or vice versa by requesting DIA to move the
machine, rather than having to physically change the location of the box or the
subnet to which it belongs.
There is no communication between zones at all. Zones should be carefully
configured with this in mind. Submitting requests from one zone to another to
retrieve data from any of the Dynamic Node Administrator hosts results in a
zone violation and is unsuccessful.
310 Implementation Guide
Advantages and Primary Functions
In DIA, zones separate different working environments for you. If you want to
keep the QA, development, and production environments separate, you can
assign a specific zone for each Knowledge Base. This causes the Dynamic Node
Administrator activated by you to belong to the designated zone. DIA
separates the environments by allowing zones to exchange information with
other zones but forbidding communication between zones.
Knowledge Base Zone and Grid Rules
Keep the following rules in mind while working with Knowledge Base zones and
grids:
■
If a Knowledge Base is not defined to a particular zone, it is placed in the
DEFAULT zone by default.
■
For security reasons, there is no communication or routing of requests
across zones. Knowledge Bases in one zone cannot communicate to
Knowledge Bases in another zone.
■
You only modify the policy file for the Master Knowledge Base. The Master
Knowledge Base is the keeper of the grid information. Other Knowledge
Base zones do not - they have slots from the grid.
■
Every Knowledge Base is only responsible for its own slot in the grid and
only makes changes to that slot.
■
The Master Knowledge Base coordinates and updates changes to all
Knowledge Bases in the zones. For example, if a Knowledge Base gets a
new managed node, the Master Knowledge Base tells other Knowledge
Bases in that zone about it.
How the Grid and Knowledge Base Zones Work
Knowledge Base zones and the grid work together to create different zones for
different purposes. The following process indicates the interaction between the
Knowledge Base zones and the grid:
■
The first Knowledge Base starts up and obtains all the SRV records for
your service name (_grid._tcp) to determine to which zone the Knowledge
Base belongs. The DNS server runs the IP address through the policy file
and indicates to which zone it belongs. The Knowledge Base realizes it is
first and becomes the Master Zone.
■
The second Knowledge Base starts (not the Master Zone) and pings the
DNS server looking for the SRV record. The DNS server runs the IP
address through the policy file and indicates to which zone it belongs. For
example, the Development zone.
■
A managed node may start up after that. Managed nodes also do a look up
in the SRV record - runs through the Activation Point section of the code.
The target is told to which Knowledge Base it belongs. By default, they
belong to a particular zone.
Appendix A: DIA Reference 311
DIA Configuration
Zone Setup
To set up zones in an environment without a Master Knowledge Base, edit the
Knowledge Base configuration file (ukb.cfg) by assigning the appropriate zone
for the Knowledge Base in the field named Zone. All Dynamic Node
Administrator machines are subsequently moved to the correct zone, where
they cannot send requests across zones.
DIA Configuration
The topics that follow will give you an understanding of the DIA configuration
and implementation process. We recommend reading the preceding portions of
this appendix before continuing.
You need to perform the following procedures so that the DIA is configured to
monitor your infrastructure:
■
Configure Knowledge Base policy file
■
Create DIA rules file
Important! Install and configure the Master Knowledge Base before installing
any other machines. The Master KB's policy file is used to automatically
configure subsequent Dynamic Node Administrator and Knowledge Base
installations. If you do not do this, you must manually configure each
machine.
312 Implementation Guide
DIA Configuration
DIA Deployment Recommendations
Consider the following recommendations when you deploy DIA in your
environment.
RFC1033 implies that it is a good practice to use reverse DNS lookup to
identify IP addressed hosts when they are added to the network. Therefore, an
important requirement for DIA installation includes reverse DNS lookup using
PTR records (pointer to canonical names) for the nodes involved.
DNAs should be activated to the geographically and physically closest
Unicenter Knowledge Base for better performance. DNA is always activated to
a Unicenter Knowledge Base on the local machine if one is available. If
possible, design Unicenter NSM deployment as follows:
■
The Master Knowledge Base has approximately an equal number of
network hops from each Unicenter Knowledge Base
■
The number of DNAs registered with a Unicenter Knowledge Base does not
exceed 500. For larger number of DNA registrations, divide them among
the closest Unicenter Knowledge Bases.
For large deployments, product installations, or product upgrades, adhere to
the following best practices:
1.
Decide on install locations for all NSM managers. Based on this
information, decide on the overall most central location for the Master
Knowledge Base.
2.
Install and setup the Master Knowledge Base (NSM Manager install).
3.
Set the activation and registration rules. For example, all machines
running on the 141.202.*.* subnet should activate to the DSM manager
Unicenter Knowledge Base and others to the MDB Unicenter Knowledge
Base.
4.
Ensure that the Master Knowledge Base is running
5.
Install the agents. The agents are activated automatically based on the
rules.
Appendix A: DIA Reference 313
DIA Configuration
Configure Unicenter Domain Name Services
You need to set up and configure the auto detection mechanism that uses
Domain Name Services (DNS) SRV records to locate the Knowledge Bases that
activate and use DIA. You do this by adding an SRV record.
Notes:
■
If DNS is not available, or if it is available but the DNS SRV record cannot
be set, see the topics Install DIA Without DNS Available and Install DIA
Without an SRV Record Set.
■
If you are installing Unicenter NSM r11.2 on a system that uses a static IP
address, you may get an error because DIA fails to find and connect to the
DNS server with the SRV record. To enable DIA to find the SRV record
during installation, you must set the connection-specific DNS suffix in your
network settings.
To add an SRV record
1.
Refer to the documentation provided by your operating system vendor or
the DNS provider for information regarding how to invoke the
configuration mechanism. If you are using a third party to host DNS
services and do not have access directly to the DNS server, a forward
lookup DNS server can be used.
The following dialog provides an example:
314 Implementation Guide
DIA Configuration
2.
Configure the fields as follows:
Service
Specifies the actual name of the service that is used to perform the
lookup. Enter _grid into this field. Once specified, you cannot change
this value.
Protocol
Specifies the type of protocol to use. Enter _tcp into this field. Once
specified, you cannot change this value.
Priority
Sets the order of priority for Knowledge Base systems to be pinged for
the service record. Set this to 1 to designate the first Knowledge Base
as the Master Zone, and if additional Knowledge Bases are installed,
the number should be incremented to allow DIA to determine which
Knowledge Base to use and in what order.
Weight
Algorithms to affect priority; this cuts down on traffic. Set this field to
0.
Port number
Specifies the port that the service is listening on. Set this port to the
number used by the Knowledge Base located on the host that has the
MDB installed. The default is 11503.
Host offering this service
Specifies the host (DNS server) where the installed service (Knowledge
Base) and the MDB is physically running. Enter the name of the
Knowledge Base into this field.
Note: See the New Resource Record dialog for an example of what the
dialog will look like with the information entered.
3.
Click OK.
The new SRV record is created.
After the SRV record is created, the DNS hosts should all become members of
the domain to which the SRV record is added. This is done in the network card
configuration for the client system.
For example, if your primary domain is company.com and you have made the
changes to the DNS server hosting company.com, set the primary DNS to
point to that domain server. If you have made the changes to
subdns.company.com, which is configured as a forward lookup domain, set
your primary DNS server on your client system to allow it to perform lookup
requests to the system hosting subdns.company.com. Then you can get the
correct DNS records from the server.
Appendix A: DIA Reference 315
DIA Configuration
In most cases, you would add the SRV records to the primary DNS server, as
in the first example.
Note: Once the MasterKB is set up, you may need to reset the location where
the WorldView Registration Server is configured. From the WorldView
Manager/MDB Server, run the switchwvregsrvr.bat utility. If you install the
WorldView Manager and MDB after configuring the MasterKB, you do not need
to run the utility. See the online CA Reference under WorldView Executables
for information about the switchwvregsrvr.bat utility.
You are now ready to begin installing DIA. DIA comes as part of the Unicenter
NSM or CA CCS package; therefore, there are no additional hardware or
software requirements than those for Unicenter NSM or CA CCS. Simply run
the DIA installation to install. DIA comes fully ready for installation with all
needed dependencies.
Note: DIA does not require that a JRE be installed or running on the system.
DIA does lay down a JRE, but it is not installed or registered with the system.
DIA is fully encapsulated and starts executables and JREs as needed during
the course of normal operations.
Configure the MasterKB Without an SRV Record or Domain
If DIA is installed in an environment where there is no domain set up or no
access to a DNS server, you can specify the MasterKB host name in the
dna.cfg file.
Note: The dna.cfg file for each Dynamic Node Administrator host that you
have installed must be changed.
To configure the MasterKB without an SRV record or domain
1.
Open the dna.cfg file in the folder
InstallPath\CA\SC\CCS\DIA\dia\dna\config using a text editor of your
choice.
2.
Set overrideSRV to yes and MasterKB to the host name of the MasterKB
that is to be your Master Knowledge Base server. For example,
overrideSRV=yes
MasterKB=mymasterkbhostname.domain.com
3.
Optional: Set a secondary MasterKB host name to take over responsibility
if the MasterKB is down. For example,
SecondaryMasterKB=secondarymasterkbhostname.domain.com
Note: Set the secondary MasterKB only when there is no domain or DIA
SRV record set up.
316 Implementation Guide
DIA Configuration
4.
Save the dna.cfg file.
5.
Stop the CA DIA 1.3 DNA service.
6.
Stop the CA DIA 1.3 Knowledge Base service.
7.
Start the CA DIA 1.3 Knowledge Base service.
8.
Start the CA DIA 1.3 DNA service.
Important! Always consider the sequence that is described in the steps 5 - 8
when you restart the two services (CA DIA 1.3 DNA and CA DIA 1.3
Knowledge Base). Stop the Dynamic Node Administrator first and then the
Knowledge Base. Then start the Knowledge Base, and lastly, start the Dynamic
Node Administrator.
Also consider the following guidelines:
■
Override the MasterKB name on all these systems by running the
updateConfigFile utility under Install_Path\SC\CCS\DIA\dia\dna\bin. Use
fully-qualified domain names in dna.cfg.
■
If both SRV record/domain and dna.cfg are configured with the MasterKB,
you can set an attribute in dna.cfg to specify which configuration has a
higher priority. If overrideSRV is set to yes in dna.cfg, the MasterKB
specified in this location takes effect regardless of the settings in the SRV
record. If overrideSRV is set to no in dna.cfg, the MasterKB in the SRV
record of the DNS takes effect. The default setting for overrideSRV is no.
■
Once the MasterKB is set up, you may need to reset the location where the
WorldView Registration Server is configured. From the WorldView
Manager/MDB Server, run the switchwvregsrvr.bat utility. If you install the
WorldView Manager and MDB after configuring the MasterKB, you do not
need to run the utility. See the online CA Reference under WorldView
Executables for information about the switchwvregsrvr.bat utility.
Commands to Start and Stop DIA Daemons on Linux or UNIX
You can start and stop the DIA daemons running in Linux or UNIX
environments with the following commands.
To start CA DIA 1.3 Dynamic Node Administrator, run this command in the
$CA_DIA_HOME/dia/dna/bin directory:
./dnacntl start
To stop CA DIA 1.3 Dynamic Node Administrator, run this command in the
$CA_DIA_HOME/dia/dna/bin directory:
./dnacntl stop
Appendix A: DIA Reference 317
DIA Configuration
To start CA 1.3 Knowledge Base, run this command in the
$CA_DIA_HOME/dia/ukb/bin directory:
./ukbcntl start
To stop CA 1.3 Knowledge Base, run this command in the
$CA_DIA_HOME/dia/ukb/bin directory:
./ukbcntl stop
Cell Configuration
DIA comes with the following cells pre-installed:
■
Agent Control Cell
■
DSM Control Cell
■
WV Cell
■
MDB Cell
■
CAEM Cell
■
CAAMS Cell
These cells are registered and activated automatically with a Dynamic Node
Administrator. If you need to manipulate the cell settings, see the DIA
Diagnostic Tool Help, Manage Resources for more information.
DIA also installs the PDI cell, a DIA internal cell that is not enabled or started
by default. You must enable and start the PDI cell manually when you want to
deploy packages using the DIA Package Deployment Infrastructure feature.
DIA Rules File
The DIA Rule execution module writes rules for DIA in XML (eXtensible Markup
Language). The module writes rules for hostnames of machines, IP addresses
of machines, or complete subnets. The rules reside on the Master Knowledge
Base, which is defined by an entry in the DNS.
DIA defines its rules using the RDL (Rule Definition Language) and interprets
its rules using the AION JSR-94 engine. A working knowledge of the RDL rule
helps in understanding the DIA rules.
Rules can be written for two reasons:
■
Setting the zone information of Knowledge Bases (the zone rule)
■
Setting the Dynamic Node Administrator ownership (the activation rule)
318 Implementation Guide
DIA Configuration
The DIA Diagnostic Tool provides the Knowledge Base Rule Editor utility to set
the rules. See DIA Diagnostic Tool Help for more information on how to set the
entries.
Important! Do not edit the ukbrule.xml file manually. Always use the rule
editor for any rule modifications.
To apply the changes of the rule file, stop and restart the CA DIA 1.3
Knowledge Base service on the Master Knowledge Base where the rule file
resides.
Note: Once a new rule is inserted by using the DIA Diagnostic Tool, then the
DIA services on all the affected DIA systems need to be restarted.
Configure Communications for Encryption
All host level outbound data communications that include those from DIA
components (Dynamic Node Administator or Knowledge Base) are able to use
secure sockets. Additionally, all of these communications can be configured to
use public and private key encryption to further enhance data transfer
security.
Note: When a system with DIA is configured to work in an encrypted mode,
all other DIA-enabled nodes, including the MasterKB, must be encrypted also
before they can communicate with each other. A mixed environment where
some nodes are configured to use encryption and some are not is not
supported.
Appendix A: DIA Reference 319
DIA Configuration
All DIA communications, such as grid synchronization, activations, and so
forth, are based on Java RMI and by default this information is not encrypted.
You can, however, configure DIA communications for encryption with the
following procedure.
To configure DIA communications for encryption
1.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and stop the Dynamic Node Administrator and Knowledge
Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base.
Note: It is important to stop the services in this order, Dynamic Node
Administrator first and the knowledge base second.
The Dynamic Node Administrator and knowledge base services are
disabled.
2.
Open the Dynamic Node Administrator configuration file
(InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg) and set
RMI_ENCRYPTION to 1, then save and close the file.
The Dynamic Node Administrator is now configured for encryption. All of
your Dynamic Node Administrator hosts must be configured in this way.
3.
Open the Knowledge Base configuration file
(InstallPath\CA\SC\CCS\DIA\dia\ukb\config\ukb.cfg) and set
RMI_ENCRYPTION to 1, then save and close the file.
Knowledge Bases are now configured for encryption. All Knowledge Bases
must be configured in this way.
By default, a non-expired encryption key is located at
InstallPath\CA\SC\CCS\DIA\dia\config\mykey. You are not required to
create a new encryption key.
4.
(Optional) If you have an explicit need to create a new encryption key,
replace the mykey file with your user key.
Use the java utility keytool that comes with the java SDK to generate a
new key. The password for the keystore must be "unicenter". The
following is an example invocation of the tool to generate the mykey file
for a validity period of 360 days:
On Windows
InstallPath\CA\SC\JRE.ccs\1.5.0_11\bin\keytool -genkey -keypass "unicenter" keystore mykey -storepass "unicenter" -validity 360 -dname "CN=Server,
OU=BAR, O=Foo, L=Some, ST=Where, C=UN"
On Linux or UNIX
/opt/CA/SharedComponents/JRE/1.5.0_11/bin/keytool -genkey -keypass
"unicenter" -keystore mykey -storepass "unicenter" -validity 360 -dname
"CN=Server, OU=BAR, O=Foo, L=Some, ST=Where, C=UN"
The expired default encryption key is now replaced.
320 Implementation Guide
DIA Configuration
5.
6.
Ensure that the ukb cleanup is done properly. The following files in the
ukb/config folder need to be deleted:
■
lgenetable
■
masterqueue (on MKB)
■
masterukbzonelist (on MKB)
■
ukbgridtable
■
ukbinfo.dat
■
gridtable.txt
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and start the Knowledge Base and Dynamic Node
Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA.
Note: It is important to start the services in this order, the Knowledge
Base first and Dynamic Node Administrator second. Start the Dynamic
Node Administrator when the Knowledge Base is up and running.
Encryption is now enabled.
7.
Restart any applications that use DIA such as the Unicenter MCC,
Unicenter MP, Unicenter Configuration Manager, Web Reporting Server,
Dashboards, Agent Technology, and so forth. The applications establish an
encrypted connection to DIA.
DIA Configuration in Special Environments
DIA supports several different environments, some requiring special
configuration and some requiring no additional configuration. The following
topics give configuration specifications for special environments in which DIA
runs.
Configure DIA for Firewalls
DIA transparently supports the firewall environment. No special inbound ports
need to be opened through the firewall. To configure DIA for this transparent
support, you must set up a proxy Unicenter Knowledge Base inside the
firewall. The proxy Knowledge Base then manages all outside Dynamic Node
Administrator hosts trying to communicate to machines inside the firewall.
Appendix A: DIA Reference 321
DIA Configuration
To set up a proxy Unicenter Knowledge Base inside the firewall
1.
Open the ukb.cfg file in the InstallPath\CA\SC\CCS\DIA\dia\ukb\config
folder.
2.
Set the PROXY_UKB to "YES" and save the file.
A proxy Knowledge Base is now set up inside the firewall.
3.
Restart the Knowledge Base and Dynamic Node Administrator services on
the system.
The changes take effect and a proxy Unicenter Knowledge Base appears
inside the firewall.
Firewall Environment Configuration Scenarios
In the firewall environment, port usage depends on the firewall setup as well
as the Knowledge Base position relative to the firewall. The following scenarios
show how DIA behaves in specific firewall environments and how you must
configure the ports.
Agents Reside Outside the Firewall With UKB Proxy Configured
If a Unicenter NSM manager resides inside the firewall and the managed nodes
(agents, DNA hosts) reside outside the firewall, the managed nodes have to
establish DIA connections to the manager inside the firewall. In this case a
managed node has no way to register with the manager because all incoming
ports are closed on the firewall. Therefore, there is no DIA communication
toward the manager. To make this work, the Unicenter NSM manager needs to
be set as a Unicenter Knowledge Base Proxy (UKB Proxy). This allows the
manager to talk to any DNA hosts outside the firewall.
If the Unicenter NSM manager (DNA manager) is a UKB Proxy, the managed
nodes (DNA hosts) outside the firewall are able to communicate with the
Knowledge Base inside the firewall.
With this configuration, for every polling interval that is set in the ukb.cfg file,
the UKB Proxy polls the DNA hosts outside the firewall through port 11501.
The UKB Proxy knows which hosts are outside the firewall by looking at the list
of hosts it manages. Since the communication session is initiated from inside
the firewall and is bidirectional, the DNA host outside the firewall is able to
respond to the UKB Proxy's requests on the same port, 11501.
322 Implementation Guide
DIA Configuration
In this scenario of a strict firewall where no inbound ports are open, activation
needs to be done from the Unicenter NSM Manager server by using the DIA
Tool.
To activate agent DNA
1.
Launch the DIA Tool by executing
Install_Path\CA\SC\CCS\DIA\dia\ukb\bin\diatool.bat in the secured zone
which is designated as the UKB proxy.
2.
From the menu bar click Deloyment, Activate and follow the instructions
on the screen. See also DIA Diagnostic Tool help: Activate Dynamic Node
Administrator.
The following ports must be outbound enabled:
■
11501 - Unicenter Knowledge Base Registry Port
■
11502 - Unicenter Knowledge Base Data Port
Appendix A: DIA Reference 323
DIA Configuration
Agents Reside Outside the Firewall Without UKB Proxy Configured
If you have the previous scenario without a UKB Proxy configured, the
following ports must be bidirectional enabled:
■
11501 - Unicenter Knowledge Base Registry Port
■
11502 - Unicenter Knowledge Base Data Port
UKB Communicates With Another UKB Inside the Firewall
If a UKB resides outside the firewall and has to communicate with a UKB inside
the firewall, the following ports must be bidirectional enabled:
■
11501 - Unicenter Knowledge Base Registry Port
■
11502 - Unicenter Knowledge Base Data Port
■
11503 - Dynamic Node Administrator Registry Port
■
11504 - Dynamic Node Administrator Data Port
NAT Settings
DIA supports the scenario where the Unicenter NSM manager (the DIA
Unicenter Knowledge Base) is inside and the the Unicenter NSM agent (the
DIA Dynamic Node Administrator component) is outside the NAT environment,
as in the following diagram:
324 Implementation Guide
DIA Configuration
As the diagram illustrates, the Unicenter NSM agents communicate with the
manager using the NAT IP address, while the manager communicates with
agents directly using their physical, or natural, IP addresses.
To apply NAT settings
1.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and stop the Dynamic Node Administrator and Knowledge
Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base.
Note: It is important to stop the services in this order, Dynamic Node
Administrator first and the knowledge base second.
The Dynamic Node Administrator and knowledge base services are
disabled.
2.
Open Dynamic Node Administrator configuration file
(InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg) and set ISNAT=YES
and NAT_PUBLIC_IP to a NAT public IP, then save and close the file.
For example, the NAT public IP in the diagram is 10.20.170.22.
3.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and start the Knowledge Base and Dynamic Node
Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA.
Note: It is important to start the services in this order, the Knowledge
Base first and Dynamic Node Administrator second. Start the Dynamic
Node Administrator when the Knowledge Base is up and running.
Unicenter NSM agents and the manager server now communicate through
a NAT IP address.
Appendix A: DIA Reference 325
DIA Configuration
HACMP Clusters
DIA supports overriding the default local IP address for RMI server binding.
You can explicitly specify an address based on your requirements. When you
enable an overriding RMI binding, the RMI server binds to the specified IP
address only and does not query the local interfaces for possible IP addresses
and then bind to them.
The overriding RMI binding feature is specific to HACMP clusters where you
have a requirement to bind to a specific IP address. This feature should strictly
be used for that purpose only.
To enable override RMI binding
1.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and stop the Dynamic Node Administrator and Knowledge
Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base.
Note: It is important to stop the services in this order, Dynamic Node
Administrator first and the knowledge base second.
The Dynamic Node Administrator and knowledge base services are
disabled.
2.
Open the Dynamic Node Administrator configuration file
(InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg), set overrideRMIBind
to yes and RMIBindHost to an explicit IP address (for example,
RMIBindHost=192.166.1.226), then save and close the file.
3.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and start the Knowledge Base and Dynamic Node
Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA.
Note: It is important to start the services in this order, the Knowledge
Base first and Dynamic Node Administrator second. Start the Dynamic
Node Administrator when the Knowledge Base is up and running.
Your HACMP cluster is now set to bind to a specific IP address.
OverrideRMIBind cannot be used for multiple network interface controller
environments where DIA traffic for one card is enabled and blocked for all
others. DIA does not support this function as the intention of OverrideRMIBind
is entirely different from this.
DMZ Environments
When running DIA in a DMZ environment, DIA does not require any special
configuration for a normal DMZ. However, DIA does not support cascaded DMZ
as of r11.2.
326 Implementation Guide
Troubleshooting and Diagnostics
Multiple Network Interface Controller Environments
When running DIA in a multiple NIC environment, consider the following:
■
DNA should not float from one zone to another.
■
The primary Master Knowledge Base and secondary Master Knowledge
Base should be in the same zone.
■
The secondary Master Knowledge Base shows all zones in its DIA
Diagnostic Tool.
■
The rule_backup folder should not be part of the Unicenter Knowledge
Base or Master Knowledge Base cleanup.
■
If a local Unicenter Knowledge Base is running, the DNA cannot be
activated to a different Unicenter Knowledge Base.
Troubleshooting and Diagnostics
This section discusses common configuration and maintenance problems that
can occur in a DIA environment and offers recommended configurations for
optimal performance of the DIA components. It also provides troubleshooting
techniques related to DIA and its components.
Backup for Master Knowledge Base
Symptom:
Not able to backup the Master Knowledge Base.
Solution:
DIA supports two Master Knowledge Bases:
■
One primary Master Knowledge Base
■
One secondary Master Knowledge Base
The second Master Knowledge Base automatically creates a mirror of the
primary Master Knowledge Base in a real time environment.
However, if your environment has only one Master Knowledge Base, copy all
the files in the ukb\config folder to a backup folder.
To solve a problem with the Master Knowledge Base
1.
Shutdown the Master Knowledge Base by stopping the Unicenter
Knowledge Base service.
2.
Replace all the files in the ukb\config folder with the backed up files.
3.
Restart Unicenter Knowledge Base service.
Appendix A: DIA Reference 327
Troubleshooting and Diagnostics
C-Gene Utilities Fail on HP-UX
Symptom:
The C-Gene utilities fail on HP-UX.
Solution:
Set the LD_PRELOAD path for the libjvm.sl library. Search for libjvm.sl and use
the correct path in the following command:
export LD_PRELOAD="/<path>/libjvm.sl"
for example:
export LD_PRELOAD="/nsmr11.2/CA2/SC/JRE/1.5.0_07/lib/PA_RISC2.0/server/libjvm.sl"
Configure Memory Usage for a Cell
Symptom:
Not able to configure the amount of memory that is used by a cell.
Solution:
A cell process uses about 8 to 10M memory. Use the <cellname>_InitHeapSize property in the cell.cfg file to configure the memory
usage for a cell.
DIA Communications
Symptom:
Not able to route DIA communications through the Unicenter Knowledge Base.
Solution:
You cannot route all the DIA communications through the Unicenter
Knowledge Base. The communication between the DSM and agents use DIA CGene communication and are not routed through the Knowledge Base.
328 Implementation Guide
Troubleshooting and Diagnostics
DIA Configuration in a Firewall or NAT Environment
Symptom:
Not able to configure DIA in a firewall or /NAT environment.
Solution:
To configure DIA in a firewall environment, set up a proxy Knowledge Base
inside the firewall. All the Dynamic Node Administrator hosts that
communicate with the machines located inside the firewall, must be managed
by the proxy Knowledge Base.
Note: A Knowledge Base is defined as a proxy, if the PROXY_UKB option is set
to "YES" in the ukb.cfg file. You need not open an inbound port through the
firewall.
To configure DIA in a NAT environment, ensure that NAT is configured to
forward packets from one network to another network using the same name.
DIA Logs
This section explains the logging details provided by DIA for its components,
which can be used for troubleshooting.
DIA logs are located in the following directory:
Windows
InstallPath\CA\SC\CCS\DIA\dia\logs
Linux or UNIX
/opt/CA/SharedComponents/ccs/dia/logs
Note: Directory path is valid only if you have used the default location for
installation.
Appendix A: DIA Reference 329
Troubleshooting and Diagnostics
The configuration files you can use to specify the parameters of the different
DIA components, include the following.
Unicenter Knowledge Base: ukb.cfg that is located at:
Windows
C:\Program Files\CA\SC\CCS\DIA\dia\ukb\config
Linux or UNIX:
/opt/CA/SharedComponents/ccs/dia/ukb/config
Dynamic Node Administrator: dna.cfg file
Cells: cell.cfg file.
C-Gene: cgene.cfg file.
The Dynamic Node Administrator, cell and cgene configuration files are located
at:
Windows:
C:\Program Files\CA\SC\CCS\DIA\dia\dna\config
Linux or UNIX:
/opt/CA/SharedComponents/ccs/dia/dna/config
The structure of all the configuration files is similar and all the parameters are
configurable.
Note: We highly recommend that an expert modify these parameters. The
parameters related to the logs can be modified by anyone.
Based on your requirement, you can configure the logs for the amount and
level of information.
The level of logging can be changed in the configuration file by modifying the
LOG_LEVEL parameter. By default, this is set to SEVERE – which means that
only the most important messages would be added to the log files (implying
that the amount of information would be minimal).
Note: For troubleshooting purpose set the LOG_LEVEL parameter in the
configuration file to INFO. This provides sufficient information in the logs to
make an intelligent interpretation.
330 Implementation Guide
Troubleshooting and Diagnostics
For the changes to the configuration file to be effective, do the following:
■
Stop the relevant service
■
Make changes to the configuration file
■
Start the relevant service again.
Note: Stop and start the service when the problem is the Dynamic Node
Administrator or Knowledge Base. Restart the cell in the case of a specific cell.
Clean, delete or backup the existing log files to understand the flow of events
(as the log files are appended to the existing ones, it might be difficult to
understand the data for troubleshooting).
The size of the log file is determined by the LOGFILE_LIMITSIZE parameter in
the <component>.cfg file and the default value is 4 MB. After reaching this
limit, the file is backed up and a new log file is automatically created.
For Example:
Assume that ukb0.log is the default log file for the Knowledge Base.
If the size of the ukb0.log reaches more than 4MB, the log is saved as
ukb1.log and then an empty ukb0.log is used for logging the new data.
Subsequently, if the new ukb0.log reaches the 4MB limit, the file is saved as
ukb2.log and so on.
The number of such saved log files depend on the LOGFILE_COUNT parameter
and the default value is 4.
Note: You must modify only the LOG_LEVEL parameter.
Appendix A: DIA Reference 331
Troubleshooting and Diagnostics
Important Log Files
This section provides a list of the important log files that you can use for
troubleshooting:
ukb0.log
Contains all the information related to the interactions and requests to the
Knowledge Base. The list of informational items contained in the log
include the following:
■
Connection Requests to the Unicenter Knowledge Base.
■
Informational transfer with the Dynamic Node Administrators
■
Autoactivate requests from the Dynamic Node Administrator
For DIA errors related to the Unicenter MCC, you can see the cause in the
javashell.log file created for Unicenter MCC. Then once the main reason is
known, you can scan the ukb0.log for the mapped sequence of events.
dna0.log
Contains the information related to the interactions of the Dynamic Node
Administrator with the cells and the owner Knowledge Bases. The list of
events for which you might refer to the dna0.log file include the following:
■
Autoactivate requests sent to the Knowledge Base
■
Cell information sent to the Knowledge Base
■
Request for information from the cells
■
Cell registration and deregistration requests
cgene0.log
Determines where the C-Gene communication information is stored. It
provides the information related to the sequence of sends and receives
done over different identifiers.
dna_launcher0.log
Contains the information related to the Dynamic Node Administrator
service startup.
ukb_launcher0.log
Contains the information related to the Knowledge Base.
332 Implementation Guide
Troubleshooting and Diagnostics
Cell Logs
Contains the information related to the cells. The cell name is added to the
logs.
For example, the AMS cell can contain the following files in the DIA logs
directory:
■
caamscell_java0.log
■
caamscell_launcher0.log
■
caamscell_native0.log
DIA Maintenance Tasks
This section explains the maintenance tasks you can perform related to the
following:
■
How to Encrypt the DIA Communication Messages (see page 335)
■
How to Set up WV Registration Server (see page 339)
■
How to Cleanup and Restart DIA (see page 333)
■
How to Activate a New or Modified Policy (see page 333)
How to Activate a New or Modified Policy
To activate a new or modified policy, restart the Unicenter Knowledge Base
service on the Master Knowledge Base.
How to Clean Up and Configure DIA
Use this process to completely cleanup and configure DIA on a system.
To clean up and configure a DIA system
1.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and stop the Dynamic Node Administrator and Knowledge
Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base.
Note: It is important to stop the services in this order, Dynamic Node
Administrator first and the knowledge base second.
The Dynamic Node Administrator and knowledge base services are
disabled.
Appendix A: DIA Reference 333
Troubleshooting and Diagnostics
2.
3.
Change to the InstallPath\CA\SC\CCS\DIA\dia\dna\config directory and
delete the following files:
■
act.dat
■
recognizerRscTable.dat
■
ukb.dat
■
MDBPushTechEntries.pt
If there is no _srv record in your DNS environment, you may want to
setup a Master Knowledge Base manually. Open the dna.cfg file in this
directory and change the following settings:
overrideSRV=yes
MasterKB=Master_KB_System_Name
Optional: Set a secondary Master Knowledge Base host name to take over
responsibility if the Master Knowledge Base is down.
SecondaryMasterKB=secondarymasterkbhostname.domain.com
Note: Set the secondary Master Knowledge Base only, if there is no
domain or DIA SRV record set up.
4.
If this system has NSM manager components (WorldView, DSM, EM)
installed, then change to the following directory:
InstallPath\CA\SC\CCS\DIA\dia\ukb\config
5.
Delete all files in this directory except the following:
6.
■
remins.cfg
■
ukb.cfg
■
ukbrule.xml
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and start the Knowledge Base and Dynamic Node
Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA.
Note: It is important to start the services in this order, the Knowledge
Base first and Dynamic Node Administrator second. Start the Dynamic
Node Administrator when the Knowledge Base is up and running.
7.
Open a command prompt and change to the following directory:
InstallPath\CA\SC\CCS\DIA\dia\dna\bin
8.
If this is an Agent-Only system, enter the following command:
autoactivatedna UKB_host_name
9.
If this system has its own local UKB then enter:
autoactivatedna
334 Implementation Guide
Troubleshooting and Diagnostics
10. Change to the InstallPath\CA\SC\CCS\DIA\dia\dna\config directory and
open the ukb.dat file to check if your DNA is owned by the correct
Knowledge Base.
You should see the name of the Knowledge Base that now owns this DNA.
11. If this system runs World View and the MDB, set up your WV Registration
Server. From the command prompt, change to the
InstallPath\CA\SC\CCS\WVEM\BIN and run the following command:
switchwvregsrvr
The DIA cleanup is now complete.
How to Encrypt the DIA Communication Messages
All host level outbound data communications that include those from DIA
components (Dynamic Node Administator or Knowledge Base) are able to use
secure sockets. Additionally, all of these communications can be configured to
use public and private key encryption to further enhance data transfer
security.
Note: When a system with DIA is configured to work in an encrypted mode,
all other DIA-enabled nodes, including the MasterKB, must be encrypted also
before they can communicate with each other. A mixed environment where
some nodes are configured to use encryption and some are not is not
supported.
All DIA communications, such as grid synchronization, activations, and so
forth, are based on Java RMI and by default this information is not encrypted.
You can, however, configure DIA communications for encryption with the
following procedure.
To configure DIA communications for encryption
1.
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and stop the Dynamic Node Administrator and Knowledge
Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base.
Note: It is important to stop the services in this order, Dynamic Node
Administrator first and the knowledge base second.
The Dynamic Node Administrator and knowledge base services are
disabled.
2.
Open the Dynamic Node Administrator configuration file
(InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg) and set
RMI_ENCRYPTION to 1, then save and close the file.
The Dynamic Node Administrator is now configured for encryption. All of
your Dynamic Node Administrator hosts must be configured in this way.
Appendix A: DIA Reference 335
Troubleshooting and Diagnostics
3.
Open the Knowledge Base configuration file
(InstallPath\CA\SC\CCS\DIA\dia\ukb\config\ukb.cfg) and set
RMI_ENCRYPTION to 1, then save and close the file.
Knowledge Bases are now configured for encryption. All Knowledge Bases
must be configured in this way.
By default, a non-expired encryption key is located at
InstallPath\CA\SC\CCS\DIA\dia\config\mykey. You are not required to
create a new encryption key.
4.
(Optional) If you have an explicit need to create a new encryption key,
replace the mykey file with your user key.
Use the java utility keytool that comes with the java SDK to generate a
new key. The password for the keystore must be "unicenter". The
following is an example invocation of the tool to generate the mykey file
for a validity period of 360 days:
On Windows
InstallPath\CA\SC\JRE.ccs\1.5.0_11\bin\keytool -genkey -keypass "unicenter" keystore mykey -storepass "unicenter" -validity 360 -dname "CN=Server,
OU=BAR, O=Foo, L=Some, ST=Where, C=UN"
On Linux or UNIX
/opt/CA/SharedComponents/JRE/1.5.0_11/bin/keytool -genkey -keypass
"unicenter" -keystore mykey -storepass "unicenter" -validity 360 -dname
"CN=Server, OU=BAR, O=Foo, L=Some, ST=Where, C=UN"
The expired default encryption key is now replaced.
5.
6.
Ensure that the ukb cleanup is done properly. The following files in the
ukb/config folder need to be deleted:
■
lgenetable
■
masterqueue (on MKB)
■
masterukbzonelist (on MKB)
■
ukbgridtable
■
ukbinfo.dat
■
gridtable.txt
Open the Windows Services user interface (Control Panel, Administrative
Tools, Services) and start the Knowledge Base and Dynamic Node
Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA.
Note: It is important to start the services in this order, the Knowledge
Base first and Dynamic Node Administrator second. Start the Dynamic
Node Administrator when the Knowledge Base is up and running.
Encryption is now enabled.
336 Implementation Guide
Troubleshooting and Diagnostics
Restart any applications that use DIA such as the Unicenter MCC, Unicenter
MP, Unicenter Configuration Manager, Web Reporting Server, Dashboards,
Agent Technology, and so forth. The applications establish an encrypted
connection to DIA.
How to Move DIA Systems From One Master Knowledge Base to Another
The following procedures describe how to move DIA systems from one Master
Knowledge Base to another Master Knowledge Base. It depends on the type of
the DIA system which of the two procedures is used.
Note: If any of these systems being moved is a WRS registration server, then
the registration server should be switched first to another system in that zone.
To move a DNA system from one Master Knowledge Base to another
Master Knowledge Base on Windows
1.
Open DIA Diagnostic Tool, right click the DNA system you want to move,
and click Remove DNA from Grid.
The selected DNA is de-activated and removed from the grid.
2.
Stop the DNA service on the system, all Agent Technology services and
other CA related agent services that use DIA.
3.
Change to Install_Path\SC\CCS\DIA\dia\dna\classes and delete everything
except dna.jar.
4.
Change to Install_Path\SC\CCS\DIA\dia\dna\lib. Delete everything except
dna.dll and nativeConsumer.dll.
5.
Change to Install_Path\SC\CCS\DIA\dia\dna\config. Delete ukb.dat,
act.dat and recognizerRscTable.dat.
6.
Start the DNA service on the system.
7.
Change to Install_Path\SC\CCS\DIA\dia\dna\bin and run
autoactivatedna.bat with the name of the Unicenter Knowledge Base that
is under the new Master Knowledge Base you want to activate to:
autoactivatedna.bat kb-name
The DNA system is activated again and has been moved to a new Master
Knowledge Base.
Note: If rules are set appropriately at the Master Knowledge Base for it to
be activated to a new Unicenter Knowledge Base, run autoactivatedna.bat
without a Unicenter Knowledge Base name.
If no rules are set, the system gets activated to a random Unicenter
Knowledge Base depending on its availability. Zones are not checked.
Appendix A: DIA Reference 337
Troubleshooting and Diagnostics
To move a UKB system from one Master Knowledge Base to another
Master Knowledge Base on Windows
1.
Stop the Unicenter Knowledge Base service on the system.
2.
Stop the DNA service on the system.
3.
Change the Master Knowledge Base by either updating it in the DNS SRV
record for this machine’s domain or in dna.cfg, if it has to be overridden.
4.
Change to Install_Path\SC\CCS\DIA\dia\ukb\config and delete all files
except ukb.cfg, remins.cfg and ukbrule.xml.
5.
Start the Unicenter Knowledge Base service on the system.
6.
Start the DNA service on the system.
7.
Open DIA Diagnostic Tool for the old Master Knowledge Base. Select this
Knowledge Base and right click Remove KB from Grid.
The UKB system has been moved to a new Master Knowledge Base. It
loses its DNA information related to the old Knowledge Base.
Note: It may be necessary to setup the same rules on the new Master
Knowledge Base as on the old one.
To move a DNA or UKB system from one Master Knowledge Base to
another Master Knowledge Base on UNIX or Linux
Follow the same procedures on Linux or UNIX platforms from the similar
locations.
How to Reactivate a DNA System
From the DNA system that you want to reactivate perform the following steps:
To reactivate a DNA system with a newer or the same version of
Unicenter Knowledge Base on Windows
1.
Open DIA Diagnostic Tool, right click the DNA system you want to
reactivate, and click Remove DNA from Grid.
The selected DNA is de-activated and removed from the grid.
2.
Stop the DNA service on the system, all Agent Technology services and
other CA related agent services that use DIA.
3.
Change to Install_Path\SC\CCS\DIA\dia\dna\classes and delete everything
except dna.jar.
338 Implementation Guide
Troubleshooting and Diagnostics
4.
Change to Install_Path\SC\CCS\DIA\dia\dna\lib. Delete everything except
dna.dll and nativeConsumer.dll.
5.
Change to Install_Path\SC\CCS\DIA\dia\dna\config. Delete ukb.dat,
act.dat and recognizerRscTable.dat.
6.
Start the DNA service on the system.
7.
Change to Install_Path\SC\CCS\DIA\dia\dna\bin and run
autoactivatedna.bat with the UKB name you want to activate to:
autoactivatedna.bat kb-name
The Dynamic Node Administrator is activated.
Note: If rules are set appropriately at the Master Knowledge Base for it to
be activated to a new Unicenter Knowledge Base, run autoactivatedna.bat
without a Unicenter Knowledge Base name.
If no rules are set, the system gets activated to a random Unicenter
Knowledge Base depending on its availability. Zones are not checked.
To reactivate a DNA system with a newer or the same version of
Unicenter Knowledge Base on UNIX or Linux
Follow the same procedure on Linux or UNIX platforms from the similar
locations.
How to Set Up WV Registration Server
Use this process to set up a WV registration server on a system that has the
WV MDB.
To set up a WV Registration Server
1.
Go to the InstallPath\CA\SC\CCS\WVEM\BIN directory.
2.
Run the switchwvregsrvr.bat utility to set up the registration server.
3.
Recycle the following services to register them with the new registration
server:
■
CA Unicenter
■
CA Remote Monitoring (if installed)
■
CA Unicenter Alert Management System
■
CA Unicenter Network and Systems Management Auxiliary Services
■
CA Web Server 1.0
Appendix A: DIA Reference 339
Troubleshooting and Diagnostics
Dynamic Node Administrator and UKB Installation Process Stops Responding
Symptom:
The Dynamic Node Administrator or Unicenter Knowledge Base installation
process stops responding.
Solution:
Do the following:
■
On a Windows machine, check the following logs:
–
casetup.log
–
diasetup.log located in the CCS/NSM install history (for example,
InstallPath\CA\CA_APPSW\InstallHistory )
■
On a Linux machine, check the DIA install logs located in the system tmp
folder (e.g.: /tmp)
■
On a Linux machine, you can also check the mount points. The DIA
installation process can hang if there are too many mount points,
especially when the automount/autofs option is enabled and Unicenter
NSM is on an automounted share.
To overcome this problem,
–
Do not have a Unicenter NSM image on a share where other file
systems can be automounted.
–
Disable autofs by using the /etc/init.d/autofsstop command.
Dynamic Node Administrator Floated to a Different Knowledge Base
Symptom:
The Dynamic Node Administrator has floated to a different Knowledge Base
and even after the Knowledge Base is autoactivated, it does not show up in
DIA Diagnostic Tool.
Solution:
Use the DIA tool to float the Dynamic Node Administrator back to the
Knowledge Base.
If this does not resolve the problem, remove the ukb.dat and act.dat files from
the dna/config directory and reactivate the node by using the
autoactivatedna.bat file.
340 Implementation Guide
Troubleshooting and Diagnostics
Dynamic Node Administrator Unable to Communicate with Unicenter
Knowledge Base
Symptom:
A Dynamic Node Administrator fails to communicate with the local or the
remote Unicenter Knowledge Base when the Knowledge Base is moved to a
different subnet.
Solution:
A Dynamic Node Administrator fails to communicate with the local or remote
Knowledge Base due to one of the following probable reasons:
■
The Knowledge Base host name cannot be resolved in the original subnet
after it is moved to a new subnet.
This might cause communication failure between the Knowledge Base and
the Dynamic Node Administrator.
To resolve the Knowledge Base host name in the original subnet, do the
following:
■
Run the following command from the console from the dna/bin folder.
autoactivatedna <knowledgebase IP Address>
■
■
Specify the new Knowledge Base host IP address during activation
DNS does not reflect the new IP address for the Knowledge Base.
To ensure that DNS reflects the new IP address for the Knowledge Base,
flush the local DNS cache on the DNS system. To flush the local DNS
cache, use the following command from the Windows command prompt:
ipconfig /flushdns
■
The Knowledge Base owner's IP address is stored in the Dynamic Node
Administrator’s ukb.dat file, instead of the host name.
In this case, the Dynamic Node Administrator cannot connect to the
Knowledge Base, if there is any change in the IP address of the Knowledge
Base.
■
If the Dynamic Node Administrator fails to connect to the Knowledge Base,
do the following:
■
Remove the act.dat and ukb.dat files from the dna/config folder.
■
Reactivate the Dynamic Node Administrator by running the following
command from the console from the dna/bin directory:
autoactivatedna <knowledgebase name>
Appendix A: DIA Reference 341
Troubleshooting and Diagnostics
Float Dynamic Node Administrator to Another UKB Temporarily
Symptom:
Not able to disable Dynamic Node Administrator floating during Unicenter
Knowledge Base shutdown.
Solution:
To disable Dynamic Node Administrator floating during the Knowledge Base
shutdown, add a new entry "preferredukb=null" to ukb.cfg file.
This setting ensures that all the managed Dynamic Node Administrators of that
Knowledge Base do not float to any other Knowledge Base when the owner
Knowledge Base is shut down.
To specify a Knowledge Base to which the Dynamic Node Administrators
managed by the Knowledge Base server must float when there is a problem
add a new entry "preferredukb = <failover UKB-host name>" in the ukb.cfg
file.
For Example:
If you add an entry in the ukb.cfg of host machine1 as: preferredukb =
machine2.xx.com, then, if the Knowledge Base service on machine1 either
fails or is stopped, the Knowledge Base on machine2 takes over all the
Dynamic Node Administrators that are being managed by the Knowledge Base
on machine1. The current Knowledge Base stores a list of all the Dynamic
Node Administrators that were floated to the preferred Knowledge Base and
when the Knowledge Base is restores, it will take back all of those Dynamic
Node Administrators.
Impact of Master Knowledge Base Crash on DIA
Symptom:
The Master Knowledge Base has crashed. You do not understand its impact on
DIA.
Solution:
If the Master Knowledge Base crashes, some of the functions like Dynamic
Node Administrator activation, zone lookup and grid synchronization fail.
Restart the services as soon as possible.
342 Implementation Guide
Troubleshooting and Diagnostics
Install DIA Without DNS Available
Symptom:
Working with DIA when DNS is not available.
Note: If DNS is available but the DNS SRV record cannot be set, see the topic
Install DIA Without an SRV Record Set.
Solution:
If there is no DNS available in a network, SRV records cannot be configured
and system or network names are not resolved to IP addresses. Host names
must be mapped to IP addresses in the etc/hosts file on every system in the
network.
Because DIA requires Fully Qualified Domain Names (FQDN, or host name with
domain appendices) to address a system, the FQDN of a system must be the
first name in the list in etc/hosts to which an IP address is mapped.
1.
Edit the etc/hosts file to make sure the first host name reference for an IP
address is the FQDN of the system. For example, entries in etc.hosts
should be similar to the following:
172.16.197.114 server.ca.com server serveralias1 serveralias2
2.
Follow the instructions in the topic Install DIA Without an SRV Record Set
(see page 344).
Note: You must configure etc/hosts accordingly on all the systems where DIA
is installed.
Appendix A: DIA Reference 343
Troubleshooting and Diagnostics
There is a new dialog box added in the installer for entering the MKB
hostname. This will override the Master Knowledge Base in the DNS SRV
records.
Install DIA Without an SRV Record Set
Symptom:
Working with DIA without setting the SRV record.
Solution:
In the dna.cfg file, specify the Master KB and set the parameter 'overrideSRV'
to 'Yes'.
344 Implementation Guide
Troubleshooting and Diagnostics
Note: You must modify the configuration file in all the systems where DIA is
installed. Override the MasterKB name on all these systems by running the
updateConfigFile utility under Install_Path\SC\CCS\DIA\dia\dna\bin. If
possible, use fully-qualified domain names in dna.cfg.
There is a new dialog box added in the installer for entering the MKB
hostname. This will override the Master Knowledge Base in the DNS SRV
records.
Multiple Entries in a Unicenter Knowledge Base in Grid
Symptom:
Grid displays multiple entries for the same Knowledge Base. While one entry is
with the original host name the other entry displays new IP address.
Solution:
In a DHCP environment, when you restart the system on which Unicenter
Knowledge Base is installed, it is possible that the DHCP server assigns a
different IP address to the system. It is further possible that the original IP
address is still available in the cache and record is not yet updated in the
Domain Name Service (DNS).
Since the Knowledge Base is not able to resolve the IP address to the host
name, the Master Knowledge Base adds the details to the grid, as a new
record with the new IP address assuming that it is a new record.
To remove the duplicate entries, do one of the following:
1.
Refresh the grid to update the local cache.
2.
Connect the DIA tool to the Master Knowledge Base or the local Knowledge
Base and remove the duplicated IP entry from the grid. Recycle the
Knowledge Base after you remove the Knowledge Base.
Note: Multiple entries in the grid do not have any impact on the functioning of
the DIA tool.
Number of Cells Supported by Dynamic Node Administrator or Knowledge Base
Symptom:
Not able to determine the limit on the number of cells that the Dynamic Node
Administrator or Knowledge Base can support.
Solution:
There is no limit to the number of cells that the Dynamic Node Administrator
or Knowledge Base can support. As the cells run in a separate process space,
the number of cells that can be supported depends on the system memory.
Appendix A: DIA Reference 345
Troubleshooting and Diagnostics
Potential Problems with DIA Consumer Applications
This section explains the potential problems with the main DIA consumers in
the Unicenter Network and Systems Management environment, which include
the following:
■
Adaptive Dashboards Server (ADS)
■
Event Cell
■
Management Command Center (Unicenter MCC)
■
Unicenter Management Portal (Unicenter MP) & Web Reporting Services
(WRS)
■
Unicenter Remote Monitoring
■
WVObject Cell
Adaptive Dashboards Server
Adaptive Dashboards Server (ADS) uses DIA for registration and updates. It
uses the Unicenter Knowledge Base as the interface to get information from
the cells regarding the different enterprise resources that need to be displayed
in the dashboards.
Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and
running locally or on a remote system that can be queried for information. In
addition to that, the dsmcell and the agctrlcell must be registered and active
to collect the information.
Potential Problems: Being a web-based application using Tomcat, the
dashboards may not be visible. The first thing to check is whether the Tomcat
server is up and running.
From the DIA perspective, if the dashboards application is not able to connect
to the Knowledge Base, it will not be able to show the latest information. In
this case, check the ukb0.log file to determine the exact reason.
If Tomcat and the Knowledge Base are both working properly, open the diatool
to verify that both the dsmcell and agctrlcell are working properly. If there is a
problem you can de-register and then reregister them. The cell-specific logs
can also provide a precise cause of the failure.
346 Implementation Guide
Troubleshooting and Diagnostics
Event Cell
The event cell depends on the DNA and the Unicenter Knowledge Base
services. It uses both the native and non-native API. The important binary for
the Event Cell is the cell registration binary, located at:
InstallPath\CA\SC/CCS/WVEM/bin/caamscellreg.exe
Potential Problems: The problems you might face with regards to the event
cell include the following:
■
Cannot connect to cell
■
No data from cell
Verify that the DNA and the owner Unicenter Knowledge Base services are
running and ensure that the event cell is enabled.
Management Command Center
The Unicenter Management Command Center (Unicenter MCC) uses DIA for
the correct and timely updates of status and other information that needs to
be used and displayed.
Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and
running locally or on a remote system that can be queried for information. In
addition, the amscell, mdbcell and the event cell must be registered and active
to collect the information from and send it to the Unicenter MCC.
Potential Problems: The Unicenter MCC has various views. The views that
are dependent on DIA could have trouble displaying the correct information
when the Dynamic Node Administrator or the Knowledge Base services are not
running properly.You must ensure that all the required cells are functioning
properly.
Appendix A: DIA Reference 347
Troubleshooting and Diagnostics
Unicenter Management Portal & Web Reporting Services
Unicenter MP and Web Reporting Services (WRS) are DIA clients and use it for
registration and updates. They use the Unicenter Knowledge Base (local or
remote) as the interface to get information from the cells (local or remote)
regarding the different enterprise resources that need to be displayed in the
dashboards.
Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and
running locally or on a remote system that can be queried for information. In
addition, the following cells are required for gathering the information:
■
wvobjectcell
■
caamscell
■
dsmcell
■
evtcell
Potential Problems: Most functionality is unavailable when DIA or the cells
are down. No reporting data is displayed. You will see the "unable to retrieve
data" messages and other messages that only a System Administrator will be
able to understand.
Restarting the Unicenter Knowledge Base is probably not possible since it is
unlikely the Knowledge Base is local to the Tomcat server. See the ukb0.log
file for more details
If Tomcat and the Unicenter Knowledge Base are both working properly, open
the DIA Diagnostic Tool to verify that both the dsmcell and agctrlcell are
working properly. If there is a problem, try deregistering and then
reregistering them. The cell-specific logs could also provide precise cause of
the failure.
Unicenter Remote Monitoring
Unicenter Remote Monitoring uses the DIA C-Gene – the communication
component of DIA – to communicate between the Administrative Interface and
Unicenter Remote Monitoring Agents.
Pre-requisites: DIA Dynamic Node Administrator must be installed and
running on both the Unicenter Remote Monitoring Agents and the
Administrative Interface nodes.
Potential Problems: Unicenter Remote Monitoring uses DIA for its
communications. If the Dynamic Node Administrator service fails or is stopped
on either the agent or the admin node, this communication fails and you get
an error message “Communication with the agent failed”
348 Implementation Guide
Troubleshooting and Diagnostics
You can also get this error message if the Dynamic Node Administrator is
running, but it is not activated properly to the Unicenter Knowledge Base. That
is, the libraries required for communication have not been pushed to the
Dynamic Node Administrator by the owner Knowledge Base. To confirm this,
check for the cgeneclient.dll library in the dna/lib directory. If this file is not
present, it means that the Dynamic Node Administrator was not activated
properly.
WVObject Cell
The WVObject cell depends on the Dynamic Node Administrator and the
Unicenter Knowledge Base. It uses both the native and non-native API. The
location of the registration and deregistration batch files are:
InstallPath\CA\SC\CCS\WVEM\Bin
The registration batch file is regwvcell.bat
The deregistration batch file is unregwvcell.bat
Potential Problems: Following are problems that a user might face with
regards to the WVObject cell:
■
Cannot connect to cell
■
No data from cell
To debug the problems related to the WVObject cell, do the following:
■
Check whether the WVObjectcell.exe, Dynamic Node Administrator, and
Unicenter Knowledge Base are running. Start them if they are not running.
■
Check whether the Severity Propagation Service and the database are
running. Start them if they are not running.
Primary Master Knowledge Base is Down
Symptom:
Primary Master Knowledge Base set for the network is down.
Solution:
It is mandatory to set a primary and secondary Master Knowledge Base for the
network.
The secondary Master Knowledge Base automatically takes over if the primary
Master Knowledge Base fails.
Appendix A: DIA Reference 349
Troubleshooting and Diagnostics
Primary and Secondary Master Knowledge Base Communication
Symptom:
Unable to understand the communication between primary and secondary
Master Knowledge Bases.
Solution:
The secondary Master Knowledge Base periodically interacts with the primary
Master Knowledge Base to get the information related to the grid, xml policy
and zone table. If the primary Master Knowledge Base is down, the secondary
Master Knowledge Base detects it and automatically takes over as the primary
Master Knowledge Base.
Reconfigure Unicenter Knowledge Base Into Master Knowledge Base
Symptom:
Unable to reconfigure the Knowledge Base into a Master Knowledge Base.
Solution:
You can reconfigure the Knowledge Base to act as a Master Knowledge Base
by modifying the dna.cfg file.
To reconfigure Unicenter Knowledge Base into the Master Knowledge Base, do
the following:
1.
Connect DIA tool to the local Knowledge Base and remove the Knowledge
Base entry from the grid.
2.
Stop the Dynamic Node Administrator and Knowledge Base services.
3.
Set overrideSRV=yes and MasterKB=<Local Host Fully Qualified Name> in
the dna.cfg file.
4.
Delete the 'ukbgridtable' table from the \dia\ukb\config folder.
5.
Restart the Dynamic Node Administrator and Knowledge Base services.
Remove Server from the Network and the Grid in DIA
Symptom:
A server is removed from the network but you cannot remove it from the grid.
Solution:
To remove an entry from the grid do one of the following:
■
Uninstall DIA from the server.
■
Use the Remove a Host from the Grid option in DIA tool.
350 Implementation Guide
Troubleshooting and Diagnostics
Security Concerns with DIA
Symptom:
Unable to encrypt DIA communications.
Solution:
All the DIA communications related to grid synchronization, activations and so
on are based on Java RMI and by default this information is not encrypted.
To encrypt these communications do the following:
■
In the dna.cfg and ukb.cfg configuration files, specify the value for the
RMI_ENCRYPTION parameter as 1.
That is, RMI_ENCRYPTION = 1
Note: Enable the encryption option for all the Dynamic Node Administrators
and Knowledge Bases so that they can communicate with each other.
Specific OS Configuration Requirements for DIA Installation
Symptom:
Not able to configure the system for installing DIA.
Solution:
DIA is installed as a part of Unicenter NSM and it has the same operating
system (OS) or hardware requirements that are required for Unicenter NSM.
Ensure that you have the required OS or hardware capability to install DIA.
Troubleshooting DIA Components
This following topics explain troubleshooting techniques for the following
components:
■
Unicenter Knowledge Base (see page 354)
■
Dynamic Node Administrator (see page 352)
■
Cells (see page 352)
Appendix A: DIA Reference 351
Troubleshooting and Diagnostics
Component Cell Binaries’ Location
This section explains the list of cells currently implemented in the Unicenter
environment and the location of their registration and de-registration binaries’
(assuming that the installation is under the default path).
Agent Control Cell:
InstallPath\CA\SC\CCS\AT\CELLS\InstallAgctrlCell.bat
DSM Control Cell:
InstallPath\CA\SC\CCS\AT\CELLS\InstallDsmCell.bat
WV Cell:
Registration:
InstallPath\CA\SC\CCS\WVEM\BIN\regwvcell.bat
Deregistration:
InstallPath\CA\SC\CCS\WVEM\BIN\Unregwvcell.bat
MDB Cell
Registration:
InstallPath\CA\SC\CCS\MDBCell\bin\mdbreg.bat
Deregistration:
InstallPath\CA\SCmponents\CCS\MDBCell\bin\mdbdereg.bat
Dynamic Node Administrator
The Dynamic Node Administrator runs as a service on all the DIA supported
platforms. A Dynamic Node Administrator is the minimum requirement for a
system that is DIA enabled. It is not mandatory that a Knowledge Base be
local on all the systems. A Dynamic Node Administrator can report to a remote
Knowledge Base. On Windows, the service manager has an entry for Dynamic
Node Administrator as CA DIA 1.3 DNA. You can manipulate the Dynamic Node
Administrator service using the service manager functions. The service spawns
two processes internally and they show up as dna.exe and dnasvc.exe in the
Windows Task Manager utility.
In addition to the service manager, you can handle the Dynamic Node
Administrator service from the console with the command line utilities that DIA
provides. In an install on the default location, the DNA service utility is located
at:
InstallPath\CA\SC\CCS\DIA\dia\dna\bin\dnacntl.exe
352 Implementation Guide
Troubleshooting and Diagnostics
You can start, stop, install, remove and check the status of the service using
this command line utility. Use the /? option to get the list of supported options
for the utility.
On Linux and UNIX platforms, the service structure is similar to that on
Windows. If you list the processes, two processes appear that correspond to
the Dynamic Node Administrator – dnasvcd and dna. In an install on the
default location, the Dynamic Node Administrator service utility is located at:
/opt/CA/SharedComponents/ccs/dia/dna/bin/dnacntl
You can start, stop, install, remove or check the status of the service using
this command line utility. In addition, you can use the Unicenter service
controller to manipulate the Dynamic Node Administrator service on Linux or
UNIX. The following is an example of the command:
unicntrl <option> CA-diadna
option can be: start | stop | install | remove | status
Activating Dynamic Node Administrator
In addition to the service binaries, Dynamic Node Administrator has another
important command line utility – autoactivatedna. This command line utility
activates the Dynamic Node Administrator to a specified Unicenter Knowledge
Base. Use this utility to change or set the current Dynamic Node
Administrator’s owner Knowledge Base. On Windows, this binary is located in
the following directory (assuming installation in the default location):
IntallPath\CA\SC\CCS\DIA\dia\dna\bin\autoactivatedna.bat
The following is an example of the command:
autoactivatedna.bat kb-name
If you do not specify the name of the Knowledge Base in the argument, the
system tries to activate the Dynamic Node Administrator to the local Unicenter
Knowledge Base. If there is no local Knowledge Base, it will locate the Master
Knowledge Base on the network and asks for an activation point.
Use this command if you have just setup your Master Knowledge Base system
and need to point to it.
You can determine what your machines current Dynamic Node Administrator’s
owner is by reading the contents of the ukb.dat file (located in
CCS\DIA\dia\dna\config). Creation of the ukb.dat file in the mentioned
directory can be inferred as successful completion of the autoactivatedna
process.
A problem with activation results in error “ConnectionRefusedException”
Appendix A: DIA Reference 353
Troubleshooting and Diagnostics
The most probable reason for this error is that the Knowledge Base that you
are trying to activate your Dynamic Node Administrator to, is either down or
unreachable. We recommend that you verify these configurations before
invoking this utility. Use the DIA tool to verify whether a Knowledge Base is up
or down.
For Linux and UNIX platforms, the utility invocation and behavior is exactly the
same. The utility is located in the directory (assuming default install location):
/opt/CA/SharedComponents/ccs/dia/dna/bin
The file is autoactivatedna.sh
The following is an example of the command:
./autoactivatedna.sh kb-name
Following are some of the problems that might occur during installation:
■
After install, the Agent-Only (Dynamic Node Administrator-only) systems
are not activated. The main reason for this is that the Master KB is not set.
See the DIA Reference Appendix in the Unicenter NSM Implementation
Guide for the procedure to set the Master Knowledge Base.
■
In rare cases, on some UNIX systems, you can have situations where the
Dynamic Node Administrator or Knowledge Base cannot be stopped and
the error message “Error stopping the Service” appears. To recover from
this situation, you must manually kill the service daemon (dnasvcd or
ukbsvcd) and the associated process (dna or ukb).
Unicenter Knowledge Base
The Unicenter Knowledge Base runs as a service on all DIA-supported
platforms. On Windows, the service manager has an entry for the Knowledge
Base as CA DIA 1.3 Knowledge Base. You can manipulate Knowledge Base
service using the service manager functions. The service spawns two
processes internally and they show up as ukb.exe and ukbsvc.exe in the
Windows Task Manager utility.
In addition to the service manager, the Knowledge Base service can also be
handled from the console with the command line utilities that we provide. In
an install on the default location, the Knowledge Base service utility is located
at:
InstallPath\CA\SC\CCS\DIA\dia\ukb\bin\ukbcntl.exe
You can start, stop, install, remove and check the status of the service using
this command line utility. Use the /? option to see the list of supported options
for the utility.
354 Implementation Guide
Troubleshooting and Diagnostics
For Linux and UNIX platforms, the service structure is similar to that of
Windows. Upon listing the processes, there are two processes that correspond
to the Knowledge Base – ukbsvcd and ukb. In an install on the default
location, the Knowledge Base service utility is located at:
/opt/CA/SharedComponents/ccs/dia/ukb/bin/ukbcntl
You can start, stop, install, remove or check the status of the service using
this command line utility. In addition, you can use the Unicenter service
controller to manipulate the Knowledge Base service on Linux or UNIX.
Example: Start, Stop, Install, Remove, or Check Status of the
Unicenter Knowledge Base
This example lets your start, stop, install, remove, or check status of the CAdiaukb:
unicntrl option CA-diaukb
option
start | stop | install | remove | status
Two Zones in DIA
Symptom:
A machine is shown under two zones in the DIA Diagnostic Tool. Not able to
rectify it.
Solution:
Recycle the Knowledge Base on the machine to refresh the zone name. The
problem is rectified automatically.
Appendix A: DIA Reference 355
Troubleshooting and Diagnostics
Unable to Autoactivate the Dynamic Node Administrator
Symptom:
Unable to autoactivate the Dynamic Node Administrator.
Solution:
Do any one of the following:
■
Check the network settings and ensure that you are able to resolve all the
host machines by nslookup or pinging.
■
If this is an activation issue related to an agent-only installation, check the
SRV record, xml rule file, network settings.
■
Ensure that the target Knowledge Base is up and the Knowledge Base
service is running on it.
Notes:
■
You can also recycle the Dynamic Node Administrator service to
automatically activate the Dynamic Node Administrator.
■
The Dynamic Node Administrator cannot change ownership if it is being
managed by a local running UKB.
Unable to Deploy Packages Using Package Deployment Infrastructure (PDI)
Symptom:
Unable to deploy packages using Package Deployment Infrastructure.
Solution:
The PDI (Package Deployment Infrastructure) cell is not enabled by default.
Enable and start the PDI cell when you want to use DIA's package deployment
feature.
Note: PDI is no longer a supported feature, but still gets packaged with DIA
for users who might be using it with earlier releases.
356 Implementation Guide
Troubleshooting and Diagnostics
Unable to Do an SRV Record Lookup
Symptom:
Unable to do an SRV record lookup.
Solution:
Check if SRV records are setup in DNS by using the following command.
c:\>nslookup
>set type=SRV
>_grid._tcp.ca.com <=== their domain where SRV records are setup
If SRV records are setup in DNS, you will get the following output:
Server:
usilsg01.xx.com
Address:
141.xxx.x.x
DNS request timed out.
timeout was 2 seconds.
_grid._tcp.xx.com
SRV service location:
priority
= 2
weight
= 0
port
= 11503
svr hostname
_grid._xxx.xx.com
= usildiaxxxxxx.xx.com
SRV service location:
priority
= 1
weight
= 0
port
= 11503
svr hostname
= usildxxx.xx.com
xx.com
nameserver = USILSxxx.xx.com
xx.com
nameserver = USLISxxx.xx.com
xx.com
nameserver = USILSxxx.xx.com
xx.com
nameserver = ASSYSxxx.xx.com
xx.com
nameserver = UKSLSxxx.xx.com
xx.com
nameserver = USILSxxx.xx.com
xx.com
nameserver = INHYSxxx.xx.com
usildiaxxxxxx.xx.com
internet address = 141.202.xxx.xxx
usildxxx.xx.com internet address = 141.202.xxx.xxx
USILSxxx.xx.com internet address = 141.202.xx.xxx
USLISxxx.xx.com internet address = 130.200.xx.xxx
USILSxxx.xx.com internet address = 141.202.x.xxx
ASSYSxxx.xx.com internet address = 155.35.xx.xxx
UKSLSxxx.xx.com internet address = 130.119.xx.xxx
USILSxxx.xx.com internet address = 141.202.x.xx
INHYSxxx.xx.com internet address = 155.35.xx.xxx
If you do not get the above response, then it implies that the SRV record
setting is not correct. See the section DIA Configuration for details about
setting up the SRV records.
Appendix A: DIA Reference 357
Troubleshooting and Diagnostics
Note: If the machine is setup using static IP make sure domain is defined in
"DNS suffix for this connection: This is defined under the DNS tab in
"Advance TCP/IP Settings". If you don't do this, you will get something like
"unable to find domain or failed to lookup SRV record ..." in the ukb0.log file.
When executing the ipconfig command, "Connection-specific DNS Suffix" field
should not be empty. If the machine is setup using DHCP, you don't need to
set this because the domain of the machine info is already stored somewhere
on the system.
Unable to Open DIA Tool
Symptom:
The correct user name and password is given but the DIA tool is unable to
open successfully.
Solution:
Do one of the following:
■
Verify whether the system to which you are trying to connect has DIA, and
more importantly that a Unicenter Knowledge Base is installed.
■
If the first point is yes, verify whether the Unicenter Knowledge Base
service is running on that system.
If either of these scenarios is true, you will not be able to open the DIA tool
successfully and would get the message “Unable to Connect to system-name”
appears. Also, the console window that opens up with the DIA tool shows the
entire error trace. This indicates you should verify these two solution points.
Unicenter Knowledge Base Failure in Firewall Scenario
Symptom
In a firewall scenario, Unicenter Knowledge Base does not automatically take
over another Knowledge Base. You do not understand its impact on consumer
applications.
Solution:
You need extra configuration for one Knowledge Base to automatically take
over another Knowledge Base in a firewall scenario. If the Knowledge Base
that is located either inside or outside the firewall belongs to same zone, then
you can route the request from a consumer application that is running inside
the firewall to an external Knowledge Base.
If the proxy Unicenter Knowledge Base fails, the C-Gene communications and
the request and response mechanisms of the Knowledge Base do not work.
358 Implementation Guide
Troubleshooting and Diagnostics
Utilities to Assist Troubleshooting DIA
The topics that follow list utilities that will help you troubleshoot DIA and
collect additional information to aid your troubleshooting.
Diacontrol Utility
The diacontrol utility located in the dia\ukb\bin folder is intended to find, and
in some cases fix, inconsistencies in the DIA grid. The DIA grid consists of a
number of Unicenter Knowledge Bases (UKBs) installed on Unicenter NSM
manager nodes and a large number of Dynamic Node Administrators (DNAs),
installed on NSM agent nodes.
Each DNA is activated and managed by one of the UKBs, its owner UKB. A
designated Master Knowledge Base, which is also a fully functional UKB,
maintains information about all DIA installations in the grid and provides this
information to all other UKBs. The DIA grid can be divided into different zones
with only the Master Knowledge Base having knowledge about all zones, but
all other DIA installations having knowledge only about other DIA nodes that
are in the zone assigned to them.
DNA Ownership and Floating
Ideally each DNA node is managed by one UKB node, the node by which it was
activated. The initial activation of a DNA node by a UKB causes the UKB to add
the DNA node to a list of original DNAs. DIA communication between DNA
nodes, or between a DNA and a UKB, typically runs through the owner UKB,
which forwards the data or request to the target UKB, or the owner of the
target DNA.
To avoid loss of communication with all managed nodes, a UKB on shutdown
floats the DNAs it manages to another UKB node, which can either be specified
with the preferredukb parameter in the ukb.cfg file or which is chosen from a
list of other UKB nodes in the same zone. The remote UKB that takes over the
DNAs adds them to a list of floating DNAs.
On startup, the UKB attempts to take back ownership of its original DNAs. It
also goes through the list of floating DNAs it had managed prior to shutdown
and resume managing those that are not currently managed by another UKB.
Appendix A: DIA Reference 359
Troubleshooting and Diagnostics
DIA Grid Problems Targeted by This Utility
DIA does not have an expiration date on grid membership. A node is removed
from the grid on DIA uninstall, but this requires the node to be connected to
the DIA grid during uninstall. Removing a host without uninstalling DIA while
connected to the DIA grid may cause stale entries in the grid.
The Diatool User Interface provides an option to float DNAs from one UKB to
another, permanently changing original ownership. Sometimes there are
problems with selected DNA installations that require manual reactivations,
often involving a cleanup of local activation files. In such cases the DNA node
is added to the original DNA list of the new owner UKB without being removed
from the list on the previous owner. This may or may not be visible in the DIA
grid as displayed by the Diatool. This utility cannot distinguish between
original DNAs and floating DNAs.
DIA nodes may be moved into another zone, or moved into another grid
managed by a different Master Knowledge Base. If this is done without going
through an uninstall while connected to the old grid, the node may remain in
the old grid, and a node with the UKB service installed may continue to be
chosen by the Master Knowledge Base as owner of a new DNA installation in
the old grid.
360 Implementation Guide
Troubleshooting and Diagnostics
Diacontrol Usage
Diacontrol implements the following commands to find or correct problems:
Syntax:
diacontrol UKB-host testconnect
Attempts a connection to the specified UKB host and reports success or failure.
In case of a failure, errors or exceptions can be found in the file diacontrol.err
in the current directory.
diacontrol UKB-host list alldnas
Lists original, first all and then those currently managed, and all floated DNAs
for the specified UKB host. A DNA node that is down and not managed by
another UKB may be included in the currently managed list. This would not be
regarded as a problem. However, a node should not be listed as currently
managed in two different UKBs though.
diacontrol UKB-host list origdnas [all]
Lists all original DNAs for the specified UKB host. These DNAs should be
managed by this UKB, which is possibly not the case.
diacontrol UKB-host list origdnas owned
Lists all original DNAs that are currently owned (managed) by the specified
UKB host.
diacontrol UKB-host list origdnas other
Lists all original DNAs that are currently not owned (managed) by the specified
UKB host.
diacontrol UKB-host list floatdnas
Lists all DNAs currently owned by the specified UKB host, but that are not
registered in the original DNA list. These DNAs were floated over from other
UKBs. This list should only contain nodes that are in the original DNA list of
UKBs and that are currently down.
diacontrol UKB-host list dnaowner DNA-host
Lists the owner UKB information for the specified DNA host as found by the
specified UKB host. This command is intended to check on grid consistencies.
It should return the same information for any UKB host in the grid.
diacontrol UKB-host list zonelist
Appendix A: DIA Reference 361
Troubleshooting and Diagnostics
Lists the ukbzonelist on the specified UKB host. For a regular UKB this
command lists all UKBs in the same DIA zone. If the UKB host is the active
Master Knowledge Base, it lists all UKBs in the DIA grid, and the zone each
UKB belongs to.
diacontrol MasterKB-host list ukbs zone
Lists all UKB hosts in the specified zone. The specified MasterKB host needs to
be the active Master Knowledge Base. The zone parameter is case sensitive
and the default DIA zone is "Default".
Important! Use the following commands with caution.
diacontrol UKB-host remove origdna DNA-host
Removes a stale DNA host entry from the original DNA list of the UKB host.
This command may be used to remove an incorrect entry, such as duplicate
entries or entries of installations that are known to no longer exist, as
identified by one of the list commands described above. Use with caution.
diacontrol UKB-host remove floatdna DNA-host
Removes a stale DNA host entry from the floated DNA list of the specified UKB
host (similar to the previous command). Use with caution.
diacontrol UKB-host remove ukb UKB-host-to-remove
Removes a UKB host entry from the zone table on the specified UKB host. This
command can be used to remove a stale entry from the local ukbzonelist, or
the masterukbzonelist on the Master Knowledge Base. It will not remove this
UKB from the DIA grid. Use the diatool to remove UKBs that are currently
found in the grid. Use with caution.
DIA Environment Checks
The following commands can be used to check if DIA works as expected:
■
Send a ping from a manager system to an agent system and conversely.
■
Perform nslookup from manager to agent and conversely
■
Run telnet on a manager system and connect to an agent system by using
port 11501.
■
Run telnet on an agent system and connect to a manager system by using
port 11503.
■
Send a ping from an agent system and from a manager system to the
master.
■
Run telnet on an agent system and on a manager system and connect to
the master by using port 11503.
362 Implementation Guide
Troubleshooting and Diagnostics
Dynamic Node Administrator-Related Utilities
The following utilities are available with the Dynamic Node Administrator:
GetRegisteredCells
Use the GetRegisteredCells utility to get a list of registered cells on a
particular Dynamic Node Administrator.
Syntax:
GetRegisteredCells.bat DNA_Host_Name|IP_Address
DNA_Host_Name|IP_Address
Specifies the name of the Dynamic Node Administrator host or its IP
address for which you want to see the list of cells.
Note: The utility returns only the external cell list; for example, the
Unicenter NSM cells are all external cells and cells such as pdicell are DIA
internal cells.
The files used to run the utility are GetRegisteredCells.bat (Windows) or
GetRegisteredCells.sh (Linux/UNIX).
GetCellInfo
Use the GetCellInfo utility to get cell information from a particular Dynamic
Node Administrator.
Syntax:
GetCellInfo.bat DNA_Host_Name|IP_Address Cell_Name
DNA_Host_Name|IP_Address
Specifies the name of the Dynamic Node Administrator host or its IP
address for which you want to see the cell information.
Cell_Name
Specifies the name of the cell about which you want to get
information.
Note: The utility returns information about external cells only; for
example, the Unicenter NSM cells are all external cells and cells such as
pdicell are DIA internal cells.
The files used to run the utility are GetCellInfo.bat (Windows) or
GetCellInfo.sh (Linux/UNIX).
Appendix A: DIA Reference 363
Troubleshooting and Diagnostics
setLogLevel
Use the setLogLevel utility to set the logging level of a particular Dynamic
Node Administrator or UKB.
Syntax:
setLogLevel dna|ukb|cgene hostname loglevel
dna|ukb|cgene
Specifies whether the logging level is to be set for a Dynamic Node
Administrator, a Knowledge Base, or a cgene.
hostname
Specifies the host name of the Dynamic Node Administrator or
Knowledge Base host for which you want to change the logging level.
loglevel
Specifies the logging level you want to set. Valid values are OFF,
SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, or ALL.
Note: The utility changes the logging level in process. It is not necessary
to restart the Dynamic Node Administrator or Knowledge Base to make the
change effective. The log level set by the setLogLevel utility is applied at
runtime. The log level in configuration files is applied at the time of startup
only.
updateConfigFile
This utility is used for changing the configuration files of UKB, DNA, cell, or
cgene on DIA systems.
Syntax:
updateConfigFile.bat hosts_file_name config_file_name property_name
property_value
hosts_file_name
Specifies the file name that stores the host names or IP addresses of
the UKBs and DNAs on which the configuration information is going to
be changed.
364 Implementation Guide
Troubleshooting and Diagnostics
config_file_name
Specifies the name of the configuration file in which the configuration
information is going to be changed; for example, UKB, DNA, cell, or
cgene.
property_name
Specifies the name of the property that needs to be changed.
property_value
Specifies the new value of the property.
Note: The LOG property is updated during runtime but not in the
configuration files. For all other properties a restart of the service is
required.
Knowledge Base-Related Utilities
The following utilities are available with the Unicenter Knowledge Base:
getMasterKB
Use the getMasterKB utility to get the Master KB of the specified doc.
Syntax:
getMasterKB.bat KB Host Name/IP
KB Host Name/IP
Specifies the Knowledge Base host for which you want to get the
Master KB.
The files used to run the utility are getMasterKB.bat (Windows) or
getMasterKB.sh (Linux/UNIX).
getOwnerKB
Use the getOwnerKB utility to get the Knowledge Base owner of a given
Dynamic Node Administrator host.
Syntax:
getOwnerKB.bat DNA Host Name/IP
DNA Host Name/IP
Specifies the Dynamic Node Administrator host for which you want to
get the Knowledge Base owner.
The files used to run the utility are getOwnerUKB.bat (Windows) or
getOwnerUKB.sh (lLinux/UNIX).
Appendix A: DIA Reference 365
Troubleshooting and Diagnostics
getSRVInfo
Use the getSRVInfo utility to get the SRV records of the domain.
Syntax:
getSRVInfo.bat domain name
domain name
Specifies the current domain name. Specifying the domain name is
optional for Linux or UNIX if the domain name entry is present in the
/etc/resolve.conf file.
The files used to run the utility are getSRVInfo.bat (Windows) or
getSRVInfo.sh (Linux/UNIX).
refreshZone
Use the refreshZone utility to reload the Master Knowledge Base rule file,
refresh the zone or grid, or reset the zone.
Syntax:
refreshzone.bat kb|zone|reset mode_value
kb|zone|reset
Specifies the mode the utility is to use.
The kb mode reloads the rule file of the Master Knowledge Base or
synchronizes grid and zone information of a Knowledge Base with the
Master Knowledge Base.
The zone mode contacts all Knowledge Bases in the zone to
synchronize zone and grid information with the Master Knowledge
Base.
The reset mode is used primarily when the zone of a Knowledge Base
changes and there is still a stale entry in the old zone. The reset mode
takes time to run if there are many Knowledge Bases in the old and
new zones. The process notifies every Knowledge Base in the old zone
to remove the stale Knowledge Base entry.
366 Implementation Guide
Troubleshooting and Diagnostics
mode_value
Specifies the Knowledge Base name or zone name on which to take
action.
If you specify the kb mode, the mode_value should be the name or IP
Address of the Knowledge Base. If you specify the Master Knowledge
Base name, the utility reloads the rule file. If you specify the regular
Knowledge Base name, the grid and zone information of the
Knowledge Base is synchronized with the Master Knowledge Base.
If you specify the zone mode, the mode_value should be the zone
name you want to reset and the utility contacts every Knowledge Base
in the zone you specify to synchronize the zone and grid of each
Knowledge Base with the Master Knowledge Base.
If you specify the reset mode, the mode_value should be the name of
the Knowledge Base that still has an entry in the old zone.
The files used to run the utility are refreshZone.bat (Windows) or
refreshZone.sh (Linux/UNIX).
getZone
Use the getZone utility to get the Knowledge Base zone name from the
Master Knowledge Base according to the rules set for it.
Syntax:
getzone.bat MasterKB Host_Name|IP
MasterKB
Specifies the name of the Master Knowledge Base.
Host Name/IP
Specifies the Knowledge Base host for which you want to get the
zoning information.
The files used to run the utility are getZone.bat (Windows) or getZone.sh
(Linux/UNIX).
Appendix A: DIA Reference 367
Troubleshooting and Diagnostics
Examples: Synchronize Zone and Grid Information for Knowledge
Bases
■
This example for Linux/UNIX synchronizes the zone and grid information of
knowledgebase1 with the Master Knowledge Base:
refreshZone.sh kb knowledgebase1
■
This example for Windows synchronizes the zone and grid information of
all Knowledge Bases in zone1 with the MasterKB.
refreshZone.bat zone zone1
■
This example for Linux/UNIX notifies all Knowledge Bases in a zone when
the zone of a Knowledge Base changes.
refreshZone.sh reset knowledgebase2
368 Implementation Guide
Appendix B: Making Components
Cluster Aware and Highly Available
This section contains the following topics:
Cluster Aware and High Availability Introduction (see page 369)
CA High Availability Service (see page 369)
Failover and Failback (see page 370)
Resource Groups (see page 371)
Unicenter NSM Highly Available Components (see page 374)
How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) (see
page 375)
How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server
Databases) (see page 377)
How You Install, Reinstall, or Uninstall Unicenter NSM Components (see page
379)
How WorldView Becomes Cluster Aware (see page 380)
How Event Management Becomes Cluster Aware (see page 380)
How AEC Becomes Cluster Aware (see page 383)
How Alert Management Becomes Cluster Aware (see page 384)
Cluster-Aware Agent Technology (see page 386)
Cluster Aware and High Availability Introduction
As organizations continue to conduct business in a global economy, it has
become increasingly important to meet the exacting computing capabilities
such an environment demands. More and more organizations are employing
clustering technology and demand the high availability of resources in the
wake of component failures in the system.
To meet these demands, the CA High Availability Service (HAS) is provided as
part of CA Common Services and Unicenter NSM to support fault tolerant
functionality when Unicenter NSM is running in a cluster environment.
CA High Availability Service
HAS makes Unicenter NSM components highly available, promoting minimal
down time and using resources optimally to ensure that your enterprise is
continuously monitored and managed. Using cluster technology, HAS makes
Unicenter NSM components cluster aware, providing high availability of service
and maximizing the performance and value of your enterprise.
Appendix B: Making Components Cluster Aware and Highly Available 369
Failover and Failback
Using HAS, applications are automatically registered, which lets them receive
status and notifications. Once registered, an application can be failed over
(migrated) to another node on the cluster, ensuring continuous service.
HAS supports the following vendor clusters:
■
Microsoft Cluster Service (MSCS)
■
Linux Red Hat Cluster Manager
Note: The MDB does not support cluster failover using Red Hat Cluster.
■
Sun Cluster (Solaris)
■
VERITAS Cluster Server (Sun Solaris)
■
Hewlett Packard Multi-Computer/Service Guard (MC/SG)
■
IBM High Availability Cluster Multiprocessing for AIX (HACMP)
Important! If you are installing UNIX agents into a cluster environment and
want to enable HAS, go to http://supportconnect.ca.com/sc/support/Index for
details.
Note: Unicenter NSM r11 and r11.1 do not support an upgrade of the CA High
Availability Service if you have an existing HAS 3.1 product installed on the
computer. See the Migration Guide at http://ca.com/support for additional
information.
Failover and Failback
Cluster technology enables failover and failback operations.
Failover is an important fault-tolerant function of mission-critical systems that
demand constant availability.
Failover is a backup operation in which the functions of a system component
(such as a processor, server, network, or database) automatically and
transparently switch to secondary system components when the primary
component becomes unavailable through either failure or scheduled down
time.
Failback is the process of migrating a failed application back to its original
node to rebalance workloads when a previously failed component is available
again.
Typically, failover—the switch from a primary system to a backup system—is
configured to perform automatically, while failback is a manual task. The
manual task ensures that the problem is properly identified and corrected
before functionality is returned to the original component.
370 Implementation Guide
Resource Groups
Resource Groups
A common characteristic of a clustering solution is the concept of resource
groups. A resource group is the logical entity that combines all of the
resources required to make a service or application highly available. Resources
can include physical hardware devices, such as disk drives and network cards,
or logical entities, such as logical disk volumes, TCP/IP addresses, entire
applications, and databases.
Note: An HP-UX package corresponds to a HAS resource group. An HP-UX
service corresponds to a HAS resource.
Resource Groups on Linux Platforms
In most cluster implementations, resources are distinct from resource groups.
On Linux platforms, no explicit definition for resources exists. In other words,
in Red Hat Cluster Manager, a one-to-one mapping between resources and
resource groups exists. You can distinguish resources from resource groups by
correctly using the service control script. If a service has five distinct
applications, each can be viewed as a resource. You can use the control script
to start, stop, and get the status of these applications separately, but report
the results to the cluster as one return code. For example, if a Unicenter NSM
resource group contained CAICCI, Event Management, and an agent, you
could use the control script to start, stop, and get the status of these
resources as a whole. These resources would then migrate together as a
resource group when a failover occurs.
Cluster Configuration
Clusters are groups of computers that function together as a single entity for
the purpose of parallel processing, load balancing, and fault tolerance. Using
cluster technology increases the reliability and availability of a computer
system. It keeps applications highly available by providing failover capabilities.
The system is no longer dependant on a single server.
The cluster software attempts to make the environment on each of the
different computers appear uniform for the applications that run on them.
Appendix B: Making Components Cluster Aware and Highly Available 371
Resource Groups
The combination of shared resources and uniform runtime environments
enables an application to migrate efficiently from one computer to another.
The application can save its information to shared storage, shut down, and
then start up on a different computer in the cluster.
When clusters are used, an enterprise is protected from the costly effects of
downtime. A system that is clustered promotes the availability of all shared
resources should a system outage occur. In addition, clustering technology lets
you add small, standard systems incrementally, instead of having to commit to
high-end servers.
The two types of cluster configurations supported by HAS are as follows:
Active/Passive Cluster Configuration
An active/passive configuration allows you to have a single instance of a
fault tolerant component running on one of the physical servers in the
cluster. The other nodes in the cluster are in standby mode until a failure
on the active node or a manual failover during maintenance occurs.
Active/Active Cluster Configuration
An active/active configuration allows you to have multiple instances of a
fault tolerant component running on both nodes of a two-way cluster. If
one of the instances in the cluster fails, the failed instance automatically
fails over to the other server.
Shared Disk Support
During the installation of Unicenter NSM in a cluster environment, several
components that install in HA mode store their data files on the Shared Disk
configured in the cluster. CA-HAS supports the following Disk and Storage
resource types available on a MSCS cluster:
The cluster software attempts to make the environment on each of the
different computers appear uniform for the applications that run on them.
Physical Disk
The default Resource Type available on MSCS.
Volume Manager Disk Group
The Disk Group Resource available with the Veritas HA Software
Foundation option installed on MSCS.
IBM ServeRAID Logical Disk
The Disk Resource Type available when the IBM ServeRAID NT Cluster
Solution utility is installed on MSCS.
Note: the Quorum Disk is not considered a valid shared disk for this purpose.
372 Implementation Guide
Resource Groups
HAS Architecture
HAS includes a set of extensions to Unicenter NSM that provide fault-tolerant
functionality when running Unicenter NSM in a cluster environment. When a
Unicenter NSM component is installed, the installation checks for the existence
of the HAS service on Windows, or the HAS daemon on UNIX/Linux. If this
service or daemon exists, the Unicenter NSM component registers with HAS
and installs what it needs to be highly available. The HAS service or daemon,
which runs on all cluster nodes, acts as the middleman between the cluster
and the Unicenter NSM components. The HAS service or daemon monitors the
cluster, and provides notifications when resource groups change state.
The Cluster Service Layer (CSL) insulates Unicenter NSM from cluster
complexities and thus, makes Unicenter NSM components independent of any
specific vendor clusters. Unicenter NSM components communicate to HAS
using the CSL.
Appendix B: Making Components Cluster Aware and Highly Available 373
Unicenter NSM Highly Available Components
Unicenter NSM Highly Available Components
The following Unicenter NSM components can be made cluster-aware and
highly available:
Event Management
Event Management records, correlates, processes, and presents the events
that occur within the enterprise. Event Management is typically the
backbone of any enterprise management system and, therefore, it is
essential that it be both cluster-aware and highly available within a
clustered environment.
Note: Event Management is not highly available on Linux platforms.
Advanced Event Correlation
Advanced Event Correlation (AEC) acts as a front end filter to the Event
Management system, providing correlation, root cause, and impact
analysis for the events being received. Event Management is fully cluster
aware, and, therefore, it is essential that AEC is also fault tolerant to the
same degree to ensure event processing continuity and quality is
maintained from the point of failure.
Note: Since Event Management is not highly available on Linux platforms,
AEC is not highly available on Linux platforms.
Agent Technology
Agent Technology lets you closely monitor the critical computing resources
in your enterprise by configuring individual agents to instrument these
resources. Agent Technology uses agents throughout the enterprise to
collect data, such as information on file systems, databases, and memory
usage. This data is distributed to one or more management nodes or DSMs
that interpret the data and take action based on custom configurations.
Cluster-aware agents use HAS to operate within a cluster environment and
to continue monitoring critical resources even in failover situations.
Alert Management
Alert Management is atool for organizing and tracking the most important
events in an enterprise or logical segment of an enterprise. It lets you
focus on and manage the hisghest severity IT events. Alert Management is
fully cluster aware and highly available in a clustered environment.
Note: Alert Management isnot highly available on Linux or UNIX
platforms.
WorldView
WorldView offers a highly visual and intuitive approach to enterprise
management with the 2D Map available through the Management
Command Center, the Unicenter Browser Interface, and the WorldView
Classic GUI.
374 Implementation Guide
How You Set Up Unicenter NSM to be Highly Available (Ingres Databases)
How You Set Up Unicenter NSM to be Highly Available
(Ingres Databases)
HAS makes Unicenter NSM components highly available, promoting minimal
down time and using resources optimally to ensure that your enterprise is
continuously monitored and managed.
To set up Unicenter NSM to be highly available, do the following:
1.
Install cluster software on each computer in the cluster.
2.
Set up a Unicenter NSM resource group on the cluster that contains, at a
minimum, the following resources:
■
Virtual IP
■
Virtual network name
■
A shared disk
Important! The Quorum Disk cannot be listed as a valid shared disk.
Also, there must be only ONE virtual IP and virtual network name in the
resource group.
3.
On the first node in the cluster, install Unicenter NSM and all the
components you want to use.
HAS is installed automatically as part of CA Common Services or Unicenter
NSM on a clustered computer where cluster software is present. For
example, on Windows, HAS is installed on a computer where Microsoft
Cluster Service is running, and on Linux, HAS is installed on a computer
where Red Hat Cluster Manager is running.
Note: Before installing Unicenter NSM cluster-aware agents, check the
following on each cluster node:
■
Verify that the native cluster service/daemon is running.
■
Verify that the servers and cluster are set up properly by forcing the
resource groups to fail over and by connecting a client.
■
Verify that SNMP is running correctly.
Important! To ensure that HAS works across the nodes of your cluster,
you must run HAS under a cluster domain account on Windows and as the
root user on UNIX/Linux.
HAS detects that the computer is in a cluster and a dialog box appears
that lists all of the resource groups in the cluster.
4.
Select the Unicenter NSM resource group.
Depending on the components you installed, one or more of the following
Unicenter NSM resources are added to the resource group:
■
Ingres Service
Appendix B: Making Components Cluster Aware and Highly Available 375
How You Set Up Unicenter NSM to be Highly Available (Ingres Databases)
■
CA-Unicenter Service
■
WorldView Severity Propagation Service
■
"UNISHARE$" file share
Since all of Unicenter NSM resources belong to one resource group, all of
Unicenter NSM fails over at the same time.
Note: Since these Unicenter NSM resources are to be managed by the
cluster administrator, during the install you may notice that the option to
autostart these services is disabled. In addition, Security Management is
unavailable in a highly available install.
5.
After the installation completes on the first node, perform the following
tasks:
a.
Take the Unicenter NSM resources offline.
b.
Move the Unicenter NSM resource group over to a subsequent node in
the cluster that does not yet have Unicenter NSM installed on it.
6.
Be sure the cluster resources (virtual IP, network name, and shared disk)
are still online.
7.
On all subsequent nodes in the cluster, install Unicenter NSM and the
same components you installed on the first node.
HAS is installed automatically.
8.
After the installation completes on each subsequent node, perform the
following tasks:
a.
Take the Unicenter NSM resources offline.
b.
Move the Unicenter NSM resource group over to a subsequent node in
the cluster that does not yet have Unicenter NSM installed on it. The
resource group must be present on the node before you can install
Unicenter NSM.
Note: If this is the last node in the cluster, you do not need to move
the resource group.
9.
After Unicenter NSM has been installed on all nodes in the cluster, bring
the Unicenter NSM resources online.
Unicenter NSM is now running in a highly available mode.
Note: If you install CA Common Service on a standalone computer and then
add the computer to a cluster, the HAS service or daemon does not start
automatically. You must manually start the HAS service/daemon or restart the
computer.
376 Implementation Guide
How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases)
How You Set Up Unicenter NSM to be Highly Available
(Microsoft SQL Server Databases)
HAS makes Unicenter NSM components highly available, promoting minimal
down time and using resources optimally to ensure that your enterprise is
continuously monitored and managed.
To set up Unicenter NSM to be highly available, do the following:
1.
Install cluster software on each computer in the cluster.
2.
Select one instance of a Microsoft SQL Server cluster resource group to
use for Unicenter NSM.
HAS will use the related network name and IP address as set up from the
Microsoft SQL Server installation.
Note: In the steps that follow, "Unicenter NSM resource group" refers to
the Microsoft SQL Server cluster resource group that you are using for
Unicenter NSM.
Important! In the Microsoft SQL Server cluster resource group, there
must be only ONE virtual IP and virtual network name. Unicenter NSM will
not install in HA mode if more than one virtual IP or network name is
defined in the same resource group.
3.
On the first node in the cluster, install Unicenter NSM and all the
components you want to use.
HAS is installed automatically as part of CA Common Services or Unicenter
NSM on a clustered computer where cluster software is present. For
example, on Windows, HAS is installed on a computer where Microsoft
Cluster Service is running.
Note: Before installing Unicenter NSM cluster-aware agents, check the
following on each cluster node:
■
Verify that the native cluster service/daemon is running.
■
Verify that the servers and cluster are set up properly by forcing the
resource groups to fail over and by connecting a client.
■
Verify that SNMP is running correctly.
Important! To ensure that HAS works across the nodes of your cluster,
you must run HAS under a cluster domain account on Windows.
HAS detects that the computer is in a cluster and a dialog box appears
that lists all of the resource groups in the cluster.
4.
Select the Unicenter NSM resource group.
Depending on the components you installed, one or more of the following
Unicenter NSM resources are added to the resource group:
■
CA-Unicenter Service
Appendix B: Making Components Cluster Aware and Highly Available 377
How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases)
■
WorldView Severity Propagation Service
■
"UNISHARE$" file share
Since all of Unicenter NSM resources belong to one resource group, all of
Unicenter NSM fails over at the same time.
Note: Since these Unicenter NSM resources are to be managed by the
cluster administrator, during the install you may notice that the option to
autostart these services is disabled. In addition, Security Management is
unavailable in a highly available install.
5.
After installation of a WorldView Manager on a node in the HAS cluster
environment, if the WorldView Manager installation requires a shutdown
and restart, after shutdown and restart, you must run the following
command to ensure the WorldView Object Cell (wvobjectcell.exe) is not
running before you can install the WorldView Manager on other cluster
nodes:
wvcellservice.exe 2
Note: If the WorldView Manager installation does not require a reboot
then no other action is required.
6.
After the installation completes on the first node, perform the following
tasks:
a.
Take the Unicenter NSM resources offline.
b.
Move the Unicenter NSM resource group over to a subsequent node in
the cluster that does not yet have Unicenter NSM installed on it.
7.
Be sure the cluster resources (virtual IP, network name, and shared disk)
are still online.
8.
On all subsequent nodes in the cluster, install Unicenter NSM and the
same components you installed on the first node.
Important! If a WorldView Manager installation requires a shutdown and
restart, perform Step 5 on each node in the cluster.
HAS is installed automatically.
9.
After the installation completes on each subsequent node, perform the
following tasks:
a.
Take the Unicenter NSM resources offline.
b.
Move the Unicenter NSM resource group over to a subsequent node in
the cluster that does not yet have Unicenter NSM installed on it. The
resource group must be present on the node before you can install
Unicenter NSM.
Note: If this is the last node in the cluster, you do not need to move
the resource group.
10. After Unicenter NSM has been installed on all nodes in the cluster, bring
the Unicenter NSM resources online.
378 Implementation Guide
How You Install, Reinstall, or Uninstall Unicenter NSM Components
Unicenter NSM is now running in a highly available mode.
Important! If you need to recreate the WorldView class hierarchy using the
Create Repository (maketng.exe) utility, you must ensure that the WorldView
Object Cell (wvobjectcell.exe) is not running on any of the other nodes except
the active node. If it is running on any node other than the active node, stop it
using the “wvcellservice.exe 2” command. After all of the WorldView Object
Cells (wvobjectcell.exe) are stopped on all the non-active nodes, you can run
the Create Repository (maketng.exe) utility to recreate the WorldView class
hierarchy.
Note: If you install CA Common Service on a standalone computer and then
add the computer to a cluster, the HAS service or daemon does not start
automatically. You must manually start the HAS service/daemon or restart the
computer.
How You Install, Reinstall, or Uninstall Unicenter NSM
Components
You must take all Unicenter resources (CA WorldView Severity Propagation
Service, CA-Unicenter) offline before taking any of the following actions:
■
Reinstalling Unicenter NSM
■
Installing any Unicenter NSM option or component after Unicenter NSM is
installed
■
Installing any product that integrates with Unicenter NSM (for example
Systems Performance Option)
■
Uninstalling Unicenter NSM
Use the Cluster Administrator tool that is available in Windows to take the
Unicenter resources offline.
Do not use the Service Control Manager to take any of the Unicenter resources
offline. Only use the Service Control Manager to shut down services that are
not registered cluster resources, such as Agent Technology.
Appendix B: Making Components Cluster Aware and Highly Available 379
How WorldView Becomes Cluster Aware
How WorldView Becomes Cluster Aware
In a clustered environment, the WorldView Manager and the WorldView Admin
Client components are closely integrated with HAS and are compliant with the
highly available directives of the HAS service.
■
When the WorldView Manager component is installed in a clustered
environment, the installation process determines the location and setup of
the installation environment, which includes information about local and
shared drives, failover and failback events, and so on.
■
Only one instance of the WorldView Manager runs against the MDB at any
one time. The WorldView Manager must be installed on the MDB server.
■
The Severity Propagation Service is added to the Unicenter NSM resource
group, and when the Severity Propagation Service is failed over by HAS, it
automatically fails over with the MDB.
■
The WorldView Admin Client is highly available only as a convenience.
■
Part of the WorldView Manager component is the WorldView Provider.
■
A Global Catalog can be placed on a cluster and is highly available. A
Global Catalog file, the AIS catalog, is stored on the shared cluster drive.
WorldView Resource Group
Within the cluster, the Severity Propagation Service is added to the <nsm,>
resource group and shared.
How Event Management Becomes Cluster Aware
In a clustered environment, the Event Manager components are closely
integrated with HAS and are compliant with the highly available directives of
the HAS service.
■
When Event Management is installed in a clustered environment, the
installation process determines the location and setup of the installation
environment, which includes information about local and shared drives,
failover and failback events, and so on.
■
All Unicenter NSM Event manager configurations are added to the
Unicenter NSM resource group.
■
Only one instance of Event Management will be running at any time within
the cluster, which is controlled by HAS.
380 Implementation Guide
How Event Management Becomes Cluster Aware
■
When failover occurs, the Event daemon resumes processing from the
point of failure, even if this is within a sequence of Message Actions
associated with a Message Record, for multiple action threads. This action
is controlled by the CA_OPR_MONITOR_STATE environment variable.
■
SAF processing resumes from the point of failure.
Event Management Resource Groups
Within the cluster, the following Event Management resources are placed on
the shared disk and shared among cluster nodes:
■
Console logs, which are the set of log files to which the events are written
and recorded. After the failover, incoming events continue to be written to
the same log, which ensures continuity for any external applications
running against that log such as the Event Console.
■
Caopr.dsb file, which is a binary representation of the MSGRECORD\
MSGACTION policies. That ensures the implemented policy remains
consistent when the failed over Event daemon is started by HAS, or when
failback occurs.
■
SAF configuration file and SAF logs. This resource group ensures that a
failed over SAF daemon can resume processing the SAF log from the point
of failure.
How Event Daemon Resumes Processing from Point of Failure
The Event Management daemon keeps track of actions that are in the middle
of processing when the CA_OPR_MONITOR_STATE environment variable is set
to Yes, which is the default.
■
When an incoming event matches a MSGRECORD policy, the list of
MSGACTIONs assigned to that policy is executed. If during this time a
failover occurs during this time or the power is turned off, the Event
Management daemon, during a start up, continues executing the rest of
the MSGACTION list for the MSGRECORD and the event it was processing
from when the failover occurred.
■
Only those events that were already retrieved by the Event Management
daemon from the CAICCI queue, and that match any of the
MSGRECORD\MSGACTION policies defined on the system are tracked.
■
These tracked events are stored in a state table in the CAOPRDMN.EXE
cache.
■
The frequency with which the state table is saved into a flat file is
determined by the value of the CA_OPR_MONITOR_INTERVAL
environmental variable. The state table contains information about the
event being processed, the matching MSGRECORD policy, and the last
MSGACTION executed.
Appendix B: Making Components Cluster Aware and Highly Available 381
How Event Management Becomes Cluster Aware
Environment Variables Event Management Uses When Highly Available
On each computer in the cluster, the following environment variables are
automatically set in the Configuration\Settings\Event Management folder so
that Event Management is highly available:
CAI_CONLOG
Specifies the shared location for the console logs files, for example g:\logs.
CA_OPR_DSB
Specifies the name of the .dsb file and the path to the shared location for
the console logs files, for example g:\logs\caopr.dsb.
CA_OPR_SAF_CONFIG
Specifies the value of the SAF Config file on the shared location where the
console logs files are, for example g:\logs\saf\saf.cfg.
CA_OPR_SAF_ROOT
Specifies the value of SAF directory on the shared location where the
console logs files are to be kept, for example, g:\logs\saf.
CA_OPR_MONITOR_STATE
Specifies whether the Event Management Daemon will keep track of
actions that it is in the middle of processing. The default is Yes.
CA_OPR_MONITOR_INTERVAL
Specifies the interval in seconds for saving the Event Management state
table into a flat file. The default is 30 seconds.
How You Configure Event Management in a Cluster Environment
In general, when a node name is required, use the Unicenter NSM cluster
virtual node (VNODE) rather than the physical node name of any of the
constituent computers. Using VNODE makes sure that Unicenter NSM services
are available.
In particular, use the VNODE when you are performing the following tasks:
■
Configuring Remote Administration Clients (RAC) to manage Unicenter
NSM on that cluster.
■
Forwarding events to a cluster node.
Events sent to Event Manager from applications that are not registered with
the cluster, or that are generated from the Windows Event Log by the Event
Management Log Reader, carry the physical node name rather than the cluster
VNODE. If those events are of interest, you should adjust any policy records
that filter on the incoming node name to include both the physical and virtual
node names.
382 Implementation Guide
How AEC Becomes Cluster Aware
How You Test Event Management in a Cluster Environment
After you install and configure Event Management in a clustered environment,
you may want to test that it is working correctly. Follow these steps:
1.
Start Event Management on your primary server and verify that the
Console Log is updated.
2.
Issue a command similar to the following command from a command
prompt on the primary server:
cawto Test from primary server
Verify that this message appears in the Console Log and has the name of
the cluster in the Node Name field.
3.
Force a failover, so that the backup server takes over the cluster
environment.
Verify that the same Console Log file is updated by the Event Management
daemon running on the secondary server.
4.
Issue a command similar to the following command from a command
prompt on the backup server:
cawto Test from backup server
Verify that this message appears in the Console Log and has the name of
the cluster in the Node Name field.
How AEC Becomes Cluster Aware
In a clustered environment, the AEC components are closely integrated with
HAS and are compliant with the highly available directives of the HAS service.
■
When AEC is installed in a clustered environment, the installation process
determines the location and setup of the installation environment, which
includes information about local and shared drives, failover and failback
events, and so on.
■
The Advanced Event Correlation configuration is added to the Unicenter
NSM resource group.
■
Only one instance of AEC will be running at any time within the cluster,
and will reside within the context of the Event Management daemon, which
may itself failover under the control of HAS. AEC cannot failover
independently of the Event Management daemon.
■
When the Event daemon (caoprdmn) is failed over by HAS, the AEC engine
automatically fails over because it runs within the context of that daemon
as a dll plugin.
Appendix B: Making Components Cluster Aware and Highly Available 383
How Alert Management Becomes Cluster Aware
■
AEC cached policy, preconfigured rules, configuration information, and
customizable tutor pane files are stored on the cluster's shared disk to
ensure the correlation engine and associated user interfaces can resume
seamlessly after failover.
■
At the point of failure, the state of any currently active AEC rules is lost
because it is maintained within memory.
AEC Resource Groups
Within the cluster, the following AEC resources are added to the Unicenter
NSM resource group and shared:
■
wvem\ace\ca-events.xml, which is a list of CA events that can be
expanded and modified to include user-defined events.
■
wvem\ace\temp\, which is a directory that contains all cached policy from
the MDB. The AEC engine is driven directly from this policy, therefore, it
must be shared so that the failover engine can to access it without running
ace_reload.
■
wvem\ace\html, which is a directory that contains html tutor-pane help
that can be customized by the user.
■
wvem\ace\config, which is a directory that contains preconfigured rules
that can be expanded or customized by the user.
■
Registry entries (shared directory/file structure on Linux), from which the
AEC engine accesses the list of deployed policy, diagnostic log settings,
and so on. Unlike the Event Management DSB concept, each policy is in a
separate cache file. The registry tracks which of these policies is to be
loaded into the engine. These registry settings are created and set using
the AEC user interfaces.
How Alert Management Becomes Cluster Aware
In a clustered environment, the Alert Management components are closely
integrated with HAS and are compliant with the highly available directives of
the HAS service.
■
When AEC is installed in a clustered environment, the installation process
determines the location and setup of the installation environment, which
includes information about local and shared drives, failover and failback
events, and so on.
■
All Unicenter NSM Alert Management configurations are added to the
Unicenter NSM resource group.
■
Only one instance of the CA-Unicenter Alert Management Service will be
running at any time within the cluster, which is controlled by HAS.
384 Implementation Guide
How Alert Management Becomes Cluster Aware
■
When failover occurs, the Alert Management Service resumes processing
from the point of failure. all alerts requested to be created by MRA and
AEC policy during failover are processed and added to the MDB when AMS
resumes on the failover system.
Alert Management Resource Group
In the cluster, the CA-Unicenter Alert Management Service is added to the
Unicenter NSM resource group and shared.
How You Test Alert Management in a Cluster Environment
After you install and configure Alert Management in a clustered environment,
you may want to test that it is working correctly. Follow these steps:
1.
Bring the CA-Unicenter Alert Management Service online on your primary
server.
2.
Use a command such as cawto to create one or more event records that
will trigger MRA or AEC policy to create alerts.
3.
Verify in the Unicenter MCC that the message alerts are created and the
alert queues are updated as expected.
4.
Force a failover to the backup server of the resource group under which
the CA-Unicenter Alert Management Service is installed.
5.
After failover, verify that the CA-Unicenter Alert Management Service is
online on the backup server.
6.
Create alerts using the same technique you used in step 2.
7.
Verify in the Unicenter MCC that the alerts are created and the alert
queues are updated as expected.
Appendix B: Making Components Cluster Aware and Highly Available 385
Cluster-Aware Agent Technology
Cluster-Aware Agent Technology
According to the underlying HAS clustering architecture, Unicenter NSM r11.x
cluster-aware agents are categorized as follows:
■
Agents monitoring individual resources from one or more resource groups.
For Unicenter NSM, these agents include:
–
Unicenter Windows System Agent (caiWinA3)
–
Unicenter UNIX/Linux System Agent (caiUxsA2)
–
Unicenter Linux/UNIX and Windows Log Agent (caiLogA2)
These agents are continuously running on all cluster nodes. However, only
one of these agents is actively monitoring a particular clustered resource,
which is the agent on the cluster node currently having ownership of the
shared resource, such as a file system or disk.
Managed objects are dynamically rebuilt in the Management Command
Center or 2D Map to visualize which agent is effectively monitoring a
clustered resource.
■
Agents monitoring an entire service or application exposed by a particular
cluster resource group. For Unicenter NSM, these agents include:
–
Unicenter Microsoft SQL Server Agent (caiSqlA2)
–
Unicenter Microsoft Exchange Agent
These agents need access to all resources used by the service/application.
Therefore, these agents fail over with the monitored service/application
and run only on the cluster node where the corresponding resource group
is active.
After a failover, this agent will no longer automatically be started with the
awservices start command. Instead, HAS will determine if the current node
is the active node and tell Agent Common Services to start the agent. This
also works in reverse, for example, if the current node becomes passive,
HAS tells Agent Common Services to stop the agent.
Managed objects are dynamically rebuilt in the WorldView repository in the
MDB to avoid false status propagation.
Important! Since Agent Technology does not support the automatic
replication of an agent's configuration between cluster nodes, you must apply
configuration changes on all cluster nodes, not just to the agent on the cluster
node currently servicing the monitored resource or resource group. This is
especially true for database agents to ensure that the agent that fails over to
the secondary other node continues with exactly the same configuration as its
predecessor.
386 Implementation Guide
Cluster-Aware Agent Technology
How Agent Technology Becomes Cluster Aware
In a clustered environment, the Agent Technology manager components are
closely integrated with HAS and are designed to be compliant with high
availability directives and requirements of the service.
■
The Agent Technology manager installation (DSM, and associated
manager-specific Agent Common Services) checks for a HAS configuration
then determines the appropriate "SharedPath." The Unicenter NSM store
and object store are configured on the "SharedPath" and the DSM runs in
the warm start mode.
■
The following registry key is updated to point to the shared drive:
KEY_LOCAL_MACHINE\\Software\\ComputerAssociates\\CA-Unicenter/TNG\\Agent
Technologies\\Distributed State Machine\\SharedPath
■
The Distributed State Machine (DSM) and resource groups for each Agent
Technology manager component (WV Gateway, DSM Monitor, SNMP, and
so on) are added to the Unicenter NSM resource group.
■
Only one instance of the DSM can be running at any time within the
cluster. The DSM requires that the manager components' directory
structure reside on the shared drive to support continued management
services regardless of the management node within the cluster.
■
Cluster-aware agents, when configured to monitor clustered resources, are
not part of the resource groups containing those resources. This is
enforced by the underlying HAS service and Agent Common Services
components, which require their directory structures to reside on a local
drive on each cluster node.
■
HAS does not require Unicenter NSM components to define cluster
resources for resource groups. Instead, when a component (such as an
agent) registers with HAS, HAS makes a mapping between the component
name and the resource group and notifies the component of events
occurring for the particular resource group (for example, the resource
group stopped and started). This approach simplifies the deployment of
agents in a cluster environment and supports the simultaneous use of both
cluster-aware and non-cluster-aware agents. Also, there is no need to
enhance policy or pollsets, or to make changes to the Agent Technology
infrastructure.
Appendix B: Making Components Cluster Aware and Highly Available 387
Cluster-Aware Agent Technology
Windows System Agent Highly Available Resource Groups
The Windows System Agent (caiWinA3) provides for the monitoring of the
health and critical performance parameters of the Windows operating system.
The caiWinA3 agent is packaged and distributed with Unicenter NSM.
The following resource groups monitored by caiWinA3 can be failed over and
continuously monitored:
■
Logical Volumes
■
Mounts
■
Processes
■
Services
How System Agents Work in a Cluster Environment
The use of HAS enables the system agent to adopt a platform independent,
common approach for operation within cluster solutions provided by major
Windows, UNIX, and Linux vendors.
When a system agent is installed in a cluster environment, the following
events occur:
■
The cluster name is reported in the System Summary Window of
AgentView.
■
The cluster type is reported for all monitored instances of a resource
eligible to be shared among the cluster nodes.
■
A dedicated passive aggregate status is used for failed-over resources
while preserving watcher settings.
■
A dedicated status icon is used to visualize a passive resource in
AgentView.
The agent interfaces closely with HAS to obtain information about the cluster
and any shared resources exposed. HAS supports and recognizes the agent's
resource as clustered resources. For these resource groups, the agent
maintains a cluster type attribute with each resource instance monitored. This
attribute is set to one of the below values to indicate the actual state of the
shared resource on the local cluster node:
■
Not-clustered—Resource is not clustered, that is, the node is not part of a
cluster or the resource is not shared with other nodes in the cluster; the
agent on this node actively monitors the resource.
■
Clustered-active—Local cluster node has resource ownership; the agent on
this node actively monitors the resource.
388 Implementation Guide
Cluster-Aware Agent Technology
■
Clustered-passive—Another node in the cluster owns the resource; the
agent on the local node does not actively monitor the resource until
ownership is transferred back (through failover or failback).
Note: To enable the agent to get the cluster type information for processes,
the name of the cluster resource group to which the monitored process
belongs must be specified when adding a watcher.
If during status evaluation a clustered-active resource is detected as passive,
the agent does the following:
■
The watcher's sub-states (individual metric states) are set to OK and info
traps are sent.
■
The watcher's aggregate status is set to passive and a passive status trap
is sent to the DSM to indicate that a failover/failback from the local cluster
node occurred for the resource.
■
Upon receipt of the passive status trap, the agent's DSM policy deletes the
corresponding managed object representing the watcher from both
NodeView and WorldView.
■
As long as the resource remains in the passive state (that is, not owned by
the local cluster node), no more status traps are sent.
During status evaluation, if a clustered-passive resource is detected as active,
the agent performs the following tasks:
■
An active status trap is sent to DSM to indicate that a failover/failback to
the local cluster node occurred for the resource.
■
Upon receipt of the active status trap, the agent's DSM policy recreates
the corresponding managed object representing the watcher in NodeView
and WorldView.
■
The watcher's sub-states (individual metric states) are evaluated as usual
and info traps are sent.
■
The watcher's aggregate status is evaluated as usual and a normal status
trap is sent.
■
As long as the resource remains in the active state (that is, owned by the
local cluster node), status and info traps are sent.
Appendix B: Making Components Cluster Aware and Highly Available 389
Cluster-Aware Agent Technology
UNIX/Linux System Agent Highly Available Resource Groups
The UNIX/Linux System Agent (caiUxsA2) monitors the health and critical
performance parameters of UNIX and Linux operating systems. The caiUxsA2
agent is packaged and distributed with Unicenter NSM.
The following resource groups monitored by caiUxsA2 can be failed over and
continuously monitored:
■
File Systems
■
Disks
■
Processes
UNIX/Linux and Windows Log Agent Highly Available Resource Groups
The Windows and UNIX/Linux Log Agent (caiLogA2) checks for the existence
or non-existence of user-specified files and monitors ASCII log files to detect
faults in applications running under the operating system. The caiLogA2 agent
is packaged and distributed with Unicenter NSM.
The Windows and UNIX/Linux Log Agent (caiLogA2) can be configured to
monitor the following resources:
■
Single log files
■
All files in a subdirectory, where the subdirectory name can contain
wildcards.
■
Windows Event Log
■
UNIX console
■
Files with ASCII control characters.
■
Single-line log files—Some applications write only one entry into a log file,
and a subsequent entry overwrites the existing one. The agent is able to
monitor these single-line log files.
390 Implementation Guide
Cluster-Aware Agent Technology
How the Log Agent Works in a Cluster Environment
HAS enables the log agent to adopt a platform independent, common
approach for operation within cluster solutions provided by major Windows,
UNIX, and Linux vendors.
When a log agent is installed in a cluster environment, the following events
occur:
■
A dedicated passive status is used for log file watchers monitoring log files
located on failed-over storage devices.
■
A dedicated status icon is used to visualize a passive log file watcher in
AgentView.
The agent interfaces closely with HAS to obtain information about the cluster
and any shared resources exposed. HAS supports and recognizes logical
volumes on Windows, disks on UNIX/Linux, and file systems on UNIX/Linux
(except IBM AIX) as clustered resources capable of hosting log files monitored
by the agent. From a local cluster node's perspective, these storage devices
can assume one the following states:
■
Not-clustered—Resource is not clustered, that is, the node is not part of a
cluster or the resource is not shared with other nodes in the cluster; the
agent on this node actively monitors log files located on the storage
device.
■
Clustered-active—Local cluster node has resource ownership; the agent on
this node actively monitors log files located on the storage device.
■
Clustered-passive—Another node in the cluster owns the resource; the
agent on the local node does not actively monitor log files located on the
storage device until ownership is transferred back (through failover or
failback).
If during log file evaluation a clustered-active storage device is detected as
passive, the agent performs the following tasks:
■
The status of every log watcher concerned is set to passive and a passive
status trap is sent to DSM to indicate that a failover/failback from the local
cluster node occurred for the storage device hosting the monitored log
files.
■
Upon receipt of the passive status trap, the agent's DSM policy deletes the
corresponding managed object representing the log file watcher from both
NodeView and WorldView.
■
As long as the storage device remains in the passive state (that is, not
owned by the local cluster node), no more status traps are sent for the log
watchers concerned.
Appendix B: Making Components Cluster Aware and Highly Available 391
Cluster-Aware Agent Technology
If during log file evaluation a clustered-passive storage device is detected as
active, the agent performs the following tasks:
■
For every log watcher concerned, an active status trap is sent to DSM to
indicate that a failover/failback to the local cluster node occurred for the
storage device hosting the monitored log files.
■
Upon receipt of the active status trap, the agent's DSM policy recreates
the corresponding managed object representing the log file watcher in
NodeView and WorldView.
■
The status of every log watcher concerned is evaluated as usual and a
normal status trap is sent.
■
As long as the storage device remains in the active state (that is, owned
by the local cluster node), status traps are sent for the log watchers
affected.
How to Set Up and Configure a System or Log Agent in a Cluster Environment
To provide full monitoring of the cluster, you must install the agent on each
cluster node.
We recommend that you enable Adaptive Configuration, which is supported
only by the Windows and UNIX/Linux System agents, to provide automatic
monitoring of critical cluster resources. Otherwise, manual user interaction is
required, which starts with the identification of salient resources and the
determination of their monitoring frequency, followed by the transformation of
those considerations into agent configurations and their deployment and
maintenance.
Depending on what is already installed on a cluster node, the setup
automatically installs or upgrades required CA Common Services components,
specifically Agent Technology and High Availability Service.
If you enabled Adaptive Configuration support, start the agent and the
Adaptive Configuration service with one of the following commands:
■
awservices start
■
aws_baseline start
If you did not enable Adaptive Configuration support, use one of the following
commands to start the agent:
■
awservices start
■
caiUxsA2 start (UNIX/Linux System agent)
■
caiWinA3 start (Windows System agent)
■
caiLogA2 start (Log agent)
392 Implementation Guide
Cluster-Aware Agent Technology
Microsoft SQL Server Agent Highly Available Resource Groups
The Unicenter Microsoft SQL Server Agent (caiSqlA2) provides status
monitoring and health-checks for fundamental areas of the Microsoft SQL
Server database environment. The Unicenter Microsoft SQL Server Agent
(caiSqlA2) is included with the Unicenter NSM Database Performance Monitor
Option (DPMO) 3.0 product suite. DPMO requires a working installation of
Agent Technology Common Services and is certified to run with Unicenter NSM
3.0 or later.
The Microsoft SQL Server Agent (caiSqlA2) can be configured to monitor the
following resources:
■
Database Server Configuration
■
System Resources
■
Server Resources
■
Locks
■
Services
■
File Systems
■
File Groups
■
Databases
■
Tables
■
Processes
■
Jobs
■
Publications
■
Subscriptions
■
Programmable Watchers
Due to its MibMUX enabled design, the caiSqlA2 agent also supports
active/active Microsoft SQL Server cluster environments.
How the Microsoft SQL Server Agent Works in a Cluster Environment
HAS enables the Microsoft SQL Server agent to effectively operate within a
Microsoft cluster environment.
When a Microsoft SQL Server agent is installed in a cluster environment, the
following events occur:
■
During configuration of the agent, the instance of the agent monitoring a
clustered instance of SQL Server is registered with HAS.
Appendix B: Making Components Cluster Aware and Highly Available 393
Cluster-Aware Agent Technology
■
If a failover or failback of the SQL Server instance occurs, the agent
instance is restarted by the Agent Technology Common Services
component on the cluster node that has assumed the workload for the SQL
Server instance. The Agent Technology Common Services component also
registers with HAS to receive notifications for caiSqlA2 start and stop
requests.
■
If HAS detects a failover or failback of an SQL Server instance, the Agent
Technology Common Services sends failover traps to the DSM computer to
report the start or stop of the affected agent instances.
–
Upon receipt of these traps, the standard DSM policy removes the
managed object representing the agent instance on the passive node
in NodeView and WorldView.
–
The managed object representing the agent instance on the active
node is recreated by initiating a rediscovery of the agent.
How to Set Up and Configure the Microsoft SQL Server Agent in a Cluster Environment
When the Microsoft SQL Server Agent is installed in an MSCS (Microsoft
Cluster Service) environment that exposes one or more clustered instances of
Microsoft SQL Server, you must install and configure agent instance on each
node in the cluster.
■
The Microsoft SQL Server instances to be monitored by the agent must be
running (online). Since the setup (and the caiSqlA2Cnf.exe configuration
program) uses a server's virtual network name, the respective SQL Server
resource group does not need to be moved between the cluster nodes
during installation or configuration of the agent instance.
■
When configuring an agent instance to use Windows Authentication with a
clustered instance of Microsoft SQL Server, the setup (or the
caiSqlA2Cnf.exe configuration program) must be running under the cluster
domain account.
■
The Agent Technology service must be running under the same account to
enable the agent instance to connect to SQL Server using Windows
Authentication.
Important! Unless you experience problems with Agent Technology or HAS
automatically starting the agent on the active node, do not explicitly start or
stop the agent on any cluster node.
394 Implementation Guide
Appendix C: CCS Linux/UNIX Reference
This section contains the following topics:
CCS Linux/UNIX Reference Introduction (see page 395)
PIF Response Files (see page 395)
Parameter Usage in PIF (see page 396)
PIF Response Files and Parameters (see page 396)
PIF Response Files Creation (see page 396)
Response File Considerations (see page 397)
CCS Linux/UNIX Reference Introduction
This appendix is a reference for all CCS r11 components that are selectable
and configurable by the product using them. It also lists those parameters that
are configurable along with their default values. You can use these parameters
to populate the PIF Response files for unattended installation.
Response files are a feature of the PIF installer to enable unattended
installations. Response files are used to customize the product or CCS
installation if the default values do not fit into a specific installation
environment.
PIF Response Files
PIF response files are plain text files that contain “parameter= value” pairs
that define settings used during the installation, for example:
CCSINST_EVTAGT=1
Appendix C: CCS Linux/UNIX Reference 395
Parameter Usage in PIF
Parameter Usage in PIF
To better understand the usage of response files, you need to know how
parameters are defined and handled in PIF. All PIF parameters are defined in
the default section of the PIF packages and they are always created with
default values.
These default values can be defined as either static or dynamic values, for
example:
#parameter:
$CASHCOMP , /opt/CA/SC
is a static default value, and
#parameter: $EMSERVER , ’uname -n’
is a dynamic default value.
Using dynamic default values for parameters makes it easy to deploy packages
to multiple systems since the values are evaluated on the target system. This
happens automatically for the parameters that are defined as dynamic
parameters. You do not need to provide parameters using a response file if
they are defined as dynamic parameters.
PIF Response Files and Parameters
Sometimes it is necessary to define certain parameters for the installation that
cannot be handled through dynamic defaults, for example, the customer’s
Unicenter MDB server name. In this case, you can use a response file to pass
these parameters to the PIF package.
PIF Response Files Creation
You can create a response file with a text editor. An example of a response file
follows:
CASHCOMP=/opt/CA/mynsm
csutils=1
CCSINST_EVTAGT=1
You can use this response file with your installation. CCS install results in a
default Event Agent installation (CCSINST_EVTAGT), indicating that the EULA
has been agreed to (csutils=1), that CCS will be installed into
/opt/CA/mynsm/ccs (CASHCOMP is set to /opt/CA/mynsm, and the ccs
directory will be created below that). Use the parameters described in
Response File Considerations to set the specifics for each CCS component.
396 Implementation Guide
Response File Considerations
Response File Considerations
Consider the following in relation to the response file in PIF:
■
You do not have to provide all the parameters in the response file. It is
intended as an overlay to the defaults from the packages, so specify only
the parameters you want to overwrite.
■
Generate a response file using the command setupNSM -a, then save it
and modify it for future deployments. Do not attempt to use “lsm -a” to
create a response file.
■
You can use environment variables in the response file, such as
(my_host=`hostname -i`) to enable dynamic settings that are evaluated
on the target system.
Appendix C: CCS Linux/UNIX Reference 397
Appendix D: Database Maintenance
Quick Reference
This section contains the following topics:
Database Maintenance Quick Reference Introduction (see page 399)
Database Backup (see page 400)
Query Optimization (Ingres Only) (see page 401)
System Catalog Optimization (Ingres Only) (see page 401)
User-Defined Tables Optimization (Ingres Only) (see page 402)
Database Recovery (see page 402)
Database Maintenance Quick Reference Introduction
The maintenance tasks and administration efforts for the MDB may be
unfamiliar to users accustomed to working with other databases used with
previous releases. This quick reference section introduces the routine
maintenance tasks needed to keep your MDB performing consistently and
provide the necessary protection for your data investments.
What follows are the commands we recommend using to keep your MDB
running smoothly, as well as a brief description of when and how often to use
each command. The following guidelines, although not comprehensive, are our
recommended best practices and will ensure a smooth and effective
experience.
Note: If you need to handle more complex issues such as special purpose
commands and customization, or if you need more detailed information on any
of the tasks that follow, see the full Ingres or Microsoft SQL Server
documentation.
Additional guidelines for planning, configuring, maintaining and tuning your
Unicenter NSM MDB can be found on the Implementation CD (go to Technical
Support at http://ca.com/support).
Information about PostgreSQL databases which are used for Event
Management on UNIX/Linux are available at http://www.postgresql.org/docs.
Appendix D: Database Maintenance Quick Reference 399
Database Backup
Database Backup
The following commands will back up your database.
Microsoft SQL Server Databases
All processes accessing the MDB must be shut down. You can enter all queries
using the Microsoft SQL Server Query Analyzer.
To determine which processes are running, execute the following query:
USE master
SELECT distinct hostname, program_name, hostprocess
FROM sysprocesses
WHERE dbid = (SELECT dbid
FROM sysdatabases
WHERE name = 'mdb')
To back up without a logical backup device, execute the following query:
USE master
BACKUP DATABASE mdb
TO DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\mdb_1.dat'
To back up with a logical backup device, execute the following queries:
1.
Create a logical device, if one does not already exist, using the following
query:
USE master
EXEC sp_addumpdevice 'disk', 'mdb_1', 'C:\Program Files\Microsoft SQL
Server\MSSQL\BACKUP\mdb_1.dat'
2.
Back up to the logical device using the following query:
USE master
BACKUP DATABASE mdb TO mdb_1
To remove a logical device (optional), execute the following query:
USE master
EXEC sp_dropdevice 'mdb_1'
Note: Update the backup path according to your environment.
400 Implementation Guide
Query Optimization (Ingres Only)
Ingres Databases
ckpdb -d -umdbadmin mdb
This command runs a checkpoint on your database to back up the data.
We recommend you run this command once a day.
This command saves only a single generation of the MDB. For your
convenience, a script is provided to handle multiple generation in the r11
Implementation CD on SupportConnect.
You must be an Ingres Administrator to perform this command.
Note: For more information about checkpoints, database backup, or the
ckpdb command, see the Ingres Command Reference Guide.
Query Optimization (Ingres Only)
Use the optimizedb command to generate statistics that optimize query
processing strategies. To optimize query processing, enter the command in the
following format:
optimizedb -zk -zw -umdbadmin mdb
We recommend that you run this command once a day to keep the database
operating at peak efficiency.
You must be an Ingres Administrator to perform this command.
Note: For more detailed information on query optimization or the optimizedb
command, see the Ingres Command Reference Guide.
System Catalog Optimization (Ingres Only)
To modify system catalogs of a database to predetermined storage structures,
enter the following command:
sysmod +w mdb
The sysmod command reorganizes the system areas within the Ingres MDB
itself to conform system catalogs to specific storage structures. Because it
reorganizes system areas within the MDB, you must run this command with no
other tasks connected to the database as it requires exclusive control.
We recommend running this command only very infrequently (perhaps once
every three months), and only when there is evidence that the system
catalogs require reorganization.
Appendix D: Database Maintenance Quick Reference 401
User-Defined Tables Optimization (Ingres Only)
You must be an Ingres Administrator to perform this command
Note: For more detailed information on system catalog optimization or the
sysmod command, see the Ingres Command Reference Guide.
User-Defined Tables Optimization (Ingres Only)
To consolidate and optimize user-defined tables within the MDB, enter the
following command:
usermod -online -umdbadmin mdb
The usermod command modifies the user-defined tables of a database to their
currently defined storage structures.
Because of its time-consuming nature, run this command infrequently,
preferably during off-peak periods. We recommend running this command
once every three months.
You must be an Ingres Administrator to perform this command.
Note: For more detailed information on user-defined tables and a more
complete description of the usermod command, see the Ingres Command
Reference Guide.
Database Recovery
You should back up your database regularly so that you can recover your data
if necessary. Databases or tables can be damaged accidentally by hardware
failure or human error.
Microsoft SQL Server Databases
All processes accessing the MDB must be shutdown. You can enter all queries
using the Microsoft SQL Server Query Analyzer.
To determine which processes are running, execute the following query:
USE master
SELECT distinct hostname, program_name, hostprocess
FROM sysprocesses
WHERE dbid = (SELECT dbid
FROM sysdatabases
WHERE name = 'mdb')
402 Implementation Guide
Database Recovery
To restore without a logical backup device, execute the following query:
USE master
RESTORE DATABASE mdb
FROM DISK = 'C:\Program Files\Microsoft SQL
Server\MSSQL\BACKUP\mdb_1.dat'
To restore with a logical backup device, execute the following queries:
1.
Create a logical device, if one does not already exist, using the following
query:
USE master
EXEC sp_addumpdevice 'disk', 'mdb_1', 'C:\Program Files\Microsoft SQL
Server\MSSQL\BACKUP\mdb_1.dat'
2.
Restore from the logical device using the following query:
USE master
RESTORE DATABASE mdb FROM mdb_1
To remove a logical device (optional), execute the following query:
USE master
EXEC sp_dropdevice 'mdb_1'
Note: Update the backup path according to your environment.
Ingres Databases
rollforwarddb -v -umdbadmin mdb
Run this command only as absolutely required.
You must be an Ingres Administrator to perform this command.
This command requires exclusive use of the database to succeed, meaning
you must terminate all connections to the database before running. If this
command should fail because the database cannot obtain the lock, the
situation can usually be resolved by terminating Ingres by issuing the
following:
ingstop -force
followed by:
ingstart
Notes: For more detailed information on database recovery and the
rollforwarddb command, see the Ingres Command Reference Guide.
Once a database is recovered successfully, we recommend that you take a
checkpoint (see the Database Backup topic) to preserve the recovered
state.
Appendix D: Database Maintenance Quick Reference 403
Index
2
2D maps • 262, 264
A
about • 252, 254
access Unicenter NSM web applications • 226
Active Directory Monitoring • 18
active/active configuration • 371
active/passive configuration • 371
Adaptive Configuration • 20, 392
Administrative Interface (AI) • 53
installation • 173
Advanced Event Correlation • 20, 47, 283
Interactive Development Environment (IDE)
• 284
agent PROC's • 161
Agent Technology • 17, 18, 51, 283
controlling the agents • 222
copying the MIB to • 160
loading the MIB • 160
update awservices • 161
update PROCs • 161
agentless monitoring • 271
agents
and Agent Technology • 51
configuration sets • 222
controlling • 222
initializing • 83
migrating configuration sets • 162
Unicenter NSM agents • 72
Alert Management System • 19
Alert manager • 48, 73
all agents • 386
and Advanced Event Correlation • 383
and Agent Technology • 386
and Event Management • 380
architecture • 373
architecture design
hardware and software • 63
network considerations • 64
operational standards • 65
Association Browser • 268
authentication and access control • 241
automated business views • 281
aws_baseline • 392
aws_baseline command • 392
awservices • 392
awservices command • 392
B
best practices, RSII • 250
business needs, determining • 67
Business Process View Management (BPVM) •
25
C
CA High Availability Service See also HAS •
369
CA LMP • 83
CA SYSVIEW Server • 85
CICS Logger task • 87
MVSDATA task • 86, 222
reassemble and link • 86
starting • 222
CA Web Server • 226
configure with SSL • 230
security • 241
CAICCI • 195
daemons • 195
remote daemons at startup • 218
remote statement • 199
troubleshooting • 217
CAICCI configuration
HP NonStop • 204
mainframe • 214
OpenVMS • 206
UNIX • 202
Windows • 200
caiLogA2 • 392
caiLogA2 command • 392
CAIRIM • 82
caiUsxA2 command • 392
caiUxsA2 • 392
caiWinA3 • 392
caiWinA3 command • 392
CCI
CAICCI • 195
ccii utility • 217
ccir utility • 218
Index 405
ccis utility • 218
CCS UNIX/Linux Reference • 395
CFGCONV utility • 162
Cisco • 24
cluster service layer • 373
cluster service layer (CSL) • 373
cluster type attributes • 388
cluster-aware • 374
cluster-awareness • 388
clustered resource states • 391
Common Discovery • 60
configuration • 371
configuration choices • 111
configuration set file default location • 162
configuration sets
location for each agent • 222
migrating • 162
configuring thresholds and poll times • 221
contacting technical support • iv
Continuous Discovery manager • 46, 60
converting to PDS format • 157
critical state • 268
cross platform scheduling • 49
CSL (cluster service layer) • 373
customer support, contacting • iv
D
dashboards • 262
Data Scoping • 26
access to the MDB • 193
for Linux and UNIX • 193
for Windows • 194
rules that protect the data • 192
Data Scoping Rule Generator • 194
create Data Scoping rules • 194
database selection for Windows • 111
date and time controls • 47
demilitarized zone (DMZ) • 307, 326
deploy the install image • 256
description • 369
DIA Grid • 297
discovery • 60, 175
Discovery Wizard • 261
Distributed Intelligence Architecture • 291
configure • 319
configure for firewalls • 321
encryption mechanism • 319, 335
HACMP Clusters • 326
NAT settings • 324
406 Implementation Guide
troubleshooting • 302
Distributed State Machine (DSM) • 17, 74
DSM manager • 46
pre-installation • 80, 81
role, Agent Technology • 51
DNA remote install • 294
documentation • 26
Dynamic Node Administrator (DNA) • 294
E
environment variables • 382
Event Console • 20
event daemon, resuming processing • 381
Event Manager • 47, 73
F
failback operation • 370
failover operation • 370
FTP files to the mainframe • 156
G
GUIs • 43
H
HAS cluster-aware components • 374
HAS daemon • 373
historical information • 268
how the reduced-size install image works • 250
I
importance • 267
Ingres
Ingres configuration dialog • 111
install image
deploy • 256
register with Unicenter Software Delivery •
254
response files for • 252
installation
AI installation • 173
CA Common Discovery • 135
Linux/UNIX considerations • 81
Pocket PC • 88, 164, 221
SPECTRUM integration kit • 174
installation methods • 69
unattended • 70
UNIX/Linux • 70
Windows • 69
installing Monitoring for z/OS • 156
installation library, download • 159
on the mainframe • 157
installing security • 105
installing Unicenter NSM • 111
deploying to hosts • 145
on Linux or UNIX • 119
installing Unicenter NSM Systems Performance
• 146
introduction • 369
J
Java Runtime Environment (JRE) • 232
JCL • 156
start and stop agent address spaces • 161
JDBC • 228
job agent • 49
Job manager • 49, 73
K
in Agent Technology • 51
managers • 45
MemoryRealm • 241
Microsoft SQL Server agent • 393
Microsoft SQL Server agent cluster-awareness
• 393
Microsoft SQL Server agent configuration • 394
Microsoft SQL Server agent resource groups •
393
migrating component data • 108
migration instructions • 26
migration, configuration sets • 162
MOM • 23
Monitoring for z/OS • 82
disabling previous release • 86
install on the mainframe • 157
monitoring technology • 54
comparison of products • 54
information monitored • 55
multiple NICs • 327
keytool utility • 232
knowledge base
Master Knowledge Base • 311
zone and grid rules • 311
N
L
O
licensing information • 82
Linux/UNIX pre-installation • 79
LMP (License Management Program)See CA
LMP • 83
LOCAL statement
format • 196
sample configurations • 199
log agent • 391
log agent cluster-awareness • 391
log agent setup • 392
log file default location • 162
OMVS segment • 162
online books • 22
OpenVMS
basic CAICCI configuration • 199
overview • 369, 380, 383, 387
M
Mainframe
CAICCI configuration • 214
Managed Object • 266
Managed Server • 72
Management Command Center • 17, 77
Business Process Views • 281
Data Scoping rules • 194
focused visualization • 279
Management Database (MDB) • 22, 44, 77
accessing the MDB • 228
Notification Services • 19
NSM Security Realm • 241
P
Performance Data Grid (PDG) • 59
PIF response files • 395
Pocket PC
configuring • 221
implementing Unicenter • 88
installing • 164
uninstalling • 189
polling intervals • 80
portal-based visualization • 271
PostgreSQL • 15, 102, 119, 399
prerequisites • 250
PROCs
security • 162
updating • 161
product licensing authorization • 82
protection against unauthorized access • 26
Index 407
proxies • 51
R
readme file • 27
register with Unicenter Software Delivery
about • 254
REMOTE statement • 196, 199
advanced sample • 199
basic sample • 199
Repository Bridge, uses • 44
resource groups • 371, 381, 384
response files
create for Systems Performance • 253
default files • 252
plan for • 252
response files and registration • 142
restricting message access • 47
S
setupNSM • 70, 119
SETVARS member • 159
smo • 159
SMP/E installation • 160
SPECTRUM integration kit installation • 174
SSL for Tomcat • 232
starting the agent address space • 223
statistics data • 268
status • 267
support, contacting • iv
supported vendor clusters • 369
T
TCP/IP
communications port number • 221
technical support, contacting • iv
testing • 383
Tomcat Administration • 226
Tomcat Manager • 226
Tomcat security • 241
Tomcat server • 263
Topology • 262, 265
Trap Daemon • 20
TrapManager • 20
install TrapManager • 170
troubleshooting • 257
U
Unicenter Advanced Network Management • 15
408 Implementation Guide
Unicenter Advanced Systems Management •
15
Unicenter Browser Interface (UBI) • 21
Unicenter CA-SYSVIEW Server • 222
Unicenter Cisco Integration • 24
install Unicenter Cisco Integration • 169
uninstall • 190
Unicenter Configuration Management • 21
Unicenter Controller • 268
Unicenter for Pocket PC • 22, 88, 164, 221
Unicenter Job Management Option • 15
Unicenter Management Command Center
(Unicenter MCC) • 262
Unicenter Management for Microsoft
Operations Manager • 23
install MOM Management • 166
MOM Discovery • 166, 224
set-up • 89
Unicenter Management Portal • 21, 271
configure a workplace • 275
event view portlet • 276
install Management Portal • 163
Unicenter NSM
Monitoring Manager • 73
overview • 15
Product Explorer • 69
Reporting and Configuring Manager • 76
security • 105
Visualization Server • 77
Web Reporting Server • 229
Unicenter Remote Monitoring • 24, 53, 76, 92,
271
configure • 273
install • 172
Unicenter Software Delivery • 71, 141
registration • 144
Unicenter Software Delivery, register with •
254
Unicenter Software Development Kit (SDK) •
21
Unicenter Systems Performance • 18, 59, 75
pre-install tasks • 87
Unicenter WMI agent • 26
configuration • 221
uninstall Unicenter NSM • 187
UNIX CAICCI configuration • 202
UNIX/Linux and Windows log agent resource
groups • 390
UNIX/Linux system agent resource groups •
390
update agent PROCs • 161
upgrade instructions • 26
upgrade Systems Performance agents • 250
user identifier • 162
V
visualization • 43
W
wait warning message • 106
Web Reports and Dashboards • 21
weight value • 266
weighted severity, using • 279
Windows
CAICCI configuration • 200
pre-installation • 79
Windows system agent • 388
Windows system agent cluster-awareness •
388
WorldView manager • 46, 74
Index 409
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement