Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

Transcription

1 Front cover Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery Solution to automatically install endpoint code on new workstations Implement NetView discovery-initiated scanning and distribution Learn NetView Integration Module for Configuration Manager Vasfi Gucer Ashish Bahuguna Olusegun Egungbohun Paul Field Carrie Horwedel Rajesh Kannaujia ibm.com/redbooks

2

3 International Technical Support Organization Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery April 2003 SG

4 Note: Before using this information and the product it supports, read the information in Notices on page ix. First Edition (April 2003) This edition applies to Tivoli Management Framework Version 4.1, IBM Tivoli Configuration Manager Version 4.2, and IBM Tivoli NetView Version Copyright International Business Machines Corporation All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Figures vii Notices ix Trademarks x Preface xi The team that wrote this redbook xi Become a published author xiii Comments welcome xiii Chapter 1. Introduction Short description of the solution Systems overview Objectives Features Benefits of the solution Tivoli management solution, Configuration Manager, and NetView.. 4 Chapter 2. High-level design and architecture Architecture overview Products used in the solution Infrastructure diagram used for testing our scenarios Step one: Discovering new nodes with NetView Discovering new nodes with NetView: Process flow Step two: Automated endpoint installation script Summary of the winstlcf command The logic the script follows Automated endpoint installation script: Process flow Step three: Automated inventory scans Configuring inventory profiles or using scripts to create profiles Inventory scan scenario using Activity Planner Brief overview of Activity Planner Distributing a scan using the command line interface Step four: Extending the solution Creating a software distribution package Distributing a software package using Activity Planner Distributing a software package using the command line interface NetView Integration Module for Configuration Manager Copyright IBM Corp All rights reserved. iii

6 Chapter 3. Implementation Discovery of nodes by NetView Prerequisites to discover the nodes with NetView Summary of steps to discover nodes with NetView Tivoli management agent installation on discovered nodes Tivoli management agent installation prerequisites Summary of steps to install Tivoli management agent on nodes Inventory scan on nodes with Tivoli management agent installed Inventory scan prerequisites for nodes Summary of inventory scan steps Software Distribution and Inventory details Software Distribution and Inventory prerequisites Software Distribution and Inventory steps Chapter 4. Installation, configuration, and administration Installation sequence Tivoli Management Region server RDBMS host RIM host IBM Tivoli NetView NetView Integration Module for Configuration Manager Source host Gateways and depots Setting up your environment: Installing the solution Configuration UNIX scenario: Configuration and script execution Windows NT scenario: Configuration and script execution Tivoli policy regions, profile managers, and tasks Administration and troubleshooting Troubleshooting the scripts Generic problem determination outline Troubleshooting Tivoli Management Framework Version Troubleshooting Software Distribution Troubleshooting Inventory Chapter 5. NetView Integration Module implementation and scenarios NetView Integration Module components NetView Integration Module component list Installing NetView Integration Module components Using IBM Tivoli Network Diagnostics for Configuration Manager Accessing Network Diagnostics from the command line interface Accessing Network Diagnostics from the NetView console Configuring and using Tivoli Discovery from NetView iv Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

7 5.5.1 Configuring Tivoli Discovery Displaying your Tivoli environment Generating reports Configuring and using Tivoli Wake on LAN IBM Tivoli NetView Integration Module for Configuration Manager Installing the IBM Tivoli NetView Integration Module components Installing IBM Tivoli NetView Integration Adapter Installing IBM Tivoli NetView Integration Module Installing RDBMS tables and views Creating the NetView Inventory query library Using IBM Tivoli NetView Integration Module Tivoli Inventory schema additions Chapter 6. Extending the solution and best practices Possible extensions of the solution Best practices Definition Strategy Scope Appendix A. Scripts used in this publication rk_first.sh rk_second.sh rk_third.sh rk_fourth.sh Appendix B. Additional material Locating the Web material Using the Web material System requirements for downloading the Web material How to use the Web material Abbreviations and acronyms Related publications IBM Redbooks Other resources How to get IBM Redbooks IBM Redbooks collections Index Contents v

8 vi Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

9 Figures 2-1 Our Tivoli infrastructure for the scenarios Discovering new nodes with NetView: Process flow Automated endpoint installation script: Process flow The script checks the exclusion list before proceeding Script execution Endpoint statistics for the newly installed endpoint Output from an inventory query for unep The nv_exclude.lst file Output from an inventory query for endpoint unep Activity Planner showing New_Endpoint_Scan plan Activity Plan Monitor showing the successful inventory scan Endpoint statistics for the newly installed node Activity Plan for Endpoint_SWD Activity Plan Monitor showing successful installation Tivoli environment used in the scenarios Install Product selection Select Product to Install list Clients to Install On list Successful installation message NetView Report example Select Product to Install list Start the installation Successful installation message Policy Region window Set Managed Resources dialog box Profile Manager window Create Profile dialog box New profile icon NetView Inventory Profile dialog box Add Entry to NetView Inventory Profile dialog box NetView Inventory Profile: Objects To Export list Distribute Profile dialog box Add Scheduled Job dialog box NETVIEW_QUERIES dialog box Extension of the solution to IBM Tivoli Monitoring Copyright IBM Corp All rights reserved. vii

10 viii Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

11 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright IBM Corp All rights reserved. ix

12 Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX 5L AIX AS/400 DB2 IBM ibm.com NetView OS/2 OS/390 OS/400 Redbooks Redbooks (logo) RS/6000 Tivoli Tivoli Enterprise Tivoli Enterprise Console Wake on LAN WebSphere The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. 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. x Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

13 Preface This IBM Redbook describes a solution to provide readers with the ability to automatically install endpoint code and perform inventory scans and required software distributions on new workstations that have been discovered by IBM Tivoli NetView, reducing the time and effort it takes to manually gather and maintain current information in a distributed environment. Using IBM Tivoli Configuration Manager Version 4.2 and NetView Version 7.1.3, this solution will benefit the reader by providing reliability, potential cost reduction, and rapid time-to-value incentives, which free up administrators and allow them to focus on actual IT needs. To get a common understanding of the solution, we provide an overview of the high-level design and architecture, including the different customer environments where this solution can be applied, followed by implementation, scenarios, and extending the solution. This IBM Redbook also covers the IBM Tivoli NetView Integration Module for Configuration Manager (formerly called Tivoli Integration Pack for NetView, TIPN) implementation and scenarios. This publication will assist customer and business partners support staff and managers, and IBM systems engineers who are involved in Tivoli sales or implementation services in general. 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, Austin Center. Vasfi Gucer is an IBM Certified IT Specialist working at the ITSO, Austin Center. He worked with IBM Turkey for 10 years and has been with the ITSO since January He has more than 10 years experience in systems management, networking hardware, and distributed platform software. He has worked on various Tivoli customer projects as a Systems Architect in Turkey and the U.S. Vasfi is also a Certified Tivoli Consultant. Ashish Bahuguna has been working for IBM Global Services, India for three years and is currently working as an IT Specialist in Tivoli Services within the IBM Strategic Outsourcing group. He has extensive experience in large deployments of IBM Tivoli product suites. He holds a B.S. in Electronics and Copyright IBM Corp All rights reserved. xi

14 Telecommunications Engineering and has five years experience in systems management, networking hardware, and distributed platform software. He is an IBM Tivoli Certified and Microsoft Certified Systems Engineer and holds two IBM Patent Awards. Olusegun Egungbohun is an IT Analyst with Softworks Limited in Nigeria, specializing in the design, implementation, and support of enterprise management and security systems. He has over six years IT experience covering networking, systems management, administration, and support. He holds a B.S. degree in Computer Science and Economics, and he is a Microsoft Certified Systems Engineer (MCSE) and a Microsoft Certified Database Administrator (MCDBA). Paul Field is an IT Specialist from Johannesburg, South Africa. He joined the Server Systems Operations division of IBM Global Services in January 2000, as a part of the IBM graduate recruitment program. He has worked in the Tivoli Technical Infrastructure team in South Africa for the past two years and has experience in systems management, administration, and support. He supports the core suite of Tivoli Systems management products, as well as performing Windows and AIX system administration functions. He holds a Bachelor of Commerce degree from the University of the Witwatersrand, with majors in Information Systems and Accounting. Carrie Horwedel has eight years project management experience, distinguished by a Project Management Professional (PMP) certification. Her broad experience includes managing multiple software and manufacturing projects, as well as consulting on project management methodology. She previously worked as a Program Manager for the Tivoli Framework group before her arrival to the ITSO, Austin Center as a Project Leader supporting IBM Tivoli products. Rajesh Kannaujia is currently working as a Deputy Manager (IIS Projects) with Bharat Petroleum Corporation Limited (BPCL), India. He holds a Bachelor of Engineering degree in Computer Science and has more than 12 years experience in the IT field. For the past three years, his team has been involved with the implementation and administration of an Enterprise Systems Management (ESM) solution at BCPL using IBM Tivoli solutions. Before working with ESM projects, he worked as a INGRES DBA and UNIX and Microsoft Windows NT Exchange Administrator, as well as designing, developing, and implementing the various in-house applications in UNIX shell scripts, Ingres, COBOL, and ISP with DB2 and SQL 7. Thanks to the following people for their contributions to this project: Elizabeth Barnes, Stephen Hochstetler International Technical Support Organization, Austin Center xii Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

15 Debbie Bandera, Patrick Davis, Dave Ertl, Mark Fantacone, Craig Lawton, Jonathan Lewis, Mike Mallo, Christopher Peters, Lorin Ullmann, Brian Vassberg, John Whitfield IBM U.S. Become a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html Comments welcome Your comments are important to us! We want our 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: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip Burnet Road Austin, Texas Preface xiii

16 xiv Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

17 1 Chapter 1. Introduction The solution covered in this IBM Redbook is designed to automatically install endpoint code and do inventory scans on new workstations discovered by IBM Tivoli NetView. This solution is based on IBM Tivoli Configuration Manager Version 4.2 and NetView Version This redbook will also cover the NetView Integration Module for Configuration Manager component (formerly called Tivoli Integration Pack for NetView, TIPN) implementation and scenarios. The solution described in this book can also be applied to other IBM Tivoli products, such as IBM Tivoli Monitoring, where it will automatically start monitoring new workstations. In this chapter, we discuss the following topics: Short description of the solution Systems overview Copyright IBM Corp All rights reserved. 1

18 1.1 Short description of the solution Automated installation of endpoint code and inventory scanning on newly discovered endpoints is a highly desired functionality by Tivoli customers worldwide. The solution described in this book provides this requested functionality. In today s IT environment, it is critical to keep your servers, workstations, and other devices up-to-date in terms of software system levels in order to comply with the ever-changing requirements of your business. Using traditional methods to install endpoint code and assess inventory, you must travel to each system, install the code, write down the software and hardware inventory information you collect, and enter the information into a spreadsheet or database program. When users upgrade software and hardware, you must update the spreadsheet or database. This method is time-consuming and difficult to keep current. As a result, administrators and accounting personnel cannot automatically reuse inventory information to perform system and software upgrades and management tasks. However, with the Inventory component, gathering and maintaining up-to-date inventory information in a distributed environment is quick, accurate, and easy. By this automated process, manual intervention is reduced to the barest minimum, freeing administrators and IT staff from mundane tasks to concentrate on actual IT needs. 1.2 Systems overview Objectives In this section, we provide an overview of the solution. We cover the following topics: Objectives Features Benefits of the solution Tivoli management solution, Configuration Manager, and NetView Our objectives are to provide an automated solution with the following features: Capable of installing endpoint code on newly discovered workstations Capable of doing an inventory scan on these workstations 2 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

19 Scalable in medium or large customer sites Reliable Rapid installation Customizable for additional requirements or future enhancements Use of standard IBM Tivoli desktop and products Features The solution can be used as a plug-in-and-operate component. The solution was designed to provide the following features: Easy installation Customizable for future enhancements Use of standard Tivoli products and procedures Independent of product database schema changes Use of standard RDBMS Interface Module (RIM) access to databases available in previous versions of Tivoli products Benefits of the solution Enterprises are becoming more demanding and require faster and more diverse deployment, change, and asset management in order to achieve their goals. This solution is the answer to helping businesses keep up with demanding deployment and asset issues. Some of the benefits to be derived by applying this solution include: Reliability Under administrator control, the system will bring new devices under management and do the appropriate inventory scan for each machine and operating system. Manual intervention is reduced to a minimum. Cost reduction Again, by reducing the amount of manual intervention and freeing administrators from mundane tasks, the IT staff is able to concentrate efforts on actual IT needs. Rapid time-to-value The solution may be used as a plug-in-and-operate component by automatically and continuously adjusting your environment to comply with your time-to-change and cost-to-change requirements. Chapter 1. Introduction 3

20 1.2.4 Tivoli management solution, Configuration Manager, and NetView The following sections provide a brief description of the Tivoli management solution, IBM Tivoli Configuration Manager, and IBM Tivoli NetView. Tivoli management solution Tivoli enterprise management solution provides a consistent management interface to different operating systems and services. It enables administrators to manage users, systems, databases, networks, and applications from one interface and provides a streamlined way to automate and delegate routine, time-consuming tasks. Tivoli consists of an underlying infrastructure known as Tivoli Management Framework and a growing set of Tivoli and third-party management applications that can utilize this framework to manage heterogeneous systems and applications in a consistent manner. Because it uses object technology, the distributed object framework performs the same functions in the same way on platforms with different operating systems (UNIX, Windows NT, OS/390, OS/2, NetWare, and so forth). The basic Tivoli environment employs a three-tiered architecture that consists of the Tivoli server (Tivoli Management Region), managed nodes, and endpoints. The Tivoli server and managed nodes are created by installing Tivoli Management Framework. Endpoints are created by installing endpoint services and select Tivoli Management Framework software on a system. A single system can be the host for a managed node, a gateway, a repeater, and multiple endpoints. When these managed resources are installed in your distributed network, they become your Tivoli environment. See the IBM Redbook An Introduction to Tivoli Enterprise, SG for further details. IBM Tivoli Configuration Manager IBM Tivoli Configuration Manager, Version 4.2, is a solution for controlling software distribution and asset management inventory in a multiplatform environment. It focuses on deploying and managing software in complex, distributed enterprise environments. IBM Tivoli Configuration Manager is a key solution to rapidly and efficiently deploying complex mission-critical or desktop productivity applications to multiple locations from a central point and to gather and maintain the inventory information about hardware and software assets, easily, quickly, and accurately. Tivoli Configuration Manager consists the following main components: Inventory Software Distribution 4 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

21 Software Distribution enables you to install, configure, and update software remotely within your network. Inventory enables you to gather and maintain up-to-date inventory asset management information in a distributed environment. This aids system administrators and accounting personnel to manage complex, distributed enterprises. Tivoli Configuration Manager also provides the following services: Activity Planner Change Manager Resource Manager Web Interface Enterprise Directory Query Facility Activity Planner enables you to define a group of activities that originate from different applications in an activity plan, submit or schedule the plan for running, and monitor the plan while it runs. Change Manager functions with Activity Planner to support software distribution, inventory, and change management in large networks. It uses reference models to simplify the management of the network environment. You can use Resource Manager, together with Software Distribution and Inventory, to perform the management operations for pervasive devices. Resource Manager is installed on a Tivoli server and on the gateways. You can use the Web Interface to install and manage various Tivoli Configuration Manager Web objects. The Web Interface has a server component that pushes software packages, inventory profiles, and reference models from the Tivoli region to the Web Gateway where they are stored until they are pulled by the Web Interface endpoint. With enterprise directory integration, you can exploit organizational information that is stored in enterprise directories in order to determine a set of targets for a software distribution or an inventory scan. The Enterprise Directory Query Facility enables you to select a specific directory object, or container of directory objects, as subscribers for a reference model or an activity plan. Our main focus in this book, however, is on the Inventory component of IBM Tivoli Configuration Manager. Chapter 1. Introduction 5

22 Components used by Inventory Inventory relies on the following components to collect and store information: The Tivoli Management Region server, which is responsible for issuing scan requests to the target systems. The Inventory application, which includes both the graphical user interface (GUI) components and the command line interface (CLI) utilities. The Inventory gateway application, which allows a managed node to act as a gateway for distributing inventory profiles to endpoints. The relational database management system (RDBMS) server and the configuration repository in the RDBMS. The configuration repository is the RDBMS that contains the schema (tables and columns) in which software and hardware inventory information is stored. The configuration repository schema provides a structure for storing information collected during an inventory scan. The RDBMS interface module (RIM) host, which enables Inventory to communicate with an RDBMS. One or more RIM objects, which connect Inventory to the RDBMS for access to the configuration repository. You can configure multiple RIM objects to write Scalable Collection Service (SCS) data in parallel to the configuration repository. The Web Gateway component, if you plan to distribute scans to pervasive devices or allow users to perform inventory scans using the Web Interface. SCS uses the following components for Inventory collections: Repeater sites organized into a repeater hierarchy. Repeater sites are systems that use the multiplexed distribution (MDist 2) service. MDist 2 parameters control the way that information is distributed throughout a Tivoli environment. A repeater hierarchy is the order in which information flows from one repeater to the next and then to the targets of the distributed data. SCS uses a collector hierarchy that mirrors the MDist 2 repeater hierarchy. SCS sends data upstream through this hierarchy, in the opposite direction of MDist 2 distributions. (See the Tivoli Management Framework Planning for Deployment Guide Version 4.1, GC for more information about configuring a repeater hierarchy.) 6 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

23 Collectors, which are repeater sites on which SCS has been installed. Specifically, a collector is an SCS daemon process on either a managed node or gateway that stores and then forwards data to other collectors or to the inventory data handler. This guide refers to any managed node as a collector if SCS has been installed on the node and the node is part of the repeater hierarchy. Collectors are composed of the following components: The depot, which persistently stores data that has been collected from scan targets or other collectors. The queues, which hold the collection table of contents (CTOCs). CTOCs contain, among other things, the name and size of the data file and the source and destination of the collected data. The input queue controls the order in which CTOCs are processed for collection. The output queue controls the order of the CTOCs as they are sent out from the collector. The completed, deferred, and error queues hold CTOCs for completed and deferred data collection and error conditions, respectively. A multithreaded scheduler daemon, which processes input and output queues and controls data flow through the collector depot. A collection manager, which maintains the collector hierarchy based on repeater hierarchy information obtained from the MDist 2 repeater manager. An inventory data handler, which is the Inventory object that receives data from collectors and sends the data to one or more RIM objects. The inventory data handler can be considered the final collector in an Inventory system. Like collectors, the inventory data handler has a depot and queues. However, the inventory data handler decompresses and decodes the data and sends it to one or more RIM objects rather than requesting collection from an upstream collector. The status collector, which collects, stores, and distributes status information for each target in a scan. You can configure the status collector to keep lists of completed scans, successful scans, failed scans, and error messages. The status collector maintains this information throughout the scan, so scan status information is available during the scan. The status collector is installed on the same managed node as the inventory data handler. If that node fails and is restarted, status information tracked by the status collector is automatically restored. The inventory callback object, which performs the following functions: When inventory data cannot be collected using the collector hierarchy, MDist 2 sends the data to the inventory callback object, which sends it to the inventory data handler. The data is then sent through one or more RIM objects to the configuration repository. Chapter 1. Introduction 7

24 For endpoint scans, MDist 2 sends a status message to the inventory callback object indicating whether it successfully delivered the inventory profile to the target. This message indicates only that the endpoint processed the profile, not that the scan data successfully reached the configuration repository. A pervasive callback object. For pervasive device scans, MDist 2 sends a status message to a special pervasive callback object. This message indicates only whether the job for the devices to be scanned was created successfully on the Web Gateway component; the data is not sent through one or more RIM objects to the configuration repository until a device actually connects to the Web Gateway component and a scan occurs. IBM Tivoli NetView In today's computing environments, network management is of strategic importance. IBM Tivoli NetView extends traditional network management to ensure the availability of critical business systems and to provide rapid resolution of problems. NetView is a scalable, comprehensive, distributed network solution that helps provide you with the flexibility to manage mission-critical networks. It helps ensure availability of critical business systems and rapid problem resolution. IBM Tivoli NetView discovers TCP/IP networks, displays network topologies, correlates and manages events and Simple Network Management Protocol (SNMP) traps, monitors network health, and gathers performance data. Tivoli NetView meets the needs of managers of large networks by providing the scalability and flexibility to manage mission-critical environments. IBM Tivoli NetView accomplishes these through its functionality, including: Policy-based management With IBM Tivoli NetView SmartSets, you can group network resources that require similar management and apply policies to these groups. As a result, you can manage a set of resources as though it were a single device. With SmartSets, you can group resources by type, location, vendor, services offered, or other characteristics. For example, you can create a SmartSet containing Cisco routers and then develop a policy requiring these routers to have CPU utilization collected every 30 minutes. As new devices are discovered and added to the SmartSet, policies can automatically extend to include them. As a result, CPU utilization can be automatically collected against these new devices. 8 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

25 Integration with leading vendors such as Cisco To help manage your expanding network, IBM Tivoli NetView integrates with CiscoWorks2000 and provides the device configuration to help efficiently manage Cisco devices. The IBM Tivoli NetView Java Web console and CiscoWorks2000 work together to help simplify the management, configuration, and availability of Cisco equipment in a distributed, heterogeneous environment. Automated event response Tivoli NetView uses a rules-based event correlation engine that graphically constructs guidelines to implement business policies, and it can help diagnose root problems without reporting all symptomatic events. It can manage events locally or centrally, or by propagating them to other Tivoli applications, such as IBM Tivoli Enterprise Console, for advanced event correlation. In addition, Tivoli NetView can handle a variety of actions when responding to events and exceeded thresholds, including paging, , and programmable responses to specific failures. Router fault isolation Router fault isolation is a root-cause analysis feature built in to Tivoli NetView. In the event of a serious network problem, router fault isolation can immediately focus on the failing device and mark affected network regions as unreachable. In response, Tivoli NetView can reduce networking polling of the affected networks, potentially reducing overall event traffic. Without a router fault isolation feature, customizing this function could be expensive and time-consuming. This feature can help simplify root-cause analysis of network failures. Network topology management TCP/IP networks are more complex than ever. Technologies, such as MPLS, Hot Standby Router Protocol by Cisco, and unnumbered serial interfaces, allow for greater network flexibility while also presenting greater network management challenges. In supporting these technologies, Tivoli NetView can help you manage and represent complex topologies and provide accurate status information. In addition, networks often consist of a wide variety of devices, such as hubs, routers, bridges, switches, workstations, PCs, laptops, and printers. With NetView, you can choose which of these devices to manage. Many network management platforms let you exclude a node from being managed, but NetView further enables you to specify which nodes, device types, or address ranges to include or exclude. It can help you focus on your most important devices, and the most important information about those devices. Chapter 1. Introduction 9

26 Widely available management With its scalable design, the IBM Tivoli NetView Web console lets you observe network activity from many locations. Using the Web console, you can view events, node status, and SmartSets and also perform network diagnostics, such as ping, traceroute, demand poll, nongraphical generated Management Information Base (MIB) application, and MIB browser. Distributed network management Tivoli NetView offers flexibility in a distributed environment. With IBM Tivoli NetView Mid-Level Manager, you can distribute management functions to remote locations that cannot support full-scale management. It can perform status polling, threshold setting, event automation, and automatic detection of new or deleted devices. Tivoli NetView Mid-Level Manager also can help minimize administrative overhead and avoid the need for dedicated management systems throughout the network. The NetView Web browser interface lets users view network information from any supported Web browser. NetView also can be configured to operate in a regional mode. When set up this way, NetView can manage a local region, such as a campus or building, and forward selected information to a central NetView server. This can enable local management to handle most problems, while staff members in the network operations center monitor critical systems. It also can enable management in regions where SNMP and Internet Control Message Protocol (ICMP) traffic cannot flow (such as the DMZ). Integration with Tivoli Enterprise products IBM Tivoli NetView can be used by itself to provide network management capabilities, or it can be integrated with other Tivoli Enterprise products for extended capabilities. For example, integration with IBM Tivoli Enterprise Console lets you consolidate and perform correlation against enterprise events, including network events. With Tivoli Inventory, network device information can be added to the Tivoli Inventory database. 10 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

27 2 Chapter 2. High-level design and architecture This chapter provides a high-level design and architure overview of the proposed solution. We also describe the products used, how they were configured, and the scripts we created to achieve the solution. In this chapter, we discuss the scenarios that we used for the solution in this book, and we also cover the necessary checks before implementing the solution in your environment. In this chapter, we discuss the following topics: Architecture overview Step one: Discovering new nodes with NetView Step two: Automated endpoint installation script Step three: Automated inventory scans Step four: Extending the solution NetView Integration Module for Configuration Manager Copyright IBM Corp All rights reserved. 11

28 2.1 Architecture overview To cover the broadest possible customer scenarios, we approached the design and testing on the two most common platforms, UNIX and Microsoft Windows NT. Obviously, the solution we provide will be deployable on both these platforms, so no script alteration is needed, provided you have the prerequisite products installed Products used in the solution Table 2-1 gives you an idea of the products we used to formulate the solution. Table 2-1 Tivoli products Tivoli products Tivoli Management Framework Product level and comments Version or later. IBM Tivoli Configuration Manager Version 4.2. IBM Tivoli NetView NetView Integration Module for Configuration Manager (packaged with IBM Tivoli Configuration Manager) RDBMS Version 7.1 or later is recommended. Formally known as Tivoli Integration Pack for NetView (TIPN). Any supported relational database management system Infrastructure diagram used for testing our scenarios The diagram illustrated in Figure 2-1 on page 13 represents the infrastructure we used for testing the solution. 12 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

29 Our Tivoli Infrastructure for the Scenarios Tivoli Management Region Server (UNIX) NetView Managed Node (Windows NT) Gateway Endpoint Two-way interconnection Tivoli Management Region Server (Windows NT) Database Server RIM Host IBM Tivoli Configuration Manger NetView Integration Module Managed Node (NT) NetView NetView Integration Module Database Client Gateway Endpoint Endpoint Endpoint Endpoint Figure 2-1 Our Tivoli infrastructure for the scenarios Stage one: IP address and operating system from NetView The solution was broken down into three identifiable components. The first stage was the NetView component. This entailed using certain NetView commands to query the NetView database to obtain IP addresses of newly discovered nodes along with the operating system type if the node was SNMP enabled. Stage two: Automatically installing the endpoint agent After the IP address and operating system type is determined, this information is parsed through to the second stage. We describe this stage as the automated endpoint installation process. Depending on the SNMP agent type, we attempt to install the endpoint code. Stage three: Distributing inventory and software profiles Now, we proceed to stage three: automated inventory, software distributions, or any other product distributions you want to add, for example, a distributed monitoring profile. We provide two options. The first option uses the functionality of Activity Planner (a component of IBM Tivoli Configuration Manager) to make Chapter 2. High-level design and architecture 13

30 the necessary distributions. The second option assumes that Activity Planner is not installed and, therefore, uses the command line functionality for distributions of your inventory and software profiles. 2.2 Step one: Discovering new nodes with NetView The script involved in this stage uses the NetView auto discovery node feature to query the NetView object database, using inherent NetView command line functions, as explained in Chapter 3, Implementation on page 25. Note: The scripts that make up the solution are provided on an AS IS basis in Appendix A, Scripts used in this publication on page 143. You can also download the scripts from the IBM redbooks site. See Appendix B, Additional material on page 163 for instructions about how to download the scripts Discovering new nodes with NetView: Process flow Figure 2-2 on page 15 shows a process flow diagram for the first stage in the Tivoli management agent (TMA) installation. 14 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

31 Administrator input Step one in automated Tivoli management agent installation Exclusion list Yes, valid device Check exclusion list Excluded? Yes, do not proceed, exit No, proceed Check object database if previously installed Yes, update log file Installed? Obtain IP from NetView and MIB value if possible IP/MIB value valid? No, proceed to TMA installation script No, not valid OS type Yes, update log file Check exclusion list Excluded? No, proceed Yes, do not proceed, exit Check object database if previously installed Installed? No, proceed to OS detection script Figure 2-2 Discovering new nodes with NetView: Process flow Devices are either SNMP enabled or not. If the community names have been set correctly for your environment, NetView will keep track of this information in its object database. As previously noted, NetView will discover nodes that are SNMP enabled and non-snmp enabled. The challenge is to separate out the non-snmp devices from the SNMP devices, as well as determine the operating system types if possible. By running an ovobjprint command, we can pull out all the SNMP agents that are present in the NetView environment. Based on this result, we can dynamically build our queries, according to the types of SNMP agents discovered. Now that we have a list of SNMP agent types, we mapped them to operating system types using a lookup table (provided with the scripts). Chapter 2. High-level design and architecture 15

32 We now had to formulate a query that would output a list or lists of nodes IP addresses pertaining to specific SNMP agent types. After much deliberation, we decided to use a simple NetView command called uvutil (smartsetutil for Windows NT) to categorize and subsequently query for IP addresses and operating system type (SNMP agent) if applicable. SNMP-enabled devices allow you to determine the operating system type, so we dymancially build the query ruleset based on the ovobjprint output as previously mentioned. We now had a list or lists of IP addresses, with the possibility of an unwanted device, which had been included. So, we employed some of the ruleset options provided by the uvutil command. The command allows you to filter out as many of the unlikely nodes as possible. For example, you can tell it to exclude nodes having port x occupied, implying that product y is installed. By using this logic we are left with a list of nodes that are suitable candidates for the Tivoli management agent code installation. In addition to this filtering, we can also filter out the nodes where the Lightweight Client Framework (LCF) agent is already installed, thereby excluding the possibility of installing the agent again. However, the Tivoli endpoint service must be running at the time the nvsniffer command is executed. Note: The nvsniffer configuration file (nvsniffer.conf) sniffs out ports being used on a node to determine what products or what functions this node serves. It then sets the appropriate field or fields in the NetView database. If the nvsniffer command needs to be run on a regular basis to update the fields in the NetView object database. It is recommended to schedule this command on a daily basis, or as frequently as you deem appropriate for your environment, bearing in mind that it does place additional load on network traffic. As previously mentioned, we also look for nodes already installed with the LCF agent. The nvsniffer.conf file needs an entry in it to cater to the LCF agent sniff when executed. The nvsniffer.conf file may need some configuration if you are not running IBM Tivoli Configuration Manager. IBM Tivoli Configuration Manager ships with an additional nvsniffer.conf file, and this file should be used when running the nvsniffer command. If you are not running IBM Tivoli Configuration Manager, the default nvsniffer.conf file is automatically edited with the appropriate entry when the script is executed for the first time. 16 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

33 2.3 Step two: Automated endpoint installation script From the previous stage, we have now have a list of IP addresses with the corresponding operating system types if applicable. Note: In determining operating system types, we separated the nodes into two lists. The first list contains UNIX machines and the other Windows. If the node in question is SNMP enabled, we are certain about our categorization. However, if a machine does not have an SNMP agent running, how do we determine operating system type? The answer is we cannot, but through this process, we filtered out as many of the non-windows machines as possible. There are tools on the market that can determine operating system type, but listing these tools here is beyond the scope of this book. This stage uses a UNIX shell script. The script, as you will see in Chapter 3, Implementation on page 25, uses the winstlcf command. As you may already know, the winstlcf command can determine the operating system type for UNIX-based machines by running an uname command. That takes care of the Tivoli-supported flavors of UNIX for installation purposes, but leaves us guessing to a certain extent about Windows machines. Remembering that Windows 98 is not supported by the winstlcf method, we attempt to install the code; if unsuccessful, the appropriate action would need to be taken by the system administrator. In all our scripts, there are detailed log files to guide you for debugging purposes if necessary. The script can be run on both platforms as per the infrastructure diagram shown in Figure 2-1 on page 13. To give you a better understanding of the winstlcf command, we provide a summary of the command functions and flags used in our scripts Summary of the winstlcf command The winstlcf command installs an endpoint on all operating systems except AS/400, OS/2, and Windows 98. Syntax The syntax of the winstlcf command is as follows: winstlcf [ f file_name][ g machine[+port][:machine[+port][ N endpoint][ Y] Description The winstlcf command installs and starts the endpoint service (lcfd) on one or more workstations. This command can be used to install an endpoint on all operating systems except OS/400, OS/2, and Windows 98. For OS/2 and Chapter 2. High-level design and architecture 17

34 Windows 98, use the provided InstallShield program or Tivoli Software Installation Service. For Windows workstations, the first endpoint installed in a domain must be installed using the InstallShield image. For additional endpoints, use winstlcf N to reference that endpoint as a proxy. This proxy installs all other Windows endpoints in this domain or trust. By default, the endpoint service starts after installation. You can install endpoints to multiple workstations by listing the machine names on the command line or using the f option to specify a file that contains a list of machine names. If you run winstlcf on a machine more than once, you have more than one instance of lcfd running on that machine. Only one instance of lcfd should exist on each machine. Remove any additional instances The logic the script follows The following lists some of the logic the script follows. More details are in Chapter 3, Implementation on page Checks the NetView interpreter type. 2. Checks the exclusion list. 3. Checks the Tivoli object database to prevent duplicate installations. 4. Runs the winstlcf command for UNIX and Windows installations. 5. Performs set label of new endpoint. 6. Creates the appropriate log files. 7. Parses the necessary values to the third stage script Automated endpoint installation script: Process flow The diagram in Figure 2-3 on page 19 illustrates the process flow of the endpoint installation script. 18 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

35 Values parsed from previous script Administrator built exclusion list Script Target endpoint machine Tivoli object database Log files Figure 2-3 Automated endpoint installation script: Process flow 2.4 Step three: Automated inventory scans We used two different distribution methods for the inventory hardware and software scans and software distributions: The first distribution method uses the given functionality of IBM Tivoli Configuration Manager to run the scans and distributions. For detailed instructions about the configuration of Activity Planner (which ships with IBM Tivoli Configuration Manager), refer to All About IBM Tivoli Configuration Manager Version 4.2, SG The second distribution method uses the command line functionality to make the appropriate distributions Configuring inventory profiles or using scripts to create profiles We provide scripts to create hardware and software inventory profiles. You can customize them to suit your needs, or you can use your existing profiles. Chapter 2. High-level design and architecture 19

36 See Appendix A, Scripts used in this publication on page 143 for the profile creation and customization scripts Inventory scan scenario using Activity Planner If you use Activity Planner to schedule and distribute your scans, see All About IBM Tivoli Configuration Manager Version 4.2, SG Activity Planner automatically picks up and scans the newly installed endpoints in the same manner as you have done with your existing endpoints. Running tasks and doing software distributions and inventory scans are the part of the operations performed in an enterprise on a daily basis. Activity Planner takes care of all these through a graphical user interface Brief overview of Activity Planner Activity Planner is an IBM Tivoli Configuration Manager component that enables you to define a group of activities in an activity plan, submit the plan to be executed, and monitor the execution of the plan. Activities are single operations that are performed on a set of targets, such as profile managers and managed nodes. These activities can be performed at specified times or run as a scheduled activity as a whole. Operations can include software distribution operations, Tivoli Management Framework tasks, and inventory scans. Change Management operations supported by Activity Planner are as follows: Run hardware and software scans Install, remove, undo, accept, commit, and verify software packages Load and unload Delete, send, retrieve single files or groups of files Execute Tivoli Management Framework tasks Activity Planner performs the following action: Manage a group of activities originating from different applications, such as Software Distribution, Inventory, and Tivoli Management Framework, as a single activity from a single machine in the network Distributing a scan using the command line interface In the second distribution method, we used the command line interface functionality of Inventory to make our distributions. At this point, you should have all the information necessary to run a scan, provided you have configured your inventory hardware and software profiles. 20 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

37 The script uses the wdistinv command to make the hardware or software inventory distribution. The basic syntax of the command is as @Endpoint:robbie Specifies the name of the inventory profile you Specifies to distribute the profile to the endpoints named sly and robbie. In our scenario, the endpoint name will be automatically substituted into the script at run time. Summary of the steps so far From the point that the new node was discovered by NetView, we have made prerequisite checks, installed the endpoint code, and subsequently taken an inventory snapshot. 2.5 Step four: Extending the solution With the successful endpoint installation, we can now extended the functionally of this solution. For example, from the previous step, we took an inventory snapshot of the node. Using IBM Tivoli Configuration Manager, we can determine what packages or software is missing from the node and distribute accordingly. Other possibilities may include a distributing monitoring profile. See Chapter 6, Extending the solution and best practices on page 137 for more information Creating a software distribution package In our testing, as you will see in Chapter 4, Installation, configuration, and administration on page 51, we used the IBM Tivoli Configuration Manager prebuilt software packages to make our distributions. In the scripts, we included the command or commands we used to make the distributions. If you want to use this functionality, please follow the customization options for including your software packages. We followed recommendations from All About IBM Tivoli Configuration Manager Version 4.2, SG All About IBM Tivoli Configuration Manager Version 4.2, SG discusses the following topics and best practices for building software packages. Chapter 2. High-level design and architecture 21

38 It provides generic guidelines, best practices, and hints and tips for using IBM Tivoli Configuration Manager as part of an enterprise-wide deployment process. The following Software Distribution business processes will be involved in the overall change management process that applies to your specific environment: Naming standards Software packaging Endpoint control Lenient distributions Endpoints as depots Activity plans Pristine installations Security If you are going to build software packages, we found it useful to define the package as lenient. This simplifies the scripting somewhat, mainly because you do not have to subscribe the endpoint to a profile before making the distribution. Note: Lenient distributions. If you define a software package as lenient, there is no need to subscribe endpoints to the profile to be able to distribute it. In this way, we avoid an operation, such as subscribing and unsubscribing endpoints in our Tivoli Management Region. Usually, this is very helpful when dealing with large numbers of endpoints and distributions. Typically, the target list of endpoints can be built based on grouping endpoints by machine roles in RDBMS. We strongly recommend choosing this option as part of your default software package definitions Distributing a software package using Activity Planner As with inventory distributions, you can use either Activity Planner or the command line interface, if you do not have Activity Planner installed, to install your software packages. As discussed in Chapter 4, Installation, configuration, and administration on page 51, we used Activity Planner to make our software package distributions. The following are some recommendations for configuring activity plans. We recommend keeping your plans simple. When dealing with a large number of packages and distributions, it is sometimes complex to track the number of on-the-fly plans and their statuses. When possible, we recommend assigning one software package per activity plan. In addition, we recommend using naming standards for your activity plans so that you can easily track them. 22 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

39 Please refer to the redbook All About IBM Tivoli Configuration Manager Version 4.2, SG for information about configuring Activity Planner Distributing a software package using the command line interface We also provide the command line syntax to make a software distribution using the winstsp command. You will need to alter the script to incorporate your packages. See Chapter 4, Installation, configuration, and administration on page 51 for more information about customizing the script. We used the winstsp command for making the distributions. To familiarize yourself with the use and syntax of the winstsp command, see Tivoli Software Distribution Reference Manual Version 4.1, GC NetView Integration Module for Configuration Manager Chapter 5, NetView Integration Module implementation and scenarios on page 85 explains the implementation, customization, and administration of the IBM Tivoli NetView Integration Module for Configuration Manager Version 4.2, or simply NetView Integration Module. The NetView Integration Module for Configuration Manager Version 4.2 component integrates NetView and Tivoli applications to provide combined systems and network management. You can use NetView Integration Module to catalog all the network devices in your enterprise. Importing the NetView discovery of Tivoli Management Region members into the Inventory database helps you maintain and diagnose the Tivoli environment. The NetView Integration Module provides you with network device inventory data, reporting functions, and other Tivoli desktop functions from the NetView console. After you have run the schema setup scripts, your Inventory database is ready to be populated with Network device data. There is also an additional task library script that needs to be run in order to build the necessary queries for the network inventory data. NetView Integration Module for Configuration Manager (formerly called Tivoli Integration Pack for NetView, TIPN) uses the NetView object database to populate the additional tables in your Inventory database. To configure this product, the following prerequisites need to be met: Running a schema script (needs to be run to make the necessary changes to the Inventory repository). IBM Tivoli Configuration Manager component. Chapter 2. High-level design and architecture 23

40 Supported and configured database management system. Tivoli NetView Enabler 7.1 for Windows NT (if you are running NetView on Windows). These are explained in more detail in Chapter 5, NetView Integration Module implementation and scenarios on page Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

41 3 Chapter 3. Implementation This chapter provides an overview of the steps required to implement the solution successfully in a user s environment. This chapter covers the points that have to be addressed before implementing this solution in a production environment. The scripts developed to achieve this goal can be executed on UNIX and Windows NT operating systems without modifying the operating system-level changes. This book provides a list of shell scripts that detect the new node discovered by NetView without Tivoli management agent (TMA). Depending on the type of operating system of the node, subsequent Tivoli management agent installation code is executed, and after successful Tivoli management agent installation, inventory details are scanned and stored in the Tivoli Inventory database repository. In this chapter, we cover the following topics: Discovery of nodes by NetView Tivoli management agent installation on discovered nodes Inventory scan on nodes with Tivoli management agent installed Software Distribution and Inventory details Copyright IBM Corp All rights reserved. 25

42 3.1 Discovery of nodes by NetView This section explains how new nodes are discovered by NetView. Note: The scripts that make up the solution are provided on an AS IS basis in Appendix A, Scripts used in this publication on page 143. You can also download the scripts from the ibm redbooks site. The instructions about how to download the scripts are in Appendix B, Additional material on page 163. In this section, we provide the various commands used in the scripts and the prerequisites, which the administrator needs to provide to ensure successful execution. Note: The scripts referenced in this section must be executed on a server installed with NetView and a managed node. In Windows NT (2000), the administrator must execute it from the bash shell Prerequisites to discover the nodes with NetView Before the scripts are executed, the administrator must ensure that the following mandatory parameters are in the scripts: mdir: The directory name. mep_shell: The name of the script to install the Tivoli management agent (endpoint) on a newly discovered node. The full name of the script (followed by extension) must be provided. minp1: The name of NetView agent master file. This file contains all of the agents with the type of operating system. The records in this file contain two columns. First is the name of the agent being identified by the NetView system, and the second column contains the type of operating system (OS) we need to refer to in our script to decide the appropriate action. These two columns are separated by a $ sign. A sample extract of the file is provided in Example 3-1. Example 3-1 Sample NetView agent master file WANServant Probe$SKIP Microsoft Windows NT$NT Microsoft Windows NT 4.0$NT IBM X Station$UNKNOWN Linux UCD-SNMP Agent;$UNIX IBM RS/6000$UNIX 26 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

43 In Example 3-1 on page 26, we notice that the OS types are SKIP, Microsoft Windows NT, UNIX, and UNKNOWN. In scripts, nodes with node type SKIP are not processed, because these pertain to network devices (such as routers, modems, and switches). minp2: List of nodes to be excluded. This entry contains the IP address on the node where Tivoli management agent installation has to be ignored. The sample record of this file is shown in Example 3-2. Example 3-2 Sample list of nodes to be excluded file mfirst_var: Starting name of the output file. This variable creates the file name containing the list of nodes based on the operating system (OS) type generated from NetView. This file is referred to as input into the Tivoli management agent installation script and appears before the OS. If we enter the mfirst_var value as out, the file name is out <OS Name><mlast_va>. mlast_var: Ending name of the output file. This variable creates a file name containing the list of nodes based on the operating system (OS) type generated from NetView. This file is referred to as input into the Tivoli management agent installation script and appears after the OS. If the value provided for mlast_var variable is.nep, the file name is <mfirst_var><os Name>.nep. For Windows NT, if we take the mfirst_var and mlast_var values as previously mentioned, the file name is outnt.nep. mout2: This variable contains the operating system file with the node name and address. This variable s exact name is derived from mfirst_var, the operating system, and the mlast_var parameter (for example, mout2 = $mfirst_var< OperatingSystem> $mlast_var). mout1: Temporary variable name used in the script. mtmp: Temporary variable name used in the script. mtmp1: Temporary variable name used in the script. mlog_sniff: The name of the log file to contain the standard output message and error message generated during the execution of the nvsniffer command. mlog_ovobj: The name of the log file to contain the standard output message and error message generated during the execution of the ovobjprint command. Chapter 3. Implementation 27

44 mlog_nvutil: The name of the log file that contains the standard output message and error message generated during the execution of the nvutil and smartsetutil commands. mdefault_password: True/False is the only value for this. This parameter checks whether or not the administrative account with the password is available. If the value of the mdefault_log parameter is True, it assumes that an administrative account with a password is provided. If the value of the mdefault_log parameter is False, the system assumes that an administrative account will be provided by an administrator at a later time. mdefault_file: The name of the file containing the entry of the operating system administrative account and password. These entries are needed in case the mdefault_password parameter value is set to True. A sample entry in this file is shown in Example 3-3. Example 3-3 Sample mdefault_file NT Administrator adminpassword UNIX root rootpassword Example 3-3 indicates that for all nodes of Windows NT operating systems, a default login and password will be used during Tivoli management agent installation. The same is true for UNIX operating systems. After the mdefault_password parameter is set to True, and the mdefault_file file is not present, or present with a blank account and password, the system logs the message as Blank account / password and resets the mdefault_password value to False. mnvpath: This variable contains the path of the NetView sniffer configuration file (nvsniffer.conf). msniff: This variable contains the exact file name with the path of the NetView sniffer configuration file (nvsniff.conf). This file updates the NetView object database using the sniffer command. mconf: Contains the exact value to verify from the nvsniff.conf file. IF this entry is not present in the nvsniff.conf file, it appends it. The correct details serve only this purpose Summary of steps to discover nodes with NetView Here is the summary of steps to discover nodes with NetView: 1. The execution of the script starts by checking the LCF entry from the nvsniffer.conf configuration file. If the entry is not there, it gets appended with the value of the mconf variable. 28 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

45 2. After checking the LCF entry from the nvsniffer.conf configuration file, the nvsniffer command is executed to update the discovered services on NetView managed nodes and for monitoring the status of these services. Service objects are created in the object database for each service discovered at a node. The command executed is as follows: nvsniffer -f $mtmp >>$mlog_sniff 2>>$mlog_sniff 3. The file name $mtmp with the -f flag is entered to discover and update the specific types of fields in the database. Because full services might involve processing time resulting in a delay in the Tivoli management agent installation and other activities, this file contains the LCF name entered in the mconf variable. 4. After the nvsniffer command completes, the ovobjprint command executes. This command generates the list of all SNMP agents stored within the NetView object database. The command, along with flag or filter used, is as follows: ovobjprint grep -i SNMPAgent grep -iv Collection cut -f 6 sort cut -d"(" -f1> $mtmp 2>>$mlog_ovobj Note: Sometimes the sort command hangs in Windows NT (in the bash shell) when it is executed with the previous command. To avoid this, you can break the command into two separate commands, as follows: ovobjprint> $mtmp1 >>$mlog_ovobj 2>>$mlog_ovobj cat $mtmp1 grep -i SNMPAgent grep -iv Collection cut -f 6 sort cut -d"(" -f1> $mtmp 2>>$mlog_ovobj 5. The above command lists all the SNMP agents stored in the NetView object database. These generated records are further processed to create unique lists of SNMP agents. The nodes where the SNMP agent is not enabled contain the value Unset and are also extracted. It does not matter whether the SNMP agent is enabled or not with the ovobjpring command. 6. Because the list of SNMP agents contains the name in the NetView system, and all these belong to specific operating systems, a separate input file containing the list of all SNMP agents with the appropriate operating system is created with the minp1 variable. We discuss the format of this file in 3.2.1, Tivoli management agent installation prerequisites on page 33. In this solution, a provision is made to cover the Microsoft Windows NT, Windows 2000, Windows XP, and UNIX operating systems. Chapter 3. Implementation 29

46 7. The unique SNMP agents are checked with the minp1 variable, and after it is found in minp1, the operating system in the matched record from minp1 is assigned to the mos variable. At this stage, the output file (mout2) is generated, including the values of mfirst_var, mos, and mlast_var. If the generated SNMP agent is not in the minp1 file, the system assigns the operating system type UNKNOWN to the mos variable and proceeds. 8. The nvutil (smartsetutil on Windows NT) command is executed on the SNMP agent generated by the ovobjprint command to get the list of the nodes IP addresses (name) associated with the SNMP agent using the following command: `echo $mutil_command` e "((SNMPAgent = '$i') && not(islcf = True) && (isnode = True))" >$mtmp1 2>> $mlog_nvutil The value of mutil_command varies with the operating system type where NetView is installed. The value of mutil_command is assigned to smartsetutil if the operating system of the NetView server is Windows NT; otherwise, it is nvutil (for NetView on a UNIX operating system). The $i variable contains the name of the SNMP agent. The output of this command is the list of IP addresses (node names) where Tivoli endpoint code is not installed (using islcf) and other network devices (iscomputer = True generates only computers, that is, PCs, laptops, and servers). Note: It has been noted on the NetView server with Windows NT or 2000 operating systems that output generated by the smartsetutil command also contains a node name with the domain name and some value. Because the system needs only an IP address or computer host name (node name), additional details are extracted using following command: cat $mtmp1 cut -d"(" -f2 cut -d")" -f1>$mtmp This command provides either an IP address or node name and removes all other details that are not required to install the Tivoli management agent code. 9. This solution provides the option not to install Tivoli management agent on all selected nodes with NetView. This facility provides the list of such IP addresses and nodes in the exclusion list (see the minp2 variable in 3.2.1, Tivoli management agent installation prerequisites on page 33,) so the system ignores these nodes even if they are discovered by a NetView system. After the list is generated from NetView, all nodes are compared with the exclusion list, and matching records are ignored. Only IP addresses and nodes that are not found (in exclusion list) are taken for Tivoli management agent installation. 30 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

47 10.To install Tivoli management agent (endpoint code) from a Tivoli Management Region (TMR) or managed node, the administrative account and password of the target machine (where the endpoint has to be installed) is mandatory. In the script, an option is provided to the administrator to provide the administrative account and password (which is common to all machines) so that the system can pick it up automatically after discovering the node and start installing Tivoli management agent. If the administrator does not want to provide the password, the administrator must enter it manually after the nodes are discovered and initiate the Tivoli management agent installation activity. 11.If the administrator wants to add the common administrative account with the password, the administrator must set the mdefault_password variable value to True and provide mdefault_file (file name mentioned in this variable) with the correct type of operating system (Windows NT or UNIX), the administrator account (administrator or root), and the password of the account. 12.The system checks the value of the operating system (Windows NT or UNIX only) and the account and password. If any are blank, the value of the mdefault_password variable is set to False, and the log file is updated with the following. Example 3-4 Account and password are blank message "Under $i OS, user account or password is blank. Update it immediately. Resetting as False to default password variable.." 13.The $i variable indicates the name of the operating system. The system also checks whether or not the file (the mdefault_file variable) containing the list of the OS type and user account and password is present. If the file is not present, system resets the value of the mdefault_password variable from True to False, and the following message is stored in the log file. Example 3-5 The $mdefault_file variable is not present message "File $mdefault_file containing password is not present. Check the filename / directory.." 14.If the mdefault_password variable is set to True, and the file in the mdefault_file variable is present in the stated path with all the required values (operating system, user account, and password), the system selects the user s account and password from this file and associates them with the IP address or node. These details are stored in the file with the name in the mout2 variable. A sample record of mout2 containing the user account and password is shown in Example 3-6 on page 32 (for Windows NT server). Chapter 3. Implementation 31

48 Example 3-6 Sample record of the mout2 file Administrator chuy After attaching the user account and password with the IP address, the system executes the Tivoli management agent installation script. Here, depending on the type of operating system, the correct mout2 file is attached as the input parameter variable for the Tivoli management agent installation script. Along with the mout2 parameter, the operating system is also noted so that the appropriate Tivoli management agent installation command is executed at the Tivoli management agent installation script level (because the Tivoli management agent installation script varies for Windows NT and UNIX operating systems). Note: All operating systems that are shown as UNKNOWN are assigned as Windows NT, and the Windows NT installation code (of Tivoli management agent) is executed. The command used to pass the parameter file along with script file name is as follows: sh $mep_shell $i $mparam $mep_shell is the Tivoli management agent installation shell script name, $i is the operating system (Windows NT or UNIX), and $mparam is the file name containing the list of nodes where Tivoli management agent code has to be installed (mout2). 16.If the value of mdefault_password is set to False, this indicates that the default administrative account and password have not been provided by the administrator, and the script will store only the IP address (or node name) and stop there. Now, the administrator has to edit this file, associate the user account with password, and execute the script starting from the Tivoli management agent installation. The Tivoli management agent installation script in this case will not be executed automatically. 17.After the administrator completes all the entries in the mout2 file, the administrator needs to execute the same command as shown above (sh $mep_shell $i $mparam) to ensure that the Tivoli management agent installation happens for these types of nodes. In this scenario, this command must be repeated for each type of operating system in the mout2 file. 32 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

49 3.2 Tivoli management agent installation on discovered nodes This section explains the implementation strategies required before starting the script to implement the Tivoli management agent code on the discovered node. Note: The server for executing this script must have the privilege to run winstlcf, wep, and tasks. For Windows NT (or 2000) operating systems, the script should be executed in the bash shell Tivoli management agent installation prerequisites The following parameters should be set before executing the Tivoli management agent installation script to complete the steps successfully: mparam: This is the name of first parameter passed from the NetView discovery script. This variable contains the name of the operating system of the nodes where the Tivoli management agent code has to be installed. The value of this parameter variable is assigned automatically and should not be altered. minputfile1: This is the second parameter passed from the NetView discovery script. This variable contains the name of the file containing the nodes (IP address) where the Tivoli management agent code has to be installed. This file also contains the administrative account and password for each node entry. Value of this parameter variable is assigned automatically and should not be altered. mdir: This is the exact path of the directory or folder where these scripts and the input, output, and temporary files are located. minv_shell: This is the name of the script that performs the inventory scan activity. The full name of the Inventory script file is provided with the extension name of the file. minput_source_ep: Specify the endpoint name of the existing and working Windows NT (2000/XP) endpoints in the domain from which systems could remotely install the Tivoli management agent code on other Windows endpoints. minput_source_gateway: Enter the IP address or host name, along with the port number of the gateway to which the endpoint has to log in. If the IP address of the gateway is, for example, (name COCHOSEGW1), the value must be entered as (or COCHOSEGW1+9494). Here, 9494 is the port number. mpolicy_region: Enter the name of the policy region where the task library is located. If the policy region is not present, the system creates it automatically. Chapter 3. Implementation 33

50 mtask_library: The name of the task library that contains the task. This is used while executing the task. The system checks the tasks library in the policy region and creates it if it is not present. mtask_name: Provide the name of the task to be executed. The system creates the task if it is not present in the task library. mtask_file: Provide the name of task to be executed on the endpoint. The system checks it for the presence of the file and path and creates it with the appropriate command if it is not present. mnode_name: Name of the managed node server from which the Tivoli management agent installation script is executed. The task file resides in this server. mlog_success: Enter the name of the log file that will contain a list of all the computers where the Tivoli management agent code has been installed successfully. mlog_failed: Enter the name of the log file that will contain the list of the computers where Tivoli management agent could not be installed. mlog_failedtask: Enter the name of the log file, that will contain the list of the computers where the Tivoli management agent code is installed successfully, but the task could not be executed successfully. mlog_eplog: Provide the name of log file that will contain the list of all the messages (as standard output or error messages) generated during the installation of the Tivoli management agent code, execution of the task, and so forth. Refer to this file for debugging purposes. mresource: This variable contains the list of resources to be added with the policy region during creation. The value of the variable is reviewed before executing the script so that all the desired resources to the policy region are assigned correctly. madmin: The variable that contains the list of administrators that the policy region has to add while creating it. mcheckpol: This variable decides whether policy region, task library, and task have to be verified or created. If the value of mcheckpol is set to True, the system verifies and creates it (if not found); otherwise, it ignores the verification activities after it is set to False Summary of steps to install Tivoli management agent on nodes Following is the summary of the steps to install Tivoli management agent on discovered nodes. Note that the scripts mentioned in this section are executed automatically by the NetView discovery script if the following conditions are true: The mdefault_password parameter is set to True. 34 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

51 All required input is checked and found acceptable. To install Tivoli management agent on discovered nodes: 1. Before starting the actual processing, the system appends the message under all the log files to indicate what time processing was started so that an administrator can start from that point in the log file if any debugging is needed. The message appended in log files is shown in Example 3-7. Example 3-7 Message in the mlog_eplog log file: Start echo "Script of Endpoint started on " `date` >> $i Where the $i variable is the name of log file. 2. The script starts execution after collecting the parameter (two fields) with the operating system and file name containing the list of IP addresses (with the user account and password). 3. The system first checks the input parameter passed from the parent script. If any are found to be blank, it creates the following message in the mlog_eplog log file. Example 3-8 Message in the mlog_eplog log file: Blank parameters "All parameters are not passed to this script..please check.">>$mlog_eplog "usage: inv_script_filename [Operating System {NT UNIX }] [Filename {containing IP Address with user / password}] " >>$mlog_eplog "Stopping the processing of script..." >>$mlog_eplog 4. It stops the execution of the script and further it checks whether or not $minputfile is present. If it is not present, it stops the execution of the script after creating and appending the following message to mlog_eplog log file. Example 3-9 Message in the mlog_eplog log file: $minputfile echo "The parameter Inputfile $minputfile not present..">>$mlog_eplog echo "usage: inv_script_filename [Operating System {NT UNIX }] [Filename {containing IP Address with user / password}] " >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog 5. The system also checks the value of the $mparam_os parameter, and if it does not contain a value of Windows NT, UNIX, or UNKNOWN, the script stops execution after appending the following message to the $mlog_eplog log file. Example 3-10 Message in the mlog_eplog log file: $mparam_os echo "Acceptable operating systems are NT / UNIX " >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog Chapter 3. Implementation 35

52 6. After checking and verifying the input parameter, the system checks the operating system parameter value in $mparam_os. If it is UNKNOWN, it is set to NT, because most of the nodes with an operating system value of UNKNOWN are not enabled with the SNMP agent. Note: Because these nodes mainly pertain to Windows NT, we decided to treat these nodes as Windows NT. 7. The system checks the other input values entered by an administrator, for example, minput_source_ep. It checks the validity of the endpoint using the wlookup command as follows: wlookup -r Endpoint $minput_source_ep >>$mlog_eplog 2>>$mlog_eplog 8. If the $minput_source_ep endpoint is not present in the Tivoli Management Region (TMR) endpoint database, the script stops processing after adding the following message to the $mlog_eplog log file. Example 3-11 Message in the mlog_eplog log file: $minput_source_ep echo "This endpoint $minput_source_ep does not exists under Endpoint list.." >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog 9. If $minput_source_ep is present in the TMR endpoint database, the system checks the status of the endpoint: wep $minput_source_ep status >>$mlog_eplog 2>>$mlog_eplog 10.If the status is OK (running), it proceeds ;otherwise, it stops processing after appending the following message to the $mlog_eplog log file. Example 3-12 Message in the mlog_eplog log file: $minput_source_ep not running echo "This endpoint $minput_source_ep is not running. Check & start it before executing the script." >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog 11.The system does not proceed if any of the previous input and parameter values are not found in a working or proper status. The system verifies the $minput_source_ep parameter, and the operating system parameter is NT. After this verification, the system continues processing. 12.The system checks the operating system, and if it is NT, the following command is executed to install the Tivoli management agent code: winstlcf -N $minput_source_ep -g $minput_source_gateway -f $minputfile -Y -R >>$mlog_eplog 2>>$mlog_eplog 36 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

53 For UNIX operating systems, the following command installs the Tivoli management agent code: winstlcf -f $minputfile -Y >>$mlog_eplog 2>>$mlog_eplog 13.After this command executes, the message is recorded in the $mlog_eplog log file. The administrator should refer to this log file to see the exact message generated during the installation of the Tivoli management agent code. In the Windows NT Tivoli management agent code, the -R flag reboots the machine. 14.After the Tivoli management agent installation finishes, the system checks each and every node using the wep command to see whether or not the Tivoli management agent is installed successfully. The command to check endpoint registration status is as follows: wep $mep status >>$mlog_eplog 2>>$mlog_eplog Where, $mep is the endpoint name (extracted from $minputfile, the first column). 15.If the return code of the previous command is 1 (meaning the endpoint was not found). The $mep value is appended in the $mlog_failed log file. If the return code is 0 (meaning the endpoint successfully registered and is live), the system continues executing task-related steps. 16.The system checks the input value of the $mcheckpol variable. If it is True, the system checks the policy region, task library, and task. If the value of the $mcheckpol variable is False, the system checks for the presence of a policy region, task library, and task. In this case, an administrator must ensure that the correct policy region, task library, and task are present in the TMR; otherwise, an error message will appear. 17.If the value of $mcheckpol is True, the system performs the activities described in the following sections: Policy region, Task library on page 38, and Task on page 38. Policy region The following steps are performed for the policy region: 1. Check and create the policy region (if the policy region name $mpolicy_region is not present). The following command checks this: wlookup -Lr PolicyRegion $mpolicy_region >>$mlog_eplog 2>>$mlog_eplog 2. If the policy region is not present, it is created using the following command: wcrtpr $madmin -m ManagedNode $mresource $mpolicy_region >>$mlog_eplog 2>>$mlog_eplog Where the $mresource variable contains value shown in Example Chapter 3. Implementation 37

54 Example 3-13 Value of $mresource mresource=" -m ManagedNode -m ProfileManager -m Endpoint -m TaskLibrary" We describe the parameters used with this command in 3.2.1, Tivoli management agent installation prerequisites on page 33. The appropriate message is also appended to the $mlog_eplog log file. These messages contain whether it is present, has been created, and so forth. 3. If the policy region was not created successfully, the system returns a message that it could not create the policy region successfully, so the task library or task is not checked or created. Task library The following steps are performed for the task library: 1. After the policy region is verified (or created successfully if missing), the task library is checked under the policy region. The following command checks the task library: wlookup -Lr TaskLibrary $mtask_library >>$mlog_eplog 2>>$mlog_eplog 2. If the task library is not found, it is created using following command: wcrttlib $mtask_library $mpolicy_region >>$mlog_eplog 2>>$mlog_eplog 3. After the task library is created successfully, the verification of the task is complete. The appropriate message is appended to the $mlog_eplog file during the check or creation of the task library. We explain the variables used in the scripts in 3.2.1, Tivoli management agent installation prerequisites on page 33. Task The following steps are performed for the task: 1. The following command is executed to check whether the task is present under the task library. We explain the variables used with the task in 3.2.1, Tivoli management agent installation prerequisites on page 33. wgettask $mtask_library $mtask_name >>$mlog_eplog 2>>$mlog_eplog If the task is not present, the task library proceeds with the following steps. 2. First, it checks whether the task file $mtask_file is present. If it is not present, it creates the file as follows: echo "hostname>host.out">$mtask_file 3. After the system creates or verifies the $mtask_file file, the task is created using the following command: wcrttask -t $mtask_name -l $mtask_library -r user -i default $mnode_name $mtask_file >>$mlog_eplog 2>>$mlog_eplog 38 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

55 4. All messages are appended to the $mlog_eplog log file (including error messages) and generated during the execution of the previous command. 5. If the value of the $mcheckpol parameter is False, this action is ignored by the system. After the $mcheckpol parameter verification, the system executes the following steps. 6. The NetView command (nvutil or smartsetutil) returns the IP address of the node, and endpoint installation is performed using this IP address. Up to this point, the endpoint name of the node is registered with the IP address. The endpoint name used to be the host name of the machine (computer name) for various purposes, because of the Dynamic Host Configuration Protocol (DHCP) environment, the IP addresses kept changing). Therefore, changing the endpoint name from the IP address to the computer name is necessary. To do this, a task is executed to retrieve the computer name of the node, and this is copied from the remote endpoint host machine to the managed node server (from where the script is executed). Using the set_label command, the endpoint name is changed to the computer name: wruntask -t $mtask_name -l $mtask_library -h $mep >>$mlog_eplog 2>>$mlog_eplog 7. This command runs the job at the endpoint level and the host name of the machine is stored in host.out file (as per the $mtask_name file, the command executed is hostname>host.out). 8. The following command copies the host.out file from the endpoint to the server: wadminep $mep get_file host.out host.out >>$mlog_eplog 2>>$mlog_eplog 9. If the task executes successfully at the endpoint, it creates the host.out file, which is copied from the endpoint machine to the managed node server. If the task did not executed successfully, the system generates the following message. Example 3-14 Task not executed successfully message echo "Task could not be executed on $mep node. It shall be executed once more after 5 minutes." >>$mlog_eplog Chapter 3. Implementation 39

56 Note: Generally, after the installation of the Tivoli management agent code, system is rebooted. For this reason, the task might not be executed successfully. To address this, the script is put to sleep for five minutes (generally, the server will reboot within five minutes). The following message to wait for five minutes (300 seconds) is in the log file: sleep 300 After five minutes, the task executes again, and the return code is checked. If it fails again, the following error message is appended to the $mlog_eplog log file: echo "Task could not be executed on $mep node second time..please check..">>$mlog_eplog At this stage, the system appends the $mep value to the $log_taskfailed log file. This indicates that the endpoint was installed on this node, but the task could not be executed. The administrator needs to look into the cause, and after resolving the issue, initiate the inventory scanning activity. 10.After the task executes successfully, the host.out file is copied from the endpoint machine to the managed node machine (with the wadminep command, explained in step 8 on page 39). 11.The installation ^M character is associated with the endpoint name. After the endpoint name is set (from the IP address to the host name), this control character (line break) gets attached, resulting in a problem with accessing the endpoint details. To avoid such situations, following command is executed, which removes the control character from the host.out file (only for managed nodes with a UNIX operating system). Example 3-15 Removing the control character if [ "$mrkos"!= "Windows_NT" ] ; then ex host.out<<end %s/^m//g wq! END fi Note: While copying the script from the UNIX server to the Windows NT server (or visa-versa), the %s/^m//g line breaks into two lines, resulting in an error while executing this command. To avoid this, the administrator must ensure that this command is on a single line only. 40 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

57 12.The endpoint name is changed to the host name of the endpoint: wep $mep set_label -s $minv_ep >>$mlog_eplog 2>>$mlog_eplog 13.At this stage, the value of $mep is appended to the $mlog_success log file. The system generates three types of log files for the endpoint: Tivoli management agent could not be installed. Tivoli management agent was installed, but the task could not be executed. Tivoli management agent installed successfully, and the task was also executed successfully. In the second and third log files, the endpoint is executed for inventory scanning. This is done with the next script. The $minv_shell variable contains the shell script name of the inventory scan. 14.Along with this script, the endpoint name is passed as a parameter variable. The command to do this is as follows: sh $minv_shell $minv_ep Here, $minv_shell is the script name used to perform the inventory scan, and $minv_ep is the endpoint name. Therefore, the inventory details of the $minv_ep endpoint will be scanned. 3.3 Inventory scan on nodes with Tivoli management agent installed This section describes implementation strategies that are required before starting the script to perform a hardware and software inventory scan on the node where the Tivoli management agent code was successfully installed. Note: The server executing this script must have the privilege to run the wsub, wdistinv, wcrtpr, wcrtprfmgr, wsetpm, and wcrtprf commands. For Windows NT (or 2000) operating systems, the script should be executed under the bash shell Inventory scan prerequisites for nodes The following parameters should be updated before starting the inventory scan script on nodes with Tivoli management agent installed to avoid any problems during subscribing and distributing the endpoint: mdir: Enter the directory name of the log file and other parameters used with the inventory scan. Chapter 3. Implementation 41

58 msd_shell: Name of the script that performs the Software Distribution activity. Full name of the Software Distribution script file is provided with the extension name of the file. mlog_inv: Enter the name of log file that contains all the standard messages and error messages generated during script execution. mepname: The parameter (endpoint name) passed by endpoint installation script. mpolicy_region_name: Enter the name of the policy region. The system checks this policy region and creates it if it is not present. An administrator should provide the existing policy region name (if one is already created). mprofile_manager_name: Enter the name of inventory profile manager. The system administrator should enter the existing inventory profile manager name from the policy region. The system creates this inventory profile manager if it is not present in the policy region. mprofile_name: Enter the name of inventory profile. This is used during the subscription and distribution of the endpoint to perform the inventory scan. The system creates the inventory profile if it is not present in the inventory profile manager. mcheckpol: Either True or False must be assigned to the variable. If this variable is set to True, it checks the policy region, inventory profile manager, and inventory profile in the TMR server. If it is set to False, it does not check any of them. resource: This variable contains the list of resources to be added with the Policy region during creation. The value of the variable should be reviewed before executing the script so that all the needed resources to the policy region are assigned correctly. madmin: This variable contains the list of administrators that the policy region added while creating it Summary of inventory scan steps The following is the summary of the steps for an inventory scan on Tivoli management agent installed nodes. Note that this script starts after the successful installation of the Tivoli management agent code on discovered nodes. The execution of this script is initiated from the Tivoli management agent installation on the discovered script with the endpoint name as the parameter variable. 1. First, the following entry is made in the $mlog_invlog variable so that an administrator can refer the Inventory log file to find out the exact status of the result or any error messages. 42 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

59 Example 3-16 Entry made in the $mlog_invlog variable echo "Script of Inventory scanning started on " `date` >> $mlog_invlog 2. The system checks the passed parameter to this program (the $mepname variable). If it is found empty (which means script is called without the parameter), the following message is appended to the $mlog_invlog log file and processing stops. Example 3-17 The $mepname parameter is empty message echo "The parameter value (endpoint name) is missing..." >>$mlog_invlog echo "Usage : ScriptFileName <endpoint_name>.." >>$mlog_invlog echo "Stopping the process. Re-execute it using correct parameter.." >>$mlog_invlog 3. After verifying the input parameter, the system checks whether the policy region, inventory profile manager, and inventory profile are required to be checked and created if unavailable. This decision is made depending on the value associated with the $mcheckpol variable. If is False, the script simply subscribes the endpoint to the inventory profile manager and distributes the profile. If the value of this variable ($mcheckpol) is True, the system performs the activities described in Policy region, Inventory profile manager on page 44, and Inventory profile on page 45. These activities are used to verify and create the policy region, inventory profile manager, and inventory profile. Policy region The following steps are performed for the policy region: 1. The system executes the following command to check whether the policy region $mpolicy_region is present (the value of the $mpolicy_region_name variable is assigned internally to $mpolicy_region): wlookup -r PolicyRegion $mpolicy_region >>$mlog_invlog 2>>$mlog_invlog 2. If the policy region is not found in the system, it appends the following message to the $mlog_invlog log file. Example 3-18 The policy region is not found in the system message echo "Policy Region $mpolicy_region does not exists.. Creating it..">>$mlog_invlog 3. The policy region is created using the following command: wcrtpr $madmin -m ManagedNode $mresource $mpolicy_region >>$mlog_invlog 2>>$mlog_invlog Chapter 3. Implementation 43

60 The $madmin and $mresourse variables are the collection of administrators and resources being assigned with the policy region. For further details, refer to Tivoli Management Framework User s Guide Version 4.1, GC The return code of this command is checked whether the policy region was created successfully or not. If it was created successfully, the following message is appended to the $mlog_invlog log file. Example 3-19 The policy region was created successfully message echo "Successfully created Policy Region $mpolicy_region.." >>$mlog_invlog 5. If the policy region was not created, the following message is appended to the $mlog_invlog log file. Example 3-20 The policy region was not created successfully message echo "Could not create Policy Region $mpolicy_region. Check with Administrator." >>$mlog_invlog 6. If the system is not able to create the policy region, it sends the $mnext variable with the value as False so that the inventory profile manager and inventory profile creation are not initiated (without a policy region, it will fail). Inventory profile manager The system executes these steps after the policy region is found (or is successfully created). The following steps are performed for the profile manager: 1. First, the system checks whether the inventory profile manager $mprofile_manager_name is present using following command: wlookup -Lr ProfileManager $mprofile_manager_name >>$mlog_invlog 2>>$mlog_invlog 2. If the inventory profile manager is present, the following message appends to the $mlog_invlog log file. Example 3-21 The inventory profile manager is present message echo "Inventory profile Manager $mprofile_manager_name already present.." >>$mlog_invlog 3. The system checks for the presence of the inventory profile manager. If the inventory profile manager is not present, the following message appears, and the system creates the profile manager. 44 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

61 Example 3-22 The inventory profile manager is not present message echo "Creating Inventory Profile Manager $mprofile_manager_name since it is not found " >>$mlog_invlog wcrtprfmgr $mpolicy_region_name $mprofile_manager_name >>$mlog_invlog 2>>$mlog_invlog 4. The following message is appended to the log file if the inventory profile manager was not created. Example 3-23 The inventory profile manager was not created message echo "Problem during creation of Inventory Profile Manager $mprofile_manager_name" >>$mlog_invlog In this case, the value of the $mnext variable is set to False, skipping the next steps. 5. If the inventory profile manager is created successfully, the following message appends to the inventory log file, followed by execution of the command to set the profile manager as a dataless profile manager. Example 3-24 The inventory profile manager is created message echo "Created Inventory Profile Manager $mprofile_manager_name" >>$mlog_invlog echo "Setting dataless profile to $mprofile_manager_name profile manager." >>$mlog_invlog wsetpm >>$mlog_invlog 2>>$mlog_invlog The log file is also updated with the result of the command (success or failure). Inventory profile The following steps are performed for the profile: 1. The inventory profile is checked or created after the successful creation (presence) of the inventory profile manager. The system first checks whether the inventory profile is present in the inventory profile manager: wlookup -Lr InventoryConfig $mprofile_name >>$mlog_invlog 2>>$mlog_invlog 2. If the inventory profile is present in the system, the following message is appended to the log file. Example 3-25 The inventory profile is present message echo "Inventory profile $mprofile_name already present.." >>$mlog_invlog 3. If the inventory profile is not present, the system creates it using the following command after appending the message to the $mlog_invlog log file. Chapter 3. Implementation 45

62 Example 3-26 The inventory profile is not present message echo "Creating Inventory Profile $mprofile_name" >>$mlog_invlog InventoryConfig $mprofile_name >>$mlog_invlog 2>>$mlog_invlog 4. If the inventory profile was not created, the following message is appended to the log file. Example 3-27 The inventory profile was not created message echo "Error while setting UNIX S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog 5. If the inventory profile is created successfully, the PC and UNIX software scan parameter is set, so the desired information can be scanned and stored under the repository. The message and the commands are shown in Example Example 3-28 Configuring the inventory profile echo "Created Inventory Profile $mprofile_name" >>$mlog_invlog echo "Updating the PC Software signature & registry scan / update for $mprofile_name " >>$mlog_invlog wsetinvpcsw -r BOTH -s >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ] ; then echo "Completed the setting PC S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog else echo "Error while setting PC S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog fi echo "Updating the UNIX Software signature & registry scan / update for $mprofile_name " >>$mlog_invlog wsetinvunixsw -p BOTH -s >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ] ; then echo "Completed the setting UNIX S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog else echo "Error while setting UNIX S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog 6. After the inventory profile completes, the system subscribes or distributes the endpoint to scan the hardware and software details. The command to subscribe the endpoint with the profile manager is as >>$mlog_invlog 2>>$mlog_invlog 46 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

63 7. The system checks whether the subscription was successful, and accordingly, updates the inventory log file ($mlog_invlog), as follows. Example 3-29 Checking whether the subscription was successful if [ $? = 0 ]; then echo "Endpoint $mepname successfully subscribed to $mprofile_manage_name ProfileManager." >>$mlog_invlog else echo "Error while subscribing Endpoint $mepname to $mprofile_manage_name ProfileManager." >>$mlog_invlog fi 8. The system uses the following command to distribute the subscribed >>$mlog_invlog 2>>$mlog_invlog The system checks the return code of the distribution, and the appropriate message is appended to the Inventory log file, as follows. Example 3-30 Checking the return code of the distribution if [ $? = 0 ] ; then echo "Endpoint $mepname successfully distributed to $mprofile_manage_name ProfileManager." >>$mlog_invlog else echo "Error while distributing Endpoint $mepname to $mprofile_manage_name ProfileManager." >>$mlog_invlog fi 9. After the distribution finishes successfully, the system executes the Software Distribution script using following command and message (in the $mlog_invlog log file). Example 3-31 Executing the Software Distribution script echo "Now executing the script $msd_shell for Software distribution.." >>$mlog_i nvlog sh $msd_shell $mepname Where $mepname is the name of endpoint on which the software distribution will be performed, and $msd_shell is the name of the script with codes to perform the software distribution. Chapter 3. Implementation 47

64 3.4 Software Distribution and Inventory details This section explains how to perform software distribution on the node having inventory details scanned. We describe the various commands used in the scripts and the prerequisites, which the administrator needs to provide to ensure successful execution. Note: The server executing this script must have the privilege to run the wsub, wdinstsp, wcrtpr, wsetpm, and wcrtprf commands. For Windows NT (or 2000) operating systems, the script should be executed under the bash shell Software Distribution and Inventory prerequisites Before the scripts are executed, the administrator must ensure that the following mandatory parameters are in the scripts: mdir: Enter the directory name where this script is being executed. mlog_splog: Name of the log file to contain the standard output and error messages generated during the execution of the Software Distribution script. mendpoint: The parameter (endpoint name) passed by the inventory scanning script. This variable is mandatory to execute the script. msppm: Enter the name of the software profile manager correctly. The administrator must ensure that the software profile manager exists in policy region; otherwise, the software distribution will fail. Before subscribing the endpoint, the system checks whether the software profile manager is present. msppack: Enter the name of the software package (including the version) that is to be distributed (installed) on the endpoint. The administrator must ensure that the correct software package name in the software profile manager is provided Software Distribution and Inventory steps This script starts automatically after the inventory scan is performed successfully with the inventory scan script. The inventory scan script sends the endpoint name as the parameter value to perform the software distribution activity. The following steps are performed for Software Distribution and Inventory: 1. The execution of the script starts by putting the time stamp in the log file as follows. 48 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

65 Example 3-32 Script processing has started message echo Script of Software Distribution started on "`date` >>$mlog_splog 2. Now, the system checks the parameter value passed from the previous script. If the script is not sent (or blank), the system appends the following message to the $mlog_splog log file and stops the processing. Example 3-33 Parameter value is not sent message echo "Wrong input parameter..exiting.." >>$mlog_splog echo "Usage : script_name <Endpoint_name> " >>$mlog_splog echo "Wrong input parametet under Software Distribution script..exiting" 3. The system checks for the software profile manager using the following command: wlookup -r ProfileManager $msppm >>$mlog_splog 4. If the software profile manager is not present in the system, the following message is appended to the $mlog_splog log file. Example 3-34 Software profile manager is not present message echo "Profile Manager $msppm is not present.." >>$mlog_splog 5. If the software profile manager is present, the system subscribes the endpoint and appends the following message in the log file. Example 3-35 Endpoint is subscribed message echo "Subscribing Endpoint $mendpoint to ProfileManager $msppm.." >>$mlog_splog 2>>$mlog_splog 6. The system checks the return code of the wsub command. If it is successful, the following message is appended to the log file. Example 3-36 The wsub command executed successfully message echo "Successfully subscribed Endpoint $mendpoint to ProfileManager $msppm..">>$mlog_splog 7. The following message is appended to the log file if the wsub command did not execute successfully. Example 3-37 The wsub command did not execute successfully message echo "Error while subscribing Endpoint $mendpoint to ProfileManager $msppm..">>$mlog_splog Chapter 3. Implementation 49

66 8. After the endpoint is subscribed to the software profile manager successfully, the software package in $msppack is distributed to it using the following >>$mlog_splog 2>>$mlog_splog 9. The following message appends to the log file if the winstsp command was not executed successfully. Example 3-38 The winstsp command did not execute successfully message echo "Error while distributing Software Package $msppack on Endpoint $mendpoint 10.The following message is appended to the log file after the winstsp command executes successfully. Example 3-39 The winstsp command executed successfully message echo "Successfully distributed Software Package $msppack on Endpoint $mendpoint" >>$mlog_splog 50 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

67 4 Chapter 4. Installation, configuration, and administration This chapter describes the steps required to set up Tivoli environment for the solution implemented in this book. Because we use IBM Tivoli Configuration Manager Version 4.2 and NetView Version for the solution, we base the installation steps on the IBM Tivoli Configuration Manager Version 4.2 and NetView Version environment. Because we assume that the reader is already familiar with Tivoli installation procedures, we do not cover these steps in detail. For more information about the installation of the Tivoli environment, refer to IBM Tivoli Configuration Manager Planning and Installation Version 4.2, GC and Tivoli NetView for UNIX Administrator s Guide Version 7.1, SC In this chapter, we discuss the following topics: Installation sequence Configuration Administration and troubleshooting Copyright IBM Corp All rights reserved. 51

68 4.1 Installation sequence The automated inventory scanning after auto discovery process requires that the following components are installed and configured properly: Tivoli Management Region server Relational database management system (RDBMS) host RDBMS Interface Module (RIM) host NetView NetView Integration Module for Configuration Manager Source host Gateway depots Tivoli Management Region server To step up the Tivoli Management Region server: 1. Install the base operating system. 2. Install the Tivoli Management Region server components of the IBM Tivoli Configuration Manager Version 4.2: IBM Tivoli Inventory Server Version 4.2 IBM Tivoli Software Distribution server Version 4.2 Activity Planner Server Version 4.2 (Activity Plan Editor and Activity Plan Monitor) Configuration Change Manager Version 4.2 MDist 2 GUI Hub-spoke configuration If you have a hub-spoke configuration, you may have one hub or master Tivoli Management Region (TMR) server and several spoke or slave TMR servers that each manage a set of endpoints. In such a case, we recommend that you install the Activity Plan Editor, Activity Plan Monitor, and MDist 2 GUI components in your hub TMR server, because this server will be the central point for the inventory distribution. NetView should be installed either on any managed node of the hub TMR or on the TMR server itself. In IBM Tivoli Configuration Manager Version 4.2, you can install those components on an endpoint if wanted. 52 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

69 4.1.2 RDBMS host RIM host To set up the relational database management system (RDBMS) host: 1. Install the base operating system. 2. Install the RDBMS server. 3. Optionally, create it as a managed node. 4. MDist 2: a. Create an MDist 2 database instance in the RDBMS. b. Create MDist 2 tables using the SQL scripts provided with IBM Tivoli Configuration Manager. 5. Activity Planner: a. Create an Activity Planner database instance in the RDBMS. b. Create Activity Planner tables using the SQL scripts provided with IBM Tivoli Configuration Manager. 6. Inventory: Create an Inventory database instance in the RDBMS. Create Inventory tables using the SQL scripts provided with IBM Tivoli Configuration Manager. To set up the RDBMS Interface Module (RIM) host: 1. Install the base operating system. 2. Install the RDBMS client. 3. Create it as a managed node. 4. Create a RIM object called mdist2. 5. Create a RIM object called planner. 6. Create a RIM object called inventory. After the connection between the RDBMS client and the RDBMS server is available, complete the following steps: Check the RIM connection to the RDBMS by running wrimtest -l mdist2. Check the RIM connection to the RDBMS by running wrimtest -l planner. Check the RIM connection to the RDBMS by running wrimtest -l Inventory. Chapter 4. Installation, configuration, and administration 53

70 4.1.4 IBM Tivoli NetView To set up the NetView server: 1. Install the base operating system. 2. Create it as a managed node. 3. For a UNIX managed node, install NetView from the Tivoli desktop. For a Windows managed node, we run the setup from the NetView code. 4. Set the community names. 5. Configure the seed file if needed NetView Integration Module for Configuration Manager Source host Refer to Chapter 5, NetView Integration Module implementation and scenarios on page 85, for the details about installing the various components of the IBM Tivoli NetView Integration Module for Configuration Manager. To set up the source host: 1. Install the base operating system. 2. Install the IBM Tivoli Configuration Manager Software Distribution gateway component. 3. Install the IBM Tivoli Configuration Manager Software Distribution source host component Gateways and depots To set up the gateways and depots: 1. Install the base operating system. 2. Install the IBM Tivoli Configuration Manager Software Distribution gateway component. 3. Install the IBM Tivoli Configuration Manager Inventory server component. 4. Install the IBM Tivoli Configuration Manager Inventory gateway component Setting up your environment: Installing the solution The solution includes placement of certain scripts that set up the environment and Tivoli interfaces for immediate operation. These scripts run a number of commands and execute other scripts. If required, these commands and scripts 54 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

71 can be executed separately in the event that more customization is needed, or incompatibility issues are found. We create the automatic inventory scanning after auto discovery process structure in the Tivoli Management Region servers for UNIX or Windows environments using the scripts that are shipped with this book. UNIX setup Perform your Tivoli Management Region server setup as described in 4.1.1, Tivoli Management Region server on page 52. The solution setup has to be done in the NetView server. For a hub-spoke configuration, run the solution setup in the hub TMR server s managed node on which NetView is installed. To set up UNIX: 1. Make sure that you have set up the Tivoli environment variables, as usually defined in /etc/tivoli/setup_env.sh. 2. To install the solution, you need to create directories where the scripts will be placed and also where the log will be generated. 3. Make sure that the NetView environment variables are set. Windows setup Perform your TMR server setup as described in 4.1.1, Tivoli Management Region server on page 52. The solution setup has to be done in the NetView server. For a hub-spoke configuration, run the solution setup in the hub TMR server s managed node on which NetView is installed. To set up Windows: 1. Make sure that you have set up the Tivoli environment variables, as usually defined in C:\WINNT\System32\drivers\etc\Tivoli\setup_env.sh. 2. To install the solution, you need to create directories where the scripts will be placed and also where the log will be generated. 3. Make sure that the NetView environment variables are set. In 4.2, Configuration on page 56, there are a few things you need to look out for before running the scripts: The exclusion list and the input needed by the administrators (pertaining to the script) Setting the required script variables Tivoli policy regions, profile managers, and tasks The NetView nvsniffer.conf file (NetView configuration) Chapter 4. Installation, configuration, and administration 55

72 Editing of the seed file in the test environment (NetView configuration) Activity Planner (if used) NetView inventory queries and database configuration (for NetView Integration Module for Configuration Manager) 4.2 Configuration In this section, we describe how we configured and ran the scripts for our two scenarios, UNIX and Windows NT, as shown in the infrastructure diagram in Figure 2-1 on page 13. The scripts cater to UNIX and Windows NT platforms (run under a bash shell in Windows NT), so no script changes need to be made UNIX scenario: Configuration and script execution We configured the following products and machines. UNIX configuration Our UNIX environment was set up with the following configuration: AIX 5L Version 5.1 Tivoli Management Region server and RIM host. Windows 2000 gateway and a number of endpoints as targets. The RDBMS was DB2 Version 7.2 running on AIX 5L Version 5.1. NetView Version for AIX on the Tivoli Management Region server. IBM Tivoli Configuration Manager Version 4.2 installed on the Tivoli Management Region server. After the installation of the environment, we tested the connectivity to our database, and then input the script prerequisite variables before running the script: Edit the exclusion list. Set the required script variables. Create Tivoli policy regions, profile managers, and tasks; nothing was done here, because we let the script create all of the above. Execute the script. Editing the exclusion list We edited the script, as shown in Figure 4-1 on page 57, with the IP addresses of where we did not want the Tivoli management agent code installed. 56 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

73 Note: As described in Chapter 3, Implementation on page 25, we created an exclusion list for Tivoli administrators to enter in IP addresses of devices, computers or any other nodes they do not want to be installed. The name of the file is nv_exclude.lst. The file needs to be populated with IP addresses as shown in Figure 4-1. Figure 4-1 The script checks the exclusion list before proceeding Setting the required script variables To set the required script variables: 1. Specify the path where the script will be executed. In our UNIX scenario, it was /tmp/shell/main/. In order to do this, you need to edit all three scripts: rk_first.sh, rk_second.sh, and rk_third.sh, and set the path for the variable mdir, as shown in Example 4-1. Example 4-1 Setting the path for the mdir variable #### Directory where the scripts are executed###### mdir="/tmp/shell/main/" Chapter 4. Installation, configuration, and administration 57

74 2. Specify a proxy endpoint used for the winstlcf command. This is an endpoint that was installed by the install shield as a proxy endpoint. This proxy endpoint is only needed for Windows NT installations. The following is found in the rk_second.sh script. Example 4-2 Specifying a proxy endpoint ## Input - List of variables like Endpoint name, Gateway etc. For NT Endpoint only minput_source_ep="3b046a" 3. Specify a gateway IP address. Enter an IP address of a gateway in close proximity to the endpoints that you are trying to install. Your select_gateway_policy should subsequently assign the endpoints their correct gateways and alternative gateways. For additional information, see Tivoli Management Framework Reference Manual Version 4.1, SC The following is found in the rk_second.sh script. Example 4-3 Specifying a gateway IP address ## Input - Gateway to which Endpoint has to login must be with:9494 For NT ## Endpoint only e.g. for GW1 it would be GW:9494 ## minput_source_gateway=" :9494" 4. In the rk_second.sh script, you need to enter a value for the mnode_name constant. This is the name of the managed node where the task.sh script will be executed. Example 4-4 shows an example. Example 4-4 Entering a value for the mnode_name constant mnode_name="aix-tmr1b" executed.. ## Name of the ManagedNode on which this script is 5. Set the path to the NetView environment variables on the system that you are working, such as the following. Example 4-5 Setting the path to the NetView environment variables PATH=$PATH:/usr/OV/bin 6. Set path to Tivoli environment variables on the system on which you are working, such as the following. Example 4-6 Setting the path to the Tivoli environment variables PATH=$PATH:/etc/Tivoli/setup_env.sh 7. Set the path to the nvsniffer.conf file in the rk_first.sh script, such as the following. 58 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

75 Example 4-7 Setting the path to the nvsniffer.conf file ###Defining the path of SNIFFER CONFIGURATION FILE mnvpath="/usr/ov/conf/" ## Directory where nvsniffer.conf is present msniff_file=$mnvpath"nvsniffer.conf" Script execution We are now at the stage where we can execute the script. To execute the script: 1. Run the rk_first.sh script. Figure 4-2 shows the output. Figure 4-2 Script execution 2. The script begins processing all the nodes not installed with the Tivoli management agent. For our purposes, we edited the NetView seed file to have only the nodes we wanted to test the installation process on. 3. At every step of the installation process, there are various log files you can view to determine how the script is progressing. The following are some extracts from these log files. The first one that is created is the SNMP agent log (log_ovobj.log), as shown in Example 4-8 on page 60. Chapter 4. Installation, configuration, and administration 59

76 Example 4-8 SNMP agent log ===================================================== Script started on Mon Mar 10 19:54:56 CST 2003 ===================================================== Generating SNMPAgent.. Successfully generated SNMPAgent.. This tells us that the script ran the necessary NetView commands to collect the SNMP information from the NetView object database. 4. The next log file shows the output from the nvsniffer command (log_snigg.log). For further information about this command, see 2.2.1, Discovering new nodes with NetView: Process flow on page 14. Example 4-9 The nvsniffer command output ===================================================== Script started on Mon Mar 10 19:54:56 CST 2003 ===================================================== islcf 9494 TivoliLCF Tivoli TMA * is present under /usr/ov/conf/nvsniffer.conf Started to execute nvsniffer command to update NetView Object database. Executed nvsniffer command to update NetView Object database. 5. Now that the NetView object database has been updated with the appropriate fields, a query is run against the database to build a list of nodes per operating system type for the following three categories: out_unix.nep out_nt.nep out_unknown.nep 6. In our case, the out_unknown.nep file was populated with the following: Administrator password This output explains that the node was discovered as not having the Tivoli management agent installed. It also shows that the node did not have an SNMP agent running; therefore, it was not categorized into a known operating system type. Note: The default.lst file contains the passwords for your UNIX and Windows NT machines. See Example 3-3 on page 28 for the layout of the file. 7. The log shown in Example 4-10 on page 61 provides further information about the categorization of the operating system (log_nvutil.log). 60 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

77 Example 4-10 Contents of log_nvutil.log ===================================================== Script started on Mon Mar 10 19:54:56 CST 2003 ===================================================== Execution of nvutil script on IBM RS/ agent to get the Node without TMA.. Completed the execution of nvutil script for IBM RS/ agent.. Execution of nvutil script on Unset agent to get the Node without TMA.. Completed the execution of nvutil script for Unset agent.. No record under /tmp/shell/main/out_nt.nep file.. No record under /tmp/shell/main/out_unix.nep file.. At this point the script will now attempt to install the endpoint code on the discovered nodes. (log_endpoint.log) ===================================================== Script of Endpoint started on Mon Mar 10 19:55:00 CST 2003 ===================================================== #TMF_Endpoint::Endpoint# 3B046A is alive. Starting Endpoint Installation for NT Operating System. Trying All target endpoints must be Windows NT w32-ix86 machines... Ready to copy files to host : source: aix-tmr1b:/usr/local/tivoli/bin/aix4-r1/../lcf_bundle.40:/usr/local/tivoli/bin/ aix4-r1/../lcf_bundle destination: :(null) files: bin/w32-ix86/mrt/lcfd.exe bin/w32-ix86/mrt/lcfep.exe lib/w32-ix86/mrt/libatrc.dll lib/w32-ix86/mrt/libcpl.dll lib/w32-ix86/mrt/libcpl60.dll lib/w32-ix86/mrt/libdes.dll lib/w32-ix86/mrt/libdes60.dll lib/w32-ix86/mrt/libipx60.dll lib/w32-ix86/mrt/libmem60.dll lib/w32-ix86/mrt/libmd2ep60.dll lib/w32-ix86/mrt/libtcp60.dll lib/w32-ix86/mrt/libmrt.dll lib/w32-ix86/mrt/libmrt60.dll lib/w32-ix86/mrt/libccms_lcf.dll lib/w32-ix86/mrt/libccms60_lcf.dll bin/w32-ix86/mrt/epproto.dat Chapter 4. Installation, configuration, and administration 61

78 bin/w32-ix86/mrt/wlcftap.exe lib/w32-ix86/mrt/msvcrt40.dll lib/w32-ix86/mrt/msvcrt.dll lib/w32-ix86/mrt/msvcirt.dll Endpoint(s) on installed. Configuring... Endpoint Installation over.. Checking the registration of Endpoint with wep command is alive. Function for policy region : aix-tmr1b-region #TMF_PolicyRegion::GUI# #TMF_Task::TaskLibrary# Task Name : TEST_TASK User Name : * Group Name : Task ACL : user Supported Platforms default <install-dir>/generic_unix/tas/task_library/bin/ /test_task_te_dprwwpd a Task Comments Task Name : TEST_TASK/TEST_TASK Task Created : Tue Mar 4 11:27:01 CST 2003 Task Created By : root@aix-tmr1b Task Files default aix-tmr1b /tmp/shell/main/task.sh Distribution Mode : ALI Task Comments : Executing task for node.. ############################################################################ (Endpoint): The task failed to execute (Endpoint): spawn_impl, could not spawn method as user Administrator. ############################################################################ Task over for node. Executing wadminep command to get host.out file.. EXCEPTION spawn_impl, could not spawn method as user Administrator. Performing administrative mode 'get_file' on endpoint ' ' Task could not be executed.. Task could not be executed on node. Please check. Would be trying again first time after 5 min.. Executing task for node.. ############################################################################ Task Name:TEST_TASK Task Endpoint: (Endpoint) 62 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

79 Return Code: Standard Output C:\Tivoli\lcf\dat\1>hostname1>host.out Standard Error Output ############################################################################ Task over for node. Executing wadminep command to get host.out file.. Performing administrative mode 'get_file' on endpoint ' ' As you can see from this log file, the endpoint was successfully installed; however, the task failed. We found that the newly installed machine needs to be rebooted in order for the task to run. We have allowed for this in the script: we set the script to sleep for five minutes, allowing for a reboot to take place. 8. The last stage of the script runs the inventory scan on the node. Example 4-11 shows the log file with this information (log_inv.log). Example 4-11 Contents of log_inv.log ===================================================== Script of Inventory scanning started on Mon Mar 10 20:03:28 CST 2003 ===================================================== Function for Policy Region : Auto_Inventory #TMF_PolicyRegion::GUI# #TMF_CCMS::ProfileManager# Inventory profile Manager Inventory_Scan already present #INV::InventoryConfig# Inventory profile Test_scan already present.. Endpoint unep3 successfully subscribed to ProfileManager. Distribution ID: Scan ID: 21 Endpoint unep3 successfully distributed to ProfileManager. In addition to this you could run further checks to determine that your scans have completed successfully by looking at the MDist GUI, for example. Lastly the remaining logs indicate overall success or failure. The one below shows the endpoint/s that have been successfully installed. ===================================================== Script of Endpoint started on Mon Mar 10 19:55:00 CST 2003 ===================================================== Chapter 4. Installation, configuration, and administration 63

80 9. We can verify that the endpoint has been installed by using the Tivoli Management Framework endpoint statistics. To do this, open up a browser on the Tivoli Management Region server and enter: Where is the IP address of the endpoint, and 9495 is the port number (by default, it is 9495). This should give you a window similar to the one in Figure 4-3, which shows that the endpoint is available and connected to a gateway. Figure 4-3 Endpoint statistics for the newly installed endpoint 10.We can also test whether this endpoint was scanned successfully. To do this, run an inventory query from the Tivoli desktop, which should show that the endpoint was scanned successfully after the installation. Figure 4-4 on page 65 shows the output of such a query. 64 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

81 Figure 4-4 Output from an inventory query for unep3 Note: As previously mentioned, there are two options for running your scans, software distributions and so forth. For the UNIX scenario, we used the command line fuctionality to subscribe the endpoints and make the distributions. If you are going to use Activity Planner for these functions, see the following Windows NT scenario. We used both the Activity Planner and the command line methods Windows NT scenario: Configuration and script execution We configured the following products in our Windows NT scenario. Windows configuration Our Windows environment was set up with the following configuration: Windows NT Tivoli Management Region server and RIM host. Windows 2000 gateway and a number of endpoints as targets. The RDBMS was DB2 Version 7.2 running on Windows NetView Version for Windows on a Windows 2000 managed node. IBM Tivoli Configuration Manager Version 4.2 on the Tivoli Management Region server. Chapter 4. Installation, configuration, and administration 65

82 We configured the products, tested the connectivity to our database, and input the prerequisite variables before running the script. Edit the exclusion list. Set the required script variables. Create Tivoli policy regions, profile managers, and tasks; nothing was done here, because we let the script create all of the above. Script execution. Use Activity Planner to make the distributions and also run the distributions through the command line for both inventory and software distributions. Editing the exclusion list We edited the exclusion list with the IP addresses on which we did not want the Tivoli management agent code installed, as shown in Figure 4-5. Note: As described in Chapter 3, Implementation on page 25, we created an exclusion list for Tivoli administrators to enter in IP addresses of devices, computers, or any other nodes they do not want to be installed. The name of the file is nv_exclude.lst. The file needs to be populated with IP addresses, as shown Figure 4-5 on page 66. Figure 4-5 The nv_exclude.lst file 66 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

83 Setting the required script variables To initialize the script variables: 1. Specify the path from where the script will be executed. In our Windows NT scenario, it was /shell/. In order to do this, you need to edit all three scripts: rk_first.sh, rk_second.sh, and rk_third.sh, and set the path for the mdir variable. Example 4-12 Setting the path from where we executed the script #### Directory where the scripts are executed###### mdir="/shell/" 2. Specify a proxy endpoint used for the winstlcf command. To do this, enter an endpoint name that was installed with the install shield as a proxy endpoint. This proxy endpoint is only needed for Windows NT installations. The following is found in the rk_second.sh script. Example 4-13 Code sample from rk_second.sh ## Input - List of variables like Endpoint name, Gateway etc. For NT Endpoint only minput_source_ep="3b046a" 3. Specify a gateway IP address. Enter an IP address of a gateway in close proximity to the endpoint or endpoints that you are trying to install. Your select_gateway_policy should subsequently assign the endpoints their correct gateways and alternative gateways. For additional information, see Tivoli Management Framework Reference Manual Version 4.1, SC The following is found in the rk_second.sh script. Example 4-14 Code sample from rk_second.sh ## Input - Gateway to which Endpoint has to login must be with:9494 For NT ## Endpoint only e.g. for GW1 it would be GW:9494 ## minput_source_gateway=" :9494" 4. In the rk_second.sh script, you need to enter a value for the mnode_name constant. This is the name of the managed node where the task.sh script will be executed. Example 4-15 shows an example. Example 4-15 Code sample from rk_second.sh mnode_name="win-mn01" executed.. ## Name of the ManagedNode on which this script is Chapter 4. Installation, configuration, and administration 67

84 5. Specify the path to NetView environment variables, such as PATH=%PATH%;/usr/OV/bin, on the machine on which you are executing the script. 6. Specify the path to Tivoli environment variables, such as PATH=%PATH%;/etc/Tivoli/setup_env.sh, on the machine on which you are executing the script. 7. Set the path to the nvsniffer.conf file found in the rk_first.sh script. Example 4-16 Code sample from rk_first.sh ###Defining the path of SNIFFER CONFIGURATION FILE mnvpath="/usr/ov/conf/" ## Directory where nvsniffer.conf is present msniff_file=$mnvpath"nvsniffer.conf" Script execution We are now at the stage where we can execute the script. To execute the script: 1. Run the rk_first.sh script. The script begins processing all the nodes not installed with the Tivoli management agent. For our purposes, we edited the NetView seed file to have only the nodes we wanted to test the installation process on. At every step of the installation process, there are various log files you can view to determine how the script is progressing. Following are some extracts from these log files. 2. The first log file that is created is the SNMP agent log (log_ovobj.log), as shown in Example Example 4-17 SNMP agent log ===================================================== Script started on Tue Mar 11 20:02: ===================================================== Generating SNMPAgent.. Successfully generated SNMPAgent.. This tells us that the script ran the necessary NetView commands to collect SNMP information from the NetView object database. The next script logs the output from the nvsniffer command (log_sniff.log). For further information regarding this command please see *** Chapter 2 ***. ===================================================== Script started on Tue Mar 11 20:02: ===================================================== 68 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

85 islcf 9494 TivoliLCF Tivoli TMA * is present under /usr/ov/conf/nvsniffer.conf Started to execute nvsniffer command to update NetView Object database. Executed nvsniffer command to update NetView Object database. 3. Now that the NetView object database has been updated the appropriate fields, a query is run against the database to build a list of nodes per operating system type for the following three categories: out_unix.nep out_nt.nep out_unknown.nep 4. In our case the out_unknown.nep file was populated with the following: Administrator password This output shows that the node was discovered as not having the Tivoli management agent installed. It also shows that the node did not have an SNMP agent running; therefore, it was not categorized into a known operating system type. Note: The default.lst file contains the passwords for your UNIX and Windows NT machines. See Example 3-3 on page 28 for the layout of the file. 5. The log shown in Example 4-18 provides further information about the categorization of the operating system (log_nvutil.log). Example 4-18 Contents of log_nvutil.log ===================================================== Script started on Tue Mar 11 20:02: ===================================================== Execution of smartsetutil script on Microsoft Windows NT 4.0 agent to get the Node without TMA.. Completed the execution of smartsetutil script for Microsoft Windows NT 4.0 agent.. Execution of smartsetutil script on Unset agent to get the Node without TMA.. Completed the execution of smartsetutil script for Unset agent.. No record under /shell/out_nt.nep file.. No record under /shell/out_unix.nep file.. At this point, the script will now attempt to install the endpoint code on the discovered nodes. (log_endpoint.log) ===================================================== Script of Endpoint started on Tue Mar 11 20:02: ===================================================== Chapter 4. Installation, configuration, and administration 69

86 #TMF_Endpoint::Endpoint# rdm01 is alive. Starting Endpoint Installation for NT Operating System. Trying unep1... All target endpoints must be Windows NT w32-ix86 machines... Ready to copy files to host unep1: source: win-mn01:c:/usr/local/tivoli/bin/w32-ix86/../lcf_bundle.40;c:/usr/local/tivoli/ bin/w32-ix86/../lcf_bundle destination: unep1:(null) files: bin/w32-ix86/mrt/lcfd.exe bin/w32-ix86/mrt/lcfep.exe lib/w32-ix86/mrt/libatrc.dll lib/w32-ix86/mrt/libcpl.dll lib/w32-ix86/mrt/libcpl60.dll lib/w32-ix86/mrt/libdes.dll lib/w32-ix86/mrt/libdes60.dll lib/w32-ix86/mrt/libipx60.dll lib/w32-ix86/mrt/libmem60.dll lib/w32-ix86/mrt/libmd2ep60.dll lib/w32-ix86/mrt/libtcp60.dll lib/w32-ix86/mrt/libmrt.dll lib/w32-ix86/mrt/libmrt60.dll lib/w32-ix86/mrt/libccms_lcf.dll lib/w32-ix86/mrt/libccms60_lcf.dll bin/w32-ix86/mrt/epproto.dat bin/w32-ix86/mrt/wlcftap.exe lib/w32-ix86/mrt/msvcrt40.dll lib/w32-ix86/mrt/msvcrt.dll lib/w32-ix86/mrt/msvcirt.dll Endpoint(s) on unep1 installed. Configuring... Endpoint Installation over.. Checking the registration of Endpoint with wep command.. unep1 is alive. Function for Policy Region : aix-tmr1b-region #TMF_PolicyRegion::GUI# #TMF_Task::TaskLibrary# Task Name : TEST_TASK User Name : * Group Name : Task ACL : user Supported Platforms 70 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

87 default <install-dir>/generic_unix/tas/task_library/bin/ /test_task_te_dprwwpd a Task Comments Task Name : TEST_TASK/TEST_TASK Task Created : 03/10/03 04:48:42 PM Task Created By : WIN-MN01\Administrator@win-mn01 Task Files default win-mn01 c:/shell/task.sh Distribution Mode : ALI Task Comments : Executing task for unep1 node.. ############################################################################ unep1 (Endpoint): The task failed to execute. unep1 (Endpoint): spawn_impl, could not spawn method as user Administrator. ############################################################################ Task over for unep1 node. Executing wadminep command to get host.out file.. EXCEPTION spawn_impl, could not spawn method as user Administrator. Task could not be executed.. Task could not be executed on unep1 node. It shall be executed once more after 5 minutes. Executing task for unep1 node.. ############################################################################ Task Name:TEST_TASK Task Endpoint:unep1 (Endpoint) Return Code: Standard Output C:\Tivoli\lcf\dat\1>hostname1>host.out Standard Error Output ############################################################################ Task over for unep1 node. Executing wadminep command to get host.out file.. Performing administrative mode 'get_file' on endpoint 'unep1' set_label failed, -s already exists. As you can see from this log file, the endpoint was successfully installed; however, the task failed. We found that the newly installed machine needs to be rebooted in order for the task to run. We have allowed for this in the script: we set the script to sleep for five minutes allowing for a reboot to take place. 6. The last stage of the script runs the inventory scan on the node. Example 4-19 on page 72 shows the log file containing this information (log_inv.log). Chapter 4. Installation, configuration, and administration 71

88 Example 4-19 Contents of log_inv.log ===================================================== Script of Inventory scanning started on Tue Mar 11 20:11: ===================================================== Function for Policy Region : Auto_Inventory #TMF_PolicyRegion::GUI# #TMF_CCMS::ProfileManager# Inventory profile Manager Inventory_Scan already present #INV::InventoryConfig# Inventory profile Test_scan already present.. Endpoint unep1 successfully subscribed to ProfileManager. Distribution ID: Scan ID: 26 Endpoint unep1 successfully distributed to ProfileManager. Now executing the script /shell/rk_fourth.sh for Software distribution. 7. In addition, you can run more checks to determine if your scans have completed successfully by looking at the MDist 2 GUI, for example. Figure 4-6 illustrates a hardware query showing that unep1 was successfully scanned. Figure 4-6 Output from an inventory query for endpoint unep1 8. We ran the inventory scans with two methods: the first method used the command line distribution and the second method used Activity Planner. Note: If you are going use Activity Planner, make sure that you comment out the last few lines of the third script pertaining to the wdistinv command. Figure 4-7 on page 73 shows the configured Activity Planner object that was used to run the scan. 72 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

89 Figure 4-7 Activity Planner showing New_Endpoint_Scan plan 9. The Activity Plan Monitor window shows if your endpoint or endpoints scanned successfully. Figure 4-8 is an example of this. Figure 4-8 Activity Plan Monitor showing the successful inventory scan Chapter 4. Installation, configuration, and administration 73

90 10.The remaining logs indicate overall success or failure. The following log shows the endpoint or endpoints that have been successfully installed (log_successep.log). Example 4-20 Endpoints that have been successfully installed ===================================================== Script of Endpoint started on Tue Mar 11 20:02: ===================================================== unep1 Figure 4-9 shows the newly installed endpoint statistics. Figure 4-9 Endpoint statistics for the newly installed node 11.In the Windows NT scenario, we added additional functionality in the form of a fourth script. This script distributes software packages. After the inventory scan completed, we installed the Tivoli Software Package Editor on the newly installed endpoint. See Chapter 3, Implementation on page 25 for further information about this script. 12.The following log output demonstrates the successful software package installation (log_sp.log). 74 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

91 Example 4-21 The log_sp.log output =============================================== Started on Tue Mar 11 20:11: =============================================== #TMF_CCMS::ProfileManager# Subscribing Endpoint unep1 to ProfileManager DataMovingProfile.. Successfully subscribed Endpoint unep1 to ProfileManager DataMovingProfile.. DISSE0074I Operation successfully submitted. Distribution ID is Successfully distributed Software Package sped^nt on Endpoint unep1 13.As previously mentioned, in the Windows NT scenario, we used Activity Planner. Our software distributions and inventory scans were also tested and completed with Activity Planner. Figure 4-10 shows the object that we configured in Activity Planner. (We configured them as two separate plans.) Figure 4-10 Activity Plan for Endpoint_SWD 14.As in the Inventory Activity Planner scenario, we can monitor the success or failure of the software distribution packages, as shown in Figure Chapter 4. Installation, configuration, and administration 75

92 Figure 4-11 Activity Plan Monitor showing successful installation Tivoli policy regions, profile managers, and tasks When creating the appropriate policy regions, profile managers, and tasks, the script provides two options. The first option, if you have decided to go with the default policy regions created by the script, creates a top-level policy region, which you set in the second and third scripts, along with names for profile managers, profiles, and tasks. In the previous scenarios, we allowed the script to create policy region objects for us. If the second script was set to create the task library and task, it will be created in the mpolicy_region variable. A task is also created when the script is run for the first time. The task runs a hostname command on the endpoint and sends the output to a file on the node. From there, we pick up the file, read it, and use the host name to perform a wep set_label command. To modify where the task will be run, or to configure the script to use your own task library structure, you need to set the following: mpolicy_region= aix-tmr1b-region" mnode_task= managed node where task will run from mtask_library="test_task" mtask_name="test_task" 76 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

93 mtask_file=$mdir"task.sh" These variables need to be altered in the second script to include your naming conventions. You need to tell the script what task library and task it should use (if you have created your own) to run the task. Edit the following line, which is also in the second script: wruntask -t $mtask_name -l $mtask_library -h $mep >>$mlog_eplog 2>>$mlog_eplog The task must execute a script called task.sh. If you want to change the names of these parameters, edit the script accordingly. The following is an extract of the third script: mpolicy_region_name="auto_inventory" mprofile_manager_name="inventory_scan" mprofile_name="test_scan" 4.3 Administration and troubleshooting In this section, we cover troubleshooting for the solution. We explain best practices for troubleshooting in all three main components of the solution: Tivoli Management Framework, Software Distribution, and Inventory. The solution aims to make distributed systems and application management relatively easy. It achieves this through a consistent interface and the use of scripts. Although the systems administrator can perform many tasks with relative ease, the code Tivoli provides to achieve those tasks is extraordinarily complex. With the solid foundation of the Tivoli Management Framework, this complexity can remain largely masked from the administrator. However, with such a sophisticated set of products, there will be occasions when those designing, testing, and implementing the solutions will encounter situations that are not resolved by reference to product manuals alone. In problem-solving situations, you need to understand what is going on between the product components, what messages and trace output means, what logs are generated by the scripts, and what extra actions you can take to try to resolve a problem. We discuss the following troubleshooting topics this section: Troubleshooting the scripts Generic problem determination outline Chapter 4. Installation, configuration, and administration 77

94 Troubleshooting Tivoli Management Framework Version 4.1 Troubleshooting Software Distribution Troubleshooting Inventory Troubleshooting the scripts This section describes about the administrative steps required to fix difficulties when running the scripts. The administrator should refer to the log file created during the execution of the script. The log file contains a full history of all stages of the script. It starts with the time stamp of when the script was executed. The result (return code) of each command is success or failure. In the case of a failure in the script, the administrator should check which command gave the message and check whether or not the command named in the script has access. If so, the PATH (such as SNMP agent master file and user account and password file) should be checked. Sometimes, the input file is missing. The administrator should refer to Chapter 3, Implementation on page 25 for detailed information about the input file and put it in the folder where the scripts are available (it can also be kept in a location of the administrator s choice, but the exact path of the file must be noted). When installing Tivoli management agent code, it is assumed that the system does not contain any Tivoli management agent code installed earlier (for example, the files and services related to Tivoli management agent, Tivoli management agent account, and group are not present). Checking is done before installing Tivoli management agent code from the wep list, and only those endpoints where it is not present (as per the wep list) are addressed in the endpoint master list. The system administrator must check the log file for failed Tivoli management agent code and whether or not the Tivoli management agent code, services, or account is present. It should be removed from the system (target system) so that during the next discovery, the Tivoli management agent code is installed successfully. The administrator can refer to Tivoli Management Framework User s Guide Version 4.1, GC , if necessary. Because the log file contains the full details of the command, the administrator is advised to refer to the log files and look for similar log details from Chapter 3, Implementation on page 25 to resolve the issue. 78 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

95 Troubleshooting the scripts, along with corrective action, are properly defined in the log file. The administrator must always refer to the log file and correlate it with Chapter 3, Implementation on page 25, to resolve. Our experience with the solution In this section, we share some of the experiences and problems we encountered while implementing and running the scripts. The main problems were centered around the target machines. In order for the winstlcf command to run successfully, we found that the target machine must have no previous Tivoli endpoint installation. It is recommended that you start off with a newly installed node. For more information, see the Tivoli Management Framework Reference Manual Version 4.1, SC The next difficultly we had was after the endpoint code had been installed, the script needed to run a task on the node to determine the host name. In almost all cases, the task did not execute unless the machine had been rebooted. In order to cater to the script, after installing the code, it will go to sleep for 300 seconds, allowing enough time for the machine to be rebooted. If you feel that this time is insufficient, see Chapter 3, Implementation on page 25 for instructions about how to change this time. We also used the -r flag with the winstlcf command. This automatically reboots the machine after the code has been installed. If you do not want your target machines to be automatically rebooted, alter the script accordingly. Also note that if you have a long list of newly discovered endpoints, and you are allowing the sleep process to take place, the time required for installing all nodes can be a factor Generic problem determination outline If you start to receive errors and you have questions about the cause, this generic outline for problem determination may help. If you have a scenario that you can recreate, the following is a generic list of steps to perform to gather documentation: To obtain an overall picture of what is being passed by oserv: Run odadmin odlist to determine the number of managed nodes and interconnected Tivoli Management Regions. Run odadmin alone to get information, such as the port range restrictions (if any), or other oserv parameters, such as the Single Port BDT in place. Run odadmin environ get to determine the environment oserv is using. Chapter 4. Installation, configuration, and administration 79

96 To gather data from each suspected machine: 1. Log on as root and as a Tivoli root administrator. This helps ensure that you are not experiencing authority problems. 2. Run the following commands: odadmin trace objcalls odadmin trace services 3. Recreate the problem on every involved machine, including the Tivoli Management Region server. 4. Run odstat -v >odstat.txt. 5. Run wtrace -jhk $DBDIR >wtrace.txt (or %DBDIR% for Windows). 6. Collect these files plus oserv.log and any useful system logs. 7. After tracing is finished, or the problem has been determined, you can turn tracing back to the default of tracing only errors: odadmin trace off odadmin trace errors The trace should help you determine the failing objcall. Note: Leaving tracing on for objcalls and services may have a performance impact on the oserv. For troubleshooting, you could leave it on until a problem is determined and then turn tracing back to the default Troubleshooting Tivoli Management Framework Version 4.1 In this section, we focus on Tivoli Management Framework logs related to Inventory and Software Distribution. When you are troubleshooting problems with Tivoli Management Framework, there are a number of important commands that will help you. The three most commonly used commands when tracing oserv are as follows: odadmin odstat wtrace Lists the managed nodes in a Tivoli Management Region and configures different aspects of how the Tivoli object dispatcher (oserv) communicates, such as defining IP addresses and interconnected regions. Lists currently running methods and method histories. Formats the odtrace.log, which is created when tracing objcalls, services, or errors (tracing is invoked with odadmin trace options). 80 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

97 Additional logs can be found in the database directory, which you can locate through the following variable names: $DBDIR on UNIX %DBDIR% on Windows NT The database directory contains other files that can be used as debugging tools: epmgrlog Endpoint manager log. gatelog Gateway log. odb.log Tivoli database transaction log. gwdb.log Tivoli gateway database transaction log. oservlog Error log of the object dispatcher (oserv). odtrace.log The file that the wtrace command reads and translates on a Tivoli management agent endpoint. There is also a log file in the /lcf/dat/xx path. lcfd.log Endpoint log. In some cases, you may need to get into the more complex area of direct manipulation of the Tivoli object database. You can use manual methods, identify method source files, and so on. For more information about troubleshooting Tivoli Management Framework-related issues, refer to Tivoli Management Framework Maintenance and Troubleshooting Guide Version 4.1, GC Troubleshooting Software Distribution In this section, we describe troubleshooting techniques for the Software Distribution component. We provide a general approach for diagnosing distribution problems. The internals, architecture, and diagnostic techniques for all major components of Software Distribution are also reviewed, because understanding the process flow of each component is very useful when troubleshooting a problem. The problem determination steps should be based on the process flow of the components of the products so that the point of failure can be determined and rectified. For Software Distribution, there are three main components in the process flow: the Tivoli Management Framework infrastructure, the endpoint, and the software package profile. The Tivoli Management Framework infrastructure needs to be reviewed first, because the distribution of profiles will not work without it. Then, the endpoint needs to be checked to ensure that it is in working order. The last Chapter 4. Installation, configuration, and administration 81

98 thing to check is the software distribution profile and its associated software package definition (SPD) or software package block (SPB). The Tivoli Management Framework environment is the infrastructure used by Software Distribution, so the first thing to check is that the Tivoli Management Framework environment is functioning correctly. You must check that all the required Software Distribution components and prerequisites have been correctly installed and configured on the Tivoli server and gateways. You need to check that the functions of the Tivoli server, all gateways, and managed nodes are all functioning correctly. A wping of the managed node may indicate that the managed nodes are up and running, but does not necessarily mean that it is functioning correctly. You can test this by pushing out other types of profiles, such as an Inventory or Remote Control profile, to endpoints other than the suspect endpoints. A failure here could indicate a problem with the Tivoli Management Framework environment. The gatelog of the gateway, the oservlog, and the MDist log should be reviewed at a increased trace level. In addition to checking that the endpoint is running, you should push out other types of profiles, such as Inventory, Remote Control profiles, or even other software package profiles, to check that it is functioning correctly. If this fails, the problem could be with the endpoint. If more than one endpoint is encountering the problem, check for any set pattern. For example, if all the problematic endpoints serviced by the same gateway or the same profile are failing on all these endpoints, the problem could be with the gateway or the profile. With the Tivoli Management Framework infrastructure and the endpoint in working order, the problem might be with the software package profile or the software package. Test the software package profile by distributing to a known working endpoint. A failure here could indicate that the problem might be with the profile or the software package. The best source of information about the distribution is in the software package log file and the Software Distribution trace files. Review these logs to determine the cause of the problem. The settings of the software package profiles should be checked and how those settings or options can affect the operations on the endpoints. One of the things to watch out for is nested software packages. A software distribution to a group of endpoints that fails with an error, such as failed cm_status check, could be due to one of the nested packages being already installed on one of the targeted endpoints. Using the force or ignore options should allow the distribution to complete. There can be times where the installation of the software package is successful, but the status in the log does not correctly indicate this. This can occur when user_program is defined as the final action, which has an indefinite time-out or a manual reboot of the target required. This is because of the records of the states of the software packages in the Inventory database are out of sync with the 82 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

99 endpoints catalogs, which hold the states of the software package. You will need to run the wsyncsp to reconcile this information. For more information about troubleshooting Software Distribution you can refer to the IBM Tivoli Configuration Manager User s Guide for Software Distribution Version 4.2, SC Troubleshooting Inventory This section covers important information related to the log files required to troubleshoot inventory scans. It is important that you understand the basic tasks and the log files used in order to troubleshoot effectively. Table 4-1 shows the various log files to be checked for Inventory-related problems. Table 4-1 Log files to check for Inventory problems Component Path Log file name Default log level Debug level Endpoint: Upcall and downcall information $LCFDIR/dat/1 lcfd.log 1 3 Endpoint scan engine: Inventory profile information Endpoint scan engine: Scan data Endpoint scan engine: Debug information From the directory where the wepscan command was run. Created by the wepscan -d command. From the directory where the wepscan command was run. Created by the wepscan -d command. From the directory where the wepscan command was run. Created by the wepscan -d command. sa_config.log N/A 3 sa_results.log N/A 3 INV_SA.log N/A 3 Hardware scan library: Debug information $LCGFDIR\inv\Scan libinvhw.log N/A N/A Chapter 4. Installation, configuration, and administration 83

100 Component Path Log file name Default log level Debug level Gateway: Upcall and downcall information $DBDIR gatelog 3 6 RIM object SQL statements and DB return codes Data handler: Debug information $RIM_DB_LOG Created by the wrimtrace command. $DBDIR/inventory/ data_handler invdh_1_rim.log N/A INFO E RROR mcollect.log 1 3 Collector: Debug information $runtime_location/ mcollect.log 1 3 For more information about troubleshooting Inventory, refer to the IBM Tivoli Configuration Manager User s Guide for Inventory Version 4.2, SC Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

101 5 Chapter 5. NetView Integration Module implementation and scenarios IBM Tivoli NetView Integration Module for Configuration Manager Version 4.2 integrates NetView and Tivoli applications to provide combined systems and network management. This product was formerly called Tivoli Integration Pack for NetView. You can use NetView Integration Module to catalog all the network devices in your enterprise. Importing the NetView discovery of Tivoli Management Region members into the Inventory database helps you maintain and diagnose the Tivoli environment. This chapter describes the requirements for installing the NetView Integration Module for Configuration Manager. It also shows you how to configure and use the component and gives possible usage scenarios. In this chapter, we discuss the following topics: NetView Integration Module components Installing NetView Integration Module components Accessing Network Diagnostics from the command line interface Copyright IBM Corp All rights reserved. 85

102 Accessing Network Diagnostics from the NetView console Configuring and using Tivoli Discovery from NetView IBM Tivoli NetView Integration Module for Configuration Manager 5.1 NetView Integration Module components Before we delve into each of the IBM Tivoli NetView Integration Module for Configuration Manager components, let us first talk about the changes to the former product, Tivoli Integration Pack for NetView (TIPN). Most of the information about the Tivoli Integration Pack for NetView applies to the IBM Tivoli NetView Integration Module for Configuration Manager. However, note the following changes: All IBM Tivoli Enterprise Console integration has been removed from Tivoli NetView Integration Module for Configuration Manager. The NetView client is not supported. Only the NetView server is supported. Only AIX, Solaris, and Windows NT operating environments are supported. NetView on AIX and Solaris must be installed through the Tivoli Management Framework. To use Network Diagnostics from the NetView console on Windows NT, you must run the setup_env.cmd command before you run the netview command. No patches are necessary to use these components. If you are installing Tivoli NetView Integration Module for Configuration Manager over Tivoli Integration Pack of NetView, you must run the rmnvinvobjs.sh script before installing Tivoli NetView Integration Module for Configuration Manager NetView Integration Module component list The following tables list the components related to the IBM Tivoli NetView Integration Module for Configuration Manager and also give a comparison of the changes made to the Tivoli Integration Pack for NetView components. 86 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

103 Table 5-1 Components related to NetView Integration Module for Configuration Manager Component (NetView Integration Module) Component (Tivoli Integration Pack for NetView) Implementation site Functions Description IBM Tivoli Network Diagnostics Gateway for Configuration Manager Tivoli Management Framework Network Diagnostics All Tivoli managed nodes wrping wrtraceroute wrnetstat wwakeup Adds command line interface (CLI) commands for diagnosing and remote troubleshooting of network problems. This component also adds a Wake on LAN utility to the Tivoli Management Framework. IBM Tivoli Network Diagnostics for Configuration Manager Tivoli Management Framework Network Diagnostics for NetView servers NetView servers Tivoli menu additions to the NetView console: Tivoli Discovery Tivoli Reports remote ping, traceroute, and netstat functions from the NetView console Adds the following functions to the NetView console: Launch the Tivoli desktop from NetView Discover and highlight managed resources in your network Generate and view various Web-based reports Access the remote ping, traceroute, and netstat functions from the Tivoli menu Removed from NetView Integration Module for Configuration Manager Tivoli Management Framework Network Diagnostics for NetView client NetView clients Same as above for NetView clients. If you are going to install Tivoli Management Framework Network Diagnostics for NetView client, you must first install Tivoli Management Framework Network Diagnostics for NetView server on the client s corresponding server. Tivoli NetView Integration Adapter for Configuration Manager Tivoli NetView/ Inventory Integration Adapter for NetView server NetView servers Allows you to target NetView server nodes for NetView/ Inventory exports. This component gives network administrators access to system information that is discovered by Inventory. It also allows for the network information discovered by NetView to be exported to the Inventory data repository. Chapter 5. NetView Integration Module implementation and scenarios 87

104 Component (NetView Integration Module) Component (Tivoli Integration Pack for NetView) Implementation site Functions Description IBM Tivoli NetView Integration Module for Configuration Manager Tivoli NetView/ Inventory Integration Profile Tivoli managed nodes Allows you to create and distribute NetView inventory profiles. This component allows for the network information discovered by NetView to be exported to the Inventory data repository. Removed from NetView Integration Module for Configuration Manager Tivoli NetView/ Tivoli Enterprise Console Integration Adapter for NetView server NetView servers with Tivoli Enterprise Console The TEC Events menu option is added to the Monitor menu of the NetView console. The Tasks menu option is added to the Tivoli Enterprise Console. Interconnects NetView and the Tivoli Enterprise Console. With Tivoli Enterprise Console Integration, you can use the NetView SmartSet (Collection on a UNIX-based machine) concepts and network information, as well as Tivoli Enterprise Console event history, to perform Tivoli Enterprise Console tasks from NetView. Removed from NetView Integration Module for Configuration Manager Tivoli NetView/ Tivoli Enterprise Console Integration Adapter for NetView client NetView client with Tivoli Enterprise Console Same as above, for NetView clients. Same as above, for NetView clients. 88 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

105 Component (NetView Integration Module) Component (Tivoli Integration Pack for NetView) Implementation site Functions Description Tivoli NetView Server 7.1 Enabler for Windows NT Tivoli NetView Server 5.1 Enabler for Windows NT NetView servers running on Windows NT Allows you to install and use NetView Integration Module/TIPN on NetView 7.1/5.1 servers running on Windows NT. Install the Enabler component on those NetView servers running Windows NT from which you want to access the following components from the NetView console: IBM Tivoli Network Diagnostics for Configuration Manager IBM Tivoli NetView Integration Adapter for Configuration Manager Tivoli NetView/Tivoli Enterprise Console Integration for NetView server Removed from NetView Integration Module for Configuration Manager Tivoli NetView client 5.1 Enabler for Windows NT NetView clients running on Windows NT Allows you to install and use Tivoli Integration Pack for NetView on NetView 5.1 clients running on Windows NT. It is only necessary to install the Enabler component on those NetView clients running Windows NT from which you want to access the following components from the NetView console: Tivoli Management Framework Network Diagnostics for NetView client Tivoli NetView/Tivoli Enterprise Console Integration for NetView client Note: If you are going to install and use NetView Integration Module for Configuration Manager or Tivoli Integration Pack for NetView components on NetView 7.1 or 5.1 servers or clients running Windows NT, you must first install the Enabler components for Windows NT. Chapter 5. NetView Integration Module implementation and scenarios 89

106 5.2 Installing NetView Integration Module components Before we delve into the scenarios, let us first show you our environment. Figure 5-1 shows the Tivoli environment we use for the scenarios. Tivoli Management Region Server (UNIX) NetView Two-way interconnection Tivoli Management Region Server (Windows NT) Database Server RIM Host Configuration Manager NetView Integration Module Managed Node (Windows NT) Gateway Endpoint Managed Node (Windows NT) NetView NetView Integration Module Database Client Gateway Endpoint Endpoint Endpoint Endpoint Figure 5-1 Tivoli environment used in the scenarios Each of the NetView Integration Module for Configuration Manager components provides a specific function. It is necessary to install those components that provide the specific function you want. 90 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

107 Note: Before installing the NetView Integration Module for Configuration Manager components, make sure your system meets the general hardware and software requirements. Please check the following Release Notes for the prerequisites for Tivoli NetView and IBM Tivoli Configuration Manager products. These Release Notes are shipped with the product CDs. IBM Tivoli NetView for Windows Release Notes, GI IBM Tivoli NetView for UNIX Release Notes, GI IBM Tivoli Configuration Manager Release Notes Version 4.2, GI NetView Integration Module for Configuration Manager adds no additional requirements to the hardware and software requirements of these products. To install NetView Integration Module for Configuration Manager components from the Tivoli desktop, complete the following steps: 1. From the Tivoli desktop s Desktop menu, select Install Install Product to display the Install Product dialog box (Figure 5-2 on page 92). Chapter 5. NetView Integration Module implementation and scenarios 91

108 Figure 5-2 Install Product selection 2. You may see an error about the media not being properly set. Click OK to open the File Browser dialog box: a. Under Hosts, highlight the name that has the installation media (disk file or CD-ROM). 92 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

109 b. Under Path Name, type in the full path name of the directory that contains the NetView Integration Module for Configuration Manager components or where the CD-ROM is mounted. NetView Integration Module for Configuration Manager components are located in the NIMCM_41 directory of the IBM Tivoli Configuration Manager Installation CD-ROM disk 1. c. Click Set Media & Close. 3. The Install Product dialog box opens, as shown in Figure 5-3 on page 94. If the NetView Integration Module for Configuration Manager components do not appear in the list of installable products, click Select Media to display the File Browser dialog box (see step 2), and set the correct path to the installation media. Chapter 5. NetView Integration Module implementation and scenarios 93

110 Figure 5-3 Select Product to Install list 4. Select the NetView Integration Module for Configuration Manager component you want to install. Note that many of the components can be installed separately. 5. From the Available Clients list, select the clients you want to install on and move them to the Clients to Install On list using the left arrow button. 94 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

111 Note: You should close the NetView user interface while installing the NetView Integration Module for Configuration Manager components. User interface additions will not appear until after you have restarted the NetView console Using IBM Tivoli Network Diagnostics for Configuration Manager The IBM Tivoli Network Diagnostics for Configuration Manager component of NetView Integration Module discovers Tivoli managed resources in your network, highlights them in your NetView submaps, and populates the NetView database with information about the resources. IBM Tivoli Network Diagnostics includes the following components: IBM Tivoli Network Diagnostics for Configuration Manager IBM Tivoli Network Diagnostics Gateway for Configuration Manager Installing the Tivoli Network Diagnostics Gateway for Configuration Manager component gives you access to the wrping, wrtraceroute, and wrnetstat commands, as well as the Tivoli Wake on LAN function (wwakeup), from the Tivoli command line interface (CLI). Installing the IBM Tivoli Network Diagnostics for Configuration Manager components makes the remote ping, remote traceroute, and remote netstat commands available from the Tivoli menu of the NetView console, and also adds the Tivoli Discovery and Tivoli Reports functions. Installing IBM Tivoli Network Diagnostics To install IBM Tivoli Network Diagnostics for Configuration Manager: 1. From the Tivoli desktop s Desktop menu, select Install Install Product to open the Install Product dialog box. 2. You may see an error about the media not being properly set. Click OK to open the File Browser dialog box: a. Under Hosts, highlight the name that has the installation media (disk file or CD-ROM). b. Under Path Name, type in the full path name of the directory that contains the NetView Integration Module for Configuration Manager components or where the CD-ROM is mounted. NetView Integration Module components are located in the NIMCM_41 directory of the IBM Tivoli Configuration Manager Installation CD-ROM disk 1. c. Click Set Media & Close. 3. Select IBM/Tivoli Network Diagnostics for Configuration Manager. Chapter 5. NetView Integration Module implementation and scenarios 95

112 4. From the Clients to Install On list, select the NetView server, and then click Install (Figure 5-4). Figure 5-4 Clients to Install On list 5. In the Product Install dialog box, click Continue Install to start the installation of the component. Figure 5-5 on page 97 shows the successful installation message. 96 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

113 Figure 5-5 Successful installation message 6. Next, you need to install the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component on all the Tivoli managed nodes, the same way as you did for the IBM Tivoli NetView Diagnostics for Configuration Manager component. Note: To use the Tivoli Network Diagnostics commands, you must be a Tivoli administrator with the role of admin, senior, super, or user. Chapter 5. NetView Integration Module implementation and scenarios 97

114 5.3 Accessing Network Diagnostics from the command line interface You can only access the diagnostic services from the Tivoli command line interface (CLI) if you have not installed the IBM Tivoli Network Diagnostics for Configuration Manager component. These commands can only be invoked from a Tivoli managed node that has the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component installed. Following is the CLI usage statement for each of the Tivoli Network Diagnostics commands. Using the wrping command The wrping command initiates an Internet Control Message Protocol (ICMP) echo from one host to another. Use the following syntax for the wrping command (the parameters in brackets are optional): wrping RemoteNode [ n Count] [ s PacketSize] [ w Timeout] TargetHost Where: RemoteNode Specifies the label of the remote node where the method is invoked. This node must be a managed node that has the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component installed. n Count Specifies the number of echo requests to be sent. s PacketSize Specifies the number of data bytes to be sent. The default is 56. On UNIX platforms, this data is combined with the 8 bytes of the ICMP header for a total of 64 bytes of ICMP data. w Timeout Specifies the timeout to wait for a reply in seconds. TargetHost Specifies the host name or IP address of the target host. Using the wtraceroute command The wrtraceroute command determines the route between two nodes. Use the following syntax for the wrtraceroute command (the parameters in brackets are optional): wrtraceroute RemoteNode [ m MaxTTL] [ n] [ q NumQueries] [ t TypeOfService] [ w WaitTime] [ s PacketSize] TargetHost 98 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

115 Where: RemoteNode Specifies the label of the remote node where the method is invoked. This node must be a managed node that has the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component installed. m MaxTTL Specifies the maximum time-to-live (maximum number of hops) used in the outgoing probe packet. The default is 30 hops. n Prints the hop addresses numerically, rather than symbolically and numerically. This flag saves a name server address-to-name lookup for each gateway found along the path. q NumQueries Specifies the number of probes the traceroute command sends at each Max TTL setting. The default is three probes. This option is ignored on Windows 95 and NT platforms. t TypeOfService Sets the TypeOfService variable in the probe packets to a decimal integer in the range of 0 to 255. The default is 0. This flag can be used to investigate whether different service types result in different paths. Useful values are t 16 (low delay) and t 8 (high throughput). w WaitTime Specifies the time (in seconds) to wait for a response to a probe. The default is 5 seconds. The minimum value is 2 seconds. s PacketSize Specifies the length of the probe datagram in bytes. The default (and minimum size) is 40. TargetHost Specifies the host name or IP address of the target node to locate. Using the wrnetstat command The wrnetstat command requests network information from a remote node. Use the following syntax for the wrnetstat command (the parameters in brackets are optional): wrnetstat [ a] [ n] [ s] [ p Proto] [ r] RemoteNode Where: a Displays all connections and listening ports (server-side connections are normally not shown). n Displays addresses and port numbers in numerical form. Chapter 5. NetView Integration Module implementation and scenarios 99

116 s Displays per-protocol statistics. By default, statistics are shown for TCP, UDP, and IP; the p option may be used to specify a subset of the default. p Proto Displays connections for the specified protocol; Proto can be TCP or UDP. If used with the s option to display per-protocol statistics, Proto may be TCP, UDP, or IP. This option is not supported on Solaris and will be ignored if specified. r Displays the contents of the routing table. RemoteNode Specifies the label of the remote node where the network information is requested. This node must be a managed node that has the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component installed. 5.4 Accessing Network Diagnostics from the NetView console To run the IBM Tivoli Network Diagnostics services from the NetView console if you have installed the IBM Tivoli Network Diagnostics for Configuration Manager component, select Tivoli Tivoli Network Diagnostics from the menu. You will see the following services: oserv ping remote ping remote traceroute remote netstat To use these tools from the NetView console, you need to have one or more objects selected in your NetView submap or submaps, depending on the function you are using: The oserv ping command requires that one object is selected. The object must be a Tivoli managed resource. The remote ping and remote traceroute commands require that two objects are selected. The first object must be a Tivoli managed node that has the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component installed. This is the location from which the command is executed. The second object is the target of the command. Click the first object to select it. Press the Ctrl key and click a second object to select it. 100 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

117 The remote netstat command requires one target object, which must be a Tivoli managed node that has the IBM Tivoli Network Diagnostics Gateway for Configuration Manager component installed. 5.5 Configuring and using Tivoli Discovery from NetView Installing the IBM Tivoli Network Diagnostics for Configuration Manager component adds new functions to your NetView Version 7.1 servers, including Tivoli Discovery. A Tivoli environment can consist of many different Tivoli resources, including Tivoli Management Region servers, Tivoli managed nodes, PC managed nodes, Tivoli management agents, and so on. It may not always be easy or convenient to keep track of where you have installed the various components of your Tivoli environment. By using the Tivoli Discovery component of Tivoli Network Diagnostics, you can easily discover, display, and report on your Tivoli environment from NetView. Tivoli Discovery automatically maps resources on the local Tivoli Management Region and all directly connected Tivoli Management Regions. Note: On managed nodes running Windows NT, the path to %NV_DRIVE%\usr\ov\bin must be set in the path environment before you attempt to run NetView (%NV_DRIVE% is the environment variable that indicates where NetView for Windows NT is installed) Configuring Tivoli Discovery To run Tivoli Discovery, select Tivoli Tivoli Discovery Perform Name Registry Discovery from your NetView menu bar. This starts a discovery process that communicates with the Tivoli Name Registry. This process learns about your Tivoli environment by querying Tivoli Name Registry and then populates your NetView database with information about your Tivoli environment. Refer to the Tivoli Management Framework Planning for Deployment Guide Version 4.1, GC to learn more about the Tivoli Name Registry. Using this method, Tivoli Discovery only learns about those Tivoli Management Regions connected to the Tivoli Management Region where NetView is located. Refer to the Tivoli Management Framework Planning for Deployment Guide Version 4.1, GC to learn more about connecting Tivoli Management Regions. Chapter 5. NetView Integration Module implementation and scenarios 101

118 To ensure that you discover your complete Tivoli environment, do the following: Make sure NetView is managing those areas of your Tivoli network. Make sure you have connected your NetView Tivoli Management Region to all other TMRs in your environment. Note: The installation of Tivoli Management Framework Network Diagnostics for NetView does not automatically run the Perform Name Registry Discovery function. To update the NetView database and the Tivoli Reports, you must run this command manually after you install the component. Until you do this step, Tivoli Reports will not provide content Displaying your Tivoli environment After you have discovered your Tivoli environment, you can locate and display the various Tivoli resources within the context of your IP network. You can locate and highlight the following Tivoli resources by selecting Tivoli Tivoli Locate from your NetView menu bar: Tivoli servers Tivoli managed nodes Tivoli PC managed nodes Tivoli management agent gateways Tivoli management agent endpoints When you locate and highlight one of these Tivoli resources, all symbols that either contain the Tivoli resource or that are the Tivoli resource are highlighted (the symbol label will be reverse video) in your NetView submaps Generating reports After you run Tivoli Discovery, you can also view a series of reports from the Tivoli menu of the NetView console. These reports include the following, which can be accessed by selecting Tivoli Tivoli Reports: Unmanaged Nodes by Segment Gateways by Segment Endpoints by Segment Endpoints by Gateway Endpoints by Interp Tivoli Servers by Segment 102 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

119 ManagedNodes by Segment ManagedNodes by Tivoli Server PcManagedNodes by Proxy In order to view these reports, you must have an Internet browser installed. From UNIX, the only supported browser is Netscape, and it must be installed and configured correctly. For users of Windows NT, reports are displayed in the default browser. Figure 5-6 NetView Report example Chapter 5. NetView Integration Module implementation and scenarios 103

120 These reports are not generated or updated automatically. Tivoli Discovery must be run to propagate new or changed Tivoli managed nodes to the NetView database, and then you must generate reports. To generate reports on UNIX platforms, use: /usr/ov/bin/nvgenrpts.sh To generate on Windows NT platforms, use: %NV_DRIVE%\usr\ov\bin\nvgenrpts.cmd. If you want to schedule reports to be generated on a regular basis, use one of the following methods: On Windows NT, use the AT service to run Tivoli Discovery, and then run nvgenrpts.cmd once a day. On UNIX-based systems, use the cron command to schedule nvgenrpts.sh to run once a day. See the cron man page for more information about the cron command. For UNIX operating systems, /usr/ov/bin/lstmr is the discovery binary and nvgenrpts.sh is the report generation script. For Windows NT, %NV_DRIVE%\usr\ov\bin\lýstmr.exe is the discovery binary and nvgenrpts.cmd is the report generation script. The following is an example AT command for Windows NT. Example 5-1 AT command for Windows NT at \\win-mn01 2:00PM /every:m,t,w,th,f,s,su \ "cmd /c setup_env.cmd && c:\usr\ov\bin\ \ lýstmr.exe" at \\win-mn01 4:00AM /every:m,t,w,th,f,s,su \ "cmd /c c:\usr\ov\bin\nvgenrpts.cmd" It is possible to do the same type of automation using the UNIX cron service. See the local man page for information about setting up a cron file entry. Remember that /usr/ov/bin/lstmr must be executed in a sourced Tivoli environment. The following are examples of AIX cron file entries. Example 5-2 AIX cron file entries * * * /usr/ov/bin/lstmr.sh * * * /usr/ov/bin/nvgenrpts.sh Note: The lstmr.sh script sources the appropriate Tivoli environment and then executes /usr/ov/bin/lstmr. 104 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

121 You can also run Tivoli Discovery and generate these reports from the NetView console. Select Tivoli Tivoli Network Diagnostics Perform Name Registry Discovery from the menu to run Discovery. Select Tivoli Tivoli Reports Generate Reports from the menu to generate reports. Use the options under the Tivoli Reports menu option to display reports Configuring and using Tivoli Wake on LAN Tivoli Wake on LAN is designed to act either as a stand-alone Wake on LAN component, or as a component that talks to a NetView server. You need to know the MAC address for the node you want to wake up to use Tivoli Wake on LAN as a stand-alone Wake on LAN application. You only need to know the IP address or the IP host name for the target wake-up node to use Tivoli Wake on LAN as an application that talks to a NetView server to resolve an IP address to a MAC address. After resolving the address, Tivoli Wake on LAN then sends a Wake on LAN packet. Communication with the NetView server is done through the Wake on LAN server component. The following syntax is used for the Tivoli Wake on LAN client (parameters in brackets are optional): wwakeup m multicast address b broadcast address a MAC address i (NetViewDatabase Name) (IP address to resolve) n (NetViewDatabase Name) (Node Name to resolve) [ h] Where: m multicast address Specifies a multicast address to which to send the wake-up packet. Valid range is to If you use the m option, you do not use the b option. -b broadcast address Specifies a broadcast address to which to send the wake-up packet. If you use the b option, you do not use the m option. a MAC address Specifies a MAC address to use to build the Wake on LAN packet. If you use the a option, you do not use the i or n options. i (NetViewDatabase Name) (IP address) This option is intended to use a NetViewDatabase Tivoli object to resolve an IP address to a MAC address. Use this option when you do not directly know the MAC address of the node you want to wake up, but you do know the IP address. If you use the i option, you do not use the a or n options. Chapter 5. NetView Integration Module implementation and scenarios 105

122 n (NetViewDatabase Name) (Node Name) Tells wwakeup to use the NetViewDatabase indicated to resolve the node name to a MAC address. After wwakeup has the MAC address, it builds the packet and sends it. If you use the n option, you do not use the a or i options. h Displays help information. 5.6 IBM Tivoli NetView Integration Module for Configuration Manager The IBM Tivoli NetView Integration Module for Configuration Manager gives you access to system information that is discovered by Tivoli Inventory and to network information NetView gathers for all the nodes in your environment. You can use NetView Integration Module to catalog all the network devices in your enterprise. Importing the NetView discovery of Tivoli Management Region members into the Inventory databases helps you maintain and diagnose the Tivoli environment. It also shows you how to configure and use the component and gives possible usage scenarios. The IBM Tivoli NetView Integration Module for Configuration Manager consists of the following two components: IBM Tivoli NetView Integration Adapter for Configuration Manager IBM Tivoli NetView Integration Module for Configuration Manager Installing the IBM Tivoli NetView Integration Module components Like Tivoli Inventory, IBM Tivoli NetView Integration Module for Configuration Manager adds a profile type, NetViewInventoryProfile, that can be added to any profile manager. You create profiles that describe from which NetView servers to gather information and what information to gather. Configuring Tivoli Inventory Refer to the IBM Tivoli Configuration Manager User s Guide for Inventory, Version 4.2, SC , for information about setting up and configuring Tivoli Inventory. You must configure Tivoli Inventory before using the IBM Tivoli NetView Integration Module for Configuration Manager component. 106 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

123 5.6.2 Installing IBM Tivoli NetView Integration Adapter To install IBM Tivoli NetView Integration Module for Configuration Manager components from the Tivoli desktop, complete the following steps: 1. From the Tivoli desktop s Desktop menu, select Install Install Product to open the Install Product dialog box. 2. You may see an error about the media not being properly set. Click OK to open the File Browser dialog box: a. Under Hosts, highlight the name that has the installation media (disk file or CD-ROM). b. Under Path Name, type in the full path name of the directory that contains the NetView Integration Module for Configuration Manager components or where the CD-ROM is mounted. NetView Integration Module for Configuration Manager components are located in the NIMCM_41 directory of the IBM Tivoli Configuration Manager Installation CD-ROM disk 1. c. Click Set Media & Close. 3. Select IBM/Tivoli NetView Integration Adapter for Configuration Manager from the Select Product to Install list, and from the Clients to Install On list, select your NetView server (Figure 5-7 on page 108). Chapter 5. NetView Integration Module implementation and scenarios 107

124 Figure 5-7 Select Product to Install list 4. Click Install. 5. Click Continue Install to start the installation (Figure 5-8 on page 109). 108 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

125 Figure 5-8 Start the installation Figure 5-9 on page 110 shows the successful installation message. Chapter 5. NetView Integration Module implementation and scenarios 109

126 Figure 5-9 Successful installation message Note: If you are installing the IBM Tivoli Integration Adapter for Configuration Manager component on a node running Windows NT, you must reboot the machine after installing the component Installing IBM Tivoli NetView Integration Module After you install the IBM Tivoli NetView Integration Adapter for Configuration Manager component on all NetView servers, install the IBM Tivoli NetView Integration Module for Configuration Manager component. Follow the previous 110 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

127 steps, selecting IBM/Tivoli NetView Integration Module for Configuration Manager as the component to install, and select any Tivoli Management Region nodes from the Available Clients list. The nodes you select on which to install the IBM Tivoli NetView Integration Module for Configuration Manager component will be the ones from which you can create and distribute NetView and inventory profiles. At least one of the nodes that you select must be the Tivoli Inventory RIM host Installing RDBMS tables and views To complete the IBM Tivoli NetView and NetView Integration Module for Configuration Manager component installations, install the relational database management system (RDBMS) tables and views into the Tivoli Inventory RDBMS. In order to do this, you need to run one of the following scripts (depending on your database) on the Tivoli Inventory RIM host. Table 5-2 RDBMS tables and views RDBMS Sybase Microsoft SQL server Oracle DB2 Script nvinv_syb_schema.sql nvinv_ms_sql_schema.sql nvinv_ora_schema.sql nvinv_db2_schema.sql These scripts install the tables and views needed to integrate Tivoli Inventory and Tivoli NetView. Execute these scripts so that the tables and views are installed in the same manner as the Tivoli Inventory schema. This includes installing the new NetView tables into the same relational database in which Tivoli Inventory currently resides. See IBM Tivoli Configuration Manager User s Guide for Inventory Version 4.2, SC , for more information about executing these scripts. On UNIX machines, these scripts are located in $BINDIR/TMF/NIMCM ($BINDIR is set by the Tivoli environment script). On Windows NT, these scripts are located in %BINDIR%\TMF\NIMCM Creating the NetView Inventory query library The next step in the installation process is to create the NetView Inventory query library. You can create the NetView Inventory query library on any node on which you want to install the IBM Tivoli Integration Module for Configuration Manager component. Chapter 5. NetView Integration Module implementation and scenarios 111

128 You need to make sure that Query Library is a managed resource in the policy region that you are installing it to. For more information, see Creating a NetView inventory profile on page 113. From a sourced Tivoli shell, execute the following command located in the $BINDIR/TMF/NIMCM directory: nvinv_create_queries.sh Policy_Region_Name Where Policy_Region_Name is the name of the policy region where you want the query library to be installed. Installing the query library adds a NETVIEW_QUERIES icon to the specified policy region, as shown in the Policy Region window (Figure 5-10). Figure 5-10 Policy Region window Using IBM Tivoli NetView Integration Module Following is an outline of the steps for using the NetView Integration Module for Configuration Manager component: 1. Create a NetView inventory profile that defines which objects and fields you want to gather from your NetView server or servers. 112 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

129 2. Distribute your NetView inventory profile or profiles to the NetView servers whose data you want. These subscribers will be only the nodes where the IBM Tivoli NetView Adapter for Configuration Manager component has been installed. 3. The distribution initiates the pull of data from your NetView database or databases to your Tivoli Inventory database. 4. Use the NetView query library to examine your completed inventory. Roles for using NetView inventory profiles In order to create or edit a NetView inventory profile, you must have the following authorization roles defined for the administrator doing the work: Inventory_edit Inventory_scan Inventory_query Inventory_view RIM_update RIM_view In addition, to distribute the NetView inventory profile, you must also have the role of super, senior, or admin. Refer to Tivoli Management Framework User s Guide Version 4.1, GC for more information about granting roles. Creating a NetView inventory profile The NetView inventory profiles you create define what objects and field values will be stored in the Tivoli Inventory database from your NetView database or databases. To create a NetView inventory profile, you must first make sure the NetView inventory profile is a managed resource in the policy region in which you are working. Use the following procedure to make a NetView inventory profile a managed resource within a policy region: 1. From the Tivoli desktop, double-click the policy region in which you want to create the NetView inventory profile. Tivoli Management Framework opens the Policy Region window. 2. Select Managed Resource from the Properties menu in the Policy Region window to display the Set Managed Resources dialog box. 3. Select NetViewInventoryProfile from the Available Resources list and click the left arrow button (Figure 5-11 on page 114). The NetViewInventoryProfile resource is moved from the Available Resources list to the Current Resources list. Chapter 5. NetView Integration Module implementation and scenarios 113

130 Figure 5-11 Set Managed Resources dialog box 4. Click Set & Close to close the dialog box. Now that the NetView inventory profile is a managed resource, you can create a profile using the following procedure: 1. Create a profile manager for the new profile (Figure 5-12 on page 115). Alternatively, you can use an existing profile manager. 114 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

131 Figure 5-12 Profile Manager window 2. Open the profile manager by double-clicking on the icon of the profile manager you want to use. 3. Select Profile from the Create menu in the Profile Manager window to display the Create Profile dialog box. 4. From the Create Profile dialog box, select the NetViewInventoryProfile type and provide a label for the profile in the Name/Icon Label field (Figure 5 on page 116). Chapter 5. NetView Integration Module implementation and scenarios 115

132 Figure 5-13 Create Profile dialog box 5. Click Set & Close to close the dialog box. You should now see a new profile icon in the Profile Manager window (Figure 5-14 on page 117). 116 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

133 Figure 5-14 New profile icon Editing and customizing the NetView inventory profile Use the following procedure to edit and customize your new profile: 1. To edit the profile, double-click the NetViewInventoryProfile icon, which opens the NetView Inventory Profile dialog box. Initially, the profile is empty, as seen in Figure 5-15 on page 118. Chapter 5. NetView Integration Module implementation and scenarios 117

134 Figure 5-15 NetView Inventory Profile dialog box 2. Click Add in the NetView Inventory Profile dialog box to indicate what types of objects should be retrieved from your NetView database or databases. The Add Entry to NetView Inventory Profile dialog box opens (Figure 5-16 on page 119). 118 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

135 Figure 5-16 Add Entry to NetView Inventory Profile dialog box 3. Select the type of object you want exported from your NetView database. You can select from Interfaces, Networks, Nodes, or Segments. 4. Select the fields you want exported for each object of the type you have chosen. To do this, select a field in the Fields Available for Export list and click the right arrow button. The selected field is moved to the Fields Selected for Export list. You can select multiple fields at once. 5. Click Add if you want to choose another object type and set of fields to add to this profile. Click Add &Close to close the dialog box. 6. Your profile should now list the types of objects that will be exported from your NetView database or databases to your Tivoli Inventory database (Figure 5-17 on page 120). Select Close from the Profile menu to close the NetView Inventory Profile dialog box. Chapter 5. NetView Integration Module implementation and scenarios 119

136 Figure 5-17 NetView Inventory Profile: Objects To Export list You are now ready to distribute the NetView inventory profile. Distributing the NetView inventory profile Distributing a NetView inventory profile to a NetView server exports the objects specified in the profile to the Tivoli Inventory database. Distribute a profile to your NetView servers by using one of the following methods: Select the Distribute menu option from within the profile. Use drag and drop from within the profile manager. Note: A successful NetView inventory profile distribution results in a message posted in the Inventory Notices Group. Select the Inventory Notices Group to view time stamps indicating when distributions occurred. 120 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

137 Desktop method To use the menu option to distribute the profile: 1. Double-click the NetViewInventoryProfile icon to display the NetView Inventory Profile dialog box. 2. Select Distribute from the Profile menu. The Distribute Profile dialog box opens (Figure 5-18). You can distribute the profile from this dialog box immediately, or you can schedule the profile to be distributed later. Figure 5-18 Distribute Profile dialog box 3. Select All levels of subscribers in the Distribute To box and Make each subscriber s profile an EXACT COPY of this profile in the Distribution Will box. 4. Move your NetView servers to the Distribute to These Subscribers list, using the arrow buttons. Chapter 5. NetView Integration Module implementation and scenarios 121

138 5. Click Schedule button if you want to schedule your distribution from the Add Scheduled Job dialog box (Figure 5-19). Otherwise, click Distribute & Close to distribute the profile immediately. For more information about scheduling jobs, see the Tivoli Management Framework User s Guide, Version 4.1, GC Figure 5-19 Add Scheduled Job dialog box 122 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

139 Drag and drop method To use the drag and drop method of profile distribution: 1. Double-click the profile manager in which you created your NetView inventory profile. 2. Drag the NetViewInventoryProfile icon from the Profiles box to the subscribers to which you want the profile distributed in the Subscribers box. Remember, profiles can only be distributed to those managed nodes running NetView. NetView inventory profiles can be created and distributed to one or more NetView servers. This allows you to collect network hardware knowledge across all domains of network management. Note the following limitations: Do not distribute multiple NetView inventory profiles to a single NetView server at one time. Node duplication may occur in the Inventory database if multiple NetView servers are targeted for distribution and they have management overlap (they have discovered and are currently managing overlapping IP segments of the network). For more information about NetView discovery and management, see the Tivoli NetView for UNIX Administrator s Guide Version 7.1, SC Querying the Tivoli Inventory database Now that you have exported data from your NetView database to your Tivoli Inventory database, you can run a number of queries against the data. Use the following procedure to run any of the predefined queries: 1. Double-click the policy region in which you installed the NetView query library. 2. Inside the policy region, you should see the NETVIEW_QUERIES icon. Double-click it to display the NETVIEW_QUERIES dialog box. 3. Right-click any of the queries and select Run Query to execute any of the queries, as seen in Figure 5-20 on page 124. Chapter 5. NetView Integration Module implementation and scenarios 123

140 Figure 5-20 NETVIEW_QUERIES dialog box Using NetView Integration Module from the Tivoli menu By selecting the Tivoli Tivoli Inventory Queries menu option, you can display hardware and software inventories of your network. You can use this information to make informed hardware and software network decisions. These queries can be invoked by the network administrator on any node that has been discovered to be a Tivoli Management Region (TMR) server or a TMR managed node. This discovery is done by the TMR Discovery component of NetView Integration Module. See 5.5, Configuring and using Tivoli Discovery from NetView on page 101 for details. Scenarios for using NetView Integration Module You have just seen how to build a profile to export many fields for many objects. This is a resource, time, and bandwidth consuming process. You will likely want to distribute a profile like this only once, to initially populate the database. Now you can decide what dynamic NetView data you want to keep up-to-date in Inventory. You can design smaller profiles, such as one that only gets the IP status of the node-type objects. You can use the profile scheduler to automate this task for you. 124 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

141 5.6.7 Tivoli Inventory schema additions The IBM Tivoli NetView Integration Module (or Adapter) for Configuration Manager component uses the existing Tivoli schema. The Tivoli NetView Integration Module component simply adds new tables and views to store and later render the NetView-based information. Tables Tables are the database structures that hold data. Data is pushed from NetView to tables in the Tivoli Inventory storage repository. Table 5-3 Tables Table NV_NODES NV_INTERFACES NV_SEGMENTS NV_NETWORKS Details Table for storing node objects from ovwdb Table for storing interface objects from ovwdb Table for storing segment objects from ovwdb Table for storing network objects from ovwdb NV_NODES Table 5-4 shows the NV_NODES table. Table 5-4 NV_NODES Column name Selection_Name IP_Hostname IP_Status isprinter isiprouter vendor iscomputer isconnector isbridge isrouter ispc Primary key YES NO NO NO NO NO NO NO NO NO NO Chapter 5. NetView Integration Module implementation and scenarios 125

142 Column name isip ismlm issnmpsupported SNMP_sysDescr SNMP_sysLocation SNMP_sysContact SNMP_sysObjectID SNMPAgent istivolimn istivolipcmn istma istme istmagateway istmaendpoint Tivoli_Interp Primary key NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NV_INTERFACES Table 5-5 shows the NIV_INTERFACES table. Table 5-5 NV_INTERFACES Column name Selection_Name IP_Address IP_Subnet_Mask IP_Status iscard isinterface isip SNMPifType Primary key YES NO NO NO NO NO NO NO 126 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

143 Column name SNMP_ifPhysAddr SNMP_ifDescr TopM_Network_ID TopM_Segment_ID TopM_Node_ID Primary key NO NO NO NO NO NV_SEGMENTS Table 5-6 shows the NV_SEGMENTS table. Table 5-6 NV_SEGMENTS Column name Selection_Name IP_Status islocation isnetwork isinternet issegment isbussegment isstarsegment istokenringsegment isfddiringsegment isserialsegment isip TopM_Network_ID Primary key YES NO NO NO NO NO NO NO NO NO NO NO NO Chapter 5. NetView Integration Module implementation and scenarios 127

144 NV_NETWORKS Table 5-7 shows the NV_NETWORKS table. Table 5-7 NV_NETWORKS Column name Selection_Name IP_Address IP_Subnet_Mask IP_Status IP_Network_Name islocation isnetwork isinternet issegment isbussegment isstarsegment istokenringsegment isfddiringsegment isip Primary key YES NO NO NO NO NO NO NO NO NO NO NO NO NO Views Views are used by Tivoli to create querable abstractions from the tables. All queries are based on views. Table 5-8 Views View NV_NODE_BASE_VIEW NV_FACE_BASE_VIEW NV_SEG_BASE_VIEW Details View that provides basic information from NV_NODES table. View that provides basic information from NV_INTERFACES table. View that provides basic information from NV_SEGMENTS table. 128 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

145 View NV_NET_BASE_VIEW NV_NODE_ENH_VIEW NV_INVENTORY_VIEW Details View that provides basic information from NV_NETWORKS table. View that provides enhanced information that links interface information in NV_INTERFACES to respective nodes in NV_NODES. View that provides enhanced information that links interface information in NV_INTERFACES to the respective nodes in NV_NODES, as well as information from the Tivoli Inventory INVENTORYDATA and NETWORK_NODE tables. NV_BASE_NODE_VIEW Table 5-9 shows the NV_BASE_NODE_VIEW table. Table 5-9 NV_BASE_NODE_VIEW Column name Selection_Name IP_Hostname IP_Status isprinter isiprouter vendor iscomputer isconnector isbridge isrouter ispc isip ismlm issnmpsupported SNMP_sysDescr SNMP_sysLocation Chapter 5. NetView Integration Module implementation and scenarios 129

146 Column name SNMP_sysContact SNMP_sysObjectID SNMPAgent istivolimn istivolipcmn istma istme istmagateway istmaendpoint Tivoli_Interp NV_FACE_BASE_VIEW Table 5-10 shows the NV_FACE_BASE_VIEW table. Table 5-10 NV_FACE_BASE_VIEW Column name Selection_Name IP_Address IP_Subnet_Mask IP_Status iscard isinterface isip SNMP_ifType SNMP_ifPhysAddr SNMP_ifDescr TopM_Network_ID TopM_Segment_ID TopM_Node_ID 130 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

147 NV_SEG_BASE_VIEW Table 5-11 shows the NV_SEG_BASE_VIEW table. Table 5-11 NV_SEG_BASE_VIEW Column name Selection_Name IP_Status islocation isnetwork isinternet issegment isbussegment isstarsegment istokenringsegment isfddiringsegment isserialsegment isip TopM_Network_ID NV_NET_BASE_VIEW Table 5-12 shows the NV_NET_BASE_VIEW table. Table 5-12 NV_NET_BASE_VIEW Column name Selection_Name IP_Address IP_Subnet_Mask IP_Status IP_Network_Name islocation isnetwork Chapter 5. NetView Integration Module implementation and scenarios 131

148 Column name isinternet issegment isbussegment isstarsegment istokenringsegment isfddiringsegment isip NV_NODE_ENH_VIEW Table 5-13 shows the NV_NODE_ENH_VIEW table. Table 5-13 NV_NODE_ENH_VIEW Column name provided to user Actual table column name Where clause (rules that allow records from separate tables to come together) Node_Name IP_Hostname NV_NODES. Selection_Name NV_NODES.IP_Hostname NV_INTERFACES.TopM_Node_ID = NV_NODES.Selection_Name and NV_INTERFACES.TopM_ IP_Address NV_INTERFACES.IP_Address Network_ID = NV_NETWORKS.Selection_Name IP_Subnet_Mask NV_INTERFACES.IP_Subnet_Mask and Node_Status NV_NODES.IP_ Status NV_INTERFACES.TopM_Segment_ID = NV_SEGMENTS.Selection_Name Vendor_Info SNMPDescription NV_NODES.vendor NV_NODES.SNMP_sysDescr SNMPLocation NV_NODES.SNMP_sysLocation N/A SNMPContact NV_NODES.SNMP_sysContact N/A SNMPAgent NV_NODES.SNMPAgent N/A istivolimn NV_NODES.isTivoliMn N/A istivolipcmn NV_NODES.isTivoliPcMn N/A istma NV_NODES.isTMA N/A isprinter NV_NODES.isPrinter N/A 132 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

149 Column name provided to user Actual table column name Where clause (rules that allow records from separate tables to come together) isiprouter NV_NODES.isIPRouter N/A iscomputer NV_NODES.isComputer N/A isconnector NV_NODES.isConnector N/A isbridge NV_NODES.isBridge N/A isrouter NV_NODES.isRouter N/A ispc NV_NODES.isPC N/A isnodeip NV_NODES.isIP N/A ismlm NV_NODES.isMLM N/A issnmpsupported NV_NODES.isSNMPSupported N/A istme NV_NODES.isTME N/A istmagateway NV_NODES.isTMAGateway N/A istmaendpoint NV_NODES.isTMAEndpoint N/A Tivoli_Interp NV_NODES.Tivoli_Interp N/A Interface_Name NV_INTERFACES.Selection_Name N/A Interface_Status NV_INTERFACES.IP_Status N/A iscard NV_INTERFACES.isCard N/A isinterface NV_INTERFACES.isInterface N/A isinterfaceip NV_INTERFACES.isIP N/A SNMPInterfaceType NV_INTERFACES.SNMP_ifType N/A SNMPMacAddress NV_INTERFACES.SNMP_ifPhysAddr N/A SNMPIfaceDescr NV_INTERFACES.SNMP_ifDescr N/A Network_Name NV_NETWORKS.Selection_Name N/A Segment_Name NV_SEGMENTS.Selection_Name N/A Chapter 5. NetView Integration Module implementation and scenarios 133

150 NV_INVENTORY_VIEW Table 5-14 shows the NV_INBENTORY_VIEW table. Table 5-14 NV_INVENTORY_VIEW Column name provided to user Hardware_Id TME_OBJECT_ID TME_OBJECT_LABEL Tme_IP_Address Computer_Arch Computer_Model Physical_Memory Paging_Space Computer_Scantime Processor_Model Processor_Speed Booted_OS_Name Booted_OS_Version Actual table column name INVENTORYDATA.HARDWARE_ SYSTEM_ID INVENTORYDATA.TME_OBJECT_ ID INVENTORYDATA.TME_OBJECT_ LABEL NETWORK_NODE.NETWORK_ NODE_ADDRESS INVENTORYDATA.COMPUTER_ ARCHITECTURE INVENTORYDATA.COMPUTER_ MODEL INVENTORYDATA.PHYSICAL_ MEMORY_KB INVENTORYDATA.PAGING_SPACE _KB INVENTORYDATA.COMPUTER_ SCANTIME INVENTORYDATA.PROCESSOR_ MODEL INVENTORYDATA.PROCESSOR_ SPEED INVENTORYDATA.BOOTED_OS_ NAME INVENTORYDATA.BOOTED_OS_ VERSION Where clause (rules that allow records from separate tables to come together) NV_INTERFACES.IP_Address =NETWORK_NODE.NETWORK_NO DE_ADDRESS and NV_INTERFACES.TopM_Node_ID =NV_NODES.Selection_Name and NETWORK_NODE.HARDWARE_SY STEM_ID =INVENTORYDATA.HARDWARE_SY STEM_ID and NV_INTERFACES.TopM_Network_ID =NV_NETWORKS.Selection_Name and NV_INTERFACES.TopM_Segment_ID =NV_SEGMENTS.Selection_Name N/A N/A N/A N/A Node_Name NV_NODES.Selection_Name N/A IP_Hostname NV_NODES.IP_Hostname N/A IP_Address NV_INTERFACES.IP_Address N/A 134 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

151 Column name provided to user Actual table column name Where clause (rules that allow records from separate tables to come together) IP_Subnet_Mask NV_INTERFACES.IP_Subnet_Mask N/A Node_Status NV_NODES.IP_Status N/A Vendor_Info NV_NODES.vendor N/A SNMPDescription NV_NODES.SNMP_sysDescr N/A SNMPLocation NV_NODES.SNMP_sysLocation N/A SNMPContact NV_NODES.SNMP_sysContact N/A SNMPAgent NV_NODES.SNMPAgent N/A istivolimn NV_NODES.isTivoliMn N/A istivolipcmn NV_NODES.isTivoliPcMn N/A istma NV_NODES.isTMA N/A isprinter NV_NODES.isPrinter N/A isiprouter NV_NODES.isIPRouter N/A iscomputer NV_NODES.isComputer N/A isconnector NV_NODES.isConnector N/A isbridge NV_NODES.isBridge N/A isrouter NV_NODES.isRouter N/A ispc NV_NODES.isPC N/A isnodeip NV_NODES.isIP N/A ismlm NV_NODES.isMLM N/A issnmpsupported NV_NODES.isSNMPSupported N/A istme NV_NODES.isTME N/A istmagateway NV_NODES.isTMAGateway N/A istmaendpoint NV_NODES.isTMAEndpoint N/A Tivoli_Interp NV_NODES.Tivoli_Interp N/A Interface_Name NV_INTERFACES.Selection_Name N/A Interface_Status NV_INTERFACES.IP_Status N/A Chapter 5. NetView Integration Module implementation and scenarios 135

152 Column name provided to user Actual table column name Where clause (rules that allow records from separate tables to come together) iscard NV_INTERFACES.isCard N/A isinterface NV_INTERFACES.isInterface N/A isinterfaceip NV_INTERFACES.isIP N/A SNMPInterfaceType NV_INTERFACES.SNMP_ifType N/A SNMPMacAddress NV_INTERFACES.SNMP_ ifphysaddr N/A SNMPIfaceDescr NV_INTERFACES.SNMP_ifDescr N/A Network_Name NV_NETWORKS.Selection_Name N/A Segment_Name NV_SEGMENTS.Selection_Name N/A 136 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

153 6 Chapter 6. Extending the solution and best practices Customers typically spend days installing, configuring, and integrating IBM Tivoli systems management applications to manage their complex IT environments. This book describes an advanced approach as to how we can have an improved customer experience by reducing the time required to deploy a targeted systems management solution from days to hours. The other chapters of this book show how to implement our solution to have an automated endpoint installation approach, and how to implement automated inventory scanning and software distribution. In this chapter, we discuss some possible enhancements to our solution. In this chapter, we discuss the following topics: Possible extensions of the solution Best practices Copyright IBM Corp All rights reserved. 137

154 6.1 Possible extensions of the solution We describe some of the possible extensions that can be made to the solution. A customer environment could have a number of IBM Tivoli systems management solutions, such as IBM Web Application Server, Tivoli Management Framework, IBM DB2, IBM Tivoli NetView, IBM Tivoli Monitoring, IBM Tivoli Storage Manager client, and Web Health Console. All these products can run independently to provide a complete systems management solution, and the configuration and usage of some of these products can be time-consuming. We propose that the solution given in this book can be extended to many of these Tivoli products, which, collectively, can result in much easier administration and configuration and, at the same time, also reduce the time required by customers to set and configure multiple IBM Tivoli products. We describe some of the possibilities you can explore and use in different Tivoli environments. However, a good understanding of shell scripting is required to modify the scripts for the desired purpose. Figure 6-1 on page 139 depicts the solution being extended to IBM Tivoli Monitoring. 138 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

155 IBM Tivoli Configuration Manager Gateway IBM Tivoli Monitoring Inventory scans Inventory scans Inventory scans Preferred monitors Preferred monitors Preferred monitors Figure 6-1 Extension of the solution to IBM Tivoli Monitoring Chapter 6. Extending the solution and best practices 139

156 IBM Tivoli Monitoring In order to extend the solution to complete the monitoring solution, several points can be identified. As NetView detects the systems on the network, its database needs to be monitored for new entries. When the new entries are identified, the infrastructure code logs into the system and deploys a Tivoli agent. When the agent logs into the gateway, and the automated inventory and software distribution completes (our solution), we can monitor the connection to the gateway for new entries. When a new entry appears, we can then deploy the IBM Tivoli Monitoring agent code and the preferred monitors, and the Java Runtime Environment (JRE) if necessary. After the monitors have been deployed, the cycle is complete, and the monitoring solution can monitor an endpoint. Obtain the status and informational data with command lines for each endpoint, and use it with the IBM Tivoli NetView status and the IBM Tivoli Monitoring status to present an overall endpoint status. IBM Tivoli Storage Manager You can add some service components to improve the reliability of the infrastructure. Keep in mind the following when building these components: Ease the implementation of trace and message logging View logs for all the products Generate and transfer problem determination data to other machines Send notifications and messages Some backup components can be developed to perform backups based on events from the base solution. The user can choose a known point-in-line where all subsystems are functioning (rollback), because the state of each product can be stored (and displayed) with each backup taken by the Tivoli Storage Manager. Command line interface outputs from the Tivoli Storage Manager client can be parsed to determine backup results and can also be displayed for or by the user. 6.2 Best practices The term best practices is one of the most over-used phrases in consulting these days. In a generic sense, it can be defined as a way of performing a task or a function that is considered to be effective in improving a company s business processes. A best practice should continually add value to a company s products and services, while ensuring the efficiency of the company s daily operations. 140 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

157 6.2.1 Definition Tivoli best practices can be defined as the common, consistent, and repeatable methods used to perform required functions, providing real world value to customers, addressing a wide range of business processes that are, at the same time, critical and supportive from the initial planning phase to the operation and maintenance of the Tivoli management software. Tivoli s best practices are effective ways of accomplishing certain tasks within the disciplines of systems and network management with Tivoli management software. The best practices initiative is an ongoing strategy developed by Tivoli to discover, apply, and broadcast the best in Tivoli software product practices and experiences that relate to functional customer processes. It is the goal of Tivoli to keep their professionals, partners, and customers aware of such practices so that they can benefit from what the Tivoli professional community is doing with Tivoli products. In addition, Tivoli s best practices are able to align people, processes, and technology to achieve the desired state of functionality at the lowest cost. It is not only a matter of doing tasks better, but of distinguishing the tasks that really make a difference to the quality and effectiveness of the work Strategy Scope When developing a best practice, it should be defined in such a generic way that it does not limit itself to the capabilities of the tools that are likely to be used to implement the different aspects of the management model. The main idea of the best practice is, from a business perspective, to define the management needs of a resource in an ideal world, in which anything is possible, and where there are no performance costs of management. When it comes to implementing the best practices, these issues will emerge, and the business needs will determine the detailed implementation issues, such as monitoring frequencies, thresholds, and corrective actions. If the business needs and benefits are high enough, anything is possible. Common acceptance guarantees that a majority of the community interested in managing the actual resource agrees that the best practice is, in fact, what it claims to be: the best set of practices that can be applied to manage this particular resource. It is not uncommon that two or more specialists have a difference of opinion regarding details of the best practice. However, these types of discussions may prove to be very fruitful and bring up certain aspects that otherwise could have been forgotten. The specialists that agree to a best practice may be recruited from various organizations, depending on the nature of the resource that is to be managed. If you develop a best practice for managing a specific type of application system, for example, IBM WebSphere applications, Chapter 6. Extending the solution and best practices 141

158 to be used within your own organization, chances are that you will need support from the application owner, who is in charge of the business aspects of the application, subject matter experts, and the systems administrators in charge of the run-time environment. At the best practices level, there is no need to get acceptance from the system administrators in charge of the tools used to implement your best practice (they have not been set at this point in time), even though it is advisable to get as many preapprovals as possible. The scope of your best practice may vary from one to the other. In most cases, you will work with best practices for resource management within your own organization, in which case, you would use an existing best practice and apply it to your specific environment. In other cases, especially if you are involved with standardization bodies or development of general system management platforms, such as Tivoli, you would be the one defining the best practice to be used by others. When developing best practices, you should be sensitive to the fact that best practices are seen as templates or skeletons that will have to be modified to fit specific needs of the organization in which they are implemented. Cultural or company differences, practices, policies, and laws may restrict or demand special features of the best practice, even though it has already been accepted by the subject matter experts of that particular field. In our everyday life, we are surrounded by best practices, some of which have become laws. Others are unwritten rules that most people within an organization or a society comply with because of belief, tradition, experience, or convenience. Most best practices may be deviated from when special needs or local circumstances demand it, except where it is expressly forbidden. Developing and complying with best practices ensures the quality of your management solution. Of course, the best practice has to be maintained and constantly revised in order to incorporate changes to the resources being managed, to refine the existing best practices, to comply with changing company policies and procedures, and to met new requirements that may have arisen. 142 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

159 A Appendix A. Scripts used in this publication This appendix contains scripts used in this publication. This appendix describes the following four scripts used to design this solution: rk_first.sh rk_second.sh rk_third.sh rk_fourth.sh Copyright IBM Corp All rights reserved. 143

160 rk_first.sh Example A-1 contains the rk_first.sh script. Example: A-1 rk_first.sh ###################################################################### ########################FIRST SCRIPT################################## ###################################################################### ## THIS SCRIPTS WOULD BE EXECUTED ON SERVER WHERE NETVIEW IS INSTALLED ## It executes "ovobjprint" command to get the all uniq types of ## SNMP Agent discovered by NetView Server where LCF code is ## Not installed and it is of type Computer (Node = True). ## ## After getting uniq SNMP Agents, it executed "nvutil (Unix) / ## smartsetutil (NT) which provides the IP address on node. ## Once IP Address is generated from nvutil / smartsetutil command, ## it is compared with the entries under EXCLUSION and in case it is located, ## it is excludes from the list and only non-matching entries ( from ## Exlcusion list) are generated with file name as Type of OS. All UNKNOWN ## type of IP Addresses are assumed as NT and NT TMA code is installed. ###################################################################### ###################################################################### #### Directory where the scripts is executed mdir="/tmp/shell/main/" #### Below variable mep_shell mentions the shell script name to be executed once all nodes are #### discovered. This will be done one default_password parameter is set to True. mep_shell=$mdir"rk_second.sh" ##### Master file declaration minp1=$mdir"nv_master.lst" minp2=$mdir"nv_exclude.lst" # List of NetView agent with OS type # List of exclusion list ##### Variables for Output file. Hence for NT, file name would be 'out_nt.nep'. ##### We may modify it as per our wish. mfirst_var="out_" mlast_var=".nep" ##### Temporary files declaration.. mout1=$mdir"tmp_magnt.tmp" mtmp=$mdir"tmp.tmp" mtmp1=$mdir"tmp1.tmp" ########## Log file declaration 144 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

161 mlog_sniff=$mdir"log_sniff.log" mlog_ovobj=$mdir"log_ovobj.log" mlog_nvutil=$mdir"log_nvutil.log" ###### Variables being used under script moos="first" ########### Insertion of date / time with log files for i in $mlog_sniff $mlog_ovobj $mlog_nvutil do echo " " >>$i echo "=====================================================" >>$i echo "Script started on " `date` >> $i echo "=====================================================" >>$i echo " " >>$i done ### Whether default password is provided..if Yes, then what is the filename ### File contains three field. First is OS, Second User & thirs password ### e.g., for NT it would be like "NT Administrator password" ### unix would have entry as "UNIX root password". If this is not followed, ### scripts shall not be executed successfully. mdefault_password=true mdefault_file=$mdir"default.lst" muser="" mpass="" if [ $mdefault_password = True ] ; then if [ -r $mdefault_file ] ; then for i in "NT" "UNIX" ## Start loop for Validity of user / password for NT / UNIX OS do muser=`cat $mdefault_file grep $i awk '{ print $2}'` mpass=`cat $mdefault_file grep $i awk '{ print $3}'` if [ "$muser" = "" ] [ "$mpass" = "" ] ; then for j in $mlog_sniff $mlog_ovobj $mlog_nvutil ## Start loop for LOG do echo "Under $i OS, user account or password is blank. Update it immediately. Resetting as False to default password variable.." >>$j echo "Kindly provide the password for each node & execute the next script manually for $i Operating System." >>$j echo "Under $i OS, user account or password is blank. Update it immediately. Resetting as False to default password variable.." echo "Kindly provide the password for each node & execute the next script manually for $i Operating System." echo "" >>$j done ##Endloop for LOG mdefault_password=false fi Appendix A. Scripts used in this publication 145

162 done ## Endloop for validity of user / password for NT / UNIX OS else for j in $mlog_sniff $mlog_ovobj $mlog_nvutil do echo "File $mdefault_file containing password is not present. Check the filename / directory.." >>$j echo "File $mdefault_file containing password is not present. Check the filename / directory.." done mdefault_password=false fi fi ## End of IF loop for default_password checking ######## Getting the Operating System of the maching executing the script.. ######## Since nvutil command name varies on NT / UNIX, hence ######## putting the command name under variable.. rm $mout1 2>/dev/null touch $mout1 mopsys="" if [ `uname` = "Windows_NT" ] ; then mutil_command="smartsetutil" else mutil_command="nvutil" fi ###################Defining the path of SNIFFER CONFIGURATION FILE mnvpath="/usr/ov/conf/" ## Directory where nvsniffer.conf is present msniff_file=$mnvpath"nvsniffer.conf" mconf="islcf 9494 TivoliLCF Tivoli TMA *" ###### Checking under sniffer configuration file for LCF parameter ###### If entry is missing, appending.. msnf=`grep "^$mconf" $msniff_file` if [ "$msnf" = "" ]; then echo $mconf >> $msniff_file echo "Appended record under $msniff_file file" >>$mlog_sniff else echo "$mconf is present under $msniff_file" >> $mlog_sniff fi echo $mconf >$mtmp echo "Started to execute nvsniffer command to update NetView Object database.">>$mlog_sniff nvsniffer -f $mtmp >>$mlog_sniff 2>>$mlog_sniff echo "Executed nvsniffer command to update NetView Object database.">>$mlog_sniff 146 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

163 #ovobjprint grep -i SNMPAgent grep -iv Collection cut -f 6 sort uniq cut -d"(" -f1> $mout1 ################ Splitted the above command since on NT, it used to hang echo "Generating SNMPAgent.." >> $mlog_ovobj ovobjprint > $mtmp1 2>>$mlog_ovobj cat $mtmp1 grep -i SNMPAgent grep -iv Collection cut -f 6 sort cut -d"(" -f1> $mtmp 2>>$mlog_ovobj if [ $? = 0 ] ; then echo "Successfully generated SNMPAgent.." >>$mlog_ovobj else echo "Error in ovobjprint command.. Check it.." >>$mlog_ovobj exit 0 fi ##### Initializing the output file STARTED... for i in "NT" "UNIX" "UNKNOWN" do mparam=$mdir$mfirst_var$i$mlast_var rm $mparam 2>/dev/null done ##### Initialization over ## Below lines are put to find the unique records. Under NT uniq command ## could not be executed. while true read i do muniq=true while true read j do if [ "$i" = "$j" ]; then muniq=false break fi done<$mout1 if [ $muniq = true ]; then echo $i >> $mout1 fi done < $mtmp ## Creation of Operating System wise list of IP Address ## after exlcuding the IP Address mentioned under EXCLUSION list. Appendix A. Scripts used in this publication 147

164 while true read i do ## Loop to read $mout1 file STARTED.. mgrep=`grep -i "$i" $minp1 cut -d"$" -f2` if [ "$mgrep" = "" ]; then mos="unknown" else mos=$mgrep fi ## Below lines associate the filename based on Operating System ## e.g., for NT it will be as $mfirst_varnt$mlast_var. Hence ## if mfirst_var is "out" and mlast_var is ".nep" then output ## filename would be "out_nt.nep". To change the name, the variable ## field (mfirst_var & mlast_var) must be modified. The same must be mentioned ## under Endpoint Installation Script. if [! "$mos" = "SKIP" ] ; then #mout2="out_"$mos".nep" mout2=$mdir$mfirst_var$mos$mlast_var if [ "$moos" = "First" ] ; then moos=$mos else mrc=`echo "$moos" grep "$mos"` if [ "$mrc" = "" ]; then moos=$moos" "$mos fi fi #nvutil e "((SNMPAgent = '$i') &&!(islcf = True) && (iscomputer = True))" >$mtmp echo "Execution of $mutil_command script on $i agent to get the Node without TMA.." >> $mlog_nvutil `echo $mutil_command` e "((SNMPAgent = '$i') && not(islcf = True) && (isnode = True))" >$mtmp1 2>> $mlog_nvutil echo "Compeleted the execution of $mutil_command script for $i agent.." >> $mlog_nvutil cat $mtmp1 cut -d"(" -f2 cut -d")" -f1>$mtmp #Steps for exclusion list... for j in `cat $mtmp` do mok='yes' 148 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

165 rk=true while rk=true read k do if [ "$j" = "$k" ]; then mok='no' rk=false fi done < $minp2 if [ "$mok" = "Yes" ]; then ## Now it checks whether default password is put. If yes, associate with IP Address if [ $mdefault_password = True ] ; then if [ "$mos" = "UNKNOWN" ] ; then mos="nt" fi muser=`cat $mdefault_file grep $mos awk '{ print $2}'` mpass=`cat $mdefault_file grep $mos awk '{ print $3}'` fi wep ls -i label,address grep $j ## Checking whether this current node is having TMA if [ $?!= 0 ] ; then echo $j" "$muser" "$mpass >>$mout2 else echo "This endpoint $j already exists in wep list.." fi fi done fi done < $mout1 #echo "OS TYPE => " $moos rm $mout1 $mtmp $mtmp1 ## Below mentioned script shall check whether default password is ## provided by Administrator. Incase Yes, it will associate the ## mentioned account with node and execute the TMA installation ## script. Otherwise, it shall stop here and Administrator ## has to execute the TMA installation script. if [ $mdefault_password = True ] ; then for i in "NT" "UNIX" "UNKNOWN" do mparam=$mdir$mfirst_var$i$mlast_var if [ -r $mparam ] ; then Appendix A. Scripts used in this publication 149

166 mrow=`cat $mparam wc -l` if [ $mrow -gt 0 ] ; then sh $mep_shell $i $mparam & fi else echo "No record under $mparam file.." >>$mlog_nvutil fi done else echo "Update the output file with account / password & execute TMA installation script.." >>$mlog_nvutil fi rk_second.sh Example A-2 contains the rk_second.sh script. Example: A-2 rk_second.sh #!/bin/ksh function_create_policyregion() { mpolicy_region=$1 echo "Function for Policy Region : " $mpolicy_region >>$mlog_eplog wlookup -Lr PolicyRegion $mpolicy_region >>$mlog_eplog 2>>$mlog_eplog if [ $?!= 0 ] ; then echo "Policy Region $mpolicy_region does not exisits.. Creating it..">>$mlog_eplog madmin="" for i in `wlookup -alr Administrator` do j=" -a "$i madmin=$madmin$j done #mresource=" -m ManagedNode -m ProfileManager -m InventoryConfig -m Endpoint" mresource=" -m ManagedNode -m ProfileManager -m Endpoint -m TaskLibrary" echo "Creating Policy Region $mprname..">>$mlog_eplog wcrtpr $madmin -m ManagedNode $mresource $mpolicy_region >>$mlog_eplog 2>>$mlog_eplog if [ $? = 0 ]; then echo "Successfully created Policy Region $mpolicy_region.." >>$mlog_eplog else echo "Could not create Policy Region $mpolicy_region. Check with Administrator. " >>$mlog_eplog fi 150 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

167 fi } function_create_task_library() { mtask_library=$1 mpolicy_region=$2 wlookup -Lr TaskLibrary $mtask_library >>$mlog_eplog 2>>$mlog_eplog if [ $?!= 0 ] ; then echo "Creating TASK LIBRARY $mtask_library under $mpolicy_region Policy Region.." >>$mlog_eplog wcrttlib $mtask_library $mpolicy_region >>$mlog_eplog 2>>$mlog_eplog if [ $? = 0 ]; then echo "Successfully created Task_Library $mtask_library under $mpolicy_region policy region.." >>$mlog_eplog else echo "Could not create TASK Library $mtask_library under $mpolicy_region policy region." >>$mlog_eplog fi fi } function_create_task() { mnode_name=$3 mtask_library=$2 mtask_name=$1 wgettask $mtask_library $mtask_name >>$mlog_eplog 2>>$mlog_eplog if [ $?!= 0 ]; then if [! -r $mtask_file ] ; then echo "hostname>host.out">$mtask_file fi echo "wcrttask -t $mtask_name -l $mtask_library -r user -i default $mnode_name $mtask_file" >>$mlog_eplog 2>>$mlog_eplog wcrttask -t $mtask_name -l $mtask_library -r user -i default $mnode_name $mtask_file >>$mlog_eplog 2>>$mlog_eplog if [ $? = 0 ]; then echo "Successfully created task $mtask_name under Task_Library $mtask_library." >>$mlog_eplog else echo "Could not create task $mtask_name under Task_Library $mtask_library." >>$mlog_eplog fi fi } function_execute_task() { Appendix A. Scripts used in this publication 151

168 mep=$1 mtask_library=$2 mnext=false echo "Executing task for $mep node.." >>$mlog_eplog wruntask -t $mtask_name -l $mtask_library -h $mep >>$mlog_eplog 2>>$mlog_eplog echo "Task over for $mep node. Executing wadminep command to get host.out file.." >>$mlog_eplog wadminep $mep get_file host.out host.out >>$mlog_eplog 2>>$mlog_eplog if [ $? = 0 ] ; then mnext=true else echo "Task $mtask could not be executed.. " >>$mlog_eplog fi return } ########################################################## #########################SECOND SCRIPT#################### ########################################################## ## This shell script has been created to install Tivoli ## Management Agent on the machine mentioned under ## Input file. ## Note : The record (IP Address) mentioned under Input file ## must contain Administrator account with password. ## Incase of Unix machine, account must be as "root" ## and incase of NT, it would be as "Administrator" ## Script checks whether default password for each type of ## Operating System (NT / Unix) has been provided. If, default ## Administrator account is provided, system shall automatically ## Start this script other wise administrator has to update the ## Input with Administrator account / password and execute the ## script. ## All unknown type of OS are put under Windows NT operating system. ## The unsuccessfull nodes (where TMA could not be installed) are redirected ## to failed log file. Administrator has to check physically to resolve the ## issue of operating system / password or availability of the machine. ########################################################## ########################################################## mparam_os=$1 minputfile=$2 #### Input - Directory where the scripts is executed mdir="/tmp/shell/main/" 152 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

169 ####### Input - File name of the Inventory shell scripts.. minv_shell=$mdir"rk_third.sh" #### Input - List of log files created during installation of TMA mlog_success=$mdir"log_successep.log" mlog_failed=$mdir"log_failedep.log" mlog_taskfailed=$mdir"log_failedtask.log" mlog_eplog=$mdir"log_endpoint.log" ########### Insertion of date / time with log files for i in $mlog_success $mlog_failed $mlog_eplog $mlog_taskfailed do echo " " >>$i echo "=====================================================" >>$i echo "Script of Endpoint started on " `date` >> $i echo "=====================================================" >>$i echo " " >>$i done if [ "$mparam_os" = "" ] [ "$minputfile" = "" ] ; then echo "All parameters are not passed to this script..please check." >>$mlog_eplog echo "usage: inv_script_filename [Operating System {NT UNIX }] [Filename {containing IP Address with user / password}] " >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog exit fi >>$mlog_eplog 2>>$mlog_eplog if [! -r $minputfile ] ; then echo "The parameter Inputfile $minputfile not present..">>$mlog_eplog echo "usage: inv_script_filename [Operating System {NT UNIX }] [Filename {containing IP Address with user / password}] " >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog exit fi >>$mlog_eplog 2>>$mlog_eplog if [ "$mparam_os"!= "NT" ] && [ "$mparam_os"!= "UNKNOWN" ] && [ "$mparam_os"!= "UNIX" ] ; then echo "The value of operating system is not correct..please check.." >>$mlog_eplog echo "Acceptable operating systems are NT / UNIX " >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog exit fi >>$mlog_eplog 2>>$mlog_eplog #echo "The OS parameter is => " $mparam_os #echo "The File parameter is => " $minputfile Appendix A. Scripts used in this publication 153

170 if [ "$mparam_os" = "UNKNOWN" ] ; then mparam_os="nt" fi >>$mlog_eplog 2>>$mlog_eplog if [ "$mparam_os" = "NT" ] ; then os only...started if loop ### Following input is required for NT ## Input - List of variables like Endpoint name, Gateway etc. For NT Endpoint only minput_source_ep="3b046a" wlookup -r Endpoint $minput_source_ep >>$mlog_eplog 2>>$mlog_eplog if [ $? = 0 ] ; then wep $minput_source_ep status >>$mlog_eplog 2>>$mlog_eplog if [ $? = 1 ] ; then echo "This endpoint $minput_source_ep is not running. Check & start it before executing the script." >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog exit fi else echo "This endpoint $minput_source_ep does not exists under Endpoint list.." >>$mlog_eplog echo "Stopping the processing of script..." >>$mlog_eplog exit fi ## Input - Gateway to which Endpoint has to login must be with For NT ## Endpoint only e.g. for GW1 it would be GW+9494 ## minput_source_gateway=" " fi ## Checking of NT loop OVER.. ### Input - List of policy region, task library & task to execute task ### to update the Endpoint hostname inplace of IP Address mpolicy_region="aix-tmr1b-region" mnode_name="aix-tmr1b" ## Name of the ManagedNode on which this script is executed.. mtask_library="test_task" mtask_name="test_task" mtask_file=$mdir"task.sh" ## Starting the installation of TMA for NT Servers echo "Starting Endpoint Installation for $mparam_os Operating System." >> $mlog_eplog if [ $mparam_os = "NT" ] ; then 154 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

171 winstlcf -N $minput_source_ep -g $minput_source_gateway -f $minputfile -Y -R >>$mlog_eplog 2>>$mlog_eplog else winstlcf -f $minputfile -Y >>$mlog_eplog 2>>$mlog_eplog fi echo "Endpoint Installation over.." >>$mlog_eplog rm host.out 2>/dev/null for mep in `cat $minputfile awk '{print $1}'` do echo "Checking the registration of Endpoint with wep command.." >>$mlog_eplog wep $mep status >>$mlog_eplog 2>>$mlog_eplog if [ $?!= 0 ]; then echo $mep >> $mlog_failed else ##### Put mcheckpol=false if checking of policy region, task library & ##### Task to be ignore. If mcheckpol is put to false then the ##### policy region, task library & task must be mentioned correctly ##### as it is present ###################################################################### ## Note=>It is adviced to ensure that all variables within ## ## the if condition are present and mcheckpol is put to ## ## false to reduce the processing time on account of ## ## checking these components which are really present. ## ###################################################################### mcheckpol=true if [ $mcheckpol = True ] ; then #########Checking whether policy region is present. ## If not, create the policy region function_create_policyregion $mpolicy_region #########Checking whether task library is present. If not, creating function_create_task_library $mtask_library $mpolicy_region #########Checking whether task is present. If not, creating function_create_task $mtask_name $mtask_library $mnode_name fi mnext=true function_execute_task $mep $mtask_library if [ $mnext = False ] ; then echo "Task could not be executed on $mep node. It shall be executed once more after 5 minutes." >>$mlog_eplog sleep 300 function_execute_task $mep $mtask_library Appendix A. Scripts used in this publication 155

172 fi if [ $mnext = False ] ; then echo $mep >> $mlog_taskfailed echo "Task could not be executed on $mep node second time..please check.." >>$mlog_eplog minv_ep=$mep else echo $mep >> $mlog_success mrkos=`uname` if [ "$mrkos"!= "Windows_NT" ] ; then ex host.out<<end %s/ //g wq! END fi minv_ep=`cat host.out` wep $mep set_label -s $minv_ep >>$mlog_eplog 2>>$mlog_eplog fi echo "Return value : " $mnext sh $minv_shell $minv_ep fi done rk_third.sh Example A-3 contains the rk_third.sh script. Example: A-3 rk_third.sh function_create_policyregion() { mnext=true mpolicy_region=$1 echo "Function for Policy Region : " $mpolicy_region >>$mlog_invlog wlookup -r PolicyRegion $mpolicy_region >>$mlog_invlog 2>>$mlog_invlog if [ $?!= 0 ] ; then echo "Policy Region $mpolicy_region does not exisits.. Creating it..">>$mlog_invlog madmin="" for i in `wlookup -alr Administrator` 156 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

173 do j=" -a "$i madmin=$madmin$j done mresource=" -m ManagedNode -m ProfileManager -m InventoryConfig -m Endpoint" echo "Creating Policy Region $mpolicy_region_name..">>$mlog_invlog wcrtpr $madmin -m ManagedNode $mresource $mpolicy_region >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ]; then echo "Successfully created Policy Region $mpolicy_region.." >>$mlog_invlog else echo "Could not create Policy Region $mpolicy_region. Check with Administrator. " >>$mlog_invlog mnext=false fi fi return } function_create_profile_manager() { mnext=true mpolicy_region=$1 mprofile_manager_name=$2 #echo "Poli : " $mpolicy_region #echo "PrfMgr : " $mprofile_manager_name wlookup -Lr ProfileManager $mprofile_manager_name >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ]; then echo "Inventory profile Manager $mprofile_manager_name already present.." >>$mlog_invlog else echo "Creating Inventory Profile Manager $mprofile_manager_name since it is not found " >>$mlog_invlog wcrtprfmgr $mpolicy_region_name $mprofile_manager_name >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ]; then echo "Created Inventory Profile Manager $mprofile_manager_name" >>$mlog_invlog echo "Setting dataless profile to $mprofile_manager_name profile manager." >>$mlog_invlog wsetpm >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ] ; then echo "Done dataless to profile manager $mprofile_manager_name." >>$mlog_invlog else echo "Problem enclounterd while setting as dataless profile to $mprofile_manager_name. Set manually.." >>$mlog_invlog fi else Appendix A. Scripts used in this publication 157

174 mnext=false echo "Problem during creation of Inventory Profile Manager $mprofile_manager_name" >>$mlog_invlog fi fi return } function_create_inventory_profile() { mprofile_manager_name=$1 mprofile_name=$2 mnext=true wlookup -Lr InventoryConfig $mprofile_name >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ]; then echo "Inventory profile $mprofile_name already present.." >>$mlog_invlog else echo " " echo "Creating Inventory Profile $mprofile_name" >>$mlog_invlog InventoryConfig $mprofile_name >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ]; then echo "Created Inventory Profile $mprofile_name" >>$mlog_invlog echo "Updating the PC Software signature & registry scan / update for $mprofile_name " >>$mlog_invlog wsetinvpcsw -r BOTH -s >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ] ; then echo "Completed the setting PC S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog else echo "Error while setting PC S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog fi echo "Updating the UNIX Software signature & registry scan / update for $mprofile_name " >>$mlog_invlog wsetinvunixsw -p BOTH -s >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ] ; then echo "Completed the setting UNIX S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog else echo "Error while setting UNIX S/W Sign / Registry scan / Update for $mprofile_name." >>$mlog_invlog fi else echo "Problem during creation of Inventory Profile $mprofile_name" >>$mlog_invlog mnext=false 158 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

175 fi fi } ###################################################################### ## START OF SCRIPT ###################################################################### #### Input - Directory where the scripts is executed mdir="/tmp/shell/main/" mlog_invlog=$mdir"log_inv.log" ####### Input - File name of the Software Distribution scripts.. msd_shell=$mdir"rk_fourth.sh" echo "" >>$mlog_invlog echo "=====================================================" >>$mlog_invlog echo "Script of Inventory scanning started on " `date` >> $mlog_invlog echo "=====================================================" >>$mlog_invlog echo "" >>$mlog_invlog mepname=$1 echo "Endpoint for Inventory Scan : " $mepname if [ "$mepname" = "" ] ; then echo "The parameter value (endpoint name) is missing..." >>$mlog_invlog echo "Usage : ScriptFileName <endpoint_name>.." >>$mlog_invlog echo "Stopping the process. Re-execute it using correct parameter.." >>$mlog_invlog exit fi mpolicy_region_name="auto_inventory" mprofile_manager_name="inventory_scan" mprofile_name="test_scan" ##### Put mcheckpol=false if checking of policy region, task library & ##### Task to be ignore. If mcheckpol is put to false then the ##### policy region, task library & task must be mentioned correctly ##### as it is present ###################################################################### ## Note=>It is adviced to ensure that all variables within ## ## the if condition are present and mcheckpol is put to ## ## false to reduce the processing time on account of ## ## checking these components which are really present. ## ###################################################################### mcheckpol=true Appendix A. Scripts used in this publication 159

176 #mcheckpol=false if [ $mcheckpol = True ] ; then #########Checking whether policy region is present. ## If not, create the policy region mnext=true function_create_policyregion $mpolicy_region_name if [ $mnext = True ] ; then function_create_profile_manager $mpolicy_region_name $mprofile_manager_name fi if [ $mnext = True ] ; then function_create_inventory_profile $mprofile_manager_name $mprofile_name fi >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ]; then echo "Endpoint $mepname successfully subscribed to $mprofile_manage_name ProfileManager." >>$mlog_invlog else echo "Error while subscribing Endpoint $mepname to $mprofile_manage_name ProfileManager." >>$mlog_invlog >>$mlog_invlog 2>>$mlog_invlog if [ $? = 0 ] ; then echo "Endpoint $mepname successfully distributed to $mprofile_manage_name ProfileManager." >>$mlog_invlog echo "Now executing the script $msd_shell for Software distribution.." >>$mlog_invlog sh $msd_shell $mepname else echo "Error while distributing Endpoint $mepname to $mprofile_manage_name ProfileManager." >>$mlog_invlog fi 160 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

177 rk_fourth.sh Example A-4 contains the rk_fourth.sh script. Example: A-4 rk_fourth.sh ###########Software distribution script.." ########### The endpoint is input as parameter in the script #### Input - Directory where the scripts is executed mdir="/tmp/shell/main/" mlog_splog=$mdir"log_sp.log" echo "">>$mlog_splog echo "===============================================">>$mlog_splog echo "Script of Software Distribution started on "`date` >>$mlog_splog echo "===============================================">>$mlog_splog echo "">>$mlog_splog if [ "$1" = "" ] ; then echo "Wrong input parameter..exiting.." >>$mlog_splog echo "Usage : script_name <Endpoint_name> " >>$mlog_splog echo "Wrong input parametet under Software Distribution script..exiting" exit fi mendpoint=$1 msppm="datamovingprofile" msppack="datamovingrequests.1" mnext=false wlookup -r ProfileManager $msppm >>$mlog_splog if [ $? = 0 ] ; then echo "Subscribing Endpoint $mendpoint to ProfileManager $msppm.." >>$mlog_splog 2>>$mlog_splog if [ $? = 0 ] ; then mnext=true echo "Successfully subscribed Endpoint $mendpoint to ProfileManager $msppm..">>$mlog_splog else echo "Error while subscribing Endpoint $mendpoint to ProfileManager $msppm..">>$mlog_splog fi else echo "Profile Manager $msppm is not present.." >>$mlog_splog fi Appendix A. Scripts used in this publication 161

178 if [ $mnext = True ] ; >>$mlog_splog 2>>$mlog_splog if [ $? = 0 ] ; then echo "Successfully distributed Software Package $msppack on Endpoint $mendpoint " >>$mlog_splog else echo "Error while distributing Software Package $msppack on Endpoint $mendpoint " >>$mlog_splog fi else echo "Error at ProfileManager stage.. Distribution did not initiate.." >>$mlog_splog fi 162 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

179 B Appendix B. Additional material This redbook refers to additional material that can be downloaded from the Internet as described below. Locating the Web material The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to: ftp:// Alternatively, you can go to the IBM Redbooks Web site at: ibm.com/redbooks Select Additional materials and open the directory that corresponds with the redbook form number, SG Using the Web material The additional Web material that accompanies this redbook includes the following files: File name SG zip Description Zipped code of the solution Copyright IBM Corp All rights reserved. 163

180 System requirements for downloading the Web material The following system configuration is recommended: Hard disk space: 10 MB minimum Operating systems: Microsoft Windows or UNIX How to use the Web material Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder. 164 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

181 Abbreviations and acronyms CORBA CTOC DHCP DMI DMZ IBM ICMP ISMP ITSO JRE JRIM LAN LDAP MDist MIF RDBMS RIM SCS SP SPB SPD TCP/IP TMA TMR Common Object Request Broker Architecture collection table of contents Dynamic Host Configuration Protocol Desktop Management Interface demilitarized zone International Business Machines Corporation Internet Control Message Protocol Install Shield MultiPlatform International Technical Support Organization Java Runtime Environment Java RIM local area network Lightweight Directory Access Protocol multiplex distribution Management Information Format relational database management system RDBMS Interface Module Scalable Collection Service software package software package block software package definition Transmission Control Protocol/Internet Protocol Tivoli management agent Tivoli Management Region Copyright IBM Corp All rights reserved. 165

182 166 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

183 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 Other resources For information on ordering these publications, see How to get IBM Redbooks on page 168. All About IBM Tivoli Configuration Manager Version 4.2, SG An Introduction to Tivoli Enterprise, SG These publications are also relevant as further information sources: IBM Tivoli Configuration Manager Planning and Installation Version 4.2, GC IBM Tivoli Configuration Manager Release Notes Version 4.2, GI IBM Tivoli Configuration Manager User s Guide for Inventory Version 4.2, SC IBM Tivoli Configuration Manager User s Guide for Software Distribution Version 4.2, SC IBM Tivoli Configuration Manager User's Guide for Inventory Version 4.2, SC IBM Tivoli Configuration Manager Reference Manual for Software Distribution Version 4.2, SC IBM Tivoli NetView for UNIX Release Notes, GI IBM Tivoli NetView for Windows Release Notes, GI Tivoli Management Framework Maintenance and Troubleshooting Guide Version 4.1, GC Tivoli Management Framework Planning for Deployment Guide Version 4.1, GC Tivoli Management Framework Reference Manual Version 4.1, SC Tivoli Management Framework User s Guide Version 4.1, GC Copyright IBM Corp All rights reserved. 167

184 Tivoli NetView for UNIX Administrator s Guide Version 7.1, SC Tivoli Software Distribution Reference Manual Version 4.1, GC How to get IBM Redbooks You can order hardcopy Redbooks, as well as view, download, or search for Redbooks at the following Web site: ibm.com/redbooks You can also download additional materials (code samples or diskette/cd-rom images) from that site. 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. 168 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

185 Index Symbols /etc/tivoli/setup_env.sh 55 A Activity Planner 5, 13, 19 20, 22, 56, 72 Activity Plan Editor 52 Activity Plan Monitor 52, 73 Activity Planner Database 53 Activity Planner Server Change Management 20 Activity plans 22 administrative account 33 AIX 5L Version application management 77 architecture 11 automated endpoint installation process 13 B base operating system bash shell 41 benefits of the solution 3 Best practices define 141 scope 142 strategy 141 WebSphere-based applications 141 business policies 9 C Change Manager 5 Cisco 9 CiscoWorks collection 7 collection manager 7 collection table of contents 7 combined systems 85 command line distribution 72 command line interface 98 Command line interface outputs 140 community name 15 community names 54 components used by Inventory 6 computer host name 30 Configuration Change Manager configuration repository 6 configuring activity plans 22 control character 40 cost reduction 3 cron 104 CTOC 7 D dataless 45 dataless profile manager 45 DB depot 7 description of the solution 2 diagnostic techniques 81 distributed systems 77 distributing a software package using Activity Planner 22 using command line 23 DMZ 10 Dynamic Host Configuration Protocol 39 E editing the exclusion list 56 endpoint control 22 endpoint installation script 18 Enterprise Directory Query Facility 5 event response 9 Exclusion list 55 F features of the solution 3 G gatelog 82 Gateway depots 52 gateway IP address 58 generic outline 79 GUI components 6 Copyright IBM Corp All rights reserved. 169

186 H host name 76 hostname command 76 hub Tivoli Management Region server 55 hub-spoke configuration 52, 55 I IBM DB2 138 IBM Tivoli Configuration Manager 21, 23, 51 Software Distribution gateway 54 Software Distribution source host 54 IBM Tivoli Configuration Manager Version IBM Tivoli Inventory server IBM Tivoli Monitoring 138 IBM Tivoli Monitoring agent code 140 IBM Tivoli NetView 138 IBM Tivoli NetView Integration Module IBM Tivoli NetView Integration Adapter for Configuration Manager 106 IBM Tivoli NetView Integration Module for Configuration Manager 106 installing 106 IBM Tivoli NetView Integration Module for Configuration Manager 106, 110, 124 components 86 install 110 installing 90 scenarios 124 schema additions 125 tables 125 using from the menu 124 views 128 IBM Tivoli NetView Integration Module for Configuration Manager components 107 IBM Tivoli NetView Java Web console 9 IBM Tivoli Network Diagnostics 95 IBM Tivoli Network Diagnostics for Configuration Manager 95 IBM Tivoli Network Diagnostics Gateway for Configuration Manager 95 IBM Tivoli Software Distribution server IBM Tivoli Storage Manager 138 IBM Web Application Server 138 ICMP 10 implementation strategies 41 InstallShield image 18 interconnected regions 80 interconnected Tivoli Management Regions 79 Internet Control Message Protocol 98 Inventory 4, 77 inventory 53 Inventory collections 6 inventory data handler 7 Inventory distribution 52 Inventory gateway 6 Inventory object 7 inventory profile manager 42, 44 inventory query 64 inventory scan 63 inventory scanning activity 40 inventory scan script 48 Inventory schema additions 125 L LCF entry 28 Lenient distribution 22 log file 63, 78 log_inv.log 63 log_nvutil.log 60 log_ovobj.log 59 log_snigg.log 60 lookup table 15 M managed node server 39 mandatory parameters 26 mdefault_password 31 mdir 67 MDist 2 6, 53 MDist 2 database 53 MDist 2 GUI 52 MDist 2 GUI 72 MDist 2 repeater manager 7 mdist log 82 mdist2 53 modem 27 multiple RIM objects 6 multiplexed distribution 6 N naming standards 22 nested software packages 82 Netscape 103 netstat 95 NetView 8, 23, 26, 51 52, 54, Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

187 auto discovery node feature 14 NetView client 86 NetView component 13 NetView environment variables 58 NetView object database 60 NetView seed file 59 NetView server 54 NetView sniffer configuration 28 submaps 95 usage scenarios 85 NetView agent master file 26 NetView Integration Module for Configuration Manager 52, 112 components 90 NetView inventory profiles 113, 123 creating 113 distributing 120 drag and drop 123 NetView Inventory query library 111 NetView object database 29 NetView submap 100 NetWare 4 network device inventory data 23 network devices 27 Network Diagnostics 86 network information 10 network management 23, 85 newly installed node 79 node duplication 123 nv_exclude.lst 57 nvsniff.conf file 28 O objcalls 80 operating system type 60, 69 OS/2 4 OS/390 4 oserv 79 oservlog 82 out_nt.nep 60 out_unix.nep 60 out_unknown.nep 60 P PATH 78 Perform Name Registry Discovery function 102 pervasive devices 6 planner 53 plug-in-and-operate 3 policy region 37, 42 43, 76 policy region objects 76 prerequisite variables 66 prerequisites 82 pristine installations 22 product components 77 profile managers 55, 76 ProfileManager 46 proxy endpoint 58, 67 Q queries 15 queues 7 R RDBMS 6, 111 RDBMS client 53 RDBMS host 52 RDBMS server 53 RDBMS client 53 RDBMS host 53 RDBMS interface module 6 Redbooks Web site 168 Contact us xiii reliability 3 remote control profiles 82 repeater hierarchy 6 repeater site 6 resource management 142 RIM 53 RIM access 3 RIM host 52 router 27 S scenarios 11, 90 scheduler daemon 7 script variables 55, 66 scripts 11 SCS data 6 security 22 seed file 54, 59 select_gateway_policy 58 Service objects 29 shell scripting 138 shell scripts 25 Index 171

188 slave Tivoli Management Region servers 52 smartsetutil 30 SNMP 10 SNMP agent 29 SNMP agent log 59, 68 SNMP agents 30 SNMP enabled 15 Software Distribution 4 5, 77, 81 software distribution packages 75 software package profile 82 software packaging 22 software package profile 81 software profile manager 48 source 54 source host 52 SQL scripts 53 status collector 7 switch 27 systems management solution 138 systems overview 2 T task library 33, 38, 76 task.sh 67 tasks 38, 55, 76 Tivoli desktop 23, 54 Tivoli Discovery 102 configuring 101 displaying 102 Tivoli endpoint code 30 Tivoli endpoint service 16 Tivoli environment 51 Tivoli environment variables 58 Tivoli Integration Pack for NetView 23, changes 86 Tivoli Inventory database 123 Tivoli management agent 33, 59 Tivoli management agent installation activity 31 Tivoli Management Framework 77, 86, 138 infrastructure 81 Tivoli Management Region server 52 Tivoli Management Region server components 52 Tivoli Name Registry 101 Tivoli NetView Mid-Level Manager 10 Tivoli Network Diagnostics 100 Tivoli Discovery 101 Tivoli object dispatcher 80 Tivoli policy regions 55 Tivoli Software Package Editor 74 Tivoli Wake on LAN 95 configuring 105 traceroute 95 troubleshooting 77 troubleshooting Software Distribution 81 troubleshooting Tivoli Management Framework U UNIX managed node 54 UNIX scenario 57 UNIX setup 55 UNIX shell script 17 user_program 82 W Wake on LAN server 105 wcrtpr 48 wcrtprf 48 wdinstsp 48 Web Gateway component 6 Web Health Console 138 Web Interface 5 wep list 78 wep set_label 76 Windows Windows 2000 gateway 56 Windows NT 29 Windows setup 55 Windows XP 29 winstsp 23 wping 82 wrnetstat 95, 99 wrping 98 wrtraceroute 95 wsetpm 48 wsyncsp 83 wwakeup Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

189 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery

190

191

192 Back cover Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery Solution to automatically install endpoint code on new workstations Implement NetView discovery-initiated scanning and distribution Learn NetView Integration Module for Configuration Manager This IBM Redbook describes a solution to provide readers with the ability to automatically install endpoint code and perform inventory scans and required software distributions on new workstations that have been discovered by IBM Tivoli NetView, reducing the time and effort it takes to manually gather and maintain current information in a distributed environment. Using IBM Tivoli Configuration Manager Version 4.2 and NetView Version 7.1.3, this solution will benefit the reader by providing reliability, potential cost reduction, and rapid time-to-value incentives, which free up administrators and allow them to focus on actual IT needs. We provide an overview of the high-level design and architecture, including the different customer environments where this solution can be applied, followed by implementation, scenarios, and extending the solution. This IBM Redbook also covers the IBM Tivoli NetView Integration Module for Configuration Manager (formerly called Tivoli Integration Pack for NetView) implementation and scenarios. This publication will assist customer and business partners support staff and managers, and IBM systems engineers who are involved in Tivoli sales or implementation services. 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 SG ISBN