Integrating IBM Director with Enterprise

Transcription

Front cover
Integrating IBM Director
with Enterprise
Management Solutions
Covers five of the major enterprise and
workgroup managers
Describes integration with IBM
^ xSeries hardware
Provides real-world examples
of event forwarding
David Watts
Paul Engel
Roberta Marchini
Sigrun Pfeiffer
ibm.com/redbooks
International Technical Support Organization
Integrating IBM Director with Enterprise
July 2001
SG24-5388-01
Take Note! Before using this information and the product it supports, be sure to read the
general information in “Special notices” on page 247.
Second Edition (July 2001)
This edition applies to:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
IBM Director 2.2
Tivoli Management Environment 3.6.1
Microsoft SMS 2.0
HP OpenView Network Node Manager 6.1
CA Unicenter TNG Framework 2.2
Tivoli NetView 6.0.1
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. HZ8 Building 662
P.O. Box 12195
Research Triangle Park, NC 27709-2195
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1999, 2001. All rights reserved.
Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject to
restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Special notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
IBM trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Upward integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Why use upward integration? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Concerns when implementing upward integration . . . . . . . . . . . . . . . 5
1.1.3 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 IBM Director architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Integrating into the enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Method 1: Via SNMP from the client . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Method 2: Via the enterprise management agent on the client. . . . . 14
2.2.3 Method 3: Via the IBM Director server . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 SNMP security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Security considerations with enterprise management agents . . . . . . 19
2.3.3 Security suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Should a Director server be used? . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Where to establish the integration. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.3 How to establish the connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 3. Installing IBM Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Starting the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Installing UM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Installing IBM Director Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Installing IBM Director Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Installing UM Server Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.1 ServeRAID hard disk failure through Director server . . . . . . . . . . . . 47
© Copyright IBM Corp. 2001
iii
3.6.2 Advanced System Management fan failure through UMS client . . . . 51
3.6.3 Remote Supervisor Adapter system shutdown . . . . . . . . . . . . . . . . . 54
3.6.4 APC UPS loss of AC power through PowerChute plus. . . . . . . . . . . 58
3.7 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.7.1 Discussion forums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7.2 Sending e-mail to technical support . . . . . . . . . . . . . . . . . . . . . . . . . 60
Chapter 4. Tivoli Management Environment. . . . . . . . . . . . . . . . . . . . . . . . 65
4.1 Introduction to Tivoli three-tier architecture. . . . . . . . . . . . . . . . . . . . . 66
4.2 Planning for UM Services Plus for Tivoli . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.1 Alert forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.2 Distributed Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.3 Client software distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.4 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2.5 Wake on LAN and other tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3 Installing UM Services Plus for Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4 Setting up alert forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.1 Setting up SNMP alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.2 Configuring IBM Director to generate Tivoli alerts . . . . . . . . . . . . . . 89
4.4.3 Setting Up Tivoli API Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.4.4 Setting Up the Windows Logfile Adapter. . . . . . . . . . . . . . . . . . . . . . 96
4.5 Setting up Distributed Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.6 Setting up Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.1 Preparing the distribution package . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.2 Distributing the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.6.3 Removing the source files from the target machine . . . . . . . . . . . . 111
4.7 Setting up Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.1 Executing a software inventory scan. . . . . . . . . . . . . . . . . . . . . . . . 114
4.7.2 Populating the UM Subscribers Profile Manager . . . . . . . . . . . . . . 118
4.7.3 Executing a hardware inventory scan . . . . . . . . . . . . . . . . . . . . . . . 120
4.8 Setting up Wake on LAN and other tasks . . . . . . . . . . . . . . . . . . . . . 124
4.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.9.1 ServeRAID hard disk failure through Director server . . . . . . . . . . . 125
4.9.2 Advanced System Management fan failure through UMS client . . . 126
4.9.3 Remote Supervisor Adapter system shutdown . . . . . . . . . . . . . . . . 128
4.9.4 APC UPS loss of AC power through PowerChute plus. . . . . . . . . . 130
4.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Chapter 5. Microsoft SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.3 Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.4 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
iv
Integrating IBM Director with Enterprise Management Solutions
5.5 Alerting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.5.1 UMS alerts going to SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.5.2 SMS Events going to Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.6 Software distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Chapter 6. HP OpenView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.2 UMS integration using SNMP trap forwarding. . . . . . . . . . . . . . . . . . 150
6.3 Integration using the upward integration module . . . . . . . . . . . . . . . 152
6.3.1 Installation and settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.3.2 Additional functionality through the integration . . . . . . . . . . . . . . . . 155
6.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Chapter 7. CA Unicenter TNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.2 Installing the Unicenter UIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.3 Reclassify UMS machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
7.4 Alert forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.5 Launching UMS from TNG maps . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
7.6 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
7.7 UMS client distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
7.8.1 ServeRAID hard disk failure through Director Server . . . . . . . . . . . 192
7.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Chapter 8. Tivoli NetView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8.1 UMS Integration using SNMP trap forwarding . . . . . . . . . . . . . . . . . 206
8.2 Integration using the Upward Integration Module . . . . . . . . . . . . . . . 209
8.2.1 Installation and settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
8.2.2 Additional functionality through the integration . . . . . . . . . . . . . . . . 212
8.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Contents
v
8.3.2 Advanced Systems Management fan failure through UMS client . . 223
Appendix A. Remote Supervisor Adapter MIB file . . . . . . . . . . . . . . . . . . 233
Appendix B. Output of ovobjprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Related publications . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other resources . . . . . . . . . . . . . . . . . . . . . . . .
Referenced Web sites . . . . . . . . . . . . . . . . . . . . . .
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . .
IBM Redbooks collections . . . . . . . . . . . . . . . . .
......
......
......
......
......
......
.......
.......
.......
.......
.......
.......
......
......
......
......
......
......
.
.
.
.
.
.
245
245
245
246
246
246
Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
vi
Preface
With the introduction of the new range of IBM ^ systems, it has become
increasingly important to integrate all the servers a customer has. One aspect of
that integration is the consolidation of systems management.
Many customers already have an enterprise management system to manage all
of their computer systems using centralized alerting, problem determination,
inventory, and the like. However, those enterprise managers typically do not
provide the hardware-level information available from systems such as the
xSeries family, so tools such as IBM Director have been developed to coordinate
that information and pass it onto the enterprise managers.
This redbook describes how to integrate IBM Director and xSeries hardware with
the following enterprise and workgroup managers:
򐂰
򐂰
򐂰
򐂰
򐂰
Tivoli Management Environment
Microsoft SMS
HP OpenView
CA Unicenter TNG
Tivoli NetView
By implementing this integration, customers will be able to receive alerts and
other information from the xSeries hardware and make it available to
administrators along with the rest of the management information from their other
platforms.
A companion Webcast, produced in conjunction with IBM PC Institute, can be
accessed via:
http://www.pc.ibm.com/training/expert_series.html
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Raleigh Center.
David Watts is a Senior IT Specialist at the IBM ITSO Center in Raleigh. He
manages residencies and produces redbooks on hardware and software
topics related to IBM ^ xSeries systems and associated client
platforms. He has authored over 20 redbooks; his most recent books include
vii
Tuning Netfinity Servers for Performance and Migrating from Netfinity Manager to
Netfinity Director. He has a Bachelor of Engineering degree from the University
of Queensland (Australia) and has worked for IBM for over 12 years. He is an
IBM Professional Server Specialist and an IBM Certified IT Specialist.
Paul Engel is a Senior IBM ^ xSeries Systems Engineer in the United
States. He has 18 years of experience in various computer fields including
software development, systems design and implementation, and computer
training. He holds certifications from Microsoft as a systems engineer for
Windows 2000 and as a trainer, as well as being a Certified Systems Expert from
IBM. His areas of expertise include systems management, overall systems
performance, and training. He has written extensively on real world
implementation of computer systems.
Roberta Marchini is an IBM ^ xSeries Systems Engineer in Italy. She
holds a degree in Electronic Engineering. She has four year’s experience in
computer science, first as a developer, then as a system engineer. She holds the
MCSE certification as well as being an IBM Professional Sever Expert. She’s
been working for IBM in the xSeries area for three years. Her main responsibility
is Systems Management as well as Citrix Metaframe projects. She has
implemented several environments with IBM Director, including integration into
Tivoli.
Sigrun Pfeiffer is an IBM ^ xSeries Systems Engineer in Germany. She
has been working for IBM for five years, and has three years of experience as a
pre-sales systems engineer for Netfinity and xSeries products. She holds a
degree in Business Administration with an emphasis on Computer Business
Data Processing from the Technische Fachhochschule Berlin. She is a
Professional Server Specialist and has expertise in Systems Management
including xSeries hardware, IBM Director, and general server hardware
validation and testing.
viii
The team (l-r): Sigrun, Roberta, Paul, David
Thanks to the following people from IBM for their contributions to this project:
Sandra Andrews, PC Institute Technical Course Developer, Raleigh
Barbara Barker, IBM Director Technical Project Manager, Raleigh
Joe Bolan, System Management Development, Raleigh
Eric Chong, TCO Specialist, Canada
Craig Elliott, Advanced Technical Support, Dallas
Chris Finley, IBM Director Integration Test, Raleigh
Peter Glasmacher, IBM Global Services, Dortmund, Germany
Dan Hauser, IBM Director Integration Test, Raleigh
Stephen Hochstetler, ITSO Austin
Jake Kitchener, Systems Management Software Developer, Raleigh
Jim Kosek, IBM Director Integration Test, Raleigh
Morten Moeller, ITSO Austin
Curtis Scott, IBM Director Integration Test, Raleigh
Dean Skotidas, IBM Director Integration Test, Raleigh
Franco Valente, Systems Management Architect, IBM Global Services, Italy
Thanks also to Alberto Russomando, Customer Support Engineer for Prisma
Engineering S.r.l, a Computer Associates business partner in Italy.
Preface
ix
Special notice
This publication is intended to help customers integrate IBM ^ xSeries
systems and IBM Director into their existing enterprise management system. The
information in this publication is not intended as the specification of any
programming interfaces that are provided by IBM Director. See the
PUBLICATIONS section of the IBM Programming Announcement for IBM
Director for more information about what publications are considered to be
product documentation.
IBM trademarks
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
Alert on LAN
Asset ID
DB2
DB2 Universal Database
e (logo)®
HelpCenter
IBM ®
Netfinity
NetVista
Predictive Failure Analysis
Redbooks
Redbooks Logo
ServeRAID
Tivoli
TME
NetView
Comments welcome
Your comments are important to us!
We want our IBM Redbooks to be as helpful as possible. Send us your
comments about this or other Redbooks in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an Internet note to:
[email protected]
򐂰 Mail your comments to the address on page ii.
x
1
Chapter 1.
Introduction
What do we mean by upward integration? Why would you use upward
integration? Like many areas of computer science, systems management is
made up of multiple products or systems that need to communicate. Let’s take a
look at these questions, and begin setting the stage for the rest of this book.
In this chapter we discuss the concepts behind upward integration, define many
of the terms used to describe systems management products, and look at some
of the reasons upward integration is used in different environments.
1
1.1 Upward integration
Many larger environments already use, or are planning for, workgroup or
enterprise management systems. Figure 1-1 shows the positioning of different
classes of systems management products:
Positioning the systems management products
Cost
Enterprise Managers
Workgroup Managers
Element Managers
Hardware
Operating
Systems
Applications
Network
Figure 1-1 Positioning systems management products
The three classes of products are:
򐂰 Element managers
Products that are designed to manage and monitor specific parts or elements
of a computer environment.
While most commonly used to manage hardware, there are some
applications that can monitor themselves and could therefore be considered
element managers. These systems usually provide little to moderate
monitoring of operating systems and applications, and do not include
software distribution and maintenance. IBM Director, Compaq Insight
Manager, and APC PowerChute are considered hardware element
managers.
2
򐂰 Workgroup managers
These are designed for the small to mid-sized usually Intel based
environments. These products are not hardware specific and usually
communicate with the operating system to monitor any hardware or
applications running on the system. These products usually include some
form of software distribution and maintenance. Microsoft Systems
Management Server (SMS) and Intel LANDesk are considered workgroup
managers.
򐂰 Enterprise managers
Designed for large corporate or government environments, enterprise
managers, like workgroup managers, are vendor independent, although they
usually allow plug-ins for vendor specific devices. Tivoli TME and CA
Unicenter are considered enterprise managers.
As you can see, element managers focus primarily on managing hardware but
lack many of the tools to manage software or large enterprises. Workgroup
managers can manage operating systems and whatever hardware information is
presented through the operating system, but cannot handle WAN or network
management as a whole. Enterprise managers are able to manage almost the
full range of the computer environment including operating systems,
applications, and network infrastructure.
Unfortunately, because enterprise managers and workgroup managers have to
run on multiple vendors' hardware, they are unable to get the hardware detail
available in element managers. Therein lies the need for upward integration.
Generally speaking, upward integration is the methods, processes and
procedures that allow a lower level systems management product, such as an
element manager, to work with a higher-level manager such as a workgroup or
enterprise manager. Upward integration will usually:
򐂰 Use standard protocols, (for example, SNMP, DMI, or CIM)
򐂰 Provide some level of integration between the element manager client and the
upstream manager client
򐂰 Offer some additional functionality on the upstream manager server
1.1.1 Why use upward integration?
There are basically two reasons why you would want to use upward integration in
your environment:
򐂰 You have made a strategic investment in your enterprise management system
and want to amortize the cost over the new systems while still getting the
additional features available in IBM Director.
Chapter 1. Introduction
3
򐂰 You have a regional, political, or skills need to use an element manager, but
still want data to flow up to the enterprise.
Let’s expand on these in more detail:
򐂰 Highly standardized management environment
One of the most common reasons to use upward integration is the need to fit
into a standardized management environment. Maybe your company has
standardized on Tivoli TME, Microsoft SMS, or another management system.
Because there has probably been a fairly large investment in the installation
and configuration of this product, it is often required that all systems
participate in it.
Also, if the enterprise management system is already configured to handle all
the asset management, problem determination, and alerting functions you
need, why recreate them on an element manager and have to maintain them
on multiple platforms? In this environment it makes sense to tightly integrate
the element manager with the existing enterprise system.
򐂰 Enterprise reporting
Perhaps your group is not required to run the enterprise management tools,
but does have a need to report certain types of information to it. For example,
the enterprise management team is not responsible for the day-to-day
operation of your systems, and your team has decided to use the
management tools from the hardware vendor to manage your systems.
If your enterprise group needs be kept informed of asset and alert
information, this can be done through “loose” upward integration, where
information is passed up to the enterprise management system but the
enterprise is not in direct control of the client.
򐂰 Taking advantage of enterprise tools
Another classic example of the need for upward integration is the desire to
take advantage of tools available in the enterprise management system. If the
enterprise management system has links to your helpdesk application, it may
be beneficial to use that integration rather than creating your own. The same
holds true for reporting and alerting systems.
4
1.1.2 Concerns when implementing upward integration
There are times when you want to limit the use of upward integration.
򐂰 Monitor conflicts
One of the most common reasons to limit upward integration is monitor
conflicts. Many systems management functions exist in most or all systems
management products. It is important to decide, for each function, which
product works best in your environment and use it for that function
For example, most systems management products can monitor the amount of
free disk space available. You should choose one product to perform that
function in your implementation, thus minimize overhead on the clients and
confusion amongst the management systems as they decide who is going to
notify you that you are out of disk space. This is especially important for
remote control functions because installing multiple products almost always
leads to serious conflicts and even erratic behavior of the client.
򐂰 Competing management systems
Depending on how you implement upward integration, you can have more
than one system that is responsible for managing a resource or performing
some other function. While running an element manager that reports to an
enterprise manager as in “Enterprise reporting” on page 4 may be beneficial,
it can also cause problems such as confusion about who is responsible for
problem resolution, or conflicting standards and requirements.
1.1.3 Conclusions
There are probably as many reasons to include upward integration in a systems
management solution as there are enterprise management implementations. As
with any computer system, there are trade-offs to be considered, including cost,
availability, usability, and others.
Ultimately, any systems management solution needs to be tailored to the
environment and needs of the user community. Whether or not to use upward
integration, and, if so, where and how to establish that integration are not
questions that can be answered with a simple blanket statement.
This redbook includes chapters on:
򐂰 The architecture of IBM Director and how it can integrate in enterprise
management solutions.
򐂰 How to install IBM Director and its components, including Upward Integration
Modules.
򐂰 Specific chapters for integration with Tivoli TME, Microsoft SMS, HP
OpenView, CA Unicenter TNG, and Tivoli NetView.
Chapter 1. Introduction
5
Included in the chapter on installing Director is 3.6, “Examples” on page 46.
These examples show you how to configure different types of event notification,
and shows you how they would look in IBM Director. Each product chapter also
has an Examples section that shows you how to customize the management
product to receive those types of alerts and what you should expect to see.
In the next chapter we will look at the IBM Director architecture and some of the
possibilities for integrating it into your enterprise management environment. We
will begin to provide the information you need to help answer the big questions:
򐂰 Do I need upward integration?
򐂰 How should I fit IBM Director into my enterprise?
6
2
Chapter 2.
Architecture
In this chapter we introduce the concepts involved in integrating IBM Director into
your enterprise management environment. The concepts here apply, in part or in
full, to all enterprise management products, and will give you an overview of how
IBM Director can work in an enterprise environment.
This chapter contains the following:
򐂰 IBM Director architecture
򐂰 Integrating IBM Director into the enterprise
򐂰 Design considerations
7
2.1 IBM Director architecture
In order to understand how IBM Director integrates into enterprise management
solutions, it is necessary to first have a basic understanding of how IBM Director
is architected, and where the integration points are.
IBM Director uses a three-tiered architecture; client, server, and console as seen
in Figure 2-1.
Console
Console
Director
Server
Server
Web or
MMC
UM Services
Web or
MMC
IT Director
Agent
UM Services
& IT Director
Agent
Clients
Figure 2-1 IBM Director three-tiered architecture
2.1.1 Client
The IBM Director client comprises one or two components, depending on the
client operating systems:
򐂰 Windows-based clients use Universal Manageability Services (UMS)
Windows-based clients. If Director Support is selected during installation
(Figure 3-4 on page 34), the Director agent is also installed.
򐂰 Non-Windows clients use the Director agent as the client. UMS is not installed
on non-Windows systems.
8
UMS was originally designed to provide very basic management of desktops
through a Web browser (Figure 2-2) or a Microsoft Management Console (MMC)
interface (Figure 2-3 on page 10). UMS provides basic hardware inventory and
problem determination as well as hardware problem alerting through Simple
Network Management Protocol (SNMP) traps.
The amount of information available through UMS is dependant on the Common
Information Model (CIM) classes that have been registered. CIM is a Desktop
Management Task Force (DMTF) standard that allows systems management
products to communicate with each other.
Figure 2-2 UMS Web interface (Netfinity 3000)
Chapter 2. Architecture
9
Figure 2-3 UMS MMC interface (Netfinity 3000)
Tip: Hardware alerting is done through communication with the LM sensors
available on most desktop systems and some low-end Netfinity / xSeries
servers. Mid-range and high-end Netfinity and xSeries servers that use
Advanced System Management (ASM) can forward ASM alerts through the
UMS client's stand-alone SNMP trapping software if they have the ASM
device driver installed. What ASM alerts will be forwarded is dependant on the
hardware and driver installed on the client.
Using a standalone UMS client provides local management (albeit minimal). On
the plus side it is easy to implement. Unfortunately, there is also no centralized
management or security, making maintenance very cumbersome and time
consuming.
You would normally use UMS in one of two ways:
򐂰 In conjunction with a management product such as IBM Director or an
enterprise manager.
򐂰 As a standalone local management tool, providing information about the local
PC or xSeries server.
10
UMS is only available on Windows systems, however.
On non-Windows systems such as NetWare or Linux where UMS is not
available, the Director agent is required to connect to IBM Director. The Director
agent cannot be used standalone (that is, it has no user interface) — it is used
solely as a client for IBM Director. If you need standalone management such as
that provided by UMS, the tools must be supplied separately by the operating
system, hardware, and/or applications.
Note: The Director agent is also known as the IT Director agent or the Tivoli
Director agent.
Many xSeries servers have management tools with SNMP capabilities, such as
IBM ServeRAID Manager, IBM Fibre Channel Storage Manager, and APC
PowerChute. These tools can act as SNMP Agents both for IBM Director and
enterprise management systems.
2.1.2 Server
Introducing an IBM Director server adds centralized management and security
as well as additional functionality for monitoring and problem determination. This
requires the installation of the IT Director agent on each client.
Note: Implement the integration between UMS and the IT Director agent by
selecting the Director Support option during UMS installation. This allows
UMS to be used as a framework for the Director services. Refer to 3.2,
“Installing UM Services” on page 34 for further details on client installation.
In this environment, the IBM Director server becomes the centralized manager.
Clients communicate with the Director server through the Director agent. Any
events generated by the client, whether the result of hardware alerts or
monitored resources, are forwarded to the Director server. It is the responsibility
of the Director server to act on the event and provide alerting or attempt
resolution. This does not mean that the client cannot also be managed
independently by an enterprise management system. As we’ll see later, both
forms of management have their place in different environments.
The addition of the IBM Director server also allows for greater detail in the
monitoring of systems. There is a large amount of information available from
Director, such as CPU utilization and free disk space, that may also be available
from your enterprise management system. However, more detailed information
11
such as system ambient temperature and serial numbers may only be available
with the Director server. Also, there are additional tools in IBM Director for overall
management. These include Cluster Systems Management, Capacity Manager,
and Advanced System Management tools.
2.1.3 Console
The IBM Director console is where administrators interact with the Director
server. It is a Java based GUI that can be run either from the Director server
itself, or remotely via TCP/IP. It does not, however, play a direct role in upward
integration.
2.2 Integrating into the enterprise
There are three different ways to integrate Director into your enterprise
management system:
򐂰 SNMP from the client
򐂰 An enterprise management agent on the client
򐂰 The Director server
2.2.1 Method 1: Via SNMP from the client
In method 1, shown in Figure 2-4, an SNMP service is running on the client. The
enterprise management system communicates directly with the client via the
SNMP protocol, and the client sends event notification to the enterprise
management server via SNMP traps. The amount of information available from
the client is based on the functionality of the agent or agents installed.
12
Console
Enterprise
Management
System
Director
Server
Web or
MMC
SNMP
Web or
MMC
Clients
UM Services
IT Director
Agent
UM Services
& IT Director
Agent
Figure 2-4 SNMP management of Director clients
For example, if the client is a Windows-based system, installing the UMS client
will provide the basic hardware inventory and access to system environmentals
(that is, temperature and fan status), as well as sending traps from LM sensors. If
the client is a properly configured xSeries server, events from an Advanced
Systems Management Processor could also be sent through the UMS client as
traps. (See 3.2, “Installing UM Services” on page 34 for more information on
configuring UMS for SNMP access.)
If the client is not a Windows system, other software needs to provide SNMP
access to the system. If the client is an xSeries server with a ServeRAID card,
the ServeRAID Manager software can be configured to send SNMP traps when
RAID events are triggered. If there is an Advanced Systems Management PCI
Adapter or Remote Supervisor Adapter available, ASM alerts can be forwarded
as SNMP traps from these adapters. Even UPS units can participate in this
environment because many come with software such as APC’s PowerChute plus
to generate SNMP traps in response to power events.
While Figure 2-4 shows an IBM Director server, one is not necessary. In this
example, both Director and the enterprise management system can manage
these client. You could also remove the Director server and manage these client
solely with the enterprise management system.
13
2.2.2 Method 2: Via the enterprise management agent on the client
The second method of integration, shown in Figure 2-5, is through an installed
enterprise management system client. In this scenario UMS or other
management software and the enterprise management agent communicate with
each other on the client. The enterprise management client handles
communication to the enterprise management server natively. With UMS this is
most often done with an upward integration module (UIM) installed on the
enterprise management server.
Console
Director
Server
Web or
MMC
Enterprise
Management
System
Enterprise
Native
Web or
MMC
Clients
UM Services
IT Director
Agent
UM Services
& Enterprise
Agent
Figure 2-5 IBM Director and enterprise management system client integration
UIMs for the following managers are discussed in this redbook:
򐂰
򐂰
򐂰
򐂰
򐂰
Tivoli TME (Chapter 4, “Tivoli Management Environment” on page 65)
Microsoft SMS (Chapter 5, “Microsoft SMS” on page 135)
HP OpenView (Chapter 6, “HP OpenView” on page 149)
CA Unicenter (Chapter 7, “CA Unicenter TNG” on page 175)
Tivoli NetView (Chapter 8, “Tivoli NetView” on page 205)
In this method, the enterprise management system has much more control over
the client. The communication between the enterprise management agent and
other management software is usually handled by DMI (Desktop Management
Interface) or the more recently adopted and much preferred CIM protocols.
If your enterprise management agent must use DMI to communicate with UMS,
then DMI Support must be enabled within the UMS client. Details on installing
DMI Support within UMS in covered in Chapter 3, “Installing IBM Director” on
page 29.
14
Attention: Installing DMI Support within UMS causes the CIM2DMI Mapper
service to be installed and started. This service can use significant resources
on the client machine and should be installed only if absolutely necessary.
As with the previous example using SNMP, the Director server shown is not
required, but can be quite useful. If the Director server can monitor information
within the system that the standard client cannot, such as ServeRAID or ASM
events, and the enterprise management client has a command line tool for
communicating with the enterprise management client or server, then these can
be used together to provide more detailed information to the enterprise
management server then it is available with its client alone.
For example, if you were running a non-Windows operating system on a client,
the IT Director agent would be running rather then UMS. Because UMS is not
running, an enterprise management client would not be able to communicate
with the Director agent. However, you could have the Director agent run a
program on the client that would pass an event to the enterprise management
agent or cause the agent to perform some other function.
2.2.3 Method 3: Via the IBM Director server
In the last method, the clients themselves do not communicate with the
enterprise management server. Instead, the Director server handles all
monitoring and events.
Events are forwarded to the enterprise management server either via SNMP or
an enterprise management client installed on the Director server. This minimizes
the footprint on the client systems because the enterprise management client
does not have to be installed on every client. However, this also means that
enterprise management system features are not available on the clients. See
Figure 2-6 on page 16.
15
Console
Director
Server
Enterprise
Management
System
SNMP or
Enterprise Native
Web or
MMC
UM Services
Web or
MMC
IT Director
Agent
UM Services
& IT Director
Agent
Clients
Figure 2-6 IBM Director server integrating with enterprise management system
2.3 Security
Whenever you’re dealing with the management of your systems and the data that
resides on them, security needs to be addressed. Some of the areas that you
need to look at in regards to security are:
򐂰 Securing access to the management agent(s)
򐂰 Securing access to the management server(s) from agents and consoles
򐂰 Communications between agent and server.
Securing access to the agents and servers is not within the scope of this
redbook, but let’s look at some issues associated with communicating between
management products. See the user’s guide for your management product for
more information on securing access to management agents and servers.
There are two areas of agent/server communication that we discuss in this
section:
򐂰 Access to the agent and server (Authentication) — This involves who can get
what level of access to the agents and the management server.
򐂰 Data on the wire (Encryption) — This is whether or not the data being sent
across your network can be read or not.
16
2.3.1 SNMP security considerations
SNMP Versions 1 and 2 have only the most rudimentary security. Version 3
currently being reviewed has more robust security, but is not expected to be
available or widely used for some time. We will limit our discussion to the current
SNMP standards.
Authentication
Access to agents and servers is controlled by a community string. This
alphanumeric string identifies a “community” of SNMP agents and servers.
Based on this string and the address of the sender, an agent will accept or reject
commands from a manager.
Figure 2-7 Windows 2000 SNMP security configuration screen
In Figure 2-7 we see the Windows 2000 SNMP security configuration screen. To
access this screen:
1. Right-click My Computer and click Manage.
2. In the left pane, open the Services and Applications node.
3. Click Services.
17
4. In the right pane, scroll down to the SNMP Service, right-click it and click
Properties.
5. Click the Security tab.
This system is configured to accept SNMP packets from the default community
name public, and to accept packets from any host.
In addition, different communities can have different levels of access to a
particular agent. In the example in Figure 2-7, the community public has READ
ONLY access. Highlighting a community name and clicking Edit shows
Figure 2-8, where you can configure the level of access.
Figure 2-8 Windows 2000 SNMP community rights screen
Encryption
When two systems communicate with each other, the physical security of the
network that communications travels across has to be considered. With the use
of the Internet and VPNs on the increase, care has to be taken that the highly
sensitive management data is not compromised.
Let’s look at the network trace of some SNMP commands, shown in Figure 2-9.
Here we were inquiring about some of the hardware in an SNMP agent. As you
can see, all of the information is sent as clear text. Anyone who could get this
trace can see the community name and IP address used, and could therefore
impersonate the management server.
For this reason, even though SNMP is widely used, it is almost always blocked by
Internet firewalls and encrypted when sent over public networks.
18
Information sent via
SNMP is freely
viewable via a
network trace.
Figure 2-9 Network trace of SNMP
2.3.2 Security considerations with enterprise management agents
Where SNMP has one current set of security protocols, each enterprise
management system may use one of more protocols.
Authentication
When the enterprise management server communicates with its own agent, it
uses whatever authentication protocols it has. However, when the enterprise
management server talks to another UMS client, it authenticates itself before
being granted access. Our testing with UMS shows that this authentication is
done using a Challenge-Handshake Authentication Protocol (CHAP). CHAP is a
standard authentication protocol whereby password information is not sent
directly over then network. The user is then authenticated against a set of user
names and passwords stored on the client.
19
While this does provide for authentication, it requires that each and every client
maintain a list of authorized user names and passwords. Maintenance of this list
can often lead to trouble accessing a system and to security holes when an
administrator leaves the group. You can use IIS for the web server rather than the
HTTPD service included with UMS. This would allow you to use domain user
names for authentication, but that would require the installation and maintenance
of IIS on all of your managed systems, and is only available on Windows NT and
2000.
Not enabling Web access in UMS does mean your enterprise management
server will only be able to communicate to the client through it’s installed agent,
but it does eliminate this security issue.
Unless Web access to UMS clients is absolutely necessary, we recommend
enabling neither Web Based Access nor Web Based Remote Control when
installing UMS clients. See 3.2, “Installing UM Services” on page 34 for more
information on options for installing UMS.
Encryption
Once a system has been authenticated, the next major concern is what data is
actually sent across the wire. As you can see with the SNMP capture example in
Figure 2-9 on page 19, it is relatively easy for someone to capture data if they
have physical access to your network. To help minimize this, the data transferred
between the UMS web access service and a web browser or enterprise
management server is encoded. While not as strong as encryption, encoding
should prevent casual hacking of your management system.
2.3.3 Security suggestions
Now that we’ve probably alarmed you, there are a few relatively simple things
you can do to help secure your network.
Physical security
One of the most common methods of securing your systems management traffic
is to physically separate it from other network traffic. This can mean simply
ensuring that your firewall will not pass management traffic to or from the
Internet.
Where more security is required, you can even build a dedicated management
network. By configuring all of your systems management traffic to run on a
separate network from your user community and applications, you add a very
high level of security because you have to physically connect to the management
20
network to access the management agents. This can be quite expensive,
especially you have a large number of systems, (each requiring a separate
network interface for systems management), or they are geographically
separated.
Communication encryption
The other option is to use encryption at the protocol level, such as implementing
Internet Protocol Security (IPSec) to secure TCP/IP communications between
the management server and critical agents.
2.4 Design considerations
In this section we discuss the reasons for choosing one implementation method
over another. In all of these cases the details of which enterprise management
system you use are not discussed, but some general concepts are used. See the
chapters in this redbook on your specific enterprise management system’s
capabilities and requirements.
2.4.1 Should a Director server be used?
One of the first questions to be answered is whether or not you need an IBM
Director server in your implementation. The basic question is whether the
Director server provide additional functionality, thereby making it worth the
investment. The following additional functionality is available from a Director
server.
򐂰 Separate management responsibility
The first, and probably easiest reason to consider implementing an IBM
Director server is the need or desire to separate the responsibility for
managing certain systems:
– There can be political reasons to separate responsibility. If the team
responsible for managing a group of systems does not report to the same
hierarchy, they may not want to use the same system. If this is approved by
management then separate management systems is a viable option.
– There can be financial reasons to put the management of a group of
systems on a less costly management platform.
– There can even be geographic reasons to separate management of a
group of systems. If there are enough systems in a specific geographic
area to justify a management server, but the cost of using your enterprise
management system is prohibitive, using a smaller less expensive solution
for that geography is a useful solution.
21
– If the implementation of your enterprise management system is not ready
to support a group of systems, using an element manager that will
eventually tie into your system is a very good short-term solution.
򐂰 Additional functionality
Adding an IBM Director server to your environment can bring additional
functionality and features not available with a stand-alone client:
– Because non-Windows clients cannot run UMS, there is nothing for your
enterprise management system to communicate with to get the additional
information and alerts available within Director.
– IBM Director has many tools to remotely manager high-end components
like ServeRAID controllers and Advanced Systems Management that are
commonly found in xSeries servers.
– IBM Director can monitor resources and counters that neither the
stand-alone nor enterprise management clients can access. Events such
as RAID drive Predictive Failure Analysis (PFA) or monitoring internal
temperatures and voltages are not possible with the stand-alone UMS
client.
– IBM Director uses a centralized security scheme that UMS does not use. If
you are going to access the UMS tools directly through the Web interface
you need to maintain user names and passwords on each and every box.
This is very time consuming and prone to error.
– There are management tools like Capacity Manager and Cluster Manager
which are not available with the stand-alone client. While some of these
may be available with your enterprise management system they can be
very expensive.
The decision on whether to include a Director server in your environment, while
often given little thought, is critical because it impacts other decisions such as
how and where to integrate into your enterprise solution. Look over these
reasons, see if you can come up with some others, then decide what would be
best for your environment. Whenever possible, leave your options open.
For example, if you plan to use a Director server in six months but not today,
include Director Support in your client installations. If you are still not sure, look at
other tools like the ones discussed next to see if they can provide what you need
without requiring a Director server.
22
Other tools to consider
There are circumstances where the features needed can be supplied by one or
two smaller tools rather than a dedicated IBM Director server. Here are some of
the tools you can use:
򐂰 Advanced System Management PCI Adapter/Remote Supervisor Adapter
This adapter allows you to put up to 12 Advanced System Management
processors on your Ethernet or Token-ring network using an ASM
interconnect. These ASM processors can then be configured to forward their
events via SNMP Trap.
Tip: Our testing has shown that putting more than 8 Advanced Systems
Management Processors on a single interconnect bus may lead to
communications problems. This appears to be due to the overall length of
the bus when multiple cables are used to interconnect the processors.
򐂰 ServeRAID Manager
Since Version 4 of this software, a monitoring service has been available. In
addition to allowing remote management of the ServeRAID controllers in the
client, it can also be configured to send SNMP traps based on RAID events.
򐂰 Netfinity Fibre Channel Storage Manager
Like the ServeRAID Manager, the Netfinity Fibre Channel Storage Manager
allows for the remote management of Netfinity Fibre Channel controllers as
well as SNMP traps for fibre channel events.
Unlike ServeRAID Manager, a Fibre Channel Storage Manager user interface
must always be running to forward SNMP traps.
All of these tools can be used where UMS is not supported, where implementing
an IBM Director server is not feasible, or to supplement the tools in IBM Director.
2.4.2 Where to establish the integration
Assuming you are planning to install an IBM Director server, the next step is to
decide where to integrate IBM Director with your enterprise management
system. In 2.2, “Integrating into the enterprise” on page 12, there were many
possibilities for integration, but only two points within a Director environment to
establish the connection; the individual clients or the Director server itself.
23
Connecting from the client
This is probably the most common connection point for upward integration
(Figure 2-10). Because most systems and people expect to see the alert coming
from the system with the problem, it is usually preferable to send the event from
the client. Also, with each client treated independently, a problem with one
system won’t prevent another system from be managed.
Console
Enterprise
Management
System
Director
Server
Web or
MMC
SNMP
Web or
MMC
Clients
UM Services
IT Director
Agent
UM Services
& IT Director
Agent
Figure 2-10 Establishing integration from the client
This configuration also has some drawbacks:
򐂰 It may require configuration work be done on the individual clients.
򐂰 There are more network links that can impact communication.
򐂰 If the client goes down it cannot notify a system what has happened.
Connecting from the server
This configuration is usually used when one group is responsible for managing a
group of systems, but needs to forward information to an enterprise management
system (Figure 2-11).
24
Console
Director
Server
Web or
MMC
UM Services
Enterprise
Management
System
SNMP or
Enterprise Native
Web or
MMC
IT Director
Agent
UM Services
& IT Director
Agent
Clients
Figure 2-11 Establishing integration from the server
In this scenario, inventory updates are usually handled by allowing the enterprise
management server to pull records from the Director database. Events that occur
on client systems are forwarded either via SNMP trap or through an enterprise
management client installed on the Director server. There are some very useful
benefits to this configuration:
򐂰 The Director server provides centralized event and security management. If
you need to make a change in access to a system or how events are
forwarded to the enterprise management system, you only have to do them in
one place.
򐂰 If your design uses an enterprise management client, then connecting only
from the Director server means you only have to buy one client rather then
one for every system you manage.
On the other hand, there are also some potentially serious drawbacks as well:
򐂰 Your enterprise management system will have to look at the details of any
alerts received from the Director server to determine which system actually
had the event. Some systems are coded only to look at who sent the alert to
determine which system had the problem.
򐂰 The Director server becomes a single point of failure. If your Director server
goes down, no events are forwarded to your enterprise management system.
There are ways of implementing redundant IBM Director servers, but they are
outside the scope of this book.
25
2.4.3 How to establish the connection
Once you’ve decided where IBM Director will integrate into your enterprise
management system, the next question is how will it integrate? There are
basically four methods to use:
򐂰 SNMP
Probably the most popular protocol for systems management, SNMP is used
in one form or another by almost every management product on the market.
Most element managers support SNMP either as their native communications
protocol or as a method of upward integration.
While SNMP is popular, it does have it’s drawbacks:
– SNMP uses the User Datagram Protocol (UDP). UDP is connectionless,
meaning no connection to the destination has to exist for the data to be
sent. Therefore there is no guarantee that the message is received.
– The current version of SNMP has very limited security features to protect
access to the agent and none to protect the data going across the
network. See 2.3.1, “SNMP security considerations” on page 17.
– Not all management systems implement the full protocol. This means that
major modification to the Management Information Base (MIB) may need
to be done just to get the systems talking to each other.
򐂰 Client management protocols
Client management protocols like DMI and CIM allow different systems
management products to share information. The basic concept is that a
management product, device driver, or operating system “exposes”
information about what things it can monitor to a service layer. The service
layer can also issue standardize commands to those services so they can
perform actions. There are frequently files stored on the client, such as .MIF
and .MOF files, to upload information like inventories to the management
software for storage.
򐂰 Upward integration module
In IBM Director, upward integration modules (UIMs) are packages that are
installed on the workgroup or enterprise management server to allow it to
communicate with a UMS client. These UIMs update the management server,
and sometimes the associated clients. Specific UIMs are discussed in the
chapter for their enterprise management systems.
26
򐂰 Scripts
One of the most flexible, yet hardest to implement, is the use of scripts. This
basically involves writing scripts on the workgroup or enterprise server and
the client to be managed. These scripts are run at scheduled intervals, or in
response to an event, and are used to either update information or cause
something to happen in response to a problem.
2.5 Conclusion
In this chapter we have looked at the architecture of an IBM Director
environment, different methods of integrating IBM Director into enterprise
management systems, and some of the things to consider when designing your
integration.
27
28
3
Chapter 3.
Installing IBM Director
In this chapter, we describe how to install IBM Director Version 2.2.
Before starting the installation, make sure that the hardware and operating
system requirements as documented in the IBM Director User’s Guide are met.
The user guide is available as DIR2_2UG.PDF in the directory \DOCS\EN\ on
the IBM Director CD-ROM.
29
3.1 Starting the installation
To start the installation program, simply insert the IBM Director CD-ROM into the
drive. The program starts automatically as shown in Figure 3-1.
Figure 3-1 Autostart window
The first option, Install Director, is where you install one or more of the Director
components or the upward integration modules (UIMs) that let you integrate
Director with an enterprise management system.
The second option, Install UM Server Extensions (UMSE), is where you install
the additional components, such as the ServeRAID Manager, that are useful for
Netfinity and xSeries servers. UMSE must be installed after Director is installed.
See 3.5, “Installing UM Server Extensions” on page 43.
Clicking the Install Director option leads to Figure 3-2, where you specify which
Director components to install.
30
Figure 3-2 Select Components window
The following options are available for the installation:
򐂰 Server
Installs IBM Director Server, Console, and Client. The database to store the
IBM Director information can reside on the IBM Director Server. You can also
choose to use an existing database on another server to store the IBM
Director database.
One IBM Director Server can manage up to 1500 systems.
Note: The IBM Director 2.2 Server is only supported on the following:
򐂰 Windows 2000 Server or Advanced Server
򐂰 Windows NT Server 4.0 (with Service Pack 4, or later)
򐂰 Console
Installs the user interface for IBM Director servers. A console is needed to
perform the IBM Director tasks and to access information stored in the IBM
Director server database. You should install the Console on all machines
where you plan to administer your Director environment. The IBM Director
Console can be installed (and simultaneously used) on multiple systems.
Note: The IBM Director V.2.2 Console can only be installed on
Windows-based systems, such as Windows 95/98/NT/2000.
Chapter 3. Installing IBM Director
31
򐂰 Client
Installs the client files on Microsoft operating systems. You need to install the
client on each system you want to manage using the IBM Director. For the
installation of the Director management agent on other operating systems,
refer to the documentation provided with the available Director management
agents.
A list of the supported operating systems can be found in the IBM Director
User’s Guide.
򐂰 Workgroup/Enterprise Integration
Installs UM Services upward integration modules (UIM) for enterprise
management environments on the server where the enterprise management
tool resides (for example, on the SMS server). Supported enterprise
managers are:
– CA Unicenter TNG Framework for WIN32 Version 2.2, AIM IT Version 3.0,
Asset Management Option 3.0, SHIP IT Version 2.0, Software Distribution
Option 2.0
– HP OpenView Network Node Manager 6.0 and 6.1
– Tivoli NetView 5.1.1 and 6.0 for Windows NT
– Microsoft SMS 1.2 and 2.0
– Tivoli Enterprise, including Tivoli Framework 3.6, Tivoli Software
Distribution 3.6, Tivoli Inventory 3.6, and Tivoli Enterprise Console 3.6
(although this UIM is installed by other means as described in 4.3,
“Installing UM Services Plus for Tivoli” on page 79).
It is assumed that the Enterprise Management software is already installed
before the installation of an upward integration module is started. You do not
need to have UM Services installed on the system before installing the UIM.
For the integration with Tivoli Enterprise there is the Tivoli Plus Module
available on the IBM Director CD (\Director\UM Services Plus for Tivoli). See
4.3, “Installing UM Services Plus for Tivoli” on page 79.
To install an upward integration module for one of the other enterprise
managers, click Workgroup/Enterprise Integration in the Select
Components window. The Integration Selection window (Figure 3-3) appears.
32
Figure 3-3 Integration Selection window
The procedure for the installation of the upward integration modules for the
enterprise management environments and the integration itself is covered in
the remaining chapters of this redbook.
Alert on LAN Proxy routes the broadcasted Alert on LAN traffic that is then
forwarded to a central collection site.
Note: Support for Intel LANDesk is included in UMS as described in 3.2,
“Installing UM Services” on page 34. LANDesk is not discussed in this
redbook.
In the rest of this chapter, we describe how to install the IBM Director Server,
Console and Client/UM Services. We start with the installation of UM Services
followed by the installation of the IBM Director Server and the console. The
installation of the UM Server Extensions is also described.
Tip: Additional information about the upward integration modules can be
found in the following readme file on the IBM Director CD-ROM:
\Director\WIN32\INSTALL\EN\readme.htm
Search for the heading “Integrating UM Services into System Management
Environments” in the file.
33
3.2 Installing UM Services
To install UM Services, click Client in the Select Components window (Figure 3-2
on page 31). The following window (Figure 3-4) shows you the components
available for installation on the local system.
Figure 3-4 UM Services Client Configuration
Director Support, Web Based Access, System Health Monitoring, and Help Files
are selected by default. The other components are optional. The SNMP
forwarding option is selected by default if SNMP is already installed.
򐂰 Director support
This option enables the client system to be managed in an IBM Director
environment. This option is required if you have or plan to have a Director
server.
򐂰 Web Based Access
Provides direct access to UM Services through a Web browser. Web Based
Access provides a Java-based tool for managing an endpoint system and
viewing the CIM-based inventory data.
This component will install an HTTP service (or integrate with an existing IIS
installation) on the local system, and will require a user name and password
be entered during install. The user name and password will be used to limit
access to the UMS client.
34
If you select this option, the following window (Figure 3-5) will appear during
installation, prompting you for the userid, password, and TCP/IP port for the
Web-based access to UMS.
Figure 3-5 Defining UserID and password for Web Based Access
Note: UserID and Password are case sensitive.
The default TCP/IP port is 411. If you need to use a different port, your
choices are 6411, 6500, 6600, or 6611. Make sure that no other TCP/IP
application uses the port you select.
򐂰 System Health Monitoring
Subject to the hardware capabilities of the system, provides active monitoring
of critical system functions such as disk space, temperature, fans, power
supply voltage, and system cover removal. It can also allow system problems
to be detected early before a system failure occurs. This component also
provides software for enabling the Alert on LAN functionality available on
systems equipped with this feature.
System administrators can be notified of health problems by a CIM event or
an SNMP trap. Administrators using Microsoft SMS 2.0 can also be notified
via an SMS Status Message. Critical problems will also be reported to the
local user with a pop-up message.
35
򐂰 Web Based Remote Control
Web Based Remote Control allows a remote user to take control of the
desktop of an endpoint. The remote user can either monitor the screen of the
endpoint or switch to active mode and take control of the keyboard and
mouse. Remote Control can be a valuable tool for troubleshooting and fixing
system problems remotely.
This option requires that the component Web Based Access also be
installed.
Attention: Do not have more than one tool for remote control installed on a
system. You need to decide which of the two tools provided by Director you
are going to use (if any):
򐂰 UMS Web Based Remote Control
򐂰 IBM Director Remote Control
While the selection in the UM Services Client Configuration window refers
to the UMS Web Based Remote Control, you will be asked later during the
installation if you want to install IBM Director Remote Control.
If both tools are installed you might experience some problems running
remote control sessions (e.g. blue stop screens or problems sending
keystrokes). In this case, uninstall UM Services and reinstall it choosing
only one of the options.
Attention: You can configure Web Based Remote Control so that the user
at the client system must authorize remote access beforehand. However,
with UMS, you can disable this prompt through the browser interface by
simply disabling the option or by setting the timeout to 0.
򐂰 LANDesk(TM) Management Suite Integration
Prepares the endpoint system to be managed by LANDesk Management
Suite by installing the Intel Common Base Agent (CBA), which is the client
part of LANDesk. CBA allows the endpoint system to be discovered by
LANDesk and enables file transfer, software distribution, and inventory from
the LANDesk server.
You only need this option if you wish to integrate with Intel LANDesk.
Choosing this option will install additional code on the client system. For the
LANDesk integration you do not need to install a separate Upward Integration
Module on the management server.
36
򐂰 Tivoli Management Agent
Installs TMA 3.6.2 which enables the system to be an endpoint managed by
the Tivoli Enterprise software. Tivoli Enterprise software is capable of
managing medium to large networks of PCs, Unix workstations and servers,
mainframes, and other network devices.
You only need this option if you wish to integrate with Tivoli Enterprise.
򐂰 SNMP access and trap forwarding
If you have SNMP already installed, then this option is selected by default.
Enables CIM information to be accessed from an endpoint using the SNMP. If
System Health Monitoring is also enabled, this option also causes CIM events
to be forwarded as SNMP traps. The SNMP Integration option requires that
you have the SNMP Service (provided with your operating system) installed
on the endpoint. If the SNMP service is not installed, you will be prompted to
insert your operating system installation media and install SNMP during the
UM Services installation.
If you select this option and do not have the SNMP network service installed,
you will be asked if you want to install the SNMP network service now.
– If you want to continue the UMS installation without installing the SNMP
network service, click No.
– If you want to install the SNMP network service, click Yes and follow the
instructions for the SNMP installation. You do not need to restart the
system at this time.
򐂰 DMI support
Enables the Desktop Management Interface (DMI) Service Provider and the
CIM2DMI Mapper service. The CIM2DMI Mapper service translates CIM data
and events into DMI data and events, and visa versa. The CIM2DMI Mapper
service can consume significant resources, and therefore this option should
only be used if you have a need for real-time mapping of UMS events to a DMI
system. None of the management products in this redbook require the use of
DMI support.
If you select this option, you will be prompted during the installation to select
the platform on which UMS is going to be installed as seen in Figure 3-6 on
page 38.
37
Figure 3-6 Defining platform for DMI Support
򐂰 Help files
Provides help resources for understanding and operating Director. Files are
HTML, and information may be found through the table of contents, index,
and search functions. The help files offer information on the general function
of the Director console as well as explanation of each field and active
component of each window in Director, from Asset ID to User Security.
Click Next to start the installation.
When the system asks you if you want to install the files for remote control, this
question concerns IBM Director Remote Control, not UMS Web Based Remote
Control.
򐂰 If you chose to install UMS Web Based Remote Control in the UM Services
Client Configuration window (Figure 3-4 on page 34), click No.
򐂰 If you did not select UM Services Web Based Remote Control, and want to
install IBM Director Remote Control instead, click Yes.
If the system asks you if you require user authorization for remote control window
access click Yes or No. If you click Yes, as soon as a remote control session is
started, either using IBM Director Remote Control or UMS Web Based Remote
Control, then the local user will be asked to confirm that a remote user can
access the local system.
38
Now the necessary files are going to be installed. At the end of the installation
you need to restart your system.
3.3 Installing IBM Director Server
To install the IBM Director Server, click Server in the Select Components window
(Figure 3-2 on page 31).
Note: The Director service account user name will be automatically set to the
user name that is logged on to install the Director Server. You will only have
the chance to provide a different password. Therefore the installation of the
IBM Director Server should be started when you are logged on using the
domain user name of the Director service account.
The first part of the installation process will be to install UMS on the local system.
The windows as described in 3.2, “Installing UM Services” on page 34 appear.
The option to install Director Support has been removed (compare Figure 3-7
with Figure 3-4 on page 34) because this support is required on the Director
server.
See 3.2, “Installing UM Services” on page 34 for details.
Figure 3-7 UMS configuration window
39
After UMS installation completes, the Director server installation begins.
You will be prompted to specify where to put:
򐂰 Program files (by default, C:\Program Files\Director)
򐂰 Software distribution package creation directory (by default, C:\Program
Files\Director\SwDistPk\) — where created packages are stored
򐂰 Installed software distribution packages (by default, C:\Program
Files\Director\SwPkInst\) — packages that are sent to this system for
installation are stored
Proceed with the installation. Because the installation of the IBM Director Server
includes the installation of UM Services, you will need to go through the same
steps as described in 3.2, “Installing UM Services” on page 34.
After the installation of the UM Services software has finished, the Windows
Account Information window opens. You need to enter and confirm the password
for the domain username which is currently logged on.
In the next step you define the database you want to use for IBM Director
(Figure 3-8). All inventory data of IBM Director is stored in this database.
Figure 3-8 Database selection
40
The following databases are supported by IBM Director:
򐂰 Microsoft Access
Choosing this option creates a new Microsoft Jet database. If the name of the
IBM Director database is already used for another Jet database, you have the
option to either delete and re-create it, or to specify a new database name.
Notes:
– The size of the Access database is limited to 1 GB.
– If you are using Windows NT, you will have to install the latest MDAC driver
before Director Server installation. This driver is on the Director CD-ROM.
򐂰 Microsoft SQL Server
Select this option to install Microsoft SQL Server database support. You will
be prompted for more information about your Microsoft SQL Server such as
ODBC Data Source, Server Name, Database Name, User ID and Password.
The necessary information should be provided by your database
administrator.
IBM Director supports Microsoft SQL Server version 6.5 and 7.0 with Service
Pack 1.
򐂰 IBM DB2
This option will install IBM DB2 Universal Database support. You will be
prompted for the information about your database such as Database Name,
User ID and Password. The necessary information should be provided by
your database administrator.
Supported versions are 5.2, 6.1, and 7.1.
򐂰 Oracle
This option will install Oracle Server Database support. You will be prompted
for the information about your database which should be provided by your
database administrator.
Supported versions are 7.3.4 through 8.1.6.
򐂰 Microsoft Data Engine
This option will install Microsoft Data Engine (MSDE) database support. You
will be prompted for the information about your database, which should be
provided by your database administrator.
Supported versions are MSDE 1.0 with Service Pack 1.
򐂰 Use existing ODBC entry
This option displays a list of existing ODBC data sources to select one of
them as your database.
41
After configuring the database connection the Network Driver Configuration
window opens (Figure 3-9).
Figure 3-9 Network Driver Configuration
You need to specify the network transport options for the IBM Director server.
These are:
򐂰 System Name — The system name of the UM Services client on the IBM
Director server.
򐂰 Network Drivers — To enable the network transport for the use of IBM
Director highlight the driver then click the Driver Enabled checkbox.
򐂰 Network Address (for NetBIOS) — The NetBIOS network name.
򐂰 Network Time-out (sec) — 15 seconds is the default time-out.
򐂰 Enable Wake on LAN — Enables IBM Director to wake up managed systems
before performing tasks on them. This function requires a network card
installed in the managed system that supports Wake On-LAN.
򐂰 Require User Authorization for Screen Access — Enables the users to control
remote access to their systems.
򐂰 Disable Screen Saver — This option disables the screen saver on the remote
system temporarily when a Remote Control session is started to prevent
42
overhead. The screen saver is restored when the Remote Control session is
stopped.
򐂰 Disable Background Wallpaper — This option disables the background
wallpaper on the remote system temporarily when a Remote Control session
is started to prevent overhead. The background wallpaper is restored when
the Remote Control session is stopped.
You can change the Network Driver Configuration settings later by selecting
Start > Programs > Director > Network Driver Configuration on the server or
by running TWGIPCCF.EXE on a client.
At the end of the installation you need to restart your system.
The IBM Director server and support program run as Windows NT/2000 services
and are automatically started when the operating system is started. You can also
set the Startup mode of the Director Support Program to Manual and start it by
clicking Start in the Services Window or using the command NET START TWGIPC.
3.4 Installing IBM Director Console
To install the IBM Director Console click Console in the Select Components
window (Figure 3-2 on page 31). Follow the prompts to install the product.
At the end of the installation you should restart your system.
3.5 Installing UM Server Extensions
UM Server Extensions should be installed on all of the following:
򐂰 Each Netfinity and xSeries server
򐂰 Each IBM Director console
򐂰 The IBM Director server
The installation of the UM Server Extensions will be started by clicking Install
UM Server Extension in Figure 3-1 on page 30.
You will be prompted to select which components you wish to install. On the
systems where you will be installing the Director server or a Director console, you
should install all components. See Figure 3-10 on page 44.
43
Figure 3-10 Select Tools window
The following tools are available:
򐂰 Advanced System Management — To access the Advanced System
Management Processor, Advanced System Management PCI Adapter,
Remote Supervisor Adapter, and interconnects.
򐂰 Capacity Manager — Resource-management and planning tool for proactive
performance monitoring. The Capacity Manager reports trends that can be
used to identify performance bottlenecks as well as potential performance
bottlenecks.
򐂰 Cluster Systems Management — To administer high-availability MSCS cluster
environments to increase the reliability of cluster nodes.
򐂰 Fibre Channel Storage Manager — To manage Fibre Channel storage
subsystems.
򐂰 Fuel Gauge Monitor — This option is only available on systems with the Fuel
Gauge architecture in the BIOS and device driver support for the service
processor. It monitors the utilization of the power subsystem and provides
functionality to review power utilization.
򐂰 Rack Manager — Using the Rack Manager you can group your equipment to
display a realistic picture of nodes and devices with their physical rack
placement for efficient management and monitoring capabilities.
򐂰 Software Rejuvenation — To schedule software restarts either on stand-alone
servers or cluster nodes.
44
򐂰 System Availability — To measure planned and unplanned downtime of the
system and to display this information graphically
򐂰 ServeRAID Manager — To configure, manage, and monitor ServeRAID RAID
controllers.
Note: Some of these options (e.g. ServeRAID Manager) are also available as
separate tools and can be installed without installing UM Server Extensions.
However, by installing them with UM Server Extensions, these tools will be
integrated into the IBM Director console.
When you click Next, you will be prompted to confirm your selections
(Figure 3-11):
Figure 3-11 Confirm Selection
Click Next to continue the installation.
Because the IBM Director services need to be stopped for the installation of the
UM Server Extension, you will be prompted to stop the IBM Director at this point
(Figure 3-12):
45
Figure 3-12 Stopping IBM Director Services
Click Yes.
The IBM Director services will be stopped to proceed with the UM Server
Extensions installation.
At the end of the installation you need to restart your system.
3.6 Examples
In this section we show you four generic examples of how to configure alerts to
be forwarded to IBM Director and enterprise management systems. These
examples are to show you how to set up four types of events:
򐂰 Pass through the Director server, using notification of a ServeRAID disk
failure as an example.
򐂰 Directly from a UMS client, using notification via an Advanced System
Management processor of a fan failure as an example.
򐂰 Directly from hardware, using notification via the Remote Supervisor Adapter
of system shutdown as an example.
򐂰 Through a third-party software package, using notification via APC
PowerChute Plus of the loss of AC power supply as an example.
In later chapters dedicated to specific enterprise management systems, we will
continue these examples, giving you details of how to configure those systems
and the results you will receive. Once the event is forwarded to your enterprise
management system, it should be handled according to your management policy
as any other event would.
46
3.6.1 ServeRAID hard disk failure through Director server
In this example, we demonstrate an event generated by a Director client, and
then forwarded to the Director server and through it to an enterprise
management system. This is the same scenario used in 2.2.3, “Method 3: Via the
IBM Director server” on page 15. In this case, the event being generated is the
failure of a hard disk drive (HDD) attached to a ServeRAID controller.
By default, all system hardware failures on systems with an IT Director agent or
Director support in UMS enabled are forwarded to the Director server. The
forwarding of ServeRAID events requires the installation of the UM Server
Extensions, which will forward events for the ServeRAID controller and attached
drive enclosures. (See 3.5, “Installing UM Server Extensions” on page 43 for
details on installing the UM Server Extensions.)
Because of this, no special configuration needs to be done on the client or the
Director server to receive these events. Figure 3-13 shows the classes of events
that can be generated by the ServeRAID adapter. You can see all of the
ServeRAID events by creating or opening an Event Filter Builder, unchecking the
Any box, and expanding the Netfinity Storage tree.
ServeRAID events in
IBM Director
Figure 3-13 Simple Event Filter showing classes of ServeRAID events
Failure of a drive, in this case SCSI channel 2 ID 5, is seen through the
ServeRAID tool in Figure 3-14, and the Director Event Log in Figure 3-15.
47
Figure 3-14 ServeRAID Manager view of HDD failure
Figure 3-15 Event Log message from HDD failure
Once the event has been received by the Director server, it is handled by an
Event Action Plan (Figure 3-16).
48
Figure 3-16 Sample event action plan for ServeRAID events
The event action plan shown in Figure 3-16 shows the plan Test SNMP to
Enterprise (circled), which includes an event filter, ServeRAID Events. Attached
to this filter are three actions, two that forward to our Tivoli NetView server and
another that forwards to our HP OpenView server. For more information on Event
Action Plans, see the IBM Director User’s Guide on the IBM Director CD.
There are two ways to get the event to an enterprise management server:
򐂰 Via an SNMP trap
򐂰 Via command line either from the Director server or from the “event” system
(that is, the system that originally generated the event).
SNMP trap
Probably the most common method of forwarding events is via an SNMP trap.
Simply create a “Send an SNMP Trap to IP Host” action (Figure 3-17), and
specify the trap destination either as an IP address or a resolvable hostname,
and the SNMP community name.
49
Figure 3-17 SNMP trap action
Command line
Using a command line utility to send a message to an enterprise management
server is also straight forward to set up. Simply create a “Start a Program on the
Server” or “Start a Program on the event system” action, specify the command to
run with it’s arguments, and the working director for the program to run from
(Figure 3-18).
Figure 3-18 Command line action
50
3.6.2 Advanced System Management fan failure through UMS client
In this example a fan failure will be picked up by the ASM processor and passed
to the UMS client for forwarding as an SNMP trap. This is the same process by
which any system health event detected on a UMS client could be forwarded to
an enterprise management system (Figure 3-19). It is the same method
described in 2.2.1, “Method 1: Via SNMP from the client” on page 12.
Because UMS only runs on Windows platforms, this example does not apply to
non-Windows systems.
Figure 3-19 Sample UMS system health
As with the ServeRAID example, any system health events are automatically
sent to the UMS client for processing. Unlike ServeRAID, there is no need to
install the UM Server Extension. However if your system has an Advanced
Systems Management processor or Remote Supervisor Adapter, you will need to
install the proper device drivers.
51
Configure UMS to forward system health events to your enterprise management
system via SNMP as follows:
1. Configure UMS to forward system health events as SNMP traps. (For more
information see “System Health Monitoring” on page 35.)
2. Using the hostname or IP address of your enterprise management server that
is handling SNMP traps, configure the community name(s) and trap
destination(s) either via the UMS Web interface as shown in Figure 3-20, or
through Windows.
Figure 3-20 Configuring SNMP trap destination through UMS
With the failure of a fan, which we can see in Figure 3-21, the UMS client
forwarded an SNMP trap as directed. In this case, one of the trap destinations is
the IBM Director server (9.24.105.202), which logged the trap (along with the
event from the IT Director agent and the UMS client) as shown in Figure 3-22.
52
Figure 3-21 UMS System Health - fan failed
Figure 3-22 IBM Director event for UMS fan failure
53
3.6.3 Remote Supervisor Adapter system shutdown
In this section we will set up IBM’s latest systems management adapter, the
Remote Supervisor Adapter (RSA), to forward SNMP traps directly to an
enterprise management system. This is similar to 2.2.1, “Method 1: Via SNMP
from the client” on page 12 except this is coming from a dedicated systems
management processor. The RSA needs to be configured to forward alerts as
SNMP traps. In this example, we will be using the Web interface to configure the
RSA. For more information on configuring and use the Remote Supervisor
Adapter, see the IBM Remote Supervisor Adapter User’s Guide.
After logging into the RSA, click Network Protocols in the navigation menu to
open the window shown in Figure 3-23 to configure the SNMP protocol.
Figure 3-23 RSA Network Protocols window
To enable the RSA to alert via SNMP traps, do the following:
1. Enable the SNMP Agent.
2. Enable SNMP traps.
3. Set one or more community names (maximum of three).
54
4. For each community name, set one or more trap destinations (maximum of
three).
For this example we’ve used the community name public and the Director server
as the trap destination.
Now configure the RSA to forward alerts. Click Alerts to open the alert
configuration screen seen in Figure 3-24.
Figure 3-24 RSA alert destinations
Now click one of the recipients. In this case we’ve already created one named
SNMP. You will see the details of this alert recipient in Figure 3-25 on page 56.
55
Figure 3-25 RSA Remote Alert Recipient screen
For most implementations there are only a few fields you have to fill in:
1. Set the Status as Enabled.
2. Set a name for the recipient.
3. Set the Notification Method to either SNMP over LAN or SNMP over PPP.
4. Click Save.
For this example we are using SNMP over LAN. If you need to use a dial-up
connect, you would select SNMP over PPP and fill in the appropriate fields. See
the IBM Remote Supervisor Adapter User’s Guide for more information about
using PPP connections.
You should now be back at the main Alerts screen. We need to set what alerts
will be forwarded. Scroll down to the Remote Alerts section shown in
Figure 3-26.
56
Figure 3-26 RSA alerts to forward
In this example we’ve chosen to forward Power Off and Power On alerts. Now
when the system is powered off, the event seen in Figure 3-27 is sent to the
Director server.
Figure 3-27 RSA Power Off SNMP trap
57
3.6.4 APC UPS loss of AC power through PowerChute plus
The last example uses third-party software to forward an event. This uses the
same basic architecture described in 2.2.1, “Method 1: Via SNMP from the client”
on page 12. In this example we have setup APC’s PowerChute plus software on
one of our systems to monitor an APC UPS and send SNMP traps when events
occur.
We installed the PowerChute plus software and configured it to monitor the UPS
through a serial cable. See the PowerChute plus User’s Guide for information on
setting up PowerChute plus and configuring SNMP traps. Figure 3-28 shows the
SNMP trap as received by IBM Director.
Figure 3-28 PowerChute power failure trap
Notice that this trap looks different than the others. IBM Director comes with
many SNMP MIBs pre-compiled in its event handler, including the one for
PowerChute. The other traps were received from agents that had not had their
MIBs compiled. See the IBM Director User’s Guide for more information on
compiling SNMP MIBs.
3.7 Support
Documentation for upward integration beyond this redbook includes the
following:
򐂰 Chapter 5 “Upward Integration Modules” on page 87 of the UM Services
User’s Guide. This publication is on the IBM Director CD-ROM as
\docs\en\ums2_2ug.pdf.
58
򐂰 The readme file \Director\WIN32\INSTALL\EN\readme.htm on the IBM
Director CD-ROM (search for the heading “Integrating UM Services into
System Management Environments” in the file)
If you need technical support for IBM Director and other systems management
products, use IBM’s support Web site:
http://www.pc.ibm.com/support
From here you can:
򐂰 Download the latest software and fixes
򐂰 Participate in the Universal Manageability forums
򐂰 Send e-mail to IBM
3.7.1 Discussion forums
To participate in the forums, click Discussion Forums in the left-hand navigation
bar as shown in Figure 3-29.
Figure 3-29 Discussion forums link
If you don’t see this link, either set up a user profile or go directly to the following
URL where you can view the forums as a guest:
http://www7.pc.ibm.com/~UMS
59
From the Choose a Forum pull-down menu, select Universal Manageability.
There are a number of forums related to xSeries management products as
shown in Figure 3-30.
Figure 3-30 Discussion forums
3.7.2 Sending e-mail to technical support
Follow these steps to send e-mail to IBM regarding a technical support issue:
1. If you have not personalized your support page, select Systems
Management from the Browse the support site section of the page.
If you have personalized your support page, click Select Another Product
then select Systems Management from the Select your Product pull-down.
Figure 3-31 will appear.
60
Figure 3-31 Systems Management Support page
2. Click Online Assistant from the left-hand navigation bar.
3. Select the country or geography where you live and click Continue.
Figure 3-32 will open.
Figure 3-32 Systems Management Online Assistant
61
4. Select the product that most closely matches your situation (e.g. IBM Director,
UMS or UM Server Extensions) and click Go. Figure 3-33 will appear.
Figure 3-33 Online Assistant for IBM Director
5. If none of the entries addresses your problem, select None of the Above and
click Go.
6. Click Submit your question or problem online to the IBM HelpCenter,
which will open the form shown in Figure 3-34.
62
Figure 3-34 Electronic Submission form
7. Enter your details and your question and click Submit.
Note: Make sure the Country/Region, Geography and Brand are correct, as
these ensure your question gets routed to the correct IBM support center.
63
64
4
Chapter 4.
Tivoli Management
Environment
In this chapter we introduce the options to manage xSeries hardware via the
Tivoli Management Environment (TME).
We’ll cover:
򐂰
򐂰
򐂰
򐂰
򐂰
Alert forwarding
UMS monitoring from TME
Software distribution
Inventory
Adding Wake On LAN and other tasks to TME
After giving a brief overview of the Tivoli architecture (for more details refer to the
redbook An Introduction to Tivoli Enterprise, SG24-5495), we introduce the
integration topic from a planning stand point, covering what can and cannot be
done. In the second part of the chapter, we discuss the implementation details for
each topic. We then give some examples of alert forwarding options.
65
4.1 Introduction to Tivoli three-tier architecture
Tivoli is a suite of products intended for enterprise management. The Tivoli
Framework provides the basic system management services for
communications, presentation, security, and so on, that all Tivoli products will
use.
The basic unit of Tivoli functionality is the Tivoli Management Region (TMR), a
set or subset of network resources in your enterprise. Its structure is commonly
referred to as a three-tiered architecture. In a TMR you will have:
򐂰 At least one TMR server
򐂰 One or more Gateways
򐂰 Endpoints
The architecture is shown in Figure 4-1.
Plus Module
TEC
RDBMS
SWD
INV
DM
TMR
RIM
Gateway
Endpoint
Gateway
Endpoint
Endpoint
Endpoint
Figure 4-1 Tivoli three tier architecture
The TMR server provides facilities required to manage the environment. It
contains and controls the major portion of a distributed database that contains
information regarding the managed resources and objects used to manage the
environment. Also, it hosts the RIM object (RDBMS Interface Module), which is a
Tivoli Management Framework service that allows certain Tivoli applications to
store and retrieve data from a variety of popular relational database systems.
66
The gateway is a managed node that acts as a communication gateway for
Endpoints, the lower level clients.
The endpoint is the name that we use to refer to a managed machine. The Tivoli
software used by the Endpoint is called Tivoli Management Agent (TMA).
Each Tivoli product takes advantage of the base services provided by the
framework to perform its tasks.
Of the full set of TME products, the four that take advantage of the UM Services
Plus Module for Tivoli features are:
򐂰 Tivoli Enterprise Console (TEC) — This product lets you collect events from
various sources and react to them in an automated way, correlating events
coming from different sources.
򐂰 Tivoli Distributed Monitoring (DM) — Tivoli DM provides an efficient, reliable,
automated way to group and monitor key computing resources. It allows
automatic problem detection and proactive corrective actions.
򐂰 Tivoli Software Distribution (SWD) — Tivoli SWD allows you to deploy
software on an enterprise scale.
򐂰 Tivoli Inventory — This product allows you to collect hardware and software
information for your enterprise in an automated way.
In addition, a Plus Module is software developed by third parties to enable
management of new resources from the TME.
Tivoli Plus partners are third party vendors that integrate their products with the
Tivoli software, including TEC. Part of this integration is to send events from their
applications to the TEC.
A few examples of Tivoli Plus can be found at:
http://www.tivoli.com/bpprogram/listings/tivoliready
4.2 Planning for UM Services Plus for Tivoli
UM Services Plus for Tivoli is a Tivoli Plus Module that adds features to the
Tivoli Management Environment to improve the integration with xSeries and
Netfinity servers, and IBM clients including NetVista and Thinkpad.
Note: We use the terms UM Services Plus for Tivoli, Plus Module, and upward
integration module (UIM) interchangeably in this chapter.
Chapter 4. Tivoli Management Environment
67
The current version of the Plus Module is V1.3. It is officially supported on TME
Version 3.6.1, although we tested the Plus Module in the following environment
without experiencing any problems:
򐂰 TME Framework Version 3.7.1 with the following patches:
–
–
–
–
–
TMF-0001
TMF-0002
TMF-0003
TMF-0004
TMF-0007
򐂰 TEC Version 3.6.2
򐂰 DM Version 3.6.2
򐂰 SWD Version 3.6.2
򐂰 Inventory Version 3.6.2
Note: The UM Services Plus for Tivoli User’s Guide found on the product
CD-ROM states that the Plus module supports Tivoli TME Version 3.6.1 or
later. The Plus module is only supported on TME Version 3.6.1
The Plus Module provides the following additional features:
򐂰 Alert forwarding
With alert forwarding, TME can receive hardware related alerts from xSeries
servers and from client PCs via Alert on LAN. This feature requires a TEC
server in your environment.
򐂰 Monitoring the hardware-specific management software
This adds features for checking that UMS is properly running. These features
require Distributed Monitoring (DM) and TEC as optional components if you
want to enable event forwarding to it.
򐂰 Distributing hardware-specific management software
This adds the capability to distribute or update the hardware-specific agent,
such as UMS or UM Server Extensions, to monitor all major server
subsystems. This feature requires Tivoli Software Distribution (SWD).
򐂰 Adding inventory information regarding specific hardware
This lets you add hardware-specific information such as serial numbers to
Tivoli Inventory data. It requires Tivoli Inventory installed in the Tivoli
Management Region (TMR).
68
򐂰 Enabling Wake On LAN (WOL) and other tasks
This adds specific tasks to manage WOL-enabled hardware, and to shut
down and restart servers.
Each of these features requires specific Tivoli products to be available in TME.
Also, in order to obtain alert forwarding you need the class definition files
contained in the upward integration module package in a compressed format.
We recommend that you install the Plus Module in your TME environment to get
those files, and uninstall it afterwards if you are not planning to use any of its
functions. An alternative method to get those files is using the sapack utility
provided with Tivoli Framework, as we describe in “Using the sapack utility to
extract files” on page 88.
Prior to any installation, we recommend that you make a careful plan of what you
want to achieve. This is useful not only from a Tivoli standpoint, but for planning
your managed machine installation procedure as well.
In addition, there are a few limitations on the alerts that can get forwarded to TEC
in some cases. We discuss these in 4.2.1, “Alert forwarding” on page 69. We
recommend that you keep this in mind when planning your integration.
4.2.1 Alert forwarding
Alert forwarding is one of the most important features because Tivoli by itself is
not able to capture hardware-specific alerts.
There are several ways to get xSeries alerts forwarded to TEC:
򐂰
򐂰
򐂰
򐂰
򐂰
SNMP directly from UMS
SNMP via IBM Director
IBM Director via Tivoli internal event generation (wpostemsg, postemsg)
UM Services via Tivoli API calls
Windows Logfile Adapter
From a Tivoli standpoint, the first two methods are different flavors of SNMP
traps coming to TEC because both pass through what is called an SNMP
Adapter, a software component that collects SNMP traps and translates them
into TEC events, as shown in Figure 4-2 on page 70.
69
TEC SNMP
Adapter
Native
Tivoli
TEC Server
SNMP
IBM Director
Server
SNMP
Native
Director
Director
Support
Director
Support
UMS Client
UMS Client
Figure 4-2 Forwarding SNMP traps to TEC via an SNMP Adapter
From a managed machine standpoint, these methods have already been
described in 2.2, “Integrating into the enterprise” on page 12. Keep in mind that if
your servers are running a non-Windows operating system on your endpoints,
you don’t have the option to use UMS.
Note: When using IBM Director pass through, alerts coming from Microsoft
clusters can be forwarded to TEC. This can be a good alternative to
monitoring the operating system event log.
Sending SNMP traps to TEC
In order to get SNMP traps forwarded to TEC, a TEC SNMP Adapter is needed
on your network. This software collects all SNMP traps and translates them into
TEC events by means of configuration files. Two of these files are of particular
interest to our purpose:
tecad_snmp.cds
tecad_snmp.oid
Class Definition Statement file
The Object Identifier file
In order for an SNMP trap to be actually forwarded to TEC, it needs to have a
definition in those files; otherwise it will be discarded by the adapter.
The UM Services Plus for Tivoli provides a CDS and an OID file containing
definitions, but they contain details about SNMP traps generated only by:
򐂰 UMS
70
򐂰 ServeRAID Manager
򐂰 IBM Director Server
The adapter will therefore only be able to send the TEC server direct SNMP
alerts coming from these sources. All the remaining alerts, such as those
generated by Advanced System Management (ASM) processors or Remote
Supervisor Adapters (RSA), need to pass through the Director server, unless you
are willing to write new class definitions and alert mappings for the Tivoli SNMP
Adapter and TEC.
The possible alert flows without creating new classes are shown in Figure 4-3.
TEC SNMP
Adapter
Native
Tivoli
TEC Server
SNMP
SNMP
IBM Director
Server
UMS Client
SNMP
SNMP
Native
Director
Director
Support
UMS Client
Director
Support
ServeRAID
Manager
Fibre Channel
Manager
SNMP /
Native
Director
ASM / RSA
Figure 4-3 Actual SNMP alert forwarding options using Tivoli
Furthermore, in order for the TEC Server to process the alerts that the SNMP
Adapter has forwarded, a class definition file (BAsic Recorder of Objects in C, or
BAROC file) needs to be loaded. This file is available once you have installed the
UIM as we’ll describe in 4.3, “Installing UM Services Plus for Tivoli” on page 79.
Note: In such a configuration, the machine hosting the SNMP Adapter is a
Single Point of Failure (SPOF). You might want to setup multiple SNMP
Adapters to avoid missing alerts, but you’ll have to filter the duplicated events
that you will receive into the TEC Server.
71
Sending IBM Director alerts via Tivoli event generator
Tivoli provides a utility to generate TEC alerts either from a Managed Node (MN)
or Endpoint (EP), called wpostemsg, or from any non-TME machine, called
postemsg. Because IBM Director is able to execute programs as an event action,
it is possible to configure it to send an event to the TEC Server using the Tivoli
provided facilities. The wpostemsg utility requires a Tivoli agent because it uses
internal Tivoli communication methods. This allows what is called a connectionoriented communication, which provides encryption facilities and ensures that
the alert finally arrives to the TEC Server via caching methods. The postemsg
utility only uses an IP socket connection to the TEC server; this means that if the
network is overloaded and a few packets are dropped, no alert will get to the
TEC server.
Because Tivoli processes only alerts that belong to a defined class, you should
pay particular attention to the Tivoli command parameters.
In Figure 4-4 the logical alert flow is shown, both using wpostemsg (left) and
postemsg (right). We recommend you use the wpostemsg because it takes
advantage of Tivoli communication methods. Postemsg is more reliable than a
standard SNMP trap, which is based on UDP and does not give any guarantee
on delivery.
Using wpostemsg
Using postemsg
TEC Server
TEC Server
IP Socket
Native
Tivoli
postemsg
Tivoli MN or EP
wpostemsg
IBM Director
Server
IBM Director
Server
Native
Director
Director
Support
Native
Director
Director
Support
UMS Client
Native
Director
Director
Support
Native
Director
Director
Support
UMS Client
Figure 4-4 Alert flow via IBM Director and Tivoli using wpostemsg and postemsg
72
Sending alerts via Tivoli API calls
Alerts are detected by UMS that, when the TMA code is also installed on the
machine, use API calls that the endpoint exposes to forward its alerts to TEC via
the usual endpoint to server event flow.
The only prerequisite for this to work is installing the Adapter Configuration
Facility (ACF) on all Gateways. Once again, the class definitions for these alerts
have to be loaded into Tivoli TEC Server. This is very easy to accomplish
because the UIM installation adds a Tivoli task that configures this for you. We
describe these steps in 4.4.3, “Setting Up Tivoli API Calls” on page 93.
The alert flow is shown in Figure 4-5.
Tivoli
Gateway
Native
Tivoli
TEC Server
Native Tivoli
Managed
system
Tivoli
Management
Agent
Tivoli API
calls
UMS
Figure 4-5 Alert flow using Tivoli API calls
This is a completely internal Tivoli alert flow, but not all alerts coming from all
kinds of hardware can be forwarded (refer to 2.2, “Integrating into the enterprise”
on page 12).
Note: This method is available only with UMS version 2.2.
73
Windows Logfile Adapter
The Windows Logfile Adapter is a TEC Adapter that reads all events into the
operating system event log and, after proper formatting, sends them to the TEC
Server. You can take advantage of this adapter in either of the following ways:
򐂰 Use the adapter to read UMS events in the application log
This means that the same limitations for UMS API calls apply. You need to
modify the TECAD_NT.FMT file to get the UM Services alert because of a
different naming scheme.
In this case the alert flow is shown in Figure 4-6.
Managed
system
Write
Windows NT
Adapter
Tivoli
Management
Agent
Windows
Event Log
UMS
Event to
TEC
Read
Write
Figure 4-6 Tivoli NT Adapter reads events from the operating system event log
As you can see from Figure 4-6, all alerts pass through the Windows NT Log
file Adapter. This can be slower than using the UMS API calls as in Figure 4-5
on page 73. We recommend that you install the TMA on the managed
machine because the alert flow would be entirely under Tivoli control, and
delivery is therefore guaranteed.
򐂰 Modifying the adapter to read an IBM Director generated log file
This method consists of configuring IBM Director to write all its events in a
given format into a user defined file. Tivoli can read these files using the same
Windows NT Adapter modified accordingly. The alert flow is shown in
Figure 4-7. Modifying the adapter accordingly can be very time consuming
but very flexible at the same time. We do not describe this process in the
redbook.
74
IBM Director
Server
Write
Windows NT
Adapter
Tivoli
Management
Agent
Custom log
file
Director
Server
Event to
TEC
Read
Director
Support
UMS Client
Write
Native
Director
Director
Support
Figure 4-7 IBM Director server writes an event to a customized log file and the NT
Adapter forwards it to TEC server
Making a choice
You can use more than one of the methods described in 4.2.1, “Alert forwarding”
on page 69. However, you may receive multiple events for the same alert, not
necessarily all belonging to the same class. This adds complexity to your
enterprise procedures. We suggest that you carefully choose the best methods
of alert forwarding for your enterprise in order to get all the alerts you are
interested in while still being able to filter out duplicated events.
Once you know the limitations of each configuration, selecting the best methods
for your environment should be straightforward, based on which alerts you want
to get forwarded, what kind of hardware you have (LM78 sensor enabled or ASM
enabled), what your security issues are, and the amount of customization you
want or can perform. Refer also to 2.2, “Integrating into the enterprise” on
page 12 for further details on the kind of alerts that can be forwarded.
75
Important: Based on which of these alert methods that you are going to set
up, you may receive multiple instances of the same alert through different
sources. For example if you had a hard disk failure and you setup both
ServeRAID Manager SNMP traps and Director SNMP trap forwarding, you
would receive two alerts of different classes related to the same hard disk
failure.
You can set up a TEC rule to filter out duplicated instances of the same event.
This is not provided with the Plus Module, however.
4.2.2 Distributed Monitoring
Distributed Monitoring (DM) is a Tivoli product that allows monitoring of critical
resources in an enterprise environment. It is notified when something is wrong,
then takes automatic actions.
With the UMS Plus Module for Tivoli, two DMs are provided:
򐂰 The SNMP service status — This service is responsible for UMS to send
SNMP alerts.
򐂰 The UMS HTTP service status — This service is responsible for responding
to http request for UM Services
The monitors are not active after installation but have to be distributed. See 4.5,
“Setting up Distributed Monitoring” on page 100 for details.
4.2.3 Client software distribution
There are procedures and standards to follow when deploying large xSeries
installations in a pre-existing Tivoli environment.
In real-life cases, when the number of servers to install is big and all the servers
will have the same configuration, a setup kit is usually built. This kit performs
unattended setup for operating system, software, and utilities. In this situation
you probably won’t have the need to distribute a management client after the
operating system installation.
In other cases, the servers will serve different needs and will have different
software installed. This time skilled staff will probably proceed with the
installation and again you won’t need to distribute the software automatically to a
server.
Note: This is not the case with client machines, but these are out of the scope of
this redbook.
76
The typical situation in which you are likely to distribute management software to
a server automatically is in case of an upgrade to a new release. Usually the
Tivoli endpoint software is installed on any managed machine. You have several
options on what kind of client software to install, depending on the OS and the
hardware itself. See 2.4, “Design considerations” on page 21 for further details
on planning for integration.
When proceeding with a UMS installation you have three options to install the
endpoint software:
򐂰 Install it from the CD or put an unattended setup install in place.
When installing UMS directly you also have the option to install the Tivoli
Management Agent at the same time, selecting the corresponding check box,
as shown in Figure 4-8.
Figure 4-8 TMA checkbox in UMS installation
This option installs the Tivoli Management Agent version 40. It performs an
unattended installation of the software, using the TMASETUP.ISS response
file found in the Director CD-ROM. We recommend you do not use this
method because the response file contains settings that may not reflect the
policy for your enterprise. Furthermore this is usually handled by Tivoli
specialists who will choose the agent installation accordingly.
77
򐂰 Distributing it with Tivoli Software Distribution.
This is possible only if the managed machine is in the Tivoli environment
already. The UIM adds a package that performs a remote unattended install.
By default the SETUP.ISS found in the Director CD-ROM is used as the
response file.
򐂰 Using logon scripts.
This method performs an unattended installation of the product taking
advantage of Windows NT/Windows 2000 domain logon scripts. This method
is used mostly for client workstation installation, not for servers.
The choice depends on the environment and is beyond the scope of this book.
Important: The SETUP.ISS response file contains certain default settings.
Make sure these settings reflect what you actually need.
If you choose to install IBM Director support and UM Server Extensions as well,
you might do so but you’ll have to either modify the response file or build the
package yourself. This is discussed in 4.6, “Setting up Software Distribution” on
page 104.
If you are using a non-Microsoft operating system for your servers, you may not
always have the option to install the Director agent unattended. For instance the
agent for Novell Netware does not support unattended installation. Linux
installation is performed using the rpm command and might therefore be
automated using Tivoli as distributing software. Refer also to the Tivoli Software
Distribution User’s Guide for supported options.
4.2.4 Inventory
All xSeries hardware is equipped with SMBIOS, which is a DMTF
definitions-compliant BIOS that contains systems management information such
as the machine serial number and model number. Tivoli Inventory by itself is not
able to retrieve such data in the hardware layer even though it provides a DMI
scanner. Tivoli Inventory may be enhanced to include all this using one of two
methods:
򐂰 Using Management Information File (MIF) files data that are generated by the
CIM layer every time an inventory scan is performed and then imported into
Tivoli Inventory database.
򐂰 Using real time MIF files using the DMI layer. If using UMS, this means using
a utility cim2dmi that runs as a service. This can be very resource intensive,
so we strongly recommend you not use it because the only advantage is to
always have up to date information in your inventory. You might accomplish
78
this using static mapping as well, so the result is not worth the effort. For
further details on cim2dmi refer to “DMI support” on page 37.
Both these methods are described in the redbook Tivoli Inventory and Company,
SG24-2120 and require heavy customization. However, the Tivoli plus module
gives an automated task to accomplish the conversion from CIM to MIF files and
for importing data into the Tivoli Inventory database. This is a good starting point
to get data in a standard format and having inventory queries than can be
customized if needed. We describe this in 4.7.3, “Executing a hardware inventory
scan” on page 120.
In addition, the software inventory data is enhanced to recognize UM clients
installed on your network.
4.2.5 Wake on LAN and other tasks
The UMS Plus Module adds a few tasks that interface with UMS. These are:
򐂰 Reboot client.
򐂰 Shutdown client.
򐂰 Wake up client. In order for this to work, the managed machine has to be
WOL-enabled.
򐂰 Launch UMS. Simply launches a web browser connecting to the specified
machine on the UMS port.
These tasks can also be executed as jobs. The difference between tasks and
jobs is that while the task is seldom executed, the job is a repeated task on a
specific node that can also be scheduled.
4.3 Installing UM Services Plus for Tivoli
We now describe the steps we performed to get the Plus Module installed. For
further details, refer to the UM Services Plus for Tivoli User’s Guide on the
Director installation CD:
\Director\UM Services Plus For Tivoli\UM_Services_Plus.pdf
and to the UM Services User’s Guide in the DOCS directory on the same CD.
The Plus Module needs to be installed on the TMR Server and on the TEC
Server, if these are installed on different hosts. Also install it on any managed
nodes on which you plan to use the Plus Module from.
79
To install the Plus Module, proceed as for any Tivoli product install. Insert the
IBM Director 2.2 installation CD and open the Tivoli Desktop. Select Desktop >
Install > Product. Set the installation path to:
<cdromdrive>:/Director/UM Services Plus For Tivoli
Click Set Media & Close. The window in Figure 4-9 appears.
Figure 4-9 Plus Module installation
Install Plus Module Support (Link binaries) - 3.1.j first, and then UM Services
Plus Module for Tivoli, Version 1.3.
This installation adds the Tivoli Plus icon
to the Tivoli Desktop if this is the
first Plus Module you install in your environment. If you double click this icon you
will find an icon for each Plus Module component. Double clicking the UM
Services Plus for Tivoli icon produces Figure 4-10. The collection of icons
contains all the additions made by the installation of the Plus Module.
80
Figure 4-10 UMS Plus for Tivoli
You may not see all the icons, depending on which modules you have in your
environment. Those icons refer to standard Tivoli object types that need to be
established in the Tivoli Environment prior to the Plus Module installation. This
means that you will need to have Tivoli SWD, Inventory, DM, and TEC installed
before proceeding with the Plus Module installation if you want to use all the
available facilities.
The icons installed are:
򐂰 Launch UM Services — Launches a browser for connecting to UMS Web
Interface.
򐂰 Indicators for UM Service Monitors — This icon contains all the indicators
installed for Distributed Monitoring.
򐂰 Subscribers of UM Services — This is a Dataless Profile Manager whose
purpose is to contain all the machines that have UM Services installed. By
default it is empty, but can be populated using inventory queries results.
81
򐂰 UM Services Inventory — This is a Dataless Profile Manager that contains
profiles for hardware and software inventory.
򐂰 UM Services Inventory Queries — This is a collection for all the queries
added by the UIM.
򐂰 About UM Services — This icon performs a task to collect information about
the UIM version installed. Its output is shown in Figure 4-11.
Figure 4-11 Output for About UM Services task
򐂰 Install UM Services — This icon contains the File Package to distribute the
UMS client.
򐂰 Monitors for UM Services — This icon contains the Distribute Monitoring
profile for the UMS monitors.
򐂰 Prepare for UM Services Install — This task configures the file package for
distributing the UMS client.
򐂰 Reboot UM Services — This task reboots a UMS client.
򐂰 Setup TEC Event Server for UM Services — This task performs a set of
actions on the TEC Server in order to make it ready to receive xSeries related
alerts.
82
򐂰 Shutdown UM Services — This task shuts down a UMS client.
򐂰 Wakeup UM Services — This task sends a WOL magic packet to a selected
NIC.
4.4 Setting up alert forwarding
There are several methods for alert forwarding. We describe how to set up each
of them from a Tivoli stand point. For client side considerations refer to 2.2,
“Integrating into the enterprise” on page 12.
4.4.1 Setting up SNMP alerts
We know what alerts can be forwarded via SNMP using the facilities provided by
the Plus Module (see 4.2.1, “Alert forwarding” on page 69). Let’s see how to
configure the Tivoli environment to do this. The first thing to do is to install the
SNMP Adapter. There are two methods:
1. Distribute it using Tivoli Adapter Configuration Facility (ACF). As a
prerequisite the target machine needs to be a Tivoli endpoint.
2. Install it using the Setup utility on the TEC CD-ROM.
The difference is that the endpoint code on the SNMP adapter machine allows
what is called a connection-oriented communication; that is, the alert flows
through Tivoli mechanisms that ensure it is actually delivered and can be
encrypted. If no endpoint code is present, the alert is sent through an IP socket.
Refer to TME 10 Enterprise Console Adapters Guide for details.
Important: The Tivoli SNMP Adapter only listens on the UDP/162 socket. Be
careful not to have services conflicting with it on your machine.
Regardless of the method you are using, the SNMP Adapter CDS and OID files
need to be modified to include the new alert definitions appending the content of
the following files to the corresponding tecad_snmp files that already exist:
$BINDIR/generic_unix/TME/PLUS/UM_Services/UMStecad_snmp.oid
$BINDIR/generic_unix/TME/PLUS/UM_Services/UMStecad_snmp.cds
The existing tecad_snmp files can be found either in the adapter install directory
on the TMR Server or in the adapter installation directory on the endpoint itself.
Note: In order to get those files, you could also unpack them directly from the
IBM Director CD using the sapack utility provided with your TME Framework.
For further details refer to “Using the sapack utility to extract files” on page 88.
83
For example, updating the OID file can be done as follows (the CDS file changes
are similar):
From a bash shell:
Example 4-1 Modifying the OID file from a Bash prompt
cd $BINDIR/../generic_unix/TME/ACF_REP
cp tecad_snmp.oid tecad_snmp_UMS.oid
cat ../PLUS/UM_Services/UMStecad_snmp.oid >> tecad_snmp_UMS.oid
From a Windows NT Command Prompt:
Example 4-2 Modifying the OID file from a Windows command line
cd %BINDIR%\..\generic_unix\TME\ACF_REP
copy tecad_snmp.oid tecad_snmp_UMS.oid
type ..\PLUS\UM_Services\UMStecad_snmp.oid >> tecad_snmp_UMS.oid
If using the Adapter Configuration Facility, remember to change the SNMP
Adapter distribution file path to the newly created files in the Profile Manager
properties as shown in Figure 4-12.
Changing the SNMP
Adapter distribution
file path to reflect the
new OID and CDS
files.
Figure 4-12 Installation path change for distributing SNMP adapter through ACF
84
If you are installing the adapter through the stand-alone setup utility, you should
manually change the configuration files. Also, remember to save copies of the
files once you’ve changed them, as the files will be overwritten should the
adapter be reinstalled.
Now the SNMP Adapter is able to send traps to TEC, but the TEC Server still has
to be configured to be able to recognize these alerts. In order to do so, you need
to add the Class Definition File that contains the new events, known as baroc file,
to the current rule base (or create a new one).
Tip: There is a job that performs these steps automatically in the Plus Module.
This is described in 4.4.3, “Setting Up Tivoli API Calls” on page 93. We chose
to perform each step manually to control the changes to the TEC Server.
We chose to create a new rule base from the default one as follows:
1. Create a new directory called snmp_rb in %BINDIR%\TME\TEC\ to contain
all the rule base files.
2. From the Tivoli Desktop, double-click the EventServer icon and click Create
> Rule Base... specifying snmp_rb as a name and the directory we just
created as path, as shown in Figure 4-13.
Figure 4-13 Rule base creation to receive SNMP traps into TEC
3. On the rule bases window a new icon appears as shown in Figure 4-14 on
page 86.
85
Figure 4-14 The snmp_rb has been created
4. Copy the Default rule base content into the newly created one. To do this,
right click the Default rule base and select Copy from the popup menu. Set
the snmp_rb as a destination for the copy. All the class definitions contained
in the Default rule base are copied into snmp_rb.
5. Import the UMStecad_snmp.baroc file, which is available from the following
location after the UIM installation:
%BINDIR%\..\generic_unix\TME\PLUS\UM_Services\UMStecad_snmp.baroc
The same considerations for unpacking the .OID and .CDS files apply. See
“Using the sapack utility to extract files” on page 88.
To import the file in the rule base, right click the snmp_rb icon and select
Import from the popup menu as shown in Figure 4-15.
Figure 4-15 Select to import class definition in the rule base
6. Figure 4-16 appears. Scroll down to the Class Definitions area in the window.
86
Figure 4-16 Plus Module baroc file import into the snmp rule base
7. Check the Import Class Definition check box and select the path for the
UIM-provided baroc file. Be careful to select to import the class file after the
last definition file in the rule base to avoid unresolved definitions.
8. The last steps are to compile and load the rule base. To compile, right click
the snmp_rb rule base and click Compile from the popup menu. Figure 4-17
on page 88 appears.
87
Figure 4-17 Rule base compilation output
9. Click Compile. You should compile the rule base without any errors. A
successful compilation output is shown in Figure 4-17.
10.Click Close.
11.Right click the snmp_rb rule base and click Load. Restart the TEC server so
the changes take effect.
Now that TEC is ready to receive SNMP traps, we can finally configure the
sources of the alerts to send the traps to the machine running the SNMP adapter,
depending on the method you have chosen. For a detailed description on how to
do this, refer to UM Services User’s Guide, IBM Director User’s Guide, and
ServeRAID Manager User’s Guide.
For examples of alerts received, refer to 4.9, “Examples” on page 125.
Using the sapack utility to extract files
In production environments, you might not want to install the Plus Module, but
still need to get the files from the CD. In these cases we recommend that you
install the module, copy the files you need in a safe location and uninstall the
Plus Module from your environment. Remember to backup your TMR database
prior to any installation.
88
However, another option to unpack these files is using the sapack utility, which is
provided with the TME Framework. In order to do so, we checked which of the
PKT files contained the file we were interested in, viewing the content of the CFG
files found in the following directory on the IBM Director CD:
\Director\UM SERVICES PLUS FOR TIVOLI\CFG
We copied the corresponding file into a temporary directory and issued the
following command:
sapack -u FILE1.PKT
All the files will be unpacked into the current directory using the relative path
specified in the .PKT file.
4.4.2 Configuring IBM Director to generate Tivoli alerts
This scenario consists of a Director server receiving events from other machines
and generating alerts via the methods provided by Tivoli.
In order for this to work, you should configure an event action plan in the Director
server to execute the Tivoli utility passing the specific alert parameters.
Use wpostemsg or postemsg, depending on whether your server is a member of
the TMR. From an architectural standpoint we have already discussed the
differences between the commands in “Sending IBM Director alerts via Tivoli
event generator” on page 72. From a practical standpoint the only difference is
the parameters that the commands require. Refer to TME 10 Enterprise Console
Reference Manual for the details on the commands syntax.
There are three IBM Director actions to use:
򐂰 Start a program on the server — This action starts a program on the IBM
Director server.
򐂰 Start a program on the event system — This action starts a program on the
system that generated the event.
򐂰 Start a program on a System — This action starts a program on a specified
system.
The choice depends on the Tivoli Environment. We recommend you execute the
utility on the machine nearest to the TEC Server in order to generates less traffic
in your network.
89
As an example, to configure the alert on a specific system (the third option
above), do the following:
1. Open the Event Action Plan window in IBM Director Console, right click the
action Start a program on a System, and select Customize. The window in
Figure 4-18 appears:
Figure 4-18 Customize the Start a Program on a System action in IBM Director
In the System Address field, type the path from the Director server to the system
you want to run the command on.
In the Program Specification field, type your command line. For example:
wpostemsg -r CRITICAL -m "This is a Director Event" Netfinity_Director_Event_CRITICAL UM_SERVICES
This will generate an event of class Netfinity_Director_Event_CRITICAL
coming from the UM_SERVICES source.
In the Working Directory field, type the path where the program wpostemsg
resides.
Once you save the action and apply it accordingly to your event filter, TEC is able
to receive the traps. However, from a Tivoli standpoint there are a few
considerations.
90
The TEC Server does not process all the alerts it receives, but only those that
are defined in the baroc files. In the UIM supplied baroc file only a few IBM
Director classes are defined. From the UMStecad_snmp.baroc (see 4.2.1, “Alert
forwarding” on page 69 for details) it easy to see the classes that we have at our
disposal.
You can see one of the defined class in Example 4-3 on page 92.
Only IBM Director categories related to severity are defined. You can use these if
you don’t want to write new class definitions. For instructions on how to write new
class definitions refer to TME 10 Enterprise Console Rule Builders Guide.
The steps you need to accomplish are:
1. Define which alerts need to be forwarded to TEC, based on your company
policies
2. Define where the events are going to be filtered.
You have three options:
– Filter at the IBM Director level
– Filter at the Gateway level
– Filter at the TEC server level
Keep in mind that the lower level the filter, the more maintenance it requires.
3. Define the command line to use
The first two steps are dependent on your environment and are not covered in
this book.
As regards the command line to execute to post messages to Tivoli, we suggest
you use Event Data Substitution as much as possible in order to avoid rewriting
many actions for different filters. See the IBM Director online help for details on
how to use Event Data Substitution.
For example, if you want to forward an event to TEC every time a ServeRAID
disk fails, you can create a filter in IBM Director that collects all these events,
then create the Start Program on a System action issuing the following
command:
wpostemsg -r &rawsev -m "This is a ServeRAID Event" ServeRAID_DriveCritical UM_SERVICES
This command sends an event of class ServeRAID_DriveCritical to the TEC
Server. We used this class because it is already defined as you can see from the
baroc file reported in Example 4-3 on page 92. Also, we used as a severity the
&rawsev variable and not &sev because TME requires the severity to be all
uppercase (which is what &rawsev provides).
91
Example 4-3 TEC Class for a ServeRAID event
TEC_CLASS :
ServeRAID_EVENT ISA EVENT
DEFINES {
severity: default = WARNING;
};
END
TEC_CLASS :
ServeRAID_DriveCritical ISA ServeRAID_EVENT
DEFINES {
};
END
Using this method, the source of the alert is always the Director server. No
information about which machine presented the problem is forwarded. In order to
do so, you might designate a slot value as a container for the name of the failed
machine. The slot can be either a new one, and in this case you will have to write
a new class definition, or modify an existing one. If you are using a
Netfinity_Director_Event_CRITICAL class, you might specify any of the slots
found in the class definition in Example 4-4 for this purpose.
Example 4-4 Netfinity_Director_Event_CRITICAL class definition
TEC_CLASS :
Netfinity_Director_Event_CRITICAL ISA UMS_EVENT
DEFINES {
trapSeverity: STRING;
trapSenderName: STRING;
trapOriginator: STRING;
trapCategory: STRING;
severity: default = CRITICAL;
};
END
If you want the trapOriginator slot to contain the name of the system that
presented the problem you can issue the following command:
wpostemsg -m "This is a Director Event" -r CRITICAL trapOriginator=&system
Netfinity_Director_Event_CRITICAL UM_SERVICES
The syntax is the same as the previous example. The only addition is assigning
the trapOriginator slot the value of the keyword system that is specific to that
event. See the IBM Director online help for details on how to use Event Data
Substitution.
92
4.4.3 Setting Up Tivoli API Calls
Receiving alerts from UMS using Tivoli API calls is much easier to accomplish
because no customization is required on the client side. You only need to install
TMA and UMS on the client.
On the Tivoli side, however, you need to setup a rule base containing UMS
events class definitions. This can be easily accomplished either using the steps
described in 4.4.1, “Setting up SNMP alerts” on page 83 or using a job provided
by the Upward Integration Module. The icon for the job, Setup TEC Event
Server for UM Services, can be found in the UM Services Plus for Tivoli
collection and is shown in Figure 4-19.
Figure 4-19 Job to setup TEC Server
When you double click it, the window shown in Figure 4-20 on page 94 appears
asking you for the parameters to execute the job.
93
Figure 4-20 Parameters for executing the TEC Server configuration task
This job imports into the specified rule base, all the alert definitions contained in
the following baroc files:
򐂰 1. %BINDIR%\..\generic_unix \TME \PLUS \UM_Services
\UMStecad_snmp.baroc (as described on page 86)
򐂰 2. %BINDIR%\..\generic_unix \TME \PLUS \UM_SERVICES
\IBM_Corp__Monitors_for_UM_Services__V1_0.baroc (as described in page
103)
Also, it adds a rule that will make the TEC Server restart the SNMP and HTTP
services should distributed monitoring (if installed) report a failure of one of these
services (Refer to 4.5, “Setting up Distributed Monitoring” on page 100 for
details).
The specified rule base can either:
򐂰 Be created by the job itself. In this case, the rule base can be either empty or
cloned from an existing one (that is, the existing rule base content is copied
into the brand new rule base).
򐂰 Already exist. In this case, leave the fields marked with (if new) empty
.
Note: The rule base to clone must already exist; otherwise you will get an
error message. Rule base names are case sensitive.
Click Set and Close. The job output window appears. In Figure 4-21 you can find
the output windows for a successful execution of the job.
94
Figure 4-21 TEC Server customization job output window
Note: The job may take some time to complete. Let the job complete before
closing the output window; otherwise you will not be able to see if the
execution was successful.
Once completed, a new source of events called UM_SERVICES is added to TEC. To
check this you can either double click the Event Console icon to obtain a
graphic representation of all the event sources as in Figure 4-22 on page 96 or
issue the wlssrc command.
95
Figure 4-22 New source added by the Setup TEC Event Server for UM Services
Now that the TEC Server is configured, if a client has TMA and UM Services
installed, you will be able to receive all events coming from UMS.
Because UMS writes all its events to the NT/W2K Application Event Log, if you
enable the Windows Logfile Adapter as well you will get those errors twice,
although the events might belong to different classes. To avoid redundancy you
can set up a rule base to discard the duplicated events. This is not provided with
the UIM.
Restriction: This method does not work if using Windows NT Service Pack 6
or 6a on the Gateway due to a Tivoli restriction. Refer to the README.1ST file
in \Director\UM Services Plus For Tivoli on the IBM Director CD.
In 4.9.2, “Advanced System Management fan failure through UMS client” on
page 126, you can find an example of the use of API calls.
4.4.4 Setting Up the Windows Logfile Adapter
Setting up the Windows Logfile Adapter is a Tivoli related task. You can install it
using either:
򐂰 Tivoli Adapter Configuration Facility if the target machine is a Tivoli endpoint
򐂰 Installing it from the TEC CD-ROM if the target is a non-TME machine.
These methods are beyond the scope of this book. For details refer to TME 10
Enterprise Console Adapters Guide.
96
We mentioned in “Windows Logfile Adapter” on page 74 that you can use the
logfile adapter in two ways; either as it is or modifying it in order to read a Director
generated file. From a technical standpoint, the latter can be done but will be very
time consuming because you will need to define a mapping for each alert you
want to be translated. Describing the details on how to do this is beyond the
scope of this redbook.
If you want to use the adapter as it is, the simple installation is not enough to get
the UM Services alerts forwarded to TEC.
In fact, a UMS generated event looks like the following (Figure 4-23).
Figure 4-23 UM Services fan failure event in the Windows NT Application Log
If using the standard Windows Logfile Adapter, this event would be formatted
according to the definitions specified in the TECAD_NT.FMT file found in the
%LCF_BINDIR%\..\TME\TEC\adapters\etc directory. Because no other event
matches UMS, it is formatted as an NT_Base event, whose formatting rules are
as follows:
Example 4-5 Formatting rules for Windows Logfile Adapter
FORMAT NT_Base
%t %s %s %s %s %s %s %s*
hostname DEFAULT
origin DEFAULT
category $3
eventType $4
sid $5
sub_source $6
id $7
msg $8
-date1 $1
-date2 $2
97
date PRINTF("%s %s", date1, date2)
sub_origin PRINTF("%s",hostname)
END
These lines state that the event entry is treated as a single line in the event log
file. The first field is formatted as a time stamp (%t), the second field is formatted
as a string (%s), and so on. The content of each field is put into a variable
numbered in order, and the variable content is referred to as $<ordinal> where
<ordinal> is the order number. The event slots as defined in the baroc file will be
populated with the variable contents. For example, if an NT Event looks like the
following:
Jan 15 15:06:19 1998 0 Error N/A Service_Control_Manager 7024 The UPS service
terminated with service-specific error 2481.
the variables content will be set as in Table 4-1. The event slots will be populated
according to the FMT file.
The PRINTF commands is useful to join two fields into a single slot value.
Table 4-1 Variable content generated by the format file
Variable
number
Format
Content
Slot
1
%t
Jan 15 15:06:19
date field through the PRINTF
command
2
%s
1998
date field through the PRINTF
command
3
%s
0
category
4
%s
Error
eventType
5
%s
N/A
sid
6
%s
Service_Control_Manager
sub_source
7
%s
7024
id
8
%s*
The UPS service
terminated with
service-specific error 2481
msg
The UM Services Fan event we showed in Figure 4-23 on page 97 is received by
TEC through the Windows Logfile Adapter and looks like the following (we
obtained the event by issuing the wtdumprl command on the TEC Server host):
98
Example 4-6 UM Services Fan event output
NT_Base;hostname=nf5600tng;origin=9.24.105.239;category=0;eventType=Error;sid=N
/A;sub_source=UM;id=Services;msg='5 Fan Sensor 0 fell below threshold of 0 RPM.
The current value is 0 RPM.';date='May 09 09:37:49
2001';sub_origin=nf5600tng;END
### END EVENT ###
PARSING_FAILED~'Line 1: Value does not match type INTEGER!'
The event is discarded because the sub_source field is formatted as a single
string while in our event the sub source UM Services has a blank. The result is
that the id field is populated with Services, while it is supposed to be a number
according to the class definition.
In order to fix this, we defined a new formatting for a new event. First we defined
a new class appending the following in the tecad_nt.baroc file:
Example 4-7 Defining a new class
TEC_CLASS :
NT_UMS_Event ISA NT_Base;
END
This defines the new class NT_UMS_Event as derived from the already defined
NT_Base.
The next step was to define the new formatting for the class. What we did is
classify all events containing the string UM Services as NT_UMS_Event.
We added the following lines to the TECAD_NT.FMT file:
Example 4-8 Lines added to TECAD_NT.FMT
FORMAT NT_UMS_Event
%t %s %s %s %s UM Services %s %s*
hostname DEFAULT
origin DEFAULT
category $3
eventType $4
sid $5
id $6
msg $7
-date1 $1
-date2 $2
date PRINTF("%s %s", date1, date2)
sub_origin PRINTF("%s",hostname)
END
Figure 4-24 on page 100 shows the alert received in TEC server.
99
Figure 4-24 Event from the newly defined NT_UMS_Event class
4.5 Setting up Distributed Monitoring
To get alert forwarding via SNMP to work properly, the SNMP service must be
running on the client machine.
Likewise, to connect to the UM Services client via a Web browser, the UMS
HTTP service must be running on the client machine.
The UIM gives an easy method to check that these processes are always up and
running using Distributed Monitoring. Two monitors are added. You can see their
properties right clicking the Monitors for UM Services icon and selecting
Properties. The window in Figure 4-25 pops up.
100
Figure 4-25 Distributed Monitoring Profile properties for Monitors for UM Services
Table 4-2 summarizes their default behavior.
Table 4-2 Available distributed monitors and relative responses
HTTPCheck
SNMPCheck
What it does
Checks if the UMS http
server is available
Checks if the SNMP
subagent is available
Monitoring Interval
5 minutes
5 minutes
Popup
No
No
Tivoli Notice
No
No
TEC Events
Yes
Yes
Sentry Indicator
Yes
Yes
Automated Action
Restart via TEC
Restart via TEC
In Figure 4-26 on page 102 we show the Edit Monitor Window for the SNMP
service.
101
Figure 4-26 Edit monitor window
It is possible to modify the settings according to your needs; for example to
automatically restart the services through DM itself. The monitors are not active
by default, so you need to distribute them in order to check the status of the two
services.
One of the actions that these monitors do is to send a TEC event in case of
failure. In the rule base that the UIM created (see 4.4.3, “Setting Up Tivoli API
Calls” on page 93 for details), two actions are added:
򐂰 Reload UM Services SNMP subagent if two messages of severity CRITICAL
are received.
򐂰 Restart UM Services HTTP server if one message of severity CRITICAL is
received.
102
Also, a class for each of the events is added to TEC using the Setup TEC Event
Server for UM Services task described in 4.4.3, “Setting Up Tivoli API Calls” on
page 93. The classes are contained in the following file:
%BINDIR%\..\generic_unix\TME\PLUS\UM_SERVICES\IBM_Corp__Monitors_for_UM_Service
s__V1_0.baroc
that can also be imported in a rule base without installing the Plus Module as
explained in 4.4.1, “Setting up SNMP alerts” on page 83.
In order to see the status of a monitor, you will need to go to the Indicator
provided by the Plus Module:
1. Double-click the Indicators for UM Services Monitors icon in UM Services
Plus for Tivoli collection.
2. Double-click the Monitors for UM Services icon.
A window similar to Figure 4-27 will appear.
Distributed Monitor
indicator showing that the
HTTP service is down.
Figure 4-27 DM Indicator for SNMP and HTTP service unavailability
Also, if you have both DM and TEC in your environment, a TEC event will show
up similar to Figure 4-28 on page 104.
103
TEC event showing that the
HTTP service is down.
Figure 4-28 Distributed Monitoring alert received by TEC
4.6 Setting up Software Distribution
Distribution means installing new software or updating an older version of
software on a client in an automated way. Software Distribution (SWD) is
accomplished by running a UMS unattended setup remotely via Tivoli. If SWD
was installed prior to the Plus Module installation, a package for distribution is
ready to use.
Note: The officially supported version of SWD is 3.6.1. We ran SWD 3.6.2
without any problem. We also tested Version 4.0 and 4.1, but after installing
the Plus Module, no icon related to SWD would appear on the Desktop.
You can configure the package by double clicking Prepare for UM Services
Install in the UM Services Plus Module collection. This icon performs a task that
allows you to configure the File Package parameters such as the host that
contains the source files and the target directory. In order to configure which
UMS options are installed, the file \Director\win32\install\en\setup.iss on the
Director CD is used.
If you want to change any option, you can do so modifying the file on the source
host. You can refer to the SETUP.ISS file itself for details or to UM Services
User’s Guide. In Example 4-9, we show the portion of the file concerning the
options selected for installation.
104
Example 4-9 Lines regarding selected options for UMS installation from SETUP.ISS
;The following is a list of available options. If adding options in the section below,
;Component-count must be accurately indicated, and all options must be sequentially numbered,
;starting at zero. Available options: (note: Basic Services cannot be removed as an option)
;Component-x=0 Director Support
;Component-x=1 Web Based Access
;Component-x=2 System Health Monitoring
;Component-x=3 Web Based Remote Control
;Component-x=4 LANDesk(TM) Management Suite Integration
;Component-x=5 Tivoli Management Agent
;Component-x=6 SNMP access and trap forwarding
;Component-x=7 DMI Support
;Component-x=8 Help Files
;Add components below if desired. Recommended defaults are already set below.
[SdAskOptions-0]
Component-type=string
Component-count=5
Component-0=0
Component-1=1
Component-2=2
Component-3=6
Component-4=8
Result=1
Attention: If you use the SETUP.ISS file as it is, UMS will be installed on the
target system’s C drive and no Director Support option will be checked. If you
want to change that, you should manually modify the file to make sure all the
options that you need are included.
After the distribution is completed, you should remove the source files from the
host you distributed the package to. You might do this removing the package
using a Tivoli task, but we recommend you do not use this method because this
would be treated as a software uninstall in your history database. We’ll show two
alternatives in 4.6.3, “Removing the source files from the target machine” on
page 111.
4.6.1 Preparing the distribution package
We recommend that you copy all the installation files on a host hard disk drive to
be able to save your changes and to have better performance.
Tivoli SWD does the following:
1. Copies the files to the target host for installation
2. Runs the script UMS_FP_AFTER.BAT that launches the UMS unattended
installation reporting the result to SD and TEC, if installed.
105
Note: When copying files to the source host, if the absolute path of the source
files changes with respect to that on the CD, you will have to modify the script
file UMS_FP_AFTER.BAT that runs after the file package copy completes.
Let’s see the details on how to do this.
Once you have copied all the source files to the distribution host hard disk and
changed all the options in the SETUP.ISS file, double-click the Prepare for UM
Services Install icon. The window in Figure 4-29 pops up asking you for the data
shown in Table 4-3.
Table 4-3 Data for Prepare_for_UM_Services
SourceHost
Name of the machine that hosts the media where the
installation files reside
Source Path
Absolute path to the UM_SETUP.EXE file
Destination Path
Directory where the installation files will be copied to the target
machine as a temporary source during the installation process.
Figure 4-29 Prepare for UM Services install arguments window
We specified as a destination path drive E: because our operating system is
installed on this drive. Running this task multiple times does not create new
packages; it just updates the parameters of the current package. However, you
might create new software distribution profiles with all the options needed for
your enterprise.
Click Set and Close to proceed with the installation. This will only execute the
task that configures your distribution package. The output window in Figure 4-30
pops up, showing the task output.
106
Figure 4-30 Successful output for the Prepare for UM Services install task
The task that we just executed configured the package to copy the files to the
destination directory. You can check these settings by right clicking the File
Package Install UM Services in the UM Services Plus for Tivoli collection, and
selecting Open from the popup menu (see Figure 4-31).
Figure 4-31 File Package properties set by the task
107
As you can see in the Log Information Options section in Figure 4-31, the file
package will report its errors in a temporary directory on the Tivoli host. By
default, the package is not configured to reboot the machine on which you
performed the installation.
To reboot the machine, click Edit > Platform Specific Options > Windows NT
Options. Figure 4-32 appears. Click After Distribution and select to reboot the
machine.
Note: In the SETUP.ISS file an option is available to automatically reboot the
machine. You should not use it when distributing software with Tivoli because
the control flow needs to be done by Tivoli. Instead, use the Tivoli reboot
option as explained.
108
Figure 4-32 File Package OS Dialog
Make sure that the BAT/EXE/COM file name field is set to the correct path to the
UMS_FP_AFTER.BAT file, as otherwise no installation will take place. The path
should be the destination path you specified in the configuration task plus the
path starting from the root of the source files.
The most important step is to check that the file UMS_FP_AFTER.BAT is
properly configured. The default file content is shown in Example 4-10 on
page 110.
109
Example 4-10 ums_fp_after.bat file content
REM
REM
REM
REM
REM

CURDRIVE and CURDIR are passed from the filepack’s
prog_env variable into the environment space of
the endpoint so that this batch file will work
properly. They are derived from the Destination
Path that the user enters when configuring the filepack.
REM Below required for UM Services wmicore install to work.
IF NOT EXIST %SystemDrive%\TEMP mkdir %SystemDrive%\TEMP
set TMP=%SystemDrive%\TEMP
set PATH=c:\windows\command;"%PATH%"
%CURDRIVE%
cd "%CURDIR%"
REM If the UM Services FilePack profile was generated using
REM a 'Source Path' that pointed to the UM Services cd
REM mounted on a Unix machine at a mount point of /cdrom,
REM i.e. /cdrom/Win32/install/en, then uncomment the line below.
REM cd cdrom
cd Win32
cd Install
cd en
start /w um_setup.exe -s -SMS
start /w logParse.exe C:\Logs\umsinst.log
if errorlevel 1 goto fail
exit 0
:fail
"%LCF_DATDIR%"\cache\bin\%INTERP%\Tas\MANAGED_NODE\wseterr.exe -1
Notes about UMS_FP_AFTER.BAT:

The statement to add values to the PATH variable is necessary for proper
installation of the WMI core for Windows 95/98 machines, and should not be
modified. On Windows NT/2000 machines, it shouldn’t cause problems if you
leave it there.
Add a statement to change directory to the root where the win32 directory is
located. After the line:
REM cd cdrom
add your change directory line; in our example:
cd e:\temp\idcode\director
The result will be:
REM cd cdrom
cd e:\temp\idcode\director
110
cd Win32
cd Install
cd en
The -sms switch prevents UM_SETUP from closing before the installation is
complete in order to continue on to the next command in the batch file.
The file is intended to run using the setup.iss file found in the same directory.
If you want to customize your response file in order to have different response
files for different kind of hardware and configurations, you should specify
which file is to be used with the -silent switch. For example:
start /w um_setup.exe silent=Server_setup.iss -s -sms
4.6.2 Distributing the software
Now we’re ready to distribute the package to its subscribers. The default
subscriber is the Subscribers of UM Services Profile Manager, which is
Dataless and empty. You need to populate it with the endpoints you want to
distribute the package to. Once subscribed, right click the Install UM Services
icon and select Distribute.
Note: If this is not a first time distribution you can automatically populate the
UM Services Subscribers using inventory results. See 4.7, “Setting up
Inventory” on page 112 for details.
You can check if the software distribution completed correctly either through the
Tivoli log file (see Figure 4-31 on page 107) or through TEC if you have installed
the Software Distribution TEC Integration facility. You may also check the UMS
installation logfile, C:\LOGS\UMSINST.LOG.
4.6.3 Removing the source files from the target machine
The last step is to remove the source installation files from the target machine. In
the UM Services Plus Module for Tivoli User’s Guide, it is stated that you should
remove the package from the target machine. Refer to it for details on how to
remove the package. However, doing so would be interpreted as a software
uninstall and we do not recommend you remove the package, especially if you
installed the Software Distribution Historical Database product to keep track of all
installations and uninstallations in your enterprise.
You should, however, remove the source installation files, as these files are no
longer needed. You can use one of two methods:
1. Modify the ums_fp_after.bat file to remove all the source files from the
machine
111
You only need to insert the following line:
start /w rd e:\temp\idcode /s /q
before the exit 0 statement (see Example 4-10 on page 110) in order to
remove the package after a successful installation.
This would remove the directory IDCODE and all its content.
2. Use the During Commit button provided by the Software Distribution Profile
options (see Figure 4-32 on page 109).
You need to write a batch file to remove all the installation files. For example
you might use the same command line as for method number one.
Clicking the During Commit button will allow you to specify what file to
execute upon a commit command. This would allow you to check for proper
installation on the target machine prior to removing the software.
We recommend you use the second method because it takes advantage of the
SWD product features and everything would be controlled by Tivoli.
If you want to upgrade or distribute UM Server Extensions as well, you will have
to create a package, as one isn’t supplied. Because unattended setup is
supported, you can create a new package for distributing this piece of software
as well, creating a batch file similar to ums_fp_after.bat. Similarly, the response
file for this unattended installation is UMServerExtensions\win\setup.iss on the
IBM Director 2.2 CD-ROM.
Consult the SETUP.TXT help file in the same directory for details on running a
silent installation.
4.7 Setting up Inventory
To insert new inventory information into a Tivoli Inventory database, the first thing
to do is to add the new tables to hold the data. The Plus Module installation also
creates a script for each supported database in directory:
%BINDIR%\..\generic_unix\TME\PLUS\UM_SERVICES.
The files are named ums_<databasename>_schema.sql, where
<databasename> is the RDBMS installed on your machine. Scripts are provided
for all the supported RDBMS (Oracle, SQL Server, Sybase, DB2).
We set up our TME using IBM DB2 UDB version 6.1. The script has to be
executed in the database context, so from a DB2 command line (not an
operating system command prompt) we typed:
db2 connect to inv user tivoli using <password>
db2 -t -f D:\tivoli\bin\generic_unix\TME\PLUS\UM_SERVICES\ums_db2_schema.sql
112
where <password> is the password to access the inventory database.
For script execution into other RDBMS, refer to that product’s user’s guide.
Once the database tables have been updated, we are ready to insert new data.
To do so, two profiles that are preconfigured to collect hardware and software
information are added to the UM Services Inventory Profile Manager by the Plus
Module. The prerequisite for this is that Inventory must be installed on your TME
prior to the Plus Module installation.
Note: The Tivoli Inventory version supported by the Plus Module is 3.6.1. We
tested version 3.6.2 without any problem. We also tested version 4.0, but no
icon would appear on the Desktop.
The software profile can also be used to automatically populate the UM Services
Subscribers Profile Manager. Also, in the Plus Module collection you can find a
few queries already configured to select data from the database tables. If you
double click the UM Services Inventory Queries icon, Figure 4-33 appears.
Figure 4-33 Query library installed by UM Services Plus for Tivoli
113
The queries are:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Alert On LAN Settings
Asset ID
BIOS Details
CIM
Cache
DMI
Geographic Information
IBM UM Services
IP Network Configuration
IPX Network Configuration
Installed UM Services
Lease Information
Memory Details
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Network Details
Personalized Data
Port Connectors
Processor Details
SNMP Agent Configuration
Serial Number Information
System Board Configuration
System Enclosure
System Slots
User Details
Video Details
Warranty Information
Note that all queries refer to hardware-related data. You’ll be able to retrieve data
using these queries only after you have scanned all your systems.
4.7.1 Executing a software inventory scan
Double click the UM Services Inventory Profile Manager in the UM Services
Plus for Tivoli collection. Two Profile Managers are present:
򐂰 UM Services PC HW Scan
򐂰 UM Services PC SW Scan
The UM Services PC SW Scan detects if UM Services is installed by checking
the presence of the UMSAGENT.MOF file. If this file is one of those detected by
a standard inventory scan that are classified as unknown in the Inventory
database, then Inventory assumes that UMS is installed on the machine.
This is accomplished by adding a view to the database, as shown in these lines
from the file UMS_DB2_SCHEMA.SQL:
Example 4-11 Creating a view of all systems with UM Services installed
create view UMS_VINST_UMS
as
select
COMPUTER_SYS.HWARE_SYS_ID,
COMPUTER_SYS.TME_OBJECT_ID,
COMPUTER_SYS.TME_OBJECT_LABEL,
INST_UNKNOWN_FILE.INST_FILE_NAME,
INST_UNKNOWN_FILE.INST_FILE_SIZE,
INST_UNKNOWN_FILE.INST_FILE_PATH,
INST_UNKNOWN_FILE.INST_FILE_DATE,
114
INST_UNKNOWN_FILE.INST_FILE_TIME
from
COMPUTER_SYS,
INST_UNKNOWN_FILE
where
COMPUTER_SYS.HWARE_SYS_ID =
INST_UNKNOWN_FILE.HWARE_SYS_ID
and
upper(INST_UNKNOWN_FILE.INST_FILE_NAME) = 'UMSAGENT.MOF';
insert into QUERY_VIEWS (VIEW_NAME) values ('UMS_VINST_UMS');
The settings for the software scan profile can be checked by right clicking the
Profile and selecting Customize... Figure 4-34 appears.
Figure 4-34 UM Services PC SW Scan inventory Profile Manager details
To execute the software inventory, you need to subscribe all your managed
machines to the UM Services Inventory Profile Manager (no subscriber is added
by default), then distribute the profile. There’s no way to get the subscriptions in
an automated way.
Once the software inventory scan has been performed, you can query the
database to know which machines have UM Services installed. UM Services is
not known to Tivoli Inventory because it is not registered in the known
applications, so the only query able to tell if UM Services is installed is the
Installed UM Services in the UM Services Inventory Queries library. Right click
it and select Run Query. You will get the result shown in Figure 4-35 on
page 116.
115
Figure 4-35 Machines with UMS installed from Inventory
Note: Our query results show two instances of UMS installed on the same
machine. This is because we installed two operating system environments on
the machine for testing purposes and each instance had UM Services
installed. Because the software scan is based on file detection, it was found
twice.
A way to make UM Services detected by Inventory would be to add the
UMSAGENT.MOF file to the list of signatures. To do so, you just need to identify
the UMSAGENT.MOF file size, then enter the following command on the TMR
server:
wfilesig -a -n UMSAGENT.MOF -s 2892 -d "UM Services" -v "2.2"
This will add the UM Services version 2.2 entry to the list of signatures that Tivoli
Inventory uses to scan the software.
As a result, UM Services will be available in the software inventory queries. In
Figure 4-36 we show a sample query that we created.
116
Figure 4-36 Query created to select all the machines with UM Services installed
Figure 4-37 shows the query results.
Figure 4-37 Query results showing all the machines with UM Services v 2.2 installed
117
4.7.2 Populating the UM Subscribers Profile Manager
Based on the software scan, it is possible to populate the subscribers for the
Subscribers of UM Services Profile Manager.
If you double click the corresponding icon in the UM Service Plus for Tivoli
collection, you will get the subscribers window (Figure 4-38).
Figure 4-38 Default Subscribers for Subscribers of UM Services Profile Manager
To subscribe all the clients that have UMS installed to it, click the Query button.
Figure 4-39 appears.
118
Figure 4-39 Query for automatic population
Double click UM Services Inventory Queries to get the list of queries and select
Installed UM Services. Clicking the Execute button will put the machines
resulting from the query in the subscribers list as shown in Figure 4-40 on
page 120.
119
Figure 4-40 Subscribers list after automatic population
Click Set Subscriptions & Close to commit your changes.
You might also populate your profile manager manually, but because its purpose
is to contain the list of all managed endpoints that have UMS installed, an
automated method can be very convenient.
4.7.3 Executing a hardware inventory scan
Once your Subscribers for UM Services Profile Manager has been populated
either automatically or manually, execute a hardware inventory scan. This scan
can be done only if UMS is installed and running on the target machine.
The UM Services PC HW Scan is an inventory profile ready for use, and can be
found in the UM Services Inventory Profile Manager. This scan is based on a
script very similar to the TMEINV.BAT script you can find in the UM Services
home directory in the inventory directory. The inventory task executes the script
that converts CIM data to MIF files using the cim2mif utility. Tivoli will read these
MIF files and populate the inventory database tables accordingly. If you right click
the profile and select customize, you will see the details as in Figure 4-41.
120
Figure 4-41 UM Services PC HW Scan default settings
The script content is shown in Example 4-12.
Example 4-12 Content of the script file executed by Tivoli Inventory
%UMS_DRIVE%
@cd "%UMS_HOME%\inventory"
IF NOT EXIST "%UMS_HOME%"\jre\bin\jre.exe GOTO jview
@..\jre\bin\jre.exe -D:WINDIR="%WINDIR%" -cp
.\cim2mif.jar;"%UMS_HOME%\httpserv\cimdre.jar";"%UMS_HOME%\httpserv\cimxml.jar";"%UMS_HOME%\httpserv\guit
ools.jar";"%UMS_HOME%\httpserv\cimfac.jar";"%UMS_HOME%\httpserv\cimwmi.jar";"%UMS_HOME%\httpserv\cimcmn.j
ar" com.ibm.sysmgt.cim.cim2mif.cim2mif /TME c:\"%UMS_HOME%\inventory\dmi2tiv.exe" @dmi.lst
exit 0
:jview
@jview -d:WINDIR="%WINDIR%" -cp:a
.\cim2mif.jar;"%UMS_HOME%\httpserv\cimdre.jar";"%UMS_HOME%\httpserv\cimxml.jar";"%UMS_HOME%\httpserv\guit
ools.jar";"%UMS_HOME%\httpserv\mswmi.jar";"%UMS_HOME%\httpserv\xml4j2.jar";"%UMS_HOME%\httpserv\xml4j.jar
" com.ibm.sysmgt.cim.cim2mif.cim2mif /TME c:\"%UMS_HOME%\inventory\dmi2tiv.exe" @dmi.lst
121
The script takes advantage of the cim2mif utility and does the following:
򐂰 For each *.script.inv file found in the %UMS_HOME%\inventory directory
generates a new GROUP and TABLE in the output MIF file
򐂰 Generates an SQL file that can be used to build a table and view for each
database supported by Inventory
򐂰 Generates a shell script to build a Tivoli Inventory query
Note that the /TME switch is used to optimize the output files for a Tivoli
Environment.
After executing this script, you should
1. Add the tables to your database running the output sql scripts
2. Run the MIF file scan
The Plus Module makes all these tasks easier since all is done automatically: the
database tables are already built running the SQL script as we discussed in 4.7,
“Setting up Inventory” on page 112. Every time a scan is launched, the script is
executed and Tivoli scans the resulting files to update its tables. The files to be
scanned are specified in the Custom Mif Files to be Read section in Figure 4-41
on page 121. They are, by default:
򐂰 umativoli.mif
򐂰 umsinv.mif
The HW Scan profile can be used as it is for each database except for DB2. In
fact, DB2 has a few limitations in the name lengths that need to be reflected in
the table names. cim2mif however creates MIF files specific for DB2. They are:
򐂰 umativdb2.mif
򐂰 uminvdb2.mif
Since in our environment inventory is using DB2, we modified the profile to read
the DB2 related files as shown in Figure 4-42.
122
Figure 4-42 UM Services PC HW Scan profile customized for DB2
Note: The file names for the inventory scan have to be specified using their
absolute path name. The umativoli.mif or umativdb2.mif file will be generated
on the UMS installation drive, so make sure you specify the correct path.
Otherwise, you’ll get an error message when collecting inventory data.
Click Save & Close to proceed to the scan.
After distributing the profile for the hardware scan, you may want to verify that the
collection was done correctly either by running one of the preconfigured queries
(see Figure 4-33 on page 113) or running a custom query as in Figure 4-43 on
page 124. We chose to query for the system model number and serial number
for the UMS machine.
123
Figure 4-43 Custom query results for Serial Number
4.8 Setting up Wake on LAN and other tasks
When the upward integration module is installed, four tasks are added:
򐂰
򐂰
򐂰
򐂰
Reboot UM Services
Shutdown UM Services
Wakeup UM Services
Launch UM Services
The Launch UM Services task can be run only from the machine specified in the
Local Machine field in the Launch UM Services@local machine icon.
Furthermore, all prerequisites for opening a UMS Web interface must be met as
specified in the UM Services User’s Guide. For details on requirements for
servers running a Unix operating system, refer to the UM Services Plus for Tivoli
guide.
Each task is run just like other Tivoli tasks. While the Reboot and Shutdown
tasks talk directly to UM Services on the client, the Wakeup task sends the WOL
“magic packet” to the client NIC. For this reason it has to be executed on the
machine where the Plus Module was installed.
Important: The default target for all the tasks is the machine on which the
Plus Module was installed. Make sure that the current target is set to the
machine you want to perform the action on.
124
Note: In order to make the Wakeup task work, you need a WOL enabled
target machine. The target should be scanned with the hardware scan profile
at least once prior to executing the task because this relies on the NIC MAC
address information.
4.9 Examples
In this section we will continue the examples that we discussed in 3.6,
“Examples” on page 46.
As you will see, a few of them need some customization that is not performed by
the Plus Module. The easiest way to get non-defined alerts is passing them
through an IBM Director Server. However, all alerts will be identified as belonging
to the same class. With some additional effort you can define your own classes
to decode SNMP traps coming from different sources.
In this section we’ll show how to configure Tivoli to get a disk drive failure through
an IBM Director server. For client and Director server configuration refer to 3.6.1,
“ServeRAID hard disk failure through Director server” on page 47.
In order for a TEC server to get an alert from the Director server, you should
configure it as we showed in 4.4.1, “Setting up SNMP alerts” on page 83. This
would allow the TEC server to recognize all SNMP traps coming from the
Director Server.
Pulling out a disk drive from a client (the TMA is not needed on either the client or
the server) would generate an SNMP trap that goes through the SNMP Adapter
to the TEC server. In Figure 4-44 on page 126 we show the event received in the
TEC Console. The source of this event is SNMP.
125
Figure 4-44 Disk drive failure alert received in the TEC Console
In 4.4.2, “Configuring IBM Director to generate Tivoli alerts” on page 89, we also
described how to configure the Director server to send an event to the TEC
Server via the wpostemsg utility.
There are two possible ways to get a fan failure alert from UMS client into Tivoli:
򐂰 Via a UMS generated SNMP trap. There’s no need for the TMA client on the
managed machine. See 4.4.1, “Setting up SNMP alerts” on page 83 for
details.
126
򐂰 Via UMS API calls. The managed machine will need the TMA code installed.
See 4.4.3, “Setting Up Tivoli API Calls” on page 93 for details.
We now show the TEC events we received.
In Figure 4-45 the SNMP fan failure event is shown. Note that the source of the
event is SNMP.
When the alert is an
SNMP trap, the class is
UMS_FanOutOfOrder
Figure 4-45 SNMP trap details for a fan failure event
In Figure 4-46 we show the event generated via a UMS API call. As you will
notice, the source of the alert is UM_Services because it was directly generated
by UMS.
When the alert comes
from the UMS API, the
class is IBMPSG_FanEvent
Figure 4-46 Fan failure event generated by UMS via API calls
127
Note that the classes for the two events are different. If the alert is an SNMP trap,
its class is UMS_FanOutOfOrder, whereas if the alert is generated via an API
call, its class is IBMPSG_FanEvent.
For this alert no description in the BAROC, CDS, and OID files that we discussed
in 4.4.1, “Setting up SNMP alerts” on page 83 is provided. If you want to get an
RSA alert into TEC, you have two options:
򐂰 Pass through a Director Server
This is described in 2.2.3, “Method 3: Via the IBM Director server” on
page 15.
The drawback is that all alerts will be received as belonging to the same
class, Netfinity_Director_Events, and will have an unknown severity. No field
is representative for the event except msg, which contains the Enterprise
specific field number, as you can see in Figure 4-47. However this number
can be hard to interpret. On the other hand, this method requires no
customization.
Figure 4-47 SNMP trap received from an IBM Director server in the TEC Server
128
򐂰 Customize the SNMP adapter CDS and OID files to include descriptions
for the RSA traps you want to decode.
This method is more time consuming, but can be very flexible because you
can define all the alerts you are interested in, creating new classes and
descriptions. In this case the alert forwarding method would be the same
described in 3.6.3, “Remote Supervisor Adapter system shutdown” on
page 54.
For this method to work, we customized the definition files based on the MIB
file found on the RSA Configuration CD-ROM. In Example 4-13,
Example 4-14, and Example 4-15 on page 130 we report the modifications
we did to the CDS, OID, and baroc files, respectively, in order to describe the
SNMP trap fields for RSA.
FTP
Available for download via FTP: The modifications to the CDS, OID, and
baroc files can be downloaded via FTP. See Appendix C, “Additional
material” on page 241 for details.
The idea is to map all SNMP traps that have an OID starting with
1.3.6.1.4.1.2.6.158 and classify them as an RSA_Trap. Furthermore, we
chose to collect the information in the attribute
1.3.6.1.4.1.2.6.158.2.1.1.9, mapped as ibmRemoteSupEventDescr, and
insert it into the msg slot of the event. We used this attribute because it
contains a string describing the kind of alert; for example, if the system was
started up or shut down. You might want to choose other identification
mechanisms according to your company policies and populate other event
slots accordingly.
Example 4-13 Class definition for an RSA trap in the CDS file
CLASS RSA_Trap
SELECT
1: ATTR(=,$ENTERPRISE), VALUE(PREFIX, "1.3.6.1.4.1.2.6.158");
2: ATTR(=,"ibmRemoteSupEventDescr");
FETCH
1:IPNAME($AGENT_ADDR) ;
MAP
hostname = $F1;
msg = PRINTF("Warning: %s RSA TEST",$V2);
END
Example 4-14 Mappings for RSA object identifiers in the OID file
"ibmRemoteSupEventDescr" "1.3.6.1.4.1.2.6.158.2.1.1.9"
129
Example 4-15 Class definition for an RSA trap in the baroc file
TEC_CLASS :
RSA_Trap ISA EVENT
DEFINES {
};
END
Figure 4-48 shows the resulting event in the TEC Console.
Figure 4-48 RSA SNMP trap decoded as RSA_Trap event
To receive an SNMP trap directly from PowerChute plus, the same
considerations from 4.9.3, “Remote Supervisor Adapter system shutdown” on
page 128 apply.
130
The Plus Module does not provide a baroc, CDS, or OID file to decode the alert.
Therefore you have two methods to get this kind of alert in the TEC Console:
򐂰 Passing through an IBM Director Server
򐂰 Customizing the baroc, OID, and CDS files to include the trap mapping to a
Tivoli event
In Figure 4-49 we show what a trap would look like if passing through an IBM
Director. Again, its severity is UNKNOWN and only the content of the msg field
identifies the alert. Again the identifier is not decoded.
Figure 4-49 PowerChute plus SNMP trap through an IBM Director server
In order to customize the files to get the PowerChute plus SNMP trap description
in Tivoli, we did the following:
1. Add the lines in Example 4-16 on page 132 in the snmp baroc file
2. Add the lines in Example 4-17 on page 132 in the snmp OID file
3. Add the lines in Example 4-18 on page 132 in the snmp CDS file
FTP
Available for download via FTP: The modifications to the CDS, OID, and
baroc files can be downloaded via FTP. See Appendix C, “Additional material”
on page 241 for details.
131
Example 4-16 Class definition for an SNMP trap coming from PowerChute plus in the
baroc file
TEC_CLASS :
UPS_Event ISA EVENT
DEFINES {
};
END
Example 4-17 PowerChute Plus object identifiers in the OID file
"EventType" "1.3.6.1.4.1.318"
Example 4-18 PowerChute Plus SNMP trap mapping in the CDS file
CLASS UPS_Event
SELECT
1: ATTR(=,$ENTERPRISE), VALUE(PREFIX, "1.3.6.1.4.1.318");
2: ATTR(=,"EventType");
FETCH
1:IPNAME($AGENT_ADDR) ;
MAP
hostname = $F1;
msg = PRINTF("Warning: %s UPS Event",$V2);
END
In Figure 4-50 we show the event that was forwarded to the TEC Console. As you
can see, the msg slot contains information on what kind of alert this is. Also, its
class is specific for UPS events.
132
Figure 4-50 Loss of AC power SNMP trap decoded as UPS_Event
4.10 Conclusion
In this chapter, we showed how to manage your IBM xSeries servers using Tivoli
Management Enterprise and how to take advantage of IBM Director or UMS
additional functions in this environment.
We showed how to:
򐂰
򐂰
򐂰
򐂰
򐂰
Forward alerts to Tivoli TEC
Use Tivoli DM to monitor UMS
Deploy UMS installations using Tivoli SWD
Add UMS information to Tivoli Inventory
Add more tasks to the Tivoli Desktop
This can be done either using the UM Service Plus Module for Tivoli or
customizing a few files. Also, we showed some real life examples on forwarding
different kind of alerts.
133
134
5
Chapter 5.
Microsoft SMS
In this chapter we describe how UM Services integrates into a Microsoft Systems
Management Server 2.0 environment. We’ll look at what this integration can and
cannot do, how the information propagates between the systems, and show
some examples of alert forwarding.
This chapter discusses the following:
򐂰 Installation options
򐂰 Inventory
򐂰 Alerting
򐂰 Software distribution
򐂰 Alerting examples
135
5.1 Prerequisites
IBM Director v2.2 includes upward integration modules for Microsoft SMS 1.2
and 2.0. While the method of communication between UMS and SMS differs
greatly between the two version of SMS, the basic functionality of inventory,
software distribution and alerting provide the same information to both products.
Note: This chapter covers the Director integration with SMS 2.0. SMS 1.2 is
not covered here.
Since SMS only monitors Windows-based clients there is no need to integrate
the IT Director agent which is used for non-Windows clients. (For more
information on IBM Director clients, see 2.1.1, “Client” on page 8.)
In order to install the UIM for SMS, you will need:
򐂰 An existing SMS site or sites
򐂰 Existing SMS clients that are supported by UMS (see the UM Services User’s
Guide for UMS system requirements)
򐂰 Administrative privilege for the SMS site server for those clients
5.2 Capabilities
Both Microsoft SMS 2.0 and the IBM Director client use the CIM protocols. This
means that the SMS client can query the CIM classes that the UMS client
provides to get additional information. This level of integration allows UMS to
provide SMS with very detailed inventory information. Also, the software
distribution tools in SMS allow the UMS client to be distributed to SMS clients
relatively easily.
Unfortunately alerting is less full featured. SMS cannot listen for SNMP traps,
and Microsoft does not provide a command line tool to send status messages to
the SMS server. This means that only the UMS System Health events can be
forwarded to SMS and not the much more detailed Director monitoring or third
party monitoring capabilities.
136
5.3 Installation options
The most logical method of integrating IBM Director into a Microsoft SMS
environment is as described in 2.2.2, “Method 2: Via the enterprise management
agent on the client” on page 14. The reasons for this are three-fold:
򐂰 SMS is not an network management server (NMS), and has no facility to
receive and process SNMP traps from a UMS client, the Director server, or
any other element manager.
򐂰 With the installation of the upward integration module, CIM notifications
generated by the UMS client will be translated into SMS status messages, but
there is no process for the Director server to forward messages to an SMS
server from one of its clients.
򐂰 In order for SMS to maintain it’s inventory and distribute software, there must
be an SMS agent on each client.
Also, SMS is used only to manage Windows-based systems. Because there is no
need to integrate clients with non-Windows operating systems (for example,
NetWare or Unix) into SMS, there is no reason to use the methods described in
2.2.3, “Method 3: Via the IBM Director server” on page 15 to support stand-alone
IT Director agents.
Installing the UIM
Start to install the SMS UIM using the procedures discussed in
“Workgroup/Enterprise Integration” on page 32. Click SMS Upward Integration
and Figure 5-1 on page 138 appears.
Chapter 5. Microsoft SMS
137
Figure 5-1 Select UIM integration components
Select Console Only if you are only updating an SMS Administrator’s Console.
In this example, we selected Server and Console because we are updating an
SMS site server.
You then see Figure 5-2 where you select the location to install upward
integration support.
138
Figure 5-2 Where to install the upward integration support
You are then asked for the name of the SMS server you are going to install on. At
this point, the site is shut down and updated as shown in Figure 5-3.
Note: It is important that you let this update complete without interruption or
the SMS site may become unstable and you may experience problems trying
to reinstall the UIM.
Figure 5-3 SMS site shutdown and update
139
Once the update is complete and the site restarted you will receive the
confirmation window shown in Figure 5-4.
Figure 5-4 UIM installation complete
5.4 Inventory
There is a large amount of inventory information that UMS makes available to the
SMS client. Figure 5-5 shows a side by side comparison of the data collected for
a Netfinity 4500 before and after the installation of UMS and the upward
integration module.
The UIM enables SMS to gather inventory data directly from the UMS client, or
via MIF files generated by DMI compliant applications.
140
Indicates added or
removed resources
Figure 5-5 Resources available after installing UMS and the upward integration module
141
5.5 Alerting
To a certain extent, alerting messages can flow both ways between a UMS client
and the SMS system. While the functionality is different, the strengths of both can
be leveraged in your overall management plan.
5.5.1 UMS alerts going to SMS
Installing UIM in your SMS environment will allow CIM notifications generated by
UMS to be forwarded to the SMS server as SMS status messages. Figure 5-6
shows an SMS status message received from a UMS client noting that a chassis
intrusion has been detected.
Figure 5-6 SMS status message from UMS
If you selected System Health Monitoring when you installed the UMS client
(Figure 3-4 on page 34), then any events generated by those monitors will
generate SMS status messages.
142
5.5.2 SMS Events going to Director
There are three ways to have SMS forward events to Director; SNMP, Windows
NT Event Log, and using the GENEVENT command.
򐂰 SNMP
One of the tools that comes with SMS is the Event to Trap Translator. While
Director also has the ability to monitor the Windows NT Event Log for events,
using the SMS tool means you don’t have to install the UMS client or can
install it without selecting the Director Support option.
Unfortunately, this is the only way to have SMS forward messages directly
from the clients. Also, because the Windows NT Event Log is not available on
Windows 9x, this only work on Windows NT or 2000 clients.
򐂰 Windows NT/2000 Event Log
One of the possible actions for SMS to take in response to a status message
is to “Report to the Windows NT Event Log”. Because Director can monitor
the NT Event Log and react to events reported there, SMS can forward status
information to Director.
If you did not want to install a UMS client on the SMS server, you could use
the SMS Event to Trap Translator to forward the event to the Director server
as an SNMP trap.
򐂰 Genevent
The most flexible method of having SMS alert Director is the GENEVENT.EXE
command line utility. See “Generating Your Own Events” on page 154 of the
IBM Director User’s Guide for the syntax of the GENEVENT.EXE command.
Using an SMS Status Filter Rule, you can run the GENEVENT.EXE program in
response to a status message. With this tool you can control what severity,
description, and even the system named in the event generated to Director.
The one limitation is that you need to install UMS with Director Support on
your SMS server.
5.6 Software distribution
The IBM Director client uses an InstallShield routine for installation. This allows
you to easily create an SMS Package to distribute the Director client as well as
an Advertisement with programs to allow users to control the installation, or do it
completely silently.
143
Note: While the instructions for creating an SMS package are included in
“Customizing the SMS Installation” on page 116 of UM Services User’s Guide,
our testing has shown that if you need Director Support you should copy the
\Director\Win32\Install directory from the Director CD rather than using the
package recommended in the user’s guide.
If you use the package provided in the instructions, Director Support will not
be installed even though it is selected.
Customizing the package for Silent Installation
Once you have a source directory, simply edit the SETUP.ISS file in the language
you need and set the appropriate options as shown in Example 5-1.
Example 5-1 UMS SETUP.ISS file
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
USER CONFIGURABLE SECTION
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;UMS detected on system. Would you like to upgrade? Yes or No
;Available options:
; 1 = Yes
; 0 = No
[UpgradeYesNo]
Result=1
;The following is a list of available options. If adding options in the section
below,
;Component-count must be accurately indicated, and all options must be
sequentially numbered,
;starting at zero. Available options: (note: Basic Services cannot be removed
as an option)
;Component-x=0
Director Support
;Component-x=1
Web Based Access
;Component-x=2
System Health Monitoring
;Component-x=3
Web Based Remote Control
;Component-x=4
LANDesk(TM) Management Suite Integration
;Component-x=5
Tivoli Management Agent
;Component-x=6
SNMP access and trap forwarding
;Component-x=7
DMI Support
;Component-x=8
Help Files
;Add components below if desired. Recommended defaults are already set below.
[SdAskOptions-0]
Component-type=string
Component-count=5
Component-0=0
Component-1=1
Component-2=2
144
Component-3=6
Component-4=8
Result=1
;installation directory
[AskDestPath-0]
szPath="C:\Program Files\UMS"
Result=1
;username and password for web access
[AskSecurInfo-0]
svUser=ums
svPassword=ums
svConfirm=ums
svPort=411
Result=1
;DMI machine
; Options:
;
;
[DMI]
DMIType=3
type
1=Desktop
2=Mobile
3=Server
;Do you want icons on the start menu?
[Icons]
Result=0
;If you installed Director support, Would you like Director Remote Control?
[NfDRemote]
Result=0
;Do you want to require authorization for Director Remote Control?
[NfDReqAuth]
Result=1
;Auto Reboot machine when install is finished?
[AutoReboot]
Result=1
;Terminal services installation question
;Setup could not detect if system is in install mode. Are you sure the system
is in install mode?
;Continue with install,
; 1 = YES
; 0 = NO
[TerminalServices]
Result=0
145
;Use IIS as web server for UMS?
;Setup detected IIS installation. Do you want to use IIS as web server for UMS?
; 1 = YES
; 0 = NO
[UseIIS]
Result=0
Once you specify options such as what components to install, what directory to
install UMS into, and so on, save this file in the source share for your package.
You can then use that directory for the source of your package. Then create an
advertisement with the following command line for the program:
en\um_setup.exe REBOOT -S -SMS
5.7 Examples
These examples are continuations of those described in 3.6, “Examples” on
page 46.
The monitoring system in Microsoft SMS 2.0 is designed to monitor it’s own
operations. It has no tools or facilities to monitor third-party products using
standard methods such as SNMP or command line tools.
While SMS can detect UMS System Health events that are posted as SMS
Status Messages (see 5.5.1, “UMS alerts going to SMS” on page 142), more
robust monitoring requires the use of other management products such as IBM
Director. Configuring the different example events to forward to an IBM Director
event was covered in 3.6, “Examples” on page 46.
Note: SMS 1.2 did have an SNMP listener, which allowed a primary site to
accept SNMP traps and record them in its site database. This functionality has
been dropped in Version 2.0.
Here, the only method of forwarding this event to SMS would be through a
command line tool. Because Microsoft does not provide any tools for generating
SMS status messages from the command line, there is no way to forward this
kind of event to SMS.
146
With the installation of System Health Monitoring on the UMS client (see “System
Health Monitoring” on page 35), any CIM events raised are forwarded to the SMS
server as SMS status messages. Installing the ASM driver allow ASM events to
be raised as CIM events. In Figure 5-7, we see the UMS System Health page
showing a fan failed and the corresponding SMS status message.
Figure 5-7 UMS System Health with fan failed and corresponding SMS status message
Because SMS 2.0 has no ability to listen for SNMP traps, this type of event
cannot be received and processed by an SMS server.
While the PowerChute plus software from APC does have Microsoft SMS
support, it only provides inventory information and has no facility for notifying
SMS about any UPS related events.
147
148
6
Chapter 6.
HP OpenView
This chapter describes the integration of UM Services with OpenView. Because
OpenView uses SNMP for its communication, we will describe how to integrate
using SNMP to forward traps from UM Services to OpenView to see them in the
OpenView Alarm Browser. This enhances the alerting functionality.
IBM also provides an upward integration module (UIM) for the integration with
HP OpenView Network Node Manager 6.0 and 6.1. We will describe how to set
up this kind of integration and the functions added to the OpenView console by
installing the UIM, which are:
򐂰
򐂰
򐂰
򐂰
򐂰
Discovery
Alerting
Launch Support
Inventory
Help
We also continue the examples that were started in 3.6, “Examples” on page 46.
149
6.1 Prerequisites
We are assuming that the OpenView enterprise management environment is
already set up and working. Therefore we will not describe the installation of the
OpenView environment.
The SNMP service in the operation system should be installed and running.
In our test environment we used HP OpenView Network Node Manager 6.1 on
Windows 2000.
6.2 UMS integration using SNMP trap forwarding
To send SNMP traps from UM Services on your system to an SNMP-based
enterprise management system like OpenView using SNMP you need to provide
the IP address of the trap destination to the SNMP service in your operating
system.
The SNMP settings can be changed in the SNMP Service properties window, or
in the SNMP section in UMS, as shown in Figure 6-1.
Figure 6-1 SNMP settings in UMS
150
Because the SNMP section of UMS relates to the SNMP service running on your
operating system, the changes you make in the UMS SNMP section will be taken
over to the SNMP settings of the operating system.
If a hardware component fails, the System Health section of UMS will show you
which component failed. If you click on Event Viewer you will see that there was
an event added to the event log as shown in Figure 6-2.
Figure 6-2 UMS Event Viewer
This event will be forwarded as an SNMP trap to the trap destinations defined for
the SNMP service. If you define the OpenView server as an additional trap
destination, this event will be shown in the OpenView Alarm Browser as seen in
Figure 6-3.
Figure 6-3 OpenView Alarm Browser
If you are also forwarding the event to the IBM Director server using SNMP, the
trap and trap details will be displayed in the IBM Director Event Log (Figure 6-4
on page 152).
Chapter 6. HP OpenView
151
Figure 6-4 Event Log IBM Director console
There are several ways to set up actions for certain events using either IBM
Director or the enterprise management tool. Please refer to the documentation of
the management tool to find out how to set them up.
UM Services is only supported on Windows based systems. On non-Windows
systems you would use the IT Director agent together with other components to
get information from the hardware (e.g. the ASM device driver).
These alerts are sent to the Director server where you can set up an Event
Action Plan to forward these alerts to the OpenView server using SNMP.
6.3 Integration using the upward integration module
For an integration that does not only provide the forwarding of SNMP traps to the
enterprise management console, you should install the UIM for OpenView. This
kind of integration enhances the functionality of the OpenView console.
152
6.3.1 Installation and settings
Before you start the installation, make sure that the OpenView environment is
installed. You should also have UM Services installed as per 3.2, “Installing UM
Services” on page 34. During the installation of UM Services you should select
SNMP access and trap forwarding in addition to the standard options.
If you are going to manage Netfinity or xSeries servers, we also recommend you
install UM Server Extensions. For more information about how to install UM
Services and UM Server Extensions, please refer to Chapter 3, “Installing IBM
Director” on page 29.
To install the UIM, do the following:
1. Start the installation of UM Services on the OpenView server by inserting the
IBM Director CD.
2. Follow the steps of the installation program.
3. In the Select Components window, Figure 3-2 on page 31, click
Workgroup/Enterprise Integration. Figure 6-5 appears.
Figure 6-5 Integration Selection
4. Click HP OpenView Upward Integration, then click Next.
153
5. The installation will automatically install the UIM for OpenView with the
following actions:
a. Install \openview\snmp_mibs\*.mib — Installs the following SNMP MIB
files for UM Services client systems:
•
•
•
•
•
•
•
•
•
•
ums.mib
umsagent.mib
umsaol.mib
umservent.mib
umshealth.mib
cimwin32.mib
umslmsensor.mib
umsassetid.mib
aolnpet.mib
aolntrap.mib
b. Configures UM Services events in OpenView — Add lines to
\openview\alerts\umstraps.conf
c. Adds map files — Install \openview\registration\c\ums*.reg
d. Adds tools menu options — Install \openview\registration\c\rrov_reg
e. Loads UM Services events into the event configuration window — Install
\openview\registration\c\umstrap.reg
f. Adds map support for UM Services — Install \openview\bin\*
6. You will be asked if you want to view the Readme file now. We recommend
you read the file at this point.
Note: In the Readme file you will be told that if you are installing the UM
Services UIM on HP OpenView 6.1 with Windows 2000 Server or
Professional, you will need to add patches. The Readme file tells you the
patch numbers; NNM_00560 and NNM_00600. They are available from
the HP Web site:
http://www.openview.hp.com
We found that on the Web site, these patches had been replaced by patch
number NNM_00626. Install this patch after the installation of the UM
Services UIM has finished.
7. When the installation is complete, you will get an additional information that
you may use the UM Services integration after restarting the Network Node
Manager. Click OK.
8. You will need to restart the OpenView server to get the new fields added to
the database. To stop the OpenView server, you have two choices:
154
– Click Start > Programs > HP OpenView > Network Node Manager
Admin > NNM Services - Stop to stop the OpenView server.
– Issue the ovstop -v command from the \OpenView\bin directory.
To start the OpenView server, do either of the following:
– Click Start > Programs > HP OpenView > Network Node Manager
Admin > NNM Services - Start.
– Issue the ovstart -v command from the \OpenView\bin directory.
After restarting the OpenView console, you will notice some changes to the
OpenView console as discussed below.
6.3.2 Additional functionality through the integration
When you log on to an OpenView console you will first see that there was a UM
Services Submap added to the Root map (Figure 6-6). By clicking on Tools, you
can see the changes made to the contents of the Tools menu.
Figure 6-6 HP OpenView Root Map
In general, the UIM provides new functions for discovering clients, alerting,
starting UMS from the OpenView console, inventory, and help.
Discovery
After the installation of the UIM, OpenView automatically discovers UM Services
Clients. This is done by the HPOVUMS program. It detects the systems that have
UM Services installed. These systems are added to the UM Services Submap.
The discovered systems need to meet the criteria for which HPOVUMS scans
the systems:
155
򐂰 isUniversalService
The Enterprise OID will be checked using an SNMP Get() operation. The OID
should be 1.3.6.1.4.1.2.6.159. Depending on the return value, the system
properties are changed to UM Services Snmp Object and the system will
become a member of the UM Services Submap.
򐂰 isUMServicesCim
This test requires Windows Management Instrumentation (WMI) installed on
the system (which is automatically installed with UM Services) and remote
access privileges for the OpenView administrator. It queries the UM Services
HTTP port. If a valid port is returned the system will be added to the UM
Services Submap (Figure 6-7).
Figure 6-7 UM Services Submap
򐂰 Launch HttpUM Services
After discovering the systems that have UM Services installed, the
HPOVUMS also checks if these systems support Web-based UM Services.
This is done by sending an SNMP request on the HTTP port. If the system
returns a valid SNMP port this will enable the menu item Tools > Universal
Manageability Services (Figure 6-8).
156
Enabled when
once the UIM is
installed and
OpenView is
restarted.
Figure 6-8 Enhanced Tools menu in the OpenView console
If you click on a system that has no UM Services installed, the Tools >
Universal Manageability Services menu item will be greyed out.
Alerting
UM Services forwards the following SNMP traps to the OpenView server
workstation by default (depending on the hardware):
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
iBMPSG_TemperatureEvent
iBMPSG_VoltageEvent
iBMPSG_ChassisEvent
iBMPSG_FanEvent
iBMPSG_StorageEvent
iBMPSG_SMARTEvent
iBMPSG_LANLeashEvent
These traps alert the OpenView administrator to critical environmental conditions
in IBM systems such as low disk space, a failing hard drive, and a system being
removed from a LAN. Once OpenView is started, these traps are added to
OpenView’s trapd.conf file with their trap properties.
In addition, the install program adds placeholders for the following traps, which
will be implemented in UM Services in the future:
򐂰 iBMPSG_ProcessorEvent
򐂰 iBMPSG_AssetEvent
򐂰 iBMPSG_POSTEvent
157
򐂰 iBMPSG_ConfigChangeEvent,
򐂰 iBMPSG_LeaseExpiration
򐂰 iBMPSG_WarrantyExpiration
The UM Services traps are configured with default properties. These are similar
to the ones shown in Example 6-1.
Example 6-1 Default properties for UM Services traps
Enterprise: ibm
· Trap-Type: Specific <Last field of NOTIFICATION-TYPE OID>
· Trap Name: <Label of NOTIFICATION-TYPE>
· Display the Trap Category as: Status Events
· With Severity: Critical
· From this Source: Load MIB
· Object Status for Specific Traps: Critical/Down
· Event Description: <Event> condition critical
· Run this command when the trap is received: “ “
· Run as: Hidden Application
While testing the upward integration in our test environment, we found that the
alerts sent by UM Services were not visible in the OpenView Alarm Browser at
the beginning.
To ensure that the alerts are displayed in the OpenView Alarm Browser, you may
need to customize some event settings as follows:
1. Go to the Alarm Browser and click Actions > Configure Event... The Event
Configuration window opens (Figure 6-9).
158
Figure 6-9 Events for the umservices enterprise
2. Scroll down in the Enterprises section and click umservices. The Events for
the umservices enterprise will show all traps that were installed by the UIM.
Click on the first event in the list, and click Edit > Event > Modify...
3. Click the Event Message tab to open the window shown in Figure 6-10 on
page 160.
159
Figure 6-10 Modify Events window
4. By default the action is set to Log only. To make the alert visible in the Alarm
Browser, you have to click Log and display in category and select a
category in which the events should be listed. We selected Status Alarms.
5. You may also want to change the default Severity setting and the Event Log
Message. Specify these as well, then click OK to close the window.
6. Repeat these steps for all other events listed for the umservices enterprise in
the Event Configuration window if you want them to be visible in the Alarm
Browser.
7. To save your changes, click File > Save in the Event Configuration window,
then close the window.
Tip: Not every MIB file loaded into OpenView creates its own enterprise. In
some cases the traps are added to the general enterprise ENTERPRISES (for
example, loading MIB files for ServeRAID or APC UPS). For an example refer
to 6.4.4, “APC UPS loss of AC power through PowerChute plus” on page 170.
Launch Support
From the OpenView console you have the ability to start UM Services on remote
systems that have the UMS Web Based Access component installed. To start it,
follow the next steps:
1. Open the UM Services Submap in the OpenView console.
2. Select the client on which you want to start UM Services.
160
3. Click Tools > Universal Manageability Services.
The UM Services connection to the remote client will be established using a
default Web browser. You will be asked to log on to UM Services using your
UserID and Password.
Note: This function is only supported if the client has the UMSHttp capability.
Inventory
To see the inventory information from the OpenView console, select the client
system in the UM Services submap then click Tools > UM Services Inventory
(Figure 6-11).
Figure 6-11 UM Services Inventory components in the OpenView Tools menu
To see the information about a specific component, click the appropriate entry.
This will start a real-time query that is run against the remote system. To run this
query you must be logged on using an account that has remote access
privileges.
Note: The UM Services Inventory menu entry is only available if the selected
client has CIM installed.
Figure 6-12 on page 162 shows the information available about the memory in
the client system.
161
Figure 6-12 Inventory information
Help
When you have the UIM for OpenView installed on your system, help capabilities
are added to the Start menu. If you click Start > Programs > HP OpenView >
UM Services Integration with HP OpenView, you have the option to open the
Readme file or the UM Services Documentation for online help.
6.4 Examples
This section describes some examples specific to managing hardware through
the OpenView upward integration. The description of how we set up these
scenarios can be found in 3.6, “Examples” on page 46.
Here, we cover the prerequisites to send these alert to the OpenView server and
the results that can be observed in the OpenView console.
To receive ServeRAID events through the IBM Director server, you should have
configured the Director server as described in 3.6.1, “ServeRAID hard disk
failure through Director server” on page 47.
During the installation of the UIM for OpenView there was an enterprise for
Director traps added in addition to the umservices enterprise. It is called
directorTraps and has the OID 1.3.6.1.4.1.2.6.146.200 as shown in Figure 6-13.
162
Figure 6-13 Director enterprise
This enterprise contains one trap called DirectorTrap. You will need to change
the properties of this trap by clicking Edit > Event > Modify... (Figure 6-14).
Figure 6-14 Modify the Director trap
In the Modify Events window, define a category in which the event will be
displayed, and specify the severity and the event log message. We used
variables instead of plain text to provide additional information in the message.
163
The Director trap contains the information in several variables as you can see in
Example 6-2.
Example 6-2 Information sent by the Director trap
Long Descr.:
"Converted Tivoli Director Event"
Variables:
1: trapType
Syntax="Object Identifier"
Descr="The type of the event"
2: trapSeverity
Syntax="Octet String"
Descr="The severity of the event"
3: trapSenderName
Descr="The system name from which the event was sent"
4: trapManagedObjectName
Descr="The system name for which the event was generated"
5: trapText
Descr="Text associated with the event"
6: trapCategory
Descr="The category of the event"
We were using these variables:
[1]
[2]
[3]
The type of event
The severity of the event
The system from which the event was sent
The trap sends more information than we used in our example. These are:
[4]
[5]
[6]
The system name of the system that generated the event.
The text that was sent with the event.
The category of the event
For more information how to use variables for configuring the event log message
and the syntax go to the OpenView online help. If an event was sent through the
Director server (for example, ServeRAID events), it will appear in the OpenView
Alarm Browser similar to Figure 6-15.
164
Right click the event to display
the full message as configured
using the variables.
Figure 6-15 ServeRAID events in the Alarm Browser
For this example we have generated a trap from the UM Services client to
OpenView. To ensure that the event will be sent, configure the SNMP settings
with the IP address of the OpenView server. If an alert is sent to the OpenView
server it will be shown in the Alarm Browser (Figure 6-16).
Figure 6-16 Fan failure events in the Alarm Browser
165
To have the alerts received interpreted by OpenView, the MIB files must be
loaded, which is done during the installation of the UIM. At that time the events
are also loaded. Select any entry from the Alarm Browser and click on Actions >
Configure Event...
You can find the loaded events in the Event Configuration window by clicking on
the enterprise umservices (Figure 6-17).
Figure 6-17 Event Configuration for umservices
To get the alerts shown in the OpenView Alarm Browser displayed, you should
have them configured to be logged and displayed in a certain category. To
configure the Event Message for the Alarm Browser, you can use the variables
sent with the trap such as the variables shown in Example 6-2 on page 164.
To configure these properties, select the event you want to modify and click Edit
> Events > Modify... to go to the Modify Events window.
166
To load the MIB file provided on the Remote Supervisor Adapter Configuration
CD-ROM, we needed to make some changes on the file. The original MIB file
(IBMNFSP.MIB) contained trap type information that could not be loaded into
OpenView due to the following error:
This MIB cannot be loaded until the following problem is corrected:
[IBMRSSPALT] - Line 137: Error defining object: found '-'
To get the MIB file to load, we had to remove all TRAP-TYPE entries. Entries of
this type include the one shown in Example 6-3. This affected all TRAP-TYPE
entries in the file.
FTP
Available for download via FTP: The original IBMNFSP.MIB and the
modified IBMNFSP.MIB (with the TRAP-TYPE entries were removed) can be
downloaded via FTP. See Appendix C, “Additional material” on page 241 for
details.
Example 6-3 Example of the TRAP-TYPE entries in the original MIB file
ibmRemoteSupTrapTempC
TRAP-TYPE
ENTERPRISE ibmRemoteSupMIB
VARIABLES
{
ibmRsTrapDateTime,
ibmRsTrapAppId,
ibmRsTrapSpTxtId,
ibmRsTrapSpNumId,
ibmRsTrapSysUuid,
ibmRsTrapSysSern,
ibmRsTrapAppType,
ibmRsTrapPrority,
ibmRsTrapMsgText
}
DESCRIPTION
"Critical Alert: Temperature threshold exceeded."
::= 00
To be able to load this MIB file into OpenView, you will need to delete or comment
out the TRAP-TYPE information in the file.
Note: The MIB file contains many of the TRAP-TYPE definitions shown in
Example 6-3. All of them should be removed or commented out. After the
changes, the content of the MIB file is as listed in Appendix A, “Remote
Supervisor Adapter MIB file” on page 233.
167
After loading the modified MIB file, you can find the information in the OpenView
MIB Browser as shown in Figure 6-18.
Figure 6-18 OpenView MIB Browser with the RSA information
During loading the MIB file, there was no separate enterprise created in
OpenView. Therefore we did it manually in the Event Configuration window
(Figure 6-19).
168
Figure 6-19 Event Configuration for RSA Events
Because we took out the TRAP-TYPE information out of the MIB file, the traps
were not loaded. For our test environment we created two events for the new
enterprise to recognize these events:
򐂰 System Power Down (specific 23)
򐂰 System Power Up (specific 24)
The specific numbers were provided in the trap type information from the original
MIB file.
When setting up the events you should modify the event log message to get an
entry in the event log which tells you already the basic information about the
event (Figure 6-20 on page 170). The RSA traps are sending the following
variables:
[1]: ibmRsTrapDateTime
[2]: ibmRsTrapAppId
[3]: ibmRsTrapSpTxtId
[4]: ibmRsTrapSpNumId
[5]: ibmRsTrapSysUuid
[6]: ibmRsTrapSysSern
[7]: ibmRsTrapAppType
[8]: ibmRsTrapPriority
[9]: ibmRsTrapMsgText
Date and time when the event was generated
Application ID (source of the event)
ASM name
ASM ID number
Host System UUID
Host System Serial Number
Application Alert ID
Event severity: critical (0), non-critical (2), system
alert(4), informational alert (255)
Event message text
169
Figure 6-20 Modify RSA events
These variables can be used to set up the event message that will be shown in
the OpenView Alarm Browser. We used variables [2] and [9] in Figure 6-20 to get
the result shown in Figure 6-21.
Figure 6-21 RSA event message in the OpenView Alarms Browser
To find more information about how to use variables to set up event messages
for the Alarm Browser, go to the OpenView online help.
This example shows how events from the APC UPS are handled in OpenView.
They will be forwarded to the OpenView server using SNMP. Therefore you need
to customize the SNMP settings of the system monitoring the UPS.
170
To enable OpenView to recognize these alerts, you need to load the MIB file
(POWERNET.MIB) provided by APC. The latest version of this file can be
downloaded from:
http://www.apcc.com/tools/download/sw_kit.cfm?sku=sdw22,sdw21,sdw23
Alternatively, you can find it as follows:
1.
2.
3.
4.
5.
FTP
Browse to http://www.apcc.com
Click Search and search for MIB.
From the results page, click APC - Software Solutions Strategy
Click APC’s SNMP Agents and MIB.
Scroll to the PowerNet MIB section and download the current version. We
used version 3.0.4.
Available for download via FTP: The POWERNET.MIB file can also be
downloaded from the Redbooks site via FTP. See Appendix C, “Additional
After loading the MIB file you can find several new events in the Event
Configuration window. The UPS events are related to ENTERPRISES in the
enterprises section as shown in Figure 6-22 on page 172. There was no
separate enterprise created for them.
171
Figure 6-22 UPS events added to ENTERPRISES
Again, you need to modify each of the events you want to have displayed in the
OpenView Alarm Browser. To do this, select the event you want to modify, click
Edit > Event > Modify..., and change the settings in the Event Message tab,
(Figure 6-23).
172
Figure 6-23 Modifying the UPS event
For example, we modified two events, upsOnBattery (specific 5) and
powerRestored (specific 9), and configured them to be displayed in the Alarm
Browser as shown in Figure 6-24.
Figure 6-24 UPS events in the Alarm Browser
173
The event message in the Alarm Browser appear with the parameters you
specified. According to the event properties set in the Modify Events window
(Figure 6-23 on page 173), the alert appears in the Status Alarms Browser and in
the All Alarms Browser, but not in the others (for example, Configuration Alarms
Browser).
174
7
Chapter 7.
CA Unicenter TNG
In this chapter, we introduce how to integrate your xSeries hardware in an
existing TNG environment. For our examples, we used Unicenter TNG
Framework 2.2, ShipIT 2.0, and AimIT 3.0, but the content of this chapter will
also apply to Unicenter Enterprise, Software Distribution Operation, and Asset
Management Operation. In fact, Unicenter TNG Enterprise includes TNG
Framework as a standard component.
After providing an overview of the integration features, we’ll go through the
upward integration module installation and describe each option that you have.
We’ll also expand the examples introduced in 3.6, “Examples” on page 46.
175
7.1 Planning
When deploying xSeries servers in your Unicenter TNG environment, the critical
features are:
򐂰 Classify servers running UM Services
You have the option to create new classes to catalog systems running UMS in
order to group them together and execute similar tasks.
The prerequisite for this is having TNG Framework or Enterprise installed.
򐂰 Alert forwarding
You can receive SNMP traps in Unicenter TNG from UMS, IBM Director or
external sources as explained in 2.2, “Integrating into the enterprise” on
page 12.
There’s no need to install any extra code to accomplish this. However, when
you receive traps from UMS, some of the configuration tasks that you need to
do are already accomplished by installing the CA Unicenter TNG upward
integration module (UIM).
򐂰 Launch the UM Services Web browser from a TNG 2D and 3D map
The prerequisite for this is installing the UIM.
򐂰 Enhanced inventory information
Information coming from SMBIOS may be retrieved via UMS
The prerequisite for this is having AimIT or Asset Management Option (AMO)
installed in your environment, and installing the UIM.
򐂰 Distributing UMS client package
The prerequisite for this is having ShipIT or Software Distribution Option
(SDO) installed in your environment and the UIM.
7.2 Installing the Unicenter UIM
The CA Unicenter TNG UIM needs to be installed on the machine that is hosting
the TNG Framework component. No additional code is required on the client
machine except UMS and the TNG agent.
The upward integration module does the following:
򐂰 Creates three new classes to catalog UMS hardware
– UMS_NTServer as a Hosts subclass, intended for all Windows NT
Servers running UMS
176
– UMS_WindowsNT as a Workstation subclass, intended for all Windows
NT Workstations running UMS
– UMS_Windows95 as a Workstation subclass, intended for all Windows
95/98 machines running UMS
Also, a utility for reclassifying and grouping UMS machines is provided.
򐂰 Adds some message actions that provide a translation for all SNMP traps
coming from UM Services.
򐂰 Enhances inventory collection capabilities by modifying the file that AimIT
uses to gather information.
򐂰 Provides a batch file to create a package for UMS distribution via ShipIT.
We assume that the TNG environment is up and running. To install the UIM on
the TNG Framework machine, do the following:
1. Insert the IBM Director CD-ROM.
2. When the Select Components window appears (Figure 3-2 on page 31), click
Workgroup/Enterprise Integration.
3. When the Integration Selection window appears (Figure 3-3 on page 33),
select Unicenter TNG Upward Integration and click Next.
4. Enter the repository that TNG is using, and a userid and password to connect
to it. The installation program needs access to the repository because it adds
the definitions for the new classes.
5. During the installation process the following commands are issued:
trix -G -X -Q ums.TNG
cautil -f ums.MSG
The file UMS.TNG contains the new classes definitions, while UMS.MSG
contains the message and message actions definitions for SNMP trap
interpretation.
6. Once completed the installation, reboot your system.
Once the system is rebooted you can easily check the new classes opening the
Unicenter TNG class browser as shown in Figure 7-1 on page 178.
Chapter 7. CA Unicenter TNG
177
Figure 7-1 New classes added by the Unicenter UIM
7.3 Reclassify UMS machines
In 7.2, “Installing the Unicenter UIM” on page 176, we said that the UIM adds
new classes for UMS machines. Once the UIM is installed, the service
“UnicenterTNG UMS Reclassification Service” is started on your TNG Server as
178
Figure 7-2 UnicenterTNG UMS Reclassification Service added after the UIM installation
This service is responsible for reclassifying newly discovered machines into the
new added classes if they have UMS installed. This is accomplished by sending
an SNMP get to check for the presence of the UM Services Enterprise SNMP
OID.
However, you will also want to reclassify the machines that were discovered prior
to the UIM installation. To do this, a utility is added by the UIM and is available by
clicking Start > Programs > IBM Integration with Unicenter TNG > Reclassify
Systems in Unicenter TNG. However, we recommend that you not run this
application from the start menu because a command window will pop up,
execute the task, and disappear without letting you check what it did. The best
way to execute the task is opening a command prompt and entering the
following:
\TNGFW\BIN\ums_reclassification
For each machine belonging to any of the following classes, the program checks
if UMS is installed:
򐂰 WindowsNT
򐂰 Windows 95
򐂰 WindowsNT_Server
If UMS is installed, the machine is reclassified to the corresponding UMS class.
The following is an example of the output of the command:
Example 7-1 Reclassification
WindowsNT Class contains 0 objects.
Please wait for the reclassification process to complete......
179
Windows95 Class contains 0 objects.
WindowsNT_Server Class contains 15 objects.
All done
You will only need to run the reclassify utility once because any future UMS
systems will be discovered and reclassified by the Unicenter TNG UMS
Reclassification service.
The UIM also adds a business process view (BPV) in the Managed Objects
window, Figure 7-3, to group all the UMS machines.
Figure 7-3 Newly created UM_Services BPV
Figure 7-4 shows an example of the contents of this BPV.
180
Figure 7-4 UM_Services BPV Content after reclassification
Note the icons include the word UMS, indicating that UMS is installed on each
system.
7.4 Alert forwarding
Unicenter TNG is able to receive events coming from its agents. It can also
receive SNMP traps from any SNMP-compliant system. To enable this
functionality, you can do either of the following:
򐂰 Run the TNG catrapd utility on the server
From a command prompt enter catrapd. The trap service will start, showing
every trap it receives and forwarding it to the Console Log. We recommend
you don’t use this option because you need to manually start the program
every time the server restarts.
򐂰 Enable the TNG SNMP Trap service
This runs the same catrapd utility as a service.
To configure this, do the following:
a. Click Start > Programs > Unicenter TNG Framework > Enterprise
Managers.
b. A window with a Windows NT icon opens. Double click the icon.
c. Depending on the TNG version you installed (Framework or Enterprise),
different windows will popup. If using the Framework you’ll have a window
containing all the TNG enabled machines in your network. Double click the
icon corresponding to your server. Figure 7-5 on page 182 will then
appear.
181
If using Enterprise, double clicking the Windows NT icon will produce
Figure 7-5 directly.
Figure 7-5 TNG Enterprise Manager window
d. Double click Configuration.
e. Double click Settings. The window in Figure 7-6 pops up.
Figure 7-6 Unicenter TNG Settings window
f. Click the Component Activation Flag tab at the bottom of the window.
g. Click the Client Preferences tab on the right and scroll to the row with
SNMP Trap Server Activated in the Description column.
h. Select Yes in the Settings column.
i. Close the window.
182
Once the TNG Server is ready to receive traps, all traps are transmitted to the
Console Log. However, in order to understand the trap content, a mapping is
needed. The only way for TNG to map the trap is via the Event Management
policies. This means that a message needs to be defined in order to recognize the
alert, and message actions need to be defined for corresponding actions to the
received alerts.
The UIM adds message descriptions for each UMS SNMP trap and adds some
actions to remap the event to something that can be better understood than the
SNMP object identifier. These definitions are contained in the UMS.MSG file that
is copied into \TNGRoot\IBM and loaded into the Console during the UIM
installation. The actions defined for a fan failure alert are shown in Figure 7-7.
Figure 7-7 Message actions defined by the UIM for a fan failure SNMP trap
For each event, the following actions are defined:
򐂰 Banner
The action posts a message to the scrolling ticker tape on the Event Console
host. The name of the machine that issued the alert is passed as a parameter.
򐂰 Command
Three command actions are defined but are inactive. Each action is intended
to change the System status to critical so as to be displayed with a red icon in
the WorldView map. There are three actions in Figure 7-7 because they take
advantage of the seterr utility that needs the target object class as an input.
Three UMS classes are defined, so three different actions are needed.
You should activate only the actions that apply to your machines. For
example, if you only have servers running UMS, then only the
UMS_NTServer class-related action should be made active.
183
򐂰 Waitoper
This action posts a new message to the Console that describes the SNMP
trap better. This message needs acknowledgement by an operator in order to
be cancelled. This ensures that critical events are properly handled.
Note: Depending on your database access configuration, you might need to
modify the action seterr in order to give userid and password for database
access. We used TNG Framework with default settings, so we had to modify
the action as follows:
/int SETSTAT -R TNG3000_TNGDB -C UMS_WindowsNT -N &NODEID -I Admin -P secret
Critical
You could also modify the ums.msg file
As an example, we generated a fan failure SNMP trap before and after installing
the UIM. Figure 7-8 shows the trap before the UIM is installed.
Figure 7-8 Fan failure SNMP trap received by TNG before installing the UIM
The only way to determine what the message refers to is by examining the trap
details as shown in Figure 7-9.
184
Figure 7-9 SNMP trap content for a fan failure
Figure 7-10 shows the trap after the UIM is installed.
Figure 7-10 Message details for a fan failure SNMP trap received by TNG after installing the UIM
Before installing the UIM, the only way to understand what event generated the
trap is looking into the SNMP trap details (Figure 7-9). After the installation, the
trap has been decoded. The base SNMP trap is received both before and after
UIM installation. What changes is the actions performed after that trap is
received.
Figure 7-11 on page 186 shows the resulting scrolling ticker tape.
185
Figure 7-11 Fan failure ticker tape after installing the UIM
You might also define any new actions you wish TNG to perform.
7.5 Launching UMS from TNG maps
The UIM also adds a task to every machine belonging to a UMS class in TNG
2D/3D maps to launch UM Services Web browser.
You can easily find the task right clicking on the selected machine as shown in
Figure 7-12.
Figure 7-12 UM Services task added by the UIM to the 2D Map
This will launch an Internet Explorer window connecting to the machine IP
address on the UMS port that is detected on the target machine.
186
7.6 Inventory
The CA module used to collect inventory information is named differently
according to the Unicenter TNG version you are using:
򐂰 AimIT for TNG Framework
򐂰 Asset Management Option (AMO) for TNG Enterprise
This piece of software can be stand-alone or integrated into Unicenter TNG. In
order to collect client information, you should configure the client to execute
periodically (either at system startup or at a scheduled time) a program located
on the AimIT Server share created for this purpose. The share name is
\\AIMITServer\AIMIT.
The file that needs to be executed is located in the Agents subdirectory of the
share, and is UMCLIWNT.EXE for Windows NT machines. This file does the
following:
򐂰 Creates the CLIENTUS directory on the machine system drive
򐂰 Creates the CLIENTWS directory on the machine system drive
򐂰 Populates the directories with inventory information
A batch file, UMCLIENT.BAT, is also provided in the Agents directory. This file
runs on the client system and checks which operating system the machine is
running, then calls the appropriate program to collect the inventory data. This is
useful when configuring logon scripts that are operating system independent.
To add UMS information to AimIT, IBM takes advantage of the cim2mif utility that
we described in 4.7.3, “Executing a hardware inventory scan” on page 120, and
is used with the /CA switch in order to optimize the MIF files for Unicenter.
When the UIM is installed, a few lines are added to the UMCLIENT.BAT batch file
to collect UMS-provided data and put the resulting files into the CLIENTWS
directory. We report the changes in Example 7-2.
Example 7-2 UIM changes to UMCLIENT.BAT file to collect UMS inventory data
REM ********************* Begin IBM Changes *********************
if not exist "%UMS_HOME%\inventory\cim2mif.jar" goto umaskip
if exist c:\clientws goto mdskip
mkdir c:\clientws
:mdskip
@echo off
set PATH=%PATH%;%UMS_DRIVE%\
187
cd > %UMS_DRIVE%\TEST.DAT
REM At base address 100, write this string
echo e 100 "set CURDIR="
> %UMS_DRIVE%\TEMP.FIL
REM 'n' means set a file named called PREFIX.DAT
echo n %UMS_DRIVE%\PREFIX.DAT
>> %UMS_DRIVE%\TEMP.FIL
REM In register cx, set the size of the file to 0xb (11 bytes).
REM Then write the file set by 'n', i.e. PREFIX.DAT
for %%i in (rcx b w q) do echo %%i
>> %UMS_DRIVE%\TEMP.FIL
debug < %UMS_DRIVE%\TEMP.FIL
copy %UMS_DRIVE%\PREFIX.DAT+%UMS_DRIVE%\TEST.DAT %UMS_DRIVE%\VARIAB.BAT
call %UMS_DRIVE%\VARIAB.BAT
REM erase the temporary files
for %%f in (%UMS_DRIVE%\PREFIX.DAT %UMS_DRIVE%\TEST.DAT %UMS_DRIVE%\VARIAB.BAT
%UMS_DRIVE%\TEMP.FIL) do del %%f >NUL
echo @echo off> %UMS_DRIVE%\volume.bat
echo set CURDRIVE=%%3>> %UMS_DRIVE%\volume.bat
dir | find "Volume"> %UMS_DRIVE%\go.bat
call %UMS_DRIVE%\go
if exist %UMS_DRIVE%\volume.bat del %UMS_DRIVE%\volume.bat
if exist %UMS_DRIVE%\go.bat del %UMS_DRIVE%\go.bat
%UMS_DRIVE%
cd "%UMS_HOME%\inventory"
IF NOT EXIST "%UMS_HOME%"\jre\bin\jre.exe GOTO jview
@..\jre\bin\jre.exe -cp
.\cim2mif.jar;"%UMS_HOME%\httpserv\cimdre.jar";"%UMS_HOME%\httpserv\cimxml.jar"
;"%UMS_HOME%\httpserv\guitools.jar";"%UMS_HOME%\httpserv\cimfac.jar";"%UMS_HOME
%\httpserv\cimwmi.jar";"%UMS_HOME%\httpserv\cimcmn.jar"
com.ibm.sysmgt.cim.cim2mif.cim2mif /CA c:\clientws
%CURDRIVE%:
cd %CURDIR%
goto umaskip
:jview
@jview -cp:a
.\cim2mif.jar;"%UMS_HOME%\httpserv\cimdre.jar";"%UMS_HOME%\httpserv\cimxml.jar"
;"%UMS_HOME%\httpserv\guitools.jar";"%UMS_HOME%\httpserv\mswmi.jar";"%UMS_HOME%
\httpserv\xml4j2.jar";"%UMS_HOME%\httpserv\xml4j.jar"
com.ibm.sysmgt.cim.cim2mif.cim2mif /CA c:\clientws
%CURDRIVE%:
cd %CURDIR%
188
:umaskip
REM ********************* End IBM Changes *********************
Running this batch file will produce the following output before the usual AimIT
inventory collection output.
Example 7-3 UMCLIENT.BAT output
IBM CIM to MIF Generator, version 1.11
Creating MIF files in c:\clientws
Processing aol...
Processing assetid...
Processing bios...
Processing cache...
Processing chassis...
Processing cim...
Processing config...
Processing ipconfig...
Processing ipxconfig...
Processing lease...
Processing locale...
Processing memory...
Processing network...
Processing personalization...
Processing ports...
Processing processor...
Processing serialization...
Processing slot...
Processing snmp...
Processing ums...
Processing user...
Processing video...
Processing warranty...
Furthermore, UMSINV.MIF is added to the CLIENTWS directory. This MIF file
contains the UMS information to be gathered by the inventory engine.
Once the data is collected using the AimIT Engine, you can view it either from the
2D Map or through the AimIT Admin Console. The UMS details are added in the
Additional tab of the inventory as shown in Figure 7-13 on page 190.
189
Figure 7-13 UM Services Inventory information added by the UIM
For further details about Inventory, check your inventory product’s user’s guide.
7.7 UMS client distribution
When deploying large xSeries installations in an existing TNG environment,
there are procedures and standards to follow.
Normally, when you have many servers to install with the same configuration, a
setup kit is built. This kit performs unattended setup of the operating system,
software, and utilities. Because the management client would be part of the
standard installation, you won’t need to roll out the client to those systems.
190
In other cases, the servers will serve different needs and will have different
software installed. In this case, skilled staff will probably perform the installation,
and again you won’t need to automatically distribute the software to a server.
This is not the case with client machines. However, distribution to clients is
beyond the scope of this book.
The typical situation in which you are likely to distribute management software to
a server automatically is in case of an upgrade to a new release. Usually all the
software needed to perform the distribution is installed on the managed
machines. You have several options on what kind of client software to install,
depending on the operating system and the hardware itself (see 2.4, “Design
considerations” on page 21 for further details).
If you already have a Unicenter environment in place and want to perform a new
install or to upgrade the UMS client software, you may use ShipIT or SDO to
distribute the package.
These are the steps:
1. Copy the package file found on the Director CD in the following path:
\Director\WIN32\File Packages\SMS\UMSW32UN.EXE
into the software distribution directory under the TNG installation path:
IBM\sw_distribution
2. From a Windows NT command prompt run RR_SWDISTRIB.BAT found in the
same software distribution directory to set up the package into the Software
Distribution Utility. The output of this command is shown in Example 7-4.
Example 7-4 RR_SWDISTRIB.BAT output
sdcmd regsw item="IBM Director" version=2.2
path=C:\TNGFW\ibm\sw_distribution\ procedures=procedure.bat
SD Command Line v1.2 Copyright (c) 1996, 1998 Computer Associates Intl.
Connecting to Server ... OK
Command is processed ...
SDCMD<0>: OK
This command may take some time to complete.
Once these tasks are accomplished, a new package is ready for distribution in
the ShipIT explorer window (Figure 7-14 on page 192).
191
Figure 7-14 IBM Director Software Distribution Package created
To distribute the package, proceed as for any software distribution. We dragged
the package onto the computer that we wanted to install it to.
You can check if the installation was performed properly in the UMS installation
log found at C:\LOG\umsinst.log.
7.8 Examples
In this section we continue the examples introduced in 3.6, “Examples” on
page 46. As you will see, a few of them need some customization that is not
performed using the UIM. The general idea of the new mappings is defining
messages describing the events that we would like to be interpreted, and
performing a few actions when an alert of that kind is received to either highlight
critical alerts or to change the status indicator color for the machine.
This can be done either writing a few configuration files that can be imported into
the Enterprise Manager via a simple command line, or adding the messages and
message actions via the GUI.
7.8.1 ServeRAID hard disk failure through Director Server
In order for TNG to receive a ServeRAID hard disk failure from a Director Server,
you should set up an Event Action Plan on the Director server to send an SNMP
trap to the server hosting the TNG Enterprise Manager. Refer to 3.6.1,
“ServeRAID hard disk failure through Director server” on page 47 and to the IBM
Director User’s Guide for details on how to configure it.
192
Once the Director Server is configured, you are able to receive traps into the
TNG Console Log. Unfortunately, the UIM does not add any configuration for
alerts coming from an IBM Director Server, so in order to interpret this trap, some
message actions need to be defined. These message actions should be similar
to those we discussed in 7.4, “Alert forwarding” on page 181.
To define these message actions, either use the GUI or a command line. We’ll
show how to configure a batch file containing the definitions so that you have an
automatic way to define these messages.
If you want to map an SNMP trap, you need to know the details of the trap. The
easiest way to get them is generating a sample trap (pulling out a drive on a test
machine, for example) into the Enterprise Manager Event Console. You might
also get the details from the OID or MIB files provided with IBM Director.
Note: The MIB files for Director traps are on the Director CD-ROM in a
compressed format. They can be extracted from the CD using the expand
command, or can be found in the Director installation directory on the IBM
Director server.
The SNMP trap details for the hard disk drive failure are shown in Figure 7-15.
Figure 7-15 SNMP trap details for the Director hard disk failure event
From the details we were able to define a message that identifies this kind of
trap, and defined a few actions following the schema found in UMS.MSG as
discussed in 7.4, “Alert forwarding” on page 181.
We created a file that can be used to import the definitions from a command line
as shown in Example 7-5 on page 194.
193
FTP
Available for download via FTP: This file can be downloaded as DIR.MSG
from the Redbooks site via FTP. See Appendix C, “Additional material” on
page 241 for details.
Example 7-5 Messages and Message Actions definitions for Director Traps
define msgrecord
msgid="* * * * * * * * * * * * 1.3.6.1.4.1.2.6.146.1*"
type="MSG"
msgnode="*"
desc="Director Alert"
cont='N'
msgact='Y'
wcsingle='?'
wcmany='*'
define MSGACT
name=(*,10)
action="BANNER"
attrib="DEFAULT"
audit='N'
color="RED"
condop=" "
evaluate='Y'
quiet='N'
status="ACTIVE"
sim='N'
text="Director Alert from &NODEID"
define msgact
name=(*,50)
action="WAITOPER"
attrib="DEFAULT"
audit='N'
color="RED"
condop=" "
evaluate='Y'
quiet='N'
status="ACTIVE"
sim='N'
text="&NODEID : Director is critical."
define MSGACT
name=(*,30)
action="COMMAND"
attrib="DEFAULT"
audit='N'
194
color="DEFAULT"
condop=" "
evaluate='Y'
quiet='Y'
SEVerity=F
status="ACTIVE"
sim='N'
text="/int SETSTAT -R TNG3000_TNGDB -C UMS_NTServer -N &NODEID -I Admin
-P secret Critical"
The message that we created maps messages containing the
1.3.6.1.4.1.2.6.146.1 OID. This will treat all alerts coming from Director the same
way. You might also define different mappings for different alerts to include, for
example, part of the text in the trap in order to distinguish drive failures from
other alerts.
Also the file will create three actions:
򐂰 Banner — This creates a scrolling ticker tape string on the console host. Note
that the alert source machine name is reported in that string.
򐂰 Waitoper — This action creates a new message to wait for an operator
acknowledgement. Note that the alert source machine name is reported in the
new message.
򐂰 Command — This changes the status icon on the WorldView map to a critical
state.
To import the file content into the Enterprise Manager, enter the following
command from an operating system command prompt:
cautil -f <filename>
where <filename> is the name of the file you created.
Remember to issue the opreload command from the Console to commit your
changes. Otherwise you will not get the result you expected.
The results for the BANNER actions are shown in Figure 7-16.
Figure 7-16 Scrolling ticker tape generated by a disk failure SNMP trap
195
The results for the WAITOPER actions are shown in Figure 7-17.
Figure 7-17 Mapping for an SNMP trap alert coming from a Director Server
The results for the COMMAND action are shown in Figure 7-18.
Figure 7-18 Critical status set for the machine presenting the disk problem
This alert is generated by the ASM processor, and passed to the UMS client for
forwarding as an SNMP trap to the machine hosting the TNG Enterprise
Manager. For details on how to configure this, refer to 3.6.2, “Advanced System
Management fan failure through UMS client” on page 51.
Because this alert is coming from UMS, all the customization needed to interpret
the event has already been done by the UIM.
196
In Figure 7-19 the SNMP trap details are shown, while in Figure 7-11 on
page 186 you can see the scrolling ticker tape.
Figure 7-19 Fan failure from UMS SNMP trap details
In Figure 7-20 the message received by the Console is shown.
Figure 7-20 Messages for fan failure from UMS SNMP trap event after proper interpretation
In this section we’ll show how to configure actions for a shutdown message
coming from a Remote Supervisor Adapter (RSA). For details on how to
configure the RSA refer to 3.6.3, “Remote Supervisor Adapter system shutdown”
on page 54.
Again, no mapping is defined by the UIM for RSA events. The best thing to do is
to simulate the events that you would like to decode in order to get the details of
the trap and define messages and message actions to perform the tasks you are
interested in.
197
In order to decode the RSA alert, we shut down an x220 to generate the sample
SNMP trap. The trap details are reported in Example 7-6. We could have also
mapped the alert using the MIB file provided with the RSA.
Example 7-6 RSA system complex power down SNMP trap details
%CATD_I_060, SNMPTRAP: -c public 2 9.24.105.235 UNRESOLVED 6 23 00:04:13 9 OID:
1.3.6.1.4.1.2.6.158.2.1.1.1
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.1 VALUE:
Date(m/d/y)=05/10/01, Time(h:m:s)=22:12:03 OID: 1.3.6.1.4.1.2.6.158.2.1.1.2
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.2 VALUE: IBM Netfinity
Service Processor OID: 1.3.6.1.4.1.2.6.158.2.1.1.3
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.3 VALUE: WMN315620240
OID: 1.3.6.1.4.1.2.6.158.2.1.1.4
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.4 VALUE: 315620240 OID:
1.3.6.1.4.1.2.6.158.2.1.1.5
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.5 VALUE:
EA94245DE71DB2118CC894A2F82FF1A5 OID: 1.3.6.1.4.1.2.6.158.2.1.1.6
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.6 VALUE: 23R0033 OID:
1.3.6.1.4.1.2.6.158.2.1.1.7
1.3.6.1.4.1.2.6.158.2.1.1.8
1.3.6.1.4.1.2.6.158.2.1.1.9
.iso.org.dod.internet.private.enterprises.2.6.158.2.1.1.9 VALUE: System Complex
Powered Down
To tell the different events coming from the Service Processor apart, we defined
a message that checks both for the SNMP trap OID and for the final string
System Complex Powered Down. Example 7-7 lists the text file used to
automatically define the actions.
FTP
Available for download via FTP: This file can be downloaded as RSA.MSG
Example 7-7 Messages and actions definitions for RSA power down messages
define msgrecord
msgid="* * * * * * * * * * * * 1.3.6.1.4.1.2.6.158.2.1.1.1 * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
System Complex Powered Down"
type="MSG"
msgnode="*"
desc="System Complex Power Down"
cont='N'
msgact='Y'
wcsingle='?'
198
wcmany='*'
define MSGACT
name=(*,10)
action="BANNER"
attrib="DEFAULT"
audit='N'
color="RED"
condop=" "
evaluate='Y'
quiet='N'
status="ACTIVE"
sim='N'
text="RSA Alert from &SOURCE"
define msgact
name=(*,50)
action="WAITOPER"
attrib="DEFAULT"
audit='N'
color="RED"
condop=" "
evaluate='Y'
quiet='N'
status="ACTIVE"
sim='N'
text="&SOURCE SysComplex Power Down"
define MSGACT
name=(*,30)
action="COMMAND"
attrib="DEFAULT"
audit='N'
color="DEFAULT"
condop=" "
evaluate='Y'
quiet='Y'
SEVerity=F
status="ACTIVE"
sim='N'
text="/int SETSTAT -R TNG3000_TNGDB -C UMS_NTServer -N &NODEID -I Admin
-P secret Critical"
Note: Make sure that all the asterisks (*) are present because each space in a
text string is considered a break. For example, if you want to search the string
“text number one” for the presence of the word text, the string “text*” will not
match it while “text * *” will. Refer to the TNG online help for further details.
199
We issued cautil -f <filename> from a command line and opreload from the
Event Console, where <filename> is the name of the file that we created.
As a result, the RSA trap is processed as per Figure 7-21, and creates the alert
Figure 7-21 RSA power down alert interpreted by the TNG Console.
Figure 7-22 Banner message created after receiving the RSA Alert
In this last example, we wanted to receive an alert from APC PowerChute. We
configured PowerChute to send an SNMP trap to the TNG Unicenter host every
time a critical event occurs, as per 3.6.4, “APC UPS loss of AC power through
PowerChute plus” on page 58.
No messages are defined for this kind of event. The procedure is similar to the
actions that we did for alerts coming from Director and the RSA (see 7.8.1,
“ServeRAID hard disk failure through Director Server” on page 192 and 7.8.3,
“Remote Supervisor Adapter system shutdown” on page 197).
We generated a sample trap shown in Figure 7-23.
200
Figure 7-23 SNMP trap details for a loss of AC Power event
From these details we built a message to identify these traps. The file we built for
automatic creation is listed in Example 7-8.
FTP
Available for download via FTP: This file can be downloaded as UPS.MSG
Example 7-8 Messages and message actions definitions for UPS loss of AC power
define msgrecord
msgid="* * * * * * * * * * * * 1.3.6.1.4.1.318 * * * The UPS has
switched to battery backup power."
type="MSG"
msgnode="*"
desc="UPS Loss of AC Power"
cont='N'
msgact='Y'
wcsingle='?'
wcmany='*'
define MSGACT
name=(*,10)
action="BANNER"
attrib="DEFAULT"
audit='N'
color="RED"
condop=" "
evaluate='Y'
quiet='N'
status="ACTIVE"
sim='N'
text="UPS Loss of Power &NODEID"
201
define msgact
name=(*,50)
action="WAITOPER"
attrib="DEFAULT"
audit='N'
color="RED"
condop=" "
evaluate='Y'
quiet='N'
status="ACTIVE"
sim='N'
text="&NODEID : UPS is critical."
Once again we imported these actions by issuing the cautil -f <filename> and
the opreload command.
Eventually, every SNMP trap matching that message will produce a ticker tape
message (see Figure 7-24) and a new message for an operator to acknowledge
it (see Figure 7-25) on the host running the Enterprise Manager.
Figure 7-24 Ticker tape produced by the UPS loss of AC power SNMP trap
Figure 7-25 UPS loss of AC power alert interpreted by the TNG Console
202
7.9 Conclusion
To manage your xSeries hardware in a Unicenter TNG environment, IBM has
developed a UIM that contains configurations for:
򐂰
򐂰
򐂰
򐂰
Adding new classes to TNG in order to catalog UMS machines
Alert forwarding
Enhanced inventory data gathering
Distributing UMS software
We described how to take advantage of what is already done by the UIM, and
how to enhance your alert forwarding features in order to get other alerts
interpreted by your Enterprise Manager with a few examples.
203
204
8
Chapter 8.
Tivoli NetView
In this chapter we describe how to integrate UM Services with Tivoli NetView. We
are covering the integration of UM Services using SNMP and the integration
using the upward integration module (UIM) provided for Tivoli NetView Version
5.1.1 and 6.0 for Windows NT.
The integration using Simple Network Management Protocol (SNMP) shows how
to forward traps from UM Services to NetView to get the events into the NetView
event browser. This method provides basic alerting function.
Our discussion of the integration using the UIM includes a description of the
functions added to the NetView console, which are:
򐂰
򐂰
򐂰
򐂰
򐂰
Discovery
Alerting
Launch support
Inventory
Help
The chapter also includes some real-life examples of alerts sent to NetView.
These examples are based on the descriptions in 3.6, “Examples” on page 46.
205
As this redbook covers the upward integration of IBM Director into enterprise
management tools, we describe how to set up the upward integration, but not
how to set up the enterprise management environment itself. Therefore we
assume that the enterprise management tool is already running. The SNMP
service in the operating system should also be installed and running.
On the NetView server and clients in our lab environment, we used Tivoli
NetView 6.0.1 running on Windows NT 4.0 with Service Pack 6.
8.1 UMS Integration using SNMP trap forwarding
To send SNMP traps from your system to an enterprise management system
such as NetView, you need to provide the IP address of the trap destination to
the SNMP service in your operating system.
The SNMP definitions can be configured in UMS SNMP section using a Web
browser as shown in Figure 8-1. They can also be changed in Windows in the
properties dialog of the SNMP service.
Enter the community name and Trap Destinations, then click Apply to save your
changes.
Figure 8-1 SNMP settings in UMS
206
The changes you make either in the SNMP properties window or in the SNMP
section of UM Services will also appear in the other window because both are
related to the Windows SNMP service.
Once you have SNMP configured, if a component that is monitored by UMS fails,
UMS will send a popup window to inform you about the event. Click on UMS
System Health to find out which component has failed.
If you click Event Viewer in the left pane, you will see that there was an event
added to the event log as shown in Figure 8-2.
Figure 8-2 UMS Event Viewer
The SNMP service will forward this event to the trap destinations, which are
defined in the UMS SNMP section. One of our defined trap destinations was the
NetView Server. Therefore this event will also be shown in the NetView Event
Browser (Figure 8-3).
Figure 8-3 NetView Event Browser
Chapter 8. Tivoli NetView
207
When opening the Event Details for this event, you will notice that the SNMP
event description contains the message that a fan problem occurred (Figure 8-4).
Figure 8-4 NetView Event Details
This event was also forwarded to the IBM Director server using SNMP. There it
will be added to the event log and the event details will show the details of the
message as seen in Figure 8-5.
208
Figure 8-5 IBM Director Event Log
UM Services only runs on Windows systems. On non-Windows systems you will
need to install the IT Director agent, which is provided for non-Windows systems
on the Director CD in the \Director\ folder.
Install the IT Director agent together with the corresponding components (for
example, the ASM device driver) to get hardware information. In combination
with the ASM device driver, the IT Director agent would be able to get the alerts
from the ASM adapter and to send these alerts to the Director server, which
should have an Event Action Plan configured to forward an SNMP trap to the
NetView Event Browser if ASM events occur.
8.2 Integration using the Upward Integration Module
To achieve a higher level of integration than just forwarding SNMP traps, you
should install the Upward Integration Module (UIM) for NetView. This kind of
integration enhances the management functions provided by the NetView
console such as the discovery of systems, alerting, launch support, inventory,
and help functions.
209
You need to install the UIM for NetView on the NetView server. You should also
install it on any other NetView console to which you want to have the functionality
added. The installation procedure, which we document below, is the same for
both except for one step.
8.2.1 Installation and settings
You should already have your NetView environment up and running. Before
starting the installation of the UIM for NetView, you need to check if the NetView
system administrator has access privileges on every remote client system to
obtain UM Services inventory data for each client system.
The easiest way to ensure this is to define every client as a member of a domain.
If the NetView system administrator is a member of the Domain Admins group,
the system administrator has access to all the computers in the domain without
requiring further authentication.
In addition, UM Services needs to be installed on the client systems. UM
Services does not have to be installed before installing the UIM, but to use any of
the new functions added to the NetView console through the installation of the
UIM you should install UM Services on the systems to which you want to get
access using UM Services, e.g. for inventory information.
During the installation of UMS on the client systems, ensure that the options Web
Based Access and SNMP access and trap forwarding are enabled. If you are
going to manage Netfinity or xSeries systems, you should also install UM Server
Extensions on those machines. For more information about how to install UM
Services and UM Server Extensions refer to Chapter 3, “Installing IBM Director”
on page 29.
To install the upward integration module, do the following:
1. Stop the NetView Server:
Start > Programs > NetView > Administration > Stop Server
2. Start the installation of UM Services on the NetView server using the IBM
Director CD and follow the steps for starting the installation. Figure 3-2 on
page 31 will appear.
3. Click Workgroup/Enterprise Integration. The Integration Selection window
appears (Figure 8-6).
210
Figure 8-6 Integration Selection window
4. Select Tivoli NetView Upward Integration and click Next.
5. You will be asked to specify if you are installing the UIM on a NetView Server
or on a NetView Console (Figure 8-7).
Figure 8-7 Select Components
211
For the installation of the UIM on the NetView server, select NetView Server,
but for the installation of the UIM on the NetView client select NetView
Console. Click Next.
6. Before the installation proceeds you will be asked in a popup window to
ensure that you have stopped the NetView Server (Figure 8-8). This was
already done in step 1, so click OK.
Figure 8-8 Stop the NetView server
7. During the installation there will be a UM Services SmartSet added to the
NetView console and the UM Services MIB files are loaded. Trap filters for
UM Services SNMP traps are added as well as menu items for the Tools
menu in the NetView console.
You can follow the install procedure on the screen to see which MIB files are
going to be loaded, as in Example 8-1.
Example 8-1 Loading UM Services MIB files
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\ums.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\umsagent.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\umsevent.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\umsaol.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\umshealth.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\umslmsensor.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\umsassetid.mib
USR\OV\IBM\INVENTORY>loadmibv2.exe -load \usr\ov\snmp_mibs\aolnpet.mib
USR\OV\IBM\INVENTORY>loadmibv2.exe -load \usr\ov\snmp_mibs\aolntrap.mib
USR\OV\IBM\INVENTORY>loadmib.exe -load \usr\ov\snmp_mibs\cimwin32.mib
8. At the end of the installation, you will need to restart your system.
After restarting the server, the UM SmartSet is populated and nvsniffer.exe
starts. It discovers the systems in the network and searches for their properties.
8.2.2 Additional functionality through the integration
You will notice that the Tools menu in the NetView console will have additional
entries. Universal Management Services will be added as well as UM Services
Inventory (Figure 8-9).
212
Figure 8-9 NetView Tools menu
The changes to the NetView console provide additional functions in the following
areas:
򐂰
򐂰
򐂰
򐂰
򐂰
Discovery
Alerting
Launch support
Inventory
Help
Discovery
To ensure that nvsniffer scans for the UM Services properties of the systems and
that the additions to the NetView console are populated correctly, you need to
customize two configuration files:
򐂰 nvsniffer.conf
򐂰 nvsniffer_ums.conf
They are located in the \USR\OV\CONF directory. Both will contain the lines
shown in Example 8-2 on page 214 at the end of the file.
213
Example 8-2 Customization of nvsniffer.conf and nvsniffer_ums.conf

# UM Services service discovery tests
#
#discover UM Services client by testing for its SNMP OID
# Netview version 5.x, 6.1.x
#isUMSSnmp|.1.3.6.1.4.1.2.6.159|||\usr\ov\bin\snmpsniffext.dll|\usr\ov\bin\snmpsniffext.dll|*
#
# Netview version 6.0
isUMSSnmp|.1.3.6.1.4.1.2.6.159|||\usr\ov\bin\snmpsnifftext.dll|\usr\ov\bin\snmpsnifftext.dll|*
#discover UM Services client by testing for instances of IBMPSG_UMSHTTP in CIMOM
isUMSCim||||\usr\ov\bin\umscimtest.exe|\usr\ov\bin\umscimtest.exe|*
#discover UM Services client by testing response from its http daemon on
#the list of ports below and see if it uses the realm IBM UMS
isUMSHttp|411,6500,6411,6611,6600|UM_Services|Universal Management
Services|\usr\ov\bin\umshttptest.exe|\usr\ov\bin\umshttptest.exe|*
The isUMSSnmp filter checks if the UM Services SNMP subagent is installed
on the remote system. Take the # sign out of the section that refers to the
NetView version you are using. Because we were using NetView 6.0.1, the
second entry had to be enabled. If you are using NetView 5.x or 6.1.x, choose
the first entry.
The isUMSCim filter checks if the NetView server user has remote access
privileges to the remote system. If yes, it requests CIM information from the
remote system. Take the # sign out of this section to enable this filter.
The isUMSHttp filter checks if the UM Services HTTP daemon is installed on
the remote system. Take the # sign out of this section to enable this filter.
Whether the new items will be shown in the Tools menu or not will depend on
your settings in the configuration files.
Alerting
During the installation of the UIM for NetView, the following traps are added to
the trapd.conf file in \usr\ov\conf:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
214
iBMPSG_TemperatureEvent
iBMPSG_VoltageEvent
iBMPSG_ChassisEvent
iBMPSG_FanEvent
iBMPSG_Storage_Event
iBMPSG_SMARTEvent
iBMPSG_LANLeashEvent
The following traps are not currently used:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
iBMPSG_AssetEvent
iBMPSG_ProcessorEvent
iBMPSG_POSTEvent
iBMPSG_ConfigChangeEvent
iBMPSG_LeaseExpiration
iBMPSG_WarrantyExpiration
iBMPSG_RedundantNetworkAdapterEvent
iBMPSG_RedundantNetworkAdapterSwitchoverEvent
iBMPSG_RedundantNetworkAdapterSwitchbackEvent
You can set a filter including one or more of these events. There will be another
filter added for filtering IBM Director events (IBM_Director_Trap). These filters
can also be used to setup actions for specific events (Figure 8-10).
Figure 8-10 Setting up a filter using the UMS traps
The alerts sent by UMS will be shown in the NetView Event Browser as shown in
Figure 8-11 on page 216.
215
Figure 8-11 NetView Event Browser
Right click on an event and select Event Details. The window that appears
shows other details about the alert than you have seen before installing the UIM.
Compare Figure 8-12 to Figure 8-4 on page 208. You will notice now that this
event was sent by UM Services to the NetView console. The Trap Name refers to
the UM Services SNMP trap, in this case IBMPSG_FanEvent.
Figure 8-12 NetView Event Details
216
Launch support
From the NetView console you can start UM Services on NetView clients that
have the UMS Web Based Access component installed. To start UM Services, do
the following:
1. Open the NetView console and go to the Root map to see the available
SmartSets (Figure 8-13).
Figure 8-13 NetView SmartSets
2. Double click the UM_Services SmartSet to open it (Figure 8-14 on
page 218).
217
Figure 8-14 UM Services SmartSet
3. In the UM Services SmartSet, select the client for which you want to start UM
Services.
4. Click Tools > Universal Manageability Services.
Note: If the selected client system does not have the Web Based Access
component installed, this selection will be disabled and unavailable.
UM Services will be started and will connect to the remote client using the default
Web browser. You need to logon using the UM Services UserID and Password.
Inventory
There are different ways to collect inventory information from UM Services
clients:
򐂰 From the NetView console:
a. In the UM Services SmartSet, select the system in the submap for which
you want to collect inventory data.
b. In the Tools menu, select UM Services Inventory and click Demand Poll
to collect the data for this client.
Note: If the selected system does not have the UMSCIM Object capability,
the UM Services Inventory item will be disabled.
218
򐂰 From the command prompt:
a. Open the file NVSNIFFER.CONF
b. Replace the line wbem_discovery.conf with ums_wbem.conf.
c. Save this file as UMS_WBEM_DISCOVERY.CONF
d. Run nvsniffer using the new NetView sniffer configuration file just created:
nvsniffer -c /usr/ov/conf/ums_wbem_discovery.conf
򐂰 From the NT Schedule service:
The nvsniffer command can be run using the NT Schedule service. You
need to configure the Schedule service to log on as a user with remote
access privileges on the client system. By default nvsniffer will be run daily at
1:00 a.m.
To get inventory information for any UMS client displayed, click on the
appropriate client. Then click Tools > UM Services Inventory (Figure 8-15).
Figure 8-15 UM Services Inventory menu
For an initial scan for inventory data, click Demand Poll.
219
To view the information about a component, click on the related menu item. For
example, to view the memory information you would click Tools > UM Services
Inventory > Memory Details. This would show results similar to Figure 8-16.
Figure 8-16 Inventory information about memory
To display all UM Services data for one specific system that is stored in the
database, use the following command:
ovobjprint -s <hostname>
An example of the output of this command is listed in Appendix B, “Output of
ovobjprint” on page 237.
Help
After the installation of the UIM for NetView, you will see that there are some
more help options available through the Start menu. If you click Start >
Programs > NetView > UM Services Integration with NetView, you will have
the option to open the Readme file or to open the UM Services Documentation.
These will help you to find more information about the NetView UM Services
Upward Integration Module.
8.3 Examples
In this section, we continue the four examples we stated in 3.6, “Examples” on
page 46, adding specific information about NetView integration.
During the installation of the UIM for NetView an enterprise and traps for UM
Services events were added to NetView but not for Director events. Therefore,
the traps sent by the Director did not appear in the NetView Event Browser in our
test environment until we set up a new enterprise called Director with the ID
1.3.6.1.4.1.2.6.146.200 (Figure 8-17).
220
Figure 8-17 Trap Settings for Director traps
For this enterprise we defined a trap called Director_Trap as specific #1, which
will be recognized as an IBM Director trap. In the Trap Settings window, select
the trap and click Properties to see the settings for this trap (Figure 8-18).
Figure 8-18 Trap Properties for Director trap
221
In the Trap Properties window, you can change the name of the trap. Further, you
can specify in which category you want the trap to be shown, its severity, and the
object status. In the Event Description field, use the variables sent with the
SNMP trap to customize the Event Message for the Event Browser. We used the
variables [1] (event description) and [2] (severity). To find out more about how to
use trap parameters in the Event Description field and what the syntax is to use
them, go to the NetView online help.
Example 8-3 shows the variables that are sent with the ServeRAID SNMP trap.
Example 8-3 Variable of a ServeRAID SNMP trap
Harmless: Netfinity Storage.ServeRAID Controller.Logical Drive.Rebuild
.Completed, Trap #6, specific: 1, args (6):
[1] private.enterprises.ibm.ibmProd.146.1 (OctetString): Netfinity
Storage.ServeRAID Controller.Logical Drive.Rebuild .Completed
[2] private.enterprises.ibm.ibmProd.146.2 (OctetString): Harmless
[3] private.enterprises.ibm.ibmProd.146.3 (OctetString): NF5000
[4] private.enterprises.ibm.ibmProd.146.4 (OctetString): NF5000
[5] private.enterprises.ibm.ibmProd.146.5 (OctetString): Rebuild complete on
logical drive 1 of controller 1.
[6] private.enterprises.ibm.ibmProd.146.6 (OctetString): Alert
According to our settings in the trap properties, the ServeRAID events are shown
as in Figure 8-19.
Figure 8-19 ServeRAID message in the Event Browser
222
8.3.2 Advanced Systems Management fan failure through UMS client
In 3.6, “Examples” on page 46, we described how to set up the environment for
certain events. One of these events is an Advanced Systems Management fan
failure sent through the UM Services client. This section shows how to set up the
NetView environment to receive the UM Services event in the NetView Event
Browser.
In the Trap Settings window, Figure 8-20, you can find one enterprise ibm with
the ID 1.3.6.1.4.1.2.159 and another one with the ID 1.3.6.1.4.1.2.159.1.1. Both
enterprises and the UM Services traps they contain were added during the
installation of the UIM for NetView. The enterprise ibm with the ID
1.3.6.1.4.1.2.159 represents the traps that are currently used by the UIM. There
are some traps added during the installation of the UIM that are not currently
used that can be found in the enterprise ibm with the ID 1.3.6.1.4.1.2.159.1.1.
Figure 8-20 UM Services traps in the Enterprise ibm
Click on one trap and then Properties to check the settings (Figure 8-21 on
page 224).
223
Figure 8-21 Trap Properties of the iBMPSG_FanEvent
Those events that you want displayed in the Event Browser should have the
corresponding entries in the Trap Properties fields changed to display the events
with the right category and severity. Further, you can customize the Event
Description field by entering meaningful text into the description field as in
Figure 8-22.
Figure 8-22 Fan event in the Event Browser
Right click on the event and click Event Details to see the details provided for
this event (Figure 8-23).
224
Figure 8-23 Fan event details
Because this trap was loaded through the UM Services MIB files, the source
value is Load MIB. It also shows some of the other values that were defined in
the Trap Properties window.
The enterprise and traps for UM Services are set up automatically when you
install the UIM for NetView.
In our test environment, we attempted to load the MIB file for the Remote
Supervisor Adapter (RSA), IBMNFSP.MIB, as supplied on the RSA Configuration
CD-ROM. However, this MIB file contains TRAP-TYPE information, as in the
entry in Example 8-4, and so could not be imported to NetView.
Example 8-4 Trap information to be removed from the original MIB file
ibmRemoteSupTrapRdpsN
TRAP-TYPE
VARIABLES
{
ibmRsTrapDateTime,
ibmRsTrapAppId,
ibmRsTrapSpTxtId,
ibmRsTrapSpNumId,
ibmRsTrapSysUuid,
ibmRsTrapSysSern,
ibmRsTrapAppType,
ibmRsTrapPrority,
ibmRsTrapMsgText
}
DESCRIPTION
"Non-Critical Alert: Redundant Power Supply failure."
::= 10
225
You should change this trap type information part of the MIB file to comment
lines, or you can delete the trap type information in the MIB file, but keep it in a
backup file for setting up the traps later on.
We removed all the TRAP-TYPE entries from the original MIB file.
FTP
Available for download via FTP: The original IBMNFSP.MIB and the
modified IBMNFSP.MIB (with the TRAP-TYPE entries removed) can be
downloaded via FTP. See Appendix C, “Additional material” on page 241 for
details.
After the changes, the content of the MIB file is as listed in Appendix A, “Remote
Supervisor Adapter MIB file” on page 233.
Loading the MIB file will make the trap objects visible through the NetView MIB
Browser as seen in Figure 8-24.
Figure 8-24 NetView MIB Browser
To receive the traps from the Remote Supervisor Adapter we defined a new
enterprise with the ID for the RSA 1.3.6.1.4.1.2.6.158 (Figure 8-25).
226
Figure 8-25 Trap Settings for the RSA
Further, we defined two traps for this enterprise that we needed for our tests. In
our test environment, we defined the traps we needed manually, but you could
also use the addtrap utility in NetView to load the trap information.
The trap information was provided in the original MIB file that we changed to get
it loaded into NetView.
Example 8-5 Trap information used to set up the trap properties in NetView
ibmRemoteSupTrapPoffS
TRAP-TYPE
VARIABLES
{
ibmRsTrapDateTime,
ibmRsTrapAppId,
ibmRsTrapSpTxtId,
ibmRsTrapSpNumId,
ibmRsTrapSysUuid,
ibmRsTrapSysSern,
ibmRsTrapAppType,
ibmRsTrapPrority,
ibmRsTrapMsgText
}
DESCRIPTION
227
"System Alert: Power Off."
::= 23
ibmRemoteSupTrapPonS
TRAP-TYPE
VARIABLES
{
ibmRsTrapDateTime,
ibmRsTrapAppId,
ibmRsTrapSpTxtId,
ibmRsTrapSpNumId,
ibmRsTrapSysUuid,
ibmRsTrapSysSern,
ibmRsTrapAppType,
ibmRsTrapPrority,
ibmRsTrapMsgText
}
DESCRIPTION
"System Alert: Power On."
::= 24
The trap with the specification number 23 sends the message “System Complex
Powered Down.”, and the trap with the specification number 24 sends the
message “System Complex Powered Up.”.
As defined in the trap type information, we used the variables [2]
(ibmRsTrapAppId—source of the trap) and [9] (ibmRsTrapMsgText—message
text). There is more information sent with the trap in other variables:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Date and Time (variable [1]) of the message
ASM name (variable [3])
ASM ID number (variable [4])
UUID (variable [5]
Serial number (variable [6]) of the adapter
Application type which sent the message (variable [7])
Trap priority (variable [8])
To display the value of these variables in the event description of the NetView
Event Browser, use the syntax as shown in Figure 8-26.
228
Figure 8-26 Trap Properties of the RSA Trap
The traps are shown in the Event Browser as seen in Figure 8-27.
Figure 8-27 RSA traps in the NetView Event Browser
To receive and display events from the APC UPS in the Event Browser, we
loaded the APC POWERNET.MIB file. This MIB file is provided by APC, and is
available from:
http://www.apcc.com/tools/download/sw_kit.cfm?sku=sdw22,sdw21,sdw23
229
Alternatively, navigate to the page as follows:
1.
2.
3.
4.
5.
FTP
Browse to http://www.apcc.com
Click Search and search for MIB.
From the results page, click APC - Software Solutions Strategy
Click APC’s SNMP Agents and MIB.
Scroll to the PowerNet MIB section and download the current version. We
used version 3.0.4.
Available for download via FTP: The POWERNET.MIB file can also be
downloaded from the Redbooks site via FTP. See Appendix C, “Additional
We also needed to set up a new enterprise, which we called APC (Figure 8-28).
Figure 8-28 Trap Settings for the APC UPS
The traps we defined for this enterprise are the traps with specification numbers
#5 (The UPS has switched to battery backup power) and #9 (Utility power has
been restored).
More information about the trap properties can be found in the MIB file.
The traps will be shown in the NetView Event Browser similar to Figure 8-29.
230
Figure 8-29 UPS traps in the NetView Event Browser
231
232
A
Appendix A.
Remote Supervisor Adapter
MIB file
This appendix lists the modified version of the Remote Supervisor Adapter MIB
file, IBMNFSP.MIB. It was modified by removing all TRAP-TYPE entries as
described in 6.4.3, “Remote Supervisor Adapter system shutdown” on page 167
for OpenView and 8.3.3, “Remote Supervisor Adapter system shutdown” on
page 225 for NetView.
Example: A-1 MIB file for loading into OpenView and NetView
IBMRSSPPALT-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE
enterprises
DisplayString
TRAP-TYPE
ibm
OBJECT IDENTIFIER ::=
FROM
FROM
FROM
FROM
RFC-1212
RFC1155-SMI
RFC1213-MIB
RFC-1215;
{ enterprises 2 }
-- IBM products group
ibmProd
OBJECT IDENTIFIER ::=
{ ibm 6 }
233
-- IBM Netfinity SP
netfinitySupportProcessor OBJECT IDENTIFIER ::= { ibmProd 158 }
-- IBM Netfinity SP Alert
ibmRemoteSupMIB
OBJECT IDENTIFIER ::= { netfinitySupportProcessor 2 }
----------------------------------------------------------------- Start: IBM Remote Supervisor Adapter SP Alerts
----------------------------------------------------------------- the rsspalt generic trap generator group
ibmRemoteSupMibObjects OBJECT IDENTIFIER ::= { ibmRemoteSupMIB 1 }
ibmRemoteSupTrapInfo OBJECT IDENTIFIER ::= { ibmRemoteSupMibObjects 1 }
ibmRsTrapDateTime OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Timestamp of Local Date and Time when alert was generated"
::= { ibmRemoteSupTrapInfo 1 }
ibmRsTrapAppId
OBJECT-TYPE
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Application ID, always 'IBM Remote Supervisor Adapter Service
Processor'"
ibmRsTrapSpTxtId
OBJECT-TYPE
ACCESS read-only
STATUS mandatory
DESCRIPTION
"SP System Identification - Text Identification"
ibmRsTrapSpNumId
OBJECT-TYPE
ACCESS read-only
STATUS mandatory
DESCRIPTION
234
"SP System Identification - Numeric Identification"
ibmRsTrapSysUuid
OBJECT-TYPE
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Host System UUID(Universal Unique ID)"
ibmRsTrapSysSern
OBJECT-TYPE
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Host System Serial Number"
ibmRsTrapAppType
OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Application Alert Type - Event Number ID"
ibmRsTrapPrority
OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Alert Severity Value
- Critical Alert(0)
- Non-Critical Alert(2)
- System Alert(4)
- Informational Only Alert(255)"
ibmRsTrapMsgText
OBJECT-TYPE
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Alert Message Text"
END
Appendix A. Remote Supervisor Adapter MIB file
235
236
B
Appendix B.
Output of ovobjprint
This appendix lists a sample of the output of the ovobjprint command as
discussed in “Inventory” on page 218.
Example: B-1 UM Services information obtained by the ovobjprint command
C:\>ovobjprint -s NF4500R1
OBJECTID
SELECTION NAME
OBJECT: 1131
FIELD ID
10
11
14
15
73
76
85
99
103
114
116
117
119
120
121
125
126
FIELD NAME
Selection Name
IP Hostname
OVW Maps Exists
OVW Maps Managed
IP Status
isIPRouter
isHTTPSupported
IP Name
vendor
isNode
isComputer
isConnector
isBridge
isRouter
isHub
isPC
isWorkstation
FIELD VALUE
"NF4500R1"
"NF4500R1"
1
1
Normal(2)
FALSE
TRUE
"NF4500R1"
Unset(0)
TRUE
TRUE
FALSE
FALSE
FALSE
FALSE
TRUE
TRUE
237
141
144
147
168
170
172
Multiprocessor
173
174
175
176
213
219
csmacd"
220
221
222
223
224
225
226
227
228
229
230
231
242
6562
7683
8569
9610
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
238
isDHCPClient
FALSE
routerSysName
"sun1"
isIP
TRUE
isWBEM
TRUE
isSNMPSupported
TRUE
SNMP sysDescr
"Windows NT version 5.0 (Build Number: 2195
Free)"
SNMP sysLocation
""
SNMP sysContact
"David Watts"
SNMP sysObjectID
"1.3.6.1.4.1.99.1.1.3.11"
SNMPAgent
EMANATE(171)
TopM Interface Count
1
TopM Interface List "AMD Up 9.24.105.103 255.255.255.0 0x000629D501E2 ethernet
WBEM_Net_ProductName
WBEM_Net_Type
WBEM_Net_MACAddr
WBEM_Net_Manufacturer
WBEM_Net_Desc
WBEM_Net_IPXAddr
WBEM_Net_DHCPServer
WBEM_Net_DHCPEnabled
WBEM_Owner
WBEM_Name
WBEM_PMsupport
WBEM_Domain
XXMAP Protocol List
isUMSHttp
UMS HTTP Port
isUMSSnmp
isUMSCim
UMS_System_Name
UMS_System_Model
UMS_Product_Name
UMS_LCCM_Image_Profile
UMS_LCCM_Image_Date
UMS_System_Serial_Number
UMS_System_GUID
UMS_System_Asset_Number
UMS_AssetID_Tag
UMS_Last_Inventoried
UMS_Purchase_Date
UMS_System_Location
UMS_Level
UMS_System_Cache_Size
UMS_System_Cache_Write_Policy
UMS_Socket_Designation
UMS_Cache_Location
UMS_Chassis_Manufacturer
UMS_Chassis_Type
UMS_Cabinet_Lock_Present
UMS_String
UMS_Lessor
UMS_Lease_Start_Date
"IBM Netfinity Fault Tolerance PCI Adapter"
"Ethernet 802.3"
"00:06:29:D5:01:E2"
"IBM"
"IBM Netfinity Fault Tolerance PCI Adapter"
"<null>"
"<null>"
"FALSE"
"David Watts"
"NF4500R1"
"<null>"
"5388"
"IP"
TRUE
411
TRUE
TRUE
"NF4500R1"
"86561RY"
"Netfinity 5600"
"<null>"
"20010509000000.000000+000"
"23A0088"
"<null>"
"<null>"
"<null>"
"20010509000000.000000+000"
"20010509000000.000000+000"
"<null>"
"3"
"32"
"3"
"Cache Memory 0"
"0"
"IBM"
"23"
"TRUE"
"SW1 1-4 Processor Core Frequency"
"<null>"
"20010509000000.000000+000"
11090
UMS_Lease_End_Date
"20010509000000.000000+000"
11091
UMS_Lease_Term_(months)
"0"
11092
UMS_Lease_Amount
"<null>"
11093
UMS_Label1
"<null>"
11094
UMS_Data1
"<null>"
11095
UMS_Label2
"<null>"
11096
UMS_Data2
"<null>"
11097
UMS_Label3
"<null>"
11098
UMS_Data3
"<null>"
11099
UMS_Label4
"<null>"
11100
UMS_Data4
"<null>"
11101
UMS_Label5
"<null>"
11102
UMS_Data5
"<null>"
11103
UMS_Logical_Name
"Mouse"
11104
UMS_Connector_Type
"59"
11105
UMS_Port_Type
"14"
11106
UMS_Asset
"Video Monitor 0"
11107
UMS_Serial_Number
"<null>"
11108
UMS_Slot_Type
"43"
11109
UMS_Slot_Data_Bus_Width
"2"
11110
UMS_Supports_Hot_Plug
"FALSE"
11111
UMS_Name
"Universal Manageability Services"
11112
UMS_Version
"2.2"
11113
UMS_Build_Number
"WQYT40AUS"
11114
UMS_HTTPD_Port
"411"
11115
UMS_SNMP_Traps_Enabled
"TRUE"
11116
UMS_Trap_Destinations
"public:9.24.105.103,public:9.24.105.102,public:9.24.105.202"
11117
UMS_User_Name
"David Watts"
11118
UMS_User_Phone
"<null>"
11119
UMS_User_Department
"<null>"
11120
UMS_User_Position
"<null>"
11121
UMS_User_Login
"NF4500R1\Administrator"
11122
UMS_Manufacturer
"GenuineIntel"
11123
UMS_Description
"S3 Compatible Display Adapter"
11124
UMS_Current_Vertical_Resolution
"768"
11125
UMS_Current_Horizontal_Resolution
"1024"
11126
UMS_Current_Number_of_Bits_per_Pixel
"16"
11127
UMS_Video_RAM_Memory_Size
"8388608"
11128
UMS_Driver_Filename
"s3sav4"
11129
UMS_Current_Refresh_Rate
"75"
11130
UMS_Color_Depth
"24"
11131
UMS_Warranty_Duration
"0"
11132
UMS_Warranty_End_Date
"20010509000000.000000+000"
11133
UMS_Warranty_Cost
"<null>"
11134
UMS_CIM_Version
"1.50.1085.0008"
11135
UMS_Processor
"CPU0"
11136
UMS_Family
"2"
11137
UMS_Clock_Speed
"733"
11138
UMS_External Clock_Speed
"133"
11139
UMS_Max Clock_Speed
"733"
11140
UMS_Processor_ID
"0000030100000681"
11141
UMS_Processor_Type
"3"
11142
UMS_Device_Locator
"DIMM 1"
Appendix B. Output of ovobjprint
239
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
240
UMS_Size
UMS_Form_Factor
UMS_Type
UMS_Speed
UMS_Data_Width
UMS_Total_Width
UMS_Current_Usage
UMS_Slot_Description
UMS_Supports_PME_Signal
UMS_Shared_Slot_Opening
UMS_BIOS_Manufacturer
UMS_BIOS_Version
UMS_BIOS_Release_Date
UMS_Supports_SMBIOS
UMS_SMBIOS_Major_Version
UMS_SMBIOS_Minor_Version
UMS_Network_Adapter
UMS_Network_Driver
UMS_MAC_Address
UMS_IP_Address
UMS_IP_Subnet_Mask
UMS_IP_Gateway
UMS_DNS_Servers
UMS_DHCP_Enabled
UMS_DHCP_Server
UMS_DNS_Hostname
UMS_DNS_Domain
UMS_IPX_Enabled
UMS_IPX_Frame_Type
UMS_IPX_Address
"536870912"
"8"
"2"
"<null>"
"<null>"
"<null>"
"3"
"PCI Slot 1- 32-bit"
"FALSE"
"FALSE"
"IBM"
"IBM BIOS Ver 0.0"
"19000115******.******+***"
"TRUE"
"2"
"1"
"AMD PCNET Family Ethernet Adapter"
"PCNet5"
"00:06:29:D5:01:E2"
"9.24.105.103"
"255.255.255.0"
"9.24.105.1"
"9.24.106.15"
"FALSE"
"<null>"
"nf4500r1"
"<null>"
"FALSE"
"<null>"
"<null>"
C
Appendix C.
Additional material
This redbook refers to additional material that can be downloaded from the IBM
Redbooks FTP server. Point your Web browser to:
FTP
ftp://www.redbooks.ibm.com/redbooks/SG245388
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the redbook form number, SG245388.
Tip: Directory names and file names are case sensitive
The additional material that accompanies this redbook are as follows:
241
Table C-1 Files available for downloading
File name
Description
\MIB\APC\POWERNET.MIB
This is Version 3.0.4 of the MIB file provided by APC for their UPS
as described in the OpenView and NetView chapters:
򐂰
򐂰
6.4.4, “APC UPS loss of AC power through PowerChute plus”
on page 170
on page 229
The latest version can be obtained from http://www.apcc.com.
\MIB\RSA\Original\IBMNFSP.MIB
This is the original Remote Supervisor Adapter MIB file that
shipped with the RSA Installation CD-ROM. As shipped, it did not
load. We modified this file to remove all the TRAP-TYPE entries as
per the discussions in the OpenView and NetView chapters:
򐂰
򐂰
6.4.3, “Remote Supervisor Adapter system shutdown” on
page 167
page 225
The changed version of this file is in the Changed directory on the
FTP site.
\MIB\RSA\Changed\IBMNFSP.MIB
This is the Remote Supervisor Adapter MIB file we modified to
remove all the TRAP-TYPE entries as per the discussions in the
OpenView and NetView chapters:
򐂰
򐂰
page 167
page 225
It is also listed in Appendix A, “Remote Supervisor Adapter MIB
file” on page 233.
\Tivoli\tecad_snmpRSA_UPS.baroc
Definitions for the class to get Remote Supervisor Adapter and
APC UPS alerts into the Tivoli TEC Server as described in:
򐂰
򐂰
\Tivoli\tecad_snmpRSA_UPS.cds
CDS trap translations for Remote Supervisor Adapter and APC
UPS alerts for the SNMP adapter as described in:
򐂰
򐂰
242
page 128
on page 130
page 128
on page 130
File name
Description
\Tivoli\tecad_snmpRSA_UPS.oid
OID for Remote Supervisor Adapter and APC UPS alerts for the
SNMP adapter as described in:
򐂰
򐂰
page 128
on page 130
\TNG\DIR.MSG
Message and message actions definitions to receive Director traps
in CA Unicenter as described in 7.8.1, “ServeRAID hard disk
failure through Director Server” on page 192.
\TNG\RSA.MSG
Message and message actions definitions to receive Remote
Supervisor Adapter traps in CA Unicenter as discussed in 7.8.3,
“Remote Supervisor Adapter system shutdown” on page 197.
\TNG\UPS.MSG
Message and message actions definitions to receive APC UPS
traps in CA Unicenter as discussed in 7.8.4, “APC UPS loss of AC
power through PowerChute plus” on page 200.
Appendix C. Additional material
243
244
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 246.
򐂰 Tivoli Inventory and Company, SG24-2120
򐂰 An Introduction to Tivoli Enterprise, SG24-5495
򐂰 Integrated Management Solutions Using NetView Version 5.1, SG24-5285
򐂰 Tivoli NetView 6.01 and Friends, SG24-6019
Other resources
These publications are also relevant as further information sources. They are
shipped with the product.
򐂰 IBM Director User’s Guide
򐂰 IBM Remote Supervisor Adapter User’s Guide
򐂰 Managing Your Network with HP OpenView Network Node Manager,
J1240-90035
򐂰 PowerChute Plus User’s Guide
򐂰 ServeRAID Manager User’s Guide
򐂰 Tivoli Software Distribution User’s Guide
򐂰 TME 10 Enterprise Console Adapters Guide
򐂰 TME 10 Enterprise Console Reference Manual
򐂰 TME 10 Enterprise Console Rule Builders Guide
򐂰 TME 10 Enterprise Console Adapters Guide
򐂰 UM Services Plus for Tivoli User’s Guide
򐂰 UM Services User’s Guide
245
Referenced Web sites
These Web sites are also relevant as further information sources:
򐂰 ftp://www.redbooks.ibm.com/redbooks/SG245388
򐂰 http://www.apcc.com
򐂰 http://www.apcc.com/tools/download/sw_kit.cfm?sku=sdw22,sdw21,sdw23
򐂰 http://www.openview.hp.com
򐂰 http://www.pc.ibm.com/training/expert_series.html
򐂰 http://www.pc.ibm.com/support
򐂰 http://www7.pc.ibm.com/~ums
򐂰 http://www.tivoli.com/bpprogram/listings/tivoliready
How to get IBM Redbooks
Search for additional Redbooks or redpieces, view, download, or order hardcopy
from the Redbooks Web site:
ibm.com/redbooks
Also download additional materials (code samples or diskette/CD-ROM images)
from this Redbooks site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and
sometimes just a few chapters will be published this way. The intent is to get the
information out much quicker than the formal publishing process allows.
IBM Redbooks collections
Redbooks are also available on CD-ROMs. Click the CD-ROMs button on the
Redbooks Web site for information about all the CD-ROMs offered, as well as
updates and formats.
246
Special notices
References in this publication to IBM products, programs or services do not imply
that IBM intends to make these available in all countries in which IBM operates.
Any reference to an IBM product, program, or service is not intended to state or
imply that only IBM's product, program, or service may be used. Any functionally
equivalent program that does not infringe any of IBM's intellectual property rights
may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact IBM Corporation, Dept.
600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The information contained in this document has not been submitted to any formal
IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer's ability to evaluate and integrate them into the
customer's operational environment. While each item may have been reviewed
by IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these
techniques to their own environments do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of these
Web sites.
247
The following terms are trademarks of other companies:
Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.
Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli,
and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems
Inc., an IBM company, in the United States, other countries, or both. In
Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.
C-bus is a trademark of Corollary, Inc. in the United States and/or other
countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United States
and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries licensed
exclusively through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks
owned by SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service
marks of others.
248
Abbreviations and acronyms
AC
air conditioning
IBM
International Business Machines
ACF
adapter configuration utility
IIS
Internet Information Server
AMO
Asset Management Option
IP
Internet Protocol
APC
American Power Conversion,
Inc.
IPSec
Internet Protocol Security
IPX
internetwork packet exchange
API
application programming
interface
ISA
industry standard architecture
LAN
local area network
MAC
medium access control
MDAC
Microsoft Data Access
Components
ASM
Advanced System Management
BAROC
basic recorder of objects in C
BIOS
basic input/output system
BPV
business process view
MIB
management information base
CA
Computer Associates
MIF
managed information format
CBA
Common Base Agent
MMC
Microsoft Management Console
CD-ROM
compact disc read only memory
MN
managed node
CDS
class definition statement
MSCS
Microsoft Cluster Services
CFG
config
MSDE
Microsoft Data Engine
CHAP
Challenge-Handshake
Authentication Protocol
NIC
network interface card
CIM
Common Information Model
NMS
network management server
CPU
central processing unit
NNM
Network Node Manager
DM
Distributed Monitoring
ODBC
open database connectivity
DMI
Desktop Management Interface
OID
object identifier
DMTF
Desktop Management Task
Force
OS
operating system
PC
personal computer
EP
endpoint
PCI
peripheral component
interconnect
PFA
predictive failure analysis
PPP
point-to-point protocol
RAID
redundant array of independent
disks
RDBMS
relational database
management system
FTP
file transfer protocol
GUI
graphical user interface
HDD
hard disk drive
HP
Hewlett Packard
HTML
hypertext markup language
HTTP
Hypertext Transfer Protocol
HTTPD
HTTP daemon
RIM
RDBMS Interface Module
HW
hardware
RPM
revolutions per minute
249
RSA
SCSI
small computer system interface
SD
software distribution
SDO
Software Delivery Option
SMBIOS
systems management BIOS
SMS
System Management Server
SNMP
Simple Network Management
Protocol
SP
service processor
SQL
Structured Query Language
SW
software
SWD
TCP/IP
Transmission Control
Protocol/Internet Protocol
TEC
Tivoli Enterprise Console
TMA
Tivoli Management Agent
TME
TMR
Tivoli Management Region
TNG
The Next Generation
UDB
Universal Database
UDP
user datagram protocol
UIM
upward integration module
UM
Universal Manageability
UMS
UM Services
UMSE
UM Server Extensions
UPS
uninterruptible power supply
UUID
universal unique identifier
VPN
virtual private network
WAN
wide area network
WMI
Windows management
instrumentation
WOL
Wake on LAN
250
Index
A
Adapter Configuration Facility 73
Advanced System Management 10, 12, 23, 44
alert example
Tivoli 126
alerts to Tivoli 71
example of alert forwarding
NetView 223
OpenView 165
SMS 147
Unicenter TNG 196
agents
IBM Director 8
Tivoli (TMA) 73
Alert on LAN 35
Alert on LAN Proxy 33
alerts
clients to Tivoli via APIs 93
Director to Tivoli 89
postemsg 72
SMS 142
Tivoli 69
wpostemsg 72
APC PowerChute
See PowerChute
architecture 7
authentication 17, 19
B
background wallpaper 43
baroc file 71
C
CA Unicenter
See Unicenter TNG
Capacity Manager 12, 44
catrapd utility, Unicenter TNG 181
CDS file 70
CIM 9, 26, 136
cim2dmi service 78
cim2mif 120
Unicenter TNG 187
client software distribution, Tivoli 76
clients
IBM Director 8
Tivoli 67
Cluster Systems Management 12, 44
Common Base Agent 36
Common Information Model 9
community string 17
console, IBM Director 12
D
database 40
DB2 41, 112
design considerations 21
Desktop Management Task Force 9
Director support 34
Director Support Program 43
discussion forums 59
Distributed Monitoring, Tivoli 76, 100
DMI 26
cim2dmi service 78
support in UMS 14, 37
DMTF 9
E
element manager 2
email support 60
encryption 18, 20
endpoint, Tivoli 67
enterprise manager agents
security 19
enterprise managers 3
Event Action Plan 48, 90
examples 46
fan failure through UMS 51
NetView 223
OpenView 165
SMS 147
Tivoli 126
Unicenter TNG 196
PowerChute to enterprise manager 58, 200
NetView 229
251
OpenView 170
SMS 147
Tivoli 130
ServeRAID alert through Director 47
NetView 220
OpenView 162
SMS 146
Tivoli 125
Unicenter TNG 192
shutdown alert to enterprise manager 54, 197
NetView 225
OpenView 167
SMS 147
Tivoli 128
F
Fibre Channel Storage Manager 23, 44
SNMP support 11
firewall 18
fixes for OpenView 154
forums 59
FTP 241
Fuel Gauge Monitor 44
G
gateway
Adapter Configuration Facility 73
setting UMS as an event source 96
Tivoli 67
H
hardware element manager 2
hardware inventory
NetView 218
OpenView 161
SMS 140
Tivoli 120
Unicenter TNG 187
help files, UMS 38
HP OpenView
See OpenView
HTTP service 34
HTTPCheck 101
I
IBM Director
additional function that it provides 21
252
alerts to SMS 143
architecture 8
components 8
console 12, 43
database 40
examples 46
installing 29
client 34
console 43
server 39
UM Server Extensions 43
integration 12
OpenView 151
remote control 38
server 11, 21
as the integration point 15
database 40
installation 39
server prerequisites 31
SMS, integration with 137
support 59
Tivoli alerts, sending 89
user authorization 38
why use? 21
IBMNFSP.MIB file 167
installation
IBM Director 29
NetView upward integration module 210
OpenView upward integration module 153
SMS upward integration module 137
Tivoli Plus Module 79
UMS 34
Unicenter TNG upward integration module 176
upward integration modules in UMS 32
integration 12
how to establish? 26
methods 12
SNMP from the client 12
using a UIM 14
via the IBM Director server 15
where to establish? 23
Intel Common Base Agent 36
Intel LANDesk 36
inventory 112
NetView 218
OpenView 161
SMS 140
Tivoli 78
Unicenter TNG 187
IPSec 21
IT Director agent 8
J
Jet database 41
L
LANDesk 36
Linux systems 11
LM sensors 10
Logfile Adapter 74, 96
M
methods of upward integration 12
MIB files
NetView 212
OpenView 154
PowerChute
NetView 229
OpenView 171
customized for NetView 226
customized for OpenView 167
Microsoft Access 41
Microsoft Data Engine 41
Microsoft Management Console 9
Microsoft SMS
See SMS
monitor conflicts 5
multiple events, receiving 75
N
Netfinity Director
See IBM Director
Netfinity Manager
See IBM Director
NetView 205–231
additional functions with UIM 213
alerting 214
Demand Poll option 219
discovery 213
enterprises
APC 230
Director 220
RSA 227
Event Browser 215
examples
PowerChute to enterprise manager 229
shutdown alert to enterprise manager 225
IBMNFSP.MIB 226
inventory 218
MIB files 212
customized for Remote Supervisor Adapter
226
nvsniffer.conf file 213, 219
ovobjprint command 220, 237
POWERNET.MIB file 229
SNMP 206
trapd.conf file 214
UIM installation 33
UMS, launching 217
upward integration module 209
NetWare systems 11
network driver configuration 42
network trace, SNMP 18
O
ODBC data source 41
OID file 70
OpenView 149–174
Alarm Browser, making UMS alerts appear 158
alerts 157
discovery 155
enterprises
directorTraps 162
RSA 168
umservices 159, 166
examples
hardware inventory 161
inventory 161
isUMServicesCim 156
isUniversalService 156
MIB file
customized for Remote Supervisor Adapter
167
MIB, error loading 167
patches 154
Index
253
prerequisites 150
SNMP 157
SNMP settings 150
traps created by the UIM 157
UIM installation 33
UMS 150
UMS alerts via SNMP 151
UMS on the Tools menu 156
UMS, starting from the console 160
upward integration module 152
Oracle 41
P
patches for OpenView 154
physical security 20
positioning 2
postemsg 72, 89
PowerChute
customized CDS, OID, baroc files for Tivoli 131
NetView 229
OpenView 170
SMS 147
Tivoli 130
Unicenter TNG 200
MIB file for NetView 229
MIB file for OpenView 171
sending an SNMP trap 58
SNMP support 11
POWERNET.MIB file
NetView 229
OpenView 171
prerequisites
IBM Director 31
OpenView 150
SMS 136
Tivoli 68
protocols 3
public (community name) 18
Q
queries, Tivoli Inventory 114
R
Rack Manager 44
rawsev variable, wpostemsg 91
readme file 33
254
Redbooks Web site 246
Contact us x
remote control 34, 36, 38
alerts to Tivoli 71
customized CDS, OID, baroc files for Tivoli 129
customized MIB
OpenView 167
customized MIB for NetView 226
NetView 225
OpenView 167
SMS 147
Tivoli 128
Unicenter TNG 197
RIM 66
rule base 85
S
sapack utility 88
screen saver 42
security 16
enterprise manager agents 19
IPSec 21
SNMP 17
suggestions 20
Web based access 20
server
IBM Director 11
ServeRAID
example of alert forwarding 47
NetView 220
OpenView 162
SMS 146
Tivoli 125
Unicenter TNG 192
part of UM Server Extensions 45
ServeRAID Manager 23
SNMP support 11
Tivoli support for SNMP 71
service
SNMP 18
TWGIPC 43
UnicenterTNG UMS Reclassification 179
SETUP.ISS 78
sev variable, wpostemsg 91
SMBIOS 78
SMS 135–147
alerting 142
CIM protocol, use of 136
examples
IBM Director, integration with 137
installing the upward integration module 137
inventory 140
prerequisites 136
SNMP traps 136
software distribution 143
UIM installation 33
SNMP 26
Director example 49
firewall 18
NetView 206
network trace 18
OpenView 150
postemsg, compared with 72
PowerChute, sending a trap from 58
Remote Supervisor Adapter, sending from 54
security 17
sending a trap to TEC 70
sending from the client 12
SMS 136, 143
SNMP Adapter in Tivoli 69
Tivoli 69
Tivoli Plus Module 83
UMS installation option 37
UMS, sending traps from 52
SNMPCheck 101
SMS 143
Tivoli 76, 104
Unicenter TNG 190
software inventory, Tivoli 114
Software Rejuvenation 44
SQL Server 41
support 59
discussion forums 59
documentation 58
email to technical support 60
readme 33, 58
System Availability 45
System Health Monitoring 35
T
TCP/IP port 35
TEC 67
tecad_nt.fmt file 74, 97
tecad_snmp.cds file 70
Tivoli 65–133
Advanced System Management 71, 126
alert flow 71
alert forwarding 69
API calls 93
architecture 66
baroc file 71
adding to a rule base 85
customize for PowerChute 131
customize for Remote Supervisor Adapter
129
CDS file 70
129
Distributed Monitoring 67, 76, 100
endpoint 67
Enterprise Console 67
examples
gateway 67
installing the UIM 79
Inventory 67, 112
Logfile Adapter 74, 96
OID file 70
129
Plus Module 67
alert forwarding 69, 83
features 68
icons 81
Install UM Services 107
installation 79
Launch UM Services 124
Monitors for UM Services 103
Prepare for UM Services Install 104
Reboot UM Services 124
Setup TEC Event Server 93
Shutdown UM Services 124
Index
255
UM Services Inventory Queries 113
Wakeup UM Services 124
postemsg 72, 89
profile managers 114
Remote Supervisor Adapter 71, 128
rule base 85
sapack utility 88
SNMP Adapter 69
SNMP traps to TEC 70
software distribution 67, 76, 104
software inventory 114
TEC 70
tecad_snmp.cds file 70
Tivoli Inventory 78
Tivoli Plus 67
UM_SERVICES event source in TEC 95
Wake on LAN 79
wpostemsg 72, 89
Tivoli Management Agent option 37, 77
Tivoli Management Region 66
Tivoli NetView
See NetView
TMASETUP.ISS file 77
TMR 66
trace, SNMP 18
TWGIPC service 43
TWGIPCCF.EXE 43
U
installing 43
UM Services Plus for Tivoli
See Tivoli, Plus Module
umativdb2.mif file 122
umativoli.mif file 122
uminvdb2.mif file 122
UMS 8
alerts to SMS 142
installation 34
Director support 34
DMI support 37
help files 38
LANDesk 36
SNMP access and trap forwarding 37
System Health Monitoring 35
Tivoli Management Agent 37, 77
Web Based Access 34
256
Web Based Remote Control 36
installing using Tivoli SWD 105
NetView 210
launching from 217
remote control 38
SETUP.ISS file 104, 144
Tivoli Inventory 116
Unicenter TNG UIM, installing 177
Unicenter TNG, launching from 186
use of 10
UMS.MSG file 183
UMS_FP_AFTER.BAT file 105
UMSAGENT.MOF file 114
UMSINST.LOG file 111
umsinv.mif file 122
UMStecad_snmp.baroc 86
UMStecad_snmp.cds file 83
UMStecad_snmp.oid file 83
Unicenter TNG 175–203
actions from an event 183
AimIT 187
alert forwarding 176
alerts 181
Asset Management Option 187
banner action 183, 195
business process view 180
catrapd 181
class browser 177
command action 196
command actions 183
console log 183
event management policies 183
examples
inventory 176, 187
manually reclassify systems 179
opreload command 195
planning 176
reclassification service 178
software distribution 190
trap service, starting 181
UM_Services managed object 180
UMCLIENT.BAT file 187
UMS, launching 186
UMS.MSG file 183
upward integration module
affect on alert messages 184
installation 33
waitoper action 184, 196
upward integration
methods 12
why not use it 5
why use it? 3
upward integration module 14, 26
installation 32
NetView 209
OpenView 152
SMS 135
Tivoli 67
See also Tivoli, Plus Module
Unicenter TNG 176
user authorization 38, 42
W
Wake on LAN 42
Tivoli 79, 124
wallpaper 43
Web based access 20, 34
Web Based Remote Control 36
wfilesig command 116
Windows
SNMP Service 18
UnicenterTNG UMS Reclassification service
179
Windows Event Log
SMS alert action 143
Windows Logfile Adapter 74, 96
wlssrc command 95
workgroup manager 3
wpostemsg 72, 89
wtdumprl command 98
Index
257
258
Back cover
®
Integrating IBM Director
with Enterprise
Covers five of the
major enterprise and
workgroup
managers
Describes
integration with IBM
^ xSeries
hardware
Provides real-world
examples of event
forwarding
With the introduction of the new range of IBM ^
systems, it has become increasingly important to integrate all
the servers that a customer has. One aspect of that
integration is the consolidation of systems management.
Many customers already have an enterprise management
system to manage all of their computer systems, with
centralized alerting, problem determination, inventory, and
the like. However, those enterprise managers typically do not
provide hardware-level information, so tools such as IBM
Director have been developed to pass it onto the enterprise
managers.
This redbook describes how to integrate IBM Director and
xSeries hardware with the following enterprise and
workgroup managers:
򐂰
򐂰
򐂰
򐂰
򐂰
Microsoft SMS
HP OpenView
CA Unicenter TNG
Tivoli NetView
By implementing this integration, customers can receive
alerts and other information from the xSeries hardware and
make it available to administrators along with the rest of the
management information from their other platforms.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
SG24-5388-01
ISBN 0738422649