Professional Documents
Culture Documents
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Helps you become ITCM 4.2.2 certified
Explains the certification path and prerequisites Tips and best practices
ibm.com/redbooks
International Technical Support Organization Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2 March 2005
SG24-6691-00
Note: Before using this information and the product it supports, read the information in Notices on page xvii.
First Edition (March 2005) IBM Tivoli Configuration Manager Version 4.2.2, IBM Tivoli Management Framework Version 4.1.1
Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Chapter 1. Certification overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 IBM Professional Certification Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Benefits of certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Tivoli Software Professional Certification . . . . . . . . . . . . . . . . . . . . . . 4 1.2 IBM Tivoli Configuration Manager V4.2.2 Implementation Certification . . . 7 1.2.1 Test 870 objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.2 Discount when taking the Test 870 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Recommended resources for study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.1 Courses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.2 Publication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 2. Tivoli Management Framework basics . . . . . . . . . . . . . . . . . . . 15 2.1 Components of the basic Tivoli architecture . . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Tivoli user interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.1 Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.2 Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3 Navigating the Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3 Tivoli resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4 Authorization roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.1 Scope of authorization roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5 Tivoli profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.5.1 Profile managers and profile distribution . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Multiplexed distribution services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.6.1 MDist and MDist 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.6.2 MDist 2 functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.6.3 MDist2 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6.4 wmdist command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
iii
2.6.5 Using the Distribution Status console . . . . . . . . . . . . . . . . . . . . . . . . 36 2.7 Connecting multiple TMR regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7.1 Benefits of connecting TMRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.7.2 Connection types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.7.3 Name registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.7.4 Case study: Hub-spoke architecture . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.8 Endpoint login sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8.1 Initial login without a select_gateway_policy script . . . . . . . . . . . . . . 49 2.8.2 Initial login with a select_gateway_policy script . . . . . . . . . . . . . . . . 50 2.8.3 Normal login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.8.4 Isolated login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.8.5 Orphan login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.8.6 Implementing policy scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.9 Firewall Security Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.9.1 Tivoli environment with a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.9.2 Tivoli environment with demilitarized zones . . . . . . . . . . . . . . . . . . . 57 2.9.3 Sending events across firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.10 Installing Firewall Security Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.10.1 Installing on UNIX operating systems . . . . . . . . . . . . . . . . . . . . . . . 59 2.10.2 Installing on Windows operating systems . . . . . . . . . . . . . . . . . . . . 60 Chapter 3. Tivoli Configuration Manager fundamentals and installation 63 3.1 IBM Tivoli Configuration Manager fundamentals . . . . . . . . . . . . . . . . . . . 65 3.1.1 Tivoli Configuration Manager components and services . . . . . . . . . 65 3.2 Creating a deployment plan for Tivoli Configuration Manager . . . . . . . . . 74 3.3 How to deploy Tivoli Configuration Manager components . . . . . . . . . . . . 75 3.3.1 Distributed Configuration Manager components . . . . . . . . . . . . . . . . 75 3.3.2 TMR server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.3.3 Components for managed nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.3.4 Components for gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.3.5 Components for endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.4 Required roles for installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.5 RDBMS considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.6 RIM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.7 General pre-install checks, hints, and tips. . . . . . . . . . . . . . . . . . . . . . . . . 83 3.7.1 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.7.2 Windows Systems on Intel 486 or Pentium systems . . . . . . . . . . 84 3.8 Installation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.9 Overview of Integrated Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.10 Server Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.10.1 Typical Server Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.10.2 Custom Server Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.10.3 Starting the installation programs . . . . . . . . . . . . . . . . . . . . . . . . . . 88
iv
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
3.11 Desktop Install. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.11.1 Starting the installation program . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.12 Web Gateway Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.12.1 Web Gateway prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.12.2 Starting the installation program . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.12.3 Multiple endpoints installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.13 Uninstallation of IBM Tivoli Configuration Manager . . . . . . . . . . . . . . . . 92 Chapter 4. Inventory and Software Distribution components. . . . . . . . . . 93 4.1 Inventory component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.1.1 What is gathered by Tivoli Inventory . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.1.2 Inventory architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.1.3 Collection Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.1.4 Collection files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.1.5 Inventory Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.1.6 Collection manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.1.7 Data Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.1.8 Status Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.1.9 Callback object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.1.10 Managing data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.1.11 Clearing the Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.1.12 Inventory collection scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.1.13 Custom scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 4.1.14 Isolated scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 4.1.15 Querying inventory data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 4.2 Software Distribution component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 4.2.1 Components of Tivoli Software Distribution . . . . . . . . . . . . . . . . . . 131 4.2.2 Software distribution process overview . . . . . . . . . . . . . . . . . . . . . . 134 4.3 Data Moving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 4.3.1 Using the Data Moving Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 4.4 Enterprise Data Warehouse integration . . . . . . . . . . . . . . . . . . . . . . . . . 153 Chapter 5. Deployment Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 5.1 Activity Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.1.1 Activity Planner components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.1.2 Roles required for the Activity Planner . . . . . . . . . . . . . . . . . . . . . . 157 5.1.3 Types of activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.1.4 Activity Plan Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.1.5 Activity Plan Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 5.1.6 Activity Planner commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.2 Change Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 5.2.1 Change Manager components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 5.2.2 Sample Change Manager scenario. . . . . . . . . . . . . . . . . . . . . . . . . 173
Contents
5.3 Enterprise Directory integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 5.3.1 Exchanging data with a directory server . . . . . . . . . . . . . . . . . . . . . 177 5.3.2 Manipulating DirectoryContext objects . . . . . . . . . . . . . . . . . . . . . . 177 5.3.3 Directory query libraries and query directories . . . . . . . . . . . . . . . . 179 5.4 Resource Manager and pervasive devices . . . . . . . . . . . . . . . . . . . . . . . 183 5.4.1 Choosing where to install the Resource Manager components . . . 185 5.4.2 Web Gateway installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 5.4.3 Web objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 5.4.4 Registering the resource types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 5.4.5 Associating endpoints with the resource gateway . . . . . . . . . . . . . 186 5.4.6 Enrolling pervasive devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 5.4.7 Installing and configuring devices for resource manager . . . . . . . . 187 5.4.8 Installing the device agent for Windows CE devices. . . . . . . . . . . . 187 5.4.9 The user ID of palm devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.4.10 Inventory scans on pervasive devices . . . . . . . . . . . . . . . . . . . . . 188 5.5 Pristine Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.5.1 Pristine Manager architecture and new components . . . . . . . . . . . 189 5.5.2 Supported platforms for pristine installation . . . . . . . . . . . . . . . . . . 190 5.5.3 Key terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 5.5.4 Pristine Manager concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.5.5 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.5.6 Installing pristine machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 5.5.7 Customizing Pristine Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 5.5.8 Adding an Operating System Element to a reference model . . . . . 204 5.5.9 Pristine Manager commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 5.5.10 IBM Tivoli Enterprise Console notification. . . . . . . . . . . . . . . . . . . 205 Chapter 6. Multicast concepts and implementation . . . . . . . . . . . . . . . . 207 6.1 Reliable multicast protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 6.2 Hyper Delivery (RMTP) flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 6.3 Distributed depot service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 6.3.1 Configuring repeaters for multicast . . . . . . . . . . . . . . . . . . . . . . . . . 215 6.4 Endpoint multicast receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 6.4.1 Configuring endpoint to receive multicast . . . . . . . . . . . . . . . . . . . . 220 6.5 Multicast scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 6.5.1 Preloading MDist2 depots with multicast . . . . . . . . . . . . . . . . . . . . 221 6.5.2 Multicast from gateways to Tivoli Management Agents . . . . . . . . . 225 6.6 Multicast limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 6.7 Troubleshooting multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.7.1 Repeater multicast log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.7.2 Endpoint receiver log and structure . . . . . . . . . . . . . . . . . . . . . . . . 233 6.7.3 Best practices and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
vi
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 7. Troubleshooting IBM Tivoli Configuration Manager . . . . . . . 235 7.1 Generic problem determination outline . . . . . . . . . . . . . . . . . . . . . . . . . . 237 7.2 Troubleshooting Framework 4.1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 7.3 Autotrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 7.4 Troubleshooting Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 240 7.4.1 General troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 7.4.2 Check the log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 7.4.3 Check the Distribution Status Console . . . . . . . . . . . . . . . . . . . . . . 242 7.4.4 Make sure that Tivoli Framework is functional . . . . . . . . . . . . . . . . 243 7.4.5 Check for MDist2 problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 7.4.6 Troubleshooting the software package . . . . . . . . . . . . . . . . . . . . . . 245 7.4.7 Software Distribution traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 7.4.8 Troubleshooting Data Moving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 7.4.9 Troubleshooting Mobile Computing . . . . . . . . . . . . . . . . . . . . . . . . 250 7.4.10 Troubleshooting pristine installations . . . . . . . . . . . . . . . . . . . . . . 251 7.4.11 Troubleshooting discovering and synchronization . . . . . . . . . . . . 252 7.4.12 Change Management Status summary. . . . . . . . . . . . . . . . . . . . . 252 7.5 Troubleshooting Activity Planner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 7.5.1 Activity Planner processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 7.5.2 Activity Planner configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . 254 7.5.3 Activity Planner logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 7.5.4 Activity Planner trace files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 7.6 Troubleshooting Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 7.6.1 Change Manager configuration file . . . . . . . . . . . . . . . . . . . . . . . . . 258 7.6.2 Change Manager logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 7.6.3 Change Manager trace files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 7.7 Troubleshooting Web Gateway and Device Management . . . . . . . . . . . 261 7.7.1 Tracing the Web Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 7.8 Troubleshooting Web User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 7.8.1 Common Web User Interface problems . . . . . . . . . . . . . . . . . . . . . 262 7.8.2 Tracing the Web User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 7.9 Troubleshooting Enterprise Directory Integration . . . . . . . . . . . . . . . . . . 266 7.10 Troubleshooting Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 7.10.1 Enabling logging and tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Appendix A. Lab exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 LAB 1 Using Integrated Install method to install a Tivoli Server. . . . . . . . . . . 275 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Install your Tivoli Server with all ITCM modules. . . . . . . . . . . . . . . . . . . . . . . 276
Contents
vii
Exercise review/wrap-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 LAB 2. Using Integrated Install method to install a Tivoli server . . . . . . . . . . 292 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Exercise review/wrap-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 LAB 3. Create an Inventory profile and run a hardware scan . . . . . . . . . . . . 296 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Create a hardware profile with SMBIOS capabilities . . . . . . . . . . . . . . . . 296 7.10.2 Distribute the profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 LAB 4. Create an Inventory profile and run and cancel the software scan . . 302 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Create an Inventory profile for software scan . . . . . . . . . . . . . . . . . . . . . . 302 Distribute the profile and cancel the distribution . . . . . . . . . . . . . . . . . . . . 303 LAB 5. Create a Custom Query with where clauses . . . . . . . . . . . . . . . . . . . 305 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Create a query library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Create a query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 LAB 6. Create and install software packages for Windows . . . . . . . . . . . . . . 307 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Install the Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Create a simple package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Test the software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Import the software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Install the software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Verify the distribution was successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Install software package in transactional mode and commit installation . . 313 Undo an installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Repair a damaged distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
viii
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Add links, registry keys, and text file objects. . . . . . . . . . . . . . . . . . . . . . . 317 LAB 7. Creating a software package using AutoPack . . . . . . . . . . . . . . . . . . 321 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Creating an AutoPack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 LAB 8. Verifying the status of a software package . . . . . . . . . . . . . . . . . . . . . 323 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 LAB 9. Using the Activity Planner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 AP - RIM and RDBMS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Assigning AP roles and verifying the AP Administrator. . . . . . . . . . . . . . . 325 Registering the AP plug-ins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Creating a simple Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Exercise review/wrap-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 LAB 10. Using Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Configuring RIM and RDBMS for Change Manager . . . . . . . . . . . . . . . . . 333 Assigning CM roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Registering the CM plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Creating a Reference Model using an existing Endpoint . . . . . . . . . . . . . 335 Customizing the Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Submitting the Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 LAB 11. Using Data Moving Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Using the Data Moving Service GUI to delete a file . . . . . . . . . . . . . . . . . 343 Recursively sending a directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Contents
ix
LAB 12. Using Multicast to install a software package. . . . . . . . . . . . . . . . . . 345 What this exercise is about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 What you should be able to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Required materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Exercise instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Configuring the repeaters for Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Creating the software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Distributing the software package without using Multicast . . . . . . . . . . . . 347 Distributing the software package using Multicast . . . . . . . . . . . . . . . . . . 347 Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 System requirements for downloading the Web material . . . . . . . . . . . . . 350 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Figures
2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 2-12 2-13 2-14 2-15 2-16 2-17 2-18 2-19 2-20 2-21 2-22 2-23 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 4-1 4-2 4-3 4-4 4-5 4-6 4-7 Tivoli Management Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Tivoli Server, managed node, and TMA communication . . . . . . . . . . . . 18 Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Navigating the Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Different managed resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Grouping by Tivoli product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Grouping by operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Grouping by department . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Inventory Profile icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Inventory profile example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Management by subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Range of a repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 MDist 2 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Distribution Status Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Status Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Time Spent Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Node Table View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Distribution Topology View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Hub-spoke architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Subscription example in a hub-spoke model . . . . . . . . . . . . . . . . . . . . . 47 Endpoint login sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A Tivoli environment with a single firewall . . . . . . . . . . . . . . . . . . . . . . . 57 A Tivoli environment with DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Activity Plan Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Activity Plan Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Web Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Enterprise Directory Query Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Pristine Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Databases created by the installation program . . . . . . . . . . . . . . . . . . . 79 RIM objects created by the installation program . . . . . . . . . . . . . . . . . . 81 A typical Inventory collection scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Collector components and CTOC transfer . . . . . . . . . . . . . . . . . . . . . . 101 Depot directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Callback object data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Scheduling collection using offlinks . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Inventory profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Configuring the Inventory profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
xi
4-8 4-9 4-10 4-11 4-12 4-13 4-14 4-15 4-16 4-17 4-18 4-19 4-20 4-21 4-22 4-23 4-24 4-25 5-1 5-2 5-3 5-4 5-5 5-6 5-7 5-8 5-9 5-10 5-11 5-12 5-13 5-14 5-15 5-16 5-17 5-18 5-19 5-20 5-21 5-22 5-23 5-24 5-25
Profile distribution from the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Creating a query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Four phases of software distribution process . . . . . . . . . . . . . . . . . . . 134 Software package block file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Software package definition file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Software package file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Converting software packages from one format to another . . . . . . . . . 139 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Disconnected commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 States of a software package profile . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Steps of the software distribution delivery . . . . . . . . . . . . . . . . . . . . . . 145 Software distribution operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 States of a software package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Install for software package block (left) and software package (right) . 149 Data Moving Service dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Data Moving dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Activity Planner GUIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Sample activity plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Sort Activity dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Execution window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Activity Plan Monitor - Plan submission . . . . . . . . . . . . . . . . . . . . . . . . 164 Monitoring the execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Launching MDist 2 GUI from the Activity Plan Monitor GUI. . . . . . . . . 166 Reference model structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Selecting subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Differencing mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Creating reference model from target . . . . . . . . . . . . . . . . . . . . . . . . . 174 Exporting a reference model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Creating a directory query library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Creating a directory query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Integration with the Activity Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Integration with the Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . 183 Pervasive Devices Integrated in a Tivoli Environment . . . . . . . . . . . . . 184 Architecture overview of Pristine Manager . . . . . . . . . . . . . . . . . . . . . 190 Flow of pristine installations (1 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Flow of pristine installations (2 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Launching the Pristine Manager GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Define servers on which operating system images are located . . . . . . 196 Set the environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Define the General parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Define the Network parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
xii
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
5-26 5-27 5-28 5-29 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 A-1 A-2 A-3 A-4 A-5 A-6 A-7 A-8 A-9 A-10 A-11 A-12 A-13 A-14 A-15 A-16 A-17 A-18 A-19 A-20 A-21 A-22 A-23 A-24 A-25 A-26 A-27
Enter Tivoli information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Enter Environment information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Group Manager windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Configure the Operating System Element . . . . . . . . . . . . . . . . . . . . . . 204 Multicast and the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Hyper Delivery handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Depot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Endpoint multicast receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Preloading MDist2 depots with multicast . . . . . . . . . . . . . . . . . . . . . . . 221 Loading depot using multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Configuring depot load for multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Gateway multicast to endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Gateway to endpoint multicast: Activity Plan Editor . . . . . . . . . . . . . . . 226 Gateway-to-endpoint multicast: Send properties . . . . . . . . . . . . . . . . . 228 Gateway-to-endpoint multicast: Select targets . . . . . . . . . . . . . . . . . . 229 Gateway-to-endpoint multicast: Activity Plan Monitor submission . . . . 230 Installation welcome screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Destination Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Type of installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Selecting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Specify the repository configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 RDBMS and RIM information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Specify user ID and password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Review the settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Select how to manage product images . . . . . . . . . . . . . . . . . . . . . . . . 285 Components to install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 After Tivoli Management Framework installation . . . . . . . . . . . . . . . . . 287 Installation continues after reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Received error for registering APM plug-ins . . . . . . . . . . . . . . . . . . . . 289 Review the components installed successfully . . . . . . . . . . . . . . . . . . 290 Installing the Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Review the installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Port settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Policy region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Profile Manager creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Hardware Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Inventory query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Edit Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Contents of Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Scan Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 General Package properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Software Package Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Distribution Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Figures
xiii
A-28 A-29 A-30 A-31 A-32 A-33 A-34 A-35 A-36 A-37 A-38 A-39 A-40 A-41 A-42 A-43 A-44 A-45 A-46 A-47 A-48
Edit Query screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Run Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Query results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Directory Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Windows Shell Folder Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Adding Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 AP Propeties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Activitiy Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 Inventory Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Selecting software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Adding Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Activity Plan Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Activity Plan Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Reference Model Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 List of subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Software Distribution element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Adding elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Adding Inventory Scan element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Selecting Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Activity Plan Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
xiv
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Tables
3-1 4-1 7-1 7-2 7-3 7-4 7-5 7-6 7-7 Required roles for installing Tivoli Configuration Manager . . . . . . . . . . 78 CTOC information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Change Management Status summary . . . . . . . . . . . . . . . . . . . . . . . . 252 Location of apm.ini, APM configuration file . . . . . . . . . . . . . . . . . . . . . 254 Location of APM logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Location of CCM configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Location of CM logfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Settings for trace_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Log file information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
xv
xvi
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
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 10504-1785 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.
xvii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX DB2 Informix IBM ibm.com NetView OS/2 OS/400 PartnerWorld Redbooks (logo) Redbooks S/390 SecureWay Tivoli Enterprise Console Tivoli Enterprise Tivoli Management Environment Tivoli TME Wake on LAN WebSphere
The following terms are trademarks of other companies: 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. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.
xviii
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Preface
This IBM Redbook is a study guide for IBM Tivoli Configuration Manager Version 4.2.2 and is aimed at the people who want to get IBM Certifications in this specific product. The IBM Tivoli Configuration Manager Certification, offered through the Professional Certification Program from IBM, is designed to validate the skills required of technical professionals who work in the implementation of the IBM Tivoli Configuration Manager Version 4.2.2 product. This Redbook provides a combination of theory and practical experience needed for a general understanding of the subject matter. It also provides sample questions that will help in the evaluation of personal progress and provide familiarity with the types of questions that will be encountered in the exam. This publication does not replace practical experience, nor is it designed to be a stand-alone guide for any subject. Instead, it is an effective tool that, when combined with education activities and experience, can be a very useful preparation guide for the exam.
xix
Thanks to the following people for their contributions to this project: Julie Czubik International Technical Support Organization, Poughkeepsie Center Ben Briggs, Susan Farago, Stefan Muller, Elizabeth Purzer IBM USA Johan Raeymaeckers JorSy Systems Management
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
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 905
xx
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Preface
xxi
xxii
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 1.
Certification overview
This chapter provides an overview of the skill requirements needed to obtain an IBM Advanced Technical Expert certification. The following chapters are designed to provide a comprehensive review of specific topics that are essential for obtaining the certification: IBM Professional Certification Program IBM Tivoli Configuration Manager 4.2.2 Certification Recommended study resources
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
designed for flexibility by allowing you to select your role; prepare for and take tests at your own pace; and, in some cases, select from a choice of elective tests best suited to your abilities and needs. Some roles also offer a shortcut by giving credit for a certification obtained in other industry certification programs. You may be a network administrator, systems integrator, network integrator, solution architect, solution developer, value-added reseller, technical coordinator, sales representative, or educational trainer. Regardless of your role, you can start charting your course through the Professional Certification Program from IBM today.
For employers:
For Business Partners and consultants: Provides independent validation of technical skills Creates competitive advantage and business opportunities Enhances prestige of the team Contributes to IBM requirements for various IBM Business Partner programs Specific benefits may vary by country (region) and role. In general, after you become certified, you should receive the following benefits: Industry recognition Certification may accelerate your career potential by validating your professional competency and increasing your ability to provide solid, capable technical support. Program credentials As a certified professional, you receive via e-mail your certificate of completion and the certification mark associated with your role for use in advertisements and business literature. You may also request a hardcopy certificate, which includes a wallet-size certificate. The Professional Certification Program from IBM acknowledges the individual as a technical professional. The certification mark is for the exclusive use of the certified individual. Ongoing technical vitality IBM Certified professionals are included in mailings from the Professional Certification Program from IBM.
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Certification checklist
Here is the Certification checklist: 1. Select the certification you would like to pursue. 2. Determine which test(s) is required by reading the certification role description. 3. Prepare for the test, using the following resources provided: Test objectives Recommended educational resources Sample/assessment test
Other reference materials Opportunities for experience Note: These resources are available from each certification description page, as well as from the Test information page. 4. Register to take a test by contacting one of our worldwide testing vendors: Thomson Prometric Pearson VUE (Virtual University Enterprises) Note: When providing your name and address to the testing vendor, be sure to specify your name exactly as you would like it to appear on your certificate. 5. Take the test. Be sure to keep the Examination Score Report provided upon test completion as your record of taking the test. Note: After a test has been taken, your test results and demographic data (including name, address, e-mail, phone number, etc.) are sent from the testing vendor to IBM for processing (please allow 23 days for transmittal and processing). Once all the tests required for a certification are passed and received by IBM, your certificate will be issued. 6. Repeat steps three through five until all required tests are successfully completed for the desired certification role. If additional requirements are needed (such as an "other vendor" certification or exam), please follow the instructions on the certification description page to submit these requirements to IBM. 7. Once you have completed your certification requirements, you will be sent an e-mail asking you to accept the terms of the IBM Certification Agreement before receiving the certificate. 8. Upon acceptance of the terms of the IBM Certification Agreement, an e-mail will be sent containing the following electronic deliverable: A Certification Certificate in .pdf format, which can be printed in either color or black and white A set of graphic files of the IBM Professional Certification mark associated with the certification achieved Guidelines for the use of the IBM Professional Certification mark 9. To avoid unnecessary delay in receiving your certificate, please ensure that we have your current e-mail on file, by keeping your profile up to date. If you
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
do not have an e-mail address on file, your certificate will be sent via postal mail. Once you receive a certificate by e-mail, you may also contact IBM at certify@us.ibm.com to request that a hardcopy certificate be sent by postal mail. Note: IBM reserves the right to change or delete any portion of the program, including the terms and conditions of the IBM Certification Agreement, at any time without notice. Some certification roles offered through the IBM Professional Certification Program require recertification.
Basic understanding of third-party software installers (MSI, InstallShield, and PDF) Core requirement In order to be certified you must select the following test: Test 870 - Tivoli Configuration Manager V4.2.2 Test 870 objectives Test 876 sample test Test 870 recommended educational resources Approximate number of questions: 80 Duration in minutes: 120 Format: Multiple choice Required Passing Score: 65 percent pass score or 52 correct out of 80 items correct answers
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
1.3.1 Courses
Course names and/or course numbers vary depending on the education delivery arm used in each geography. Please refer to the Tivoli software education Web site to find the appropriate course and education delivery vendor for each geography. General training information can also be found at IBM IT Training at:
http://ibm.com/training
Course duration: Five days. Course number: (TV170 - IBM Technical Education Services) | (TV107 Education Centers for IBM Software). Course numbers vary depending on the education delivery arm used in each geography. Please refer to the Web site
below to find the appropriate course number according to the education delivery vendor chosen.
Geo education page: Worldwide schedules available at Tivoli software education. IBM PartnerWorld "You Pass We Pay": This course is approved for IBM
PartnerWorld You-Pass, We-Pay. Note: At the time of writing this book, IBM Tivoli Configuration Manager 4.2.2 courses were not available yet on http://ibm.com/training. Check out this link for the most updated information about offered Tivoli workshops.
Course duration: Thirty-two hours, self-paced. Course number: (TIV69 - IBM Technical Education Services) | (TV113 Education Centers for IBM Software). Course numbers vary depending on the education delivery arm used in each geography. Please refer to the Web site below to find the appropriate course number according to the education delivery vendor chosen.
Geo education page: Worldwide schedules available at Tivoli software education. IBM PartnerWorld "You Pass We Pay": This course is not approved for IBM
PartnerWorld You-Pass, We-Pay.
10
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
1.3.2 Publication
Before taking test 870 IBM Tivoli Configuration Manager V4.2.2 Implementation, the recommended publications to review are IBM Tivoli Configuration Manager manuals and redbooks. You may want to refer to the following manuals: IBM Tivoli Configuration Manager: Introducing IBM Tivoli Configuration Manager, GC23-4703 Provides an overview of IBM Tivoli Configuration Manager and its components, and uses scenarios to highlight various processes. IBM Tivoli Configuration Manager: Planning and Installation Guide, GC23-4702 Explains how to install, upgrade, and uninstall IBM Tivoli Configuration Manager and its components in a Tivoli environment. IBM Tivoli Configuration Manager: Users Guide for Software Distribution, SC23-4711 Explains the concepts and procedures necessary for you to effectively use the Software Distribution component to distribute software over local area networks (LANs) and wide area networks (WANs). IBM Tivoli Configuration Manager: Reference Manual for Software Distribution, SC23-4712 Explains advanced features and concepts needed to use and tailor the Software Distribution component. IBM Tivoli Configuration Manager: Users Guide for Inventory, SC23-4713 Describes the Inventory component and the management tasks that you can perform. IBM Tivoli Configuration Manager: Database Schema Reference, SC23-4783 Describes the IBM Tivoli Configuration Manager database tables. IBM Tivoli Configuration Manager: Messages and Codes, SC23-4706 Lists all of the messages produced by IBM Tivoli Configuration Manager. IBM Tivoli Configuration Manager: Users Guide for Deployment Services, SC23-4710 Provides information about the different services provided as part of Tivoli Configuration Manager. You may also follow the link below in order to reach the online publications of IBM Tivoli Configuration Manager 4.2.2.
11
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp?toc=/com .ibm.tivoli.itcm.doc/toc.xml
This book will assist Software Distribution specialists with installing, customizing, using, and troubleshooting IBM Tivoli Configuration Manager. Automated Distribution and Self-Healing with IBM Tivoli Configuration Manager V 4.2, SG24-6620 This IBM Redbook covers a solution to implement an automated software distribution and Self-Healing mechanism on top of IBM Tivoli Configuration Manager Version 4.2. The solution described in this book (referred as the Solution throughout he book) guarantees the availability of designated software packages on workstations. The Solution is also backwards compatible with IBM Tivoli Software Distribution Version 4.1 and Inventory Version 4.0. The Solution will extend the benefits of using IBM Tivoli Configuration Manager Version by reducing costs, increasing reliability, and providing fast delivery. The scripts that make up the Solution are shipped with the book (on an AS-IS basis), so you can customize the Solution according to your needs. We believe the Solution described in this book will be very useful for customers who are planning to implement a software distribution infrastructure or are already using IBM Tivoli Configuration Manager Version and want to automate the software enforcement/Self-Healing process. Migration to IBM Tivoli Configuration Manager Version 4.2, SG24-6616
12
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
This redbook explains both the business reasons and the technical implementation details for migrating from Software Distribution and Inventory 3.6.X to IBM Tivoli Configuration Manager Version 4.2. The topics include: Business reasons for migration Functional and architectural differences between IBM Tivoli Configuration Manager and 3.6.X versions of Software Distribution and Inventory Planning and methodology of migration Framework migration Migration scenarios Package migration This book will help you in all aspects of migration from Software Distribution and Inventory 3.6.X to IBM Tivoli Configuration Manager Version 4.2. Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery, SG24-6626 This book 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 book 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.
13
14
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 2.
15
Tivoli Management Region (TMR) is an entity that contains the Tivoli server and its clients. A Tivoli Management Region contains three tiers of resources: The Tivoli server, managed nodes and gateways, and endpoints, as shown in Figure 2-1.
Tivoli Management Region (TMR) Server includes the libraries, binaries, data
files, and the graphical user interface (GUI) (the Tivoli desktop) needed to install and manage your Tivoli environment. The Tivoli server performs all
16
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
authentication and verification necessary to ensure the security of Tivoli data. The following components comprise a Tivoli server: An object database, which maintains all object data for the entire Tivoli region. An object dispatcher, which coordinates all communication with managed nodes and gateways. The object dispatcher process is the oserv, which is controlled by the oserv command. By default, oserv communicates in the TMR on port 94. This port is configurable. An endpoint manager, which is responsible for managing all of the endpoints in the Tivoli region. Note: The TMR server should be dedicated to the task of managing the TMR. The TMR server must be up and available in order for the rest of the TMR to function. For more information on increasing the fault tolerance of your TMR, see the IBM Redbook, High Availability Scenarios with IBM Tivoli Workload Scheduler and IBM Tivoli Framework, SG24-6632. The machine that serves as the TMR server can also serve as a client (target of management operations) in the TMR.
Managed Node runs the same software that runs on a Tivoli server. Managed nodes maintain their own object databases that can be accessed by the Tivoli server. When managed nodes communicate directly with other managed nodes, they perform the same communication or security operations that are performed by the Tivoli server.
The difference between a Tivoli server and a managed node is that the Tivoli server object database is global to the entire region, including all managed nodes. In contrast, the managed node database is local to the particular managed node. To manage a computer system that hosts the managed node, install an endpoint on that managed node.
Gateway controls communication with and operations on endpoints. Each gateway can support thousands of endpoints. A gateway can launch methods on an endpoint or run methods on behalf of the endpoint.
A gateway is generally created on an existing managed node. This managed node provides access to the endpoint methods and provides the communication with the Tivoli server that the endpoints occasionally require.
17
Typically, an endpoint is installed on a computer system that is not used for daily management operations. Endpoints run a very small amount of software and do not maintain an object database. The majority of systems in a Tivoli environment should be endpoints. The Tivoli desktop is not installed with the endpoint software. If you choose to run a desktop on an endpoint, you must install Tivoli Desktop for Windows or telnet to a UNIX-managed node. The TMA is implemented differently for different platforms. It is a process on UNIX systems and a service on Windows NT systems. By default, a TMA will contact its gateway on port 9494, the port on which the gateway is listening for TMAs. This port is configurable. By default, a TMA listens for TMR communications on port 9495. Figure 2-2 shows Tivoli server and client components communication.
Sizing considerations for gateways: Sizing the endpoint gateways is an important consideration when designing your Tivoli topology. The following are the main factors to consider when sizing endpoint gateways: Number of endpoints Number of upcalls and downcalls Number of endpoint platform types that must be supported
18
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The Tivoli Desktop provides a graphical user interface (GUI) for administrators to graphically view and control the Tivoli Management Environment with a logical, consistent layout across all Tivoli products. The Tivoli Desktop is automatically installed on every UNIX-managed node. It is invoked on UNIX systems via the tivoli command. You must run the tivoli command from an X-Window session after sourcing the environment variables.
19
Tivoli Desktop for Windows is a separate program that must be installed manually before an administrator can access the Tivoli Desktop on a Windows NT-managed node. The Tivoli Desktop for Windows code is on Framework CD2. It can be installed on any Windows-based system, even if it is not in the TMR. It can be used to access the Tivoli Desktop of a UNIX-managed node as well as an NT-managed node. Note: The Tivoli Desktop for Windows requires you to specify a host, which could be another machine.
20
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
21
To manage a specific type of resource, you must first install a Tivoli application that is designed to manage that resource. Tivoli applications manage resources from a single logical view. Upon installation of Framework on the TMR server, the default Tivoli desktop (Figure 2-3 on page 10) displays five icons, each of which represents a type of Tivoli resource: The administrators, notices, a default policy region, the endpoint manager, and the scheduler.
Administrator
A Tivoli administrator is a system administrator who has been authorized to perform systems management tasks and manage policy regions. The Administrator Collection is a container for all the Tivoli administrators. Tivoli software products use administrators to delegate the use of the system root account without giving those administrators the system password or complete control. Most system administrators have a Tivoli administrator that maps to their system account. However, users on multiple systems can use the same Tivoli administrator. A Tivoli administrator is the person or group of people each with a user account to access a computer system where Tivoli software products are installed.
Notices
Notices are a resource that contains notes posted by Tivoli applications. These notes inform the administrators of management functions performed in the Tivoli environment.
22
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Policy region
A policy region is a container for managed resources that conform to the same set of policies or rules. Upon installation of the TMR server, there will be one default policy region, and initially the managed node on the TMR server will be the only resource contained within it. A policy region can be used to reflect the management and organization of a distributed computing environment. It has two primary objectives: To enforce company rules and policies To enforce a security model or delegation of authority It represents logical relationships tied to an organizational structure such as divisions, departments, geographical locations, types of workstations, or business functions. Policy regions can be nested to provide hierarchical relationships; if a policy region is contained in another policy region it is called a policy subregion. Policy region hierarchy can be designed in different ways. Figure 2-6 shows grouping by Tivoli products, Figure 2-7 on page 24 shows grouping by Tivoli operating systems, and Figure 2-8 on page 24 shows grouping by departments.
23
Endpoint manager
The endpoint manager runs on the TMR server and maintains TMA and gateway information. The endpoint manager maintains an endpoint list that keeps track of every TMA in a TMR and tracks the gateway associated with each TMA.
24
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
From the endpoint manager, you can view the gateways and their associated endpoints. You can also create new gateways.
Scheduler
Scheduler is a resource that allows access to the scheduling queue to manipulate scheduled jobs. The scheduler executes previously defined jobs at predefined times, such as scheduling jobs to occur at specific times or within a specified time frame, to repeat a specified number of times, at specified intervals, or indefinitely.
25
backup Allows an administrator to create backups of Tivoli object databases. An administrator must have the backup role in the region that contains the object databases for the Tivoli server and managed nodes to be backed up. restore Allows an administrator to restore Tivoli object databases from backup. The administrator must have the restore role in the region that contains the object databases for the Tivoli server and managed nodes to be restored. install-product Allows an administrator to install new applications and products in the local Tivoli region. install-client Allows an administrator to install managed nodes within policy regions that allow the managed node resource type. policy Allows an administrator with both the policy and senior roles to create policy regions. In addition, the administrator can add resource types to policy regions and set up the policies that govern the policy region. Dist_control Allows an administrator to control multiplexed distribution 2 (MDist 2) distributions. Note: Depending on the Tivoli products installed, other authorization roles might be available.
26
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Roles should be assigned based on the management operations specific to an administrator. You should carefully plan how you are going to delegate system management tasks. Tivoli Management Framework provides control and flexibility in assigning management authority to various personnel. Carefully consider and review the areas of responsibility for each Tivoli administrator when assigning roles for various resources and in various Tivoli regions. For example, Juan is to manage Documentation policy region. He should be assigned the senior, admin, and user roles for this policy region. If Juan has administrative needs for other policy regions or resources outside of his policy region, these can be granted later. Authorization roles can be granted at the resource level or region level.
27
makes it easier to access, manage, and duplicate resources. Profiles and profile managers enable you to do this. A profile is a container for a Tivoli application. Each application has its own type of profile. The profile template is configured by a system administrator to manage resources as desired. As an example, Figure 2-9 shows the Inventory Profile icon.
Profiles are sent to target systems.You can apply a profile to a set of managed resources in the TMR. This causes the management task to be sent to the target resource, which is usually a computer system such as a managed node or TMA. The Framework provides profile managers to associate profiles with their target systems. One profile can define configurations for multiple platforms. A profile can contain only information related to the profile type (for instance, IBM Tivoli Monitoring), but within each profile type, configuration information for multiple platform types can be stored. For example, the User Administration profile can store a particular user's account information for their UNIX and Windows accounts both in the same profile record. Figure 2-10 on page 29 is an example of a profile for the Inventory component of the IBM Configuration Manager product. This allows you to scan machines for hardware and software assets.
28
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
29
As a result of profile distribution, profile data is copied to target systems and sent to the appropriate application that will understand the configuration information and apply it accordingly. When a TMA receives a profile and does not have the corresponding application loaded in its method cache, the application code will be downloaded from the TMA's Management Gateway.
30
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
ability to subscribe resources across TMR boundaries means that a profile can be distributed easily to hundreds or thousands of machines.
31
The TMR server is a repeater by default. Understanding MDist behavior is important because, under some circumstances, the default MDist behavior can strain the resources of the TMR server or your network bandwidth.
Single TMR environments: In a single TMR, MDist distributes for the TMR server to all target machines in parallel, up to a default maximum of 100 machines at a time. The number of machines can be configured differently. Multiple TMR environments: When distributing data to machines in more than
one TMR, MDist distributes data in parallel to local machines and once to other TMR server(s). A TMR server in another region is called a wan repeater. The other TMR servers' MDist repeaters then redistribute the data to the target machines. TMR servers and managed nodes configured as management gateways are automatically designated as repeaters. You may define additional repeater sites. Configuration of repeaters is done by the single command called wrpt. Note: Any system in the TMR that does not explicitly belong to the range of a repeater will belong to the range of the default repeater (which defaults to the TMR server).
32
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Mobile computing support: This graphical interface allows users to download and install distributions at their convenience. Disconnected endpoint support: Enables users to download and save distributions in a local storage directory for installation at a later date. Roaming endpoint support: Enables endpoints to receive a distribution when an endpoint migrates to a different gateway during distribution. Installation from CD or file server: Enables administrators to specify a CD or
file server to use rather than a repeater.
Wake on LAN (WOL) support: Enables administrators to send distributions to powered off computers. If WOL is enabled, the machine will wake up to receive the distribution. Multicast support: Enables system administrators to improve performance by using parallel distribution.
33
Repeater site
Repeater depot
Repeater queue
Distribution manager
GUI RIM
34
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
I enables you to view detailed information about the distributions that the repeater is currently processing, and obtains the ID for the distribution.
wmdist k depot_directory...
This lists distribution status. The options are as follows: a returns active distributions only. i dist_id specifies the distribution ID. When no distribution ID is specified, the command returns the status for all distributions. v returns all information about the status. If you do not specify the v option, the command returns only the keyword value information.
wmdist m dist_id [t ep_label] [n node_type] [state...]
35
wmdist q dist_id
This displays the nodes associated with a given distribution in an indented format that indicates the route. Each node displayed is suffixed with its state. You can also determine the distribution path for an active distribution.
wmdist [f] r dist_id | endpoint_id [endpoint_id...]
This resumes a paused distribution specified by dist_id, or resumes one or more paused distributions by target specified by endpoint_id.
wmdist R [rim_object]
This allows the user to change the RIM object used by the distribution manager to store status. The default value is mdist2. Issuing this command without a value prints the current value.
wmdist s repeater_name [C noprompt| nostart| nostop] [keyword=value.]
This configures a repeater (specified by repeater_name) using one or more of the following keywords and values. If a value is not specified, the existing options for the specified repeater are displayed. When no keyword value pairs are listed, the command returns the configurations currently in use.
wmdist T [database_purge_interval]
This sets the interval (in seconds) when completed distributions are deleted by the distribution manager from the RIM database. Setting this interval allows the distribution manager to delete completed or irrelevant distributions from the database after a distribution request is submitted. Although a purge interval is defined, the completed distributions are not deleted unless the defined interval has elapsed and a distribution request was submitted. Issuing this command without a purge interval prints the current setting. Setting the purge interval to -1 disables database purges. The default value is -1. For the complete wmdist command function please refer to the Tivoli Management Framework Reference Guide.
36
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
37
Time Spent Chart The Time Spent Chart view displays a bar chart, which indicates the amount of time spent in each stage of the completed distribution. This view displays the minimum, average, and maximum amount of time (in seconds) a distribution was in a given state.
38
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Node Table The Node Table view works the same way as the Distributions table. However, instead of querying distribution status, it queries the states of repeaters or endpoints associated with a specific distribution.
39
Distribution Topology The Distribution Topology view displays a tree view showing the data structured as nodes and links. It allows you to see the path the profile will follow. Nodes refer to repeaters and endpoints in the currently selected distribution. Links show the relationship between the nodes in the distribution hierarchy. These objects are color-coded so that you can quickly identify the state of a node. The lines that link nodes in the hierarchy are also colored to display relationships between connecting nodes. You can use this view to gain an understanding of the distribution route and to show relationships that help identify items to focus on. For example, you can identify bottlenecks that prevent a distribution from completing and you can also determine the distribution path for active distributions.
40
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
41
performed to make known the types and values of resources in the remote region. After the initial information exchange, the information should be updated on a regular basis. Important: To connect two regions, each region must have a name that is unique among all regions. If you attempt to connect a region that has the same name as another region, the connection fails. Any Tivoli product installed in two connected regions should be installed in compatible versions in each region. Incompatible versions of a product do not cause a connection to fail, but can cause operation problems at a later time. However, you can connect two regions that do not have the same products installed.
Decrease server load: The load on a single TMR server caused by network activity, memory demands, or the number of clients can be lessened by multiple TMRs. Localized system administration: Multiple TMRs enable local control with more independence at different operational sites. Enhance security: An additional TMR can be used to restrict local
administrators access to certain machines within the enterprise. Also, an additional TMR enables differing encryption levels within a Tivoli environment. With the super authorization role and the TMR password (if it exists), a Tivoli administrator can connect or disconnect two or more TMRs.
42
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
while the connection from the central site is used for more global updates across the company, such as a new version of an application. Although one-way connections are feasible, two-way connections are recommended.
43
managed functions are performed within a Tivoli environment. It is dedicated primarily to high-level management functions, such as creating administrator desktops and TEC consoles; creating, configuring, and distributing sentry profiles to spoke servers; and other hub-wide management activities. Spoke TMRs provide the direct control function for all endpoints in the Tivoli environment. Spoke regions can be used to group managed nodes by physical location in the network and to localize functions in order to improve network and system performance. Generally, spoke TMRs are not used as entry points for administrators. Tivoli Administrators can use either the hub TMR or any managed node strategically placed in the design as an entry point into the Tivoli Management Environment. Figure 2-19 illustrates the hub-spoke architecture.
HUB TMR
TEC TMR
The TEC server can be configured either as a managed node contained within the hub TMR server or on a stand-alone TMR at the same management level as the hub TMR server.
44
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
All managed systems (managed nodes, gateways, and endpoints) are spread out into the Tivoli environment beneath spoke TMRs, as determined by function, server load, or physical network location. Managed nodes are still required in this environment. For example, managed nodes can be used to support remote Tivoli Administrators desktops or to serve for profile staging. Endpoint gateways are installed throughout the Tivoli environment to host endpoints. In this TME hierarchy, all endpoint gateways are assigned to spoke TMRs only.
TMR architecture
One of the most important factors for designing the hub-spoke TMR architecture is the scalability limitations of the Tivoli environment: Number of endpoints The number of endpoints managed by a single region has been increased to tens of thousands. It has been shown in production environments that 20,000 endpoints can be managed by a single region. For organizations requiring more than 20,000 endpoints to be managed, multiple regions are required. The limit of 20,000 endpoints represents a threshold beyond which special performance and tuning requirements might be needed. Therefore, use multiple connected regions. Number of managed nodes Generally, a single Tivoli server can support a maximum of 200 managed nodes. However, use endpoints instead of managed nodes in most cases. Endpoints are the preferred mechanism for managing your environment. The introduction of endpoints greatly reduces the number of managed nodes in a single region. A gateway installed on a managed node can perform all communication and operations with thousands of endpoints. Endpoints therefore have no direct communication with a Tivoli server. In addition, the ability to perform maintenance functions such as database checks are greatly inhibited by large numbers of managed nodes. If the network contains more than 200 managed nodes, create multiple regions and connect them.
45
Note: For performance reasons, in a multi-TMR environment it is important to make sure that endpoints get connected to the designated TMR. The best was to ensure that is to configure the endpoints to log in to specific gateways and disable broadcasting.
TMR architecture
It is a good practice to create policy regions based on a Tivoli application (IBM Tivoli Configuration Manager, IBM Tivoli Monitoring, and so on) only on the hub TMR server. The subscriber policy regions then reside on the spoke TMR servers. The subscribed policy regions contain the profile managers used for distributing to endpoints. Organizing your policy regions in this manner enables the hub server to be the central point of operations for each application and associated functions. This also avoids subscribing endpoints across TMR boundaries. If an endpoint is subscribed across TMR boundaries, a new object is created in the object database and the wchkdb command must track the object directly, causing unnecessary transactions across TMR boundaries and server load. Instead, if endpoints stay subscribed to their local TMR, the hub and spoke TMRs only need to exchange resources, causing only an entry in the Tivoli Name Registry (TNR) on the hub TMR. See Figure 2-20 on page 47 for more details.
46
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
.
Hub TMR
DM_Appl.HUB.PR
Spoke TMR
WinNT_DM_Appl.HUB_PR Win98_DM_Appl.HUB_PR Subscribers_Spoke.PR
Subscribers_WinNT_Spoke.PR
Subscribers_Win98_Spoke.PR
Subscribers_WinNT_Spoke_PM
47
compiled by the endpoint manager, defined in the select_gateway_policy script, or configured with lcfd command options. Note: Depending on how your environment supports network address translation (NAT), you might need to define the host names for gateways in the select_gateway_policy script. The gateways defined through select_gateway_policy or the lcfd command can be host names instead of object identifiers (OIDs). To facilitate the login process and endpoint communication, configure login parameters during endpoint creation or with the lcfd command after installation. For more information about the lcfd command and the select_gateway_policy script, refer to Tivoli Management Framework Reference Manual, Version 4.1.1, SC32-0806.
48
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
49
4. If the login is successful, the endpoint receives its identity in the Tivoli region from the intercepting gateway along with the name of its assigned gateway. 5. When logged in, the endpoint performs a normal login to its assigned gateway.
50
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
51
3. If login fails for all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled). 4. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before beginning the login process again with step 1.
52
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
2. If login fails for all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled). 3. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before attempting to contact its assigned gateway again.
53
summarize the orphan login, the following are the general parameters and default time outs: 1. When the endpoint cannot reach its assigned gateway, the endpoint uses a set of gateway addresses configured during installation to contact a gateway to receive the endpoint login request: These gateway addresses are specified by the lcs.login_interfaces option. By default, the endpoint attempts to contact each of the gateways three times, with 5 minutes between each attempt. The attempts are specified by the login_attempts option. The time between each attempt is specified by the login_timeout option. If the endpoint is successful in contacting one of the alternate gateways, endpoint policy scripts run including any orphan endpoint parameters you have specified. 2. If login fails for all the addresses in the lcs.login_interfaces list, the endpoint broadcasts a request to log in (if broadcast is enabled). 3. If no gateways in the lcs.login_interfaces list respond or the broadcast login request fails, the endpoint waits 30 minutes (the login_interval default of the lcfd command) before attempting to contact its assigned gateway again.
54
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
55
checking changes to IP addresses and port numbers. When the gateway detects changes, it notifies the endpoint manager. When the policy script exits with a nonzero value, the endpoint login will not fail. Note: The same login_policy policy script is run on all the gateways in a Tivoli region.
56
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Just as multiple endpoints can connect to a single gateway and multiple gateways to a single Tivoli server, multiple endpoints can connect to a single gateway proxy and multiple gateway proxies can connect to a single endpoint proxy. The endpoint proxy emulates all the endpoints to the gateway that manages them. The communications between these Tivoli components is based on a Tivoli proprietary protocol over TCP/IP.
57
Instead, Firewall Security Toolbox provides relays, which are installed between the firewalls in DMZs. These relays pass on information to each other from one DMZ to another and, finally, to or from the endpoint proxy and gateway proxy. Figure 2-23 shows an example of this configuration.
58
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
59
3. Gateway port [default=9494]: Specify the TCP/IP port number of the gateway on which it will listen for communication from the endpoint proxy as if it were the endpoint. This is normally port 9494. Do not change this value unless the gateway is known to be using a different listening port with the endpoint. 4. Endpoint proxy port: Specify the port number of the endpoint proxy machine from which it listens for connections with the relay or gateway proxy.
60
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
61
62
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 3.
63
Server Install on page 86 Desktop Install on page 89 Web Gateway Install on page 90 Uninstallation of IBM Tivoli Configuration Manager on page 92
64
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Software Distribution
Using the Software Distribution component, you can install, configure, and update software remotely within your network, eliminating the need to update software manually on numerous systems. You can: Distribute client/server applications, applications for desktops, laptops, and pervasive devices across multi-platform networks. Update existing software with newer versions. Synchronize software on distributed systems. The Software Distribution component is discussed in detail in 4.2, Software Distribution component on page 130.
65
Inventory
Using the Inventory component, you can gather and maintain up-to-date inventory information in a distributed environment quickly, accurately, and easily. This helps system administrators and accounting personnel manage complex, distributed enterprises. Administrators and accounting personnel can perform the following tasks: Manage all enterprise systems centrally. Determine the installed software base. Confirm a software distribution. Supplement and replace physical inventory function. Assist in procurement planning. Check software requirements. Control assets. For example, you can combine inventory and software distribution operations to determine if any critical files are missing, then re-establish the proper configuration. After creating and deploying management-ready applications, you can continually maintain the desired state of your systems by synchronizing applications and system configurations on an enterprise scale. The Inventory component is discussed in detail in 4.1, Inventory component on page 94.
Activity Planner
Activity Planner is a deployment service that enables you to: Define a group of activities to be submitted as an activity plan. Submit or schedule the plan for running. Monitor the plan while it runs. Activities are tasks that can be scheduled to be performed on a set of targets at specified times. Operations can include software distribution, inventory operations, and Tivoli tasks. Activities contained in a plan can have dependencies associated with them that define circumstances under which the activity should be run. The running of the operation defined in the activity is performed by the application to which the operation belongs. The group of activities forms the activity plan. Activity Planner is made up of two components, the Activity Plan Editor and the Activity Plan Monitor.
66
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
67
View all submitted activity plans along with their status, start time, and completion time. View the list of activities contained in the plan. View a graphical representation of the plan in the Activity Plan Editor window. For each activity, view the targets (gateways, depots) assigned to it. Perform operations such as pause, cancel, and resume. Restart an activity on an endpoint where the operation was unsuccessful. Delete the status information of a plan from the activity plan database. Launch the Distribution Status Console to monitor and control software distributions submitted using the Activity Planner. Figure 3-2 shows the Activity Plan Monitor.
The Activity Planner component is discussed in detail in 5.1, Activity Planner on page 156.
68
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Change Manager
Change Manager (previously called Change Configuration Manager) is a deployment service that, together with Activity Planner, supports software distribution, inventory, and change management in a large network. Activity Planner is a prerequisite of Change Manager. Change Manager works with the Activity Plan Monitor to manage specified groups of users, workstations, or devices as single subscribers. Subscribers can be users, groups of users, endpoints, a profile manager, the results of a query, or pervasive devices. Change Manager uses reference models, which contain an association of configuration elements and subscribers, to simplify the management of your network environment. Figure 3-3 shows the Change Manager.
The Change Manager component is discussed in detail in 5.2, Change Manager on page 168.
69
Web Gateway
The Web Gateway component supports the Resource Manager deployment service and the Web Interface (Web UI) deployment service. The Resource Manager deployment service extends the traditional three-tier Tivoli environment to a forth tier, thus providing software distribution, inventory, and management of pervasive devices such as the Palm Pilot, Pocket PC, and Nokia Communicator. (See Resource Manager on page 70.) The Web Interface (Web UI) enables software distribution and inventory to be initiated by users. By using the Web Interface, users can access a Web site and install software on their own machine, or generate an inventory scan by themselves. (See Web Interface on page 71). The Web Gateway component is comprised of two elements: Web Gateway Database Web Gateway Server code These elements are installed on an endpoint machine in the Tivoli environment. The Web Gateway utilizes WebSphere technology, and provides improved security by leveraging Access Manager for authentication and the HTTPS protocol for secure communications.
Resource Manager
A Tivoli management region is a three-tier architecture, including servers, gateways, and endpoints, that is created using Tivoli Management Framework. By using the Resource Manager deployment service, you can extend the Tivoli region to a fourth tier, pervasive devices, such as PDAs. Resource Manager is made up of two sub-components: The Resource Manager, which is installed on a Tivoli server; and the Resource Manager Gateway, which is installed on a gateway that connects to an endpoint on which the Web Gateway component has been installed. You can use Resource Manager, together with the Software Distribution, Inventory, and Web Gateway components, to perform the following operations: Add or remove pervasive devices. Provide access to devices for software distribution. Provide access to devices for inventory operations. Customize devices.
70
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Web Interface
The Web Interface deployment service is a browser-based tool that enables remote management operations to be initiated by users on machines that do not have the Tivoli Management Agent installed. The Web Interface is shown in Figure 3-4.
71
information about the users or the workstations defined in the enterprise directory server. The following LDAP products are supported by the Enterprise Directory Query Facility: IBM SecureWay Directory Server Active Directory for Windows 2000 Novell Directory Server for NetWare The Enterprise Directory Query Facility is shown in Figure 3-5.
Active Directory
Figure 3-5 Enterprise Directory Query Facility
LDAP
The Enterprise Directory Query Facility is discussed in detail in 5.3, Enterprise Directory integration on page 176.
72
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Data Moving
Data Moving is a Tivoli Configuration Manager component used to send/retrieve/delete data from endpoint to endpoint or managed node without creating a software package. Data Moving is discussed in detail in 4.3, Data Moving on page 151.
Pristine Manager
Pristine Manager is a component of Tivoli Configuration Manager, available with Version 4.2.1. Pristine Manager enables Tivoli Configuration Manager to manage machines that have no operating systems installed (bare-metal machines). It does not perform the real pristine setup; it leverages third-party products. Figure 3-6 on page 74 shows the relationship between the server, gateway, endpoint, and pristine machines. The sequence of operations is: 1. From the AMP/CCM console, define the server and machine databases and create the operating system elements. 2. Create and synchronize the reference model to create the activity plan. The reference model and activity plan are created with information stored on the RDBMS server. The plan that is generated must be run from the Activity Plan Monitor. The activity plan contains the pristine activity. 3. The Tivoli server distributes the pristine activity to the RIS/ADS server on the endpoint for each Pristine machine. 4. When a Pristine machine boots, the RIS/ADS server installs the operating system and a Tivoli management agent on that machine. 5. When the operating system and the Tivoli management agent have been installed on the Pristine machine, the Pristine machine logs on to the Tivoli gateway to notify the Tivoli server that the Pristine Manager has completed the configuration of the Pristine machine.
73
74
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Which IBM Tivoli Configuration Manager components to install on which computer systems in your distributed network to support your business needs and whether they have additional third-party software requirements. This information is provided in IBM Tivoli Configuration Manager Release Notes, GI11-0926, and Introducing IBM Tivoli Configuration Manager, GC23-4703. For each system where you plan to install components of IBM Tivoli Configuration Manager, you should also provide the following information: Host name Operating system Available memory and available disk space Which components of IBM Tivoli Configuration Manager to install
75
Here are the Configuration Manager components that must be installed on the TMR server before deploying other components in your Tivoli environment. (Of course, if you are not going to use the component in your Tivoli environment, you do not need to install it on your TMR server.) Scalable Collection Service * (patch) Inventory Software Distribution Activity Planner Change Manager Pristine Manager Enterprise Directory Query Facility Resource Manager Web Infrastructure Note: You must install the Scalable Collection Service patch before you install the Inventory component. This patch is not required for the other components.
76
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Is a repeater that will act as a collector Is a gateway that connects to the Web Gateway components Install the Inventory Gateway component on each gateway that will: Distribute Inventory profiles to endpoints. Recognize Inventory methods and download these methods to endpoints. Run methods to perform requested Inventory actions. Install the Software Distribution Gateway on each gateway that will: Recognize Software Distribution methods and download these methods to endpoints. Run methods to perform the requested Software Distribution operation. Install the Pristine Manager Gateway component on each gateway that: Pristine machine will attach to The Remote Installation Service or Automatic Deployment Services endpoints are attached to
77
78
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Component
Activity Planner Change Manager Distribution Status Inventory Pristine Manager Resource Manager
Database planner (or cm_db) ccm_db (or cm_db) mdist2 (or cm_db) Invtiv (or cm_db) pristine (or cm_db) Invtiv (or cm_db)
These databases, known as repositories, are created in the RDBMS by running SQL admin scripts. Tivoli provides sample SQL scripts in the FRESH/SQL/admin directory of the Configuration Manager installation CD. These scripts will create the various databases required by Configuration Manager. The scripts may not fit your production environment as-is; make sure to review these scripts, and edit them to meet your database requirements. The values used in the SQL admin scripts are default values. The values can be changed by editing the SQL admin script files. If you are using the integrated server installation program, you can choose to have the installation program create the configuration repository; in this case, you do not need to explicitly run these SQL scripts. Depending upon the RDBMS product, you may need to do some additional setup outside of these scripts, such as create/catalog the database, or create operating system accounts that the RDBMS will use. This is true whether you run the admin scripts manually, or create the configuration repository using the integrated server installation program. Check the contents of the SQL admin scripts to determine what steps must be done before creating the repository. The following example shows the cm_db2_admin.sql script, which is used if you opt for one database creation (cm_db). Note the PRECONDITION statements. Also note that table spaces are created by the script.
Example 3-1 db2 admin script -- cm_db2_admin.sql --
79
-- PRECONDITION: The default 'cm_db' database is created with the statement -'create database cm_db', then catalogued on the client with the statement -'catalog database cm_db at node <server_node_name>'. -The users invtiv, planner, tivoli and mdstatus are already created -using the operating system user manager utility. -This script is then run as the database administrator. --- for single server, cm_db is the primary database with tablespace cm_ts CREATE REGULAR TABLESPACE cm_ts MANAGED BY DATABASE USING (FILE 'cm_ts.dat' 1408M) EXTENTSIZE 16; CREATE TEMPORARY TABLESPACE cm_temp_ts MANAGED BY DATABASE USING (FILE 'cm_temp_ts.dat' 2500) EXTENTSIZE 16; -- logfile size UPDATE DATABASE UPDATE DATABASE UPDATE DATABASE in in 4k pages. Total log space is 176MB CONFIGURATION FOR cm_db USING LOGFILSIZ CONFIGURATION FOR cm_db USING LOGPRIMARY CONFIGURATION FOR cm_db USING LOGSECOND
4096; 5; 5;
GRANT CREATETAB, CONNECT ON DATABASE TO USER invtiv; GRANT USE OF TABLESPACE cm_ts TO USER invtiv; GRANT CREATETAB, CONNECT ON DATABASE TO USER planner; GRANT USE OF TABLESPACE cm_ts TO USER planner; GRANT CREATETAB, CONNECT ON DATABASE TO USER tivoli; GRANT USE OF TABLESPACE cm_ts TO USER tivoli; GRANT CREATETAB, CONNECT ON DATABASE TO USER mdstatus; GRANT USE OF TABLESPACE cm_ts TO USER mdstatus;
Note: You should consider tuning your database. This is not a simple task. You need to know what you are doing and why you are doing it before changing any database parameters. Each environment is different and needs special consideration. The first thing you need to do is understand where the bottleneck is. You will need to get help from your database administrator when you try to tune your Inventory database (or any other Tivoli database) for best performance. Hints about tuning can be found in the IBM Redbook All About IBM Tivoli Configuration Manager 4.2, SG24-6612.
80
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Component
Activity Planner Change Manager Distribution Status Inventory
Database planner (or cm_db) ccm_db (or cm_db) mdist2 (or cm_db) Invtiv (or cm_db) pristine (or cm_db) Invtiv (or cm_db)
RIM object planner ccm mdist2 invdh_1 inv_query pristine trm (only if inv_query is not in local Tivoli management region)
81
Although RIM objects are created during installation, you can create additional RIM objects using the wcrtrim command, or by moving a RIM object from one managed node to another using the wmvrim command. You can also change the database information for a given RIM object using the wsetrim command. The syntax for the wsetrim command is given below:
wsetrim [n name] [d database] [u user] [H db_home] [s server_id] [I instance_home] [t instance_name] [a application_label] [m max_connections] rim_name
Where: a application_label changes the application label for the RIM object. d database changes the name of the database or data source to which the RIM object connects. H db_home changes the path to the database home directory. I instance_home (for DB2 only) changes the path to the DB2 instance for the specified RIM object. m max_connections changes the maximum number of connections between the RIM object and the RDBMS. n name changes the name of the RIM object to name. s server_id changes the server ID for the database t instance_name (for DB2 only) changes the name of the DB2 instance for the specified RIM object. u user changes the name of the database user that the RIM object uses. To change the vendor for a RIM object, you must delete the object using the wdel command and re-create it using the wcrtrim command. Note: Vendor specification specifies the vendor of the RDBMS you are using when creating the RIM object (one entry for each RDBMS system that is supported by the Tivoli RIM component). Valid entries are as follows: DB2 Oracle Sybase Informix MS_SQL Note that Microsoft SQL is supported on Windows systems only.
82
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
To change the managed node for a RIM object, you can either move the RIM object using the wmvrim command or delete and re-create the RIM object. To change the label for a RIM object, you can either use the wsetrim n command or delete and re-create the RIM object. Also, you cannot set the database password for an (RIM) object using the wsetrim command. You can use the wsetrimpw command for this purpose. The following example changes the database ID to inventory, the database user to tivoli, the database home directory to /ORACLE, and the database server ID to invdb2 for the inventory RIM object:
wsetrim -d inventory -u tivoli -H /ORACLE \ -s invdb2 inventory
3.7.1 UNIX
The install process performs some space checking once the install gets going, but you will save a lot of time if you check for adequate Tivoli code and database file system space in advance. To make your system easier to manage, you may want to define some new file systems for Tivoli. You have to ensure that your file systems are large enough to contain all the Tivoli files (refer to the product
83
release notes and user manuals to determine file space requirements). Tivoli, by default, will install most of its files into /var and /usr. There are a number of reasons why you may want to set up specific Tivoli file systems: You avoid problems where other applications may fill up space in /var and /usr file systems. You can back up and restore individual file systems defined on your system, although this may still be a little complex for Tivoli products. You can control the overall disk structure and layout. Default directories created are: /etc/Tivoli /var/spool/Tivoli /usr/local/Tivoli This directory is small at install time and can be left as part of the /etc file system. Make a new file system for this and specify that it should be mounted at system restart. This is the largest of the directory trees created by Tivoli. Create the file system and specify that it should be mounted at system restart.
Tivoli will also write install and other logfiles to /tmp or the temporary directory selected during Integrated Install.
84
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
85
directory.
Scalable Collection Service. Scalable Collection Service is considered part of Tivoli Management Framework, and is used to collect inventory scan results. Distribution Status Console. The Distribution Status Console tracks Software Distributions and other profile distributions. The installation of the Distribution
86
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Status Console requires the following Java components (which are provided by Tivoli Management Framework): Java 1.3 for Tivoli Java RDBMS Interface Module Java Client Framework for Tivoli These Java components are used by several of the other IBM Tivoli Configuration Manager components. The installation of the Distribution Status Console creates the mdist2 RIM object. Activity Planner. This installation creates the Planner RIM object. This RIM object can be on the Tivoli Server. Change Manager. This installation creates the ccm RIM object. Inventory and Inventory Gateway. The installation of the Inventory component creates the inv_query and invdh_1 RIM objects. Software Distribution and Software Distribution Gateway. Software Package Editor. This installation program can be used on all platforms supported as a Tivoli Server. For details about which platforms are supported as a Tivoli Server, see the Tivoli Management Framework Release Notes Version 4.1, GI11-0890 (comes with the product).
87
Note: With the typical installation, the Enterprise Directory Query Facility is also installed, but you are not prompted for configuration values, and so must configure this component later. When you choose the custom option, you will be prompted for Enterprise Directory Query Facility parameters.
UNIX
From the /FRESH subdirectory of the IBM Tivoli Configuration Manager Installation CD5, enter one of the following commands. If you do not have a Java Virtual Machine Version 1.3.1 on the system and you want to download this software to the /tmp directory, enter:
./file .bin
Where file is the name of the file that starts the installation program. For each UNIX operating system, there is a different installation program. For example, for IBM AIX the installation program file will be setup_aix.bin. If you want to download the Java Virtual Machine to a directory other than the /tmp directory, enter:
./file .bin -is:tempdir directory
Where directory is the directory to where you download the Java Virtual Machine. Note: You need at least 50 MB of free space in your tempdir directory. If you have a Java Virtual Machine on the system and do not want to use the Java provided by Tivoli, then enter:
java -D is.external.home=path -jar setup.jar
Where path is the path to the setup.jar file that is located on the installation CD under /FRESH subdirectory.
88
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Note: If the correct version of Java is not installed, the following message appears at the beginning of the install:
#java -Dis.external.home=/img/cd5/FRESH -jar setup.jar -jar : illegal
argument
Usage: java [-options] class
Windows
From the /FRESH subdirectory of the IBM Tivoli Configuration Manager Installation CD5, run the Setup.exe file.
89
90
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Refer to individual product manuals or the All About IBM Tivoli Configuration Manager Version 4.2, SG24-6612, redbook for more information on installing these prerequisites. Notes: Prior to installing WebSphere Application Server, make sure that no active existing services are using ports 900 and 9080 on the server on which you install WebSphere. In order to install Access Manager Base, you can use the ezinstall_ldap_server program.
91
Intel: c:\Program Files\Tivoli\lcfHORecovery - Second installation UNIX: /opt/Tivoli/lcfHO UNIX: /opt/Tivoli/lcfHORecovery The port number must be unique for communication purposes, and not overlap. If your endpoint policy utilizes the ep_ipadd (5$), you must modify it accordingly.
Where: tag specifies the registered product tag for the Tivoli Enterprise product to remove. Tip: The list of these tags can be found in the IBM Tivoli Configuration Manager Planning and Installation Guide, GC23-4702. You can also list the registered product tags by running wuninst -list. hostname specifies the name of the managed node from which to remove the product. If you specify the Tivoli server, the product is removed from all managed nodes in the Tivoli region. rmfiles indicates that all product files are to be removed from specified managed nodes. When you do not specify this option, the command removes the database entries only. When you issue this command from the Tivoli server and specify this option, all entries for each managed node in the Tivoli region are removed.
92
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 4.
93
Software Files (name, size, path, permissions, group, etc.) Software (description, version, name, size, etc.)
TMR server : Tivoli Inventory is installed on the TMR server and is managed from the database object repository on the TMR server. The TMR server provides Inventory access to services and resources: Profile managers, profiles, profile distribution, resource authentication and authorization, event notification, tasks, jobs, and queries.
94
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Tivoli Management Console: Tivoli Inventory is also installed on any managed nodes that will run the Tivoli Desktop (X-Windows version) or the Tivoli Desktop for Windows. To manage Tivoli Inventory using the graphical interface or the command line interface (CLI), you must install Tivoli Inventory on these Tivoli Management Consoles. These are normally desktop machines (UNIX or NT/2000) installed as managed nodes and do not provide services within the TMR (such as Management Gateways, RIM Hosts, etc.). Inventory Data Handler: This server is a managed node in the TMR with an additional object/service installed (installed during Tivoli Inventory installation). This service is responsible for and controls the following:
Receives the scanned data information from the collectors (service on the Inventory Gateways). This collector hierarchy follows the MDist 2 repeater hierarchy used in distribution of large amounts of data (such as in Software Distribution)just in reverse. The data is collected and sent up to the server, not distributed down to the targets. Sends the scanned data information to the Configuration Repository (via the RIM host). The Data Handler manages the connection to the RIM Host/RDBMS and efficiently loads the data into the Configuration Repository. This offloads the TMR server from having to handle receiving this scan data and forwarding it to the RIM Host.
95
Inventory scanners: Software components that run on the target to gather, process, and return inventory data. Inventory profile: Contains the parameters that define how the scanner
should behave, such as whether to do a hardware, software, or custom scan, or all of them.
Collection Table of Contents: Contains a set of header information that describes the data and its destination, and the actual data itself.
To understand the Tivoli Inventory architecture better, let us examine step by step a typical inventory scan scenario. Steps 12 are the distribution of the Inventory profile through the MDist2 hierarchy. It is important to understand that this is an asynchronous profile distribution to activate the scanner at the endpoints, which means it does not wait for the return of data. This allows scans to proceed in parallel across all targets of the profile distribution. In this way, MDist 2 distributions (in this case, Inventory profile distribution) can be monitored through the Distribution Status Console or by using the wmdist command. This also applies to Inventory profile distribution. In steps 34 the endpoint receives the profile, scans the endpoint, and the MIF files are created and parsed. After the MDist 2 distribution is successful, the Scalable Collection Service takes over and sends the data to RDBMS. The endpoint informs the collector on the gateway that the data is ready and requests collection by sending its Collection Table of Contents (CTOC). CTOC includes the data file name and size and the source and destination of the collection. Depending on the configuration of your network, the data may then travel through a hierarchy of collectors before arriving at the Inventory Data Handler.The data remains in the collectors depot until it receives confirmation that the upstream collector has received the entire data bundle. In steps 57 the Collector sends collections to the Data Handler. The Data Handler decompresses and decodes the collection before it writes data into the repository through one or multiple RIM interfaces. In summary, once an inventory profile has been distributed to an endpoint, the collection path for inventory data is endpoint gateway collector Inventory Data Handler RIM host Configuration Repository.
96
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
TMR A
1 6 7
RD
Data Handler
RIM host
RDBMS
Gateway 1 Collector
Gateway 2 Collector
4
Gateway 3 Collector
97
method assembles the collection. It then uses an upcall to pass the CTOC to the Collector process on the endpoint gateway. Once the Collector has registered the CTOC for the collection it will execute a downcall back to the endpoint and retrieve the data. The data contained in a CTOC is described in Table 4-1.
Table 4-1 CTOC information CTOC value CTOC ID Priority SOURCE_NAME SOURCE_OID Description A unique number identifying the collection. Not used. The name of the object label of the machine that started the distribution. OID of the source object. This is the OID of a object that requested the collection. Initially this is the endpoint. OID of the originating object ID. This value is usually the endpoint OID that the scan data belongs to. The method that requested the collection. In the case of Inventory, it should always be mc_get_data. The method (mc_get_data) that requested the collection. This field is no longer used in Inventory 4.2.2. DEST_ID is used instead. This field is used to determine the OID of the destination Data Handler object. The field contains the region ID and Data Handler object label. This information is used to determine the OID of the Data Handler. The method (mc_request_collection) that will receive the data. The full path of the DON file. The DON file is created on the endpoint when the data has been successfully collected by the Collector. Data pack number. Inventory scan ID.
ORIGINATOR_OID
SOURCE_METHOD
DEST_METHOD WRITE_COMPLETION_FILE
DATAPACK inventory_scan_id
98
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Description Number of results. Used for unsolicited scans. Represents the application version. The status of the CTOC file. Indicates the count of the number of failed attempts. This value is reset to 0 if Collector/Data Handler is restarted. If this value reaches the max retry, the Collection Status field on the CTOC is set to false and the CTOC is eventually discarded.
CTOC information is stored in a binary format. Therefore it cannot be viewed using a text editor. The wcstat command can be used for viewing the CTOC information. The command syntax is as follows:
wcstat -v CTOC ID collector
CTOC information and status are depicted in Example 4-1. You must, however, know which Collector currently has the collection before you can check its status. You can view CTOC information using the wcstat command and checking the Collectors queues.
Example 4-1 Output from the wcstat -v command wcstat -q o @managed node:win-rptr01a CTOC ID: c13707486641226774 CTOC Properties: PRIORITY: 1 SOURCE_NAME: WIN-NTK-A SOURCE_OID: 1370748664.4.21 ORIGINATOR_OID: 1370748664.12.522+#TMF_endpoint::endpoint# SOURCE_METHOD: mc_get_data DEST_OID: 1370748664.2.35#InvDataHandler# DEST_ID: 1370748664#inv_data_handler#InvDataHandler DEST_METHOD: mc_request_collection WRITE_COMPLETION_FILE: C:\Tivoli\lcf\inv\SCAN\mcollect\INV00093.DON DATAPACK: 613 Client Properties: inventory_scan_id: 93 inventory_num_results: 1 inventory_opts: 0 inventory_ctoc_version: 16896 Collection Status: QUEUED_OUTPUT
99
#Retries: 0
100
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Collector components
There are three types of resources that are used to control flow of CTOCs and Dat files between two Collectors or the Data Handler: Queues Used as temporary storage areas for CTOCs, and also control the flow of CTOCs between Collectors or the Data Handler. A subdirectory created in the Collectors run-time directory used to store collection data. Processes that control the timing and the flow of data.
Depots Scheduler
Queues
Queues are areas in memory that the Collector uses to hold CTOCs for the collections it is currently transporting. Each Collector has four queues: Input queue Output queue
101
Error queue Deferred queue Each queue has a checkpoint file used to back up a copy of the queues contents to the file system. These files are stored in the SCS run-time directory. Checkpoint files are binary files and are named checkpointGL_[queue]qfile.dat. The checkpoint files are not the queues themselves, but are used by the Collector process to restore the queue if it is stopped or killed. The Collector will append a CTOC to the checkpoint file when it places it in the corresponding queue. When a CTOC is removed from a queue, the Collector also removes it from the corresponding file. Similar to the checkpoint files, a Collector maintains a log file of all completed collections. This log file is named CTOC_log.dat, and it is stored in the same directory as the checkpoint files. CTOC_log.dat also uses the same binary format as the checkpoint files, and its contents can be viewed with the wcstat command. You can check the status of a Collectors queues using wcstat. The syntax is:
wcstat -q queue collector
This gives essentially the same output as the wcstat -v command (described in Example 4-2) for each CTOC in the queue. Example 4-2 shows sample output from this command. You can also use wcstat to read from the completed CTOC log file by using c for the queue option.
Example 4-2 Output from wcstat -q command wcstat -q o @managed node:win-rptr01a CTOC ID: c1370748664612628 CTOC Properties: PRIORITY: 1 SOURCE_NAME: WIN-ARCH01A SOURCE_OID: 1370748664.4.21 ORIGINATOR_OID: 1370748664.6.522+#TMF_endpoint::endpoint# SOURCE_METHOD: mc_get_data DEST_OID: 1370748664.2.35#InvDataHandler# DEST_ID: 1370748664#inv_data_handler#InvDataHandler DEST_METHOD: mc_request_collection WRITE_COMPLETION_FILE: C:\Program Files\Tivoli\lcf\inv\SCAN\mcollect\INV00100.DON DATAPACK: 484 Client Properties: inventory_scan_id: 100 inventory_num_results: 1 inventory_opts: 0 inventory_ctoc_version: 16896
102
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
When an endpoint finishes assembling a collection, it makes an upcall to pass the CTOC to the Collector process on its gateway. The Collector places the CTOC in its input queue and appends it to the checkpointGL_iqfile.dat checkpoint file. The Collector then executes a downcall to the endpoint to retrieve the scan data file. Once the Collector has placed the data file in the depot directory it moves the CTOC from the input queue to the output queue and adjusts the checkpoint files accordingly. If the Collector is unable to retrieve the data file from the endpoint, it will move the CTOC to the error queue and also append it to the checkpointGL_eqfile.dat file. If a CTOC is added to the error queue, the Collector will retry the attempt as per the max_input_retries parameter. This parameter can be configured using the wcollect command. If all max_input_retries have been exhausted and the data still cannot be collected, the Collector will continue to transfer the CTOC to upstream Collectors. Error CTOCs will eventually reach the Data Handler, which notifies the Status Collector and then discards them. Once a CTOC is added to the output queue, the Collector will pass it to an upstream Collector or Data Handler. The process then starts again with the upstream Collector placing it in its input queue and executing a downcall for the data file. CTOCs are copied into the checkpoint files, which are stored in the run-time location directory. The run-time location file system should have enough space to store multiple CTOCs in the input, output, and error queues. The run-time location can be set using the wcollect -l command. If you change the run-time location you must stop the Collector using wcollect -h. If you have a collection in the old run-time directory you must move the contents of the run-time and depot directories to the new location. The unprivileged user account (user nobody on UNIX or tmersrvd on Windows NT) must have read/write permission to the run-time and depot directories. To change the run-time directory run the commands shown in Example 4-3 on page 104.
103
Example 4-3 Changing run-time directory wcollect -l c:/tivoli/mcollect @Gateway:win-rptr01a-gw wcollect -h graceful @Gateway:win-rptr01a-gw Performed 'graceful' halt of collector: @Gateway:win-rptr01a-gw. wcollect -s @Gateway:win-rptr01a-gw Started collector: @Gateway:win-rptr01a-gw.
Tips: Where possible, use a standard directory as a run-time directory on all similar Collectors. Using a standard directory facilitates easy troubleshooting and scripting. If you reconfigure your repeater hierarchy, you need to remove the old Collector information with the wcollect -r command.
Depots
Each Collector has a depot directory used to store scan data. This directory has several subdirectories, one for each CTOC currently in the output queue. The Collector depot also contains an index file called Index.dpo that contains a reference to each collections data files. The structure of a depot is shown in Figure 4-3 on page 105. If the depot is empty, the index file contains the maximum size for the depot. The depots maximum size can be set using the wcollect -z command. The syntax is:
wcollect -z depot size in MB collector.
104
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The use of depots enables the store and forward mechanism of SCS. After a CTOC is placed in the input queue of the upstream Collector, it will make a downcall to the downstream Collector and retrieve the data file from its depot. Depots should be located on a file system with plenty of free space and sizes should be set to a large number. If an upstream Collector tries to retrieve a data file and does not have enough room to store it in the depot, it will cause an error and move the CTOC into the error queue. The depot directory is always a subdirectory of the run-time location. In order to set the depot directory, you must use the wcollect -l command to move the run-time location, as described in Queues on page 101.
105
Scheduler
The Collector scheduler daemon is a multi-threaded process that sends and receives CTOCs. Collector is responsible for moving data upstream to the Data Handler. SCS allows you to set several Collector parameters controlling the bandwidth and schedule that scheduler uses to transmit data. The Collector process spawns input and output threads that move CTOCs from one queue to the next and retrieve data files from downstream endpoints and Collectors. SCS enables you to control the number of threads allocated to input and output. Input threads process the CTOC in the Collectors input or error queue by retrieving the corresponding datapacks from a lower-level Collector or endpoint. Output threads process the CTOC in the output queue of a Collector by making a mc_request_collection upcall to transfer the CTOC to the input queue of the next level Collector or Data Handler. You can change the number of threads allocated to each of these queues. The same as changing the run-time location, you need to restart the Collector for changes to take effect. Example 4-4 shows how to increase input threads to 20 using the wcollect -i command. You can use the -o option to change the output threads.
Example 4-4 Changing input threads wcollect -i 20 @managed node:win-inv01a wcollect -h graceful @managed node:win-inv01a Performed 'graceful' halt of collector: @managed node:win-inv01a. wcollect -s @managed node:win-inv01a Started collector: @managed node:win-inv01a.
Depot chunk size is used to control the size of each data stream that a Collector sends during transmission of collections. The threads values, combined with the depot chunk size, are used to throttle the maximum amount of data being transmitted at any time. If a Collector has 20 output threads and its depot chunk size is set to 5 K, then it will transmit up to 20 simultaneous 5 K chunks of data using, a total of 100 K of bandwidth. The Collector will continue transmitting at this rate as long as there is data in its depot. If a slow wide area network (WAN) link exists between Collectors, the output threads and depot chunk size should be set accordingly. The wcollect -c command is used to set the depot chunk size, as illustrated in Example 4-5.
Example 4-5 Changing depot chunk size wcollect -c 512 @Gateway:win-rptr01a-gw wcollect -h graceful @Gateway:win-rptr01a-gw Performed 'graceful' halt of collector: @Gateway:win-rptr01a-gw. wcollect -s @Gateway:win-rptr01a-gw Started collector: @Gateway:win-rptr01a-gw.
106
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Important: Most Collector parameters require that you stop and start the Collector in order for the changes to take effect.
107
This will reset collection managers route information for a managed node named wininv01a.
Where: -d Specifies the location of the status directory. The default location is $DBDIR/inventory/stat_dir on the managed node where the Inventory Data Handler resides.
108
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
-n
Specifies the interval at which scan completion notifications are sent. This option works in conjunction with the n option of the wsetinvglobal command (option BUNDLE). The alternative notification option is -q, which bundles according to the number of targets. Specifies the number of times the Inventory Data Handler tries to write data to a RIM object. After the maximum number of retries is reached, a failure notification is sent. The default value is 5. Specifies whether the Inventory Data Handler stores status information that can be restored in case of a system failure. Specifies a value in seconds from which to calculate the time-out period in seconds between retries of writes to a RIM object. This time-out period works according to the algorithm timeout*retry_count. For example, on the first retry, with a time-out value of 30 seconds, the algorithm sets the timer to 30 * 1 or 30 seconds. On the second retry, the timer sets to 30 *2 or 1 minute. The default value is 30 seconds. Specifies whether the Data Handler sends a notice to the Inventory notice group when an unsolicited update of scan data occurs. An unsolicited update is an update that is not initiated by distributing a scan to an endpoint remotely from another system. The label of the ManageNode where the Data Handler object will be created. Notice that, unlike other SCS commands, this command leaves out the managed node specifier and just uses the name of the managed node that Data Handler should be created on.
-r
-s
-t
-u
win-inv01a
109
Tip: Data Handler does a great deal of processing during the Data Collection process. Based on this fact we recommend that in large environments you select a dedicated managed node as a Data Handler. This managed node should have enough memory, CPU, and disk space to support the function of a Data Handler. It is possible to move the Data Handler from one managed node to the next by running the wmvinvdh command. The command syntax is as follows:
wmvinvdh -t timeout_value managed_node
Where: -t specifies the number of seconds after which the command will wait before it times out. If you do not specify this option the default of 120 seconds is used. managed_node specifies the managed node to which you want to move the Inventory Data Handler. You must have Scalable Collection Service installed on the managed node in order to use it as a Data Handler. The Data Handler process has input and output threads, just like the Collector process does. These threads can be manipulated using the wcollect -o or wcollect -i commands. Data Handler input threads function essentially the same way as Collector input threads. They receive CTOCs and data files. Output threads function differently. They are used to unpack data and send it to RIM. As described in Scheduling collection using output threads on page 118, you can change Data Handler output threads to schedule data flow to the RIMs the same way that you can change Collector threads to schedule data flow to upstream Collectors. Data Handler also contains queues and checkpoint files just like the Collector process. It also has input, output, and error queues. For an explanation of queues, queue operations, and checkpoint files please refer to Collector components on page 101. The only operational difference between the Data Handler queues and the Collector queues is the final destinations of the CTOCs. When an error CTOC reaches the Data Handler error queue, it is sent to the Status Collector. When a normal CTOC reaches the output queue, it is forwarded on to RIM. The Data Handler uses the output error queue to store CTOCs that require RIM retries. The Data Handler process has a depot that is identical to the Collector process depot. The Data Handler depot is located under the run-time location directory, has an identical index file, and operates the same way. For more information on Collector depots, refer to Collector components on page 101.
110
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
111
handled by the Data Handler process. There are two types of binary files inside the status_dir directory. The first type is the scan ID file. This is a single file named inv_scan_id.cfg. This file contains the last scan ID given out by the Status Collector process. The scan ID number is incremented by one each time a collect data enabled scan is distributed. The second type of file is the scan information file. This file is named inv_scan_XX.cfg, where XX is the scan ID of a running inventory scan. The Status Collector maintains one scan information file for each running status-enabled inventory scan. The Status Collector uses the scan information files to record the current status (pending, successful, or failed) for each node involved in the scan. These files are deleted once the Data Handler process reports that the scan is complete. You can view status information for an active scan by running the wgetscanstat command. This command contacts the Status Collector process and retrieves a list of status-enabled inventory scans that are currently running. This is really a formatted list of all of the scans that have scan information files in the status_dir directory. The wgetinvstat command can be used with the -a switch to view all information on currently running scans. Using the -p -f -s switches will show which endpoints are pending, have failed, or were successful. This is illustrated in Example 4-8.
Example 4-8 Output from wgetscanstat command wgetscanstat -a -s -f -p The following scans using the Inventory Scan ID: 93 Profile Scan ID: 100 Profile Scan ID: 101 Profile Scan ID: 102 Profile Scan ID: 103 Profile Scan ID: 104 Profile Scan ID: 105 Profile status collector are in progress: name: replace.SW.scan.NT.pf name: Custom.SIG.SW.scan.pf name: Initial.HW.scan.pf name: Initial.HW.scan.pf name: Initial.HW.scan.pf name: Initial.HW.scan.pf name: palm_scan.1.0
Tips: It is important to note that the status information returned by wgetscanstat is only as good as what the Status Collector process has in its status files. Since the Status Collector is only notified when a scan begins and when the data is inserted into the database, everything in between will show up as pending. The target is only successful once data has been inserted into the repository.
112
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Handler. The Data Handler unpacks and decodes the data before writing it into the repository using one or multiple RIM objects. The Callback object collection method serves as a backup. Figure 4-4 shows data flow in the case of Collector failure.
Note: Callback object is only used when a failure is detected by the endpoint and first level Collector, and not between Collectors.
113
Tip: In large environments we recommend moving the Callback object to a different managed node than the TMR server, because in the event of a Collector failure all scan data will be sent to the TMR server. This could easily overwhelm the TMR server. The Callback object can be moved once created by using the wmvinvcb command. The command syntax is as follows:
wmvinvcb -t timeout_value managed_node
Where: -t specifies the number of seconds after which the command will wait before it times out. If you do not specify this option the default of 120 seconds is used. managed_node specifies the managed node to which you want to move the Inventory Callback object. You must have Scalable Collection Service installed on the managed node in order to use it as a Callback object.
114
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Important: The number of Data Handler output treads should match the total number of RDBMS connections set for all RIM objects used by the Data Handler. For example, if you have two RIM objects with five RDBMS connections each, the recommended number of output threads for the Inventory Data Handler is 10. (Default or out-of-the-box configuration is 5 output treads and one RIM object.) All Data Handler RIM objects are used for inserting data into the repository. We recommend that you use a separate RIM object for queries. The inv_query RIM object is created by default for this function (in addition to invdh_1, which is created for the Data Handler). Using separate RIM objects will prevent queries from contesting with Data Handler for database access when you are conducting inventory scans. The possibility still exists when running queries, however, that Data Handler will have a table or row locked for inserting data when your query tries to access it. In this case your query may return no results, or incomplete results. For this reason you should try to schedule database updates during off hours. You might wonder what is the optimal number of RIM connections for a TMR. Every RIM object consumes a certain amount of memory overhead, so it is best to run with the fewest possible number of RIM objects per machine. Separating RIM objects on separate RIM hosts divides the processing load, and increases availability in case one of the RIM hosts go down. For example, if you have 10 connections to the database, the optimum setting with two machines configured is such that each one runs a single RIM object. Note: When forecasting how many endpoints can be scanned and the data updated in the RIM database in a fixed period of time, the guideline for the amount of time required (per endpoint) to collect scan data on a local area network is two minutes on average for a full scan.
Planning considerations
Planning your Collector configuration carefully before you begin configuring your Collectors is very a important step for creating an efficient collection data flow. The following factors need to be taken into account when deciding on configuration: WAN links peak hours.
115
Repeater hierarchy. Anticipated scan data per gateway/Collector. Current system load for repeaters intended to be used as Collectors. Disk space Memory CPU Data retention period per Collector. Influences the amount of disk space required for storage of collection data. Data collection time slots. You should calculate the amount of time that is available for data collection tasks. The following factors should be considered: Network off-peak period. Tivoli infrastructure availability. DB availability. To minimize errors ensure that the Inventory database is available during the data insertion phase of the collection process. Note: Ensure that database maintenance tasks that may hold locks on the database do not conflict with the time that the Data Handler inserts data into the repository.
116
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
depot of the downstream Collector. The next time the upstream Collector process starts, it will check the deferred queue against the offlinks list again to see if it can retrieve data files for any of the CTOCs. The wcollect command with the -x option sets the offlinks list. You can list the object dispatcher IDs of the downstream Collectors to defer, separated by commas. Always list the dispatcher numbers in numerical order. This is illustrated in Figure 4-5.
You can also disable a range of object IDs by using a dash. This should also be done in numerical order. The same command is illustrated as follows:
wcollect -x 3-4 @managed node:win-inv01a
The -x option switches between the enabled and disabled connection. You may have to first check the status of each connection before using this option. And like most other Collector settings, you must stop and start the Collector for changes to take effect. Example 4-9 shows commands used to set offlinks.
117
Example 4-9 Setting offlinks example wcollect -x 3,4 @managed node:win-inv01a wcollect -h graceful @managed node:win-inv01a Performed 'graceful' halt of collector: @managed node:win-inv01a. wcollect -s @managed node:win-inv01a Started collector: @managed node:win-inv01a.
To reset the offlinks list, specify wcollect -x with null string as the dispatcher number. This would look as shown in Example 4-10.
Example 4-10 Resetting offlinks example wcollect -x "" @managed node:win-inv01a wcollect -h graceful @managed node:win-inv01a Performed 'graceful' halt of collector: @managed node:win-inv01a. wcollect -s @managed node:win-inv01a Started collector: @managed node:win-inv01a.
To schedule collections simply place these commands in a script and create a task and a job that runs the script. Schedule the job using the Tivoli Framework Scheduler. Offlinks can only be set between Collectors. Note: Offlinks cannot be used in the following situations: Between the endpoint and first Collector Between Data Handler and the RIM object You can check the mcollect.log file to verify that offlinks are working. Use the wcollect command to set the debug level to three on the Collector or Data Handler with the offlinks list. At debug level three, the daemon process will write a message in the mcollect.log logfile every time a CTOC is moved to the deferred queue. The message is scheduler_offlink_test and contains the CTOC ID that was deferred.
118
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
hierarchy all the way to the Data Handler and hold it there. The Data Handler will not attempt to place data in the database until you set its output threads to a number. Using this technique, the Data Handler is prevented from attempting to insert data into the database if the database is down for maintenance or being heavily queried. wcollect -o changes the number of output threads. As with setting the offlinks list, the Collector must be restarted for this to take affect. This is illustrated in Example 4-11.
Example 4-11 Setting output threads to zero: Collector wcollect -o 0 @managed node:win-inv01a wcollect -h graceful @managed node:win-inv01a Performed 'graceful' halt of collector: @managed node:win-inv01a. wcollect -s @managed node:win-inv01a Started collector: @managed node:win-inv01a.
To stop data from leaving the Data Handler run the commands illustrated in Example 4-12.
Example 4-12 Setting output threads to zero: Data Handler wcollect -o 0 @InvDataHandler:inv_data_handler wcollect -h graceful @InvDataHandler:inv_data_handler Performed 'graceful' halt of collector: @InvDataHandler:inv_data_handler. wcollect -s @InvDataHandler:inv_data_handler Started collector: @InvDataHandler:inv_data_handler.
To re-enable collection transmissions these commands are simply reissued using a value higher than 0 for the wcollect -o command. As with offlinks, to schedule collections using this method, these commands must be placed in a script, and the execution of that script must be scheduled using the Tivoli Framework Scheduler. Note: Remember that if this technique is being used to simulate an offlink, the commands must be executed against the downstream Collector. If your Collector output threads are not consistent across all Collectors you may need to set different values when re-enabling collection.
119
reasons you may need to clear the collection before they reach the Inventory repository. For example: If Collectors data has become redundant Failure during profile distribution The wcancelscan command cancels an active inventory scan. This command can cancel a scan at the following points: During the profile distribution, before the profile reaches the endpoint For scans of pervasive devices at the Web Gateway component before the job is processed As the data travels through the Collector hierarchy to the Inventory Data Handler through SCS At the Inventory Data Handler If scan data has been passed from the Inventory Data Handler to a RIM object, that scan data cannot be cancelled. During a scan of multiple targets, the scan data for each target reaches the Inventory Data Handler at different times. Therefore, it is possible that the wcancelscan command could cancel the scan of one target but not another. Example 4-13 demonstrates how to use this command.
Example 4-13 wcancelscan command example wgetscanstat The following scans using the Inventory status collector are in progress: Scan ID: 2 Profile name: Initial.HW.scan.pf wcancelscan -i 2 Starting to cancel Inventory The cancel operation sent to The cancel operation sent to The cancel operation sent to The cancel operation sent to
profile Initial.HW.scan.pf with scan ID 2. Inventory status collector is complete. MDistII manager is complete. Scalable Collection Service is complete. Inventory data handler is complete.
In Example 4-13 we used two commands. The first command, wgetscanstat, gives us the list of all active scans. And wcancelscan with the -i option tells the scan ID to cancel the scan. To cancel all active scans use the -a option. Note: Using the wcancelscan command does not stop the endpoint from completing the scan and data from flowing back to the Data Handler. The scan data is discarded when it reaches the Data Handler.
120
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
121
2. Next, you need to configure the profile (Figure 4-7 on page 124). The Global Properties window is used to set the distribution and data options for the entire Inventory Profile. These options apply globally to all scans that this profile distributes (that is, PC hardware, software, and custom scans, as well as UNIX hardware, software, and custom scans). In this window you can enter:
Profile Name: Name of the current Inventory Profile. Distribution Options: What actions occur when you distribute a profile.
Distribute configuration file and run scan: (Default) Distributes the configuration file to the target endpoint, and then runs the scan on the endpoint. Choose this option when you want to scan the endpoint immediately. Distribute configuration file: Distributes the profile configuration file only, does not run the scan on the endpoint.
122
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Data Options: These options specify how the inventory data gathered by this
profile is stored in the configuration repository: Update with differences: (Default) Compares MIF files created during the current distribution with those from the previous distribution and saves the differences. Only data that has been added or changed since the last scan is transmitted and stored in the configuration repository. Data from previous scans that is not present in the current scan is deleted from the configuration repository. No record of changes is kept unless history tables are used. Select this option to reduce the amount of information that is sent to the configuration repository. Replace with current results: Replaces existing data in the configuration repository with the data gathered by this scan. In the Global Properties Signatures window you specify the software signatures stored in the configuration repository. Note: Software signature is the set of unique information that identifies a software application, such as the name, version, and file size of an application. Inventory uses software signatures to determine which software packages are installed on the machines you scan. When you run a software signature scan on an endpoint, Tivoli Inventory distributes the software signatures to the endpoint, and then compares each file on the endpoint to the list of software signatures. When a file matches, the software signature data for that file is sent to the configuration repository. Because only data for matching files is sent, this scan returns less data to the configuration repository than scans for basic file information or header information. Similarly, a signature package is a logical grouping of two or more signatures. During the Tivoli Inventory installation, over 19-K signatures are loaded into the database. From this window, you can edit or display software signatures. Finally the Global Properties Custom Filter window is used to view/edit the list of entries in the custom filter stored in the configuration repository.
123
The next step is to customize what to scan. You can gather three sets of information with Tivoli Inventory: Hardware scan: Collect data from a list of parameters. Software scan: Collect data from a list of parameters. Custom scan: Additional script to find other hardware/software. There are different customization windows for PCs and UNIX and OS/400. You can also scan pervasive devices. For both UNIC and PC software scans you have the Scan for File Information. Here you can specify which directories and files will be included in the scan. You also specify whether to use signature matching for installed products, use the header information (for PCs only), or scan files for basic information. For PCs, an alternative way to scan for file information is to use Scan Registry for Product Information option. This initiates a scanner on the target endpoint. This registry scanner will scan the registry of the MS Windows platforms for information on installed products.
124
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
On UNIX, there is no registry scan option, but you can use Scan Operating System for Product Information, which uses UNIX OS-specific commands to gather product and patch information. Note: Unlike hardware scans, software scans generally cannot be conducted on both PC and UNIX computers with one profile. There are too many differences between OS types in terms of directory structure, file naming conventions, case sensitivity, and executable file distinction methods. Separate profiles should therefore be created for them and housed in separate Profile Managers whose targets are PC or UNIX, as appropriate. All of your selections are reflected in the Summary of Profile Configuration Settings window. In the Distribution Options you can select the priority of the distribution and then after selecting the targets, you distribute the profile (Figure 4-8 on page 126). You need to have admin, senior, super, or the inventory_scan role to be able to distribute Inventory profiles. Note: The Tivoli Inventory profile utilizes the services of the Tivoli Framework and specifically the MDist2 functionality for distributions. The main feature that can be seen of MDist2 is the priority level selection presented to the user. These priority levels will allow higher priority distributions to be transferred to the targets first, and lower priority distributions (such as a full software package install) would be delayed slightly as the higher priority distribution is allowed access to the target.
125
Note: If you want to distribute an inventory profile to a number of endpoints, but you want the distribution to fail for endpoints that have not received the profile before a certain time, you can use the Advanced Options Timeout Settings from the upper-right part of the menu on the distribution dialog. If you are using the command line (wdistinv command), you can use the deadline parameter of this command. You can configure Inventory to send information about events and errors that result from an inventory profile distribution to which the following locations: Log file Inventory notice group Tivoli Enterprise Console
126
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
127
128
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The query libraries and queries that are provided with Inventory are created during the installation process.
Creating a query
When you create a query, you must specify the following on the Create Query dialog (Figure 4-9 on page 130):
Query Name: Name that is unique in the TMR Repository: Determines which tables and views you can use for the query Table/View Name: Table or view that you select determines which columns you can use for the query Chosen Columns: Within the table or view that are to be retrieved
You can also specify one or more clauses for the query in the following ways:
Where Clause section: To construct a SQL search clause that specifies which
information the query will return
129
Name must be unique in TMR Select view or table name Select columns to be returned Selection criteria Used to limit results If no limit, will return all data for given view/table and columns
It is also possible to use the command line. Use the following commands: wcrtqlib to create a query library wcrtquery to create a query wsetquery to change a query
130
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
mobile users. These users are no longer permanently connected to a network and therefore pose some challenges for distribution of software. Todays software distribution issues are: High number of machines with different configurations and operating systems Systems located remotely Mobile users Limited resources (for example, bandwidth) Complex applications Tivoli Software Distribution provides a centralized software management system with which administrators can install and configure new applications, update existing software with newer versions, and synchronize software on distributed systems. The ultimate goal is to eliminate all human intervention at the target workstation.
Software package
A software package is defined as a file that contains a collection of objects and actions to be performed on a target machine. This file is prepared prior to distribution time. Actions in a software package fall into three separate categories:
Adding and removing objects: This category involves actions that add or remove something from the target system. Examples include adding and removing:
Files Services Registry keys Device objects
System actions: Several system actions are currently available for inclusion in software packages. These include:
Checking for disk space
131
Restarting the target system Setting OS400 system values Inventory signature
Source host
This is the system on which software package definitions are stored. Any machine in a Tivoli environment can be a source host, provided Tivoli Management Framework and the Software Distribution component are installed. Important: Any managed node that is not an OS/2 or NetWare managed node can be used as a source host.
You also use the Software Package Editor to arrange actions contained in the software package in the order in which they are to be performed on the target system.
132
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
There are two versions of the Software Package Editor: Tivoli Software Distribution Endpoint Package Editor This version is installed on endpoints on which software packages will be created and tested. All functionality is available with this version. A software package file can be saved into any of the three formats using this editor. This is also called the Java Endpoint Package Editor. Note: For OS/400 Java Endpoint Package Editor is supported as a preparation site only. Tivoli Software Distribution Package Editor This version is installed on managed nodes and is primarily used for editing existing software packages. Software package blocks cannot be created or edited with this version. In addition, some functionality is not available with the Software Package Editor installed on managed nodes. Certain tools to automate the creation of software packages (AutoPack) and to make using third-party software easier are not available with this editor. Figure 4-10 shows the Tivoli Software Distribution Endpoint Package Editor.
133
Pristine Tool
This is a tool for creating a repository and storing diskette images for installing an operating system remotely on a clean machine. The advantages of using the Pristine Tool are: Preparation and installation can be performed at different times. Installation can be performed almost completely unattended. Synchronizing reference models can be performed automatically.
TMA SD PrepSite
Gateway Repeater
TMA
TMA
TMA
134
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
135
SPB file
SP file File_1 File_2
File_n
Note: Tivoli Software Distribution 3.6 and earlier versions used a file package instead of the software package format. To migrate a file package to a software package object, you must use the wfptosp command. Similarly, a Tivoli Software Distribution V3.6 file package object can be converted with the wfptosp command to a software package definition file. Migration of file package blocks and Autopack are the same as the file package definition file with the exception that no source files are required since these formats contain source files. File package block to a software package block migration must be done on the same platform on which it was created. For example, if a file package was created on a Windows NT platform, it must be migrated on a Windows NT TMR. Software package definition file (extension .spd) A text file that describes a software package. Contains a list of actions to be executed on the target. Can be updated with a text editor in place of using the Software Package Editor. Can be manipulated with scripts. Files are collected from the source host at distribution time.
136
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Signature of SPD
add win_registry_key Add object parent_key = "HKEY_LOCAL_MACHINE\SOFTWARE" key = "OTHELLO" add = y override_permissions = n Attribute value pair end end
26
Software package file (extension: .sp) Internal binary version of the software package. Files are collected from the source host at distribution. See Figure 4-14 on page 138.
137
SP file
Source Host
File_1 File_2
...
File_n
The three different software package formats can be easily converted from one format to another, as shown in Figure 4-15 on page 139. The wconvspo command enables you to convert SPBs to SPs and vice versa. The wimspo and wexpspo commands enable the conversion from SP to SPD and vice versa, and from SPD to SPB and vice versa. Creating a software package in built format ensures that the data in the software package remain static between distributions at different times.
138
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
wexpspo/wimpspo
SPD
SPB
Cr ea te SP fro Ex m po SP rt D SP to SP D wexpspo/wimpspo
SP
SP to PB PB dS uil rt S B po Ex wconvspo
m fro
SP
Versioning
You can define a software package as versionable and specify whether it is a refresh package or a patch. Refreshes are not installed if a later version of the package is already installed. Patches are not installed unless the version to which the patch applies is already installed. The default policy of Tivoli Software Distribution allows the following naming format for software packages: sp_name^version, for example: office^1.0.0 notes^1.2a sp_name.version, for example: office.1.0.0 notes.1.2a Software package name and version numbers are separated by a karat (^) symbol or a dot (.). Version numbers, on the other hand, should be separated by dots (Figure 4-16 on page 140).
139
Dependencies
With software and hardware dependencies, you ensure that the package is installed only if the necessary prerequisites are satisfied. You can define an expression that makes the installation or removal of a software package dependent on meeting hardware and software prerequisites. Figure 4-17 on page 141 shows how you define the dependencies.
140
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Variables
Variables can be used to express any attribute value of type string contained in the software package, making a software package more generic for use on different target systems. For example, it is not necessary to create several software packages for different platforms. You can substitute the platform-specific information with variables and use the same software package for distribution to multi-platform networks.
Conditions
You set conditions on the actions contained in a software package or on the entire software package. Using conditions, you define the circumstances under which an action is executed. For example, you can specify which actions are to be executed on Windows NT with Service Pack 5 target systems and which are to be executed only on Windows NT with Service Pack 6 targets. Valid operators are: Comparison operators: >, >=, <, <=, ==, != Boolean operators: NOT, OR, AND
141
w d crtsp w d u bld sp w d lssp w d instsp w d rm vsp w d cm m tsp w d u ndosp w d acptsp w d ve rsp w d instsp w d se tsps
C reate a n S P B file from an S P D file E xp ort an S P B file into S P D file List conte n ts of the local catalog In stall an S P B R em ove an S P C om m it an S P U nd o an S P In stall/R em ove A ccept a n u nd oab le Insta ll/R e m o ve V erify th e state of an S P R un A uto P ack snap sho ts/diffe rences R ecord ap plica tions not in stalled w ith SD
Autopack
Many actions can happen during the installation of an application. Registry keys may be added to a Windows system or a symbolic link might be added to a UNIX system. Determining what actions take place when an application is installed can be a difficult process. The autopack tool can automatically create a software package for any application installed on a Windows 98, Windows NT, OS/2 3.x, or UNIX platform. Below is a summary of Autopack functions: A tool to automate the creation of software packages. Detects file and system changes made by the installation of an application
142
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Can be accessed from the Software Package Editor on an endpoint or command line Is not accessible from the Software Package Editor on a managed node
143
Empty
A software package object just created
Built
A software package object built during the import
Not Built
A software package object not built during the import Will be built at the time of distribution
The task of associating an SPD, SP, or SPB file with a software package profile is called Import (wimpspo).
Note: When importing a software package file or software package definition file into a software package object, the administrator can choose to build the software package immediately or leave it not built. The advantages of creating a software package in the not-built format are: You can revise the software package until the moment of distribution. It occupies a smaller amount of disk space. If you use the non-built format, you need to take into consideration that data may change on the source host, so subscribers may receive different data at a different time. Software packages should always be imported into the built state if you want to use the deporting functionality.
Delivery
After the planning and administration tasks have been completed, the delivery of the necessary files begins. The delivery step is performed by MDist 2. The steps of the software distribution delivery phase are illustrated in Figure 4-20 on page 145.
144
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Tivoli Server
Tivoli Desktop
5. Return a distribution ID
Standalone Repeater
Source Host
3. Source host initiates the
distribution
Gateway/Repeater
Gateway/Repeater
MDist 2
Endpoints
Endpoints
The Software Distribution process uses the Frameworks MDist 2 service to deliver the files to the endpoint target: 1. An administrator submits a request to the Tivoli management region server from the Tivoli Desktop. 2. The Tivoli management region server routes the request to the appropriate source host. 3. The source host begins the distribution process. 4. The source host returns a distribution identification number to the Tivoli management region server. 5. The Tivoli management region forwards the distribution identification number back to the administrators Tivoli desktop. 6. Files are distributed down to the endpoints. The components in the figure are:
Source host: A system that holds all the files referenced by software packages
in the not-built state. Software packages already in the built state (software package blocks) will also reside on this system.
Repeater: Receives a single copy of data and fans out the distribution to the
next tier of clients. In Tivoli Software Distribution, endpoint gateways are automatically repeaters.
145
These operations fully automate distributing, installing, and maintaining software, and are as follows:
Install: The install operation performs the actions contained in the software package. The actions executed by the install operation depend on the nature of the action. For example, while the install operation of the Add file action copies a file to the target file system, the install operation of the remove
146
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
registry key action removes a registry key from the target system Windows registry.
Remove: The remove operation reverses object-related actions that add something. If a software package adds a file or registry key, the remove operation will remove that file or registry key. Conversely, if the software package has an action that removes a file, nothing will happen to replace that file during the remove operation. Actions to be performed during a remove action can be specified for program actions within the software package. Undo: Performing a remove operation does not necessarily return the system
to its previous state. For this reason, an undo operation is recommended where system files are involved in distributions. Executing an install operation in undoable mode creates a backup of everything necessary to return the system back to its previous state. An undo operation cannot be executed for an installed software package if it was not installed in undoable mode in the first place. An administrator can determine if an installation was performed in undoable mode by checking the state of the software package on the target. Note: The machine must have adequate space to create the backup; otherwise the installation will not occur.
Accept: The accept operation discards the resources needed to undo the
previous operation (backup copy). The accept operation, which frees up system resources, should be performed only when you are certain that you will not need to undo the previous operation. After running an accept operation, the previous operation is no longer undoable.
Commit: An install or remove operation can be submitted in transactional mode. In this case the operation is performed in two phases: The preparation phase and the commit phase. During the preparation phase, each action in the package prepares the conditions for the successful execution of the requested operation, which reduces the risk of failure during the commit phase. The commit operation causes all the updates established in the preparation phase to take effect. Verify: The verify operation verifies the consistency of the software package and the object on the target system. If the verify operation fails, the software package is placed in an error state. Load: The load operation loads the software packages on a repeater depot for subsequent distribution. This operation is valid for only built software packages.
147
Note: A depot is a directory on the repeater that enables you to temporarily or permanently store data segments associated with distributions on the repeater. Every distribution flowing through a repeater is stored at least temporarily in the depot. The location of the depot parent directory is set by the rpt_dir repeater parameter. Use wmdist to view and set the parent directory of the depot. As mentioned, the load operation loads the software packages on a repeater depot for subsequent distribution. You can also use the command line for this purpose. The command to use is wldsp.
148
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Remove
In Error -
An install has been committed. An install has been committed and can be undone. An install has been prepared and it will be committed during the next reboot. A remove has been committed, but it can be undone. An install has been committed, but the software package is in error. The software package was discovered by Inventory.
Install options
There are a number of install options when installing a software package and software package blocks (see Figure 4-23).
Figure 4-23 Install for software package block (left) and software package (right)
149
Figure 4-23 on page 149 shows the installation window (when installing from the Tivoli Desktop) for a software package block (left) and a software package (right). Some of the important installation options are below:
Delta Install: Creates a software package that contains only the delta between the base software package and the software package to be installed. By creating and distributing a delta software package, network traffic is reduced. Label: Label of the distribution (can be seen from the wmdist -l command or
MDist GUI).
Source: Distributes only source host files that have been modified since last distribution time. This applies only to not-built software packages and to target machines where the software package has already been installed and committed. Repair: A distribution at some point may become damaged on the endpoint.
The distribution may have never successfully completed. Or the distribution was originally successful but files were modified, deleted, or corrupted since the distribution. A repair distribution is a distribution that includes only the files necessary to repair the endpoint. The software package is built specifically for the distribution. Since this is the case, only not-built software package objects can be used to repair a damaged distribution.
From Fileserver/CD: Rather than installing from the source host or from a depot, a software package can be installed from a file server or from a CD. The file server must not be a managed node.
First, a distribution image must be created using the wdepot command, which can then be transferred to a file server or onto a CD. Note: Installing from file server or CD options is useful if the endpoints are at the end of a slow link. Using these options, you can separate the data from the distribution itself and load the data on a dedicated file server or CD located in the same location as the target endpoints.
From Depot: Sends the software package from the depot. Disposable: Removes the software package block from the repeater depots after the distribution is complete. This saves disk space on the repeaters and reduces the need for you to manage the depot contents. Advanced Options: Sets the timeout setting or the notification settings of a
software package. Installing from a file server.
150
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
151
3. Let us assume we want to perform a send operation. Select the Send menu item. The Data Moving Service Send Operation dialog is displayed (Figure 4-24).
4. Fill in the dialog as appropriate and click Send to finish the operation.
152
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Note: These options are also available if you want to use the command line, instead of the GUI. The command to use is wspmvdata.
153
154
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 5.
Deployment Services
This chapter provides an overview of IBM Tivoli Configuration Manager 4.2.2 Deployment Services. The following topics will be covered in this chapter: Activity Planner on page 156 Change Manager on page 168 Enterprise Directory integration on page 176 Resource Manager and pervasive devices on page 183
155
156
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The Activity Planner User Interface which consists of the following: Activity Plan Editor (APE) Activity Plan Monitor (APM) The Activity Plan Editor is used to create activity plans, and the Activity Plan Monitor is used to monitor these plans. RDBMS: RIM object planner. Used to store: The definitions of the activity plans The status of the submitted activity plans Activity Plan Monitor administrator: It is used internally by the Activity Plan Monitor engine and added during the installation of the Activity Planner, swd_admin_regionname, login tivapm.
157
Double-click the Activity Plan Editor icon to open up the Activity Plan Editor. To define an activity using the Activity Plan Editor, specify the following: The name of the activity A brief description of the activity The type of operation the activity will perform on a set of targets Properties related to the type of operation Targets of the activity (if not specified at the activity plan level) Activities that perform Tivoli Software Distribution operations are represented in the Activity Plan Editor main window by an icon that displays a box with an inserted CD-ROM. Activities that perform Tivoli Management Framework tasks are represented in the Activity Plan Editor main window by an icon that displays a timer, a schedule, and a pencil. Activities that perform Tivoli inventory scan tasks are represented in the Activity Plan Editor main window by an icon that displays a magnifying glass.
158
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
You can save activity plans that you prepared using the Activity Plan Editor as any of the following: Drafts, if they are not yet complete Templates, if they are complete XML files Note: You can also use this format when creating an activity plan with a text editor. It is also possible to start creating your activity plan from the GUI, save it as XML file, and than perform additional changes on the XML file. Draft plans and templates are stored in their respective repositories in the activity plan database, but only templates are made available for submission.
159
You can assign targets at the activity level or at the activity plan level. However, if you assign targets for each individual activity, you cannot specify targets at the activity plan level. If you assign targets at the activity plan level, the targets apply to all of the contained activities, and no other targets can be specified at the activity level. You can assign targets in one of the following ways: A list of target names A file name containing a list of target names An inventory subscriber A query library subscriber A profile subscriber A directory query library subscriber A pristine target subscriber Tivoli Configuration Manager provides a dynamic target resolution capability. If this feature is enabled, the targets for an activity will be resolved when the activity is started and not when the activity plan is submitted. For example, when a query directory is used to select the targets of an activity, the query directory will be executed when the activity is submitted.
Failure: The execution of Activity B is performed if the operation defined in Activity A fails with an error.
The execution of Activity B depends on the completion of Activity A on all of the targets defined in Activity A. The operation specified in Activity B is executed when Activity A has completed execution on all its targets.
160
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
A completion percentage of targets can be specified. For example, you can specify to execute Activity B when Activity A has completed executing on 50 percent of its targets. Note: If you want an activity plan to stop if there is a software distribution error, the stop on error setting should be warning for the activity plan. In addition to conditioning the execution of Activity B based on the result of Activity A, you can specify the targets on which the specified result must occur. You can specify one of the following:
Depot: The execution of Activity B on a set of targets sharing the same depot depends on the execution of Activity A on the specified depot. The operation specified in Activity B is executed on target X when Activity A has completed execution on the specified depot.
Note: Conditioning by depot is available only if the conditioning activity is a Load, Unload, or Task Library activity, and if the conditioned activity is addressed to endpoints sharing the specified depot. You can define a final activity in the plan that is executed when all other activities in the plan have either completed or have been canceled.
161
162
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
163
Activity Plan Monitor is launched from the Tivoli Desktop. Figure 5-5 shows the steps to submit a plan. Select Plans Submit from the menu of the Activity Plan Monitor window to submit a plan. The Select plan for submission dialog box is displayed.
The General page is displayed by default. Before submitting the plan for execution you can edit the attributes that were defined at the time the plan was created. The modifications are applied only to the current submission instance and have no effect on the template If you click the Execution Time tag, you can specify an execution time at the plan level as opposed to activity level, which was discussed in Scheduling when to execute an activity on page 162. An activity plan can be scheduled to run more than once. Select the Frequency tab for this purpose. You can specify to repeat the execution of a plan in days, months, at a specific date interval, or a time interval. When you specify to execute an activity plan recursively, each time the plan is executed, an instance of the plan is submitted for execution. The reference point from which the recursion begins is the start not before time specified on the Execution Time page.
164
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Finally in the Plan Submission Parameters notebook you can define new variables, change values previously assigned to variables, and specify the targets for the plan to be submitted. From the Plan Properties notebook, select the Variables tab for specifying a variable.
The Activity Plan Monitor GUI will provide an overview of the status of each activity of a submitted plan. This GUI will not provide any details about the MDist 2 distribution, such as a time spent chart or a distribution topology graph. However, a button on the Activity Plan Monitor GUI will automatically launch the MDist 2 GUI, showing the details for the activity that was selected in the Activity Plan Monitor GUI below.
165
Figure 5-7 Launching MDist 2 GUI from the Activity Plan Monitor GUI
166
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
To define the plans you want to remove, you can specify any of the following options: Plans with a particular status (canceled, failed, successful) Days elapsed since plans completed Days elapsed since plans started Plans with a specific age When all the cleanup parameters have been set, the Activity Plan Monitor relies on the Tivoli Management Framework Scheduler to perform the cleanup.
167
The following commands are used to monitor activity plans: wdelstat removes the status of a submitted plan. wmonpln displays the status for all activities in an activity plan. wsfdpln sets filters to automatically remove completed activity plans from the activity plan database. The following commands manage the Activity Planner database: wapmfltr specifies one or more filters to be applied to plans, targets, or activities. wdelpln removes an activity plan from the activity plan database. wexppln exports an activity plan stored in the activity plan database in the activity plan definition file XML format. wimppln imports a specified activity plan in XML file format into the activity plan database. wlstpln returns a list of the activity plans maintained in the activity plan database. wunlockpln displays a list of locked plans and unlocks plans currently locked.
168
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The root level defines requirements that are common to all users, and the child models define additional specific requirements that apply only to a particular group of users.
All Employees
Support Staff
Software Developers
Managers
Endpoints
C++ Developers
Endpoints
Java Developers
Endpoints
Configuration elements
Configuration elements are associated with each reference model and use the concept of desired state to define the hardware and software requirements of subscribers to the reference model. For each registered plug-in, a configuration element is uniquely and completely identified by the name/desired state pair. The configuration elements available depend on the set of plug-ins you have registered. When you want to add a configuration element to a reference model, you must specify the elements name and the desired state. The only exception to this is when you want to add an InventoryData element. InventoryData elements do not require you to specify a desired state because this element only checks for information and has no desired state to reach. Configuration elements defined for models at the top of the hierarchy are inherited by those lower in the hierarchy. The types of configuration elements are:
169
Inventory data elements: An Inventory data element verifies the reference model against the Inventory database, for example, for hardware requirements or sets of requirements. To create an Inventory element, you define an expression that includes, for example, one or more hardware characteristics, such as physical memory size, and software characteristics, such as installed software. Inventory scan elements: An inventory scan element enables you to perform software and hardware scans of subscriber machines. To create an inventory scan element, you define a profile that includes one or more scan characteristics. Operating System elements: An Operating System element enables you to
perform operating system and TMA installations on pristine or bare metal machines. A SWD element can be made conditional on a software dependency. A software dependency is defined as one of the following: Prerequisite, where the changes required by the element are only made if the dependency condition is true Exrequisite, where the changes required by the element are not made if the dependency condition is true Corequisite, where the changes required by the element can only be made as part of a sequence that includes the requirement defined in the dependency condition
Selecting subscribers
Configuration Manager provides multiple ways to select subscribers: Specifying a CSV (Comma Separated Value) file Specifying a Profile Manager Specifying individual targets Defining an SQL query on the Tivoli Inventory configuration database Enterprise Directory Query Facility: Selecting reference model subscribers using a directory query The subscribers to a reference model are the workstations, OS elements, devices, and users that you want to be configured to match the hardware and software requirements defined for the model. Figure 5-9 on page 171 shows how to select subscribers.
170
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Differencing mechanism
Change Manager creates required actions by using a differencing mechanism (Figure 5-10 on page 172) that compares the current state of each element on the specified subscribers with the desired states defined in the reference model. The Change Manager differencing mechanism produces the actions necessary to arrive at the desired state for each element on each target assigned to it, in the form of an activity plan. The activity plan contains a list of actions necessary to attain the desired state and is submitted to the Activity Planner or imported to the Activity Planner database for scheduling.
171
Reference Model
Differencing
Activity Planner
Figure 5-10 Differencing mechanism
Change Manager includes two functions that use a differencing mechanism to produce a list of the actions required to bring subscribers to the desired state defined in a reference model. These functions are Preview Activity Plan and Submit Activity Plan. When you preview or submit an activity plan, the differencing mechanism creates an activity plan listing all the actions requested to move the configuration elements to their desired state. The Preview function simply displays the activity plan in a window so you can preview the changes that are going to take place. The Submit function allows you to set other Activity Plan Manager (APM) specific parameters before it submits the plan to APM for processing. By default Change Manager synchronizes a reference model to create the associated activity plan by considering all the configuration elements specified in the model and creating the actions related to those elements. However, the full synchronization feature allows you to perform a further step in the synchronization process. In general, Change Manager synchronization creates the requested actions related to the listed elements as in the default behavior. When it does this, it also creates a new set of actions related to all the elements already present on the selected subscribers though not listed in the current reference model, in order to revert the state of such elements. In the case of Software Distribution elements, reverting means to uninstall, or to remove the software element, or package, from the target machine. This does not necessarily mean that such actions will all involve actual remove actions. The required action will depend on the actual state of the package on the target machine. Thus, for a Software Distribution element, when you select the full synchronization option, Change Manager creates a set of actions to remove from the subscribers all the software packages not listed in the reference model being synchronized.
172
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
173
5. If the new model is to be a new root model, select the Create new root check box. 6. In the Target name field, enter the name of the target from which you are creating the new reference model. 7. Use the radio buttons below the Target name field to specify the appropriate target type. If you selected the endpoint subscriber type, you can browse the endpoints. If you selected the device type, the navigator is disabled since it is not possible to navigate the individual device instances. If you selected the user type, the navigator displays the association between a user and the related endpoint. 8. Select the Hardware check box if you want the new model to perform checks on the selected hardware configuration elements from the target. If you select this check box, you must also select the specific hardware elements you want included. 9. Select the Software check box if you want the new model to include all the target's software configuration elements. 10.Click OK. Change Manager creates the new reference model with the name you specified in the Name field.
174
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
11.When you have finished building the reference model, you can export it to an XML file format. In this format, you can read the file and edit it in any standard text or XML editor and reimport the file to Change Manager. To export a reference model to xml format, perform the following steps: 1. Go to the main Change Manager window, and from the File menu select Export. The Export settings dialog box appears, as shown below.
2. In the Reference model definition file (XML) field, enter the name you want to give the XML file. 3. Select the Include inherited elements check box if you want to export elements the model inherited from the parent model. Select the Export single reference model check box if you want to export only the selected reference model itself and no child models. These check boxes are optional, so you can select one, both, or neither. If you select neither check box, the model is exported with its child models, and without elements inherited from the parent model. 4. Click OK. The reference model is exported in XML format to the specified file. Next you need to select the subscribers for your reference model.
175
Note: When using the Change Manager, if you remove the parent reference model, children reference models are automatically removed.
176
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
distributing the profile to a Resource Group of users. Similarly, you can distribute an Inventory profile to a Resource Group of users to scan the endpoints associated with the users. After the Directory Query Services product has been installed on the Tivoli management region server, the directory server schema has to be modified. This has to be done manually on the directory server. Note: The directory server requires no specific Tivoli software; it does not have to be a managed node or Tivoli endpoint. The directory schema has to be modified using the ldifde command (which is available on the directory server) and an LDAP Data Interchange Format (LDIF) file. The LDIF template file is provided on the Tivoli management region server in $BINDIR/TAS/QueryDir/SCRIPTS. The template file has to be edited, and the correct directory context has to be provided. After running the ldifde command on the directory server, the Enterprise Directory schema is changed to accept three new attributes: tmeObjectId, tmeObjectLabel, and tmeTrmId. These attributes will be used to link directory users to Tivoli endpoints (tmeObjectId and tmeObjectLabel) or Tivoli Resource Manager devices (tmeTrmId).
177
The wcrtdirctx command is used to create a directory query context. The syntax is:
wcrtdirctx [-i] -s server -u user -c naming_context [-f provider] [-p port] [-P ssl_port] [-S y|n] [-k keystore_path] directory_context_name
Where: i input Specifies that the password must be read from standard input. s server Specifies the server. u user Specifies the directory server administrator or a user with equivalent authority. c naming_context Specifies the naming context to use for the search. f provider Specifies the java class name that identifies the directory access protocol. The default is "com.sun.jndi.ldap.LdapCtxFactory". p port Specifies a server port for a non-secure connection. If not specified, the default value 389 is used. P ssl_port Specifies a server port for a secure (SSL) connection. If not specified, the default value 636 is used. S y|n Enables the Secure Sockets Layer (SSL) between the directory server and the Tivoli region. Y specifies enable, n specifies do not enable. If not specified, SSL is disabled. k keystore_path Specifies the path of the keystore containing the certificates used during an SSL connection. If you specify this option you must also specify the keystore_path password. dirquery_context_name Specifies the name of the new directory query context.
178
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
For example, to create a directory query context named firea3ctx for a connection to a Novell server directory:
wcrtdirctx -s armando.enterprise.com -u cn=admin,o=context1 -c o=context1 -p 389 novellctx
In this example port 389 is the TCP port for LDAP service. cn= and dc= is standard syntax for LDAP queries. o=context1 is the Novell directory context for users of the Novell Directory domain. After the DirectoryContext object has been correctly configured, the wmanagedir command can be used to update the information of the Enterprise Directory. This command is used to link Tivoli endpoints to directory users. An endpoint can only be linked to one user, and a user can only be linked to one endpoint (one-to-one relationship). The purpose of linking endpoints to users is to be able to retrieve Tivoli endpoints from the Enterprise Directory, based on information contained in the Enterprise Directory. This is done using directory queries, for example, a directory query that selects all endpoints of users in the marketing department. For more information on wmanagedir and other Enterprise Directory integration commands refer to IBM Tivoli Configuration Manager: User's Guide for Deployment Services, SC23-4710.
179
CLI: wcrtdirquerylib
Figure 5-13 Creating a directory query library
After creating the directory query library, a Directory Query can be created from the GUI or by using the wcrtdirquery command (authorization role admin, senior, or super). See Figure 5-14.
180
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Note: The scope scrolling list in Figure 5-14 on page 180 specifies the point in the directory tree hierarchy at which you begin the search. Possible values are: object The search if performed only on the specified object one level The search if performed on one level of the tree subtree The search if performed on the specified tree and on all the descendent directories Unlike Inventory queries, query directories cannot be used to set the subscribers of a profile manager or to select the targets for a Tivoli profile distribution (software package profile, Inventory profile, Monitoring profile, and so on). Query directories can only be used to select the targets of an Activity Plan Monitor activity or to select the subscribers of a Change Manager reference model. If you want to create a subscriber Directory Query, you should at least specify the tmeObjectId and the tmeObjectLabel.
181
When selecting the query directory, the user can specify when the query should be executed: When the plan is submitted When the activity is started For testing purposes, the query can be executed using the Get result button. It is important to note that you should always select the tmeObjectLabel in the attributes section. The attribute you select is the actual data that will be passed to the activity for determining the targets.
182
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
183
Resource Manager enables you to manage resources in your Tivoli environment. Resources can be users and pervasive devices, such as Palm devices, Nokia 9200 Communicator series devices, and Windows CE devices. You can keep track of devices in your environment and customize their settings from a central location. You can also distribute software to and scan inventory of pervasive devices and the endpoints associated with users. Resource Manager, which is installed on the Tivoli server, maintains a master database of the pervasive devices that are managed by the resource gateways. Resource gateways are endpoints that have applications that extend the Tivoli endpoint to manage pervasive devices. In Tivoli Configuration Manager 4.2.2, the only supported resource gateway is Web Gateway. Gateways that have the Resource Manager gateway component installed connect the Tivoli server with the resource gateways. Each resource gateway maintains an independent Web Gateway database. Resource Manager notifies the Web Gateway databases of any changes to the master database and vice versa.
184
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
For example, when you create or delete a device in the Resource Manager database, Resource Manager notifies the Web Gateway database on the endpoint managing the device to update its database. When a new device connects, it is automatically enrolled and Web Gateway notifies Resource Manager to update its database. Note: As a resource type, the Pervasive_Device resource type is used for pervasive devices.
185
Before a Web object can be used, it has to be published. This process grants access rights to those users who want to access the object, and copies it to a server from where it can be accessed by means of the Web. To publish and unpublish Web objects use the wweb command (there is no GUI equivalent, so this must be from a CLI). This command allows you to give access to a specified Web object to one user, several users, a list of users, or to grant unrestricted access to all users. The Tivoli Web Gateway component maintains a list of enrolled devices. Scalable Collection Service is used to return notification of resource management operations.
To manage resource gateways from any managed node in interconnected regions, you must run the wresgw add command from each region.
186
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
187
188
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Another big advantage of Pristine Manager is that the pristine machines can now be defined in the reference models and activity plans before the machines are part of the Tivoli environment; in other words, before the Tivoli Management Agent is installed on the machines. Pristine Manager integrates capabilities of the Microsoft Automated Deployment Services (ADS) or Microsoft Remote Installation Services (RIS) servers with Tivoli functions. Pristine Manager uses the images that are on your RIS and ADS servers to install them on the target machines. At the same time, Pristine Manager includes the machines in the Tivoli environment as endpoints: It takes the label that you define and makes it the endpoint label of the new machine. This enables Change Manager and Activity Plan Monitor to work with the machines as if they are Tivoli endpoints after the pristine installation. In Pristine Manager, you define the servers that have the images and the pristine machines on which they will be installed. You specify the operating system element and the targets. This creates a connection among the operating system to be installed, the target pristine machines, and the servers. Then this information is used to create an activity plan that is used by Activity Planner to do the pristine installation.
189
Tivoli Console
TMR Server
CCM APM APM Plugin: pristine execution logic
Element and subscriber navigator (GUI)
TMA
TMA
TMA
ADS
ADS
...
RIS
190
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Professional and its upgrades to any number of client computers at one time from a centralized location. Microsoft positions RIS for client workstation installs. Automatic Deployment Services Windows 2003 introduced another pristine deployment feature called Automatic Deployment Services (ADS) in Windows 2003. Microsoft positions ADS for server installs. You cannot install Windows XP with ADS. Both ADS and RIS are shipped with Windows 2003. ADS has more advanced features than RIS, such as multicast capability and image-based installation, whereas RIS is script based. Preboot Execution Environment Both ADS and RISC use Preboot Execution Environment (PXE), which is a standard created by Intel and allows a network adapter to act before a server loads an operating system from a load hard disk.
5.5.5 Prerequisites
In order to use Pristine Manager successfully, ensure that you have the following prerequisites: Your RIS or ADS server is already installed, configured, and working. There is a Tivoli endpoint on the machines where the RIS or ADS server is installed.
191
You have already created the images on your RIS or ADS server. Refer to the appropriate documentation for instructions. On the ADS or RIS server, you have created a directory with the binary files to install the Tivoli endpoint. The directory must be shared and have full-control permissions.
192
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
CCM
APM
2. APM invokes CM4OS plugin for execution CM for OS APM Plugin 4. Execution engine 4. Execution engine populates the activity populates the database activity database 3. Activity ID is generated, control is given to the execution engine CM for OS Execution Engine CM for OS Activity completion daemon
DB
TMA
CM for OS Remote plugin ADS Server
TMA
CM for OS Remote plugin RIS Server
5. Execution engine sends commands to the pristine servers with downcalls that are executed by the remote plugins
Figure 5-19 shows that the pristine installation is kicked off by CCM via a reference model, but the flow is the same when it is initiated manually by APM (in that case it would start from step 2, rather than step 1). In step 3 an activity ID is generated, and in step 4 the activity ID is populated in the activity database step 4. At this point the pristine activity can be monitored from the APM Console. The installation begins by the commands sent by the APM execution engine to the pristine servers.
193
CCM
APM
DB
Endpoint Manager
Gateway
2. CM for OS polls the EP Manager to see if new TMAs logged in (only for pending machines)
1. TMA from the new pristined machines login to the gateway TMA TMA
3. CM for OS verifies the identity of the pristined machine with a sort of scan operation
RIS Server
In addition to the operating system, the TMA is laid down on the machine. When the pristine installation is finished (step 1), TMA logs into the gateway. APM understands the completion of the installation by polling the EP for new TMAs logged in. This is done by polling by the Activity completion daemon (step 2). Note that this is the only method that Activity Planner can understand the status of the pristine operation. If something goes wrong during the pristine installation no information is passed to the Activity Planner (since there is no TMA on the machine yet). For this reason it is very important to define a proper time out for the pristine operation (by default, this is 2 hours). You can change this value by using wpristine set timeout value command. This command sets the maximum time, in hours, for an operating system installation to be completed before it times out and is considered unsuccessful. Operating system installation completion means the pristine machine has logged in to the gateway. After finding out that the new TMA has logged in, the Activity completion daemon sends an event to that endpoint to verify the identity of the machine by a scan operation on the endpoint (step 3). Once this is verified, the status of the target is passed to the APM (steps 4 and 5). At that point, Activity Planner can proceed with the other activities on the activity plan.
194
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Before starting the pristine installation, you need to set up some parameters thorough this GUI. Now let us walk through some of the important settings: 1. The first thing you need to define is the servers on which the operating system images are located, as shown in Figure 5-22 on page 196. These distribution servers are already part of the Tivoli environment, because they have a TMA on them. From the Server Manager menu, click the General tab. In the General parameters window, you need to define the type of the distribution server (ADS or RIS) and also enter the Endpoint label (remember that there has to be a TMA installed on distribution servers).
195
Figure 5-22 Define servers on which operating system images are located
2. Click the Environment tab and you will see the Environment window for the server settings. Here you can set environment variables, which can be inherited as default settings by the machines associated with the server. Unless these variables are changed on a per-machine basis in the Machine Manager menu, they will be used for all machines that use the server. The following is the list of environment variables provided by Pristine Manager, but you can define your own variables as well. _CM4OS_SMBIOS_GUID _CM4OS_MAC_ADDRESS _CM4OS_SCREENWIDTH _CM4OS_SCREENHEIGHT _CM4OS_COLORDEPTH _CM4OS_COMPUTERNAME _CM4OS_HOSTNAME _CM4OS_DOMAINNAME _CM4OS_IPADDRESS _CM4OS_DNSSERVER_ADDRESS _CM4OS_GATEWAY_ADDRESS _CM4OS_SUBNETMASK
196
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
3. After defining your distribution servers, you can define your pristine machines. Note that these machines are not part of the Tivoli environment yet. They do not have a TMA on them. We will use the Machine Manager menu for this purpose. The first panel is the General parameters window, as shown in Figure 5-24 on page 199. Here you can define the General parameters for this installation. First you need to specify the distribution server this machine will be served from. Do not forget here that you need to enter the name (not the endpoint label) of the server machine in the Server field. In the Endpoint label field, you enter what you want the endpoint label of the TMA on the machine to be, once the TMA is installed.
197
You need to put in SMBIOS GUI D for those machines. This is similar to a MAC address for a network interface card. Every PC that complies with the PC98 standard has a unique SMBIOS GUI D. This is a 32-character hexadecimal value, required for installation from a RIS server. For ADS servers, it is recommended that you specify this setting, because it is used to verify the success of installation on the pristine machine. Pristine mode is a very important parameter. If you make a machine a part of a reference model, and the first step of this reference model is pristine installation, this machine can be re-installed every time this reference model is synchronized. So by default, the Pristine mode setting is Ignore, which means that it will not attempt the pristine installation. The possible settings are: Force: Install the new OS with no regard of current status. Ignore: Do not install the OS. If different: Install the OS only if the new OS is different from the current one. If newer: Install the OS only if the new OS is a new version of the current one.
198
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
4. Click the Network tab and define the Network parameters. Here you see the parameters that are inherited from Server settings. You can overwrite these settings on a machine basis. For example, here we have changed the domain name.
199
5. Click the Tivoli tab and enter information that will be used to include the machine in the Tivoli environment, as shown in Figure 5-26 on page 201. Again, you will see settings that are inherited from the server. But if necessary, you can change these settings. The most important setting here is the PRISTINE_TMA_SETUP_PATH setting. This is where the pristine installation will get the TMA code from. In most of the cases this will be a shared directory on the server and will be inherited from the server, but you can also define it here for a specific machine.
200
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
6. Click the Environment tab and you will see the inherited environment list that displays the settings that the machine inherits from the server by default, as shown in Figure 5-27 on page 202. You can override these settings for that specific machine or add additional settings. Here, for example, we have defined additional settings.
201
7. Optionally, you can group target machines based on the needs of the user group and install software that is tailored for that group. The group concept is similar to a profile managers. In Tivoli, profile managers are used to distribute profiles to a bunch of machines at the same time. But since profile managers do not understand the pristine operation flags such as ignore, force, etc., you cannot group pristine machines in profile managers. So, you need to have a different kind of grouping mechanism for pristine machines, and this is called a group. Management of groups is done through the Group Manager menu. Similar to a profile manager, you define a group and define the machines that belong to a group from the Group Manager windows, as shown in Figure 5-28 on page 203. Later when you create a target for a pristine action, you can target a group, rather than a specific machine.
202
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
8. Finally, you need to configure the Operating System Element (Figure 5-29 on page 204) via the Operating System Element Manager menu. Here you create an Operating System Element and then you define which images on pristine servers correspond to the operating system that you want to lay down for this Operating System Element. For example, if you have more than one RIS or ADS servers, and each has a Windows 2000 image, you need to let Pristine Manager know which images on which servers are associated with your Operating System Element for Windows 2000. Note: The images might have different names on different servers, depending on the server the machine is connected to. It should be able to pull the right image using the Operating System Element definition. You will use the Operating System Element later in the reference models and activity plans. In the Images window, Operating System Name is important if you plan to use If new or If different pristine mode setting options. The Architecture field is reserved for future use.
203
After these settings are done, your machines should be ready to be installed when they are referenced in a reference model (or manually added to an activity plan).
204
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Enter the name of the operating system element and click OK. Desired state The state that the pristine machine should reach. It is installed by default and read-only, because the action that the element performs is a pristine installation. You cannot choose an undo or uninstall state. 6. Click OK. The new operating system element is added to the reference model.
205
Installation_Failed Installation_Successful To enable the IBM Tivoli Enterprise Console notification use the wpristine enable tec command. Similarly, to disable the notification you can use wpristine disable tec.
206
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 6.
207
Mbytes to 100 endpoints would take about 5.6 hours (assuming the default bandwidth of 500 Kbytes/sec). Using multicast, this same distribution could be done in less than 3.5 minutes. Not only is the distribution time decreased, but network traffic is also decreased by the same ratio. This is useful for customers sending data to multiple targets over satellite, on slow network links, or wanting to conserve bandwidth. This chapter discusses the following topics related to multicast: Reliable multicast protocol Hyper Delivery (RMTP) flow Distributed depot service Endpoint multicast receivers Multicast scenarios Multicast limitations Troubleshooting multicast
208
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The overhead incurred for reliability causes distribution times to depend on the number of receivers. However, if the number of dropped packets is small, the overhead is only a fractional increase of the distribution time per receiver.
209
Multicast packets are targeted at a multicast group, which is a combination of an IP address and port number. Multicast uses the class D IP addresses in the range of 224.0.0.0 to 239.255.255.255. To receive multicast data, a receiver must join the multicast group. During the join process the receivers router or switch is contacted and told to forward multicast traffic for that group. Users wishing to use multicast must have their network hardware (routers and switches) multicast enabled. Tivoli Management Framework uses the registered multicast address 224.0.1.18 (tivoli-systems.mcast.net) to listen for the multicast advertisements. The headers of UDP datagrams carrying multicast traffic contain a time to live (TTL) setting. The TTL setting is the number of routers that will forward the packet before it is discarded. In other words, TTL is a mechanism for determining the scope of a transmission. Unlike a unicast address, a multicast address can extend through the entire network. The value contained in this field is decremented at each hop.
210
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
4. Sender: RMTPConnectSender() requests a connection to the receivers by sending a CONN packet. Depending on the value of the repeat parameter, the sender will send multiple copies of each control message. The default is 2. The sender will resend the CONN request to retry the receivers depending on two parameters, connrtry and connwtout, but each resend is driven by multiple sends decided by a repeat value. Connrty specifies the number of times that a multicast sender will rebroadcast the connection message to the receivers. The default is set to 5. Connwtout specifies how long the sender waits before retry. The default is 2 seconds (2000 milliseconds).
211
So, a sender will resend CONN requests every connwtout ms. It will do this connrty times or until it hears from all the receivers. The sender repeats this same pattern for CONN (connrtry/connwtout), POLL (pollrtry/dtwtout), and RELEASE (relrtry/relwtout). 5. Receiver: On receiving a connection request, it calls RMTPAcceptConnection (). RMTPAcceptConnection () sends a CACK using the source address parameter (specified by returnIP on the sending gateway) to support an alternate reply path to the sender. For example, the sender's IP address of the terrestrial uplink may be different from the one of the downlink for a one-way satellite network. 6. Sender: On receiving the CACK, sender will now start sending data. The data to be transmitted is divided into messages that are messagesize bytes long, except in the case of the last message, which may be smaller than this. Each message is divided into blocks, which are defined by blocksize. Confirmation of receipt (sender POLL, receiver ACK/NACK) and retransmission (if necessary) is done after sending each message. The default message size is 90 Mbytes. 7. Sender: After sending all blocks in a message, the sender polls receivers and waits for a response from each receiver. The response is either ACK (received all blocks) or NACK (requesting missing blocks). 8. If the sender has not received ACK/NACK from all receivers before the timeout specified by dtwtout (default is 3000 milliseconds), it again polls receivers from which no response was received, if any. The polling is repeated for up to pollrtry (default is 5) times. Receivers that still have not responded will be ignored thereafter. 9. Sender: If the sender has received NACK(s), another transmission of data blocks occurs in the same way as the initial data transfer, but only missing blocks are transmitted again. The number of transmissions is up to dtrtry (default is 10), including the initial one. 10.Sender: After the sender has successfully sent all of the messages, or has reached dtrtry, the sender requests connection release to receivers that responded with ACK. The timeout value to wait for a response (RACK) is relwtout (default 2000 milliseconds) and the number of retries is up to relrtry (default is 5) including the initial one. 11.If there are multiple messages, the transmission sequence above is repeated for each message.
212
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Receive Multicast
Gateway / Repeater
MDist 2 Depot
Depot Server
Send Multicast
Managed Node
Figure 6-3 Depot server
The depot server is divided into various components: Multicast Sender: We are using the Hyper Delivery reliable multicast transport protocol (RMTP) developed by IBM Japan for sending bulk data. The sender can broadcast to other depot servers or directly to endpoints. Multicast Receiver: Allows the depot server to receive broadcasts from other depot servers. MDIST2 Depot: Local storage of bulk data. It can read and write from an MDist2 repeater depot. Location is decided by the rpt_dir value on the repeater. The depot server is enabled on the managed node, which is a repeater, using:
wmdist -s repeater_name repeater_multicast=TRUE
This configures a managed node repeater to send multicast data. This command also works for gateway repeaters, which you will need if you want to use multicast to load a gateways depot.
213
The gateway repeater is multicast enabled running (explained in more detail in 6.4, Endpoint multicast receivers on page 218):
wmdist -s repeater_name endpoint_multicast=TRUE
This is for the gateway to send multicast to endpoints. If you want it to receive multicast, then you need to do the previous repeater_multicast configuration. Note: In order to use multicast, you must install Java 1.3 for Tivoli and Tivoli Java Client Framework 4.1 on the managed node/gateway. Once enabled, the depot server will be started at boot time and remain running. There are two more options with wmdist regarding multicast, which are explained in Configuring repeaters for multicast on page 215. In a typical business scenario there may be many branch offices distributed around the country, or the world. If the IT department in the companys headquarters needs to distribute software to each branch office, multicast can be employed to keep the distribution time to a minimum. If each branch office has a managed node in it, the source host (the Tivoli Server in the headquarters building that initiates the distribution) can multicast the distribution by way of a high-speed link (for example, a satellite link) to MDist2 depots on managed nodes at each branch office. As with unicast, managed nodes that multicast to endpoints must be configured as gateways. The depot services running on the gateway in each branch office listen for multicast broadcasts. When a multicast broadcast is received by a depot service, the service writes the distribution to an existing MDist2 depot on the gateway. Once the data is in the MDist2 depot, it can be multicast or unicast to all of its endpoints over the LAN in the branch office. The depot service sends a multicast message, a UDP broadcast, to advertise the distribution. The advertisement contains a description of the data being sent and the endpoints that should receive it. Multicast receivers listen for these advertisements to determine which distributions they should receive. Each distribution requires a separate distribution process; you cannot load MDist2 depots and deliver to endpoints in a single step. The first distribution sends the package from the source host to the gateways (or repeaters). The second distribution sends the package from the gateway to one or more endpoints (or in the case of a repeater, to another gateway). If an MDist2 depot is not functioning when the distribution is sent to it, there is currently no provision to retry the multicast distribution. Instead, retries can be manually performed using a unicast distribution to the endpoints that did not receive the original multicast distribution.
214
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
endpoint_multicast Whether the repeater sends distributions to endpoints using multicast. The default is FALSE. default_multicast Back-level applications that use MDist2 but do not have the multicast distribution option built in can take advantage of multicast if this parameter is set to TRUE. This will cause that application to send all distributions from the specified repeater using multicast first. If the distribution fails then it will attempt to do unicast depending on the fail_unavailable settings. When set to TRUE, repeater will not attempt a unicast retry for endpoints that failed to receive multicast. The default is False. This option is hidden and does not show up. This parameter is also for back-level applications and only relevant to gateway repeaters.
fail_unavailable
The wmcast command sets repeater properties for MDist2 multicast distributions. The defaults provided are designed for use in most LAN environments. However, if a repeater sends multicast over both fast and slow links, configure multicast repeater settings for the slowest link.
wmcast s repeater_name [keyword=value...]
The settings are: backofftm=time_in_milliseconds Specifies the back-off time in milliseconds. When receivers acknowledge receipt of a multicast advertisement, the receiver waits for a random time interval between 0 ms and the number of ms specified by this keyword before responding to the sender. This reduces congestion. As you add more receivers, this number might need to be increased to improve performance. The default is 100.
215
blocksize=size_in_bytes Specifies the size of the block, in bytes, that the sender uses when writing data to the network. The size specified must be less than 65535 bytes. The default is 1460 bytes, which is the Maximum Transmission Unit (MTU) for Ethernet transmissions. connrtry=retry_count Specifies the number of times that a multicast sender will rebroadcast the connection message to the receivers. The default is 5. connwtout=milliseconds Specifies the time, in milliseconds, that a multicast sender waits for receivers to accept a connection. The default is 2000. dtrtry=retry_count Specifies the number of times that a multicast sender will resend dropped packets to receivers. The default is 10. dtwtout=time_in_milliseconds Specifies the time, in milliseconds, that a receiver will wait before timing out if the data transmission is interrupted. The default is 3000. ifrcvaddr=address... Specifies a list of IP addresses that the receivers use when listening for multicast packets. Separate multiple addresses with semicolons (;) and enclosed in double quotation marks (...). The default is 0.0.0.0. ifsrcaddr=address Specifies the IP address of the source host interface that is used to send multicast packets. The default is 0.0.0.0. mcadvert=address Specifies the address for multicast messages. If you set mcadvert to something other than the default, the endpoints must log out and relog in or disable and enable to listen to the other address for multicast advertisements. The default is 224.0.1.118, which is the IANA-registered address for Tivoli multicast. mchigh=highest_address Specifies the highest address to be used to send multicast data. When the server is ready to send multicast data, the server selects an address between mclow and mchigh to find an address that is available for multicast data traffic. If the first address checked is being used for sending multicast data, the address is incremented and the next address is monitored for activity. This continues until an available address or mchigh is reached. The default is 224.2.255.255.
216
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
mclow=lowest_address Specifies the lowest address to be used to send multicast data. When the server is ready to send multicast data, the server selects an address between mclow and mchigh to find an address that is available for multicast data traffic. If the first address checked is being used for sending multicast data, the address is incremented and the next address is monitored for activity. This continues until an available address or mchigh is reached. The default is 224.2.128.0. mc_netload=bytes_per_second Specifies the speed, in bytes per second, that the repeater will send multicast distributions. The default is 500000. mc_debug_level=trace_level Specifies the trace level. 0: Records no trace information 1: Records exceptions only 2: Records general trace information 3: Records all implemented tracing
Trace levels are incremental. The trace logs are written locally on each repeater to $DBDIR \mcast.log. The default is 1. pollrtry=retry_count Specifies the maximum number of times that a multicast receiver will poll receivers to determine their final status. The default is 5. port=port_number Specifies the port number to use for multicast advertisements and multicast data. The default is 9499. rcvbufsz=size_in_bytes Specifies the size, in bytes, of the receive buffer of the UDP socket. The default is 250,000. relrty=retry_count Specifies the number of times that a multicast receiver will broadcast the connection-release message to receivers. The default is 5. relwtout=time_in_milliseconds Specifies the time, in milliseconds, that the sender will wait for the receiver to release the connection after all data is transmitted. The default is 2000. repeat=count Specifies the number of times that the server sends the same control packets. This can be increased if packet drop affects performance. The default is 2.
217
returnIP=address Specifies the IP address of the server that the receivers communicate with. In satellite configurations, for example, the server-to-receiver traffic is a satellite link, and the receiver-to-server traffic is generally a telephone line; the return IP address will be different from the IP address of the source. The default is 0.0.0.0. sndbufsz=size_in_bytes Specifies the size, in bytes, of the send buffer of the UDP socket. The default is 250,000. ttl=count Specifies the time-to-live integer. The integer indicates the number of times a packet can be forwarded by routers. When a packet is passed through a router, this integer is decremented; when it reaches zero, the packet is dropped. Specify a number larger than the number of routers between the multicast sender and receiver. The default is 5.
When this command is run the first time, it will ask you whether you would like to start the multicast receivers on all the endpoints connected to this gateway. When a multicast distribution occurs, the depot server sends a multicast message advertising the distribution. The advertisement will contain a description of the data being sent and the endpoints that should receive it. Clients listen for these advertisements to determine which distributions they should receive.
218
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
LCFD
Spawn
Multicast Client
Receive Multicast
Software Distribution
File Cache
TMA
Figure 6-4 Endpoint multicast receivers
The multicast client stores the entire distribution in a local file on the endpoint. This means that the endpoint should have enough free disk space to store the distribution twiceonce for the data cached in the local file and once for the data as it is being installed. The transfer of bulk data occurs before any downcalls are performed. Eliminating downcalls before the transfer of data will improve performance. For this release, the data transfer is also done without the participation of the application. This means that neither the application nor the user has the ability to refuse the transfer of data. Later, when the application is run, it still has the option of not installing the data. The only negative impact is that disk space may be consumed temporarily. Checkpoint restart does not occur for multicast distributions. The depot server always sends the entire distribution. Endpoints marked as mobile will not receive multicast distributions unless the distribution is hidden or the mandatory date has passed. Mobile users will continue to use the mobile GUI and receive distributions through unicast connections. After the bulk data has been moved to endpoints through multicast, the repeater will invoke the application's endpoint method. Instead of receiving data from the
219
gateway, the MDist2 endpoint library will read data from the local file. The local file will be deleted when all of the data has been read. Results will be returned as in a normal MDist2 distribution. The download of application method binaries will still occur through unicast connections. Retries for endpoints that fail to receive a multicast distribution will use the normal MDist2 unicast retry mechanisms of retrying every X minutes for Y minutes (default is every 15 minutes for an hour) or when the agent logs into the gateway.
log_threshold
For details about the wep command, refer to the Tivoli Management Framework Reference Manual Version 4.1, SC32-0806. Note: Note that the endpoint version level must be 41000 or higher to support multicast.
220
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Source Host
Gateway or Managed Node Repeater Multicast
MDist 2 Repeater
Gateway or Managed Node
MDist 2 Repeater
Gateway or Managed Node
MDist 2 Repeater
Gateway or Managed Node
MDist 2 Depot
MDist 2 Depot
MDist 2 Depot
The user's network must support multicast traffic from the source host to all of the gateways. The source host must be a managed node running either a
221
managed node repeater or a gateway. Both the sending and the receiving repeater must have repeater_multicast=TRUE. The final step of moving the data to endpoints is accomplished by a second distribution that uses the pre-stored data in the gateway depots. The second distribution may use multicast or unicast to send data to the gateway's agents. In this example we have a Windows 2000 Advance Server TMR server (win-tmr01a), which is also the source host. We will load software package Tivoli_JRIM^4.1 to three Microsoft Windows NT/2000 gateways using multicast. We do not want the distribution to attempt any unicast if multicast fails.
We have selected the database profile manager (pkgs.swd.apps.pm.a) to be able to distribute to the specified managed nodes. The network is multicast ready.
222
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
We have also enabled all the gateways to be multicast ready. 6.3, Distributed depot service on page 213, explains how to enable repeaters for multicast. Perform the following steps to the load the MDist2 depots using multicast: 1. From your Tivoli Desktop right-click the profile, as shown in Figure 6-6 on page 222. 2. Click Load, which should bring up the Load software package window. 3. After configuring the distribution and selecting subscribers, click Advance Options and select Distribution Settings, as shown in Figure 6-7 on page 224. 4. This brings up the Distribution Settings widow. By default under the Multicast Management, Enable Multicast is unchecked. To enable multicast you will have to check the box, which will also check Retry Unicast. Because in our example we do not want to retry unicast, you should uncheck Retry Unicast, which will cause the distribution to fail if multicast fails.
223
5. After making the selections, click Set and Close, followed by Load and Close. This will cause the software package to be loaded to the respective depots using multicast. Note: If a multicast distribution is attempted to a single endpoint, then unicast will be used irrespective of the distribution mode. You can still multicast to a single repeater.
Command line
Loading of depot using multicast can also be achieved via command line by using wldsp with -l is_multicast [ t | f ] set to t. Setting the enable_multicast token to t enables the retry_unicast token. To disable and unicast attempt you have to set the retry_unicast to f. This option can be used only if the enable_multicast option is set to t. For more detailed information
224
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
regarding wldsp please refer to IT Configuration Manager Reference Manual for Software Distribution 4.2.2, SC23-4712.
Gateway Repeater
Multicast
TMA
TMA
TMA
TMA
TMA
TMA
To explain the scenario of multicast between gateway and endpoints we will use the Data Moving service to show how a large file of 135 MB is sent to multiple endpoints from a source host that is a gateway. The gateway is an AIX 5.1 box serving multiple endpoints. The target boxes that will receive the distributions are Windows 2000 Professional desktops. Each desktop has a single endpoint running. We will use only five endpoints for our target distribution. The gateway has a zipped file, data4.zip, which is located in a user-defined directory, /usr/local/Tivoli/file_source. The file size is approximately 135 MB, and has to be placed in the C:/TEMP directory on the target. The network has been multicast enabled, and we verified that all the target endpoints are multicast enabled and listening by doing a simple multicast ping using the wmcast -p option. The Data Moving service provides the capability to perform data distribution, with send, retrieve, and delete capabilities, between managed nodes and endpoints. However, for this example we focus on the send option.
225
Data Moving operations can be managed in an activity plan, using the Activity Plan Editor. We will store our plan as a draft template. All Data Moving operations are referenced with a single, logical software package object reference known as DataMovingRequest.1. This consistent object helps prevent database cleanups and maintenance issues after distributions. Step-by-step information on how Data Moving was used to distribute a file through the multicast follow: 1. From the Tivoli Desktop click Activity Plan Editor. This will bring up the Activity Plan Editor using the same user login that was used to open the desktop. 2. As shown in Figure 6-9, click the Software Distribution icon under Activities to create a Data Move activity. 3. This brings up the Activity Properties window, as shown in the same figure. Give it a name of your choice. We call it Data_Moving_Multicast_Send. Give it a description of your choice. 4. Select the operation to be performed, which is Send.
226
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
5. Click Properties and this will bring up the Send Properties window, as seen in Figure 6-10 on page 228. 6. The Send Properties window is divided into multiple folders. Under Applications Options, key in the: a. Data Origin Source Host: Select the source host that is our gateway, aix-tmr1b. b. File Name: data4.zip. c. Data Moving Objects: File Path at origin: /usr/local/Tivoli/file_source. File path at destination: C:/TEMP. d. Under Distribution Options, right at the bottom you should see Multicast Management. Click Enable Multicast and leave Retry unicast checked. e. Click OK to save the send properties and the next OK for the Activity properties.
227
228
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
7. Now that we have tuned our distribution parameters, we should see our distribution icon in the planer. The next step is to select our Windows 2000 desktop endpoints as targets for the distribution. 8. Right-click the icon, which now has the label of Data_Moving_Multicast_Send. 9. Select Targets, which brings up the Select Target window, as seen in Figure 6-11. 10.As we want the endpoints to be our targets, we will leave the default value of Endpoints for Target Types for Browsing. 11.Under the Target Selection list, click Insert and this should bring up the Select target window as shown in Figure 6-11. By clicking Target List you can bring up the endpoint list to select your endpoints. 12.Save the targets by clicking OK in all the target windows.
229
13.Once done, the activity plan is complete and we need to save the plan name. Select the icon and click View from the top menu and select Plan Properties. Give it a plan name. We gave it the name Data_Move_Plan. This is the name you select to submit the plan. 14.Now to submit the plan we need to click the Activity Plan Monitor from the desktop. This brings up the Tivoli Software Distribution - Activity Plan Monitor as seen in Figure 6-12. 15.Click Plans Submit and select the plan. 16.The zip file data4.zip will now be multicast to all our target endpoints.
230
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
network congestions. But, with all the benefits come a few limitations and concerns one must consider before using multicast. 1. While data is being sent through multicast, a pause or cancel action will have no effect. The command will not take effect until after multicasting has finished. 2. While data is being sent through multicast, the wmdist -I command will not show the progress of the transfer. Instead you will see an arbitrary number identifying that this distribution is multicast. Example 6-1 shows an example. 3. Software Distribution will be used to preload depots similarly to the way it is done today, but with multicast enabled. Multicasting to agents will be done in Software Distribution by enabling the distribution's multicast flag. When using multicast, bulk data is moved to the endpoint before invoking the application. For Software Distribution, this means that its prerequisite checking (for example, checking available disk space or if the application has already been installed) happens after the bulk data has been stored on the endpoint. If Software Distribution later decides it should not install the application, the bulk data was transferred needlessly. However, the only adverse side effect of this is the temporary consumption of disk space.
Example 6-1 Multicast distribution status and ID # wmdist -I aix-tmr1b Repeater: aix-tmr1b Jobs in SEND queue: 2 Jobs in RECEIVE queue: 0 === Session Information === Low: available = 40 Medium: available = 9 High: available = 5 used = 0 used = 1 used = 0
=== Distribution Information === External Id: Internal Id: Label: Priority: Application: Target: Target: Target: Target: 1375372617.152 1375372617.152 jcf.1 (install) 3 Software Distribution State: State: State: State: WAITING WAITING WAITING WAITING 0% 0% 0% 0% (0/0) (0/0) (0/0) (0/0)
231
Target: WIN-MUR-03 State: WAITING 0% (0/0) Target: WIN-MUR-04 State: WAITING 0% (0/0) Target: WIN-MUR-05 State: WAITING 0% (0/0) === Distribution Information === External Id: Internal Id: Label: Priority: Application: 1375372617.152 1375372617.1.578#1028222779 jcf.1 (install) 3 Software Distribution State: RECEIVING 0% (0/0)
Target: aix-tmr1b
4. By nature, as mentioned earlier, multicast is a UDP-based protocol, and networks need to be configured to allow multicast to flow. This definitely is a concern in a firewall environment. If you wish to use multicast through firewalls then you will have to configure the firewall to pass multicast packets in both directions (from sender to receiver for bulk data, from receiver to sender for acknowledgements). Multicast uses at least two multicast groups (IP address + port): Multicast advertisements, which in our case use 224.0.1.18 + 9499. Actual distribution, which will be decided by the mclow and mchigh values configured under wmcast. By default this range is from 224.2.128.0 to 224.2.255.255. 5. The data sent through multicast is not encrypted and should be used under secure networks. 6. Because multicast is cached on the endpoint prior to processing, the endpoint must have twice the distribution size in free space.
232
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
If the managed node is a repeater then the MDist2 log is written to the rpt2log in the database directory. The logging level can be set using the following command:
wmdist -s repeater_name debug_level=number
Where 0 is the least information and 9 is most information. The default is set to 3. If the repeater is a gateway, then the gateways gatelog provides the necessary MDist2 logs. Setting the gateway to debug level 9 would give the most information regarding MDist2. The gateways debug level can be set using the following command:
wgateway gateway_name set_debug_level number
It is recommended to set the gateway to debug level 9 when dealing with Mdist2 issues. The new logfile for the multicast depot server is placed in the $DBDIR/mcast.log. This log provides detailed information regarding multicast depot communication. The logging level for multicast can be set using:
wmcast -s repeater_name mc_debug_level=number
Where the number ranges from 0 to 3. The default is set to 1. 0: No logging 1: Exception logging 2: Most logs including exceptions 3: Most logs plus the entry, exit, and exceptions
233
To check if endpoints are listening for multicast, the following command can be used to do a multicast ping:
wmcast -p repeater name
This will send a multicast advertisement to the endpoints and check if they are received.
If the advertisement address is changed on the repeater, then it needs to be changed on all the receivers endpoints too. We recommend leaving the Tivoli default advertisement address as 224.0.1.18, as it is registered with the IANA. The time-to-live integer for multicast is set to 5 by default. If you have multiple routers between your receiver and target, then you may have to change this value. You can use Trace Route to determine how many hops are between the sender and receiver.
234
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Chapter 7.
235
Troubleshooting Activity Planner Troubleshooting Change Manager Troubleshooting Web Gateway and Device Management Troubleshooting Web User Interface Troubleshooting Enterprise Directory Integration Troubleshooting Inventory
236
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
c. Recreate the problem on every involved machine, including the TMR server. d. Do odstat -v > odstat.txt. e. Do wtrace -jHk $DBDIR >wtrace.txt (or %DBDIR% for Windows). f. Collect the above files plus oserv.log and any useful system logs. 5. Once tracing has been done or the problem determined, you could 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 could cause 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.
237
Additional logs can be found in the database directory, which is locatable through the following variable names: $DBDIR on UNIX %DBDIR% on Windows NT/2000/2003 or OS/2 The database directory contains other files that can be used as debugging tools: epmgrlog gatelog odb.log gwdb.log oservlog odtrace.log Endpoint manager log Gateway log Tivoli database transaction log Tivoli Gateway database transaction log Error log of the Object Dispatcher (oserv) The file that the wtrace command reads and translates
On a TMA endpoint, there is also a logfile in the /lcf/dat/xx path. lcfd.log Endpoint log
238
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
In some cases, you may need to get into the more complex area of direct manipulation of the Tivoli object database. You can hand-run methods, identify method source files, and so on. For more information on these Framework commands and logs refer to Tivoli Framework V 4.1.1, Maintenance and Troubleshooting Guide, GC32-0807.
7.3 Autotrace
In Tivoli Management Framework 4.1 the Autotrace feature has been incorporated for various components. Autotrace is a "flight recorder" type trace tool, which means it is designed to run all the time in a product's production environment with minimal performance impact. Autotrace is a third-party tool incorporated by Tivoli for troubleshooting. The software is originally developed by The Kernel Group Inc. (TKG). The data collected by Autotrace represents the execution of the program itself and can be used to determine control flow. Function entry and exit are recorded with the parameters passed and the return codes given. Autotrace has a minimal impact on the performance of a process. Because of this, we can deploy code with Autotrace built in. This removes the need for debug code to be shipped for many cases of problem determination. Each trace hook can be set to be active or not. It captures all traces in memory for maximum performance. Trace buffers are in shared memory, which allows trace to be captured to a file even when the Tivoli product abends suddenly. Autotrace has a concept of a trace ID. Autotrace associates each unique function signature with a number called the trace ID. The number and types of parameters, the return type, and the file the function is found in make up the function signature. IBM keeps a database of these trace IDs. The trace IDs are remembered across releases so that we can accurately report the data from snap files across different versions of the executables. It also allows for dynamic control over the parts of a program that are being traced at any given time. Trace data collection is as simple as running a command to save a trace buffer snapshot, which can then be analyzed later, either locally or remotely, with the interactive tools provided. The Autotrace Trace Profiler analyzes one or more snap files and produces a summary output detailing which program functions were called, how often they were called, and provides overall statistics. The Trace Profiler can be used to determine what the First Failure Data Capture set of functions needs to be.
239
Note: Reading the data collected from Autotrace requires access to the Tivoli source code and database. One should do the required tracing only if requested by a Tivoli representative.
240
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
encountering the problem, check for any set pattern. For examples, all the problematic endpoints serviced by the same gateway or the same profile are failing on all these endpoints. The problem then could be with the gateway or the profile. For problems with the gateway and endpoint, refer to 7.2, Troubleshooting Framework 4.1.1 on page 238, to further determine the cause of the problem. With the Framework infrastructure and the endpoint in working order, the problem could 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 could be with the profile or the software package. The best source of information of the distribution is in the software package logfile 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 with nested software packages. A Software Distribution to a group of endpoints failing with an error like 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. Refer to the IBM Tivoli Configuration Manager Users Guide for Software Distribution, SC23-4711, for the requirements and implications of using these options. There can be times where the installation of the software package is successful but the status in the log does is not correctly indicate this. This can occur with user_program defined as the final action, which has an indefinite time out or a manual reboot of the target required. This is due to the records of the states of the software packages in the Inventory database being out of sync with the endpoints catalogs, which hold the states of the software package. You will need to run wsyncsp to reconcile the information. The other sections in this chapter detail how to enable tracing and which logfiles need to be reviewed for the different components.
241
The default location of the logfile is on the TMR server under directory structure $BINDIR/. ./swdis/work. However, it is possible to generate a logfile on a specific managed node with the log_host_name attribute in the SPD file that specifies the label of the managed node, typically the host name, where the logfile is generated. The default name for the log is package-name^package-version.log. You can specify the logfiles location on any managed node or target in the Package Properties dialog from the Software Package Editor. To change the location of the logfile using a software package definition file, update the log_file_path attribute. We recommend that you generate a detailed log on the endpoint that records each action in the software package and the results of change management operations on the package. The target logfile is set with the log_object_list stanza in the SPD file, and the location keyword that identifies the path name or subdirectory. If the directory does not already exist, it will be created. The logfile will also be SPname.SPversion.log or SPname^SPversion.log, the same as for the logfile name on the TMR or designated managed node. IBM Tivoli Configuration Manager, by default, will overwrite the logfile with each new distribution of the software package.
242
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
243
information on Error messages. 8 (maximum level) provides the most verbose information on upcall and downcall activity. Tips: One particular case is when you have reinstalled an endpoint, but the endpoint does not seem to be able to log into the Tivoli environment. To correct this problem you need to delete the previous endpoint using the wdelep command. If your endpoints have problems contacting their gateway first check whether your endpoints can see their gateway by using the ping command.
244
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
You can no longer distribute to an endpoint to which you previously were able to send distributions. Ensure that the endpoint is connected to its gateway and is active. Distribution times out. If the distribution times out, check the values for send and execute timeout set using the wmdist command. Note: All distributions have an absolute maximum time limit, after which they will be reported as expired. The default time limit is 72 hours. Distribution takes longer than expected. You can use the wmdist -I gateway/repeater name command to monitor the progress of loading the software package at each repeater (it gives the number of bytes transferred and the percentage complete). If you decide that performance is bad, you may decide to change the way in which your network is configured (netload). The alternative wdepot command checks on the existence of a package at a depot, and thus may be useful if the level of completion is of no interest to you. You may also consider configuring a machine that is continually used as a source host as a repeater. By configuring the source host as a repeater, you can tune the communication parameters of the machine so that the software package is routed directly from the source host to its gateway. This saves time and network load. Note: Use the wmdist -s rptname debug_level command to change the information level from the repeater log or gateway log. The value ranges from 09. The log name is $DBDIR/rpt2log. If the system is a repeater, the default is 3. If the system is a gateway, the default is 0. For example, the wmdist -s test debug_level 9 command changes the information level on the test system to 9. The log is written in the $DBDIR/rpt2log file.
245
The SPD file provides details of the software package in one look. Use the wgetspat command to get the attributes of the software package. Note: The minimum authorization role required to retrieve the attributes for a specified software package object is user. The SPD file allows for setting all possible properties and options in a readable text format, including those only available using an import or export. The SPD file can be considered the instructions or control file defining actions and how they are performed. There are three ways to obtain the software package definition file, which is given a suffix of .spd, for example, SPname.SPversion.spd, by convention: Java Endpoint Software Package Editor -> File -> Save as and save the package, selecting .spd as the suffix (or extension). The wexpspo command, which allows for exporting content of a software package to either a file or standard out. Tivoli Desktop -> SP profile, right-click Export. The wgetspat command extracts the attributes of the SP object, which may be quite useful in debugging a problem. Some of the relevant attributes to review for diagnosing a problem are the settings for: stop_on_error Specifies whether to stop (fail) a distribution to an endpoint when any error (fatal or non-fatal) occurs. backup_fmt Specifies whether and where to back up any files being overwritten by the files distributed in the software package. list_path Specifies where to write a list of files distributed to an endpoint. prog_env Sets the environment for the configuration programs on an endpoint. (This keyword applies to UNIX and Windows NT/2000 platforms only.) log_file Specifies the file to which log information is written. log_host Specifies the machine on which the logfile resides.
246
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Important: Setting the trace level using swdist.ini works only for endpoints. You can use the command, wswdcfg, to set trace information on the Software Distribution servers and managed nodes. The syntax follows:
wswdcfg s trace_level= 0, 1, .....6 wswdcfg h hostname
This command is not applicable for endpoints, where swdist.ini should be used. There is also another troubleshooting command: wmsgbrowse. It is used for investigating the Notification Manager queue (browse the message queue, filter it, find undelivered messages, etc.) in order to understand the problem. For details on both of these troubleshooting commands please refer to the IBM Tivoli Configuration Manager Reference Manual for Software Distribution Version 4.2.2, SC23-4712. The trace level by default is zero (as seen in Example 7-1) or none, which really indicates no tracing or that tracing is, in effect, disabled. The new trace level takes effect on the next distribution or execution.
Example 7-1 swdis.ini [#SERVER] product_dir=/usr/local/Tivoli/bin/swdis working_dir=/usr/local/Tivoli/bin/swdis/work backup_dir=/usr/local/Tivoli/bin/swdis/backup trace_level=0 trace_size=1000000
247
report_threads_limit=10 inventory_rim_name=inv_query autopack_dir=/usr/local/Tivoli/bin/swdis/autopack staging_dir=usr/local/Tivoli/bin/swdis/service user_file_variables=/usr/local/Tivoli/bin/swdis/swdis.var import_libraries=spd,libscimp [aix-tmr01b] product_dir=/opt/Tivoli/swdis/1 working_dir=/opt/Tivoli/swdis/1/work backup_dir=/opt/Tivoli/swdis/1/backup trace_level=0 trace_size=1000000 send_timeout=300 autopack_dir=/opt/Tivoli/swdis/1/autopack staging_dir=opt/Tivoli/swdis/1/service user_file_variables=/opt/Tivoli/swdis/1/swdis.var import_libraries=spd,libecimp inventory_scan_file=/opt/Tivoli/lcf/inv/SCANNER/sd_scan.nfo
There is no maximum size of each trace file; the default size per type is 1,000,000 bytes. When the trace_size specified is reached, the first trace file is overwritten. For example, the trace files can be written from spo1.trc up to spo9.trc (sp01.trc, sp02.trc, etc.), and if the specified maximum size is reached and sp09 gets full, sp01.trc is overwritten (unless the trace_style keyword is activated). The trace file depends on the machine role for the installed component. The trace files themselves are created initially, with trace_level = 0, zero byte, until the trace_level is increased. Example 7-2 shows the swdist.ini file with the trace level set to 5.
Example 7-2 Listing in swdis.ini on endpoint C:\WINNT>type swdis.ini |more [3B-053] speditor_dir=C:\Tivoli\swdis\1\speditor product_dir=C:\Tivoli\swdis\1 working_dir=C:\Tivoli\swdis\1\work backup_dir=C:\Tivoli\swdis\1\backup profile_dir=C:\Tivoli\swdis\1\work\profiles trace_level=5 trace_size=1000000 send_timeout=300 autopack_dir=C:\Tivoli\swdis\1\autopack staging_dir=Tivoli\swdis\1\service user_file_variables=C:\Tivoli\swdis\1\swdis.var inventory_scan_file=C:\Tivoli\lcf\inv\SCANNER\sd_scan.nfo [#MOBILE]
248
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
speditor_dir=C:\Tivoli\swdis\1\speditor product_dir=C:\Tivoli\swdis\1 working_dir=C:\Tivoli\swdis\1\work backup_dir=C:\Tivoli\swdis\1\backup profile_dir=C:\Tivoli\swdis\1\work\profiles trace_level=5 trace_size=1000000 send_timeout=300 autopack_dir=C:\Tivoli\swdis\1\autopack staging_dir=Tivoli\swdis\1\service user_file_variables=C:\Tivoli\swdis\1\swdis.var inventory_scan_file=C:\Tivoli\lcf\inv\SCANNER\sd_scan.nfo
It may be worthwhile to erase any existing trace files to ensure a good capture for recreation or diagnosis. Software Distribution trace levels 0: None (default) 1: Fatal 2; Error 3: Warning 4: Information 5: Verbose 6: On L3/Development request only [F]: Fatal Failure [E]: Error [W]: Warning [I]: Information
Here is a summary of the logfiles at the different locations. Server (spo_core.exe) tmesdis*.trc CLI spo*.trc Import/export Requests to source host
249
mdist*.trc MDist2 interfaces Endpoint/PrepSite (spd_eng.exe) tmesdis*.trc CLI spde*.trc Build (prep.site) Execution
The DataMovingRequestxxx.log
The DataMovingRequestsXXX.log is located under the working_dir designation in the swdis.ini file on the TMR server; for example, on an AIX TMR server under the path /usr/local/Tivoli/bin/swdis/work/. The logfile records information regarding Data Movement operations and distributions.
250
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
251
Trace information about the pristine installation when it is part of a reference model or an activity plan is included in the trace files associated with the Change Manager and Activity Planner.
Install Remove
Prepared Committed
Changing
In Error
Discovered Hidden -
The statuses are: Pos 1 - Operation Pos 2 - State Pos 3 - Undo state Indicates the last operation that was performed on the software package, either I (install) or R (remove). Indicates the state of the software package, either P (prepared) or C (committed). If the SP is in an undo state, there will be a letter in the third position of the five-character sequence, which can be P (prepared), U (undoable), or R (restored), or otherwise a dash (-) if undo state does not apply.
252
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
A B indicates a reboot was requested. A dash (-) indicates a reboot was not requested. An E indicates the software package is in error and may not work properly. Install has been committed and can be undone. Install has been prepared and will be committed during the next reboot. Remove has been committed but can be undone. Install has been committed, but the SP is in error (the application may not work properly). The software package has been added with use of the wdsetsps command. The software package has been superseded by a versionable package installed in undoable mode.
In summary, the overall state of a software package is represented by a sequence of five letters.
APMain
253
254
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
[APMEDITOR] trace_level=0 working_dir=C:\Tivoli\bin\w32-ix86\..\w32-ix86\..\apm trace_size=1000000 plugin_download=enabled [MONITOR] enable_auto_update=true auto_update_interval=180 trace_level=0 working_dir=C:\Tivoli\bin\w32-ix86\..\w32-ix86\..\apm trace_size=1000000 plugin_download=enabled
Tip: A new command, wtrcapm, can be used to change or view the current log and trace settings for the activity plan engine components. For example, the following changes the value of trace_level key in the [HANDLER] session in apm.ini file to 3.
wtrcapm H s trace_level=3
/tmp/
$SystemDrive\
Example 7-4 on page 256 shows the APM logfiles on our UNIX TMR server.
255
Example 7-4 APM logfiles eastham> pwd /tmp eastham> ls -al ap*.* -rw------1 root -rw-r--r-1 root -rw-r--r-1 root -rw-r--r-1 root -rw-r--r-1 root eastham>
07 01 06 01 06
The logs are: APM general log: apmlog Records operational level messages for APM, including plan submission and completion. It is created by default. AP Monitor log: apmon.log Specific for the Activity Planner GUI. AP Editor log: apmed.log Contains log information specific to the AP Editor. APM internal log: apm.log Contains all information related to the APM_core functionality. It records all APM calls made to its IDL interface. It also records all the JVM initialization and completion messages. It is not generated by default. To generate and record to the APM internal log, apm.log, an APM environment variable, __APM_DEBUG__, must be enabled through the use of the Framework command odadmin environ set, or by setting a system environment variable. An example on usage of the odadmin environ get / odadmin environ set command follows (Example 7-5) to enable the APM environment variable, __APM_DEBUG__.
Example 7-5 odadmin environ example eastham> eastham> eastham> eastham> 15382 26368 28916 odadmin environ get >/tmp/environ echo __APM_DEBUG__=1>>/tmp/environ odadmin environ set </tmp/environ ps -e | grep -i APM - 0:09 APM_core - 0:00 apmmonl - 0:00 apmmonl
30234
- 0:00 apmeditl
256
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
512 512 1000042 259 1000004 1000083 2635 1000021 5187 1000071 34647 292027 100024 416 84063 170
Mar Feb Feb Mar Feb Mar Mar Mar Mar Feb Mar Mar Feb Mar Feb Mar
07 05 27 07 27 04 07 05 07 05 07 07 10 07 01 06
06:00 14:57 16:35 06:05 16:33 15:03 06:00 16:43 06:00 13:16 06:00 06:00 19:00 06:00 12:25 21:01
. .. APDefault0.trc APDefault1.trc APDefault2.trc APExecuter0.tr APExecuter1.tr APMCli0.trc APMCli1.trc APMHandler0.tr APMHandler1.tr APMMain0.trc apmlog0 apmlog1 logs.tar.Z repqueue.dat
The files are: APDefault0.trc Contains all trace messages related to threads not tracked in the other files. It is considered a general trace file. Reports all traces associated with the executer thread that manage the operations submitted at the Task Library and SWD plug-ins. Contains all the traces associated with the APMHandler thread. Records the main thread traces, which involves initialization of APM, starting of the executer, and the APMHandler.
APExecuter.trc
APHandler.trc APMain.trc
257
Contains the traces related to the CLI execution. This trace file records traces associated with the use of the Activity Plan Monitor. This trace file records traces associated with the use of the Activity Plan Editor.
258
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Table 7-4 Location of CCM configuration file File name confccm.xml confccm.xml Operating system UNIX NT/W2000 Path /etc/Tivoli/ $SystemDrive\WINNT\
The CM configuration file is organized in stanzas that define CM implements such as elements, dependencies, and security. The CM configuration file can be customized to add new Java classes to change the current implementation, in such a case where the user decides to add new elements different from those currently supported. The confccm.xml configuration file can be customized to set the debug level for the CM traces. All log and trace files are created on the TMR server.
259
Creation of a reference model Import of a reference model Export of a reference model Preview operation
It is located on the TMR server and those managed nodes where the CM GUI is installed. It is located under $(working_dir). ccm_apm*.trc The ccm_apm*.trc trace file contains all the actions performed by CCM_core when other applications, such as APM, SD WEB UI, and Pristine, interact with CM. All of the traces tracked by the Java code executed by the APM Java Virtual Machine are reported in this file. Examples of what is recorded include: Submit operations for APM CM answer to a WEB UI request CM synchronization operation for pristine machines The ccm_apm*.trc trace file is located only on the TMR server. ccm_webxxx.trc Contains the history of all operations performed by the Change Manager engine when interacting with the new WEB UI 4.2.2 on the Application Server. ccm_clixxx.trc Contains the history of all the operations performed using the CM command line as well as the operations performed when Change Manager interacts with the Activity Planner to download the plug-in information. You can set the trace level to determine the level of detail recorded for each operation. The trace file is only created if the trace_level keyword is set to greater than zero (default is zero). Trace values are as follows: 0 (none) 1 (fatal) 2 (error) 3 (warning) 4 (information) 5 (verbose)
You can set the trace level using the wtrcccm command. Alternatively, you can use the Change Manager GUI and press the F2 key. When you press the F2 key, the Update trace dialog box displays, and you can enter a new value in the New trace level text box. Also, trace_size determines the maximum number of records that can be written to the file (default is 1000000).
260
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
261
Depending on the situation, your support representative may request turning on tracing for the other components. If the servlets are not running, start them to put the new trace settings into effect. If the servlets are running, do one of the following to put the new trace setting into effect without restarting the servlets: On any Tivoli Web Gateway (TWG) machine, perform the following:
server -app dmserver -trace set -host dmserver_hostname
The output files of the tracing are DMS_stdout.log, DMS_stderr.log, and DMSMsg1.log, which are located in the app_server_dir/log directory. The default for the Windows installation is C:\WebSphere\AppServer\log. You should also provide the ApiServlet.log in the /tmp directory to your support representative.
262
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Unable to publish Web objects. Before publishing any Web objects, you must make sure the following are up and running: Gateways servicing the endpoints, which have Web Gateway components installed Endpoints on the Web Gateway Servers Primary and secondary Web Gateway Servers DB2 server DB2 client Web Server WebSphere Application Server Access Manager WebSEAL server Check the logfile DMS_stdout.log and make sure that the log has the following entry, which indicates that the Web Gateway Server has started successfully: WSVR0023I: Server DMS_AppServer open for e-business. An insufficient authorization error when using the wweb command normally indicates that the Tivoli Administrator does not have the WebUI_Admin role. A Profile not found error when running wweb under Windows could be due to an extra caret (^) missing when specifying the profile name. For example, the profile mysoftware^1.0 needs to be specified as @mysoftware^^1.0 when running wweb under Windows. A general oserv error could indicate a problem with the gateway that services the endpoint that has the Web Gateway component installed. Restart the gateway with the wgateway command and test again. The wweb command completed with a distribution ID when publishing a software package but does not show up on the Web Interface. Check the file package_name.log in the ../swdis/work directory of the Tivoli Server for the results of the publishing of the software package. The users file in ../swdis/work should contain the list of the users that the Web objects are published for. On the endpoint where the Web Gateway Server is located, the outcome of the publishing of the software packages is recorded in the file called results located in the ..\swdis\1\ directory. Check this file for any error messages. The file called users contains the list of users that have access to the published Web objects. Enable the tracing and review the DMS_stdout.log for errors. You may have to enable more components for tracing depending on the situation. Publishing to
263
an invalid user ID will fail and the log should reflect that. Refer to 7.8.2, Tracing the Web User Interface on page 265, for enabling tracing. Memory usage is increasing dramatically over time, causing the Tivoli Web Gateway application server to fail. Disable JIT for the Java Virtual Machine to circumvent this behavior. Note: JIT stands for just-in-time compiler. It is a code generator that converts Java bytecode into machine language instructions. If that will not solve the problem, check if you are running too many inventory jobs, since running a lot of inventory jobs on Red Hat Linux or Microsoft Windows platforms might increase memory usage dramatically, Problems with software package installation: Error in downloading attachment in the Operations Console. This error is not seen in the software_package.log. The Web Gateway Server could be down or the host name of the Web Gateway Server cannot be resolved. Make sure that you can resolve both the short and FQDN of the Web Gateway Server and perform the install again. DISSE0082E Error decoding software package object. It could be corrupted, or not a valid object. This error can be seen in both the Operations Console and in the software_package.log located on the Tivoli Server in the ../swdis/work directory. You will encounter this corrupt file error if you have used an IP address instead of the host name of the WebSEAL server in the URL to get to the Web Interface. Make sure the host name and short name of both the WebSEAL server and Web Gateway Server can be resolved. Use the host name of the WebSEAL server in the URL for the WEB UI Interface, log in again, and redo the install of the software package. In the dynamic resource group of the type User, the Query Selection group box on the Resource Group Members dialog is grayed out. Run the update_trm_query.sh script on the Tivoli server. Problems with the inventory scan. Inventory scan completed successfully but not data in the RDBMS database. Check the mcollect.log on the gateways and the trace file for the TWG-MCollect. Refer to 7.10, Troubleshooting Inventory on page 266, on Inventory mcollect to debug the failed collection.
264
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The traces (*.trc) are located on the TMR server (by default) in the $product_dir directory, which is specified in the [#SERVER] section of the swdis.ini file. The swdis.ini is located on C:/WINNT for the Windows Tivoli Server and /etc/Tivoli for the UNIX TMR server. In the $product_dir, the spo*.trc and spde*.trc should have traces of the publishing of software packages to TWG. The swdmgr*.trc should have the results of the publishing.
265
The swd traces directory can be changed using the product_dir parameter.
wswdcfg -s product_dir=trace_dir
The trace files are written to $DBDIR on the TMR server. DirQueryCli0 contains the CLI trace, and DirQueryEngine0.trc contains the engine trace. Sometimes the problem is a port issue. For Directory Integration, the communication takes place through a socket listening on port 9090. If this port is reserved for other applications, we suggest that you change it, setting the variable DQ_PORT to a different value. The command to use is again:
odadmin environ get/set
266
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Table 7-7 contains a summary of the logfiles we will be discussing in this chapter.
Table 7-7 Log file information Component Path Log file name lcfd.log Default log level 1 Debug level 3
Endpoint Upcall and downcall information Endpoint scan engine Inventory profile information Endpoint scan engine Scan data
$LCFDIR/dat/1.
From directory where the wepscan command was run. Created by wepscan -d command. From directory where the wepscan command was run. Created by wepscan -d command. From directory where the wepscan command was run. Created by wepscan -d command. $LCGFDIR\inv\Scan. $DBDIR.
sa_config.log
N/A
sa_results.lo g
N/A
INV_SA.LOG
N/A
Hardware scan library Debug information Gateway Upcall and downcall information RIM object SQLstatements and DB return codes Data Handler Debug information Collector Debug information
libInvHW.log gatelog
N/A 3
N/A 6
N/A
INFO|ER ROR 3 3
1 1
267
Component
Path
Debug level 3
Endpoint Upcall and downcall information Endpoint scan engine Inventory profile information Endpoint scan engine Scan data
$LCFDIR/dat/1.
From directory where the wepscan command was run. Created by wepscan -d command. From directory where the wepscan command was run. Created by wepscan -d command. From directory where the wepscan command was run. Created by wepscan -d command. $LCGFDIR\inv\Scan. $DBDIR.
sa_config.log
N/A
sa_results.lo g
N/A
INV_SA.LOG
N/A
Hardware scan library Debug information Gateway Upcall and downcall information RIM object SQLstatements and DB return codes Inventory GUI log information
libInvHW.log gatelog
N/A 3
N/A 6
$RIM_DB_LOG Created by wrimtrace. Unix: $DBDIR directory. PC Systems: $DSWIN directory. Note: You need to open the inv_gui.sh file in a text editor on the system on which you are using the GUI, This file is located in $BINDIR/TME/INVENTORY. Change the DEBUG variable to 2 from 0. No files are generated by deafult value, which is 0.
N/A
INFO|ER ROR 2
268
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
make by the gateway to the endpoint. Depending on the type of problem you are troubleshooting, you may elect to only have certain traces enabled. For the purpose of this exercise we will enable all the traces.
269
270
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
5. Kill all RIM_vendor_Agent processes that are running on the RIM host managed node, as shown in Example 7-11.
Example 7-11 Killing the RIM agent process ntprocinfo|grep -i agent 1980 RIM_Oracle_Agent WIN-INV01A\tmersrvd ntprocinfo -k 1980 08/06/2002 10:02:09
RIM tracing is now enabled and will be tracing all invdh_1 RIM object calls. Notes: The RIM log can grow and fill up disk space very quickly at INFORMATION:ERROR. Be sure to set it back to no tracing when you are done tracing by running the following command:
wrimtrace invdh_1 "TRACE_OFF"
To troubleshoot RIM connection problems, the RIM_vendor_Agent can be started manually. On Unix, however, DB2 and Informix RDBMS systems require setting the shared library path first.
271
INV_SA.LOG: Contains debugging information. It is identical to the logfile that is created using the wdistinv command and inv_ep_debug keyword. If you used the -s option, this logfile is sent to the Inventory Data Handler. You can also create these logfiles by creating an environment variable on your system named WEPSCAN_DEBUG. Set this environment variable to a value of 1, 2, or 3. These values correspond to the options you specify with the -d option. When using the -d option, the libInvHW.log is created. This file contains more detailed debug information of the Hardware Scan Library. It is very useful when troubleshooting hardware scan related problems. At this point in time there is no similar logfile for the software scan library.
272
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Appendix A.
Lab exercises
This appendix provides lab exercises for the related chapters. You need to first download the SG243946.zip, which has the necessary files for these exercises. Refer to Appendix B, Additional material on page 349, for instructions to download this zip file.
273
Introduction
In the these exercises we have used ITCM 4.2.2, but you can also use ITCM 4.2.1 or ITCM 4.2.0 if you prefer. Lab 1 contains installation instructions for getting all the support applications plus ITCM 4.2.2 up and running on a single box. All the other labs can be used as reference during a demo of a self-study guide. The lab setup is two Windows 2000 Server or Professional machines for each group. The machines are called TivoliServer and WindowsTarget. TivoliServer will serve as a Source Host, Tivoli Server, and endpoint; and WindowsTarget will serve as a second target endpoint in the exercises. We will install endpoints on both machines and these endpoints will have the same names as the machines. Most of the IBM Tivoli Configuration Manager 4.2.2 installation will be done on the TivoliServer machine.
274
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
Before you start the exercises, you should make sure you have access to the following software: Framework 4.1.1 Installation CD1 Framework 4.1.1 Installation CD2 ITCM 4.2.2 Installation CD ITCM 4.2.2 Server CD Note: We have used ITCM 4.2.2 for implemening these labs. If you use ITCM 4.2.0, you will not see Figure A-10 on page 286 in the installation of ITCM (since this step was new with ITCM 4.2.1). Other than that, all lab instructions are applicable to ITCM 4.2.0 as well.
Exercise instructions
This exercise should be done after reviewing Chapter 3, Tivoli Configuration Manager fundamentals and installation on page 63.
Preface
DB2 V8.1 has already been installed on your Windows 2000 Server with the following options: DB2 database home: c:\Program Files\SQLLIB Instance owner: db2admin Instance: DB2
275
4. Create five new Windows 2000 user accounts for the default ITCM users: planner, invtiv, mdstatus, pristine, and tivoli. Make all users part of the Administrators group and give them tivoli as password. To create a user, select Start Programs Administrative Tools Active Directory Users and Computers. Note: If you are using Windows 2000 Professional, use the link Start Settings Control Panel and then select Users and Passwords. 5. Now it is time to start the integrated installation. Use the Windows Explorer to go to the <ITCM images>\CD5\ directory of the ITCM code installation directory. Double-click setup.exe. This will start the InstallShield wizard installation. 6. Select English as installation language. Click OK.
276
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
7. Click Next on the installation welcome screen. 8. Accept the license and click Next again.
277
278
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
10.Select Custom installation. 11.A Typical installation will install all ITCM components but not configure Directory Query. If you choose the Custom option, it is possible to select what parts to install and to provide some configuration options. You also have the option to configure the Directory Query component. 12.In a Typical installation, one common database, cm_db, will be created for all components. In a Custom installation, you have the option to create separate databases, but in our installation we will create only one database, which is cm_db. 13.Click Next.
279
14.Select the components to install. Use the default of all selected. Click Next. 15.Click Next for Additional Languages. Do not specify any additional languages. Note: Your instructor has probably not added the Language CD for ITCM, so you will not be able to add additional languages. 16.In a Typical installation the installer will run all SQL scripts to create the table spaces, all tables, and views. When you run the custom installation you have the option to defer the execution of the scripts. Maybe your database administrator wants to create custom table spaces in different locations with different sizes.
280
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
We created the table spaces in step 3. Now we only want to run the schema scripts. Select the option to Run schema scripts only. 17.Click Next.
281
Next, you will get a number of windows, one for each RIM object, where you specify the information needed for RIM to connect to the RDMBS. For all these windows, perform the following changes: a. Change the database name to cm_db. b. Enter the RIM password as tivoli. Leave the rest as default. 18.Click Next.
282
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
19.For tivapm use the password tivoli. Click Next. 20.Fill in the rest of the RIM Information (similar to step 17). 21.For Enterprise Directory Query Facility, do not configure anything. Click Next.
283
22.Review the installation settings. Click Next to start the copy process.
284
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
During this process, you will have to specify the location of the software. Ask your instructor for this location. Select Verify local depot and enter the location of the images (ask your instructor for this location). Note: If you receive a message window saying that the Integrated Installation program could not locate a program, specify the correct directory that has the .IND file for that component.
285
23.Select Run All in the following Installation Step window. Note that this window gives you a last chance before the installation to change the selected components to install. You would not get this window if you had selected the Typical installation instead of Custom.
286
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
After completion of the installation, the Tivoli Management Framework system will ask you to reboot the machine. 24.Click Finish to reboot the machine.
287
Installation will continue from where it was, after the reboot. 25.Click Run All to continue to install. If any of these steps fails installation will stop and that particular step will get Error status. You can check the errors by clicking that line with the right mouse button and going to Properties.
288
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
If you receive an error while the system is registering plug-ins for Activity Planner, right-click the Windows desktop and select New Shortcut. Fill in cmd /k%systemroot%\system32\drivers\etc\tivoli\setup_env.cmd for the shortcut and name it Tivoli CLI. 26.Double-click the new shortcut. You should see the message Tivoli environment variables configured. 27.Open a command window and set the Tivoli environment and type the following commands;
bash wstopapm -f bash wstartapm
28.After APM starts, right-click the line where you get an error, and set the status to Ready and click Run All again.
289
29.When all components have been installed successfully, click Finish. 30.Double-click the new shortcut. You should see the message Tivoli environment variables configured. 31.Type the following Tivoli command:
odadmin odlist
35.Cancel out of the session by typing x. 36.Verify the installed Tivoli products and patches using the wlsinst command:
wlsinst ah
290
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Exercise review/wrap-up
In this exercise, you have learned how to install a Tivoli Server and all the required ITCM components using the new integrated installation method.
291
Introduction
The Integrated Desktop installation can be used to install the Tivoli Desktop and all the ITCM administrative GUIs. You can only run this on Windows NT and 2000 systems.
Required materials
For this exercise, you need access to ITCM Desktop for NT Version 4.2.2 CD.
Exercise instructions
This exercise should be done after reviewing Chapter 3, Tivoli Configuration Manager fundamentals and installation on page 63.
Preface
All exercises of this chapter depend on the availability of specific equipment in your classroom.
292
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
6. Click Yes for the default destination directory and click Next. 7. When you receive the following window, click Finish to finish the installation.
293
8. Test the desktop. Log into your TivoliServer as the Administrator user. 9. Start the MDist2 GUI from the Tivoli Desktop. Have a look at the "c:\Program Files\Tivoli\Desktop" directory. Where is the CMD file to launch the Inventory GUI located?
294
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
2. Reboot the NT machine when you finish. 3. Also install the endpoint on the Windows Target machine, with the same settings. Note that endpoint names are same as the machine names.
Exercise review/wrap-up
In this exercise, we have covered the new method to install the Tivoli Desktop and the Tivoli administrative GUIs. We also installed endpoints on our lab machines.
295
Required materials
None.
Exercise instructions
This exercise should be done after reviewing Chapter 4, Inventory and Software Distribution components on page 93.
296
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
5. Open the new policy region and create a new dataless ProfileManager named pm.itcm.inv.hw.
297
6. Open the new ProfileManager and subscribe all your Tivoli endpoints to the new ProfileManager. To do so, right-click the ProfileManager, select Subscribers, and move the endpoints to the Current Subscribers window. 7. Create a new InventoryConfig profile. Select Create Profile from the profile manager menu and select the InventoryConfig resource. Name the profile ic.hw. 8. Right-click the new profile and select Properties. The Inventory Configuration Java GUI will start. Customize the profile as follows: a. For PC and UNIX, deselect Software scanning. b. Check the hardware configuration. Click Configure.
9. We do not want to collect IPX and USB Device information, so deselect them. Leave all other options at the default. 10.Click OK to close the Inventory Configuration window.
298
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
2. Select Advanced Options Timeout Settings from the top menu. 3. Note that you can enable Wake on LAN from the profile in Inventory. Close the Timeout Settings window. 4. Select all your endpoints and distribute the profile. 5. Check the distribution status from the command line:
wmdist -al wgetscanstat -a
6. Check the data that was collected. Run the Queries from the installed query library. Open the default policy region: <Tivoli server>-region.
7. Open the INVENTORY_QUERY query library and execute some of the new queries to find out what data is collected.
299
300
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
301
LAB 4. Create an Inventory profile and run and cancel the software scan
In this section we discuss the creation of an Inventory profile and run and cancel the software scan.
Required materials
None.
Exercise instructions
This exercise should be done after reviewing Chapter 4, Inventory and Software Distribution components on page 93.
302
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
For PC software, select to run a file scan. Configure the scan options as shown in Figure A-24. 6. Disable all hardware scans. 7. For PC software, select to run a file scan. Configure the Scan options as shown in Figure A-24.
8. Also customize the profile to scan for .exe and .com files in the Program Files directory only. 9. Close the profile.
303
Example: A-1 Example ic.sw 1709687078.3 # wgetscanstat -a Scan ID: Distribution ID: Profile name: Start time: Elapsed time: Clients completed: Clients pending: 1 0( 0%) 0( 0%) 0( 0%)
5. Now cancel the scan. (you can also use wcancelscan -i scan_id to cancel a separate scan):
# wcancelscan a
6. Start to cancel Inventory profile ic.sw with scan ID 4. 7. The cancel operation sent to Inventory status collector is complete. 8. The cancel operation sent to MDistII manager is complete. 9. The cancel operation sent to Scalable Collection Service is complete. 10.The cancel operation sent to Inventory data handler is complete. 11.Verify that the collection has been cancelled:
# wgetscanstat -a
12.No scans using the Inventory status collector are in progress. 13.Verify that no software data has been received into the repository. 14.Run the NATIVE_SWARE_QUERY from the INVENTORY_QUERIES QueryLibrary. 15.Now distribute the Profile again. Do not cancel the scan, and verify that data was collected by running the NATIVE_SWARE_QUERY and INVENTORY_SWARE query.
304
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
None.
Exercise instructions
This exercise should be done after reviewing Chapter 4, Inventory and Software Distribution components on page 93.
Create a query
To create a query: 1. Create a custom named High_Memory in the Custom Queries query library. Select Create Query from the menu. 2. Enter High_Memory in the name field. 3. For the repository, select inv_query.
305
4. Click the ellipses () next to the Table/View Name field and select the INVENTORYDATA view. 5. Move the TME_OBJECT_ID and TME_OBJECT_LABEL from the Available Columns to Chosen Columns. 6. Click the ellipses () to the right of the Column Name field in the Where Clause panel. 7. Select the PHYSICAL TOTAL_KB column name, and then click the Close button. 8. Select >= from the drop-down menu next to the Column Value field in the Where Clause panel. 9. In the Column Value field, enter 131102 for 128 MB memory (128 * 1024). 10.Click Add. 11.Select only the Windows machines for this query, such as OS_TYPE = Microsoft 2000. (Tip: This step is similar to the previous step where you have selected the where clause for PHYSICAL TOTAL_KB.) Ask your instructor if you need help. 12.When you finish, click Create & Close. 13.Run the query and see if your workstations are listed.
306
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
For this exercise you need to access to: ITCM Desktop installation CD (CD 3) Redbooks directory of the SG243946.zip NTprocinfo directory of the SG243946.zip
Exercise instructions
This exercise should be done after reviewing Chapter 4, Inventory and Software Distribution components on page 93.
307
The InstallShield wizard will start. Follow the installation process, make sure you select the English language, accept the license agreement, and select the Software Package Editor component to be installed. (All the other components were already installed.) After the installation finishes, you will have two new icons on your Windows desktop, one to launch the Software Package Editor GUI and one icon to launch a CMD where the Software Distribution environment is source (allowing the use of the SWD CLI).
308
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
6. Click the Advanced button. Check Descend Directories to include all files in the C:\LabFiles\Redbooks directory. Leave Create Directories checked. 7. Click OK for both windows. 8. Select Edit Properties. 9. Click Condition to add the following package installation condition: Choose os_name from the variable list and set the following Condition to install the package: os_type == 'Windows 2000'. 10.Click OK for both windows. 11.Save the package as both a software package and a software package block. 12.Choose File Save As and type C:\SWPKGs\Redbooks.sp and C:\SWPKGs\Redbooks.spd. Be sure to change the bottom pull-down menu to indicate either sp or spb when saving to a particular software package type.
309
3. List the software packages installed on the machine and confirm that Redbooks.spb is listed. 4. Confirm that PDF files have been added to the c:\SWPKGs directory.
310
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
311
The second way is to check the Distribution Status icon on the Tivoli Desktop or by using wmdistgui from the command line. Select By Distribution Name and choose Redbooks^1.0.
312
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
The third method is to use the Verify feature. From the Tivoli Desktop, right-click the Redbooks^1.0 profile and select Verify. Click Verify and Close. If the verify operation finds an error, it puts the status of the package in the error state of Installed-Committed-Error (IC..E); to see if it is successful, use the wdlssp command. You need to launch the Software Distribution environment (SWDIS ENV) first with the command. Example A-3 is a sample.
Example: A-3 IC state ---------------------------------------DISSE0164I Name : Redbooks DISSE0165I Version : 1.0 DISSE0166I State : IC------------------------------------------
313
5. Select Force in the checks section. You need to force the installation, since the software package state is IC. 6. Choose your Windows Endpoint as the target of the distribution. 7. Click Install and Close. 8. Check that the state of the software package is IP (Installed-Prepared) using the CM_STATUS_QUERY query. Note: This could also be achieved using the wdlssp command. 9. To run the query open up the CM_STATUS_QUERY from the INVENTORY_QUERY query library and run the query as shown in Figure A-28.
10.You should see the status of the Redbooks^1.0 software package as IP.
314
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
11.Go to the SDLABs profile manager again and right-click Redbooks^1.0. 12.Commit the installation by selecting Commit. 13.Confirm that the state of the package is now IC and the files have moved to the SWPKGs directory. Note: Alternatively, you could achieve the same results from the CLI with:
wrunquery CM_STATUS_QUERY
315
Undo an installation
Now we will undo the installation of Redbooks^1.0. 1. Right-click the Redbooks^1.0 profile. 2. Right-click the Redbooks^1.0 profile and select Install. 3. Select Force. 4. Select your Windows Endpoint as the target. 5. Under the Advanced Options (on the top), select Operation Modes. 6. Select Yes under the Undoable section. 7. Click Set & Close. 8. Click Install and Close. 9. Check that the state of the software package is ICU (Installed-Committed-Undoable). 10.Right-click the Redbooks^1.0 profile and select Accept to accept the distribution. 11.Check that the state of the software package is IC (Installed-Committed).
316
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
317
5. Click OK to save and return to the add directory dialog. Click OK. 6. Next we will add an object to create a shortcut to the NTproclist application on the Windows desktop. From the package drop-down menu select Insert Add Object Windows shell folder. 7. In the Location field, click the right mouse button and then select all_users_shell_desktop from the list. Click OK to place a link on the Windows desktop.
318
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
8. Click OK to save. 9. From the Windows Shell folder drop-down menu, select Insert Link. Customize as follows: Display name: NTprocinfo Command: C:\ntprocinfo.exe 10.Click Advanced. Customize as follows: Working directory: c:\temp Icon location: $(system_drive)\LabFiles\NTprocinfo\awt.ico 11.Now we will add a key that contains the version of the Ntprocinfo application to the Windows registry. 12.From the package drop-down menu, select Add Object Windows registry. Customize as follows: Hive: HKEY_LOCAL_MACHNE Parent key: SOFTWARE Key: NTprocinfo Class: Blank
13.Click OK.
319
14.From the above Windows registry drop-down menu, select Insert value. Customize as follows: Name: Version Data: 1.0 15.Finally, we will add an entry to the c:\Winnt\Tivoli\lcf\1\lcf_env.cmd file. In order to do this, we must first define a Text File object in our package. Again, right-click the NTprocinfo package and select Insert Add Object Text File. Fill in c:\Winnt\Tivoli\lcf\1\lcf_env.cmd. 16.Right-click the new file object, select Insert Line, and input the following values: Text: REM: Ntprocinfo is running on this system Position: End 17.Now we will save the package as a software package. From the File menu select Save as and select the directory c:\SWPKGs. File name: ntprocinfo File of Type: Software Package Block (sp) 18.Click Save. Now we will install the software package on our second Windows Endpoint. 1. Open the Tivoli Desktop as Administrator. 2. Open the pr.itcm.swd policy region. Create a dataless ProfileManager called pm.swd.NTprocinfo and subscribe your Windows Endpoint (non-MN machine). 3. From the Profile Manager, create a software package called Ntprocinfo^1.0. 4. From the software profile drop-down menu, select Import. 5. On the Import panel, choose the Endpoint Machine and then type your Endpoint name. Click . to browse the file at the location C:\SWPKGs\Ntprocinfo.spb. 6. Enter the source host name <Your_Tivoli_server>. 7. Click Import & Close. 8. Install the software package on your other Windows Endpoint. Right-click and select Install. Accept all the default values and select your other Windows Endpoint as a target. 9. Look at the distribution log ${BINDIR}/../swdis/work/NTprocinfo.1.0.log on your Tivoli Server to verify the distribution. You should see an icon on your desktop called Ntprocinfo. (It is a small program used to browse Windows processes.)
320
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
The images are located in the Winzip directory of the SG243946.zip.
Exercise instructions
This exercise should be done after rewiewing Chapter 4, Inventory and Software Distribution components on page 93.
Creating an AutoPack
On your Tivoli Server, start the Software Package Editor by double-clicking the Software Package Editor icon on the desktop. 1. Select AutoPack Technology and click OK. 2. Click Next to start the AutoPack Guided Process. 3. Under General Options, be sure to monitor the C: drive. 4. Explore the other options, but leave the defaults. 5. Start the first snapshot. 6. Next, install Winzip by launching c:\LabFiles\winzip80.exe. Install the application in c:\winzip. Complete the installation (select express setup). 7. Start the second snapshot from the AutoPack Guided Process. 8. When AutoPack Guided Process creates the package, change the name to Winzip and the Version to 8.0. 9. Have a look at the software package and delete any unwanted objects. Make sure you understand the meaning of each object in the package.
321
10.Before saving the software package specify a log file on the target machine. Select Edit Properties Logfile c:\logs. 11.Save the package as Software Package Block in c:\spb. 12.Now create a new software package for the WinZip application and install it on your other Windows Endpoint. Create a new ProfileManager (pm.swd.winzip). Create an empty software package (winzip^8.0). 13.Import the SPB. Subscribe your Windows Endpoint. 14.Install the winzip^8.0 software package. 15.Verify that WinZip was correctly installed (by using the MDist 2 GUI, log file, or the wmdist command).
322
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
None.
Exercise instructions
This exercise should be done after rewiewing Chapter 4, Inventory and Software Distribution components on page 93. 1. Bring up the Tivoli Desktop as Administrator and open the default policy region (hostname-region). 2. Open the INVENTORY_QUERY QueryLibrary. 3. Right-click the CM_STATUS_QUERY query and select Run Query. 4. Verify the status of the Redbooks application on your Windows Target. The status should be IC---- (Installed Committed). 5. Alternatively, you could achieve the same results from the CLI by running:
wrunquery CM_STATUS_QUERY
323
Required materials
None.
Introduction
In this exercise, we will first check the RIM object and RDBMS schema needed for the Activity Planner. Next, we will assign the necessary roles to our Tivoli Administrator, allowing him to use all AP functionality. We will also verify the AP Administrator settings. Before creating an activity plan, we will register the AP plug-ins. In the first activity plan, we will use an Inventory Scan for one of the activities.
Exercise instructions
This exercise should be done after rewiewing Chapter 5, Deployment Services on page 155.
324
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
as Administrator user. Verify whether a RIM object for AP already exists by running:
wlookup -ar RIM
The name of the RIM object for APM should be planner. If it does not exist, use the wcrtrim command to create a new RIM object named planner. Ask your instructor for the correct RIM settings of your DB2 installation. 1. Verify the correct functioning of the RIM object using:
wrimtest -l planner
325
4. You should get a message saying that activity plan database is empty.
How many plug-ins are registered? All four plug-ins (TaskLibrary, Inventory, OSElement, and Software Distribution) should be registered. Launch the AP editor GUI on your Tivoli Server:
wapmgui ed
Which activities can you add to a plan? Does this correspond to the registered plug-ins? (It should.) Note that the number of registered plug-ins will depend on the installation order. For example, if Inventory is installed after AP, the Inventory plug-in should be automatically registered.
326
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
5. Click OK again; this will return you to the main AP editor window. Now we will add the first activity. Click the Inventory Task activity icon. Fill in the values shown in Figure A-35 on page 328.
327
6. Then click Properties. Select the ic.hw InventoryConfig profile (click ...).
328
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
7. Explore the different settings, but leave the default values. Return to the main window (click OK twice). 8. Next, we will add the second activity. Click the Software Distribution activity. Name the activity RedbookPDFs. Click Properties. Select the Redbooks^1.0 software package.
329
9. In the Application Options tab, change the Checks option to Force. 10.Select the User Notification Settings tab. Enable the User Notification settings and fill in values of your choice. 11.Next, select the Distribution Options tab. Change the Priority to High. 12.Now add a condition on the RedbookPDFs activity. Right-click the activity and select Condition. Add a condition so that this activity will only start if the InventoryScan activity is complete.
330
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
13.Will the RedbookPDFs activity start if the InventoryScan activity fails on one node and succeeds on the other node? 14.Click OK. Now save the plan as a Template. What is the difference between Template and Draft?
15.Close the AP editor GUI and open the APM monitoring GUI (apmmon.bat file).
331
16.From the APM monitor, select Plans Submit. Submit PlanA with the default settings. 17.Monitor the progress of the plan until it completes.
Exercise review/wrap-up
In this exercise, we have configured the Activity Planner component of ITCM 4.2.2, including the RIM configuration, the RDBMS schema creation, the AP plug-in registration, and assigning the AP authorization roles.
332
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
None.
Introduction
In this exercise, we will first verify the RIM object and RDBMS schema needed for Change Manager. Next, we will assign the necessary roles to our Tivoli Administrator, allowing him to use all CM functionality. Before creating a Reference Model, we will register the CM plug-ins for Inventory and Software Distribution. We will create a Reference Model using an existing Tivoli Endpoint as a template. We will add an Inventory scan to this Reference Model and use the new command line interface of CM to perform a number of operations on this Reference Model.
Exercise instructions
This exercise should be done after rewiewing Chapter 5, Deployment Services on page 155.
333
installation mechanism, the RIM object and the database schema will be created during the installation. If CM was installed using SIS or the "classic" Tivoli installation mechanism, the RIM object and database schema must be created manually. If you have successfully installed the product using ISMP, just read through this exercise and verify the different steps. 1. Log into the Tivoli Server as the Administrator user. Verify whether a RIM object for CM already exists:
wlookup -ar RIM
2. The name of the RIM object for CM should be ccm. If it does not exist, use the wcrtrim command to create a new RIM object named ccm. Ask your instructor for the correct RIM settings of your DB2 installation. 3. Verify the correct functioning of the RIM object using:
wrimtest -l ccm
5. Cancel out of the session using x. 6. Verify that CCM is working correctly:
wlstrmod
7. You should get an error message saying no reference models are in the CM database.
Assigning CM roles
In this step, we will assign the necessary roles to our Tivoli Administrator, allowing him to use all CM functionality. Open the Tivoli Desktop as the Administrator user. Double-click the Administrator collection.
334
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Right-click the Root Administrator and select Edit TMR Roles. Assign all the CCM roles to the Root Administrator, if they are not already assigned. Move the roles to the left and click Change & Close.
2. How many plug-ins are registered? If four plug-ins are registered (InventoryScan, SoftwareDistribution, InventoryData, and OSElement), skip to the next exercise. 3. We want to register at least the following plug-ins for our exercise: InventoryScan and SoftwareDistribution. The plug-ins can be registered using scripts that are located in $BINDIR/TME/CCM/SCRIPTS. 4. Have a look at the scripts reg_swd_plugin.sh and reg_invscan_plugin.sh. Execute both scripts. 5. Again, list the registered plug-ins using:
wccmplugin -l
This time, you should see the InventoryScan and SoftwareDistribution plug-ins.
2. Log in as the Administrator user on the Tivoli Server. 3. Select Edit Create reference model from target. Fill in the settings as shown below. Fill in the name of one of your Windows Endpoints in the Target Name. Using these settings, we will add elements to our reference model for all software that is installed on the target node and Inventory elements for the memory size. Click OK.
335
4. Have a look at the new Reference Model elements. You should see elements similar to the ones in the following figure.
336
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
5. Save the reference model. We will customize the model more in the next step.
337
2. Click OK. Now we will add a child reference model named ACME_sales. Right-click the ACME^1.0 model and select Create reference model. Create a new reference model using the settings shown in Figure A-44 on page 339.
338
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
3. Click OK. Now we will add two elements to the ACME_Sales model. First, we will add an Inventory scan. In the Element section, right-click and select Add Inventory Scan Element.
339
4. Select your InventoryConfig profile named ic.hw. Can you specify distribution options for this profile? (For example, can you specify an expiration date?) 5. Finally, we will set the subscribers for our reference model. Select the Subscribers tab, then right-click and select the Inventory subscriber. 6. Select only Windows 2000 machines, as in the following figure. Note that this is a dynamic subscription; the targets will be resolved at the execution time.
340
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
341
3. CM will create a XML plan. What are the activities contained in the preview XML plan? Is this what you expected? After reviewing the plan, click OK to submit it. 4. Track the status of the submitted plan from the Activity Plan Monitor. You should see it as successful.
342
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
The images are located in the Datamoving directory of the SG243946.zip.
Introduction
In this exercise, we will first explore the Data Moving Service GUI. We will use the GUI to delete a file from a target Tivoli Endpoint. Next, we will use the wspmvdata command to recursively send an entire directory, including all files and subdirectories, from a Tivoli Endpoint to another Tivoli Endpoint. Finally, we will use the new reserved tokens ($(MAX) and $(MIN)) to send a specific file from a source directory to a target machine.
Exercise instructions
This exercise should be done after rewiewing Chapter 4, Inventory and Software Distribution components on page 93.
343
2. If the package is not present, it can be created using the wspmvdata command. The profile should be located in your "main" policy region (<TMR_Server>-region) in a ProfileManager named DataMovingProfile. Open the DataMovingProfile ProfileManager. 3. Subscribe both of your Windows Endpoints to this ProfileManager. 4. Right-click the DataMovingRequests.1 profile and select Delete. 5. The file that has to be deleted is c:\LabFiles\Datamoving\To_Del.txt. 6. Select both of your Windows Endpoints and click Delete & Close. 7. Use the wmdist command or the MDist2 GUI to follow up on the status of the DataMovement operation. 8. Verify that the file was deleted on your target machines.
344
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Required materials
For this exercise, you need to access to Multicast directory of the SG243926.zip.
Introduction
In this exercise, we will configure and use the new Multicast functionality of MDist2. We will compare the performance of a traditional MDist2 distribution with a Multicast distribution. We will first create a simple software package with a size of 50 MB. We will distribute this profile twice to both of our Endpoints. First, we will distribute the software package without Multicast, then we will use Multicast and compare the results. This will allow us to see the advantage of using Multicast.
Exercise instructions
This exercise should be done after rewiewing Chapter 6, Multicast concepts and implementation on page 207.
Preface
This exercise depends on the network configuration of the classroom. If the network does not allow Multicast packets to be sent from one machine to another, this exercise will not work. If all machines are in a single subnet there should be no problem. If, however, your machines are on separate subnets connected through routers, these routers must be Multicast enabled.
345
Note that all the Multicast settings are disabled by default. 1. Enable the endpoint_multicast setting on your Tivoli Server. Use the wmdist command to change this setting to TRUE. You will be asked whether you want to start the Multicast receivers on all the endpoints connected to the Tivoli Server gateway. Specify y to start the Multicast receivers on the Endpoints. Wait until all the Multicast receivers on the Endpoints have been started. 2. Verify that on your Endpoints a new process is running named mcast_receiver. Use the Windows Task Manager to verify this. Also, you can have a look at the lcfd.log file on your Endpoints and verify that the mcast_receiver has started. 3. Now we will have a look at the Multicast settings of our repeater. Use the wmcast command to verify the settings of your Tivoli Server:
wmcast -s <TMR_Server>
4. What is the value of the mcast_advert setting? This is the address that the server will use to advertise Multicast distributions. On your Windows Target or Tivoli Server endpoint, locate the file:
<LCFDAT_DIR>\mcast\mcast_receiver.cfg
5. Open the file using a text editor. What is the value of MCADDR? Does it correspond to the mcast_advert setting in the previous exercise? (It should.) 6. On your Tivoli Server, change the mc_debug_level to 2. Use the wmcast command to do this. (Have a look at the man page if you are not sure how to do this.) After changing the debug level, you have to restart the oserv on the Tivoli Server:
odadmin reexec
7. What is the value of the MDist2 net_load setting on your Tivoli Server? What is the value of the Multicast mc_netload setting on the Tivoli Server. Are they the same? Note: The wmcast command has a (non-documented) setting (-p) that allows you to "Multicast ping" the endpoints connected to a gateway. Check that your Endpoints are "Multicast reachable":
wmcast -p <Tivoli_Server>
8. Finally, have a look at the Multicast log file on the Tivoli Server:
346
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
$DBDIR/mcast.log
3. How long did it take to distribute the 50 MB to all three machines (this can be verified using wmdist -l -i <Dist_Id> -v)? What was the setting of the net_load parameter on the Tivoli Server? How long should it take theoretically to distribute the 50 MB to two targets using unicast?
347
1. When installing from the Tivoli Desktop, use the following options: Software package: sp_50MB.1.0. Targets: Both endpoints. Multicast enabled. Do not retry failed distributions using unicast. Force the distribution. (Why?)
2. How long did it take to distribute the 50 MB using Multicast? What was the setting of the mcast_netload? How long should it take theoretically to distribute the 50 MB to two targets using Multicast? 3. Launch the MDist2 GUI and log in as the Administrator user on the Tivoli Server. Compare both distributions (Time Spent, Node Table, and so on) using the MDist2 GUI.
348
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Appendix B.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Select the Additional materials and open the directory that corresponds with the redbook form number, SG246691.
349
350
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 352. Note that some of the documents referenced here may be available in softcopy only. All About IBM Tivoli Configuration Manager Version 4.2, SG24-6612 High Availability Scenarios with IBM Tivoli Workload Scheduler and IBM Tivoli Framework, SG24-6632 Migration to IBM Tivoli Configuration Manager Version 4.2, SG24-6616 Implementing Automated Inventory Scanning and Software Distribution After Auto Discovery, SG24-6626 Automated Distribution and Self-Healing with IBM Tivoli Configuration Manager V 4.2, SG24-6620
Other publications
These publications are also relevant as further information sources: IBM Tivoli Configuration Manager: Introducing IBM Tivoli Configuration Manager, Version 4.2.2, GC23-4703 IBM Tivoli Configuration Manager: Planning and Installation Guide, Version 4.2.2, GC23-4702 IBM Tivoli Configuration Manager: Users Guide for Software Distribution, Version 4.2.2, SC23-4711 IBM Tivoli Configuration Manager: Reference Manual for Software Distribution, Version 4.2.2, SC23-4712 IBM Tivoli Configuration Manager: Users Guide for Inventory, SC23-4713 IBM Tivoli Configuration Manager: Database Schema Reference, Version 4.2.2, SC23-4783
351
IBM Tivoli Configuration Manager: Messages and Codes, Version 4.2.2, SC23-4706 IBM Tivoli Configuration Manager: Users Guide for Deployment Services, Version 4.2.2, SC23-4710 Tivoli Management Framework Reference Manual, Version 4.1.1, SC32-0806
Online resources
These Web sites and URLs are also relevant as further information sources: The IBM Professional Certification Program Web site
http://www.ibm.com/certify/index.shtml
352
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Index
A
accept operation 147 Activity Plan Editor 67, 157 Monitor 67, 163, 165 types 157 Activity Planner 66, 156, 181 commands 167 components 156 configuration file 254 log files 255 processes 253 Roles 157 trace files 257 troubleshooting 253 ApiServlet.log 262 apply maintenance 85 authorization roles 25, 27 Automatic Deployment Services 191 Autotrace 239 dynamic control 239 First Failure Data Capture 239 Trace buffers 239 Trace ID 239 Trace Profiler 239 Change Manager 69, 168, 182 configuration file 258 trace files 259 checkpoint file 102 Checkpoint restart 219 checkpointGL_iqfile.dat 103 CM status summary 252 Collection clearing 120 data files 100 Manager 107 Manager components 107 scheduling 116 Collector 103, 116 Collection Manager 107 components 101 configuration 115 CTOC 116 debugging 269 deferring collections 116 depot chunk size 106 depot directory 104 disable a range of object ID 117 downstream 116 first Collector 118 input or error queue 106 Inventory Collectors 100 offlinks list 116 process 103 Queues 101 router cache 107 scheduling transmissions 116 setting offlinks 118 upstream 116 vieving configuration 107 Command wcancelscan 120 wcollect 103, 108, 116 wconvspo 138 wcrtdirctx 178 wcrtinvdh 108 wcrtqlib 130 wcrtquery 130 wcstat 99, 102
B
bandwidth 106 Best practices Multicast 234 browser 262
C
Callback object 108, 111112 caret 263 Certification benefits 3 checklist 5 IBM Professional Certification Program 2 process 7 Tivoli Certification 4 Change Management Status summary 252
353
wdelep 53 wdistinv 272 wep set_config 220 wepscan 128 wexpspo 138 wfptosp 136 wgetscanstat 120 winviso 128 wloadiso 128 wmanagedir 179 wmcast 215 wmdist 215 wmvinvdh 110 wmvrim 82 wresgw add 186 wsetquery 130 wsetrim 114 wspmvdata 151 wweb 186 commit phase 147 confccm.xml 173 Configuration elements 169 consistent install 85 Courses 9 Creating Data Handler 108 deployment plan 74 Query 129 CTOC 104105 custom scans 127
deferred queue 102, 117 Delta Install 150 demilitarized zones 57 deploying components 75 deployment plan 74 Deployment services 83 Depot 34 chunk size 106 directory 103 server 213 depot chunk size 106 device management troubleshooting 261 differencing mechanism 171 Directory query libraries 179 distmgr.log 244 Distribution Status Console 36, 242 Distribution Topology view 40 dmsadmin 185 dmsuser 185
E
Endpoint 17 log 238 Manager 107, 243 policies 92 endpoint login sequence 47 Enterprise Directory Query Facility 71 Services 176 Enterprise Directory Integration trace 266 troubleshooting 266 error queue 102103 ETL 153 events 58
D
Data collection tasks 116 time slots 116 Data Handler 106 components 108 creating 108 troubleshooting 267 Data Moving 73 log file 250 Service 151 trace files 250 troubleshooting 250 Data Retention 116 datapacks 106 debug level 269 debug level 3 268
F
Firewall Security Toolbox 56 flight recorder 239 Framework 4.1 239 Autotrace 239 FRESH subdirectory 88
G
gatelog 270 gateway logfile 270
354
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
H
Hub TMR 44, 46 hub-spoke architecture 43 Hyper Delivery 210
I
IBM Certification Agreement 6 initial login process 49 input queue 101 install operation 146 Installation Desktop Install 89 Java Virtual Machine 88 Multiple endpoints 91 Server 86 TMR server 86 Web Gateway 90 installation methods 85 installing endpoint proxy 61 event sink 6061 Firewall Security Toolbox 59 gateway proxy 6061 relay 6061 required roles 78 Installing pristine machines 192 Integrated Desktop Install Change Manager GUI 89 Components to install Activity Planner GUI 89 Distribution Status Console 89 Inventory GUI 89 Software Package Editor 89 Tivoli Desktop for Windows 89 Tivoli Java components 89 Integrated Install benefits 85 Integrated Desktop Install 89 Integrated Endpoint Install 90 Multiple Endpoints Installation 91 overview 85 Server Install 86 installation programs 88, 91
Typical Install 8687 Integrated Installation hints and tips 83 Installation types for ITCM 85 Java Virtual Machine 88 pre-install checks 83 Interface command line interface 1920 intermediate client 34 Inventory architecture 94 Configuration Repository 95 Data Handler 95, 108 Gateway / Collector 95 profile 96, 121 queries 128 repository 111 scan 188 scan methods 124 scanners 96 Inventory component 66, 94 Collector logging 269 log files 266 RIM trace 270 troubleshooting 266 troubleshooting on the endpoint 271 invtable.xml 173 ISMP 85 isolated login 52 scans 128 ITCM components 75
J
Java 1.3 for Tivoli 87 Client Framework for Tivoli 87 interface 34 RDBMS Interface Module 87
L
lcfd service 269 lcfd.log 268 LDAP troubleshooting 266 load opretation 147 lower level Collector 106
Index
355
M
Managed nodes 17 map of the collection hierarchy 107 mc_request_collection 107 Mcollect 269 mcollect.log 118 MDist 31, 33 MDist2 33 Depot 213 problems 244 MDist2 components 34 Distribution manager 34 GUI 34 Repeater Depot 34 Repeater manager 34 Repeater queue 34 Repeater site 34 Mobile Computing configuration files 251 log files 251 trace files 251 multicast 209, 225 broadcasts 214 distributions 220 limitations 230 log 232 receiver 213, 218 sender 213 multiple RIM objects 114 multiple TMR regions. 41 multiplexed distribution facility 31 multi-threaded process 100
list 117 method 116 offlinks list 117 off-peak period 116 one-way connection 42 Operations Console 264 orphan login 53 oserv 243 ostable.xml 173 output queue 101 thread 106, 118 output threads 118
P
Palm devices 184 Pearson VUE 6 Pervasive devices 183, 188 policy region 23, 46 policy scripts 54 after_install_policy 55 allow_install_policy 55 implementing 54 login_policy 56 Preboot Execution Environment 191 Pristine Manager 195 pristine tool 134 profile manager 29 Profile managers 30 Profiles 28 publications 11
N
name registry 43 netstat 234 netstat -s 234 network interface cards 221 nobody 103 Node Table view 39 normal login 51 Notification Manager 247
Q
query directories 179 queue 102, 106 Queues 101 queuing mechanism 34
R
RDBMS considerations 78 RDBMS Interface Module See RIM read data from Autotrace 240 Receiver 103 Redbooks Web site 352 Contact us xx region connection types 42
O
odadmin 270 environ 270 odlist 237 offlinks
356
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Remote Installation Service 190 remove operation 147 repeater depot 34 repository 112 Resetting offlinks 118 Resource Manager 70, 183, 185 Manager Gateway 86 types 186 retry function 34 RIM 34 agent process 271 considerations 81 host managed node 271 log 271 object 177 RIM_DB_LOG 271 Rim_vendor_Agent 271 runtime directory 104
Editor 132, 242 file 137 profile 143 Variables 141 Version 139 Source host 132 spoke TMR 4546 stable.xml 173 Status Chart view 37 Status Collector 110111 storage mechanism 34 store and forward collections 100 swdis.ini 266 synchronous 89
T
Task Library 253 Thomson Prometric 6 Time Spent Chart view 38 time-to-live integer 234 Tivoli administrator 22 architecture 16 Certification benefits 5 Data Warehouse interfaces 153 Desktop 19 Enterprise Data Warehouse 153 Framework Scheduler 118119 Management Console 95 Management Framework 86 Management Region See TMR Name Registry 46 resources 21 software education 9 tmersrvd 103 TMR 34 Toubleshooting Syncronization 252 trace 247 Troubleshooting Activity Planner 253 APM 253 append_log keyword 241 Autotrace 239 backup_fmt 246 base configuration file 247 Change Manager 258
S
Scalable Collection Service 97 Scenarios multicast 221 Multicast from gateways to Tivoli Management Agents 221 Pre-loading MDist2 depots with multicast 221 receiver and sender address is different 221 scheduler 25, 100, 106 scheduling activities 162 SCS 97, 111 select_gateway_policy 48, 50, 55 Setting Collector logging 270 Setup.exe 89 simplified maintenance 85 single server installation 86 slow wide area network 106 Software Distribution 131 component 65 components 131 delivery 144 process 134, 145 Software package 131 Autopack 142 block file 135 conditions 141 definition file 136 dependencies 140
Index
357
cm_status 241 Collector 269 Data Handler 270 Data Moving 250 default name for the log 242 e-mail 241 Enterprise Directory Integration 266 gateway log 243 Inventory 266 list_path 246 log_file 246 log_file_path 242 log_host 246 log_host_name 242 log_object_list 242 logs epmgrlog 238 gatelog 238 gwdb.log 238 odb.log 238 odtrace.log 238 oservlog 238 MDist2 244 Mobile Computing 250 notice group entry 241 object identification number 243 odadmin odlist command 243 pristine 251 pristine installation 251 prog_env 246 Resource Manager problems 261 set_debug_level option 243 Software Distribution traces 247 Software Package 245 software package 245 stop_on_error 246 Tivoli Software Distribution 240 trace_size 248 user_program 241 wadminep command 243 Web Gateway and device management 261 Web User Interface 262 wep command 243 wexpspo command 246 wgateway command 243 wgetspat command 246 wping command 243 two-way connection 43
U
undo operation 147 unicast 214 uninstallation 92 unload opretation 148 Upstream Collector 103
V
verify operation 147 view_config_info 243
W
wchkdb 46 wcollect 106 wcollect -h 103 wcollect -l 103 Web Gateway 184185, 261 component 70 Install 90 troubleshooting 261 Web Interface 71 Web Interface service 134 Web objects 185 Web User Interface DISSE0082E error message 264 inventory scan problems 264 login problems 262 Profile not found error 263 software package installation problems 264 tracing 265 tracing WebUI plug-in 265 Troubleshooting 262 troubleshooting 262 unable to publish web objects 263 Web-based courses 9 wgateway 270 wmdist 33, 35 wmsgbrowse 247 wrimtrace 271 wrpt 32 wswdcfg 247 wsyncsp 241 wsyncsp.log 252
358
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Back cover
Certification Study Guide: IBM Tivoli Configuration Manager (ITCM) Version 4.2.2
Helps you become ITCM 4.2.2 certified Explains the certification path and prerequisites Tips and best practices
This IBM Redbook is a study guide for IBM Tivoli Configuration Manager Version 4.2.2 and is aimed at the people who want to get IBM Certifications in this specific product. The IBM Tivoli Configuration Manager Certification, offered through the Professional Certification Program from IBM, is designed to validate the skills required of technical professionals who work in the implementation of the IBM Tivoli Configuration Manager Version 4.2.2 product. This book provides a combination of theory and practical experience needed for a general understanding of the subject matter. It also provides sample questions that will help in the evaluation of personal progress and provide familiarity with the types of questions that will be encountered in the exam. This publication does not replace practical experience, nor is it designed to be a stand-alone guide for any subject. Instead, it is an effective tool that, when combined with education activities and experience, can be a very useful preparation guide for the exam.
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.